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: Sat Apr 21 05:00:22 CEST 2018
media-tree git hash:1d338b86e17d87215cf57b1ad1d13b2afe582d33
media_build gi
Good day,
I am seeking your concept with great gratitude to present you as a
representative to carry out business transactions with a reasonable share upon
your interest and cooperation to work with us in trust. If interested please
get back.
Regards
Kingsley
---
This email has been checked
Hi,
On Wed, Apr 18, 2018 at 08:29:59PM +0200, Daniel Glöckner wrote:
> The VBI instruction queue read pointer points outside the VBI instruction
> queue and into the video y/packed CMDS (to 0x18+0x11*4). The values
> next to the iq rd ptr look ok.
>
> We only initialize the iq rd ptr to zero
Wolfram Sang writes:
> This header only contains platform_data. Move it to the proper directory.
>
> Signed-off-by: Wolfram Sang
For mach-pxa:
Acked-by: Robert Jarzmik
Take it through your tree, no problem for the pxa part.
Cheers.
--
Robert
Hi Mauro,
Thank you for the patch.
On 04/20/2018 09:01 PM, Mauro Carvalho Chehab wrote:
> Building this driver on arm64 gives this warning:
> drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error:
> return expression in void function
>
> Signed-off-by: Mauro Carvalho Chehab
On Thu, Apr 19, 2018 at 01:36:39PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> On Monday, 16 April 2018 15:36:50 EEST Maxime Ripard wrote:
> > From: Mylène Josserand
> >
> > Add the auto-focus ENABLE/DISABLE feature as V4L2 control.
> > Disabled by default.
> >
Hi Laurent,
On Thu, Apr 19, 2018 at 12:44:18PM +0300, Laurent Pinchart wrote:
> On Monday, 16 April 2018 15:36:51 EEST Maxime Ripard wrote:
> > From: Mylène Josserand
> >
> > Add the light frequency control to be able to set the frequency
> > to manual (50Hz or 60Hz) or auto.
> >
> > Signed-off
This driver depends on FB_VIA for lots of things. Provide stubs
for the functions it needs, in order to allow building it with
COMPILE_TEST outside x86 architecture.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7bae
Building this driver on arm64 gives this warning:
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error:
return expression in void function
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 4 ++--
1 file changed, 2 insertions(+
On Fri, Apr 20, 2018 at 04:29:42PM +0200, Daniel Mack wrote:
> Hi,
>
> On Friday, April 20, 2018 04:15 PM, Maxime Ripard wrote:
> > On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
>
> >> struct ov5640_ctrls {
> >>struct v4l2_ctrl_handler handler;
> >> + struct {
> >> +
From: Daniel Fu
Remove STATE_TRAILER_SPACE from state machine.
Causing 2 issue:
- can not decode the keycode, if it didn't following with
another keycode/repeat code
- will generate one more code in current logic.
i.e. key_right + repeat code + key_left + repeat code.
expect: key_right, key
From: Jun Yan
Add keymap with NEC and SONY12 protocol for NVIDIA IR
Signed-off-by: Jun Yan
Signed-off-by: marting
Signed-off-by: Daniel Fu
Signed-off-by: Vladislav Zhurba
---
drivers/media/rc/keymaps/Makefile| 2 +
drivers/media/rc/keymaps/rc-nvidia-nec.c | 66 +
Adds two IR keymaps for NVIDIA devices.
The RC types are SONY12 and NEC.
Jun Yan (1):
media: rc: Add NVIDIA IR keymapping
drivers/media/rc/keymaps/Makefile| 2 +
drivers/media/rc/keymaps/rc-nvidia-nec.c | 66
drivers/media/rc/keymaps/rc-nvidia.c | 66 +
Despite depending on ACPI, this driver builds fine on non-x86
archtecture with COMPILE_TEST, as it doesn't depend on
ACPI-specific functions/structs.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/intel/ipu3/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Add stubs for omapfb_dss.h, in the case it is included by
some driver when CONFIG_FB_OMAP2 is not defined, with can
happen on ARM when DRM_OMAP is not 'n'.
That allows building such driver(s) with COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab
---
include/video/omapfb_dss.h | 54 +++
Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.
I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
This driver depends on FB_VIA for lots of things. Provide stubs
for the functions it needs, in order to allow building it with
COMPILE_TEST outside x86 architecture.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/via-camera.c | 10 +++
The virt_to_bus/bus_to_virt macros are arch-specific. Some
archs don't support it. Yet, as it is interesting to allow
doing compilation tests on non-ia32/ia64 archs, provide a
fallback for such archs.
While here, enable COMPILE_TEST for two media drivers that
depends on it.
Signed-off-by: Mauro C
The pnp header already provide enough stub to build those
drivers with COMPILE_TEST on non-x86 archs.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/rc/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconf
Now that FB_OMAP has stubs, the omap2 media drivers can be
built on ARM with COMPILE_TEST && DRM_OMAP.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/platform/omap/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers
This driver depends on sony-laptop driver, but this is available
only for x86. So, add a stub function, in order to allow building
it on non-x86 too.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/meye/Kconfig | 3 ++-
include/linux/sony-laptop.h| 4
2 files changed, 6 inser
Hi Sakari,
On 04/20/2018 05:24 AM, Sakari Ailus wrote:
Hi Steve,
Thanks for the patchset.
On Tue, Mar 20, 2018 at 05:37:19PM -0700, Steve Longerbeam wrote:
v4l2_async_notifier_add_subdev() adds an asd to the notifier. It checks
that the asd's match_type is valid and that no other equivalent
On 04/19/18 23:11, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20180419:
>
> I have added a patch to the arm-current tree to fix build problems
> discovered overnight.
>
> Non-merge commits (relative to Linus' tree): 1278
> 1324 files changed, 47025 insertions(+), 20625 deletions(-)
>
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.
Would it not make sense to try to apply everything en masse rather th
Hi Hans,
On 04/20/2018 05:28 AM, Hans Verkuil wrote:
On 03/21/18 01:37, Steve Longerbeam wrote:
Parse neighbor remote devices on the video muxes input ports, add them to a
subdev notifier, and register the subdev notifier for the video mux, by
calling v4l2_async_register_fwnode_subdev().
Sign
Hi Hans,
On 04/20/2018 05:22 AM, Hans Verkuil wrote:
On 03/21/18 01:37, Steve Longerbeam wrote:
Generalize v4l2_async_notifier_fwnode_has_async_subdev() to allow
searching for any type of async subdev, not just fwnodes. Rename to
v4l2_async_notifier_has_async_subdev() and pass it an asd pointe
2018-04-18 21:55 GMT+09:00 jacopo mondi :
>> @@ -898,8 +922,20 @@ static int ov772x_s_power(struct v4l2_subdev *sd, int
>> on)
>> /* If the power count is modified from 0 to != 0 or from != 0 to 0,
>>* update the power state.
>>*/
>> - if (priv->power_count == !on)
>> -
On Fri, Apr 20, 2018 at 05:48:12PM +0200, Hans Verkuil wrote:
> On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote:
> > Hi Hans,
> >
> > Any comments?
>
> I have been traveling and haven't had time to look at this. Next week will
> be busy as well, but I expect to be able to look at it the we
On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote:
> Hi Hans,
>
> Any comments?
I have been traveling and haven't had time to look at this. Next week will
be busy as well, but I expect to be able to look at it the week after that.
I remember from the previous series that I couldn't test it
Hi Hans,
Any comments?
Thanks.
On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote:
> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
> but is also integrated into HDMI transceivers such as the TDA9989 and
> TDA19989.
>
> The TDA9950 contains a command processo
On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > > num_resources) which does the handling common to all drivers.
> > > A structure that
On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered
On Thursday, April 05, 2018 04:29:42 PM Mauro Carvalho Chehab wrote:
> This driver builds cleanly with COMPILE_TEST, and it is
> needed in order to allow building drivers/media omap2
> driver.
>
> So, change the logic there to allow building it.
>
> Signed-off-by: Mauro Carvalho Chehab
This cha
On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is ARCH_RENESAS a more appropriate platform dependency than the legacy
"ARCH_RENESAS is", no?
> ARCH_SHMOBILE, hence use the former.
>
> This will allow to drop ARCH_
Hi,
On Friday, April 20, 2018 04:15 PM, Maxime Ripard wrote:
> On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
>> struct ov5640_ctrls {
>> struct v4l2_ctrl_handler handler;
>> +struct {
>> +struct v4l2_ctrl *link_freq;
>> +struct v4l2_ctrl *pixel_rat
Hi,
On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
> Add v4l2 controls to report the pixel and MIPI link rates of each mode.
> The camss camera subsystem needs them to set up the correct hardware
> clocks.
>
> Tested on msm8016 based hardware.
>
> Signed-off-by: Daniel Mack
> ---
Hi,
On Fri, Apr 20, 2018 at 11:44:19AM +0200, Daniel Mack wrote:
> Allow setting the xclk rate via an optional 'clock-frequency' property in
> the device tree node.
>
> Signed-off-by: Daniel Mack
> ---
> Documentation/devicetree/bindings/media/i2c/ov5640.txt | 2 ++
> drivers/media/i2c/ov5640.
On 04/19/18 17:45, Paul Kocialkowski wrote:
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
>
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a co
On 04/19/18 17:45, Paul Kocialkowski wrote:
> This introduces support for Allwinner's MB32-tiled NV12 format, where
> each plane is divided into macroblocks of 32x32 pixels. Hence, the size
> of each plane has to be aligned to 32 bytes. The pixels inside each
> macroblock are coded as they would be
On 04/19/18 17:45, Paul Kocialkowski wrote:
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
>
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a co
On 04/19/18 17:41, Paul Kocialkowski wrote:
> When using the request API in the context of a m2m driver, the
> operations that come with a m2m run scheduling call in their
> (m2m-specific) ioctl handler are delayed until the request is queued
> (for instance, this includes queuing buffers and strea
On 04/19/18 17:41, Paul Kocialkowski wrote:
> When calling media operation driver callbacks related to media requests,
> only a pointer to the request itself is provided, which is insufficient
> to retrieve the driver's context. Since the driver context is usually
> set as vb2 queue private data an
On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven
wrote:
> Hi all,
>
> Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
> ARM SoCs. This patch series completes the conversion, by:
> 1. Updating de
On 04/19/18 17:41, Paul Kocialkowski wrote:
> This adds a missing v4l2_ctrl_unlock call that is required to avoid
> deadlocks.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers
All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
platform dependencies. Hence finish the conversion from ARCH_SHMOBILE
to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
Signed-off-by: Geert Uytterhoeven
-
The Kconfig symbol for Renesas 64-bit ARM SoCs has always been
ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared
with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs.
Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SH
Hi all,
Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
ARM SoCs. This patch series completes the conversion, by:
1. Updating dependencies for drivers that weren't converted yet,
2. Removing the AR
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency than the legacy
ARCH_SHMOBILE, hence use the former.
This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/Kco
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check.
This will allow to drop ARCH_SH
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check, just like before support for Ren
Emma Mobile is a Renesas ARM SoC. Since commit 9b5ba0df4ea4f940 ("ARM:
shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
platform dependency than the legacy ARCH_SHMOBILE, hence use the
former.
This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Signed-off-by: Ge
Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
both SuperH and ARM SoCs are supported.
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
SoCs than the legacy ARCH_SHMOBILE, hence
The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
than the legacy ARCH_SHMOBILE, hence use the former.
This will allow to drop ARCH_SHMOBILE o
On 04/13/18 08:59, Kai Heng Feng wrote:
> Hi,
>
>> On Mar 26, 2018, at 2:06 PM, Kai-Heng Feng
>> wrote:
>>
>> User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER.
>> Add the device to the id_table to make it work.
>
> *Gentle ping*
> I am hoping this patch can get merged in v4.
The following changes since commit 1d338b86e17d87215cf57b1ad1d13b2afe582d33:
media: v4l2-compat-ioctl32: better document the code (2018-04-20 08:24:13
-0400)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v4.18a
for you to fetch changes up to 548ea201
Hi Laurent,
I've addressed those your comments, that I had no questions for, but I'm
waiting for your replies to my clarification requests to finalise and post
the next revision of the patches.
Thanks
Guennadi
On Wed, 11 Apr 2018, Guennadi Liakhovetski wrote:
> Hi Laurent,
>
> First just ans
Em Fri, 20 Apr 2018 14:58:15 +0200
Takashi Iwai escreveu:
> On Fri, 20 Apr 2018 14:51:29 +0200,
> Mauro Carvalho Chehab wrote:
> >
> > Em Fri, 20 Apr 2018 14:37:46 +0200
> > Takashi Iwai escreveu:
> >
> > > On Fri, 20 Apr 2018 14:32:15 +0200,
> > > Mauro Carvalho Chehab wrote:
> > > >
> >
On Fri, 20 Apr 2018 14:58:55 +0200,
Mauro Carvalho Chehab wrote:
>
> Drivers that depend on ISAPNP currently can't be built with
> COMPILE_TEST. However, looking at isapnp.h, there are already
> stubs there to allow drivers to include it even when isa
> PNP is not supported.
>
> So, remove such d
On Fri, 20 Apr 2018 15:01:22 +0200,
Mauro Carvalho Chehab wrote:
>
> Em Fri, 20 Apr 2018 09:51:29 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Em Fri, 20 Apr 2018 14:37:46 +0200
> > Takashi Iwai escreveu:
> >
> > > On Fri, 20 Apr 2018 14:32:15 +0200,
> > > Mauro Carvalho Chehab wrote:
> > >
Em Fri, 20 Apr 2018 09:51:29 -0300
Mauro Carvalho Chehab escreveu:
> Em Fri, 20 Apr 2018 14:37:46 +0200
> Takashi Iwai escreveu:
>
> > On Fri, 20 Apr 2018 14:32:15 +0200,
> > Mauro Carvalho Chehab wrote:
> > >
> > > All sound drivers that don't depend on PNP can be safelly
> > > build with C
Drivers that depend on ISAPNP currently can't be built with
COMPILE_TEST. However, looking at isapnp.h, there are already
stubs there to allow drivers to include it even when isa
PNP is not supported.
So, remove such dependencies when COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab
---
drive
On Fri, 20 Apr 2018 14:51:29 +0200,
Mauro Carvalho Chehab wrote:
>
> Em Fri, 20 Apr 2018 14:37:46 +0200
> Takashi Iwai escreveu:
>
> > On Fri, 20 Apr 2018 14:32:15 +0200,
> > Mauro Carvalho Chehab wrote:
> > >
> > > All sound drivers that don't depend on PNP can be safelly
> > > build with COMP
Em Fri, 20 Apr 2018 14:37:46 +0200
Takashi Iwai escreveu:
> On Fri, 20 Apr 2018 14:32:15 +0200,
> Mauro Carvalho Chehab wrote:
> >
> > All sound drivers that don't depend on PNP can be safelly
> > build with COMPILE_TEST, as ISA provides function stubs to
> > be used for such purposes.
> >
> >
On 04/18/18 12:30, Sakari Ailus wrote:
> On Wed, Apr 18, 2018 at 01:46:08AM -0700, Matt Ranostay wrote:
>
> ...
>
>> On Wed, Apr 18, 2018 at 1:03 AM, Sakari Ailus wrote:
+ if (vid_cap_buf) {
+ struct vb2_buffer *vb2_buf =
&vid_cap_buf->vb.vb2_buf;
On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > num_resources) which does the handling common to all drivers.
> > A structure that contains
> >
> > {page,offset,len} + {dma_addr+dma_len}
> >
> > is not a
On Fri, 20 Apr 2018 14:32:15 +0200,
Mauro Carvalho Chehab wrote:
>
> All sound drivers that don't depend on PNP can be safelly
> build with COMPILE_TEST, as ISA provides function stubs to
> be used for such purposes.
>
> As a side effect, with this change, the radio-miropcm20
> can now be built o
All sound drivers that don't depend on PNP can be safelly
build with COMPILE_TEST, as ISA provides function stubs to
be used for such purposes.
As a side effect, with this change, the radio-miropcm20
can now be built outside i386 with COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab
---
drive
While now all media drivers build with COMPILE_TEST on i386, there are still
a few of them that don't build on x86_64.
Making them compiling there is just a matter of touching Kconfig files.
While here, fix smatch warnings when building the siano driver on big endian
architectures.
Mauro Carvalh
This driver doesn't use any weird API. So, allow building it
with COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/sta2x11/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/sta2x11/Kconfig
b/drivers/media/pci/sta2x11/Kconfig
in
Several radio devices only build on i386, because they depend
on ISA. Allow them to build on other archs by adding a
COMPILE_TEST check.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/radio/Kconfig | 38 --
1 file changed, 24 insertions(+), 14 deletion
Those are all false-positives that appear with smatch when building for
arm:
drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted
__le32
drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted
__le32
drivers/media/common/siano/smsendian.c:38:36: warni
On 03/21/18 01:37, Steve Longerbeam wrote:
> Parse neighbor remote devices on the video muxes input ports, add them to a
> subdev notifier, and register the subdev notifier for the video mux, by
> calling v4l2_async_register_fwnode_subdev().
>
> Signed-off-by: Steve Longerbeam
> ---
> Changes sin
Hi Steve,
Thanks for the patchset.
On Tue, Mar 20, 2018 at 05:37:19PM -0700, Steve Longerbeam wrote:
> v4l2_async_notifier_add_subdev() adds an asd to the notifier. It checks
> that the asd's match_type is valid and that no other equivalent asd's
> have already been added to this notifier's asd l
On 03/21/18 01:37, Steve Longerbeam wrote:
> Generalize v4l2_async_notifier_fwnode_has_async_subdev() to allow
> searching for any type of async subdev, not just fwnodes. Rename to
> v4l2_async_notifier_has_async_subdev() and pass it an asd pointer.
>
> TODO: support asd compare with CUSTOM match
On 03/21/18 01:37, Steve Longerbeam wrote:
> Documentation/devicetree/bindings/media/video-interfaces.txt states that
> the 'remote-endpoint' property is optional.
>
> So v4l2_async_notifier_fwnode_parse_endpoint() should not return error
> if the endpoint has no remote port parent. Just ignore th
On 04/20/18 13:44, Mauro Carvalho Chehab wrote:
> Em Fri, 20 Apr 2018 13:16:00 +0200
> Hans Verkuil escreveu:
>
> Thanks for the review!
>
>>> +/**
>>> + * do_video_ioctl() - Ancillary function with handles a compat32 ioctl call
>>> + *
>>> + * @file: pointer to &struct file with the file handle
On 04/20/18 13:45, Mauro Carvalho Chehab wrote:
> This file does a lot of non-trivial struff. Document it using
> kernel-doc markups where needed and improve the comments inside
> do_video_ioctl().
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
This file does a lot of non-trivial struff. Document it using
kernel-doc markups where needed and improve the comments inside
do_video_ioctl().
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 165 +-
1 file changed, 159 insertions(
Em Fri, 20 Apr 2018 13:16:00 +0200
Hans Verkuil escreveu:
Thanks for the review!
> > +/**
> > + * do_video_ioctl() - Ancillary function with handles a compat32 ioctl call
> > + *
> > + * @file: pointer to &struct file with the file handler
> > + * @cmd: ioctl to be called
> > + * @arg: arguments
Hi Mauro,
A bunch of typo, grammar and style fixes below. Looks good otherwise.
On 04/19/18 18:33, Mauro Carvalho Chehab wrote:
> This file does a lot of non-trivial struff. Document it using
> kernel-doc markups where needed and improve the comments inside
> do_video_ioctl().
>
> Signed-off-by:
On 04/19/18 18:33, Mauro Carvalho Chehab wrote:
> 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-compli
On 04/19/18 18:33, 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
Am 20.04.2018 um 12:17 schrieb Christoph Hellwig:
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into dma-buf", but that doesn't ren
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
> > Yes there's a bit a layering violation insofar that drivers really
> > shouldn't each have their own copy of "how do I convert a piece of dma
> > memory into dma-buf", but that doesn't render the interface a bad idea.
>
> Comple
Smatch complains that "venc" could be unintialized. There a couple
error paths where it looks like maybe that could happen. I don't know
if it's really a bug, but it's reasonable to set "venc" to NULL and
silence the warning.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/platform/dav
We check "lutdpc->dpc_size" in ipipe_validate_lutdpc_params() but if
it's invalid then we would have corrupted memory already when we do
the memcpy() before calling it.
We don't ever check "gamma->tbl_size" but we should since they come from
the user.
Signed-off-by: Dan Carpenter
diff --git a/d
Hi Paul,
On Fri, Apr 20, 2018 at 12:46 AM Paul Kocialkowski <
paul.kocialkow...@bootlin.com> wrote:
[snip]
> +struct v4l2_ctrl_mpeg2_frame_hdr {
> + __u32 slice_len;
> + __u32 slice_pos;
> + enum { MPEG1, MPEG2 } type;
Is enum suitable for UAPI?
> +
> + __u16 width;
> +
Allow setting the xclk rate via an optional 'clock-frequency' property in
the device tree node.
Signed-off-by: Daniel Mack
---
Documentation/devicetree/bindings/media/i2c/ov5640.txt | 2 ++
drivers/media/i2c/ov5640.c | 10 ++
2 files changed, 12 insertions(+)
This patch initializes the members of struct ov5640_mode_info by name for
better readability. This makes later additions to this struct easier.
No functional change intended.
Signed-off-by: Daniel Mack
---
drivers/media/i2c/ov5640.c | 207 +
1 file ch
Add v4l2 controls to report the pixel and MIPI link rates of each mode.
The camss camera subsystem needs them to set up the correct hardware
clocks.
Tested on msm8016 based hardware.
Signed-off-by: Daniel Mack
---
drivers/media/i2c/ov5640.c | 77 ++
1
Am 20.04.2018 um 09:13 schrieb Daniel Vetter:
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.
Of course we'll never
Hi Mauro,
Three patches for 4.17: two are fixes, one add a new cx231xx board.
Regards,
Hans
The following changes since commit 42a182282ea2426d56b2d63be634ee419194c45c:
media: si470x: fix a typo at the Makefile causing build issues (2018-04-18
15:21:41 -0400)
are available in the g
This driver needs a pull up output GPIO, but devm_gpiod_get() is called
with GPIOD_IN. This apparently works fine for the RPi3 where the DT
correctly specifies a pull up GPIO, but on the i.MX6 it also needs to
be specified with devm_gpiod_get().
Signed-off-by: Hans Verkuil
Reported-by: Henrik Mau
On Thu, 19 Apr 2018, Wolfram Sang wrote:
> This header only contains platform_data. Move it to the proper directory.
>
> Signed-off-by: Wolfram Sang
> ---
> MAINTAINERS | 2 +-
> arch/arm/mach-ks8695/board-acs5k.c | 2 +-
> arch/arm/mach-omap1/
Hi Mauro,
These patches include the low latency changes, which do make IR more
responsive. These patches could breaks things in subtle ways, so it
would be great to have these changes in early in the cycle.
Thanks,
Sean
The following changes since commit 8b8fcf32502694971fb7f166030361212cb2f9e6:
On Fri, Apr 20, 2018 at 12:43 AM Paul Kocialkowski <
paul.kocialkow...@bootlin.com> wrote:
> When using the request API in the context of a m2m driver, the
> operations that come with a m2m run scheduling call in their
> (m2m-specific) ioctl handler are delayed until the request is queued
> (for i
On Thu, Apr 19, 2018 at 05:45:35PM +0200, Paul Kocialkowski wrote:
> This adds nodes for the Video Engine and the associated reserved memory
> for the Allwinner A20. Up to 96 MiB of memory are dedicated to the VPU.
>
> The VPU can only map the first 256 MiB of DRAM, so the reserved memory
> pool h
Hi and thanks for the review,
On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote:
> Hi Paul, Philipp,
>
> On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel
> wrote:
>
> > Hi Paul,
> > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > > This adds a device-tree binding document that s
On Thu, Apr 19, 2018 at 05:41:15PM +0200, Paul Kocialkowski wrote:
> This adds a missing v4l2_ctrl_unlock call that is required to avoid
> deadlocks.
Maybe you can explain what the deadlock scenario is?
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 7 ++-
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> > We've broken that assumption in i915 years ago. Not struct page backed
> > gpu memory is very real.
> >
> > Of course we'll never feed such a strange sg table to
100 matches
Mail list logo
