Thank you for your response Peter!
Indeed, it seems strange. dvbsky.c driver seems to use mutex_lock in
very much the same way as many other drivers. I've now confirmed that
I can get a 4.10 kernel with working DVBSky S960 by reverting the
following 4 patches:
549bdd3 Revert "locking/mutex: Add l
Hi,
The Realtek 0bda:58f4 webcam which XPS 9370 uses doesn't work [1], not sure
if it's because Linux doesn't support UVC1.5:
[2.174138] Linux video capture interface: v2.00
[2.182580] usbcore: registered new interface driver btusb
[2.188376] uvcvideo: Found UVC 1.50 device Integr
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Apr 18 05:00:11 CEST 2018
media-tree git hash:8b8fcf32502694971fb7f166030361212cb2f9e6
media_build gi
On Tue, Apr 17, 2018 at 8:41 PM Paul Kocialkowski <
paul.kocialkow...@bootlin.com> wrote:
> Hi,
> On Tue, 2018-04-17 at 06:17 +, Alexandre Courbot wrote:
> > On Tue, Apr 17, 2018 at 3:12 PM Hans Verkuil
> > wrote:
> >
> > > On 04/17/2018 06:33 AM, Alexandre Courbot wrote:
> > > > On Mon, Apr
Hello Daniel,
See below.
Devin
[ 68.750805] cx88[0]: irq vid [0x18080] vbi_risc2* vbi_sync opc_err*
[ 68.750805] cx88[0]/0: video risc op code error
[ 68.750809] cx88[0]: video y / packed - dma channel status dump
[ 68.750811] cx88[0]: cmds: initial risc: 0x8aa98000
[ 68.750813] cx88
On Tue, Apr 17, 2018 at 05:59:47PM +0200, Maxime Ripard wrote:
> On Tue, Apr 17, 2018 at 04:20:10PM +0300, Sakari Ailus wrote:
> > On Tue, Apr 17, 2018 at 03:10:24PM +0200, Maxime Ripard wrote:
> > > Hi Sakari,
> > >
> > > On Fri, Apr 13, 2018 at 03:14:37PM +0300, Sakari Ailus wrote:
> > > > > +st
Hi Todor,
On Tue, Apr 17, 2018 at 06:32:07PM +0300, Todor Tomov wrote:
...
> >> +static int ov7251_regulators_enable(struct ov7251 *ov7251)
> >> +{
> >> + int ret;
> >> +
> >> + ret = regulator_enable(ov7251->io_regulator);
> >
> > How about regulator_bulk_enable() here, and bulk_disable below?
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Hi Sean!
On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote:
> mceusb devices have a default timeout of 100ms, but this can be changed.
We finally added a backport of the v2 series (and also the mce_kbd
series) to LibreELEC yesterday and ratcher quickly received 2 bugreports
from users us
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Hi all,
As of v4.17-rc1, patch series "[PATCH v2 0/5] Allow compile-testing
NO_DMA (core)" (https://lkml.org/lkml/2018/3/16/435) has been included
upstream, and drivers using the DMA API can be compile-tested on
platforms selecting NO_DMA.
This follow-up patch series removes dependencies
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
On Mon, Apr 16, 2018 at 04:22:39PM -0700, Samuel Bobrowicz wrote:
> I've been digging around the ov5640.c code for a few weeks now, these
> look like some solid improvements. I'll give them a shot and let you
> know how they work.
Great, thanks!
> On that note, I'm bringing up a module that uses
2018-04-16 19:55 GMT+09:00 Sakari Ailus :
> Hi Akinobu,
>
> As the driver now offers a V4L2 sub-device uAPI, it needs to serialise
> access to its internal data structures. This appears to be fine, but there
> are additional requirements; for instance ov772x_select_params() should
> likely fail if
Now the board values match the hard coded
constants used in the dvb initialization.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx23
Replace all usage of hard coded values with
the proper field from the board profile.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/me
Replace zero fill memset inits with
equivalent {} in declaration
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/media/usb/cx231xx/cx231xx-dvb.
Trim out some unused config params. Use the i2c mux
adapter returned by frontend with the tuner.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb
Mostly very straight forward replace of blocks with equivalent code.
Cleanup added at end of dvb_init in case of failure.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 331
1 file changed, 82 insertions(+), 249 deletions(-)
diff --git a
Hauppauge 935C cannot communicate with the si2157
when using the mux adapter returned by the si2168,
so disable it to fix the device.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx
cx231xx requires i2c mux adapter capability.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/Kconfig
b/drivers/media/usb/cx231xx/Kconfig
index 8a6acc2..98890a3 100644
--- a/drivers/media
VIDEO_CX231XX_RC requires RC_CORE, but VIDEO_CX231XX
does not require RC to compile or function.
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/Kconfig
b/drivers/media/usb/cx231xx/Kconfig
index 6276d9b.
Included in this patch set is:
- Bugfix for a device not working
- Some clean up and value corrections
- Conversion to new dvb i2c helpers
- Update of device from old dvb attach to i2c device
- Dependency fixes
- Style fixes
Brad Love (9):
cx231xx: Fix several incorrect demod addresses
cx231x
The default is now 0, no need to override
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index ac1d8e6..7fd096b 100644
--- a/drivers/media/u
On Tue, Apr 17, 2018 at 04:20:10PM +0300, Sakari Ailus wrote:
> On Tue, Apr 17, 2018 at 03:10:24PM +0200, Maxime Ripard wrote:
> > Hi Sakari,
> >
> > On Fri, Apr 13, 2018 at 03:14:37PM +0300, Sakari Ailus wrote:
> > > > +static int csi2tx_set_pad_format(struct v4l2_subdev *subdev,
> > > > +
Making the cast right for get_user/put_user is not trivial, as
it needs to ensure that the types are the correct ones.
Improve it by using macros.
Tested with vivid with:
$ sudo modprobe vivid no_error_inj=1
$ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a
-s
Hi Sakari,
Thank you for the review.
On 29.03.2018 14:51, Sakari Ailus wrote:
> Hi Todor,
>
> Thanks for the patch. A few quick comments below...
>
> On Fri, Mar 23, 2018 at 12:14:20PM +0800, Todor Tomov wrote:
>> The ov7251 sensor is a 1/7.5-Inch B&W VGA (640x480) CMOS Digital Image
>> Sensor
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Reference id -> 1c8f422059ae ("mm: change return type to
vm_fault_t")
Sign
Em Tue, 17 Apr 2018 10:58:24 -0300
Mauro Carvalho Chehab escreveu:
> Em Tue, 17 Apr 2018 10:10:09 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Em Tue, 17 Apr 2018 10:01:31 -0300
> > Mauro Carvalho Chehab escreveu:
> >
> > > > >> ->blocks is a u32, so this should be a u32 cast as well.
As we need to have a 32 bits version in order to check for
compat32 issues, let's print if v4l2-compliance was built
with 32 or 64 bits.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/utils/v4l2-compliance/v4l2-compliance.cpp
b/utils/v4l2-compliance/v4l2-compliance.cpp
index eb1f90fd7ad8..ec
Em Tue, 17 Apr 2018 10:10:09 -0300
Mauro Carvalho Chehab escreveu:
> Em Tue, 17 Apr 2018 10:01:31 -0300
> Mauro Carvalho Chehab escreveu:
>
> > > >> ->blocks is a u32, so this should be a u32 cast as well.
> > >
> > > Be aware that the unsigned char * cast is actually a bug: it will clam
Em Tue, 17 Apr 2018 15:11:10 +0200
Hans Verkuil escreveu:
> >> Be aware that the unsigned char * cast is actually a bug: it will clamp the
> >> u32 'blocks' value to a u8.
> >>
> >> Regards,
> >>
> >>Hans
> >
> > What about this approach (code untested)?
>
> I prefer the explicit casts.
On Tue, Apr 17, 2018 at 03:10:24PM +0200, Maxime Ripard wrote:
> Hi Sakari,
>
> On Fri, Apr 13, 2018 at 03:14:37PM +0300, Sakari Ailus wrote:
> > > +static int csi2tx_set_pad_format(struct v4l2_subdev *subdev,
> > > + struct v4l2_subdev_pad_config *cfg,
> > > +
On 04/17/18 15:01, Mauro Carvalho Chehab wrote:
> Em Tue, 17 Apr 2018 13:04:31 +0200
> Hans Verkuil escreveu:
>
>> On 04/17/18 12:53, Mauro Carvalho Chehab wrote:
>>> Em Tue, 17 Apr 2018 12:33:11 +0200
>>> Hans Verkuil escreveu:
>>>
On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
>
Hi Sakari,
On Fri, Apr 13, 2018 at 03:14:37PM +0300, Sakari Ailus wrote:
> > +static int csi2tx_set_pad_format(struct v4l2_subdev *subdev,
> > +struct v4l2_subdev_pad_config *cfg,
> > +struct v4l2_subdev_format *fmt)
> > +{
> > + struct csi
Em Tue, 17 Apr 2018 10:01:31 -0300
Mauro Carvalho Chehab escreveu:
> > >> ->blocks is a u32, so this should be a u32 cast as well.
> >
> > Be aware that the unsigned char * cast is actually a bug: it will clamp the
> > u32 'blocks' value to a u8.
> >
> > Regards,
> >
> > Hans
>
> What
Hi Daniel,
Thanks for the feedback.
On Tue, Apr 17, 2018 at 12:53 AM, Daniel Glöckner wrote:
>> [ 54.427224] cx88[0]: irq vid [0x10088] vbi_risc1* vbi_risc2* opc_err*
>> [ 54.427232] cx88[0]/0: video risc op code error
>> [ 54.427238] cx88[0]: video y / packed - dma channel status dump
>
Em Tue, 17 Apr 2018 13:04:31 +0200
Hans Verkuil escreveu:
> On 04/17/18 12:53, Mauro Carvalho Chehab wrote:
> > Em Tue, 17 Apr 2018 12:33:11 +0200
> > Hans Verkuil escreveu:
> >
> >> On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
> >>> Smatch report several issues with bad __user annotatio
On Tue, 2018-04-17 at 11:32 +0200, Ibtsam Ul-Haq wrote:
> On Tue, Apr 17, 2018 at 10:34 AM, Philipp Zabel
> wrote:
> > Hi Ibtsam,
> >
> > On Tue, 2018-04-17 at 09:26 +0200, Ibtsam Ul-Haq wrote:
> > > On Mon, Apr 16, 2018 at 11:30 AM, Philipp Zabel
> > > wrote:
> > > > On Mon, 2018-04-16 at 09:
On 04/17/18 14:16, Mauro Carvalho Chehab wrote:
> Em Tue, 17 Apr 2018 14:01:06 +0200
> Hans Verkuil escreveu:
>
>> On 04/17/18 13:55, Mauro Carvalho Chehab wrote:
>>> Em Tue, 17 Apr 2018 11:59:40 +0200
>>> Hans Verkuil escreveu:
>>>
On 04/16/18 21:41, Hans Verkuil wrote:
> On 04/16
Em Tue, 17 Apr 2018 14:01:06 +0200
Hans Verkuil escreveu:
> On 04/17/18 13:55, Mauro Carvalho Chehab wrote:
> > Em Tue, 17 Apr 2018 11:59:40 +0200
> > Hans Verkuil escreveu:
> >
> >> On 04/16/18 21:41, Hans Verkuil wrote:
> >>> On 04/16/2018 08:09 PM, Mauro Carvalho Chehab wrote:
>
IA_CSS_ERROR shows the ddr_buffer_addr as a decimal value with a '0x'
prefix, which is somewhat misleading.
Let's fix it to print hexadecimal, as was intended.
Fixes: 158aeefc("[media] atomisp: Add __printf validation and fix fallout")
Cc: Alan Cox
Cc: Sakari Ailus
Cc: Joe Perches
Signed-off
Em Mon, 16 Apr 2018 21:48:56 +0200
Hans Verkuil escreveu:
> On 04/16/2018 09:40 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 16 Apr 2018 21:27:01 +0200
> > Hans Verkuil escreveu:
> >
> >> On 04/16/2018 08:01 PM, Mauro Carvalho Chehab wrote:
> >>> Em Mon, 16 Apr 2018 15:21:16 +0200
> >>> Han
On 04/17/18 13:55, Mauro Carvalho Chehab wrote:
> Em Tue, 17 Apr 2018 11:59:40 +0200
> Hans Verkuil escreveu:
>
>> On 04/16/18 21:41, Hans Verkuil wrote:
>>> On 04/16/2018 08:09 PM, Mauro Carvalho Chehab wrote:
Em Mon, 16 Apr 2018 15:03:35 -0300
Mauro Carvalho Chehab escreveu:
Em Tue, 17 Apr 2018 11:59:40 +0200
Hans Verkuil escreveu:
> On 04/16/18 21:41, Hans Verkuil wrote:
> > On 04/16/2018 08:09 PM, Mauro Carvalho Chehab wrote:
> >> Em Mon, 16 Apr 2018 15:03:35 -0300
> >> Mauro Carvalho Chehab escreveu:
> >>
> >>> Em Mon, 16 Apr 2018 15:21:18 +0200
> >>> Hans Ve
Hi,
On Mon, 2018-04-09 at 16:20 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add support for requests to vim2m.
Please find a nit below.
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/platform/vim2m.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --
Hi,
On Tue, 2018-04-17 at 06:17 +, Alexandre Courbot wrote:
> On Tue, Apr 17, 2018 at 3:12 PM Hans Verkuil
> wrote:
>
> > On 04/17/2018 06:33 AM, Alexandre Courbot wrote:
> > > On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil
> > > wrote:
> > >
> > > > From: Hans Verkuil
> > > > Hi all,
> > >
Em Tue, 17 Apr 2018 13:04:31 +0200
Hans Verkuil escreveu:
> On 04/17/18 12:53, Mauro Carvalho Chehab wrote:
> > Em Tue, 17 Apr 2018 12:33:11 +0200
> > Hans Verkuil escreveu:
> >
> >> On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
> >>> Smatch report several issues with bad __user annotatio
On 04/17/18 12:53, Mauro Carvalho Chehab wrote:
> Em Tue, 17 Apr 2018 12:33:11 +0200
> Hans Verkuil escreveu:
>
>> On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
>>> Smatch report several issues with bad __user annotations:
>>>
>>> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning:
Em Tue, 17 Apr 2018 12:33:11 +0200
Hans Verkuil escreveu:
> On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
> > Smatch report several issues with bad __user annotations:
> >
> > drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect
> > type in argument 1 (different address
On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
> In the past, "up" were an acronym for "user pointer" and "kp" for
> "kernel pointer". However, since a1dfb4c48cc1 ("media:
> v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
> are now __user pointers.
>
> So, the usage of "kp" is really
On 04/17/18 12:20, Mauro Carvalho Chehab wrote:
> Smatch report several issues with bad __user annotations:
>
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect
> type in argument 1 (different address spaces)
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:e
Em Tue, 17 Apr 2018 06:20:10 -0400
Mauro Carvalho Chehab escreveu:
> There were several interactions at the COMPILE_TEST and smatch
> patch series. While I applied most of them, there are 5 patches that
> I kept out of it. The omap3 patch that were in my tree was the old
> one. So, I'm re-posting
In the past, "up" were an acronym for "user pointer" and "kp" for
"kernel pointer". However, since a1dfb4c48cc1 ("media:
v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
are now __user pointers.
So, the usage of "kp" is really misleading there. So, rename
both to just "p32" and "p64" e
There were several interactions at the COMPILE_TEST and smatch
patch series. While I applied most of them, there are 5 patches that
I kept out of it. The omap3 patch that were in my tree was the old
one. So, I'm re-posting it.
The ioctl32 patches are the latest version. Let's repost it to get some
From: Laurent Pinchart
The omap3isp driver can't be compiled on non-ARM platforms but has no
compile-time dependency on OMAP. It however requires common clock
framework support, which isn't provided by all ARM platforms.
Drop the OMAP dependency when COMPILE_TEST is set and add ARM and
COMMON_CL
Smatch report several issues with bad __user annotations:
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect type
in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void
[noderef] *uptr
drivers/media/v4l2-core/v4
From: Arnd Bergmann
There aren't much things required for it to build with COMPILE_TEST.
It just needs to not compile the code that depends on arm-specific
iommu implementation.
Signed-off-by: Arnd Bergmann
Co-developed-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
drive
Drivers that depend on omap-iommu.h (currently, just omap3isp)
need a stub implementation in order to be built with COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/omap-iommu.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/omap-iommu.h b/include/linu
On 04/16/18 21:41, Hans Verkuil wrote:
> On 04/16/2018 08:09 PM, Mauro Carvalho Chehab wrote:
>> Em Mon, 16 Apr 2018 15:03:35 -0300
>> Mauro Carvalho Chehab escreveu:
>>
>>> Em Mon, 16 Apr 2018 15:21:18 +0200
>>> Hans Verkuil escreveu:
>>>
From: Hans Verkuil
The v2 pad structure n
On Tue, Apr 17, 2018 at 10:34 AM, Philipp Zabel wrote:
> Hi Ibtsam,
>
> On Tue, 2018-04-17 at 09:26 +0200, Ibtsam Ul-Haq wrote:
>> On Mon, Apr 16, 2018 at 11:30 AM, Philipp Zabel
>> wrote:
>> > On Mon, 2018-04-16 at 09:54 +0200, Ibtsam Ul-Haq wrote:
>> > [...]
>> > > This indeed looks the case.
Em Sun, 8 Apr 2018 12:12:17 +0200
Matthias Schwarzott escreveu:
> Am 05.04.2018 um 19:54 schrieb Mauro Carvalho Chehab:
> > Drivers that depend on omap-iommu.h (currently, just omap3isp)
> > need a stub implementation in order to be built with COMPILE_TEST.
> >
> > Signed-off-by: Mauro Carvalho
Hi Jacob,
On Thu, Mar 8, 2018 at 6:49 PM Jacob Chen wrote:
> From: Jacob Chen
> This is the capture device interface driver that provides the v4l2
> user interface. Frames can be received from ISP1.
Thanks for the patch. Please find my comment inline.
[snip]
> +static int
> +rkisp1_start_str
Hi Ibtsam,
On Tue, 2018-04-17 at 09:26 +0200, Ibtsam Ul-Haq wrote:
> On Mon, Apr 16, 2018 at 11:30 AM, Philipp Zabel
> wrote:
> > On Mon, 2018-04-16 at 09:54 +0200, Ibtsam Ul-Haq wrote:
> > [...]
> > > This indeed looks the case. But then, is 'GR16' the FourCC for 'SGRBG16'?
> >
> > Yes, see Do
On Mon, Apr 16, 2018 at 11:30 AM, Philipp Zabel wrote:
> On Mon, 2018-04-16 at 09:54 +0200, Ibtsam Ul-Haq wrote:
> [...]
>> This indeed looks the case. But then, is 'GR16' the FourCC for 'SGRBG16'?
>
> Yes, see Documentation/media/uapi/v4l/pixfmt-srggb16.rst:
> https://linuxtv.org/downloads/v4l-dv
82 matches
Mail list logo
