Re: [PATCH RFT/RFC v2 01/47] staging: media: Revert "media: zoran: remove deprecated driver"

[Laurent Pinchart]

On Sat, May 07, 2022 at 10:58:39AM -0500, Sergey Meirovich wrote:
> Sergey Meirovich has sent you an email via Gmail confidential mode:
> 
> Gmail logoRe: [PATCH RFT/RFC v2 01/47] staging: media: Revert "media: zoran:
> remove deprecated driver"
> 
> This message was sent on May 7, 2022 at 8:58:50 AM PDT
> You can open it by clicking the link below. This link will only work for
> laurent.pinch...@ideasonboard.com.

Please don't use this feature when posting to public mailing lists. Such
messages will be totally ignored.

> View the email
> 
> Gmail confidential mode gives you more control over the messages you send. The
> sender may have chosen to set an expiration time, disable printing or
> forwarding, or track access to this message. Learn more
> 
> Gmail: Email by Google
> Use is subject to the Google Privacy PolicyGoogle
> Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USAlogo
> You have received this message because someone sent you an email via
> Gmail confidential mode.
> 

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v7 3/4] drm/bridge: anx7625: add MIPI DPI input feature

[Laurent Pinchart]

Hi Xin,

Thank you for the patch.

On Fri, Jun 11, 2021 at 05:13:33PM +0800, Xin Ji wrote:
> Add MIPI rx DPI input feature support.

Could you expand the commit message to explain what this feature is ?

> Reviewed-by: Robert Foss 
> Signed-off-by: Xin Ji 
> ---
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 245 --
>  drivers/gpu/drm/bridge/analogix/anx7625.h |  18 +-
>  2 files changed, 203 insertions(+), 60 deletions(-)

[snip]

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 4/5] drm/bridge: anx7625: add HDCP support

[Laurent Pinchart]

Hi Xin,

On Fri, Apr 02, 2021 at 10:27:08AM +0800, Xin Ji wrote:
> On Mon, Mar 29, 2021 at 02:02:08PM -0400, Sean Paul wrote:
> > On Mon, Mar 29, 2021 at 6:27 AM Xin Ji  wrote:
> > >
> > > On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> > > > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji  wrote:
> > > > >
> > > > > Add HDCP feature, enable HDCP function through chip internal key
> > > > > and downstream's capability.
> > > > >
> > > > > Signed-off-by: Xin Ji 
> > > > > ---
> > 
> > /snip
> > 
> > > > >  static void anx7625_dp_start(struct anx7625_data *ctx)
> > > > >  {
> > > > > int ret;
> > > > > @@ -643,6 +787,9 @@ static void anx7625_dp_start(struct anx7625_data 
> > > > > *ctx)
> > > > > return;
> > > > > }
> > > > >
> > > > > +   /* HDCP config */
> > > > > +   anx7625_hdcp_setting(ctx);
> > > >
> > > > You should really use the "Content Protection" property to
> > > > enable/disable HDCP instead of force-enabling it at all times.
> > >
> > > Hi Sean, it's hard to implement "Content Protection" property, we have
> > > implemented HDCP in firmware, it is not compatible with it. We don't
> > > have interface to get Downstream Cert.
> > > Thanks,
> > > Xin
> > 
> > Hi Xin,
> > I'm sorry, I don't understand what you mean when you say you don't
> > have an interface to get Downstream Cert.
> > 
> > The Content Protection property is just a means through which
> > userspace can turn on and turn off HDCP when it needs. As far as I can
> > tell, your patch turns on HDCP when the display is enabled and leaves
> > it on until it is disabled. This is undesirable since it forces HDCP
> > on the user.
> > 
> > Is it impossible to enable/disable HDCP outside of display
> > enable/disable on your hardware?
>
> Hi Sean, I have commit a test patch on google review site, can you
> please help to review it? I'll use Connector's ".atomic_check()"
> interface to detect Content Protection property change.
> (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2674580)

Please note that upstream review happens on mailing lists, not in
gerrit. Internal reviews for Chrome OS development are certainly fine
there, but that will not mean the patch will then be accepted upstream
as-is, it will still need to go through the upstream review process,
without any shortcut. I strongly recommend using an upstream-first
strategy, with public review.

> > > > > +
> > > > > if (ctx->pdata.is_dpi)
> > > > > ret = anx7625_dpi_config(ctx);
> > > > > else
> > 
> > /snip

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: media: omap4iss: code style - avoid macro argument precedence issues

[Laurent Pinchart]

Hi Nikolay,

Thank you for the patch.

On Sun, Feb 21, 2021 at 10:53:08PM +0300, Nikolay Kyx wrote:
> This patch fixes the following checkpatch.pl check:
> 
> CHECK: Macro argument 'i' may be better as '(i)' to avoid precedence issues
> 
> in file iss_regs.h
> 
> Signed-off-by: Nikolay Kyx 

Reviewed-by: Laurent Pinchart 

> ---
> 
> Additionally some style warnings remain valid here and could be fixed by
> another patch.
> 
>  drivers/staging/media/omap4iss/iss_regs.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_regs.h 
> b/drivers/staging/media/omap4iss/iss_regs.h
> index 09a7375c89ac..cfe0bb075072 100644
> --- a/drivers/staging/media/omap4iss/iss_regs.h
> +++ b/drivers/staging/media/omap4iss/iss_regs.h
> @@ -197,7 +197,7 @@
>  #define CSI2_TIMING_STOP_STATE_COUNTER_IO1_MASK  (0x1fff << 0)
>  #define CSI2_TIMING_STOP_STATE_COUNTER_IO1_SHIFT 0
>  
> -#define CSI2_CTX_CTRL1(i)(0x70 + (0x20 * i))
> +#define CSI2_CTX_CTRL1(i)(0x70 + (0x20 * (i)))
>  #define CSI2_CTX_CTRL1_GENERIC   BIT(30)
>  #define CSI2_CTX_CTRL1_TRANSCODE (0xf << 24)
>  #define CSI2_CTX_CTRL1_FEC_NUMBER_MASK   (0xff << 16)
> @@ -210,7 +210,7 @@
>  #define CSI2_CTX_CTRL1_PING_PONG BIT(3)
>  #define CSI2_CTX_CTRL1_CTX_ENBIT(0)
>  
> -#define CSI2_CTX_CTRL2(i)(0x74 + (0x20 * i))
> +#define CSI2_CTX_CTRL2(i)(0x74 + (0x20 * (i)))
>  #define CSI2_CTX_CTRL2_FRAME_MASK(0x << 16)
>  #define CSI2_CTX_CTRL2_FRAME_SHIFT   16
>  #define CSI2_CTX_CTRL2_USER_DEF_MAP_SHIFT13
> @@ -222,19 +222,19 @@
>  #define CSI2_CTX_CTRL2_FORMAT_MASK   (0x3ff << 0)
>  #define CSI2_CTX_CTRL2_FORMAT_SHIFT  0
>  
> -#define CSI2_CTX_DAT_OFST(i) (0x78 + (0x20 * i))
> +#define CSI2_CTX_DAT_OFST(i) (0x78 + (0x20 * (i)))
>  #define CSI2_CTX_DAT_OFST_MASK   (0xfff << 5)
>  
> -#define CSI2_CTX_PING_ADDR(i)(0x7c + (0x20 * 
> i))
> +#define CSI2_CTX_PING_ADDR(i)(0x7c + (0x20 * 
> (i)))
>  #define CSI2_CTX_PING_ADDR_MASK  0xffe0
>  
> -#define CSI2_CTX_PONG_ADDR(i)(0x80 + (0x20 * 
> i))
> +#define CSI2_CTX_PONG_ADDR(i)(0x80 + (0x20 * 
> (i)))
>  #define CSI2_CTX_PONG_ADDR_MASK  
> CSI2_CTX_PING_ADDR_MASK
>  
> -#define CSI2_CTX_IRQENABLE(i)(0x84 + (0x20 * 
> i))
> -#define CSI2_CTX_IRQSTATUS(i)(0x88 + (0x20 * 
> i))
> +#define CSI2_CTX_IRQENABLE(i)(0x84 + (0x20 * 
> (i)))
> +#define CSI2_CTX_IRQSTATUS(i)(0x88 + (0x20 * 
> (i)))
>  
> -#define CSI2_CTX_CTRL3(i)(0x8c + (0x20 * i))
> +#define CSI2_CTX_CTRL3(i)    (0x8c + (0x20 * (i)))
>  #define CSI2_CTX_CTRL3_ALPHA_SHIFT   5
>  #define CSI2_CTX_CTRL3_ALPHA_MASK\
>   (0x3fff << CSI2_CTX_CTRL3_ALPHA_SHIFT)

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: media: omap4iss: code style - avoid macro argument precedence issues

[Laurent Pinchart]

Hi Nikolay,

On Mon, Feb 22, 2021 at 12:21:36AM +0300, Nikolay K. wrote:
> Hi Laurent,
> 
> Thank you for the review.
> I think that if we drop the unneeded parentheses here, we need to drop
> them everywhere in the file for consistency, even in places checkpatch.pl

That's a good point.

> doesn't warn about. It'll increase patch size without actual usefullness 
> gain, as for me. I am very (very) novice to the kernel,
> but who wants slightly more readable one-line simple macros?

Let's keep your patch as-is, we can drop the unneeded parentheses in a
subsequent patch if desired.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: media: omap4iss: code style - avoid macro argument precedence issues

[Laurent Pinchart]

Hi Nikolay,

Thank you for the patch.

On Sun, Feb 21, 2021 at 10:53:08PM +0300, Nikolay Kyx wrote:
> This patch fixes the following checkpatch.pl check:
> 
> CHECK: Macro argument 'i' may be better as '(i)' to avoid precedence issues
> 
> in file iss_regs.h
> 
> Signed-off-by: Nikolay Kyx 
> ---
> 
> Additionally some style warnings remain valid here and could be fixed by
> another patch.
> 
>  drivers/staging/media/omap4iss/iss_regs.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_regs.h 
> b/drivers/staging/media/omap4iss/iss_regs.h
> index 09a7375c89ac..cfe0bb075072 100644
> --- a/drivers/staging/media/omap4iss/iss_regs.h
> +++ b/drivers/staging/media/omap4iss/iss_regs.h
> @@ -197,7 +197,7 @@
>  #define CSI2_TIMING_STOP_STATE_COUNTER_IO1_MASK  (0x1fff << 0)
>  #define CSI2_TIMING_STOP_STATE_COUNTER_IO1_SHIFT 0
>  
> -#define CSI2_CTX_CTRL1(i)(0x70 + (0x20 * i))
> +#define CSI2_CTX_CTRL1(i)(0x70 + (0x20 * (i)))

This is a good change, as it fixes potential issues, but maybe we could
go one step forward and drop the unneeded parentheses ?

-#define CSI2_CTX_CTRL1(i)  (0x70 + (0x20 * i))
+#define CSI2_CTX_CTRL1(i)  (0x70 + 0x20 * (i))

What do you think ?

>  #define CSI2_CTX_CTRL1_GENERIC   BIT(30)
>  #define CSI2_CTX_CTRL1_TRANSCODE (0xf << 24)
>  #define CSI2_CTX_CTRL1_FEC_NUMBER_MASK   (0xff << 16)
> @@ -210,7 +210,7 @@
>  #define CSI2_CTX_CTRL1_PING_PONG BIT(3)
>  #define CSI2_CTX_CTRL1_CTX_ENBIT(0)
>  
> -#define CSI2_CTX_CTRL2(i)(0x74 + (0x20 * i))
> +#define CSI2_CTX_CTRL2(i)(0x74 + (0x20 * (i)))
>  #define CSI2_CTX_CTRL2_FRAME_MASK(0x << 16)
>  #define CSI2_CTX_CTRL2_FRAME_SHIFT   16
>  #define CSI2_CTX_CTRL2_USER_DEF_MAP_SHIFT13
> @@ -222,19 +222,19 @@
>  #define CSI2_CTX_CTRL2_FORMAT_MASK   (0x3ff << 0)
>  #define CSI2_CTX_CTRL2_FORMAT_SHIFT  0
>  
> -#define CSI2_CTX_DAT_OFST(i) (0x78 + (0x20 * i))
> +#define CSI2_CTX_DAT_OFST(i) (0x78 + (0x20 * (i)))
>  #define CSI2_CTX_DAT_OFST_MASK   (0xfff << 5)
>  
> -#define CSI2_CTX_PING_ADDR(i)(0x7c + (0x20 * 
> i))
> +#define CSI2_CTX_PING_ADDR(i)(0x7c + (0x20 * 
> (i)))
>  #define CSI2_CTX_PING_ADDR_MASK  0xffe0
>  
> -#define CSI2_CTX_PONG_ADDR(i)(0x80 + (0x20 * 
> i))
> +#define CSI2_CTX_PONG_ADDR(i)(0x80 + (0x20 * 
> (i)))
>  #define CSI2_CTX_PONG_ADDR_MASK  
> CSI2_CTX_PING_ADDR_MASK
>  
> -#define CSI2_CTX_IRQENABLE(i)(0x84 + (0x20 * 
> i))
> -#define CSI2_CTX_IRQSTATUS(i)(0x88 + (0x20 * 
> i))
> +#define CSI2_CTX_IRQENABLE(i)(0x84 + (0x20 * 
> (i)))
> +#define CSI2_CTX_IRQSTATUS(i)(0x88 + (0x20 * 
> (i)))
>  
> -#define CSI2_CTX_CTRL3(i)(0x8c + (0x20 * i))
> +#define CSI2_CTX_CTRL3(i)    (0x8c + (0x20 * (i)))
>  #define CSI2_CTX_CTRL3_ALPHA_SHIFT   5
>  #define CSI2_CTX_CTRL3_ALPHA_MASK\
>   (0x3fff << CSI2_CTX_CTRL3_ALPHA_SHIFT)

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFT/RFC v2 00/47] staging: media: bring back zoran driver

[Laurent Pinchart]

gt;   staging: media: zoran: move v4l_settings out of zoran_fh
> >   staging: media: zoran: move jpg_settings out of zoran_fh
> >   staging: media: zoran: move overlay_settings out of zoran_fh
> >   staging: media: zoran: Use video_drvdata to get struct zoran
> >   staging: media: zoran: Change zoran_v4l_set_format parameter from
> > zoran_fh to zoran
> >   staging: media: zoran: remove overlay
> >   staging: media: zoran: Use DMA coherent for stat_com
> >   staging: media: zoran: use ZR_NORM
> >   staging: media: zoran: zoran does not support STD_ALL
> >   staging: media: zoran: convert irq to pci irq
> >   staging: media: zoran: convert zoran alloc to devm
> >   staging: media: zoran: convert mdelay to udelay
> >   staging: media: zoran: use devm for videocodec_master alloc
> >   staging: media: zoran: use pci_request_regions
> >   staging: media: zoran: use devm_ioremap
> >   staging: media: zoran: add stat_com buffer
> >   staging: media: zoran: constify struct tvnorm
> >   staging: media: zoran: constify codec_name
> >   staging: media: zoran: Add more check for compliance
> >   staging: media: zoran: Add vb_queue
> >   staging: media: zoran: disable output
> >   staging: media: zoran: device support only 32bit DMA address
> >   staging: media: zoran: enable makefile
> >   staging: media: zoran: remove framebuffer support
> >   staging: media: zoran: add vidioc_g_parm
> >   staging: media: zoran: remove test_interrupts
> >   staging: media: zoran: fix use of buffer_size and sizeimage
> >   staging: media: zoran: fix some compliance test
> >   staging: media: zoran: remove deprecated .vidioc_g_jpegcomp
> >   staging: media: zoran: convert to vb2
> >   staging: media: zoran: update TODO
> > 
> >  Documentation/media/v4l-drivers/zoran.rst  |  575 +
> >  MAINTAINERS|   10 +
> >  drivers/staging/media/Kconfig  |2 +
> >  drivers/staging/media/Makefile |1 +
> >  drivers/staging/media/zoran/Kconfig|   76 ++
> >  drivers/staging/media/zoran/Makefile   |7 +
> >  drivers/staging/media/zoran/TODO   |   19 +
> >  drivers/staging/media/zoran/videocodec.c   |  330 +
> >  drivers/staging/media/zoran/videocodec.h   |  308 +
> >  drivers/staging/media/zoran/zoran.h|  320 +
> >  drivers/staging/media/zoran/zoran_card.c   | 1333 
> >  drivers/staging/media/zoran/zoran_card.h   |   30 +
> >  drivers/staging/media/zoran/zoran_device.c | 1013 +++
> >  drivers/staging/media/zoran/zoran_device.h |   64 +
> >  drivers/staging/media/zoran/zoran_driver.c | 1038 +++
> >  drivers/staging/media/zoran/zr36016.c  |  433 +++
> >  drivers/staging/media/zoran/zr36016.h  |   92 ++
> >  drivers/staging/media/zoran/zr36050.c  |  842 +
> >  drivers/staging/media/zoran/zr36050.h  |  163 +++
> >  drivers/staging/media/zoran/zr36057.h  |  154 +++
> >  drivers/staging/media/zoran/zr36060.c  |  872 +
> >  drivers/staging/media/zoran/zr36060.h  |  201 +++
> >  22 files changed, 7883 insertions(+)
> >  create mode 100644 Documentation/media/v4l-drivers/zoran.rst
> >  create mode 100644 drivers/staging/media/zoran/Kconfig
> >  create mode 100644 drivers/staging/media/zoran/Makefile
> >  create mode 100644 drivers/staging/media/zoran/TODO
> >  create mode 100644 drivers/staging/media/zoran/videocodec.c
> >  create mode 100644 drivers/staging/media/zoran/videocodec.h
> >  create mode 100644 drivers/staging/media/zoran/zoran.h
> >  create mode 100644 drivers/staging/media/zoran/zoran_card.c
> >  create mode 100644 drivers/staging/media/zoran/zoran_card.h
> >  create mode 100644 drivers/staging/media/zoran/zoran_device.c
> >  create mode 100644 drivers/staging/media/zoran/zoran_device.h
> >  create mode 100644 drivers/staging/media/zoran/zoran_driver.c
> >  create mode 100644 drivers/staging/media/zoran/zr36016.c
> >  create mode 100644 drivers/staging/media/zoran/zr36016.h
> >  create mode 100644 drivers/staging/media/zoran/zr36050.c
> >  create mode 100644 drivers/staging/media/zoran/zr36050.h
> >  create mode 100644 drivers/staging/media/zoran/zr36057.h
> >  create mode 100644 drivers/staging/media/zoran/zr36060.c
> >  create mode 100644 drivers/staging/media/zoran/zr36060.h

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/49] DRM driver for Hikey 970

[Laurent Pinchart]

Hi Mauro,

On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 25 Aug 2020 05:29:29 +1000
> Dave Airlie  escreveu:
> 
> > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> >  wrote:
> > >
> > > Hi Mauro,
> > >
> > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:  
> > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:  
> > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:  
> > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:  
> > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab 
> > > > > > > wrote:  
> > > > > > > > This patch series port the out-of-tree driver for Hikey 970 
> > > > > > > > (which
> > > > > > > > should also support Hikey 960) from the official 96boards tree:
> > > > > > > >
> > > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > > > > > > >
> > > > > > > > Based on his history, this driver seems to be originally written
> > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > > > > > > implementation for FB dev API.
> > > > > > > >
> > > > > > > > As I need to preserve the original history (with has patches 
> > > > > > > > from
> > > > > > > > both HiSilicon and from Linaro),  I'm starting from the original
> > > > > > > > patch applied there. The remaining patches are incremental,
> > > > > > > > and port this driver to work with upstream Kernel.
> > > > > > > >  
> > > > > ...  
> > > > > > > > - Due to legal reasons, I need to preserve the authorship of
> > > > > > > >   each one responsbile for each patch. So, I need to start from
> > > > > > > >   the original patch from Kernel 4.4;  
> > > > > ...  
> > > > > > > I do acknowledge you need to preserve history and all -
> > > > > > > but this patchset is not easy to review.  
> > > > > >
> > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by 
> > > > > > and
> > > > > > Co-developed-by should be enough, shouldn't it ? Having a public 
> > > > > > branch
> > > > > > that contains the history is useful if anyone is interested, but I 
> > > > > > don't
> > > > > > think it's required in mainline.  
> > > > >
> > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you
> > > > > have on this but preserving the "absolute" history here is actively
> > > > > detrimental for review and understanding of the patch set.
> > > > >
> > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by
> > > > > lines should be sufficient to provide both atribution credit and DCO
> > > > > history.  
> > > >
> > > > I'm not convinced that, from legal standpoint, folding things would
> > > > be enough. See, there are at least 3 legal systems involved here
> > > > among the different patch authors:
> > > >
> > > >   - civil law;
> > > >   - common law;
> > > >   - customary law + common law.
> > > >
> > > > Merging stuff altogether from different law systems can be problematic,
> > > > and trying to discuss this with experienced IP property lawyers will
> > > > for sure take a lot of time and efforts. I also bet that different
> > > > lawyers will have different opinions, because laws are subject to
> > > > interpretation. With that matter I'm not aware of any court rules
> > > > with regards to folded patches. So, it sounds to me that folding
> > > > patches is something that has yet to be proofed in courts around
> > > > the globe.
> > > >
> > > > At least for US legal system, it sounds that the Country of
> > > > origin of a patch is relevant, as they have a concept of
> > > > "national technology" that can be subject

Re: [PATCH 00/49] DRM driver for Hikey 970

[Laurent Pinchart]

Hi Mauro,

On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:
> > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:
> > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:  
> > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:  
> > > > > This patch series port the out-of-tree driver for Hikey 970 (which
> > > > > should also support Hikey 960) from the official 96boards tree:
> > > > >
> > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > > > >
> > > > > Based on his history, this driver seems to be originally written
> > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > > > implementation for FB dev API.
> > > > >
> > > > > As I need to preserve the original history (with has patches from
> > > > > both HiSilicon and from Linaro),  I'm starting from the original
> > > > > patch applied there. The remaining patches are incremental,
> > > > > and port this driver to work with upstream Kernel.
> > > > >  
> > ...
> > > > > - Due to legal reasons, I need to preserve the authorship of
> > > > >   each one responsbile for each patch. So, I need to start from
> > > > >   the original patch from Kernel 4.4;  
> > ...
> > > > I do acknowledge you need to preserve history and all -
> > > > but this patchset is not easy to review.  
> > >
> > > Why do we need to preserve history ? Adding relevant Signed-off-by and
> > > Co-developed-by should be enough, shouldn't it ? Having a public branch
> > > that contains the history is useful if anyone is interested, but I don't
> > > think it's required in mainline.  
> > 
> > Yea. I concur with Laurent here. I'm not sure what legal reasoning you
> > have on this but preserving the "absolute" history here is actively
> > detrimental for review and understanding of the patch set.
> > 
> > Preserving Authorship, Signed-off-by lines and adding Co-developed-by
> > lines should be sufficient to provide both atribution credit and DCO
> > history.
> 
> I'm not convinced that, from legal standpoint, folding things would
> be enough. See, there are at least 3 legal systems involved here
> among the different patch authors:
> 
>   - civil law;
>   - common law;
>   - customary law + common law.
> 
> Merging stuff altogether from different law systems can be problematic,
> and trying to discuss this with experienced IP property lawyers will
> for sure take a lot of time and efforts. I also bet that different
> lawyers will have different opinions, because laws are subject to 
> interpretation. With that matter I'm not aware of any court rules 
> with regards to folded patches. So, it sounds to me that folding 
> patches is something that has yet to be proofed in courts around
> the globe.
> 
> At least for US legal system, it sounds that the Country of
> origin of a patch is relevant, as they have a concept of
> "national technology" that can be subject to export regulations.
> 
> From my side, I really prefer to play safe and stay out of any such
> legal discussions.

Let's be serious for a moment. If you think there are legal issues in
taking GPL-v2.0-only patches and squashing them while retaining
authorship information through tags, the Linux kernel if *full* of that.
You also routinely modify patches that you commit to the media subsystem
to fix "small issues".

The country of origin argument makes no sense either, the kernel code
base if full of code coming from pretty much all country on the planet.

Keeping the patches separate make this hard to review. Please squash
them.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/49] DRM driver for Hikey 970

[Laurent Pinchart]

fault GEM_CMA fops
> >   staging: hikey9xx/gpu: place vblank enable/disable at the right place
> >   staging: hikey9xx/gpu: remove an uneeded hack
> >   staging: hikey9xx/gpu: add a possible implementation for
> > atomic_disable
> >   staging: hikey9xx/gpu: register connector
> >   staging: hikey9xx/gpu: fix driver name
> >   staging: hikey9xx/gpu: get rid of iommu_format
> >   staging: hikey9xx/gpu: re-work the mode validation code
> >   staging: hikey9xx/gpu: add support for enable/disable ldo3 regulator
> >   staging: hikey9xx/gpu: add SPMI headers
> >   staging: hikey9xx/gpu: solve most coding style issues
> >   staging: hikey9xx/gpu: don't use iommu code
> >   staging: hikey9xx/gpu: add kirin9xx driver to the building system
> >   staging: hikey9xx/gpu: get rid of typedefs
> >   staging: hikey9xx/gpu: get rid of input/output macros
> >   staging: hikey9xx/gpu: get rid of some unused data
> >   staging: hikey9xx/gpu: place common definitions at kirin9xx_dpe.h
> >   staging: hikey9xx/gpu: get rid of DRM_HISI_KIRIN970
> >   dts: hisilicon: hi3670.dtsi: add I2C settings
> >   dts: hikey970-pinctrl.dtsi: add missing pinctrl settings
> >   dt: hisilicon: add support for the PMIC found on Hikey 970
> >   dts: add support for Hikey 970 DRM
> >   staging: hikey9xx/gpu: drop kirin9xx_pwm
> >   dt: display: Add binds for the DPE and DSI controller for Kirin
> > 960/970
> > 
> > Xiubin Zhang (7):
> >   staging: hikey9xx/gpu: add support to hikey970 HDMI and panel
> >   staging: hikey9xx/gpu: Solve SR Cannot Display Problems.
> >   staging: hikey9xx/gpu: Solve HDMI compatibility Problem.
> >   staging: hikey9xx/gpu: Support MIPI DSI 3 lanes for hikey970.
> >   staging: hikey9xx/gpu: Solve SR test reset problem for hikey970.
> >   staging: hikey9xx/gpu: add debug prints for this driver
> >   staging: hikey9xx/gpu: Add support 10.1 inch special HDMI displays.
> > 
> >  .../display/hisilicon,hi3660-dpe.yaml |   99 +
> >  .../display/hisilicon,hi3660-dsi.yaml |  102 +
> >  .../boot/dts/hisilicon/hi3670-hikey970.dts|   56 +-
> >  arch/arm64/boot/dts/hisilicon/hi3670.dtsi |   77 +
> >  .../boot/dts/hisilicon/hikey970-drm.dtsi  |   93 +
> >  .../boot/dts/hisilicon/hikey970-pinctrl.dtsi  |  548 +++-
> >  .../boot/dts/hisilicon/hikey970-pmic.dtsi |  197 ++
> >  drivers/staging/hikey9xx/Kconfig  |3 +
> >  drivers/staging/hikey9xx/Makefile |1 +
> >  drivers/staging/hikey9xx/gpu/Kconfig  |   22 +
> >  drivers/staging/hikey9xx/gpu/Makefile |9 +
> >  drivers/staging/hikey9xx/gpu/kirin960_defs.c  |  378 +++
> >  .../staging/hikey9xx/gpu/kirin960_dpe_reg.h   |  233 ++
> >  drivers/staging/hikey9xx/gpu/kirin970_defs.c  |  381 +++
> >  .../staging/hikey9xx/gpu/kirin970_dpe_reg.h   | 1188 
> >  drivers/staging/hikey9xx/gpu/kirin9xx_dpe.h   | 2437 +
> >  .../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 1178 
> >  .../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h |  286 ++
> >  .../staging/hikey9xx/gpu/kirin9xx_drm_drv.c   |  368 +++
> >  .../staging/hikey9xx/gpu/kirin9xx_drm_drv.h   |   57 +
> >  .../staging/hikey9xx/gpu/kirin9xx_drm_dss.c   | 1063 +++
> >  .../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 1005 +++
> >  .../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 2132 ++
> >  .../hikey9xx/gpu/kirin9xx_dw_dsi_reg.h|  146 +
> >  .../staging/hikey9xx/gpu/kirin9xx_fb_panel.h  |  191 ++
> >  25 files changed, 12229 insertions(+), 21 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/hisilicon,hi3660-dpe.yaml
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/hisilicon,hi3660-dsi.yaml
> 
> Patch that intropduce new bindings must following the submitting patches
> guidelines for bindings. For once the subject is "dt-bindings: bla bla".
> 
> >  create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-drm.dtsi
> >  create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi
> >  create mode 100644 drivers/staging/hikey9xx/gpu/Kconfig
> >  create mode 100644 drivers/staging/hikey9xx/gpu/Makefile
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_defs.c
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_defs.c
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dpe.h
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
> >  create mode 100644 
> > drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dw_dsi_reg.h
> >  create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: nxp imx8m CSI drivers

[Laurent Pinchart]

Hi Martin,

On Tue, Jul 28, 2020 at 12:36:58PM +0200, Martin Kepplinger wrote:
> On 09.07.20 11:32, Martin Kepplinger wrote:
> > hi linux-media people,
> > 
> > TL-DR: when exactly is "sd->entity.function == MEDIA_ENT_F_VID_MUX"?
> > 
> > 
> > I try to use the camera on our librem5-devkit (imx8mq): I try to use
> > only mainline drivers except for "mxc-mipi-csi2_yav" taken from
> > linux-imx (which we can prepare to submit if a PoC works. This is the
> > tree I'm experimenting with:
> > 
> > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc4/librem5___csi
> > 
> > * "imx7-media-csi" / imx-media-capture / imx-media-utils currently in
> > staging (that should work according to NXP)
> > * ov5640 mainline driver
> > * mxc-mipi-csi2_yav from NXP tree (linux-imx) with
> > v4l2_subdev_video_ops' mipi_csis_g_parm and mipi_csis_s_parm callbacks
> > removed (due to missing API in mainline)
> > 
> > the drivers probe and run but the following fails when trying to use the
> > camera (gstreamer):
> > 
> > in imx-media-utils' imx_media_pipeline_set_stream() the call to
> > v4l2_subdev_call(sd, video, s_stream, 1) returns with 32 (broken pipe)
> > and thus the application that tries to use the camera too.
> > 
> > One problem is definitely the trees' last commit (that I did as a
> > workaround) in this tree that makes the drivers probe but only by
> > ignoring this probably needed check:
> > 
> > imx7-media-csi's imx7_csi_notify_bound() callback implementation gets
> > called during startup. But if (WARN_ON(sd->entity.function !=
> > MEDIA_ENT_F_VID_MUX)) is true so this is the wrong type of subdev (?).
> > 
> > I just want to put this out there and check if the general approach is
> > valid at all and if there's anything that comes to your mind.
> 
> (added Pavel Machek)
> 
> still I'm only on the librem5 Devkit: the situation regarding a tree
> that should use the imx7-media-csi csi_bridge driver hasn't changed, see
> above for the details. The tree I tried now is this one:
> 
> https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc7/librem5___csi_ml1
> 
> A tree that includes NXP's csi_bridge and mipi-csi drivers (and camera
> driver) on the other hand works, and I have one based on v5.8-rcX too:
> 
> https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc7/librem5___csi_nxp
> 
> Since I want to look into a different camera driver, I might use that
> nxp-drivers tree to work on that, but our goal is obviously to use what
> is already in staging and should work (the csi bridge driver at least).
> In case you know more about the v4l2 details that don't match over
> there, please have a look.

For what it's worth, I'm debugging a complete system memory corruption
with the imx staging camera driver on an i.MX7D, on v5.8-rc6. The issue
didn't occur on v5.7. I however have a fairly large number of custom
patches that I'm in the process of upstreaming on top of mainline for
that driver, so I can't tell yet whether the problem is in my code or in
v5.8-rc6.

I haven't been able to use the staging driver as-is, neither on v5.7 nor
on v5.8-rc6, with the camera sensor I'm working with (a Sony IMX296). I
also get an EPIPE (32) error. Seems there's a reason why this driver is
in staging :-) This however makes debugging more difficult as I can't
test v5.8-rc6 without my custom changes.

As for MEDIA_ENT_F_VID_MUX, the check is about verifying that the device
connected directly to the input of the CSI (*not* MIPI CSI2) is the
video mux that selects between the MIPI CSI2 receiver and the parallel
sensor input. On i.MX7D, this models the "CSI Input MUX Control" bit in
register IOMUXC_GPR_GPR5. On i.MX8M, there seems to be no such mux, as
there seems to be no parallel sensor input. It should thus be safe to
drop the check, but other adjustements to the routing and pipeline
configuration logic in the driver will likely be needed.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH for v5.9] media: omap: Replace HTTP links with HTTPS ones

[Laurent Pinchart]

Hi Alexander,

Thank you for the patch.

On Sun, Jul 19, 2020 at 01:21:33PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

Reviewed-by: Laurent Pinchart 

I expect Sakari to take this patch in his tree when he will be back from
vacation at the end of the month.

> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  drivers/media/platform/omap3isp/isp.c | 2 +-
>  drivers/staging/media/omap4iss/iss.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/omap3isp/isp.c 
> b/drivers/media/platform/omap3isp/isp.c
> index b91e472ee764..74fa67082e09 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -142,7 +142,7 @@ static struct isp_reg isp_reg_list[] = {
>   * readback the same register, in this case the revision register.
>   *
>   * See this link for reference:
> - *   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08149.html
> + *   https://www.mail-archive.com/linux-omap@vger.kernel.org/msg08149.html
>   */
>  void omap3isp_flush(struct isp_device *isp)
>  {
> diff --git a/drivers/staging/media/omap4iss/iss.c 
> b/drivers/staging/media/omap4iss/iss.c
> index 6fb60b58447a..e06ea7ea1e50 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -55,7 +55,7 @@ static void iss_print_status(struct iss_device *iss)
>   * readback the same register, in this case the revision register.
>   *
>   * See this link for reference:
> - *   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08149.html
> + *   https://www.mail-archive.com/linux-omap@vger.kernel.org/msg08149.html
>   */
>  static void omap4iss_flush(struct iss_device *iss)
>  {

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] fixing ERROR: Macros with complex values must be enclosed within parentheses.

[Laurent Pinchart]

Hi Karthik,

Thank you for the patch.

On Thu, Jun 25, 2020 at 10:17:23PM -0400, B K Karthik wrote:
> soc_camera.c:
> 
> fixing ERROR: Macros with complex values must be enclused within parentheses.
> 
> Signed-off-by: B K Karthik 
> ---
>  drivers/staging/media/soc_camera/soc_camera.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/soc_camera/soc_camera.c 
> b/drivers/staging/media/soc_camera/soc_camera.c
> index 39f513f69b89..f609ecf6691c 100644
> --- a/drivers/staging/media/soc_camera/soc_camera.c
> +++ b/drivers/staging/media/soc_camera/soc_camera.c
> @@ -238,8 +238,7 @@ unsigned long soc_camera_apply_board_flags(struct 
> soc_camera_subdev_desc *ssdd,
>  }
>  EXPORT_SYMBOL(soc_camera_apply_board_flags);
>  
> -#define pixfmtstr(x) (x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, \
> - ((x) >> 24) & 0xff
> +#define pixfmtstr(x) ((x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, 
> ((x) >> 24) & 0xff)

This won't work. Try to compile this driver with CONFIG_DYNAMIC_DEBUG
and the compiler will tell you why.

Regardless, drivers/staging/media/soc_camera/soc_camera.c is in staging
because it will be removed from the kernel, cleanups for this file won't
be accepted.

>  static int soc_camera_try_fmt(struct soc_camera_device *icd,
> struct v4l2_format *f)

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v12 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP

[Laurent Pinchart]

Hello Xin,

Thank you for the patch.

On Thu, Jun 04, 2020 at 03:58:05PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
> 
> Signed-off-by: Xin Ji 
> ---
>  drivers/gpu/drm/bridge/analogix/Kconfig   |9 +
>  drivers/gpu/drm/bridge/analogix/Makefile  |1 +
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 1961 
> +
>  drivers/gpu/drm/bridge/analogix/anx7625.h |  397 ++
>  4 files changed, 2368 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d8..024ea2a 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
>  config DRM_ANALOGIX_DP
>   tristate
>   depends on DRM
> +
> +config DRM_ANALOGIX_ANX7625
> + tristate "Analogix Anx7625 MIPI to DP interface support"
> + depends on DRM
> + depends on OF
> + help
> +   ANX7625 is an ultra-low power 4K mobile HD transmitter
> +   designed for portable devices. It converts MIPI/DPI to
> +   DisplayPort1.3 4K.
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b3..44da392 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> new file mode 100644
> index 000..f1cc6bb
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -0,0 +1,1961 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "anx7625.h"
> +
> +/*
> + * There is a sync issue while access I2C register between AP(CPU) and
> + * internal firmware(OCM), to avoid the race condition, AP should access
> + * the reserved slave address before slave address occurs changes.
> + */
> +static int i2c_access_workaround(struct anx7625_data *ctx,
> +  struct i2c_client *client)
> +{
> + u8 offset;
> + struct device *dev = >dev;
> + int ret;
> +
> + if (client == ctx->last_client)
> + return 0;
> +
> + ctx->last_client = client;
> +
> + if (client == ctx->i2c.tcpc_client)
> + offset = RSVD_00_ADDR;
> + else if (client == ctx->i2c.tx_p0_client)
> + offset = RSVD_D1_ADDR;
> + else if (client == ctx->i2c.tx_p1_client)
> + offset = RSVD_60_ADDR;
> + else if (client == ctx->i2c.rx_p0_client)
> + offset = RSVD_39_ADDR;
> + else if (client == ctx->i2c.rx_p1_client)
> + offset = RSVD_7F_ADDR;
> + else
> + offset = RSVD_00_ADDR;
> +
> + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev,
> +   "fail to access i2c id=%x\n:%x",
> +   client->addr, offset);
> +
> + return ret;
> +}
> +
> +static int anx7625_reg_read(struct anx7625_data *ctx,
> + struct i2c_client *client, u8 reg_addr)
> +{
> + int ret;
> + struct device *dev = >dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_read_byte_data(client, reg_addr);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
> +   client->addr, reg_addr);
> +
> + return ret;
> +}
> +
> +static int anx7625_reg_block_read(struct anx7625_data *ctx,
> +   struct i2c_client *client,
> +   u8 reg_addr, u8 len, u8 *buf)
> +{
> + int ret;
> + struct device *dev = >dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_read_i2c_block_data(client, reg_addr, len, buf);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "read i2c block fail id=%x:%x\n",
> +   client->addr, reg_addr);
> +
> + return ret;
> +}
> +
> 

Re: [PATCH] media: staging: ipu3: Fix stale list entries on parameter queue failure

[Laurent Pinchart]

1 c5 70 0a 00 00 49 39
> c5 74 3b 49 bc 00 01 00 00 00 00 ad de 49 8d 5c 24 22 4c 8b 30 48 8b 48
> 08 <49> 89 4e 08 4c 89 31 4c 89 20 48 89 58 08 48 8d b8 58 fc ff ff 44
> [  225.360509] RSP: 0018:9468ab32fbe8 EFLAGS: 00010293
> [  225.360511] RAX: 8aa7a51577a8 RBX: dead0122 RCX:
> dead0122
> [  225.360512] RDX:  RSI: 0006 RDI:
> 8aa7a5157400
> [  225.360514] RBP: 9468ab32fc18 R08: 8aa64e47e600 R09:
> 
> [  225.360515] R10:  R11: c06036e6 R12:
> dead0100
> [  225.360517] R13: 8aa7820f1940 R14: dead0100 R15:
> 0006
> [  225.360519] FS:  7c1146ffd700() GS:8aa7baa0()
> knlGS:
> [  225.360521] CS:  0010 DS:  ES:  CR0: 80050033
> [  225.360523] CR2: 7aea3473a000 CR3: 537d6004 CR4:
> 003606f0
> [  225.360525] Call Trace:
> [  225.360528]  imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu]
> [  225.360531]  __vb2_queue_cancel+0x33/0x22d [videobuf2_common]
> [  225.360534]  vb2_core_streamoff+0x16/0x78 [videobuf2_common]
> [  225.360537]  __video_do_ioctl+0x33d/0x42a
> [  225.360540]  video_usercopy+0x34a/0x615
> [  225.360542]  ? video_ioctl2+0x16/0x16
> [  225.360546]  v4l2_ioctl+0x46/0x53
> [  225.360548]  do_vfs_ioctl+0x50a/0x787
> [  225.360551]  ksys_ioctl+0x58/0x83
> [  225.360554]  __x64_sys_ioctl+0x1a/0x1e
> [  225.360556]  do_syscall_64+0x54/0x68
> [  225.360559]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  225.360561] RIP: 0033:0x7c118030f497
> [  225.360563] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00
> 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48
> [  225.360565] RSP: 002b:7c1146ffa5a8 EFLAGS: 0246 ORIG_RAX:
> 0010
> [  225.360567] RAX: ffda RBX: 7c1140010018 RCX:
> 7c118030f497
> [  225.360569] RDX: 7c114001019c RSI: 40045613 RDI:
> 004c
> [  225.360570] RBP: 7c1146ffa700 R08: 7c1140010048 R09:
> 
> [  225.360572] R10:  R11: 0246 R12:
> 7c11400101b0
> [  225.360574] R13: 7c1140010200 R14: 7c1140010048 R15:
> 0001
> [  225.360576] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
> veth bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
> nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header cmac rfcomm uinput
> ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common
> videobuf2_dma_sg videobuf2_memops ov13858 ov567
> 
> Fix this by moving the list_del() call just below the list_first_entry()
> call when the buffer no longer needs to be in the list.
> 
> Fixes: 8ecc7c9da013 ("media: staging/intel-ipu3: parameter buffer 
> refactoring")
> Signed-off-by: Tomasz Figa 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/staging/media/ipu3/ipu3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/ipu3/ipu3.c 
> b/drivers/staging/media/ipu3/ipu3.c
> index 4d53aad31483..7a1d1881483b 100644
> --- a/drivers/staging/media/ipu3/ipu3.c
> +++ b/drivers/staging/media/ipu3/ipu3.c
> @@ -261,6 +261,7 @@ int imgu_queue_buffers(struct imgu_device *imgu, bool 
> initial, unsigned int pipe
>  
>   ivb = list_first_entry(_pipe->nodes[node].buffers,
>  struct imgu_vb2_buffer, list);
> + list_del(>list);
>   vb = >vbb.vb2_buf;
>   r = imgu_css_set_parameters(>css, pipe,
>   vb2_plane_vaddr(vb, 0));
> @@ -274,7 +275,6 @@ int imgu_queue_buffers(struct imgu_device *imgu, bool 
> initial, unsigned int pipe
>   vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
>   dev_dbg(>pci_dev->dev,
>   "queue user parameters %d to css.", vb->index);
> - list_del(>list);
>   } else if (imgu_pipe->queue_enabled[node]) {
>   struct imgu_css_buffer *buf =
>   imgu_queue_getbuf(imgu, node, pipe);

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging: rkisp1: avoid unused variable warning

[Laurent Pinchart]

Hi Arnd,

Thank you for the patch.

On Wed, Apr 08, 2020 at 05:52:44PM +0200, Arnd Bergmann wrote:
> When compile-testing with CONFIG_OF disabled, we get a warning
> about an unused variable, and about inconsistent Kconfig dependencies:
> 
> WARNING: unmet direct dependencies detected for PHY_ROCKCHIP_DPHY_RX0
>   Depends on [n]: STAGING [=y] && STAGING_MEDIA [=y] && MEDIA_SUPPORT [=m] && 
> (ARCH_ROCKCHIP [=n] || COMPILE_TEST [=y]) && OF [=n]
>   Selected by [m]:
>   - VIDEO_ROCKCHIP_ISP1 [=m] && STAGING [=y] && STAGING_MEDIA [=y] && 
> MEDIA_SUPPORT [=m] && VIDEO_V4L2 [=m] && VIDEO_V4L2_SUBDEV_API [=y] && 
> (ARCH_ROCKCHIP [=n] || COMPILE_TEST [=y])
> 
> drivers/staging/media/rkisp1/rkisp1-dev.c: In function 'rkisp1_probe':
> drivers/staging/media/rkisp1/rkisp1-dev.c:457:22: error: unused variable 
> 'node' [-Werror=unused-variable]
>   457 |  struct device_node *node = pdev->dev.of_node;
> 
> Simply open-coding the pointer dereference in the only place
> the variable is used avoids the warning in all configurations,
> so we can allow compile-testing as well.
> 
> Fixes: d65dd85281fb ("media: staging: rkisp1: add Rockchip ISP1 base driver")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/staging/media/phy-rockchip-dphy-rx0/Kconfig | 2 +-
>  drivers/staging/media/rkisp1/rkisp1-dev.c   | 3 +--
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/media/phy-rockchip-dphy-rx0/Kconfig 
> b/drivers/staging/media/phy-rockchip-dphy-rx0/Kconfig
> index bd0147624de1..dd5d4d741bdd 100644
> --- a/drivers/staging/media/phy-rockchip-dphy-rx0/Kconfig
> +++ b/drivers/staging/media/phy-rockchip-dphy-rx0/Kconfig
> @@ -2,7 +2,7 @@
>  
>  config PHY_ROCKCHIP_DPHY_RX0
>   tristate "Rockchip MIPI Synopsys DPHY RX0 driver"
> - depends on (ARCH_ROCKCHIP || COMPILE_TEST) && OF
> + depends on (ARCH_ROCKCHIP && OF) || COMPILE_TEST
>   select GENERIC_PHY_MIPI_DPHY
>   select GENERIC_PHY
>   help
> diff --git a/drivers/staging/media/rkisp1/rkisp1-dev.c 
> b/drivers/staging/media/rkisp1/rkisp1-dev.c
> index b1b3c058e957..5e7e797aad71 100644
> --- a/drivers/staging/media/rkisp1/rkisp1-dev.c
> +++ b/drivers/staging/media/rkisp1/rkisp1-dev.c
> @@ -454,7 +454,6 @@ static void rkisp1_debug_init(struct rkisp1_device 
> *rkisp1)
>  
>  static int rkisp1_probe(struct platform_device *pdev)
>  {
> - struct device_node *node = pdev->dev.of_node;
>   const struct rkisp1_match_data *clk_data;
>   const struct of_device_id *match;
>   struct device *dev = >dev;
> @@ -463,7 +462,7 @@ static int rkisp1_probe(struct platform_device *pdev)
>   unsigned int i;
>   int ret, irq;
>  
> - match = of_match_node(rkisp1_of_match, node);
> + match = of_match_node(rkisp1_of_match, pdev->dev.of_node);
>   rkisp1 = devm_kzalloc(dev, sizeof(*rkisp1), GFP_KERNEL);
>   if (!rkisp1)
>   return -ENOMEM;

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files

[Laurent Pinchart]

Hi Greg,

On Tue, Mar 31, 2020 at 02:47:56PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Mar 31, 2020 at 03:39:14PM +0300, Laurent Pinchart wrote:
> > On Tue, Mar 31, 2020 at 02:22:09PM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Mar 31, 2020 at 03:06:08PM +0300, Laurent Pinchart wrote:
> > > > On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote:
> > > > > Most of media Kconfig/Makefile files already has SPDX,
> > > > > but there are a few ones still missing. Add it to them.
> > > > 
> > > > I think it's a good idea to state the license of each source file, the
> > > > patch looks fine to me. I've however been thinking about licenses for
> > > > build system files recently, and I'll hijack this thread a bit to ask a
> > > > question :-)
> > > > 
> > > > For a project like the Linux kernel, and especially for subsystems that
> > > > are covered by a single license, the choice is easy, we can apply the
> > > > same license to the build files. However, for a project that contains
> > > > components covered by different licenses (such as, for instance, an LGPL
> > > > library, a GPL application and a BSD plugin), how should the license
> > > > covering the build system files be selected ? I searched a bit for
> > > > guidance on this topic, and couldn't find much.
> > > 
> > > By "default" if there is no license on a file in the kernel tree, it
> > > falls under the GPLv2 license and we should explicity state it, like
> > > this patch does.
> > > 
> > > So this is fine, but if you want to license the build files some other
> > > way, that's good too, but do so when you add them to the tree, not at
> > > some later time when it could cause confusion :)
> > 
> > Thanks for your answer. I was hijacking the thread a little bit, the
> > question wasn't related to the kernel, but in this case to libcamera.
> > We've been wondering how to pick licenses for build files there, and I
> > thought fellow kernel developers may have valuable input on this topic.
> 
> I would make the files the same license as your project overall is to
> make things simpler for everyone involved :)

I would if the project had a single license, but we have GPL, LGPL and
BSD components :-S

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files

[Laurent Pinchart]

Hi Greg,

On Tue, Mar 31, 2020 at 02:22:09PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Mar 31, 2020 at 03:06:08PM +0300, Laurent Pinchart wrote:
> > On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote:
> > > Most of media Kconfig/Makefile files already has SPDX,
> > > but there are a few ones still missing. Add it to them.
> > 
> > I think it's a good idea to state the license of each source file, the
> > patch looks fine to me. I've however been thinking about licenses for
> > build system files recently, and I'll hijack this thread a bit to ask a
> > question :-)
> > 
> > For a project like the Linux kernel, and especially for subsystems that
> > are covered by a single license, the choice is easy, we can apply the
> > same license to the build files. However, for a project that contains
> > components covered by different licenses (such as, for instance, an LGPL
> > library, a GPL application and a BSD plugin), how should the license
> > covering the build system files be selected ? I searched a bit for
> > guidance on this topic, and couldn't find much.
> 
> By "default" if there is no license on a file in the kernel tree, it
> falls under the GPLv2 license and we should explicity state it, like
> this patch does.
> 
> So this is fine, but if you want to license the build files some other
> way, that's good too, but do so when you add them to the tree, not at
> some later time when it could cause confusion :)

Thanks for your answer. I was hijacking the thread a little bit, the
question wasn't related to the kernel, but in this case to libcamera.
We've been wondering how to pick licenses for build files there, and I
thought fellow kernel developers may have valuable input on this topic.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote:
> Most of media Kconfig/Makefile files already has SPDX,
> but there are a few ones still missing. Add it to them.

I think it's a good idea to state the license of each source file, the
patch looks fine to me. I've however been thinking about licenses for
build system files recently, and I'll hijack this thread a bit to ask a
question :-)

For a project like the Linux kernel, and especially for subsystems that
are covered by a single license, the choice is easy, we can apply the
same license to the build files. However, for a project that contains
components covered by different licenses (such as, for instance, an LGPL
library, a GPL application and a BSD plugin), how should the license
covering the build system files be selected ? I searched a bit for
guidance on this topic, and couldn't find much.

> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb-frontends/Kconfig | 2 ++
>  drivers/media/mc/Kconfig| 2 ++
>  drivers/media/platform/sunxi/Kconfig| 2 ++
>  drivers/media/platform/sunxi/Makefile   | 2 ++
>  drivers/media/platform/sunxi/sun4i-csi/Kconfig  | 2 ++
>  drivers/media/platform/sunxi/sun4i-csi/Makefile | 2 ++
>  drivers/staging/media/hantro/Makefile   | 2 ++
>  drivers/staging/media/rkisp1/Makefile   | 2 ++
>  8 files changed, 16 insertions(+)
> 
> diff --git a/drivers/media/dvb-frontends/Kconfig 
> b/drivers/media/dvb-frontends/Kconfig
> index 1f45808d94da..aa24506257b3 100644
> --- a/drivers/media/dvb-frontends/Kconfig
> +++ b/drivers/media/dvb-frontends/Kconfig
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  if MEDIA_DIGITAL_TV_SUPPORT
>  
>  comment "DVB Frontend drivers hidden by 'Autoselect ancillary drivers'"
> diff --git a/drivers/media/mc/Kconfig b/drivers/media/mc/Kconfig
> index 3b9795cfcb36..0c5c52f14c64 100644
> --- a/drivers/media/mc/Kconfig
> +++ b/drivers/media/mc/Kconfig
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  #
>  # Media controller
>  #Selectable only for webcam/grabbers, as other drivers don't use it
> diff --git a/drivers/media/platform/sunxi/Kconfig 
> b/drivers/media/platform/sunxi/Kconfig
> index 71808e93ac2e..7151cc249afa 100644
> --- a/drivers/media/platform/sunxi/Kconfig
> +++ b/drivers/media/platform/sunxi/Kconfig
> @@ -1,2 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
>  source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> diff --git a/drivers/media/platform/sunxi/Makefile 
> b/drivers/media/platform/sunxi/Makefile
> index ff0993f70dc3..fc537c9f5ca9 100644
> --- a/drivers/media/platform/sunxi/Makefile
> +++ b/drivers/media/platform/sunxi/Makefile
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  obj-y+= sun4i-csi/
>  obj-y+= sun6i-csi/
>  obj-y+= sun8i-di/
> diff --git a/drivers/media/platform/sunxi/sun4i-csi/Kconfig 
> b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
> index e86e29b6a603..93b4e82a2655 100644
> --- a/drivers/media/platform/sunxi/sun4i-csi/Kconfig
> +++ b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  config VIDEO_SUN4I_CSI
>   tristate "Allwinner A10 CMOS Sensor Interface Support"
>   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> diff --git a/drivers/media/platform/sunxi/sun4i-csi/Makefile 
> b/drivers/media/platform/sunxi/sun4i-csi/Makefile
> index 7c790a57f5ee..5062b006d63e 100644
> --- a/drivers/media/platform/sunxi/sun4i-csi/Makefile
> +++ b/drivers/media/platform/sunxi/sun4i-csi/Makefile
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  sun4i-csi-y += sun4i_csi.o
>  sun4i-csi-y += sun4i_dma.o
>  sun4i-csi-y += sun4i_v4l2.o
> diff --git a/drivers/staging/media/hantro/Makefile 
> b/drivers/staging/media/hantro/Makefile
> index 68c29a9c4946..743ce08eb184 100644
> --- a/drivers/staging/media/hantro/Makefile
> +++ b/drivers/staging/media/hantro/Makefile
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  obj-$(CONFIG_VIDEO_HANTRO) += hantro-vpu.o
>  
>  hantro-vpu-y += \
> diff --git a/drivers/staging/media/rkisp1/Makefile 
> b/drivers/staging/media/rkisp1/Makefile
> index 69ca59c7ef34..ab32a77db8f7 100644
> --- a/drivers/staging/media/rkisp1/Makefile
> +++ b/drivers/staging/media/rkisp1/Makefile
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  obj-$(CONFIG_VIDEO_ROCKCHIP_ISP1) += rockchip-isp1.o
>  rockchip-isp1-objs +=rkisp1-capture.o \
>   rkisp1-common.o \

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/4] media Kconfig reorg - part 2

[Laurent Pinchart]

Hi Mauro,

On Thu, Mar 26, 2020 at 09:28:32AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Mar 2020 00:13:43 +0200 Laurent Pinchart escreveu:
> > On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:  
> > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:  
> > > > > That's the second part of media Kconfig changes. The entire series is
> > > > > at:
> > > > > 
> > > > >   
> > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig 
> > > > >
> > > > 
> > > > I made a quick experiment (using this branch) with someone who works 
> > > > with the kernel for his master degree, but doesn't have much experience 
> > > > in kernel development in general.
> > > > I asked him to enable Vimc (from default configs, where multimedia 
> > > > starts disabled).
> > > > He knows that Vimc is a virtual camera driver, and this is how he 
> > > > behaved:
> > > > 
> > > > === Start of experiment:
> > > > 
> > > > * He pressed '/' and searched for vimc to see the location path.
> > > > * Then he enabled "Multimedia support" and went straight to "Media 
> > > > drivers" (which just shows USB and PCI).
> > > > * He went back to "Multimedia support", entered "Media device types" 
> > > > and enabled "Test drivers".
> > > > * He went back to "Media drivers" again and didn't find Vimc (nothing 
> > > > changed in this menu).
> > > > * He seemed a bit lost, going back and forth in the menus a couple of 
> > > > times.
> > > > * Then he pressed '/' again to search for vimc and see the location 
> > > > path, and he realized that there
> > > > should be an option called "V4L test drivers" under "Media drivers" 
> > > > that is not showing up.
> > > > * He went back to "Media device types" again and start re-reading the 
> > > > options.
> > > > * He selected "Cameras and video grabbers" ant went back to "Media 
> > > > drivers".
> > > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > > * He selects "Virtual Media Controller Driver".
> > > > 
> > > > I asked his impressions, and he mentioned that he thought that enabling 
> > > > just "Test drivers" would be enough, without need
> > > > to combine "Test drivers" with "Cameras and video grabbers".
> > > > He also asked me why virtual drivers should be hidden, and he mentioned 
> > > > that the word "Virtual" in front would be enough.
> > > > 
> > > > Then I showed him he could have disabled the option "Filter devices by 
> > > > their types" to see everything at one (which he didn't
> > > > realized by himself until that moment, nor tried it out to see what 
> > > > would happen).
> > > > 
> > > > He mentioned that hiding is nice, because it shows less options, but 
> > > > not very nice to search for something.
> > > > He also mentioned that if he had understood the filter mechanism from 
> > > > the start, he would have disabled "Filter devices by their types" 
> > > > sooner.  
> > > 
> > > That's easy to solve: all it needs is to add something similar
> > > to this at drivers/media/Kconfig:
> > > 
> > >   +   comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > >   +   visible if MEDIA_SUPPORT_FILTER
> > >   +
> > >   +   comment "All available drivers are shown below"
> > >   +   visible if !MEDIA_SUPPORT_FILTER
> > >   +
> > >   menu "Media drivers"
> > > 
> > >   source "drivers/media/usb/Kconfig"
> > >   
> > > > === End of experiment
> > > > 
> > > > This was just one experiment from one person, I'll see if I can get 
> > > > some other people from lkcamp.dev group to also check
> > > > and send us their impressions. I think it would be nice to get more 
> > > > data about user experience, from people that are not used to
> > > > kernel development (kernel dev newbies for instance).
> > 

Re: [PATCH 0/4] media Kconfig reorg - part 2

[Laurent Pinchart]

e bigger (and it's not counting staging, headers or
documentation).

> So, about 99,9998% of the users using the media subsystems aren't
> Kernel hackers. I bet that almost all of those will either need
> to enable USB or a PCI driver.

And the extremely vast majority of these will never enable a kernel
option because they will never compile a kernel. They don't even know
what a kernel is :-)

> Granted, 99,9998% seems too optimistic, but, assuming that this
> would reduce to something like 80% (e. g. only 200 users
> would ever try to build a media driver, with is a *very conservative*
> number) this is still a lot more than the number of media Kernel
> developers.
> 
> Also, a Kernel hacker will sooner or later find a way to enable it.
> A normal user may find it a lot more trickier and will very likely
> require more support, if the menus are too technical and the
> default options are wrong.

I'm not sure to follow you. Are you implying that this patch series,
which Helen has tested against a real user, not an experienced kernel
hacker, may make the configuration options more difficult for kernel
hackers, but improves the situation for users ?

> 
> -
> 
> Even with that, based on your small experiment (of someone from the
> area), I suspect that, if you had asked him to enable, for example,
> em28xx or dvbsky (with are some of the most popular drivers
> those days), he would be able to enable it a lot faster.

This is the *only* real piece of evidence we have, let's not assume we
know better.

> > and selecting those doesn't do anything, and people can even think
> > that, if they want to enable an USB device, just enabling the USB option 
> > there is enough (which is not), since no drivers
> > shows up.
> 
> It is hard to comment on individual experiments. In the past, our
> Kconfig system were like that: written for technical people with
> background on computer engineering and some experience building the
> Kernel.
> 
> E.g. people that knows that "/" activates a search mechanism at
> the Kernel building system.
> 
> We usually had to spend *a lot of time* both on IRC and on e-mail
> explaining people that just want to have their card supported,
> how to do that. After the reorg (with added those more user-faced
> interfaces), the number of people with problems reduced a lot.

Don't you think that could come mainly from better support for media
devices in distributions ?

> Btw, if one tries to compile from media-build (with lots of users
> do), this is even more relevant.

Can you quantify "lots of users" ?

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 07/10] dt-bindings: adv748x: add information about serial audio interface (I2S/TDM)

[Laurent Pinchart]

Hi Alex,

On Fri, Mar 20, 2020 at 10:03:39AM +0100, Alex Riesen wrote:
> Geert Uytterhoeven, Fri, Mar 20, 2020 09:48:14 +0100:
> > On Fri, Mar 20, 2020 at 9:44 AM Alex Riesen  
> > wrote:
> > > Laurent Pinchart, Thu, Mar 19, 2020 19:01:25 +0100:
> > > > On Thu, Mar 19, 2020 at 06:42:36PM +0100, Alex Riesen wrote:
> > > > > As the driver has some support for the audio interface of the device,
> > > > > the bindings file should mention it.
> > > > >
> > > > > @@ -16,6 +18,8 @@ Required Properties:
> > > > >  slave device on the I2C bus. The main address is mandatory, 
> > > > > others are
> > > > >  optional and remain at default values if not specified.
> > > > >
> > > > > +  - #clock-cells: must be <0> if the I2S port is used
> > > >
> > > > Wouldn't it be simpler to set it to 0 unconditionally ?
> > >
> > > Would it? If the port itself is optional, shouldn't the clock be an option
> > > too?
> > 
> > You'd be surprised how many board designers would consider this a cheap
> > 12.288 MHz clock source, without using the I2S port ;-)
> 
> Well, I am :-)
> 
> Especially considering that the driver will not switch the MCLK pin aktive
> (all I2S-related pins are tristate by default).

If the MCLK can't be output without enabling the I2S then I don't mind
if we make the #clock-cells optional, although, as Geert mentioned,
someone may still want to use it.

> And how do I require it to be set unconditionally? By just removing the
> "if ..." part of the statement?

Yes. For YAML it's easy too, the hard part is making properties
conditional :-)

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 03/10] media: adv748x: reduce amount of code for bitwise modifications of device registers

[Laurent Pinchart]

Hi Alex,

Thank you for the patch.

On Thu, Mar 19, 2020 at 06:41:53PM +0100, Alex Riesen wrote:
> The regmap provides a convenient utility for this.
> 
> Signed-off-by: Alexander Riesen 
> ---
>  drivers/media/i2c/adv748x/adv748x-core.c |  6 ++
>  drivers/media/i2c/adv748x/adv748x.h  | 15 ---
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 345f009de121..36164a254d7b 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -133,6 +133,12 @@ static int adv748x_write_check(struct adv748x_state 
> *state, u8 page, u8 reg,
>   return *error;
>  }
>  
> +int adv748x_update_bits(struct adv748x_state *state, u8 page, u8 reg, u8 
> mask,
> + u8 value)
> +{
> + return regmap_update_bits(state->regmap[page], reg, mask, value);
> +}
> +
>  /* adv748x_write_block(): Write raw data with a maximum of 
> I2C_SMBUS_BLOCK_MAX
>   * size to one or more registers.
>   *
> diff --git a/drivers/media/i2c/adv748x/adv748x.h 
> b/drivers/media/i2c/adv748x/adv748x.h
> index 09aab4138c3f..c5245464fffc 100644
> --- a/drivers/media/i2c/adv748x/adv748x.h
> +++ b/drivers/media/i2c/adv748x/adv748x.h
> @@ -393,25 +393,34 @@ int adv748x_write(struct adv748x_state *state, u8 page, 
> u8 reg, u8 value);
>  int adv748x_write_block(struct adv748x_state *state, int client_page,
>   unsigned int init_reg, const void *val,
>   size_t val_len);
> +int adv748x_update_bits(struct adv748x_state *state, u8 page, u8 reg,
> + u8 mask, u8 value);
>  
>  #define io_read(s, r) adv748x_read(s, ADV748X_PAGE_IO, r)
>  #define io_write(s, r, v) adv748x_write(s, ADV748X_PAGE_IO, r, v)
> -#define io_clrset(s, r, m, v) io_write(s, r, (io_read(s, r) & ~(m)) | (v))
> +#define io_clrset(s, r, m, v) adv748x_update_bits(s, ADV748X_PAGE_IO, r, m, 
> v)
> +#define io_update(s, r, m, v) adv748x_update_bits(s, ADV748X_PAGE_IO, r, m, 
> v)

Those two are identical. Do we need both ? I would standardize on either
*_update or *_clrset for all the functions here. Apart from that,

Reviewed-by: Laurent Pinchart 

>  
>  #define hdmi_read(s, r) adv748x_read(s, ADV748X_PAGE_HDMI, r)
>  #define hdmi_read16(s, r, m) (((hdmi_read(s, r) << 8) | hdmi_read(s, (r)+1)) 
> & (m))
>  #define hdmi_write(s, r, v) adv748x_write(s, ADV748X_PAGE_HDMI, r, v)
> +#define hdmi_update(s, r, m, v) \
> + adv748x_update_bits(s, ADV748X_PAGE_HDMI, r, m, v)
> +
> +#define dpll_read(s, r) adv748x_read(s, ADV748X_PAGE_DPLL, r)
> +#define dpll_update(s, r, m, v) \
> + adv748x_update_bits(s, ADV748X_PAGE_DPLL, r, m, v)
>  
>  #define repeater_read(s, r) adv748x_read(s, ADV748X_PAGE_REPEATER, r)
>  #define repeater_write(s, r, v) adv748x_write(s, ADV748X_PAGE_REPEATER, r, v)
>  
>  #define sdp_read(s, r) adv748x_read(s, ADV748X_PAGE_SDP, r)
>  #define sdp_write(s, r, v) adv748x_write(s, ADV748X_PAGE_SDP, r, v)
> -#define sdp_clrset(s, r, m, v) sdp_write(s, r, (sdp_read(s, r) & ~(m)) | (v))
> +#define sdp_clrset(s, r, m, v) adv748x_update_bits(s, ADV748X_PAGE_SDP, r, 
> m, v)
>  
>  #define cp_read(s, r) adv748x_read(s, ADV748X_PAGE_CP, r)
>  #define cp_write(s, r, v) adv748x_write(s, ADV748X_PAGE_CP, r, v)
> -#define cp_clrset(s, r, m, v) cp_write(s, r, (cp_read(s, r) & ~(m)) | (v))
> +#define cp_clrset(s, r, m, v) adv748x_update_bits(s, ADV748X_PAGE_CP, r, m, 
> v)
>  
>  #define tx_read(t, r) adv748x_read(t->state, t->page, r)
>  #define tx_write(t, r, v) adv748x_write(t->state, t->page, r, v)

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 01/10] media: adv748x: fix end-of-line terminators in diagnostic statements

[Laurent Pinchart]

Hi Alex,

Thank you for the patch.

On Thu, Mar 19, 2020 at 06:41:43PM +0100, Alex Riesen wrote:
> Signed-off-by: Alexander Riesen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/i2c/adv748x/adv748x-core.c | 24 
>  drivers/media/i2c/adv748x/adv748x-csi2.c |  2 +-
>  2 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 23e02ff27b17..c3fb113cef62 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -623,11 +623,11 @@ static int adv748x_parse_dt(struct adv748x_state *state)
>  
>   for_each_endpoint_of_node(state->dev->of_node, ep_np) {
>   of_graph_parse_endpoint(ep_np, );
> - adv_info(state, "Endpoint %pOF on port %d", ep.local_node,
> + adv_info(state, "Endpoint %pOF on port %d\n", ep.local_node,
>ep.port);
>  
>   if (ep.port >= ADV748X_PORT_MAX) {
> - adv_err(state, "Invalid endpoint %pOF on port %d",
> + adv_err(state, "Invalid endpoint %pOF on port %d\n",
>   ep.local_node, ep.port);
>  
>   continue;
> @@ -635,7 +635,7 @@ static int adv748x_parse_dt(struct adv748x_state *state)
>  
>   if (state->endpoints[ep.port]) {
>   adv_err(state,
> - "Multiple port endpoints are not supported");
> + "Multiple port endpoints are not supported\n");
>   continue;
>   }
>  
> @@ -702,62 +702,62 @@ static int adv748x_probe(struct i2c_client *client)
>   /* Discover and process ports declared by the Device tree endpoints */
>   ret = adv748x_parse_dt(state);
>   if (ret) {
> - adv_err(state, "Failed to parse device tree");
> + adv_err(state, "Failed to parse device tree\n");
>   goto err_free_mutex;
>   }
>  
>   /* Configure IO Regmap region */
>   ret = adv748x_configure_regmap(state, ADV748X_PAGE_IO);
>   if (ret) {
> - adv_err(state, "Error configuring IO regmap region");
> + adv_err(state, "Error configuring IO regmap region\n");
>   goto err_cleanup_dt;
>   }
>  
>   ret = adv748x_identify_chip(state);
>   if (ret) {
> - adv_err(state, "Failed to identify chip");
> + adv_err(state, "Failed to identify chip\n");
>   goto err_cleanup_dt;
>   }
>  
>   /* Configure remaining pages as I2C clients with regmap access */
>   ret = adv748x_initialise_clients(state);
>   if (ret) {
> - adv_err(state, "Failed to setup client regmap pages");
> + adv_err(state, "Failed to setup client regmap pages\n");
>   goto err_cleanup_clients;
>   }
>  
>   /* SW reset ADV748X to its default values */
>   ret = adv748x_reset(state);
>   if (ret) {
> - adv_err(state, "Failed to reset hardware");
> + adv_err(state, "Failed to reset hardware\n");
>   goto err_cleanup_clients;
>   }
>  
>   /* Initialise HDMI */
>   ret = adv748x_hdmi_init(>hdmi);
>   if (ret) {
> - adv_err(state, "Failed to probe HDMI");
> + adv_err(state, "Failed to probe HDMI\n");
>   goto err_cleanup_clients;
>   }
>  
>   /* Initialise AFE */
>   ret = adv748x_afe_init(>afe);
>   if (ret) {
> - adv_err(state, "Failed to probe AFE");
> + adv_err(state, "Failed to probe AFE\n");
>   goto err_cleanup_hdmi;
>   }
>  
>   /* Initialise TXA */
>   ret = adv748x_csi2_init(state, >txa);
>   if (ret) {
> - adv_err(state, "Failed to probe TXA");
> + adv_err(state, "Failed to probe TXA\n");
>   goto err_cleanup_afe;
>   }
>  
>   /* Initialise TXB */
>   ret = adv748x_csi2_init(state, >txb);
>   if (ret) {
> - adv_err(state, "Failed to probe TXB");
> + adv_err(state, "Failed to probe TXB\n");
>   goto err_cleanup_txa;
>   }
>  
> diff --git a/drivers/media/i2c/adv748x/adv748x-csi2.c 
> b/drivers/media/i2c/adv748x/adv748x-csi2.c
> index 2091cda50935..c4

Re: [PATCH v2 07/10] dt-bindings: adv748x: add information about serial audio interface (I2S/TDM)

[Laurent Pinchart]

Hi Alex,

Thank you for the patch.

On Thu, Mar 19, 2020 at 06:42:36PM +0100, Alex Riesen wrote:
> As the driver has some support for the audio interface of the device,
> the bindings file should mention it.

While at it, how about converting the bindings to YAML ? :-) It can of
course be done on top.

> Reviewed-by: Rob Herring 
> Signed-off-by: Alexander Riesen 
> ---
>  .../devicetree/bindings/media/i2c/adv748x.txt| 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt 
> b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
> index 4f91686e54a6..7d6db052c294 100644
> --- a/Documentation/devicetree/bindings/media/i2c/adv748x.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
> @@ -2,7 +2,9 @@
>  
>  The ADV7481 and ADV7482 are multi format video decoders with an integrated
>  HDMI receiver. They can output CSI-2 on two independent outputs TXA and TXB
> -from three input sources HDMI, analog and TTL.
> +from three input sources HDMI, analog and TTL. There is also support for an
> +I2S compatible interface connected to the audio processor of the HDMI 
> decoder.

s/I2S compatible/I2S-compatible/ ?

> +The interface has TDM capability (8 slots, 32 bits, left or right justified).
>  
>  Required Properties:
>  
> @@ -16,6 +18,8 @@ Required Properties:
>  slave device on the I2C bus. The main address is mandatory, others are
>  optional and remain at default values if not specified.
>  
> +  - #clock-cells: must be <0> if the I2S port is used

Wouldn't it be simpler to set it to 0 unconditionally ?

Reviewed-by: Laurent Pinchart 

> +
>  Optional Properties:
>  
>- interrupt-names: Should specify the interrupts as "intrq1", "intrq2" 
> and/or
> @@ -47,6 +51,7 @@ are numbered as follows.
> TTL   sink9
> TXA   source  10
> TXB   source  11
> +   I2S   source  12
>  
>  The digital output port nodes, when present, shall contain at least one
>  endpoint. Each of those endpoints shall contain the data-lanes property as
> @@ -72,6 +77,7 @@ Example:
>  
>   #address-cells = <1>;
>   #size-cells = <0>;
> + #clock-cells = <0>;
>  
>   interrupt-parent = <>;
>   interrupt-names = "intrq1", "intrq2";
> @@ -113,4 +119,12 @@ Example:
>   remote-endpoint = <_in>;
>   };
>   };
> +
> + port@c {
> + reg = <12>;
> +
> + adv7482_i2s: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
>   };

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 02/10] media: adv748x: include everything adv748x.h needs into the file

[Laurent Pinchart]

Hi Alexander,

Thank you for the patch.

On Thu, Mar 19, 2020 at 06:41:48PM +0100, Alex Riesen wrote:
> To follow the established practice of not depending on others to
> pull everything in.
> 
> Signed-off-by: Alexander Riesen 

Good idea. While at it, could you include "adv748x.h" as the very first
header in at least one of the C files ? That will help ensuring the
header stays self-contained in the future.

> ---
>  drivers/media/i2c/adv748x/adv748x-afe.c  | 2 --
>  drivers/media/i2c/adv748x/adv748x-core.c | 2 --
>  drivers/media/i2c/adv748x/adv748x-csi2.c | 2 --
>  drivers/media/i2c/adv748x/adv748x-hdmi.c | 2 --
>  drivers/media/i2c/adv748x/adv748x.h  | 2 ++
>  5 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> b/drivers/media/i2c/adv748x/adv748x-afe.c
> index dbbb1e4d6363..ab0479641c10 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -11,8 +11,6 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index c3fb113cef62..345f009de121 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -20,8 +20,6 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/media/i2c/adv748x/adv748x-csi2.c 
> b/drivers/media/i2c/adv748x/adv748x-csi2.c
> index c43ce5d78723..78d391009b5a 100644
> --- a/drivers/media/i2c/adv748x/adv748x-csi2.c
> +++ b/drivers/media/i2c/adv748x/adv748x-csi2.c
> @@ -8,8 +8,6 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
>  #include 
>  
>  #include "adv748x.h"
> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> index c557f8fdf11a..0dffcdf79ff2 100644
> --- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> @@ -8,8 +8,6 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/media/i2c/adv748x/adv748x.h 
> b/drivers/media/i2c/adv748x/adv748x.h
> index fccb388ce179..09aab4138c3f 100644
> --- a/drivers/media/i2c/adv748x/adv748x.h
> +++ b/drivers/media/i2c/adv748x/adv748x.h
> @@ -19,6 +19,8 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  
>  #ifndef _ADV748X_H_
>  #define _ADV748X_H_

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 8/8] arm64: dts: renesas: salvator: add a connection from adv748x codec (HDMI input) to the R-Car SoC

[Laurent Pinchart]

Hi Alex,

On Tue, Mar 10, 2020 at 09:17:14AM +0100, Alex Riesen wrote:
> Kuninori Morimoto, Tue, Mar 10, 2020 02:07:23 +0100:
> > > Should the adv748x driver also implement anything to configure the 
> > > frequency
> > > of MCLK clock? I mean something like .set_sysclk and .set_fmt callbacks of
> > > snd_soc_dai_ops?
> > > 
> > > Or is the driver implementation, which depends on mclk-fs to be 256, the 
> > > audio
> > > stream format to be 8x S24_LE, and requires strictly 48kHz sampling rate 
> > > on
> > > the HDMI input, a totally acceptable first attempt at writing a DAI 
> > > driver?
> > > 
> > > I'm a bit bothered by that, as the hardware is also capable of decoding
> > > stereo, sampling rate 32-192kHz, a variety of PCM and compressed/encrypted
> > > formats, 128-768fs MCLK multipliers, and a row of I2S options.
> > > 
> > > I just find it confusing to place the configuration interfaces.
> > > For instance, the patches use the media ioctl for audio output selection 
> > > to
> > > select I2S protocol. While works, it does not feel right (shouldn't it be 
> > > in
> > > the device tree?)
> > > 
> > > Maybe you can point me at a driver doing something similar? I'm studying 
> > > media
> > > drivers now, but not many of them use ASoC interfaces for devices 
> > > providing a
> > > clock. Or maybe I should better look at sound/soc/...?
> > 
> > Setting Sound Clock for all cases/patterns are very complex and difficult 
> > actually.
> > (ADV7482 configuration) x (ADG divider / selector) x etc, etc...
> > 
> > Thus, Current R-Car sound is assuming that audio_clk_a/b/c/i are providing
> > route clock (= no configuration, fixed clock), and ADG divides it,
> > and provide best clock to each SSIx.
> > Current Salvator/ULCB already have 44.1/48kHz route clock (= CS2000 and 
> > Audio_CLK_A),
> > and we can reuse it for all SSIx. Thus, ADV7482 clock is not necessary, I 
> > guess ?
> > Or providing specific clock for some case is enough
> > (ADG will automatically select it if necessary).
> 
> In this particular case, the ADV7482 *must* provide the clock, I believe: it
> extracts the audio stream from the HDMI connection (in addition to everything
> else) and serves the stream on I2S. Its MCLK line is physically connected to
> the CLK_C line (which is an input) of the R-Car SoC. The I2S audio
> transmission does not work if the ADV7482 clock is not programmed (or
> programmed incorrectly).
> Yes, I tried (I also tried programming it incorrectly, just because I didn't
> know what I was doing).
> 
> > If ADV7482 needs more detail clock settings combination,
> > then, there is no method to adjust to it.
> > We need to consider such system somehow.
> 
> Not encouraging...
> 
> Maybe I should leave the clock fixed, with the frequency configuration in the
> device tree, e.g. as adv7482 port node property "clock-frequency".
> Which feels rather pathetic, but at least serves my purpose (48k, 8x24).
> 
> But let me describe the situation as I see it first.
> 
> As far as I understand, the SSI4 (Salvator-X board) should be programmed by
> the snd-soc-rcar driver in the "slave receiver" mode for this use case, which
> is HDMI input ADV7482 (I2S master, TDM) -> SSI4 (I2S slave)):
> 
> [   63.305990] asoc_simple_card_parse_clk: asoc-audio-graph-card sound: 
> rsnd-dai.1 : sysclk = 6664, direction 0
> [   63.306028] asoc_simple_card_parse_clk: asoc-audio-graph-card sound: 
> adv748x-i2s : sysclk = 12288000, direction 1
> 
> I am a bit bothered by the fact that sysclk of rsnd-dai.1 does not match that
> sysclk of adv7482-i2s, but I think it's just DT node configuration.
> 
> [   63.306033] asoc_simple_card_set_dailink_name: asoc-audio-graph-card 
> sound: name : rsnd-dai.1-adv748x-i2s
> ...
> [   63.332641] asoc-audio-graph-card sound: adv748x.4-0070 <-> rsnd-dai.1 
> mapping ok
> ...
> [   63.341317] dapm_connect_dai_link_widgets:  rsnd-dai.1-adv748x-i2s: 
> connected DAI link adv748x.4-0070:Capture -> ec50.sound:DAI1 Capture
> ...
> [  128.961389] rsnd_write: rcar_sound ec50.sound: w ssi[4] - SSICR ( 124) 
> : 9ceb0100
> 
> Decoding this last line (9ceb0100) gives SSICR.TRMD (bit1) =0, SSICR.SCKD
> (bit15) =0, SSICR.SWSD (bit14) =0. The combination is documented as "slave
> receiver". Which, I assume, makes SSI4 use the external clock. Given the
> received stream looks ok, something also must have set the dividers correctly.
> 
> From the above, I conclude, whatever the complexity of the audio system clock
> configuration, it seems to be implemented for the case.
> 
> I only miss a more or less clear way to configure the I2S master (ADV7482, 
> that is).

As a stop-gap measure, until the sound driver programs the clock, you
can set its frequency in DT with the assigned-clock-rates property.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 8/8] arm64: dts: renesas: salvator: add a connection from adv748x codec (HDMI input) to the R-Car SoC

[Laurent Pinchart]

Hi Alex,

(CC'ing Morimoto-san)

On Fri, Mar 06, 2020 at 02:41:54PM +0100, Alex Riesen wrote:
> Laurent Pinchart, Fri, Mar 06, 2020 14:16:32 +0100:
> > On Thu, Mar 05, 2020 at 03:36:28PM +0100, Alex Riesen wrote:
> >> Geert Uytterhoeven, Mon, Mar 02, 2020 17:13:30 +0100:
> >>> On Mon, Mar 2, 2020 at 5:09 PM Alex Riesen  
> >>> wrote:
> >>>> Geert Uytterhoeven, Mon, Mar 02, 2020 16:32:32 +0100:
> >>>>>
> >>>>> The #clock-cells should be in the main video-receiver node.
> >>>>> Probably there is more than one clock output, so #clock-cells may be 1?
> >>>>
> >>>> AFAICS, the device can provide only this one clock line (audio master 
> >>>> clock
> >>>> for I2S output)... I shall re-check, just in case.
> >> 
> >> And you're right, of course: the audio output formatting module of the 
> >> ADV748x
> >> devices provides a set of clock lines related to the I2S pins: the already
> >> discussed master clock, left-right channel clock and the serial clock (bit
> >> clock?).
> > 
> > I don't think we need to model the last two clocks through CCF though,
> > they're part of the I2S protocol, not clock sources that need to be
> > explicitly controlled (or queried).
> 
> That's good, because I'm right now having hard time finding out how to
> calculate the frequencies!
> 
> >> Just to try it out (I'll set #clock-cells to 1), I registered a fixed rate
> >> clock in the driver, added a clock provider:
> >> 
> >> adv748x_probe:
> >> 
> >> clk = clk_register_fixed_rate(state->dev,
> >>  "clk-hdmi-i2s-mclk",
> >>  NULL /* parent_name */,
> >>  0/* flags */,
> >>  12288000 /* rate */);
> >> of_clk_add_provider(state->dev->of_node, of_clk_src_simple_get, clk);
> >> 
> >> And removed the audio_clk_c frequency setting. I also replaced the 
> >> audio_clk_c
> >> in the list of input clocks of the R-Car-side sound card with the phandle 
> >> of
> >> the adv7482 main node:
> >> 
> >> salvator-common.dtsi:
> >> 
> >>  {
> >>status = "okay";
> >> 
> >>adv7482_hdmi_decoder: video-receiver@70 {
> >>#clock-cells = <0>; // to be replaced with <1>
> >>};
> >> };
> >> 
> >> _sound {
> >>clocks = ..., <_hdmi_decoder>, ...;
> >> };
> >> 
> >> As everything continues to work as before, I assume that at least the clock
> >> dependencies were resolved.
> > 
> > This looks good to me.
> 
> Ok, I settle on this than.
> 
> >> Is there a way to verify that the added input clock is actually used?
> >> IOW, if its frequency is actually has been programmed into the ssi4 (R-Car
> >> receiving hardware) registers, and not just a left-over from previuos 
> >> attempts
> >> or plain default setting?
> >> 
> >> As the ADV748x devices seem to provide also the clocks for video outputs, 
> >> will
> >> it make any sense to place the clock definition into the port node?
> >> Or should all provided clocks be indexed in the main device node?
> > 
> > Those clocks are part of the CSI-2 protocol and also don't need to be
> > explicitly controlled. As far as I can tell from a quick check of the
> > ADV7482 documentation, only the I2S MCLK is a general-purpose clock that
> > needs to be exposed.
> 
> Thanks, that's good to know!
> 
> Do you know, by chance, which of the snd_soc* callbacks should be used to
> implement setting of the MCLK? The one in snd_soc_component_driver or
> snd_soc_dai_driver->ops (snd_soc_dai_ops)?
> 
> Or how the userspace interface looks like? Or, if there is no userspace
> interface for this, how the MCLK is supposed to be set? Through mclk-fs?

I'm afraid my knowledge of the sound subsystem is limited. Morimoto-san
is the main developer and maintainer of Renesas sound drivers.
Morimoto-sensei, would you have an answer to that question ? :-)

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 8/8] arm64: dts: renesas: salvator: add a connection from adv748x codec (HDMI input) to the R-Car SoC

[Laurent Pinchart]

Hi Alex,

On Thu, Mar 05, 2020 at 03:36:28PM +0100, Alex Riesen wrote:
> Geert Uytterhoeven, Mon, Mar 02, 2020 17:13:30 +0100:
> > On Mon, Mar 2, 2020 at 5:09 PM Alex Riesen  
> > wrote:
> > > Geert Uytterhoeven, Mon, Mar 02, 2020 16:32:32 +0100:
> > > >
> > > > The #clock-cells should be in the main video-receiver node.
> > > > Probably there is more than one clock output, so #clock-cells may be 1?
> > >
> > > AFAICS, the device can provide only this one clock line (audio master 
> > > clock
> > > for I2S output)... I shall re-check, just in case.
> 
> And you're right, of course: the audio output formatting module of the ADV748x
> devices provides a set of clock lines related to the I2S pins: the already
> discussed master clock, left-right channel clock and the serial clock (bit
> clock?).

I don't think we need to model the last two clocks through CCF though,
they're part of the I2S protocol, not clock sources that need to be
explicitly controlled (or queried).

> > > > There is no need for a fixed-clock compatible, nor for clock-frequency
> > > > and clock-output-names.
> > > >
> > > > But most important: this should be documented in the adv748x DT 
> > > > bindings,
> > > > and implemented in the adv748x driver.
> > >
> > > So if the driver is to export that clock for the kernel (like in this 
> > > case),
> > > it must implement its support?
> > 
> > Exactly.  Unless that pin is hardcoded to output a fixed clock, in which 
> > case
> > you can just override the existing audio_clk_c rate.
> 
> Just to try it out (I'll set #clock-cells to 1), I registered a fixed rate
> clock in the driver, added a clock provider:
> 
> adv748x_probe:
> 
> clk = clk_register_fixed_rate(state->dev,
> "clk-hdmi-i2s-mclk",
> NULL /* parent_name */,
> 0/* flags */,
> 12288000 /* rate */);
> of_clk_add_provider(state->dev->of_node, of_clk_src_simple_get, clk);
> 
> And removed the audio_clk_c frequency setting. I also replaced the audio_clk_c
> in the list of input clocks of the R-Car-side sound card with the phandle of
> the adv7482 main node:
> 
> salvator-common.dtsi:
> 
>  {
>   status = "okay";
> 
>   adv7482_hdmi_decoder: video-receiver@70 {
>   #clock-cells = <0>; // to be replaced with <1>
>   };
> };
> 
> _sound {
>   clocks = ..., <_hdmi_decoder>, ...;
> };
> 
> As everything continues to work as before, I assume that at least the clock
> dependencies were resolved.

This looks good to me.

> Is there a way to verify that the added input clock is actually used?
> IOW, if its frequency is actually has been programmed into the ssi4 (R-Car
> receiving hardware) registers, and not just a left-over from previuos attempts
> or plain default setting?
> 
> As the ADV748x devices seem to provide also the clocks for video outputs, will
> it make any sense to place the clock definition into the port node?
> Or should all provided clocks be indexed in the main device node?

Those clocks are part of the CSI-2 protocol and also don't need to be
explicitly controlled. As far as I can tell from a quick check of the
ADV7482 documentation, only the I2S MCLK is a general-purpose clock that
needs to be exposed.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [greybus-dev] [PATCH] staging: greybus: match parenthesis alignment

[Laurent Pinchart]

Hi Kaaira,

Thank you for the patch.

On Thu, Feb 20, 2020 at 01:26:51AM +0530, Kaaira Gupta wrote:
> Fix checkpatch.pl warning of alignment should match open parenthesis in
> audio_codec.c
> 
> Signed-off-by: Kaaira Gupta 
> ---
>  drivers/staging/greybus/audio_codec.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/greybus/audio_codec.c 
> b/drivers/staging/greybus/audio_codec.c
> index 08746c85dea6..d62f91f4e9a2 100644
> --- a/drivers/staging/greybus/audio_codec.c
> +++ b/drivers/staging/greybus/audio_codec.c
> @@ -70,7 +70,7 @@ static int gbaudio_module_enable_tx(struct 
> gbaudio_codec_info *codec,
>   i2s_port = 0;   /* fixed for now */
>   cportid = data->connection->hd_cport_id;
>   ret = gb_audio_apbridgea_register_cport(data->connection,
> - i2s_port, cportid,
> + i2s_port, cportid,
>   AUDIO_APBRIDGEA_DIRECTION_TX);

I'm curious to know why you think the line you changed deserves a
modification, while the next one doesn't :-)

>   if (ret) {
>   dev_err_ratelimited(module->dev,
> @@ -160,7 +160,7 @@ static int gbaudio_module_disable_tx(struct 
> gbaudio_module_info *module, int id)
>   i2s_port = 0;   /* fixed for now */
>   cportid = data->connection->hd_cport_id;
>   ret = gb_audio_apbridgea_unregister_cport(data->connection,
> - i2s_port, cportid,
> +   i2s_port, cportid,
>   AUDIO_APBRIDGEA_DIRECTION_TX);
>   if (ret) {
>   dev_err_ratelimited(module->dev,
> @@ -205,7 +205,7 @@ static int gbaudio_module_enable_rx(struct 
> gbaudio_codec_info *codec,
>   i2s_port = 0;   /* fixed for now */
>   cportid = data->connection->hd_cport_id;
>   ret = gb_audio_apbridgea_register_cport(data->connection,
> - i2s_port, cportid,
> + i2s_port, cportid,
>   AUDIO_APBRIDGEA_DIRECTION_RX);
>   if (ret) {
>   dev_err_ratelimited(module->dev,
> @@ -295,7 +295,7 @@ static int gbaudio_module_disable_rx(struct 
> gbaudio_module_info *module, int id)
>   i2s_port = 0;   /* fixed for now */
>   cportid = data->connection->hd_cport_id;
>   ret = gb_audio_apbridgea_unregister_cport(data->connection,
> - i2s_port, cportid,
> +   i2s_port, cportid,
>   AUDIO_APBRIDGEA_DIRECTION_RX);
>   if (ret) {
>   dev_err_ratelimited(module->dev,

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v8 5/5] media: imx: Try colorimetry at both sink and source pads

[Laurent Pinchart]

c != V4L2_YCBCR_ENC_601 &&
> + tryfmt->ycbcr_enc != V4L2_YCBCR_ENC_709)
> + tryfmt->ycbcr_enc = V4L2_YCBCR_ENC_601;
>   } else {
> - if (tryfmt->xfer_func == V4L2_XFER_FUNC_DEFAULT) {
> - tryfmt->xfer_func =
> - V4L2_MAP_XFER_FUNC_DEFAULT(tryfmt->colorspace);
> - }
>   if (tryfmt->ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT) {
>   tryfmt->ycbcr_enc =
>   V4L2_MAP_YCBCR_ENC_DEFAULT(tryfmt->colorspace);
>   }
> - if (tryfmt->quantization == V4L2_QUANTIZATION_DEFAULT) {
> - tryfmt->quantization =
> - V4L2_MAP_QUANTIZATION_DEFAULT(
> - is_rgb, tryfmt->colorspace,
> - tryfmt->ycbcr_enc);
> - }
>   }
>  
> - if (ic_route) {
> - tryfmt->quantization = is_rgb ?
> - V4L2_QUANTIZATION_FULL_RANGE :
> - V4L2_QUANTIZATION_LIM_RANGE;
> - tryfmt->ycbcr_enc = V4L2_YCBCR_ENC_601;
> - }
> + if (tryfmt->quantization == V4L2_QUANTIZATION_DEFAULT)
> + tryfmt->quantization =
> + V4L2_MAP_QUANTIZATION_DEFAULT(is_rgb,
> +   tryfmt->colorspace,
> +   tryfmt->ycbcr_enc);
>  }
> -EXPORT_SYMBOL_GPL(imx_media_fill_default_mbus_fields);
> +EXPORT_SYMBOL_GPL(imx_media_try_colorimetry);
>  
>  int imx_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix,
> struct v4l2_rect *compose,
> diff --git a/drivers/staging/media/imx/imx-media-vdic.c 
> b/drivers/staging/media/imx/imx-media-vdic.c
> index 4487374c9435..fbafd7fb7aeb 100644
> --- a/drivers/staging/media/imx/imx-media-vdic.c
> +++ b/drivers/staging/media/imx/imx-media-vdic.c
> @@ -617,14 +617,13 @@ static void vdic_try_fmt(struct vdic_priv *priv,
> >format.height,
> MIN_H, MAX_H_VDIC, H_ALIGN, S_ALIGN);
>  
> - imx_media_fill_default_mbus_fields(>format, infmt,
> -true);
> -
>   /* input must be interlaced! Choose SEQ_TB if not */
>   if (!V4L2_FIELD_HAS_BOTH(sdformat->format.field))
>   sdformat->format.field = V4L2_FIELD_SEQ_TB;
>   break;
>   }
> +
> + imx_media_try_colorimetry(>format, true);
>  }
>  
>  static int vdic_set_fmt(struct v4l2_subdev *sd,
> diff --git a/drivers/staging/media/imx/imx-media.h 
> b/drivers/staging/media/imx/imx-media.h
> index 6587aa49e005..23024c9bc887 100644
> --- a/drivers/staging/media/imx/imx-media.h
> +++ b/drivers/staging/media/imx/imx-media.h
> @@ -172,9 +172,8 @@ int imx_media_init_mbus_fmt(struct v4l2_mbus_framefmt 
> *mbus,
>   const struct imx_media_pixfmt **cc);
>  int imx_media_init_cfg(struct v4l2_subdev *sd,
>  struct v4l2_subdev_pad_config *cfg);
> -void imx_media_fill_default_mbus_fields(struct v4l2_mbus_framefmt *tryfmt,
> - struct v4l2_mbus_framefmt *fmt,
> - bool ic_route);
> +void imx_media_try_colorimetry(struct v4l2_mbus_framefmt *tryfmt,
> +bool ic_route);
>  int imx_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix,
> struct v4l2_rect *compose,
> const struct v4l2_mbus_framefmt *mbus,
> diff --git a/drivers/staging/media/imx/imx7-media-csi.c 
> b/drivers/staging/media/imx/imx7-media-csi.c
> index a708a0340eb1..6e2f4c3eb24f 100644
> --- a/drivers/staging/media/imx/imx7-media-csi.c
> +++ b/drivers/staging/media/imx/imx7-media-csi.c
> @@ -1003,8 +1003,6 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi,
>  
>   sdformat->format.colorspace = in_fmt->colorspace;
>   sdformat->format.xfer_func = in_fmt->xfer_func;
> - sdformat->format.quantization = in_fmt->quantization;
> - sdformat->format.ycbcr_enc = in_fmt->ycbcr_enc;
>   break;
>   case IMX7_CSI_PAD_SINK:
>   *cc = imx_media_find_mbus_format(sdformat->format.code,
> @@ -1015,14 +1013,14 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi,
>false);
>   sdformat->format.code = (*cc)->codes[0];
>   }
> -
> - imx_media_fill_default_mbus_fields(>format, in_fmt,
> -false);
>   break;
>   default:
>   return -EINVAL;
>   break;
>   }
> +
> + imx_media_try_colorimetry(>format, false);
> +
>   return 0;
>  }
>  
> -- 
> 2.17.1
> 

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH -next] staging: media: omap4iss: use devm_platform_ioremap_resource() to simplify code

[Laurent Pinchart]

Hello YueHaibing,

Thank you for the patch.

The same fix has already been submitted a week ago, and I have sent a
pull request today that includes it. I'm afraid I thus can't take this
patch. The good news is that the change was good :-)

On Wed, Oct 16, 2019 at 04:51:36PM +0800, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/staging/media/omap4iss/iss.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c 
> b/drivers/staging/media/omap4iss/iss.c
> index 1a966cb..6fb60b5 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -908,11 +908,7 @@ static int iss_map_mem_resource(struct platform_device 
> *pdev,
>   struct iss_device *iss,
>   enum iss_mem_resources res)
>  {
> - struct resource *mem;
> -
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, res);
> -
> - iss->regs[res] = devm_ioremap_resource(iss->dev, mem);
> + iss->regs[res] = devm_platform_ioremap_resource(pdev, res);
>  
>   return PTR_ERR_OR_ZERO(iss->regs[res]);
>  }

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: media: make use of devm_platform_ioremap_resource

[Laurent Pinchart]

Hello Hariprasad,

Thank you for the patch.

As the patch only touches the omap4iss driver, you could have made the
subject line a bit more specific, for instance "staging: media:
omap4iss: Use devm_platform_ioremap_resource". No big deal though.

On Tue, Oct 08, 2019 at 12:25:51PM +0530, 
hariprasadkelamhariprasad.ke...@gmail.com wrote:
> From: Hariprasad Kelam 
> 
> fix below issue reported by coccicheck
> drivers/staging//media/omap4iss/iss.c:915:1-15: WARNING: Use
> devm_platform_ioremap_resource for iss -> regs [ res ]
> 
> Signed-off-by: Hariprasad Kelam 

The change looks good to me.

Reviewed-by: Laurent Pinchart 

and applied to my tree for v5.5.

> ---
>  drivers/staging/media/omap4iss/iss.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c 
> b/drivers/staging/media/omap4iss/iss.c
> index 1a966cb..6fb60b5 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -908,11 +908,7 @@ static int iss_map_mem_resource(struct platform_device 
> *pdev,
>   struct iss_device *iss,
>   enum iss_mem_resources res)
>  {
> - struct resource *mem;
> -
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, res);
> -
> - iss->regs[res] = devm_ioremap_resource(iss->dev, mem);
> + iss->regs[res] = devm_platform_ioremap_resource(pdev, res);
>  
>   return PTR_ERR_OR_ZERO(iss->regs[res]);
>  }

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding

[Laurent Pinchart]

Hi Xin Ji,

On Mon, Oct 14, 2019 at 03:02:48AM +, Xin Ji wrote:
> On Fri, Oct 11, 2019 at 03:54:18PM +0300, Laurent Pinchart wrote:
> > On Fri, Oct 11, 2019 at 01:21:43PM +0200, Andrzej Hajda wrote:
> >> On 11.10.2019 04:21, Xin Ji wrote:
> >>> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> >>> for portable device. It converts MIPI to DisplayPort 1.3 4K.
> >>>
> >>> You can add support to your board with binding.
> >>>
> >>> Example:
> >>>   anx7625_bridge: encoder@58 {
> >>>   compatible = "analogix,anx7625";
> >>>   reg = <0x58>;
> >>>   status = "okay";
> >>>   panel-flags = <1>;
> >>>   enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> >>>   reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> >>>   #address-cells = <1>;
> >>>   #size-cells = <0>;
> >>>
> >>>   port@0 {
> >>> reg = <0>;
> >>> anx_1_in: endpoint {
> >>>   remote-endpoint = <_dsi>;
> >>> };
> >>>   };
> >>>
> >>>   port@3 {
> >>> reg = <3>;
> >>> anx_1_out: endpoint {
> >>>   remote-endpoint = <_in>;
> >>> };
> >>>   };
> >>>   };
> >>>
> >>> Signed-off-by: Xin Ji 
> >>> ---
> >>>  .../bindings/display/bridge/anx7625.yaml   | 96 
> >>> ++
> >>>  1 file changed, 96 insertions(+)
> >>>  create mode 100644 
> >>> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml 
> >>> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>> new file mode 100644
> >>> index 000..fc84683
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>> @@ -0,0 +1,96 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >>> +# Copyright 2019 Analogix Semiconductor, Inc.
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
> >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> >>> +
> >>> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> >>> +
> >>> +maintainers:
> >>> +  - Xin Ji 
> >>> +
> >>> +description: |
> >>> +  The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> >>> +  designed for portable devices.
> >>> +
> >>> +properties:
> >>> +  "#address-cells": true
> >>> +  "#size-cells": true
> >>> +
> >>> +  compatible:
> >>> +items:
> >>> +  - const: analogix,anx7625
> >>> +
> >>> +  reg:
> >>> +maxItems: 1
> >>> +
> >>> +  panel-flags:
> >>> +description: indicate the panel is internal or external
> >>> +maxItems: 1
> >>> +
> >>> +  interrupts:
> >>> +maxItems: 1
> >>> +
> >>> +  enable-gpios:
> >>> +description: used for power on chip control, POWER_EN pin D2.
> >>> +maxItems: 1
> >>> +
> >>> +  reset-gpios:
> >>> +description: used for reset chip control, RESET_N pin B7.
> >>> +maxItems: 1
> >>> +
> >>> +  port@0:
> >>> +type: object
> >>> +description:
> >>> +  A port node pointing to MIPI DSI host port node.
> >>> +
> >>> +  port@1:
> >>> +type: object
> >>> +description:
> >>> +  A port node pointing to MIPI DPI host port node.
> >>> +
> >>> +  port@2:
> >>> +type: object
> >>> +description:
> >>> +  A port node pointing to external connector port node.
> >>> +
> >>> +  port@3:
> >>> +type: object
> >>> +description:
> >>> +  A port node pointing to eDP port node.
> >> 
> >>

Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding

[Laurent Pinchart]

 different approach, but maybe better in this case.

I believe that, when connected to a DP display (either DP or eDP), the
DisplayPort signals are output on SS1 and/or SS2. I this really wonder
if we need two separate ports for this, it seems that port@2 and port@3
should be merged.

> Maybe it would be good to add 2nd example with USB-C port.

That would help with the discussion, yes.

> [1]:
> https://www.analogix.com/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
> 
> [2]: Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> > +
> > +required:
> > +  - "#address-cells"
> > +  - "#size-cells"
> > +  - compatible
> > +  - reg
> > +  - port@0
> > +  - port@3
> > +
> > +example:
> > +  - |
> > +anx7625_bridge: encoder@58 {
> > +compatible = "analogix,anx7625";
> > +reg = <0x58>;
> > +status = "okay";
> > +panel-flags = <1>;
> > +enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> > +reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +  reg = <0>;
> > +  anx_1_in: endpoint {
> > +remote-endpoint = <_dsi>;
> > +  };
> > +};
> > +
> > +port@3 {
> > +  reg = <3>;
> > +  anx_1_out: endpoint {
> > +remote-endpoint = <_in>;
> > +  };
> > +};
> > +};

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding

[Laurent Pinchart]

Hi Xin Ji,

Thank you for the patch.

On Wed, Oct 09, 2019 at 09:27:07AM +, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
> 
> You can add support to your board with binding.
> 
> Example:
>   anx_bridge: anx7625@58 {
>   compatible = "analogix,anx7625";
>   reg = <0x58>;
>   enable-gpios = < 45 GPIO_ACTIVE_LOW>;
>   reset-gpios = < 73 GPIO_ACTIVE_LOW>;
>   status = "okay";
>   port@0 {
>   reg = <0>;
>   anx7625_1_in: endpoint {
>   remote-endpoint = <_dsi_bridge_1>;
>   };
>   };
>   };
> 
> Signed-off-by: Xin Ji 
> ---
>  .../bindings/display/bridge/anx7625.yaml   | 79 
> ++
>  1 file changed, 79 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml 
> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> new file mode 100644
> index 000..0ef6271
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Analogix Semiconductor, Inc.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> +
> +maintainers:
> +  - Xin Ji 
> +
> +description: |
> +  The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> +  designed for portable devices.
> +
> +properties:
> +  compatible:
> +items:
> +  - const: analogix,anx7625
> +
> +  reg:
> +maxItems: 1
> +
> +  hpd-gpios:
> +description: used for HPD interrupt
> +maxItems: 1

You explained in your reply to v1 review that this describes the
interrupt generated by the ANX7625. It should be replaced by an
interrupts property.

> +
> +  enable-gpios:
> +description: used for power on chip control
> +maxItems: 1
> +
> +  reset-gpios:
> +description: used for reset chip control
> +maxItems: 1

Could you please mention the exact name of the corresponding pins on the
chip for enable and reset ?

> +
> +  port@0:
> +type: object
> +description:
> +  A port node pointing to MIPI DSI host port node.
> +
> +  port@1:
> +type: object
> +description:
> +  A port node pointing to MIPI DPI host port node.
> +
> +  port@2:
> +type: object
> +description:
> +  A port node pointing to external connector port node.
> +
> +  port@3:
> +type: object
> +description:
> +  A port node pointing to internal panel port node.
> +
> +  port@4:
> +type: object
> +description:
> +  A port node pointing to normal eDP port node.

I don't think three output ports is correct. Ports 3 and 4 are really
the same. I'm even unsure about port 2 and 3, someone with better
knowledge of USB-C and DisplayPort would be in a better position to
comment.

> +

You're missing the #address-cells and #size-cells properties required
for the ports. As the device is an I2C device we're lucky that the
parent will specify compatible address and size cells numbers, but I'm
not sure we should rely on that luck.

Rob, how does yaml schema handle this ?

> +required:
> +  - compatible
> +  - reg
> +  - port@0 | port@1
> +
> +example:
> +  - |
> +anx_bridge: anx7625@58 {

The node name should describe the device's function. How about
encoder@58 ?

> +compatible = "analogix,anx7625";
> +reg = <0x58>;
> +status = "okay";
> +port@0 {
> +  reg = <0>;
> +  anx7625_1_in: endpoint {
> +remote-endpoint = <_dsi_bridge_1>;
> +  };
> +};
> +};

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding

[Laurent Pinchart]

DSI input port is
connected.

Assuming the ANX7625 can also output DisplayPort directly without going
through USB Type-C (I can't verify that without the datasheet), I think
you should use two output ports, one for USB Type-C and one for
DisplayPort. The extcon-supported and internal-pannel-supported
properties should be removed, and deduced from the connect output port.

> +
> +required:
> +  - compatible
> +  - reg
> +  - dsi-channel-id
> +  - dsi-lanes-num
> +  - port@0
> +
> +example:
> +  - |
> +anx_bridge: anx7625@58 {
> +compatible = "analogix,anx7625";
> +reg = <0x58>;
> +low-power-gpios = <0>;
> +dsi-supported = <1>;
> +dsi-channel-id = <1>;
> +dsi-lanes-num = <4>;
> +hpd-gpios = < 19 IRQ_TYPE_LEVEL_LOW>;
> +status = "okay";
> +};

You mention the port@0 node as being required, but it's missing from the
example.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 5/7] media: use the BIT() macro

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Fri, Aug 23, 2019 at 06:47:30AM -0300, Mauro Carvalho Chehab wrote:
> As warned by cppcheck:
> 
>   [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   ...
>   [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
> 
> There are lots of places where we're doing 1 << 31. That's bad,
> as, depending on the architecture, this has an undefined behavior.
> 
> The BIT() macro is already prepared to handle this, so, let's
> just switch all "1 << number" macros by BIT(number) at the header files
> with has 1 << 31.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> v2: 
>   As suggested by Laurent:
>  - Don't touch multi-bit masks
>  - remove explicit casts
> 
>  drivers/media/pci/cobalt/cobalt-driver.h  |  63 +-
>  drivers/media/pci/ivtv/ivtv-irq.h |  28 +-
>  drivers/media/pci/mantis/mantis_reg.h | 152 ++---
>  drivers/media/pci/solo6x10/solo6x10-regs.h| 286 -
>  .../media/platform/am437x/am437x-vpfe_regs.h  |  26 +-
>  .../media/platform/davinci/dm644x_ccdc_regs.h |  20 +-
>  .../media/platform/exynos4-is/fimc-lite-reg.h |  80 +--
>  drivers/media/platform/exynos4-is/fimc-reg.h  | 138 +++--
>  drivers/media/platform/omap3isp/ispreg.h  | 580 +-
>  drivers/media/platform/s3c-camif/camif-regs.h | 118 ++--
>  drivers/media/platform/tegra-cec/tegra_cec.h  |  80 +--
>  drivers/media/platform/ti-vpe/vpe_regs.h  |  94 +--
>  drivers/media/platform/vsp1/vsp1_regs.h   | 224 +++
>  drivers/media/platform/xilinx/xilinx-vip.h|  29 +-
>  drivers/media/radio/wl128x/fmdrv_common.h |  88 +--
>  drivers/staging/media/ipu3/ipu3-tables.h  |   4 +-
>  16 files changed, 1011 insertions(+), 999 deletions(-)

[snip]

> diff --git a/drivers/media/platform/omap3isp/ispreg.h 
> b/drivers/media/platform/omap3isp/ispreg.h
> index 38e2b99b3f10..4c6ebc0b74d1 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h

[snip]

> @@ -1167,14 +1167,14 @@
>  #define ISPHIST_HV_INFO_MASK 0x3FFF3FFF
>  
>  #define ISPCCDC_LSC_ENABLE   1

This is a bit too, it could be replaced with BIT(0).

> -#define ISPCCDC_LSC_BUSY (1 << 7)
> +#define ISPCCDC_LSC_BUSY BIT(7)
>  #define ISPCCDC_LSC_GAIN_MODE_N_MASK 0x700
>  #define ISPCCDC_LSC_GAIN_MODE_N_SHIFT8
>  #define ISPCCDC_LSC_GAIN_MODE_M_MASK 0x3800
>  #define ISPCCDC_LSC_GAIN_MODE_M_SHIFT12
>  #define ISPCCDC_LSC_GAIN_FORMAT_MASK 0xE
>  #define ISPCCDC_LSC_GAIN_FORMAT_SHIFT1
> -#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK   (1<<6)
> +#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK   BIT(6)
>  
>  #define ISPCCDC_LSC_INITIAL_X_MASK   0x3F
>  #define ISPCCDC_LSC_INITIAL_X_SHIFT  0

[snip]

With this small issue addressed,

For omap3isp, vsp1, xilinx, wl128x and ipu3,

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/7] media: use the BIT() macro

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thu, Aug 22, 2019 at 04:39:32PM -0300, Mauro Carvalho Chehab wrote:
> As warned by cppcheck:
> 
>   [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   ...
>   [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
> 
> There are lots of places where we're doing 1 << 31. That's bad,
> as, depending on the architecture, this has an undefined behavior.
> 
> The BIT() macro is already prepared to handle this, so, let's
> just switch all "1 << number" macros by BIT(number) at the header files
> with has 1 << 31.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/pci/cobalt/cobalt-driver.h  |  63 +-
>  drivers/media/pci/ivtv/ivtv-irq.h |  28 +-
>  drivers/media/pci/mantis/mantis_reg.h | 156 ++---
>  drivers/media/pci/solo6x10/solo6x10-regs.h| 290 -
>  .../media/platform/am437x/am437x-vpfe_regs.h  |  28 +-
>  .../media/platform/davinci/dm644x_ccdc_regs.h |  22 +-
>  .../media/platform/exynos4-is/fimc-lite-reg.h |  86 +--
>  drivers/media/platform/exynos4-is/fimc-reg.h  | 172 ++---
>  drivers/media/platform/omap3isp/ispreg.h  | 592 +-
>  drivers/media/platform/s3c-camif/camif-regs.h | 128 ++--
>  drivers/media/platform/tegra-cec/tegra_cec.h  |  80 +--
>  drivers/media/platform/ti-vpe/vpe_regs.h  |  94 +--
>  drivers/media/platform/vsp1/vsp1_regs.h   | 254 
>  drivers/media/platform/xilinx/xilinx-vip.h|  33 +-
>  drivers/media/radio/wl128x/fmdrv_common.h |  88 +--
>  drivers/staging/media/ipu3/ipu3-tables.h  |   4 +-
>  16 files changed, 1065 insertions(+), 1053 deletions(-)
> 
> diff --git a/drivers/media/pci/cobalt/cobalt-driver.h 
> b/drivers/media/pci/cobalt/cobalt-driver.h
> index 429bee4ef79c..14b8ca2daa17 100644
> --- a/drivers/media/pci/cobalt/cobalt-driver.h
> +++ b/drivers/media/pci/cobalt/cobalt-driver.h
> @@ -10,6 +10,7 @@
>  
>  #ifndef COBALT_DRIVER_H
>  #define COBALT_DRIVER_H
> +#include 
>  

The blank line should go before the header, not after.

>  #include 
>  #include 

[snip]

> diff --git a/drivers/media/platform/omap3isp/ispreg.h 
> b/drivers/media/platform/omap3isp/ispreg.h
> index 38e2b99b3f10..197f8f43c8fc 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
> @@ -45,7 +45,7 @@
>  
>  #define ISPCCP2_REVISION (0x000)
>  #define ISPCCP2_SYSCONFIG(0x004)
> -#define ISPCCP2_SYSCONFIG_SOFT_RESET (1 << 1)
> +#define ISPCCP2_SYSCONFIG_SOFT_RESET BIT(1)
>  #define ISPCCP2_SYSCONFIG_AUTO_IDLE  0x1
>  #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT12
>  #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_FORCE\
> @@ -55,44 +55,44 @@
>  #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART\
>   (0x2 << ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
>  #define ISPCCP2_SYSSTATUS(0x008)
> -#define ISPCCP2_SYSSTATUS_RESET_DONE (1 << 0)
> +#define ISPCCP2_SYSSTATUS_RESET_DONE BIT(0)
>  #define ISPCCP2_LC01_IRQENABLE   (0x00C)
>  #define ISPCCP2_LC01_IRQSTATUS   (0x010)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ(1 << 11)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_LE_IRQ(1 << 10)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_LS_IRQ(1 << 9)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FE_IRQ(1 << 8)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_COUNT_IRQ (1 << 7)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FIFO_OVF_IRQ  (1 << 5)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ   (1 << 4)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ   (1 << 3)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQ(1 << 2)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ   (1 << 1)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ   (1 << 0)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQBIT(11)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_LE_IRQBIT(10)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_LS_IRQBIT(9)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FE_IRQBIT(8)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_COUNT_IRQ BIT(7)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FIFO_OVF_IRQ  BIT(5)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ   BIT(4)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ   BIT(3)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQBIT(2)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ   BIT(1)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ   BIT(0)
>  
>  #define ISPCCP2_LC23_IRQENABLE   (0x014)
>  #define ISPCCP2_LC23_IRQSTATUS   (0x018)
>  #define ISPCCP2_LCM_IRQENABLE(0x02C)
> -#define ISPCCP2_LCM_IRQSTATUS_EOF_IRQ(1 << 0)
> -#define 

Re: [PATCH v2] Adjust analogix chip driver location

[Laurent Pinchart]

Hello Xin Ji,

Thank you for the patch.

On Fri, Jun 28, 2019 at 03:00:05AM +, Xin Ji wrote:
> Move analogix chip ANX78XX bridge driver into "analogix" directory.
> 
> Signed-off-by: Xin Ji 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/Kconfig   | 10 --
>  drivers/gpu/drm/bridge/Makefile  |  3 +--
>  drivers/gpu/drm/bridge/analogix/Kconfig  | 10 ++
>  drivers/gpu/drm/bridge/analogix/Makefile |  2 ++
>  drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c |  0
>  drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h |  0
>  6 files changed, 13 insertions(+), 12 deletions(-)
>  rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%)
>  rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index ee77746..862789b 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -16,16 +16,6 @@ config DRM_PANEL_BRIDGE
>  menu "Display Interface Bridges"
>   depends on DRM && DRM_BRIDGE
>  
> -config DRM_ANALOGIX_ANX78XX
> - tristate "Analogix ANX78XX bridge"
> - select DRM_KMS_HELPER
> - select REGMAP_I2C
> - ---help---
> -   ANX78XX is an ultra-low Full-HD SlimPort transmitter
> -   designed for portable devices. The ANX78XX transforms
> -   the HDMI output of an application processor to MyDP
> -   or DisplayPort.
> -
>  config DRM_CDNS_DSI
>   tristate "Cadence DPI/DSI bridge"
>   select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..223ca5d 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> @@ -12,8 +11,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
>  obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> -obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-y += analogix/
>  obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e930ff9..dfe84f5 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,14 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +config DRM_ANALOGIX_ANX78XX
> + tristate "Analogix ANX78XX bridge"
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + ---help---
> +   ANX78XX is an ultra-low Full-HD SlimPort transmitter
> +   designed for portable devices. The ANX78XX transforms
> +   the HDMI output of an application processor to MyDP
> +   or DisplayPort.
> +
>  config DRM_ANALOGIX_DP
>   tristate
>   depends on DRM
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index fdbf3fd..d4c54ac 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,3 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +
>  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> similarity index 100%
> rename from drivers/gpu/drm/bridge/analogix-anx78xx.c
> rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> similarity index 100%
> rename from drivers/gpu/drm/bridge/analogix-anx78xx.h
> rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1] Adjust analogix chip driver location

[Laurent Pinchart]

Hello Xin Ji,

Thank you for the patch.

On Thu, Jun 27, 2019 at 11:29:47AM +, Xin Ji wrote:
> Move analogix chip ANX78XX bridge driver into "analogix" directory.
> 
> Signed-off-by: Xin Ji 
> ---
>  drivers/gpu/drm/bridge/Kconfig   | 10 --
>  drivers/gpu/drm/bridge/Makefile  |  3 +--
>  drivers/gpu/drm/bridge/analogix/Kconfig  | 10 ++
>  drivers/gpu/drm/bridge/analogix/Makefile |  2 ++
>  drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c |  0
>  drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h |  0
>  6 files changed, 13 insertions(+), 12 deletions(-)
>  rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%)
>  rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index ee77746..862789b 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -16,16 +16,6 @@ config DRM_PANEL_BRIDGE
>  menu "Display Interface Bridges"
>   depends on DRM && DRM_BRIDGE
>  
> -config DRM_ANALOGIX_ANX78XX
> - tristate "Analogix ANX78XX bridge"
> - select DRM_KMS_HELPER
> - select REGMAP_I2C
> - ---help---
> -   ANX78XX is an ultra-low Full-HD SlimPort transmitter
> -   designed for portable devices. The ANX78XX transforms
> -   the HDMI output of an application processor to MyDP
> -   or DisplayPort.
> -
>  config DRM_CDNS_DSI
>   tristate "Cadence DPI/DSI bridge"
>   select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..02cb4cd 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> @@ -12,8 +11,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
>  obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> -obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>  obj-y += synopsys/
> +obj-y += analogix/

Could you place that line just above the synopsys/ directory, to have
them alphabetically sorted (this could also be done while applying) ?
Apart from that the patch looks good to me, so

Reviewed-by: Laurent Pinchart 

> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e930ff9..dfe84f5 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,14 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +config DRM_ANALOGIX_ANX78XX
> + tristate "Analogix ANX78XX bridge"
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + ---help---
> +   ANX78XX is an ultra-low Full-HD SlimPort transmitter
> +   designed for portable devices. The ANX78XX transforms
> +   the HDMI output of an application processor to MyDP
> +   or DisplayPort.
> +
>  config DRM_ANALOGIX_DP
>   tristate
>   depends on DRM
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index fdbf3fd..d4c54ac 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,3 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +
>  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> similarity index 100%
> rename from drivers/gpu/drm/bridge/analogix-anx78xx.c
> rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> similarity index 100%
> rename from drivers/gpu/drm/bridge/analogix-anx78xx.h
> rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging/imx: add media device to capture register

[Laurent Pinchart]

Hi Rui,

Thank you for the patch.

On Fri, Apr 12, 2019 at 05:44:00PM +0100, Rui Miguel Silva wrote:
> When register the capture media device it is assumed that the device
> data is the media device. In the imx6 case is but in the imx7 is not
> case. The device data is the csi structure.
> 
> Add the explicit argument of the media device that we want to
> associate with the capture device.

I've tested this, and the driver no longer deadlocks. I can't capture
images though, but that may well be due to my platform, the sensor
driver hasn't been validated yet.

Thank you for your help, I will report any progress. In any case there's
certainly room for improvement in the i.MX6/7 camera driver if we want
to get it out of staging, the way the multiple components are backed by
separate drivers that access each other's device data is a big hack at
best. If time permits, after getting capture working, I'll see if I can
start cleaning it up.

> Reported-by: Laurent Pinchart 
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/staging/media/imx/imx-ic-prpencvf.c   | 2 +-
>  drivers/staging/media/imx/imx-media-capture.c | 6 +++---
>  drivers/staging/media/imx/imx-media-csi.c | 2 +-
>  drivers/staging/media/imx/imx-media.h | 3 ++-
>  drivers/staging/media/imx/imx7-media-csi.c| 2 +-
>  5 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
> b/drivers/staging/media/imx/imx-ic-prpencvf.c
> index 5c8e6ad8c025..3ca1422f6154 100644
> --- a/drivers/staging/media/imx/imx-ic-prpencvf.c
> +++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
> @@ -1270,7 +1270,7 @@ static int prp_registered(struct v4l2_subdev *sd)
>   if (ret)
>   return ret;
>  
> - ret = imx_media_capture_device_register(priv->vdev);
> + ret = imx_media_capture_device_register(priv->md, priv->vdev);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/staging/media/imx/imx-media-capture.c 
> b/drivers/staging/media/imx/imx-media-capture.c
> index 9703c85b19c4..7688238a3396 100644
> --- a/drivers/staging/media/imx/imx-media-capture.c
> +++ b/drivers/staging/media/imx/imx-media-capture.c
> @@ -706,7 +706,8 @@ void imx_media_capture_device_error(struct 
> imx_media_video_dev *vdev)
>  }
>  EXPORT_SYMBOL_GPL(imx_media_capture_device_error);
>  
> -int imx_media_capture_device_register(struct imx_media_video_dev *vdev)
> +int imx_media_capture_device_register(struct imx_media_dev *md,
> +   struct imx_media_video_dev *vdev)
>  {
>   struct capture_priv *priv = to_capture_priv(vdev);
>   struct v4l2_subdev *sd = priv->src_sd;
> @@ -715,8 +716,7 @@ int imx_media_capture_device_register(struct 
> imx_media_video_dev *vdev)
>   struct v4l2_subdev_format fmt_src;
>   int ret;
>  
> - /* get media device */
> - priv->md = dev_get_drvdata(sd->v4l2_dev->dev);
> + priv->md = md;
>  
>   vfd->v4l2_dev = sd->v4l2_dev;
>  
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index 3b7517348666..3408ec023d29 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -1806,7 +1806,7 @@ static int csi_registered(struct v4l2_subdev *sd)
>   if (ret)
>   goto free_fim;
>  
> - ret = imx_media_capture_device_register(priv->vdev);
> + ret = imx_media_capture_device_register(priv->md, priv->vdev);
>   if (ret)
>   goto free_fim;
>  
> diff --git a/drivers/staging/media/imx/imx-media.h 
> b/drivers/staging/media/imx/imx-media.h
> index ae964c8d5be1..c3a8512bd10f 100644
> --- a/drivers/staging/media/imx/imx-media.h
> +++ b/drivers/staging/media/imx/imx-media.h
> @@ -271,7 +271,8 @@ int imx_media_of_add_csi(struct imx_media_dev *imxmd,
>  struct imx_media_video_dev *
>  imx_media_capture_device_init(struct v4l2_subdev *src_sd, int pad);
>  void imx_media_capture_device_remove(struct imx_media_video_dev *vdev);
> -int imx_media_capture_device_register(struct imx_media_video_dev *vdev);
> +int imx_media_capture_device_register(struct imx_media_dev *md,
> +struct imx_media_video_dev *vdev);
>  void imx_media_capture_device_unregister(struct imx_media_video_dev *vdev);
>  struct imx_media_buffer *
>  imx_media_capture_device_next_buf(struct imx_media_video_dev *vdev);
> diff --git a/drivers/staging/media/imx/imx7-media-csi.c 
> b/drivers/staging/media/imx/imx7-media-csi.c
> index 3fba7c27c0ec..a907c5feb3eb 100644
> --- a/drivers/staging/media/imx/imx7-media-csi.c
> +++ b/drivers/staging/media/imx/imx7-media-csi.c
> @@ -1124,7 +

Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver

[Laurent Pinchart]

Hi Rui,

On Tue, Mar 12, 2019 at 02:07:02PM +, Rui Miguel Silva wrote:
> On Sun 10 Mar 2019 at 21:48, Laurent Pinchart wrote:
> > On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva wrote:
> >> On Fri 18 May 2018 at 06:58, Sakari Ailus wrote:
> >>> On Thu, May 17, 2018 at 01:50:27PM +0100, Rui Miguel Silva wrote:
> >>>> Add bindings documentation for i.MX7 media drivers.
> >>>> 
> >>>> Signed-off-by: Rui Miguel Silva 
> >>>> ---
> >>>>  .../devicetree/bindings/media/imx7.txt| 145 ++
> >>>>  1 file changed, 145 insertions(+)
> >>>>  create mode 100644 
> >>>>  Documentation/devicetree/bindings/media/imx7.txt
> >>>> 1
> >>>> diff --git 
> >>>> a/Documentation/devicetree/bindings/media/imx7.txt 
> >>>> b/Documentation/devicetree/bindings/media/imx7.txt
> >>>> new file mode 100644
> >>>> index ..161cff8e6442
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/media/imx7.txt
> >>>> @@ -0,0 +1,145 @@
> >>>> +Freescale i.MX7 Media Video Device
> >>>> +==
> >>>> +
> >>>> +Video Media Controller node
> >>>> +---
> >>>
> >>> Note that DT bindings document the hardware, they are as such 
> >>> not Linux dependent.
> >> 
> >> This was removed in this series, however I removed it in the wrong
> >> patch, If you see patch 11/12 you will see this being removed. I
> >> will fix this in v5. Thanks for notice it.
> >> 
> >>>> +
> >>>> +This is the media controller node for video capture  support. It is a
> >>>> +virtual device that lists the camera serial interface nodes that the
> >>>> +media device will control.
> >>>
> >>> Ditto.
> >>>
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible : "fsl,imx7-capture-subsystem";
> >>>> +- ports  : Should contain a list of phandles pointing to camera
> >>>> +sensor interface port of CSI
> >>>> +
> >>>> +example:
> >>>> +
> >>>> +capture-subsystem {
> >>>
> >>> What's the purpose of this node, if you only refer to another 
> >>> device? This one rather does not look like a real device at 
> >>> all.
> >>>
> >>>> +compatible = "fsl,imx7-capture-subsystem";
> >>>> +ports = <>;
> >>>> +};
> >>>> +
> >>>> +
> >>>> +mipi_csi2 node
> >>>> +--
> >>>> +
> >>>> +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. 
> >>>> It is
> >>>> +compatible with previous version of Samsung D-phy.
> >>>> +
> >>>> +Required properties:
> >>>> +
> >>>> +- compatible: "fsl,imx7-mipi-csi2";
> >>>> +- reg   : base address and length of the register set for the 
> >>>> device;
> >>>> +- interrupts: should contain MIPI CSIS interrupt;
> >>>> +- clocks: list of clock specifiers, see
> >>>> + 
> >>>> Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
> >>>> +- clock-names   : must contain "pclk", "wrap" and "phy" entries, 
> >>>> matching
> >>>> +  entries in the clock property;
> >>>> +- power-domains : a phandle to the power domain, see
> >>>> + 
> >>>> Documentation/devicetree/bindings/power/power_domain.txt for details.
> >>>> +- reset-names   : should include following entry "mrst";
> >>>> +- resets: a list of phandle, should contain reset entry of
> >>>> +  reset-names;
> >>>> +- phy-supply: from the generic phy bindings, a phandle to a 
> >>>> regulator that
> >>>> +  provides power to MIPI CSIS core;
> >>>> +- bus-width : maximum number of data lanes supported (SoC specific);
> >>>> +
> >>>> +Optional properties:
> >>>> +
> >>>> +- clock-frequency : The 

Re: [PATCH v14 08/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections

[Laurent Pinchart]

Hi Rui,

On Tue, Mar 12, 2019 at 02:05:24PM +, Rui Miguel Silva wrote:
> On Sun 10 Mar 2019 at 21:41, Laurent Pinchart wrote:
> > Hi Rui,
> >
> > Thank you for the patch.
> 
> Where have you been for the latest 14 versions? :)

Elsewhere I suppose :-)

> This is already merged, but... follow up patches can address your
> issues bellow.

I saw the driver and DT bindings patches merged in the media tree for
v5.2, where have the DT patches been merged ?

> > On Wed, Feb 06, 2019 at 03:13:23PM +, Rui Miguel Silva 
> > wrote:
> >> This patch adds the device tree nodes for csi, video 
> >> multiplexer and mipi-csi besides the graph connecting the necessary
> >> endpoints to make the media capture entities to work in imx7 Warp
> >> board.
> >> 
> >> Signed-off-by: Rui Miguel Silva 
> >> ---
> >>  arch/arm/boot/dts/imx7s-warp.dts | 51 
> >>  arch/arm/boot/dts/imx7s.dtsi | 27 +
> >
> > I would have split this in two patches to make backporting 
> > easier, but it's not a big deal.
> >
> > Please see below for a few additional comments.
> >
> >>  2 files changed, 78 insertions(+)
> >> 
> >> diff --git a/arch/arm/boot/dts/imx7s-warp.dts 
> >> b/arch/arm/boot/dts/imx7s-warp.dts
> >> index 23431faecaf4..358bcae7ebaf 100644
> >> --- a/arch/arm/boot/dts/imx7s-warp.dts
> >> +++ b/arch/arm/boot/dts/imx7s-warp.dts
> >> @@ -277,6 +277,57 @@
> >>status = "okay";
> >>  };
> >>  
> >> + {
> >> +  csi_mux {
> >> +  compatible = "video-mux";
> >> +  mux-controls = < 0>;
> >> +  #address-cells = <1>;
> >> +  #size-cells = <0>;
> >> +
> >> +  port@1 {
> >> +  reg = <1>;
> >> +
> >> +  csi_mux_from_mipi_vc0: endpoint {
> >> +  remote-endpoint = 
> >> <_vc0_to_csi_mux>;
> >> +  };
> >> +  };
> >> +
> >> +  port@2 {
> >> +  reg = <2>;
> >> +
> >> +  csi_mux_to_csi: endpoint {
> >> +  remote-endpoint = 
> >> <_from_csi_mux>;
> >> +  };
> >> +  };
> >> +  };
> >> +};
> >> +
> >> + {
> >> +  status = "okay";
> >> +
> >> +  port {
> >> +  csi_from_csi_mux: endpoint {
> >> +  remote-endpoint = <_mux_to_csi>;
> >> +  };
> >> +  };
> >> +};
> >
> > Shouldn't these two nodes, as well as port@1 of the mipi_csi 
> > node, be moved to imx7d.dtsi ?
> 
> Yeah, I guess you are right here.
> 
> >
> >> +
> >> +_csi {
> >> +  clock-frequency = <16600>;
> >> +  status = "okay";
> >> +  #address-cells = <1>;
> >> +  #size-cells = <0>;
> >> +  fsl,csis-hs-settle = <3>;
> >
> > Shouldn't this be an endpoint property ? Different sensors connected
> > through different endpoints could have different timing
> > requirements.
> 
> Hum... I see you point, even tho the phy hs-settle is a common
> control. 

I suppose we don't need to care about DT backward compatibility if we
make changes in the bindings for v5.2 ? Would you fix this, or do you
want a patch ?

> >> +
> >> +  port@1 {
> >> +  reg = <1>;
> >> +
> >> +  mipi_vc0_to_csi_mux: endpoint {
> >> +  remote-endpoint = <_mux_from_mipi_vc0>;
> >> +  };
> >> +  };
> >> +};
> >> +
> >>   {
> >>pinctrl-names = "default";
> >>pinctrl-0 = <_wdog>;
> >> diff --git a/arch/arm/boot/dts/imx7s.dtsi 
> >> b/arch/arm/boot/dts/imx7s.dtsi
> >> index 792efcd2caa1..01962f85cab6 100644
> >> --- a/arch/arm/boot/dts/imx7s.dtsi
> >> +++ b/arch/arm/boot/dts/imx7s.dtsi
> >> @@ -8,6 +8,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "imx7d-pinfunc.h"
> >>  
> >>  / {
> >> @@ -709,6 +710,17 @@
> >>status = "disabled";
> >>};
> >>  
> >> +   

Re: [PATCH v14 08/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections

[Laurent Pinchart]

Hi Rui,

Thank you for the patch.

On Wed, Feb 06, 2019 at 03:13:23PM +, Rui Miguel Silva wrote:
> This patch adds the device tree nodes for csi, video multiplexer and
> mipi-csi besides the graph connecting the necessary endpoints to make
> the media capture entities to work in imx7 Warp board.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  arch/arm/boot/dts/imx7s-warp.dts | 51 
>  arch/arm/boot/dts/imx7s.dtsi | 27 +

I would have split this in two patches to make backporting easier, but
it's not a big deal.

Please see below for a few additional comments.

>  2 files changed, 78 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7s-warp.dts 
> b/arch/arm/boot/dts/imx7s-warp.dts
> index 23431faecaf4..358bcae7ebaf 100644
> --- a/arch/arm/boot/dts/imx7s-warp.dts
> +++ b/arch/arm/boot/dts/imx7s-warp.dts
> @@ -277,6 +277,57 @@
>   status = "okay";
>  };
>  
> + {
> + csi_mux {
> + compatible = "video-mux";
> + mux-controls = < 0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csi_mux_from_mipi_vc0: endpoint {
> + remote-endpoint = <_vc0_to_csi_mux>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + csi_mux_to_csi: endpoint {
> + remote-endpoint = <_from_csi_mux>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + port {
> + csi_from_csi_mux: endpoint {
> + remote-endpoint = <_mux_to_csi>;
> + };
> + };
> +};

Shouldn't these two nodes, as well as port@1 of the mipi_csi node, be
moved to imx7d.dtsi ?

> +
> +_csi {
> + clock-frequency = <16600>;
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + fsl,csis-hs-settle = <3>;

Shouldn't this be an endpoint property ? Different sensors connected
through different endpoints could have different timing requirements.

> +
> + port@1 {
> + reg = <1>;
> +
> + mipi_vc0_to_csi_mux: endpoint {
> + remote-endpoint = <_mux_from_mipi_vc0>;
> + };
> + };
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_wdog>;
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 792efcd2caa1..01962f85cab6 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "imx7d-pinfunc.h"
>  
>  / {
> @@ -709,6 +710,17 @@
>   status = "disabled";
>   };
>  
> + csi: csi@3071 {
> + compatible = "fsl,imx7-csi";
> + reg = <0x3071 0x1>;
> + interrupts = ;
> + clocks = < IMX7D_CLK_DUMMY>,
> + < IMX7D_CSI_MCLK_ROOT_CLK>,
> + < IMX7D_CLK_DUMMY>;
> + clock-names = "axi", "mclk", "dcic";
> + status = "disabled";
> + };
> +
>   lcdif: lcdif@3073 {
>   compatible = "fsl,imx7d-lcdif", 
> "fsl,imx28-lcdif";
>   reg = <0x3073 0x1>;
> @@ -718,6 +730,21 @@
>   clock-names = "pix", "axi";
>   status = "disabled";
>   };
> +
> + mipi_csi: mipi-csi@3075 {
> + compatible = "fsl,imx7-mipi-csi2";
> + reg = <0x3075 0x1>;
> + interrupts = ;
> + clocks = < IMX7D_IPG_ROOT_CLK>,
> +     < IMX7D_MIPI_CSI_ROOT_CLK>,
> + < IMX7D_MIPI_DPHY_ROOT_CLK>;
> + clock-names = "pclk", "wrap", "phy";
> + power-domains = <_mipi_phy>;
> + phy-supply = <_1p0d>;
> + resets = < IMX7_RESET_MIPI_PHY_MRST>;
> + reset-names = "mrst";
> + status = "disabled";

How about already declaring port@0 here too (but obviously without any
endoint) ?

> + };
>   };
>  
>   aips3: aips-bus@3080 {

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver

[Laurent Pinchart]

Hi Rui,

On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva wrote:
> Hi Sakari,
> Thanks for the review.
> On Fri 18 May 2018 at 06:58, Sakari Ailus wrote:
> > On Thu, May 17, 2018 at 01:50:27PM +0100, Rui Miguel Silva wrote:
> >> Add bindings documentation for i.MX7 media drivers.
> >> 
> >> Signed-off-by: Rui Miguel Silva 
> >> ---
> >>  .../devicetree/bindings/media/imx7.txt| 145 
> >>  ++
> >>  1 file changed, 145 insertions(+)
> >>  create mode 100644 
> >>  Documentation/devicetree/bindings/media/imx7.txt
> >> 
> >> diff --git a/Documentation/devicetree/bindings/media/imx7.txt 
> >> b/Documentation/devicetree/bindings/media/imx7.txt
> >> new file mode 100644
> >> index ..161cff8e6442
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/imx7.txt
> >> @@ -0,0 +1,145 @@
> >> +Freescale i.MX7 Media Video Device
> >> +==
> >> +
> >> +Video Media Controller node
> >> +---
> >
> > Note that DT bindings document the hardware, they are as such 
> > not Linux dependent.
> 
> This was removed in this series, however I removed it in the wrong 
> patch, If you see patch 11/12 you will see this being removed. I will
> fix this in v5. Thanks for notice it.
> 
> >> +
> >> +This is the media controller node for video capture support. 
> >> It is a
> >> +virtual device that lists the camera serial interface nodes 
> >> that the
> >> +media device will control.
> >
> > Ditto.
> >
> >> +
> >> +Required properties:
> >> +- compatible : "fsl,imx7-capture-subsystem";
> >> +- ports  : Should contain a list of phandles pointing to 
> >> camera
> >> +  sensor interface port of CSI
> >> +
> >> +example:
> >> +
> >> +capture-subsystem {
> >
> > What's the purpose of this node, if you only refer to another 
> > device? This one rather does not look like a real device at all.
> >
> >> +  compatible = "fsl,imx7-capture-subsystem";
> >> +  ports = <>;
> >> +};
> >> +
> >> +
> >> +mipi_csi2 node
> >> +--
> >> +
> >> +This is the device node for the MIPI CSI-2 receiver core in 
> >> i.MX7 SoC. It is
> >> +compatible with previous version of Samsung D-phy.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: "fsl,imx7-mipi-csi2";
> >> +- reg   : base address and length of the register set 
> >> for the device;
> >> +- interrupts: should contain MIPI CSIS interrupt;
> >> +- clocks: list of clock specifiers, see
> >> + 
> >> Documentation/devicetree/bindings/clock/clock-bindings.txt for 
> >> details;
> >> +- clock-names   : must contain "pclk", "wrap" and "phy" 
> >> entries, matching
> >> +  entries in the clock property;
> >> +- power-domains : a phandle to the power domain, see
> >> + 
> >> Documentation/devicetree/bindings/power/power_domain.txt for 
> >> details.
> >> +- reset-names   : should include following entry "mrst";
> >> +- resets: a list of phandle, should contain reset 
> >> entry of
> >> +  reset-names;
> >> +- phy-supply: from the generic phy bindings, a phandle to 
> >> a regulator that
> >> +provides power to MIPI CSIS core;
> >> +- bus-width : maximum number of data lanes supported (SoC 
> >> specific);
> >> +
> >> +Optional properties:
> >> +
> >> +- clock-frequency : The IP's main (system bus) clock frequency 
> >> in Hz, default
> >> +  value when this property is not specified is 
> >> 166 MHz;
> >> +
> >> +port node
> >> +-
> >> +
> >> +- reg   : (required) can take the values 0 or 1, 
> >> where 0 is the
> >> +     related sink port and port 1 should be 
> >> the source one;
> >> +
> >> +endpoint node
> >> +-
> >> +
> >> +- data-lanes: (required) an array specifying active 
> >> physical MIPI-CSI2
> >> +  data input lanes and their mapping to logical 
> >> lanes; the
> >> +  array's content is unused, only its length is 
> >> meaningful;
> >> +
> >> +- fsl,csis-hs-settle : (optional) differential receiver 
> >> (HS-RX) settle time;
> >
> > Could you calculate this, as other drivers do? It probably 
> > changes
> > depending on the device runtime configuration.
> 
> The only reference to possible values to this parameter is given 
> by table in [0], can you point me out the formula for imx7 in the
> documentation?
> 
> [0] https://community.nxp.com/thread/463777

Can't you use the values from that table ? :-) You can get the link
speed by querying the connected subdev and reading its
V4L2_CID_PIXEL_RATE control.

-- 
Regards,

Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: media: omap4iss: Added SPDX license identifiers

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Monday, 25 June 2018 16:21:32 EEST Daniel Graefe wrote:
> Added missing SPDX license identifiers to all files of the omap4iss
> driver.
> 
> Most files already have license texts which clearly state them to be
> licensed under GPL 2.0 or later. SPDX identifiers were added accordingly.
> 
> Some files do not have any license text. SPDX identifiers for GPL 2.0
> were added to them, in accordance with the default license of the
> kernel.
> 
> Signed-off-by: Daniel Graefe 
> Signed-off-by: Roman Sommer 
> ---
>  drivers/staging/media/omap4iss/Kconfig   | 2 ++
>  drivers/staging/media/omap4iss/Makefile  | 3 +++
>  drivers/staging/media/omap4iss/iss.c | 1 +
>  drivers/staging/media/omap4iss/iss.h | 1 +
>  drivers/staging/media/omap4iss/iss_csi2.c| 1 +
>  drivers/staging/media/omap4iss/iss_csi2.h| 1 +
>  drivers/staging/media/omap4iss/iss_csiphy.c  | 1 +
>  drivers/staging/media/omap4iss/iss_csiphy.h  | 1 +
>  drivers/staging/media/omap4iss/iss_ipipe.c   | 1 +
>  drivers/staging/media/omap4iss/iss_ipipe.h   | 1 +
>  drivers/staging/media/omap4iss/iss_ipipeif.c | 1 +
>  drivers/staging/media/omap4iss/iss_ipipeif.h | 1 +
>  drivers/staging/media/omap4iss/iss_regs.h| 1 +
>  drivers/staging/media/omap4iss/iss_resizer.c | 1 +
>  drivers/staging/media/omap4iss/iss_resizer.h | 1 +
>  drivers/staging/media/omap4iss/iss_video.c   | 1 +
>  drivers/staging/media/omap4iss/iss_video.h   | 1 +
>  17 files changed, 20 insertions(+)
> 
> diff --git a/drivers/staging/media/omap4iss/Kconfig
> b/drivers/staging/media/omap4iss/Kconfig index 273..841cc0b 100644
> --- a/drivers/staging/media/omap4iss/Kconfig
> +++ b/drivers/staging/media/omap4iss/Kconfig
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>  config VIDEO_OMAP4
>   tristate "OMAP 4 Camera support"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
> diff --git a/drivers/staging/media/omap4iss/Makefile
> b/drivers/staging/media/omap4iss/Makefile index a716ce9..e64d489 100644
> --- a/drivers/staging/media/omap4iss/Makefile
> +++ b/drivers/staging/media/omap4iss/Makefile
> @@ -1,4 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
>  # Makefile for OMAP4 ISS driver
> +#
> 
>  omap4-iss-objs += \
>   iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o
> iss_video.o diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index b1036ba..0c41939 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later

The SPDX identifier used for "GPL v2.0 or later" in the kernel is GPL-2.0+, as 
documented in Documentation/process/license-rules.rst. I'm aware that that 
identifier has been deprecated by the FSF in favour of the GPL-2.0-or-later 
identifier, but until Documentation/process/license-rules.rst gets updated, 
please use GPL-2.0+.

>  /*
>   * TI OMAP4 ISS V4L2 Driver
>   *

Could you please remove the boilerplate license text, as it's not needed 
anymore ?

Those two comments apply to all the other files.

[snip$

-- 
Regards,

Laurent Pinchart



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

[Laurent Pinchart]

Hi Geert,

On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote:
> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
> > 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 on ARM and ARM64 in the near
> > future.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> 
> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> 
> How would you like to get this merged ?

Unless you would like to merge the whole series in one go, I'll take this in 
my tree as I have a conflicting patch I would like to submit for v4.18.

> > ---
> > 
> >  drivers/media/platform/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index f9235e8f8e962d2e..7ad4725f9d1f9627
> > 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -396,7 +396,7 @@ config VIDEO_SH_VEU
> >  config VIDEO_RENESAS_FDP1
> > tristate "Renesas Fine Display Processor"
> > depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> > -   depends on ARCH_SHMOBILE || COMPILE_TEST
> > +   depends on ARCH_RENESAS || COMPILE_TEST
> > depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
> > select VIDEOBUF2_DMA_CONTIG
> > select V4L2_MEM2MEM_DEV

-- 
Regards,

Laurent Pinchart



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
> 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 on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

How would you like to get this merged ?

> ---
>  drivers/media/platform/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f9235e8f8e962d2e..7ad4725f9d1f9627 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -396,7 +396,7 @@ config VIDEO_SH_VEU
>  config VIDEO_RENESAS_FDP1
>   tristate "Renesas Fine Display Processor"
>   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> - depends on ARCH_SHMOBILE || COMPILE_TEST
> + depends on ARCH_RENESAS || COMPILE_TEST
>   depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV

-- 
Regards,

Laurent Pinchart



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 17/19] media: omap4iss: make it build with COMPILE_TEST

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thursday, 5 April 2018 23:29:44 EEST Mauro Carvalho Chehab wrote:
> This driver compile as-is with COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

I don't have patches pending for the omap4iss driver, could you merge this 
patch as part of the whole series ?

> ---
>  drivers/staging/media/omap4iss/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/omap4iss/Kconfig
> b/drivers/staging/media/omap4iss/Kconfig index 46183464ee79..192ba0829128
> 100644
> --- a/drivers/staging/media/omap4iss/Kconfig
> +++ b/drivers/staging/media/omap4iss/Kconfig
> @@ -1,6 +1,7 @@
>  config VIDEO_OMAP4
>   tristate "OMAP 4 Camera support"
> - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
> + depends on ARCH_OMAP4 || COMPILE_TEST
>   depends on HAS_DMA
>   select MFD_SYSCON
>   select VIDEOBUF2_DMA_CONTIG


-- 
Regards,

Laurent Pinchart



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] [media] staging: media: davinci_vpfe: fix spelling mistake in variable

[Laurent Pinchart]

Hi Colin,

Thank you for the patch.

On Thursday 13 Jul 2017 23:34:16 Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> Trivial fix to spelling mistake, rename the function name
> resizer_configure_in_continious_mode to
> resizer_configure_in_continuous_mode and also remove an extraneous space.
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

> ---
>  drivers/staging/media/davinci_vpfe/dm365_resizer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> b/drivers/staging/media/davinci_vpfe/dm365_resizer.c index
> 857b0e847c5e..d751d590a894 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> @@ -480,7 +480,7 @@ resizer_configure_common_in_params(struct
> vpfe_resizer_device *resizer) return 0;
>  }
>  static int
> -resizer_configure_in_continious_mode(struct vpfe_resizer_device *resizer)
> +resizer_configure_in_continuous_mode(struct vpfe_resizer_device *resizer)
>  {
>   struct device *dev = resizer->crop_resizer.subdev.v4l2_dev->dev;
>   struct resizer_params *param = >config;
> @@ -1242,7 +1242,7 @@ static int resizer_do_hw_setup(struct
> vpfe_resizer_device *resizer) ipipeif_source == IPIPEIF_OUTPUT_RESIZER)
>   ret = resizer_configure_in_single_shot_mode(resizer);
>   else
> - ret =  resizer_configure_in_continious_mode(resizer);
> + ret = resizer_configure_in_continuous_mode(resizer);
>       if (ret)
>   return ret;
>   ret = config_rsz_hw(resizer, param);

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

[Laurent Pinchart]

Hi Daniel,

On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> > Most of the items have been taken care of by a clean up series. Remove
> > the completed items and add a few new ones.
> > 
> > Signed-off-by: Laura Abbott <labb...@redhat.com>
> > ---
> > 
> >  drivers/staging/android/TODO | 21 -
> >  1 file changed, 4 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..5f14247 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> > 
> > @@ -7,23 +7,10 @@ TODO:
> >  ion/
> > 
> > - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel
> > internal -   interface on top of dma-buf. flush_for_device needs to be
> > added to dma-buf -   first.
> > - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in
> > some -   vendor trees. Should be replaced with an ioctl on the dma-buf to
> > expose the -   begin/end_cpu_access hooks to userspace.
> > - - Clarify the tricks ion plays with explicitly managing coherency behind
> > the -   dma api's back (this is absolutely needed for high-perf gpu
> > drivers): Add an -   explicit coherency management mode to
> > flush_for_device to be used by drivers -   which want to manage caches
> > themselves and which indicates whether cpu caches -   need flushing.
> > - - With those removed there's probably no use for ION_IOC_IMPORT anymore
> > either -   since ion would just be the central allocator for shared
> > buffers. - - Add dt-binding to expose cma regions as ion heaps, with the
> > rule that any -   such cma regions must already be used by some device
> > for dma. I.e. ion only -   exposes existing cma regions and doesn't
> > reserve unecessarily memory when -   booting a system which doesn't use
> > ion.
> > + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This
> > would +   involve putting appropriate bindings in a memory node for Ion
> > to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> > + - Better test framework (integration with VGEM was suggested)
> 
> Found another one: Integrate the ion kernel-doc into
> Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.

If ion is a generic-purpose allocator, should its documentation really reside 
in Documentation/gpu/ ?

> There's a lot of api and overview stuff already around, would be great to
> make this more accessible.
> 
> But I wouldn't put this as a de-staging blocker, just an idea.
> 
> On the series: Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> 
> No full review since a bunch of stuff I'm not too familiar with, but I
> like where this is going.
> -Daniel
> 
> >  Please send patches to Greg Kroah-Hartman <g...@kroah.com> and Cc:
> >  Arve Hjønnevåg <a...@android.com> and Riley Andrews
> >  <riandr...@android.com>

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly

[Laurent Pinchart]

/* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
>   return 0;
> 
> -free_table:
> - kfree(info->table);
>  free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
>  err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
>   return -ENOMEM;
>  }
> 
>  static void ion_cma_free(struct ion_buffer *buffer)
>  {
>   struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> + struct page *pages = buffer->priv_virt;
> 
> - dev_dbg(dev, "Release buffer %p\n", buffer);
>   /* release memory */
> - dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
> + cma_release(cma_heap->cma, pages, buffer->size);
>   /* release sg table */
> - sg_free_table(info->table);
> - kfree(info->table);
> - kfree(info);
> -}
> -
> -static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
> - struct vm_area_struct *vma)
> -{
> - struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> -
> - return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
> -  buffer->size);
> -}
> -
> -static void *ion_cma_map_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> - /* kernel memory mapping has been done at allocation time */
> - return info->cpu_addr;
> -}
> -
> -static void ion_cma_unmap_kernel(struct ion_heap *heap,
> -  struct ion_buffer *buffer)
> -{
> + sg_free_table(buffer->sg_table);
> + kfree(buffer->sg_table);
>  }
> 
>  static struct ion_heap_ops ion_cma_ops = {
>   .allocate = ion_cma_allocate,
>   .free = ion_cma_free,
> - .map_user = ion_cma_mmap,
> - .map_kernel = ion_cma_map_kernel,
> - .unmap_kernel = ion_cma_unmap_kernel,
> + .map_user = ion_heap_map_user,
> + .map_kernel = ion_heap_map_kernel,
> + .unmap_kernel = ion_heap_unmap_kernel,
>  };
> 
>  struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
> @@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct
> ion_platform_heap *data) * get device from private heaps data, later it
> will be
>* used to make the link with reserved CMA memory
>*/
> - cma_heap->dev = data->priv;
> + cma_heap->cma = data->priv;
>   cma_heap->heap.type = ION_HEAP_TYPE_DMA;
>   return _heap->heap;
>  }

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: media: omap4iss: Replace a bit shift by a use of BIT.

[Laurent Pinchart]

Hi Arushi,

Thank you for the patch.

On Friday 24 Mar 2017 21:31:45 Arushi Singhal wrote:
> This patch replaces bit shifting on 1 with the BIT(x) macro.
> This was done with coccinelle:
> @@
> constant c;
> @@
> 
> -1 << c
> +BIT(c)
> 
> Signed-off-by: Arushi Singhal <arushisinghal19971...@gmail.com>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

Greg, as this is a staging driver, do you want to merge the patch through your 
tree ?

> ---
> changes in v2
>  -Remove unnecessary parenthesis
> 
>  drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
>  drivers/staging/media/omap4iss/iss_ipipe.c   | 2 +-
>  drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
>  drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_csi2.c
> b/drivers/staging/media/omap4iss/iss_csi2.c index
> f71d5f2f179f..f6acc541e8a2 100644
> --- a/drivers/staging/media/omap4iss/iss_csi2.c
> +++ b/drivers/staging/media/omap4iss/iss_csi2.c
> @@ -1268,7 +1268,7 @@ static int csi2_init_entities(struct iss_csi2_device
> *csi2, const char *subname) snprintf(name, sizeof(name), "CSI2%s",
> subname);
>   snprintf(sd->name, sizeof(sd->name), "OMAP4 ISS %s", name);
> 
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, csi2);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 
> diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c
> b/drivers/staging/media/omap4iss/iss_ipipe.c index
> d38782e8e84c..d86ef8a031f2 100644
> --- a/drivers/staging/media/omap4iss/iss_ipipe.c
> +++ b/drivers/staging/media/omap4iss/iss_ipipe.c
> @@ -508,7 +508,7 @@ static int ipipe_init_entities(struct iss_ipipe_device
> *ipipe) v4l2_subdev_init(sd, _v4l2_ops);
>   sd->internal_ops = _v4l2_internal_ops;
>   strlcpy(sd->name, "OMAP4 ISS ISP IPIPE", sizeof(sd->name));
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, ipipe);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 
> diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c
> b/drivers/staging/media/omap4iss/iss_ipipeif.c index
> 23de8330731d..cb88b2bd0d82 100644
> --- a/drivers/staging/media/omap4iss/iss_ipipeif.c
> +++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
> @@ -739,7 +739,7 @@ static int ipipeif_init_entities(struct
> iss_ipipeif_device *ipipeif) v4l2_subdev_init(sd, _v4l2_ops);
>   sd->internal_ops = _v4l2_internal_ops;
>   strlcpy(sd->name, "OMAP4 ISS ISP IPIPEIF", sizeof(sd->name));
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, ipipeif);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 
> diff --git a/drivers/staging/media/omap4iss/iss_resizer.c
> b/drivers/staging/media/omap4iss/iss_resizer.c index
> f1d352c711d5..4bbfa20b3c38 100644
> --- a/drivers/staging/media/omap4iss/iss_resizer.c
> +++ b/drivers/staging/media/omap4iss/iss_resizer.c
> @@ -782,7 +782,7 @@ static int resizer_init_entities(struct
> iss_resizer_device *resizer) v4l2_subdev_init(sd, _v4l2_ops);
>   sd->internal_ops = _v4l2_internal_ops;
>   strlcpy(sd->name, "OMAP4 ISS ISP resizer", sizeof(sd->name));
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, resizer);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Laurent Pinchart]

Hi Hans,

On Tuesday 14 Mar 2017 08:55:36 Hans Verkuil wrote:
> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> > 
> > I started preparing a long argument about it, but gave up in favor of a
> > simpler one.
> > 
> > Em Mon, 13 Mar 2017 14:46:22 +0200 Sakari Ailus escreveu:
> >> Drivers are written to support hardware, not particular use case.
> > 
> > No, it is just the reverse: drivers and hardware are developed to
> > support use cases.
> > 
> > Btw, you should remember that the hardware is the full board, not just the
> > SoC. In practice, the board do limit the use cases: several provide a
> > single physical CSI connector, allowing just one sensor.
> > 
> >>> This situation is there since 2009. If I remember well, you tried to
> >>> write such generic plugin in the past, but never finished it, apparently
> >>> because it is too complex. Others tried too over the years.
> >> 
> >> I'd argue I know better what happened with that attempt than you do. I
> >> had a prototype of a generic pipeline configuration library but due to
> >> various reasons I haven't been able to continue working on that since
> >> around 2012.
> > ...
> > 
> >>> The last trial was done by Jacek, trying to cover just the exynos4
> >>> driver. Yet, even such limited scope plugin was not good enough, as it
> >>> was never merged upstream. Currently, there's no such plugins upstream.
> >>> 
> >>> If we can't even merge a plugin that solves it for just *one* driver,
> >>> I have no hope that we'll be able to do it for the generic case.
> >> 
> >> I believe Jacek ceased to work on that plugin in his day job; other than
> >> that, there are some matters left to be addressed in his latest patchset.
> > 
> > The two above basically summaries the issue: the task of doing a generic
> > plugin on userspace, even for a single driver is complex enough to
> > not cover within a reasonable timeline.
> > 
> > From 2009 to 2012, you were working on it, but didn't finish it.
> > 
> > Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
> > I didn't check when the generic plugin interface was added to libv4l).
> > 
> > In the case of Jacek's work, the first patch I was able to find was
> > 
> > written in Oct, 2014:
> > https://patchwork.kernel.org/patch/5098111/
> > (not sure what happened with the version 1).
> > 
> > The last e-mail about this subject was issued in Dec, 2016.
> > 
> > In summary, you had this on your task for 3 years for an OMAP3
> > plugin (where you have a good expertise), and Jacek for 2 years,
> > for Exynos 4, where he should also have a good knowledge.
> > 
> > Yet, with all that efforts, no concrete results were achieved, as none
> > of the plugins got merged.
> > 
> > Even if they were merged, if we keep the same mean time to develop a
> > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > years to be developed.
> > 
> > There's a clear message on it:
> > - we shouldn't keep pushing for a solution via libv4l.
> 
> Or:
>   - userspace plugin development had a very a low priority and
> never got the attention it needed.
>
> I know that's *my* reason. I rarely if ever looked at it. I always assumed
> Sakari and/or Laurent would look at it. If this reason is also valid for
> Sakari and Laurent, then it is no wonder nothing has happened in all that
> time.

The reason is also valid for me. I'd really love to work on the userspace 
side, but I just can't find time at the moment.

> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it because of fundamental design defects, or because nobody paid attention
> to it?
> 
> I strongly suspect it is the latter.
> 
> In addition, I suspect end-users of these complex devices don't really care
> about a plugin: they want full control and won't typically use generic
> applications. If they would need support for that, we'd have seen much more
> interest. The main reason for having a plugin is to simplify testing and
> if this is going to be used on cheap hobbyist devkits.
> 
> An additional complication is simply that it is hard to find fully supported
> MC hardware. omap3 boards are hard to find these days, renesas boards are
> not easy to get, freescale isn't the most popular either. Allwinner,
> mediatek, amlogic, broadcom and qualcomm all have closed source
> implementations or no implementation at all.
> 
> I know it took me a very long time before I had a working omap3.
> 
> So I am not at all surprised that little progress has been made.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Laurent Pinchart]

Hi Pavel,

On Tuesday 14 Mar 2017 19:26:35 Pavel Machek wrote:
> Hi!
> 
> >> Mid-layer is difficult... there are _hundreds_ of possible
> >> pipeline setups. If it should live in kernel or in userspace is a
> >> question... but I don't think having it in kernel helps in any way.
> > 
> > Mid-layer is difficult, because we either need to feed some
> > library with knowledge for all kernel drivers or we need to improve
> > the MC API to provide more details.
> > 
> > For example, several drivers used to expose entities via the
> > generic MEDIA_ENT_T_DEVNODE to represent entities of different
> > 
> > types. See, for example, entities 1, 5 and 7 (and others) at:
> > > https://mchehab.fedorapeople.org/mc-next-gen/igepv2_omap3isp.png
> 
> Well... we provide enough information, so that device-specific code
> does not have to be in kernel.
> 
> There are few types of ENT_T_DEVNODE there. "ISP CCP2" does not really
> provide any functionality to the user. It just has to be there,
> because the pipeline needs to be connected. "ISP Preview" provides
> format conversion. "ISP Resizer" provides rescaling.
> 
> I'm not sure if it ever makes sense to use "ISP Preview
> output". Normally you take data for display from "ISP Resizer
> output". (Would there be some power advantage from that?)

There was a bug on the preview engine to resizer hardware bus in OMAP34xx that 
required capturing data from the preview engine output and performing the 
scaling in memory-to-memory mode in some cases. You can also capture at the 
preview engine output if you don't need scaling, or if you want to render on 
the image before scaling (to draw pieces of a GUI for instance). There could 
be other use cases.

> > A device-specific code could either be hardcoding the entity number
> > or checking for the entity strings to add some logic to setup
> > controls on those "unknown" entities, a generic app won't be able
> > to do anything with them, as it doesn't know what function(s) such
> > entity provide.
> 
> Generic app should know if it wants RGGB10 data, then it can use "ISP
> CCDC output", or if it wants "cooked" data suitable for display, then
> it wants to use "ISP Resizer output". Once application knows what
> output it wants, there's just one path through the system. So being
> able to tell the ENT_T_DEVNODEs apart does not seem to be critical.
> 
> OTOH, for useful camera application, different paths are needed at
> different phases.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

Hi Daniel,

On Monday 06 Mar 2017 11:38:20 Daniel Vetter wrote:
> On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote:
> > - I haven't seen any proposal how a heap-based solution could be used in a
> > generic distribution. This needs to be figured out before committing to
> > any API/ABI.
> 
> Two replies from my side:
> 
> - Just because a patch doesn't solve world hunger isn't really a good
>   reason to reject it.

As long as it goes in the right direction, sure :-) The points I mentioned 
were to be interpreted that way, I want to make sure we're not going in a 
dead-end (or worse, driving full speed into a wall).

> - Heap doesn't mean its not resizeable (but I'm not sure that's really
>   your concern).

Not really, no. Heap is another word to mean pool here. It might not be the 
best term in this context as it has a precise meaning in the context of memory 
allocation, but that's a detail.

> - Imo ION is very much part of the picture here to solve this for real. We
>   need to bits:
> 
>   * Be able to allocate memory from specific pools, not going through a
> specific driver. ION gives us that interface. This is e.g. also needed
> for "special" memory, like SMA tries to expose.
> 
>   * Some way to figure out how to allocate the buffer object. This
> is purely a userspace problem, and this is the part the unix memory
> allocator tries to solve. There's no plans in there for big kernel
> changes, instead userspace does a dance to reconcile all the
> constraints, and one of the constraints might be "you have to allocate
> this from this special ION heap". The only thing the kernel needs to
> expose is which devices use which ION heaps (we kinda do that
> already), and maybe some hints of how they can be generalized (but I
> guess stuff like "minimal pagesize of x KB" is also fulfilled by any
> CMA heap is knowledge userspace needs).

The constraint solver could live in userspace, I'm open to a solution that 
would go in that direction, but it will require help from the kernel to fetch 
the constraints from the devices that need to be involved in buffer sharing.

Given a userspace constraint resolver, the interface with the kernel allocator 
will likely be based on pools. I'm not opposed to that, as long as pool are 
identified by opaque handles. I don't want userspace to know about the meaning 
of any particular ION heap. Application must not attempt to "allocate from 
CMA" for instance, that would lock us to a crazy API that will grow completely 
out of hands as vendors will start adding all kind of custom heaps, and 
applications will have to follow (or will be patched out-of-tree by vendors).

> Again I think waiting for this to be fully implemented before we merge any
> part is going to just kill any upstreaming efforts. ION in itself, without
> the full buffer negotiation dance seems clearly useful (also for stuff
> like SMA), and having it merged will help with moving the buffer
> allocation dance forward.

Again I'm not opposed to a kernel allocator based on pools/heaps, as long as

- pools/heaps stay internal to the kernel and are not directly exposed to 
userspace

- a reasonable way to size the different kinds of pools in a generic 
distribution kernel can be found

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laurent Pinchart]

Hi Daniel,

On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote:
> On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
> > On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> >>> When CMA was first introduced, its primary use was for DMA allocation
> >>> and the only way to get CMA memory was to call dma_alloc_coherent. This
> >>> put Ion in an awkward position since there was no device structure
> >>> readily available and setting one up messed up the coherency model.
> >>> These days, CMA can be allocated directly from the APIs. Switch to
> >>> using this model to avoid needing a dummy device. This also avoids
> >>> awkward caching questions.
> >> 
> >> If the DMA mapping API isn't suitable for today's requirements anymore,
> >> I believe that's what needs to be fixed, instead of working around the
> >> problem by introducing another use-case-specific API.
> > 
> > I don't think this is a usecase specific API. CMA has been decoupled from
> > DMA already because it's used in other places. The trying to go through
> > DMA was just another layer of abstraction, especially since there isn't
> > a device available for allocation.
> 
> Also, we've had separation of allocation and dma-mapping since forever,
> that's how it works almost everywhere. Not exactly sure why/how arm-soc
> ecosystem ended up focused so much on dma_alloc_coherent.

I believe because that was the easy way to specify memory constraints. The API 
receives a device pointer and will allocate memory suitable for DMA for that 
device. The fact that it maps it to the device is a side-effect in my opinion.

> I think separating allocation from dma mapping/coherency is perfectly
> fine, and the way to go.

Especially given that in many cases we'll want to share buffers between 
multiple devices, so we'll need to map them multiple times.

My point still stands though, if we want to move towards a model where 
allocation and mapping are decoupled, we need an allocation function that 
takes constraints (possibly implemented with two layers, a constraint 
resolution layer on top of a pool/heap/type/foo-based allocator), and a 
mapping API. IOMMU handling being integrated in the DMA mapping API we're 
currently stuck with it, which might call for brushing up that API.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

-
> >  drivers/staging/android/ion/ion_enumerate.c|  89 +++
> >  drivers/staging/android/ion/ion_of.c   | 184 --
> >  drivers/staging/android/ion/ion_of.h   |  37 ---
> >  drivers/staging/android/ion/ion_page_pool.c|   3 -
> >  drivers/staging/android/ion/ion_priv.h |  57 -
> >  drivers/staging/android/ion/ion_system_heap.c  |  14 +-
> >  drivers/staging/android/ion/tegra/Makefile |   1 -
> >  drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
> >  include/linux/cma.h|   6 +-
> >  mm/cma.c   |  25 +-
> >  mm/cma.h   |   1 +
> >  mm/cma_debug.c |   2 +-
> >  25 files changed, 312 insertions(+), 958 deletions(-)
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
> >  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
> >  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
> >  delete mode 100644 drivers/staging/android/ion/ion_of.c
> >  delete mode 100644 drivers/staging/android/ion/ion_of.h
> >  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
> >  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laurent Pinchart]

struct vm_area_struct *vma)
> -{
> - struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> -
> - return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
> -  buffer->size);
> -}
> -
> -static void *ion_cma_map_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> - /* kernel memory mapping has been done at allocation time */
> - return info->cpu_addr;
> -}
> -
> -static void ion_cma_unmap_kernel(struct ion_heap *heap,
> -  struct ion_buffer *buffer)
> -{
> + sg_free_table(buffer->sg_table);
> + kfree(buffer->sg_table);
>  }
> 
>  static struct ion_heap_ops ion_cma_ops = {
>   .allocate = ion_cma_allocate,
>   .free = ion_cma_free,
> - .map_user = ion_cma_mmap,
> - .map_kernel = ion_cma_map_kernel,
> - .unmap_kernel = ion_cma_unmap_kernel,
> + .map_user = ion_heap_map_user,
> + .map_kernel = ion_heap_map_kernel,
> + .unmap_kernel = ion_heap_unmap_kernel,
>  };
> 
>  struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
> @@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct
> ion_platform_heap *data) * get device from private heaps data, later it
> will be
>* used to make the link with reserved CMA memory
>*/
> - cma_heap->dev = data->priv;
> + cma_heap->cma = data->priv;
>   cma_heap->heap.type = ION_HEAP_TYPE_DMA;
>   return _heap->heap;
>  }

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laurent Pinchart]

,
> > -  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
> > -   dma_buf_put(dmabuf);
> > -   return 0;
> > -}
> > -
> > 
> >  int ion_query_heaps(struct ion_client *client, struct ion_heap_query
> >  *query) {
> >  
> > struct ion_device *dev = client->dev;
> > 
> > diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
> > b/drivers/staging/android/ion/ion_carveout_heap.c index 9bf8e98..e0e360f
> > 100644
> > --- a/drivers/staging/android/ion/ion_carveout_heap.c
> > +++ b/drivers/staging/android/ion/ion_carveout_heap.c
> > @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer
> > *buffer)> 
> > ion_heap_buffer_zero(buffer);
> > 
> > -   if (ion_buffer_cached(buffer))
> > -   dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> > -  DMA_BIDIRECTIONAL);
> > -
> > 
> > ion_carveout_free(heap, paddr, buffer->size);
> > sg_free_table(table);
> > kfree(table);
> > 
> > @@ -128,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct
> > ion_platform_heap *heap_data)> 
> > page = pfn_to_page(PFN_DOWN(heap_data->base));
> > size = heap_data->size;
> > 
> > -   ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
> > -
> > 
> > ret = ion_heap_pages_zero(page, size, 
pgprot_writecombine(PAGE_KERNEL));
> > if (ret)
> > 
> > return ERR_PTR(ret);
> > 
> > diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
> > b/drivers/staging/android/ion/ion_chunk_heap.c index 8c41889..46e13f6
> > 100644
> > --- a/drivers/staging/android/ion/ion_chunk_heap.c
> > +++ b/drivers/staging/android/ion/ion_chunk_heap.c
> > @@ -101,10 +101,6 @@ static void ion_chunk_heap_free(struct ion_buffer
> > *buffer)> 
> > ion_heap_buffer_zero(buffer);
> > 
> > -   if (ion_buffer_cached(buffer))
> > -   dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> > -  DMA_BIDIRECTIONAL);
> > -
> > 
> > for_each_sg(table->sgl, sg, table->nents, i) {
> > 
> > gen_pool_free(chunk_heap->pool, page_to_phys(sg_page(sg)),
> > 
> >   sg->length);
> > 
> > @@ -132,8 +128,6 @@ struct ion_heap *ion_chunk_heap_create(struct
> > ion_platform_heap *heap_data)> 
> > page = pfn_to_page(PFN_DOWN(heap_data->base));
> > size = heap_data->size;
> > 
> > -   ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
> > -
> > 
> > ret = ion_heap_pages_zero(page, size, 
pgprot_writecombine(PAGE_KERNEL));
> > if (ret)
> > 
> > return ERR_PTR(ret);
> > 
> > diff --git a/drivers/staging/android/ion/ion_page_pool.c
> > b/drivers/staging/android/ion/ion_page_pool.c index aea89c1..532eda7
> > 100644
> > --- a/drivers/staging/android/ion/ion_page_pool.c
> > +++ b/drivers/staging/android/ion/ion_page_pool.c
> > @@ -30,9 +30,6 @@ static void *ion_page_pool_alloc_pages(struct
> > ion_page_pool *pool)> 
> > if (!page)
> > 
> > return NULL;
> > 
> > -   if (!pool->cached)
> > -   ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool-
>order,
> > - DMA_BIDIRECTIONAL);
> > 
> > return page;
> >  
> >  }
> > 
> > diff --git a/drivers/staging/android/ion/ion_system_heap.c
> > b/drivers/staging/android/ion/ion_system_heap.c index 6cb2fe7..a1b
> > 100644
> > --- a/drivers/staging/android/ion/ion_system_heap.c
> > +++ b/drivers/staging/android/ion/ion_system_heap.c
> > @@ -75,9 +75,6 @@ static struct page *alloc_buffer_page(struct
> > ion_system_heap *heap,> 
> > page = ion_page_pool_alloc(pool);
> > 
> > -   if (cached)
> > -   ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
> > - DMA_BIDIRECTIONAL);
> > 
> > return page;
> >  
> >  }
> > 
> > @@ -401,8 +398,6 @@ static int ion_system_contig_heap_allocate(struct
> > ion_heap *heap,> 
> > buffer->sg_table = table;
> > 
> > -   ion_pages_sync_for_device(NULL, page, len, DMA_BIDIRECTIONAL);
> > -
> > 
> > return 0;
> >  
> >  free_table:

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laurent Pinchart]

->map_kernel) {
> + mutex_lock(>lock);
> + vaddr = ion_buffer_kmap_get(buffer);
> + mutex_unlock(>lock);
>   }
> 
> - mutex_lock(>lock);
> - vaddr = ion_buffer_kmap_get(buffer);
> - mutex_unlock(>lock);
> - return PTR_ERR_OR_ZERO(vaddr);
> + /*
> +  * Close enough right now? Flag to skip sync?
> +  */
> + if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
> + buffer->sg_table->nents,
> +DMA_BIDIRECTIONAL))

Aren't the dma_(un)map_* calls supposed to take a real, physical device as 
their first argument ? Beside, this doesn't seem to be the right place to 
create the mapping, as you mentioned in the commit message the buffer should 
be mapped in the dma_buf map handler. This is something that needs to be 
fixed, especially in the light of the comment in ion_buffer_create():

/*
 * this will set up dma addresses for the sglist -- it is not
 * technically correct as per the dma api -- a specific
 * device isn't really taking ownership here.  However, in practice on
 * our systems the only dma_address space is physical addresses.
 * Additionally, we can't afford the overhead of invalidating every
 * allocation via dma_map_sg. The implicit contract here is that
 * memory coming from the heaps is ready for dma, ie if it has a
 * cached mapping that mapping has been invalidated
 */

That's a showstopper in my opinion, the DMA address space can't be restricted 
to physical addresses, IOMMU have to be supported.

> + return -ENOMEM;
> +
> + return 0;
>  }
> 
>  static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> @@ -1031,9 +1024,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf
> *dmabuf, {
>   struct ion_buffer *buffer = dmabuf->priv;
> 
> - mutex_lock(>lock);
> - ion_buffer_kmap_put(buffer);
> - mutex_unlock(>lock);
> + if (buffer->heap->ops->map_kernel) {
> + mutex_lock(>lock);
> + ion_buffer_kmap_put(buffer);
> + mutex_unlock(>lock);
> + }
> +
> + dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
> + buffer->sg_table->nents,
> + DMA_BIDIRECTIONAL);
> 
>   return 0;
>  }

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

aging/android/ion/ion_enumerate.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.h
>  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 1/2] staging: omap4iss: fix multiline comment style

[Laurent Pinchart]

Hi Avraham,

Thank you for the patches.

On Thursday 09 Feb 2017 18:57:55 Avraham Shukron wrote:
> Fixed multi-line comments to their preferred style (First line empty)
> 
> Signed-off-by: Avraham Shukron <avraham.shuk...@gmail.com>

For both of them,

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

I've applied the patches to my tree and will send a pull request for v4.12.

> ---
>  drivers/staging/media/omap4iss/iss_video.c | 38 ++-
>  1 file changed, 25 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index bb0e3b4..e21811a 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -128,7 +128,8 @@ static unsigned int iss_video_mbus_to_pix(const struct
> iss_video *video, pix->width = mbus->width;
>   pix->height = mbus->height;
> 
> - /* Skip the last format in the loop so that it will be selected if no
> + /*
> +  * Skip the last format in the loop so that it will be selected if no
>* match is found.
>*/
>   for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
> @@ -138,7 +139,8 @@ static unsigned int iss_video_mbus_to_pix(const struct
> iss_video *video,
> 
>   min_bpl = pix->width * ALIGN(formats[i].bpp, 8) / 8;
> 
> - /* Clamp the requested bytes per line value. If the maximum bytes per
> + /*
> +  * Clamp the requested bytes per line value. If the maximum bytes per
>* line value is zero, the module doesn't support user configurable 
line
>* sizes. Override the requested value with the minimum in that case.
>*/
> @@ -172,7 +174,8 @@ static void iss_video_pix_to_mbus(const struct
> v4l2_pix_format *pix, mbus->width = pix->width;
>   mbus->height = pix->height;
> 
> - /* Skip the last format in the loop so that it will be selected if no
> + /*
> +  * Skip the last format in the loop so that it will be selected if no
>* match is found.
>*/
>   for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
> @@ -360,7 +363,8 @@ static void iss_video_buf_queue(struct vb2_buffer *vb)
> 
>   spin_lock_irqsave(>qlock, flags);
> 
> - /* Mark the buffer is faulty and give it back to the queue immediately
> + /*
> +  * Mark the buffer is faulty and give it back to the queue immediately
>* if the video node has registered an error. vb2 will perform the 
same
>* check when preparing the buffer, but that is inherently racy, so we
>* need to handle the race condition with an authoritative check here.
> @@ -443,7 +447,8 @@ struct iss_buffer *omap4iss_video_buffer_next(struct
> iss_video *video)
> 
>   buf->vb.vb2_buf.timestamp = ktime_get_ns();
> 
> - /* Do frame number propagation only if this is the output video node.
> + /*
> +  * Do frame number propagation only if this is the output video node.
>* Frame number either comes from the CSI receivers or it gets
>* incremented here if H3A is not active.
>* Note: There is no guarantee that the output buffer will finish
> @@ -605,7 +610,8 @@ iss_video_set_format(struct file *file, void *fh, struct
> v4l2_format *format)
> 
>   mutex_lock(>mutex);
> 
> - /* Fill the bytesperline and sizeimage fields by converting to media 
bus
> + /*
> +  * Fill the bytesperline and sizeimage fields by converting to media 
bus
>* format and back to pixel format.
>*/
>   iss_video_pix_to_mbus(>fmt.pix, );
> @@ -678,8 +684,9 @@ iss_video_get_selection(struct file *file, void *fh,
> struct v4l2_selection *sel) if (subdev == NULL)
>   return -EINVAL;
> 
> - /* Try the get selection operation first and fallback to get format if 
not
> -  * implemented.
> + /*
> +  * Try the get selection operation first and fallback to get format if
> +  * not implemented.
>*/
>   sdsel.pad = pad;
>   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
> @@ -867,7 +874,8 @@ iss_video_streamon(struct file *file, void *fh, enum
> v4l2_buf_type type)
> 
>   mutex_lock(>stream_lock);
> 
> - /* Start streaming on the pipeline. No link touching an entity in the
> + /*
> +  * Start streaming on the pipeline. No link touching an entity in the
>* pipeline can be activated or deactivated once streaming is started.
>*/
>   pipe = entity->pipe
> @@ -895,7 +903,8 @@ iss_video_streamon(struct file *file, void *fh, enum
> v4l2_buf_type type) while ((entity = media_graph_walk_next()))
&

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Laurent Pinchart]

" posted by Pavel Machek recently. The problem with that is also
> > similar than with this one: how to pass the CSI-2 bus configuration to the
> > receiver.
> > 
> > There's some discussion here:
> > 
> > <URL:http://www.spinics.net/lists/linux-media/msg109493.html>
> 
> [Added Sebastian do Cc:]
> 
> Yes, this is essentially the same driver, except that this driver also
> handles MMIO-bitfield controlled muxes, and that the actual physical bus
> (which the drivers currently don't care about) is MIPI CSI-2 in the
> other case, and parallel this one.
> They should probably be combined, or maybe split into two separate
> drivers (MMIO controlled mux, GPIO controlled switch), possibly using
> the same v4l2_subdev boilerplate.

I'd split the bindings in two with two separate compat strings, but we can 
handle both in a single driver as most of the code would be identical 
otherwise.

> > As Laurent already suggested, I think we should have a common solution for
> > the problem that, besides conveying the bus parameters to the receiver,
> > also encompasses CSI-2 virtual channels and data types.
> 
> Yes, that seems to be necessary, as certainly we can't configure the mux
> output bus parameters in DT to a fixed setting.
> 
> > That would mean finishing the series of patches in the branch I believe
> > Laurent already quoted here.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Laurent Pinchart]

Hi Benoit,

On Tuesday 07 Feb 2017 07:36:48 Benoit Parrot wrote:
> Laurent Pinchart wrote on Tue [2017-Feb-07 12:26:32 +0200]:
> > On Monday 06 Feb 2017 15:10:46 Steve Longerbeam wrote:
> >> On 02/06/2017 02:33 PM, Laurent Pinchart wrote:
> >>> On Monday 06 Feb 2017 10:50:22 Hans Verkuil wrote:
> >>>> On 02/05/2017 04:48 PM, Laurent Pinchart wrote:
> >>>>> On Tuesday 24 Jan 2017 18:07:55 Steve Longerbeam wrote:
> >>>>>> On 01/24/2017 04:02 AM, Philipp Zabel wrote:
> >>>>>>> On Fri, 2017-01-20 at 15:03 +0100, Hans Verkuil wrote:
> >>>>>>>>> +
> >>>>>>>>> +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct
> >>>>>>>>> v4l2_mbus_config *cfg)
> > 
> > [snip]
> > 
> >>>>>>>> I am not certain this op is needed at all. In the current kernel
> >>>>>>>> this op is only used by soc_camera, pxa_camera and omap3isp
> >>>>>>>> (somewhat dubious). Normally this information should come from the
> >>>>>>>> device tree and there should be no need for this op.
> >>>>>>>> 
> >>>>>>>> My (tentative) long-term plan was to get rid of this op.
> >>>>>>>> 
> >>>>>>>> If you don't need it, then I recommend it is removed.
> >>>>>> 
> >>>>>> Hi Hans, the imx-media driver was only calling g_mbus_config to the
> >>>>>> camera sensor, and it was doing that to determine the sensor's bus
> >>>>>> type. This info was already available from parsing a
> >>>>>> v4l2_of_endpoint from the sensor node. So it was simple to remove the
> >>>>>> g_mbus_config calls, and instead rely on the parsed sensor
> >>>>>> v4l2_of_endpoint.
> >>>>> 
> >>>>> That's not a good point.
> >>> 
> >>> (mea culpa, s/point/idea/)
> >>> 
> >>>>> The imx-media driver must not parse the sensor DT node as it is not
> >>>>> aware of what bindings the sensor is compatible with.
> >> 
> >> Hi Laurent,
> >> 
> >> I don't really understand this argument. The sensor node has been found
> >> by parsing the OF graph, so it is known to be a camera sensor node at
> >> that point.
> > 
> > All you know in the i.MX6 driver is that the remote node is a video
> > source. You can rely on the fact that it implements the OF graph bindings
> > to locate other ports in that DT node, but that's more or less it.
> > 
> > DT properties are defined by DT bindings and thus qualified by a
> > compatible string. Unless you match on sensor compat strings in the i.MX6
> > driver (which you shouldn't do, to keep the driver generic) you can't know
> > for certain how to parse the sensor node DT properties. For all you know,
> > the video source could be a bridge such as an HDMI to CSI-2 converter for
> > instance, so you can't even rely on the fact that it's a sensor.
> > 
> >>>>> Information must instead be queried from the sensor subdev at
> >>>>> runtime, through the g_mbus_config() operation.
> >>>>> 
> >>>>> Of course, if you can get the information from the imx-media DT
> >>>>> node, that's certainly an option. It's only information provided by
> >>>>> the sensor driver that you have no choice but query using a subdev
> >>>>> operation.
> >>>> 
> >>>> Shouldn't this come from the imx-media DT node? BTW, why is omap3isp
> >>>> using this?
> >>> 
> >>> It all depends on what type of information needs to be retrieved, and
> >>> whether it can change at runtime or is fixed. Adding properties to the
> >>> imx-media DT node is certainly fine as long as those properties
> >>> describe the i.MX side.
> >> 
> >> In this case the info needed is the media bus type. That info is most
> >> easily available by calling v4l2_of_parse_endpoint() on the sensor's
> >> endpoint node.
> > 
> > I haven't had time to check the code in details yet, so I can't really
> > comment on what you need and how it should be implemented exactly.
> > 
> >> The media bus type is not something that can be added to the
> >> imx-media node since it contains no endpoint nodes.
> > 
> > Agreed. You have endpoints in t

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Laurent Pinchart]

Hi Philipp,

On Tuesday 07 Feb 2017 11:41:30 Philipp Zabel wrote:
> On Tue, 2017-02-07 at 12:26 +0200, Laurent Pinchart wrote:
> > On Monday 06 Feb 2017 15:10:46 Steve Longerbeam wrote:
> >> On 02/06/2017 02:33 PM, Laurent Pinchart wrote:
> >>> On Monday 06 Feb 2017 10:50:22 Hans Verkuil wrote:
> >>>> On 02/05/2017 04:48 PM, Laurent Pinchart wrote:
> >>>>> On Tuesday 24 Jan 2017 18:07:55 Steve Longerbeam wrote:
> >>>>>> On 01/24/2017 04:02 AM, Philipp Zabel wrote:
> >>>>>>> On Fri, 2017-01-20 at 15:03 +0100, Hans Verkuil wrote:
> >>>>>>>>> +
> >>>>>>>>> +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct
> >>>>>>>>> v4l2_mbus_config *cfg)
> > 
> > [snip]
> > 
> >>>>>>>> I am not certain this op is needed at all. In the current kernel
> >>>>>>>> this op is only used by soc_camera, pxa_camera and omap3isp
> >>>>>>>> (somewhat dubious). Normally this information should come from the
> >>>>>>>> device tree and there should be no need for this op.
> >>>>>>>> 
> >>>>>>>> My (tentative) long-term plan was to get rid of this op.
> >>>>>>>> 
> >>>>>>>> If you don't need it, then I recommend it is removed.
> >>>>>> 
> >>>>>> Hi Hans, the imx-media driver was only calling g_mbus_config to the
> >>>>>> camera sensor, and it was doing that to determine the sensor's bus
> >>>>>> type. This info was already available from parsing a
> >>>>>> v4l2_of_endpoint from the sensor node. So it was simple to remove the
> >>>>>> g_mbus_config calls, and instead rely on the parsed sensor
> >>>>>> v4l2_of_endpoint.
> >>>>> 
> >>>>> That's not a good point.
> >>> 
> >>> (mea culpa, s/point/idea/)
> >>> 
> >>>>> The imx-media driver must not parse the sensor DT node as it is not
> >>>>> aware of what bindings the sensor is compatible with.
> >> 
> >> Hi Laurent,
> >> 
> >> I don't really understand this argument. The sensor node has been found
> >> by parsing the OF graph, so it is known to be a camera sensor node at
> >> that point.
> > 
> > All you know in the i.MX6 driver is that the remote node is a video
> > source. You can rely on the fact that it implements the OF graph bindings
> > to locate other ports in that DT node, but that's more or less it.
> > 
> > DT properties are defined by DT bindings and thus qualified by a
> > compatible string. Unless you match on sensor compat strings in the i.MX6
> > driver (which you shouldn't do, to keep the driver generic) you can't know
> > for certain how to parse the sensor node DT properties. For all you know,
> > the video source could be a bridge such as an HDMI to CSI-2 converter for
> > instance, so you can't even rely on the fact that it's a sensor.
> > 
> >>>>> Information must instead be queried from the sensor subdev at
> >>>>> runtime, through the g_mbus_config() operation.
> >>>>> 
> >>>>> Of course, if you can get the information from the imx-media DT
> >>>>> node, that's certainly an option. It's only information provided by
> >>>>> the sensor driver that you have no choice but query using a subdev
> >>>>> operation.
> >>>> 
> >>>> Shouldn't this come from the imx-media DT node? BTW, why is omap3isp
> >>>> using this?
> >>> 
> >>> It all depends on what type of information needs to be retrieved, and
> >>> whether it can change at runtime or is fixed. Adding properties to the
> >>> imx-media DT node is certainly fine as long as those properties
> >>> describe the i.MX side.
> >> 
> >> In this case the info needed is the media bus type. That info is most
> >> easily available by calling v4l2_of_parse_endpoint() on the sensor's
> >> endpoint node.
> > 
> > I haven't had time to check the code in details yet, so I can't really
> > comment on what you need and how it should be implemented exactly.
> > 
> >> The media bus type is not something that can be added to the
> >> imx-media node since it contains no endpoint nodes.
> > 
> > Agreed. You have endpoints in 

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Laurent Pinchart]

Hi Steve,

On Monday 06 Feb 2017 15:10:46 Steve Longerbeam wrote:
> On 02/06/2017 02:33 PM, Laurent Pinchart wrote:
> > On Monday 06 Feb 2017 10:50:22 Hans Verkuil wrote:
> >> On 02/05/2017 04:48 PM, Laurent Pinchart wrote:
> >>> On Tuesday 24 Jan 2017 18:07:55 Steve Longerbeam wrote:
> >>>> On 01/24/2017 04:02 AM, Philipp Zabel wrote:
> >>>>> On Fri, 2017-01-20 at 15:03 +0100, Hans Verkuil wrote:
> >>>>>>> +
> >>>>>>> +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct
> >>>>>>> v4l2_mbus_config *cfg)

[snip]

> >>>>>> I am not certain this op is needed at all. In the current kernel this
> >>>>>> op is only used by soc_camera, pxa_camera and omap3isp (somewhat
> >>>>>> dubious). Normally this information should come from the device tree
> >>>>>> and there should be no need for this op.
> >>>>>> 
> >>>>>> My (tentative) long-term plan was to get rid of this op.
> >>>>>> 
> >>>>>> If you don't need it, then I recommend it is removed.
> >>>> 
> >>>> Hi Hans, the imx-media driver was only calling g_mbus_config to the
> >>>> camera sensor, and it was doing that to determine the sensor's bus
> >>>> type. This info was already available from parsing a v4l2_of_endpoint
> >>>> from the sensor node. So it was simple to remove the g_mbus_config
> >>>> calls, and instead rely on the parsed sensor v4l2_of_endpoint.
> >>> 
> >>> That's not a good point.
> > 
> > (mea culpa, s/point/idea/)
> > 
> >>> The imx-media driver must not parse the sensor DT node as it is not
> >>> aware of what bindings the sensor is compatible with.
> 
> Hi Laurent,
> 
> I don't really understand this argument. The sensor node has been found
> by parsing the OF graph, so it is known to be a camera sensor node at
> that point.

All you know in the i.MX6 driver is that the remote node is a video source. 
You can rely on the fact that it implements the OF graph bindings to locate 
other ports in that DT node, but that's more or less it.

DT properties are defined by DT bindings and thus qualified by a compatible 
string. Unless you match on sensor compat strings in the i.MX6 driver (which 
you shouldn't do, to keep the driver generic) you can't know for certain how 
to parse the sensor node DT properties. For all you know, the video source 
could be a bridge such as an HDMI to CSI-2 converter for instance, so you 
can't even rely on the fact that it's a sensor.

> >>> Information must instead be queried from the sensor subdev at runtime,
> >>> through the g_mbus_config() operation.
> >>> 
> >>> Of course, if you can get the information from the imx-media DT node,
> >>> that's certainly an option. It's only information provided by the sensor
> >>> driver that you have no choice but query using a subdev operation.
> >> 
> >> Shouldn't this come from the imx-media DT node? BTW, why is omap3isp
> >> using this?
> > 
> > It all depends on what type of information needs to be retrieved, and
> > whether it can change at runtime or is fixed. Adding properties to the
> > imx-media DT node is certainly fine as long as those properties describe
> > the i.MX side.
>
> In this case the info needed is the media bus type. That info is most easily
> available by calling v4l2_of_parse_endpoint() on the sensor's endpoint
> node.

I haven't had time to check the code in details yet, so I can't really comment 
on what you need and how it should be implemented exactly.

> The media bus type is not something that can be added to the
> imx-media node since it contains no endpoint nodes.

Agreed. You have endpoints in the CSI nodes though.

> > In the omap3isp case, we use the operation to query whether parallel data
> > contains embedded sync (BT.656) or uses separate h/v sync signals.
> > 
> >> The reason I am suspicious about this op is that it came from soc-camera
> >> and predates the DT. The contents of v4l2_mbus_config seems very much
> >> like a HW description to me, i.e. something that belongs in the DT.
> > 
> > Part of it is possibly outdated, but for buses that support multiple modes
> > of operation (such as the parallel bus case described above) we need to
> > make that information discoverable at runtime. Maybe this should be
> > considered as related to Sakari's efforts to support VC/DT for CSI-2, and
> > supported through the API he is working on.
> 
> That sounds interesting, can you point me to some info on this effort?

Sure.

http://git.retiisi.org.uk/?p=~sailus/linux.git;a=shortlog;h=refs/heads/vc

> I've been thinking the DT should contain virtual channel info for CSI-2
> buses.

I don't think it should. CSI-2 virtual channels and data types should be 
handled as a software concept, and thus supported through driver code without 
involving DT.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Laurent Pinchart]

Hi Hans,

(CC'ing Sakari)

On Monday 06 Feb 2017 10:50:22 Hans Verkuil wrote:
> On 02/05/2017 04:48 PM, Laurent Pinchart wrote:
> > On Tuesday 24 Jan 2017 18:07:55 Steve Longerbeam wrote:
> >> On 01/24/2017 04:02 AM, Philipp Zabel wrote:
> >>> On Fri, 2017-01-20 at 15:03 +0100, Hans Verkuil wrote:
> >>>>> +
> >>>>> +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct
> >>>>> v4l2_mbus_config
> >>>>> *cfg)
> >>>>> +{
> >>>>> +   struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> >>>>> +   struct media_pad *pad;
> >>>>> +   int ret;
> >>>>> +
> >>>>> +   if (vidsw->active == -1) {
> >>>>> +   dev_err(sd->dev, "no configuration for inactive 
mux\n");
> >>>>> +   return -EINVAL;
> >>>>> +   }
> >>>>> +
> >>>>> +   /*
> >>>>> +* Retrieve media bus configuration from the entity connected 
to the
> >>>>> +* active input
> >>>>> +*/
> >>>>> +   pad = media_entity_remote_pad(>pads[vidsw->active]);
> >>>>> +   if (pad) {
> >>>>> +   sd = media_entity_to_v4l2_subdev(pad->entity);
> >>>>> +   ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
> >>>>> +   if (ret == -ENOIOCTLCMD)
> >>>>> +   pad = NULL;
> >>>>> +   else if (ret < 0) {
> >>>>> +   dev_err(sd->dev, "failed to get source
> >>>>> configuration\n");
> >>>>> +   return ret;
> >>>>> +   }
> >>>>> +   }
> >>>>> +   if (!pad) {
> >>>>> +   /* Mirror the input side on the output side */
> >>>>> +   cfg->type = vidsw->endpoint[vidsw->active].bus_type;
> >>>>> +   if (cfg->type == V4L2_MBUS_PARALLEL ||
> >>>>> +   cfg->type == V4L2_MBUS_BT656)
> >>>>> +   cfg->flags = vidsw->endpoint[vidsw-
> >>>>> active].bus.parallel.flags;
> >>>>> +   }
> >>>>> +
> >>>>> +   return 0;
> >>>>> +}
> >>>> 
> >>>> I am not certain this op is needed at all. In the current kernel this
> >>>> op is only used by soc_camera, pxa_camera and omap3isp (somewhat
> >>>> dubious). Normally this information should come from the device tree
> >>>> and there should be no need for this op.
> >>>> 
> >>>> My (tentative) long-term plan was to get rid of this op.
> >>>> 
> >>>> If you don't need it, then I recommend it is removed.
> >> 
> >> Hi Hans, the imx-media driver was only calling g_mbus_config to the
> >> camera sensor, and it was doing that to determine the sensor's bus type.
> >> This info was already available from parsing a v4l2_of_endpoint from the
> >> sensor node. So it was simple to remove the g_mbus_config calls, and
> >> instead rely on the parsed sensor v4l2_of_endpoint.
> > 
> > That's not a good point.

(mea culpa, s/point/idea/)

> > The imx-media driver must not parse the sensor DT node as it is not aware
> > of what bindings the sensor is compatible with. Information must instead
> > be queried from the sensor subdev at runtime, through the g_mbus_config()
> > operation.
> > 
> > Of course, if you can get the information from the imx-media DT node,
> > that's certainly an option. It's only information provided by the sensor
> > driver that you have no choice but query using a subdev operation.
> 
> Shouldn't this come from the imx-media DT node? BTW, why is omap3isp using
> this?

It all depends on what type of information needs to be retrieved, and whether 
it can change at runtime or is fixed. Adding properties to the imx-media DT 
node is certainly fine as long as those properties describe the i.MX side.

In the omap3isp case, we use the operation to query whether parallel data 
contains embedded sync (BT.656) or uses separate h/v sync signals.

> The reason I am suspicious about this op is that it came from soc-camera and
> predates the DT. The contents of v4l2_mbus_config seems very much like a HW
> description to me, i.e. something that belongs in the DT.

Part of it is possibly outdated, but for buses that support multiple modes of 
operation (such as the parallel bus case described above) we need to make that 
information discoverable at runtime. Maybe this should be considered as 
related to Sakari's efforts to support VC/DT for CSI-2, and supported through 
the API he is working on.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 15/24] media: Add userspace header file for i.MX

[Laurent Pinchart]

Hi Steve,

On Friday 13 Jan 2017 15:13:33 Steve Longerbeam wrote:
> On 01/13/2017 04:05 AM, Philipp Zabel wrote:
> > Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> >> This adds a header file for use by userspace programs wanting to interact
> >> with the i.MX media driver. It defines custom v4l2 controls and events
> >> generated by the i.MX v4l2 subdevices.
> >> 
> >> Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com>
> >> ---
> >> 
> >>   include/uapi/media/Kbuild |  1 +
> >>   include/uapi/media/imx.h  | 30 ++
> >>   2 files changed, 31 insertions(+)
> >>   create mode 100644 include/uapi/media/imx.h
> >> 
> >> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> >> index aafaa5a..fa78958 100644
> >> --- a/include/uapi/media/Kbuild
> >> +++ b/include/uapi/media/Kbuild
> >> @@ -1 +1,2 @@
> >> 
> >>   # UAPI Header export list
> >> 
> >> +header-y += imx.h
> >> diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
> >> new file mode 100644
> >> index 000..2421d9c
> >> --- /dev/null
> >> +++ b/include/uapi/media/imx.h
> >> @@ -0,0 +1,30 @@
> >> +/*
> >> + * Copyright (c) 2014-2015 Mentor Graphics Inc.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> the + * Free Software Foundation; either version 2 of the
> >> + * License, or (at your option) any later version
> >> + */
> >> +
> >> +#ifndef __UAPI_MEDIA_IMX_H__
> >> +#define __UAPI_MEDIA_IMX_H__
> >> +
> >> +/*
> >> + * events from the subdevs
> >> + */
> >> +#define V4L2_EVENT_IMX_CLASS  V4L2_EVENT_PRIVATE_START
> >> +#define V4L2_EVENT_IMX_NFB4EOF(V4L2_EVENT_IMX_CLASS + 1)
> >> +#define V4L2_EVENT_IMX_EOF_TIMEOUT(V4L2_EVENT_IMX_CLASS + 2)
> >> +#define V4L2_EVENT_IMX_FRAME_INTERVAL (V4L2_EVENT_IMX_CLASS + 3)
> > 
> > Aren't these generic enough to warrant common events? I would think
> > there have to be other capture IP cores that can signal aborted frames
> > or frame timeouts.
> 
> Yes, agreed. A frame capture timeout, or frame interval error, are
> both generic concepts. At some point it would be great to make the
> Frame Interval Monitor generally available under v4l2-core. As for the
> EOF timeout event, I'll look into moving that into a generic V4L2 event.

I'd prefer generic events if possible, but regardless of whether that's 
possible, the events must be documented in the V4L2 specification.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Laurent Pinchart]

Hi Steve,

On Tuesday 24 Jan 2017 18:07:55 Steve Longerbeam wrote:
> On 01/24/2017 04:02 AM, Philipp Zabel wrote:
> > On Fri, 2017-01-20 at 15:03 +0100, Hans Verkuil wrote:
> >>> +
> >>> +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct v4l2_mbus_config
> >>> *cfg)
> >>> +{
> >>> + struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> >>> + struct media_pad *pad;
> >>> + int ret;
> >>> +
> >>> + if (vidsw->active == -1) {
> >>> + dev_err(sd->dev, "no configuration for inactive mux\n");
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + /*
> >>> +  * Retrieve media bus configuration from the entity connected to the
> >>> +  * active input
> >>> +  */
> >>> + pad = media_entity_remote_pad(>pads[vidsw->active]);
> >>> + if (pad) {
> >>> + sd = media_entity_to_v4l2_subdev(pad->entity);
> >>> + ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
> >>> + if (ret == -ENOIOCTLCMD)
> >>> + pad = NULL;
> >>> + else if (ret < 0) {
> >>> + dev_err(sd->dev, "failed to get source 
configuration\n");
> >>> + return ret;
> >>> + }
> >>> + }
> >>> + if (!pad) {
> >>> + /* Mirror the input side on the output side */
> >>> + cfg->type = vidsw->endpoint[vidsw->active].bus_type;
> >>> + if (cfg->type == V4L2_MBUS_PARALLEL ||
> >>> + cfg->type == V4L2_MBUS_BT656)
> >>> + cfg->flags = vidsw->endpoint[vidsw-
>active].bus.parallel.flags;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >> 
> >> I am not certain this op is needed at all. In the current kernel this op
> >> is only used by soc_camera, pxa_camera and omap3isp (somewhat dubious).
> >> Normally this information should come from the device tree and there
> >> should be no need for this op.
> >> 
> >> My (tentative) long-term plan was to get rid of this op.
> >> 
> >> If you don't need it, then I recommend it is removed.
> 
> Hi Hans, the imx-media driver was only calling g_mbus_config to the camera
> sensor, and it was doing that to determine the sensor's bus type. This info
> was already available from parsing a v4l2_of_endpoint from the sensor node.
> So it was simple to remove the g_mbus_config calls, and instead rely on the
> parsed sensor v4l2_of_endpoint.

That's not a good point. The imx-media driver must not parse the sensor DT 
node as it is not aware of what bindings the sensor is compatible with. 
Information must instead be queried from the sensor subdev at runtime, through 
the g_mbus_config() operation.

Of course, if you can get the information from the imx-media DT node, that's 
certainly an option. It's only information provided by the sensor driver that 
you have no choice but query using a subdev operation.

> > We currently use this to make the CSI capture interface understand
> > whether its source from the MIPI CSI-2 or from the parallel bus. That is
> > probably something that should be fixed, but I'm not quite sure how.
> > 
> > The Synopsys DesignWare MIPI CSI-2 reciever turns the incoming MIPI
> > CSI-2 signal into a 32-bit parallel pixel bus plus some signals for the
> > MIPI specific metadata (virtual channel, data type).
> > 
> > Then the CSI2IPU gasket turns this input bus into four separate parallel
> > 16-bit pixel buses plus an 8-bit "mct_di" bus for each of them, that
> > carries the MIPI metadata. The incoming data is split into the four
> > outputs according to the MIPI virtual channel.
> > 
> > Two of these 16-bit + 8-bit parallel buses are routed through a
> > multiplexer before finally arriving at the CSI on the other side.
> > 
> > We need to configure the CSI to either use or ignore the data from the
> > 8-bit mct_di bus depending on whether the source of the mux is
> > configured to the MIPI CSI-2 receiver / CSI2IPU gasket, or to a parallel
> > input.
> 
> Philipp, from my experience, the CSI_MIPI_DI register (configured
> by ipu_csi_set_mipi_datatype()) can only be given a virtual channel 0,
> otherwise no data is received from the MIPI CSI-2 sensor, regardless
> of the virtual channel the sensor is transmitting over.
> 
> So it seems the info on the 8-bit mct_di buses generated by the CSI2IPU
>

Re: [PATCH v3 12/24] add mux and video interface bridge entity functions

[Laurent Pinchart]

Hi Steve,

Thank you for the patch

On Friday 06 Jan 2017 18:11:30 Steve Longerbeam wrote:
> From: Philipp Zabel <p.za...@pengutronix.de>
> 
> Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
> ---
>  Documentation/media/uapi/mediactl/media-types.rst | 22 
>  include/uapi/linux/media.h|  6 ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/media/uapi/mediactl/media-types.rst
> b/Documentation/media/uapi/mediactl/media-types.rst index 3e03dc2..023be29
> 100644
> --- a/Documentation/media/uapi/mediactl/media-types.rst
> +++ b/Documentation/media/uapi/mediactl/media-types.rst
> @@ -298,6 +298,28 @@ Types and flags used to represent the media graph
> elements received on its sink pad and outputs the statistics data on
> its source pad.
> 
> +-  ..  row 29
> +
> +   ..  _MEDIA-ENT-F-MUX:
> +
> +   -  ``MEDIA_ENT_F_MUX``
> +
> +   - Video multiplexer. An entity capable of multiplexing must have at
> + least two sink pads and one source pad, and must pass the video
> + frame(s) received from the active sink pad to the source pad.
> Video
> + frame(s) from the inactive sink pads are discarded.

Apart from the comment made by Hans regarding the macro name, this looks good 
to me.

> +-  ..  row 30
> +
> +   ..  _MEDIA-ENT-F-VID-IF-BRIDGE:
> +
> +   -  ``MEDIA_ENT_F_VID_IF_BRIDGE``
> +
> +   - Video interface bridge. A video interface bridge entity must have
> at
> + least one sink pad and one source pad. It receives video frame(s)
> on
> + its sink pad in one bus format (HDMI, eDP, MIPI CSI-2, ...) and
> + converts them and outputs them on its source pad in another bus
> format
> + (eDP, MIPI CSI-2, parallel, ...).


The first sentence mentions *at least* one sink pad and one source pad, and 
the second one refers to "its sink pad" and "its source pad". This is a bit 
confusing. An easy option would be to require a single sink and a single 
source pad, but that would exclude bridges that combine a multiplexer.

I also wonder whether "bridge" is the appropriate word here. Transceiver might 
be a better choice, to insist on the fact that one of the two pads corresponds 
to a physical interface that has special electrical properties (such as HDMI, 
eDP, or CSI-2 that all require PHYs).

>  ..  tabularcolumns:: |p{5.5cm}|p{12.0cm}|
> 
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 4890787..08a8bfa 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -105,6 +105,12 @@ struct media_device_info {
>  #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS(MEDIA_ENT_F_BASE + 0x4006)
> 
>  /*
> + * Switch and bridge entitites
> + */
> +#define MEDIA_ENT_F_MUX  (MEDIA_ENT_F_BASE + 
0x5001)
> +#define MEDIA_ENT_F_VID_IF_BRIDGE(MEDIA_ENT_F_BASE + 0x5002)
> +
> +/*
>   * Connectors
>   */
>  /* It is a responsibility of the entity drivers to add connectors and links
> */

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Laurent Pinchart]

Hi Russell,

On Monday 30 Jan 2017 22:51:33 Russell King - ARM Linux wrote:
> On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> > +   ov5640: camera@40 {
> > +   compatible = "ovti,ov5640";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_ov5640>;
> > +   clocks = <_xclk>;
> > +   clock-names = "xclk";
> > +   reg = <0x40>;
> > +   xclk = <2200>;
> > +   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> > +   pwdn-gpios = < 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> > +
> > +   port {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   ov5640_to_mipi_csi: endpoint@1 {
> > +   reg = <1>;
> > +   remote-endpoint = 
<_csi_from_mipi_sensor>;
> > +   data-lanes = <0 1>;
> > +   clock-lanes = <2>;
> 
> How do you envision a four-lane sensor being described?
> 
>   data-lanes = <0 1 3 4>;
>   clock-lanes = <2>;
> 
> ?
> 
> The binding document for video-interfaces.txt says:
> 
> - clock-lanes: an array of physical clock lane indexes. Position of an entry
> determines the logical lane number, while the value of an entry indicates
> physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes =
> <0>;", which places the clock lane on hardware lane 0. This property is
> valid for serial busses only (e.g. MIPI CSI-2). Note that for the MIPI
> CSI-2 bus this array contains only one entry.
> 
> So I think you need to have a good reason to make the clock lane non-zero.

The purpose of the data-lanes and clock-lanes properties is to describe lane 
assignment for hardware that supports lane routing. As far as I know the 
OV5640 doesn't support lane routing and has dedicated pins for the clock and 
data lanes. The data-lanes and clock-lanes properties should probably not be 
specified at all.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Laurent Pinchart]

On Monday 16 Jan 2017 13:55:23 Philipp Zabel wrote:
> On Fri, 2017-01-13 at 15:04 -0800, Steve Longerbeam wrote:
> > On 01/13/2017 04:03 AM, Philipp Zabel wrote:
> > > Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> > >> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2
> > >> sensor.
> > >> Both hang off the same i2c2 bus, so they require different (and non-
> > >> default) i2c slave addresses.
> > >> 
> > >> The OV5642 connects to the parallel-bus mux input port on
> > >> ipu1_csi0_mux.
> > >> 
> > >> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> > >> mipi_csi. It is set to transmit over MIPI virtual channel 1.
> > >> 
> > >> Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com>
> > >> ---
> > >> 
> > >>   arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
> > >>   arch/arm/boot/dts/imx6q-sabrelite.dts|   6 ++
> > >>   arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 118 ++
> > >>   3 files changed, 129 insertions(+)
> > >> 
> > >> diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts
> > >> b/arch/arm/boot/dts/imx6dl-sabrelite.dts index 0f06ca5..fec2524 100644
> > >> --- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
> > >> +++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
> 
> [...]
> 
> > >> @@ -299,6 +326,52 @@
> > >> 
> > >>  pinctrl-names = "default";
> > >>  pinctrl-0 = <_i2c2>;
> > >>  status = "okay";
> > >> 
> > >> +
> > >> +ov5640: camera@40 {
> > >> +compatible = "ovti,ov5640";
> > >> +pinctrl-names = "default";
> > >> +pinctrl-0 = <_ov5640>;
> > >> +clocks = <_xclk>;
> > >> +clock-names = "xclk";
> > >> +reg = <0x40>;
> > >> +xclk = <2200>;
> > > 
> > > This is superfluous, you can use clk_get_rate on mipi_xclk.
> > 
> > This property is actually there to tell the driver what to set the
> > rate to, with clk_set_rate(). So you are saying it would be better
> > to set the rate in the device tree and the driver should only
> > retrieve the rate?
> 
> Yes. Given that this is a reference clock input that is constant on a
> given board and never changes during runtime, I think this is the
> correct way. The clock will be fixed rate on most boards, I assume.

I think it's a bit worse than that. The ov5640 and ov5642 drivers should 
retrieve the clock rate and compute register values accordingly (PLL 
configuration parameters for instance, but most probably other values as 
well). Unfortunately, as usual with Omnivision, the lack of public and even 
non-public information results in drivers hardcoding large lists of 
register/value pairs that have been computed for a specific clock frequency. 
The drivers will thus not operate correctly if the clock is running at a 
different rate. Until that can be fixed, the best option is probably to assign 
the rate in the device tree as Philipp proposed, and to use clk_get_rate() in 
the driver to reject any rate other than 22MHz.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 00/24] i.MX Media Driver

[Laurent Pinchart]

Hello,

On Wednesday 01 Feb 2017 16:19:27 Steve Longerbeam wrote:
> On 02/01/2017 01:30 AM, Philipp Zabel wrote:
> > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> > [...]
> > 
> >>> # Set pad formats
> >>> media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
> >>> media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]"
> >>> media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080]"
> >>> media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080]"
> >>> 
> >>> v4l2-ctl -d /dev/video4 -V
> >>> # This still is configured to 640x480, which is inconsistent with
> >>> # the 'ipu1_csi0':2 pad format. The pad set_fmt above should
> >>> # have set this, too.
> >> 
> >> Because you've only configured the source pads,
> >> and not the sink pads. The ipu_csi source format is
> >> dependent on the sink format - output crop window is
> >> limited by max input sensor frame, and since sink pad is
> >> still at 640x480, output is reduced to that.
> > 
> > No, it is set (see below). What happens is that capture_g_fmt_vid_cap
> > just returns the capture devices' priv->vdev.fmt, even if it is
> > incompatible with the connected csi subdevice's output pad format.
> > 
> > priv->vdev.fmt was never changed from the default set in
> > imx_media_capture_device_register, because capture_s/try_fmt_vid_cap
> > were not called yet.
> 
> Ah, yep, this is a bug. Need to modify the capture device's
> width/height at .set_fmt() in the subdev's device-node source
> pad (csi and prpenc/vf).
> 
> >> Maybe I'm missing something, is it expected behavior that
> >> a source format should be automatically propagated to
> >> the sink?
> > 
> > media-ctl propagates the output pad format to all remote subdevices'
> > input pads for all enabled links:
> > 
> > https://git.linuxtv.org/v4l-utils.git/tree/utils/media-ctl/libv4l2subdev.c
> > #n693
>
> Ah cool, I wasn't aware media-ctl did this, but it makes sense and
> makes it easier on the user.

To be precise, userspace is responsible for propagating formats *between* 
subdevs (source to sink, over a link) and drivers for propagating formats *in* 
subdevs (sink to source, inside the subdev).

> >>> v4l2-ctl --list-formats -d /dev/video4
> >>> # This lists all the RGB formats, which it shouldn't. There is
> >>> # no CSC in this pipeline, so we should be limited to YUV formats
> >>> # only.
> >> 
> >> right, need to fix that. Probably by poking the attached
> >> source subdev (csi or prpenc/vf) for its supported formats.
> > 
> > You are right, in bayer/raw mode only one specific format should be
> > listed, depending on the CSI output pad format.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

[Laurent Pinchart]

Hi Steve,

Thank you for the patch. Many of the comments below apply to the ov5642 driver 
too, please take them into account when reworking patch 23/24.

On Friday 06 Jan 2017 18:11:40 Steve Longerbeam wrote:
> This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta
> branch, modified heavily to bring forward to latest interfaces and code
> cleanup.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/Kconfig   |8 +
>  drivers/staging/media/imx/Makefile  |2 +
>  drivers/staging/media/imx/ov5640-mipi.c | 2348 

You're missing DT bindings.

The driver should go to drivers/media/i2c/ as it should not be specific to the 
i.MX6, and you can just call it ov5640.c.

>  3 files changed, 2358 insertions(+)
>  create mode 100644 drivers/staging/media/imx/ov5640-mipi.c
> 
> diff --git a/drivers/staging/media/imx/Kconfig
> b/drivers/staging/media/imx/Kconfig index ce2d2c8..09f373d 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -17,5 +17,13 @@ config VIDEO_IMX_CAMERA
>   ---help---
> A video4linux camera capture driver for i.MX5/6.
> 
> +config IMX_OV5640_MIPI
> +   tristate "OmniVision OV5640 MIPI CSI-2 camera support"
> +   depends on GPIOLIB && VIDEO_IMX_CAMERA

The sensor driver is generic, it shouldn't depend on IMX. It should however 
depend on at least I2C and OF by the look of it.

> +   select IMX_MIPI_CSI2
> +   default y
> +   ---help---
> + MIPI CSI-2 OV5640 Camera support.
> +
>  endmenu
>  endif

[snip]

> diff --git a/drivers/staging/media/imx/ov5640-mipi.c
> b/drivers/staging/media/imx/ov5640-mipi.c new file mode 100644
> index 000..54647a7
> --- /dev/null
> +++ b/drivers/staging/media/imx/ov5640-mipi.c
> @@ -0,0 +1,2348 @@
> +/*
> + * Copyright (c) 2014 Mentor Graphics Inc.
> + * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights
> Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Pet peeve of mine, please sort the headers alphabetically. It makes it easier 
to locate duplicated.

> +
> +#define OV5640_VOLTAGE_ANALOG   280
> +#define OV5640_VOLTAGE_DIGITAL_CORE 150
> +#define OV5640_VOLTAGE_DIGITAL_IO   180
> +
> +#define MIN_FPS 15
> +#define MAX_FPS 30
> +#define DEFAULT_FPS 30
> +
> +/* min/typical/max system clock (xclk) frequencies */
> +#define OV5640_XCLK_MIN  600
> +#define OV5640_XCLK_TYP 2400
> +#define OV5640_XCLK_MAX 5400
> +
> +/* min/typical/max pixel clock (mclk) frequencies */
> +#define OV5640_MCLK_MIN 4800
> +#define OV5640_MCLK_TYP 4800
> +#define OV5640_MCLK_MAX 9600
> +
> +#define OV5640_CHIP_ID  0x300A
> +#define OV5640_SLAVE_ID 0x3100
> +#define OV5640_DEFAULT_SLAVE_ID 0x3c

You're mixing lower-case and upper-case hex constants. Let's pick one. Kernel 
code usually favours lower-case.

Please define macros for all the other numerical constants you use in the 
driver (register addresses and values). The large registers tables can be an 
exception if you don't have access to the information, but for registers 
written manually, hardcoding numerical values isn't good.

> +
> +#define OV5640_MAX_CONTROLS 64
> +
> +enum ov5640_mode {
> + ov5640_mode_MIN = 0,
> + ov5640_mode_QCIF_176_144 = 0,
> + ov5640_mode_QVGA_320_240,
> + ov5640_mode_VGA_640_480,
> + ov5640_mode_NTSC_720_480,
> + ov5640_mode_PAL_720_576,
> + ov5640_mode_XGA_1024_768,
> + ov5640_mode_720P_1280_720,
> + ov5640_mode_1080P_1920_1080,
> + ov5640_mode_QSXGA_2592_1944,
> + ov5640_num_modes,
> + ov5640_mode_INIT = 0xff, /*only for sensor init*/

Please add spaces after /* and before */.

Enumerated values should be all upper-case.

> +};
> +
> +enum ov5640_frame_rate {
> + ov5640_15_fps,
> + ov5640_30_fps
> +};
> +
> +static int ov5640_framerates[] = {
> + [ov5640_15_fps] = 15,
> + [ov5640_30_fps] = 30,
> +};
> +#define ov5640_num_framerates ARRAY_SIZE(ov5640_framerates)
> +
> +/* image size under 1280 * 960 are SUBSAMPLING
> + * image size upper 1280 * 960 are SCALING
> + */

The kernel multi-line comment style is

/*
 * text
 * text
 */

> +enum ov5640_downsize_mode {
> + SUBSAMPLING,
> + SCALING,
> +};
> +
> +struct reg_value {
> + u16 reg_addr;
> + u8 val;
> + u8 mask;
> + u32 delay_ms;
> +};
> +
> +struct ov5640_mode_info {
> + enum ov5640_mode mode;
> + enum 

Re: [PATCH] V4l: omap4iss: Clean up file handle in open() and release().

[Laurent Pinchart]

Hi Shailendra,

Thank you for the patch.

On Thursday 01 Dec 2016 10:22:52 Shailendra Verma wrote:
> Both functions initialize the file handle with v4l2_fh_init()
> and thus need to call clean up with v4l2_fh_exit() as appropriate.
> 
> Signed-off-by: Shailendra Verma <shailendr...@samsung.com>

Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

and applied to my tree for v4.11.

> ---
>  drivers/staging/media/omap4iss/iss_video.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..077c9f8 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -1141,6 +1141,7 @@ static int iss_video_open(struct file *file)
>  done:
>   if (ret < 0) {
>   v4l2_fh_del(>vfh);
> + v4l2_fh_exit(>vfh);
>   kfree(handle);
>   }
> 
> @@ -1162,6 +1163,7 @@ static int iss_video_release(struct file *file)
>   vb2_queue_release(>queue);
> 
>   v4l2_fh_del(vfh);
> + v4l2_fh_exit(vfh);
>   kfree(handle);
>   file->private_data = NULL;

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: davinci_vpfe: - Fix for memory leak if

[Laurent Pinchart]

Hi Shailendra,

Thank you for the patch.

I think the subject line is incomplete.

On Friday 11 Nov 2016 14:21:41 Shailendra Verma wrote:
> From: "Shailendra Verma" <shailendr...@samsung.com>
> 
> Fix to avoid possible memory leak if the decoder initialization
> got failed.Free the allocated memory for file handle object
> before return in case decoder initialization fails.
> 
> Signed-off-by: Shailendra Verma <shailendra.capric...@gmail.com>
> ---
>  drivers/staging/media/davinci_vpfe/vpfe_video.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index 8be9f85..80c2e25
> 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -423,6 +423,7 @@ static int vpfe_open(struct file *file)

(Adding a bit of context here for review purpose)

v4l2_fh_init(>vfh, >video_dev);
v4l2_fh_add(>vfh);

mutex_lock(>lock)

>   /* If decoder is not initialized. initialize it */
>   if (!video->initialized && vpfe_update_pipe_state(video)) {
>   mutex_unlock(>lock);
> + kfree(handle);

This isn't enough. The v4l2_fh_init() and v4l2_fh_add() calls have side 
effects. The major one is adding vfh to the file handles' list in video_dev. 
If you just free the memory here you will get a crash pretty soon afterwards.

>   return -ENODEV;
>   }
>   /* Increment device users counter */

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: davinci_vpfe: fix indentation issue in vpfe_video.c

[Laurent Pinchart]

Hi Leo,

Thank you for the patch, and sorry for the late reply.

On Sunday 23 Oct 2016 14:02:23 Leo Sperling wrote:
> This is a patch to the vpfe_video.c file that fixes an indentation
> warning reported by checkpatch.pl
> 
> Signed-off-by: Leo Sperling <leosperlin...@gmail.com>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

and applied to my tree. I will send a pull request for v4.11.

> ---
>  drivers/staging/media/davinci_vpfe/vpfe_video.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index 8be9f85..c34bf46
> 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -1143,8 +1143,8 @@ static int vpfe_buffer_prepare(struct vb2_buffer *vb)
>   /* Initialize buffer */
>   vb2_set_plane_payload(vb, 0, video->fmt.fmt.pix.sizeimage);
>   if (vb2_plane_vaddr(vb, 0) &&
> - vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0))
> - return -EINVAL;
> + vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0))
> + return -EINVAL;
> 
>   addr = vb2_dma_contig_plane_dma_addr(vb, 0);
>   /* Make sure user addresses are aligned to 32 bytes */

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] [media] staging: davinci_vpfe: fix W=1 build warnings

[Laurent Pinchart]

Hi Arnd,

Thank you for the patch, and sorry for the late reply.

On Monday 20 Jun 2016 17:47:56 Arnd Bergmann wrote:
> When building with "make W=1", we get multiple harmless build warnings
> for the vpfe driver:
> 
> drivers/staging/media/davinci_vpfe/dm365_resizer.c:241:1: error: 'static' is
> not at beginning of declaration [-Werror=old-style-declaration]
> drivers/staging/media/davinci_vpfe/dm365_resizer.c: In function
> 'resizer_set_defualt_configuration':
> drivers/staging/media/davinci_vpfe/dm365_resizer.c:831:16: error:
> initialized field overwritten [-Werror=override-init]
> drivers/staging/media/davinci_vpfe/dm365_resizer.c:831:16: note: (near
> initialization for 'rsz_default_config.rsz_rsc_param[0].h_typ_c')
> drivers/staging/media/davinci_vpfe/dm365_resizer.c:849:16: error:
> initialized field overwritten [-Werror=override-init]
> drivers/staging/media/davinci_vpfe/dm365_resizer.c:849:16: note: (near
> initialization for 'rsz_default_config.rsz_rsc_param[1].h_typ_c')
> 
> All of them are trivial to fix without changing the behavior of the
> driver, as "static const" is interpreted the same as "const static",
> and VPFE_RSZ_INTP_CUBIC is defined as zero, so the initializations
> are not really needed.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

and applied to my tree. I will send a pull request for v4.11.
> ---
>  drivers/staging/media/davinci_vpfe/dm365_resizer.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> b/drivers/staging/media/davinci_vpfe/dm365_resizer.c index
> 3cd56cc132c7..567f995fd0f9 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> @@ -237,9 +237,8 @@ resizer_calculate_resize_ratios(struct
> vpfe_resizer_device *resizer, int index) ((informat->width) * 256) /
> (outformat->width);
>  }
> 
> -void
> -static resizer_enable_422_420_conversion(struct resizer_params *param,
> -  int index, bool en)
> +static void resizer_enable_422_420_conversion(struct resizer_params *param,
> +   int index, bool en)
>  {
>   param->rsz_rsc_param[index].cen = en;
>   param->rsz_rsc_param[index].yen = en;
> @@ -825,7 +824,7 @@ resizer_set_defualt_configuration(struct
> vpfe_resizer_device *resizer) .o_hsz = WIDTH_O - 1,
>   .v_dif = 256,
>   .v_typ_y = VPFE_RSZ_INTP_CUBIC,
> - .h_typ_c = VPFE_RSZ_INTP_CUBIC,
> + .v_typ_c = VPFE_RSZ_INTP_CUBIC,
>   .h_dif = 256,
>   .h_typ_y = VPFE_RSZ_INTP_CUBIC,
>   .h_typ_c = VPFE_RSZ_INTP_CUBIC,
> @@ -843,7 +842,7 @@ resizer_set_defualt_configuration(struct
> vpfe_resizer_device *resizer) .o_hsz = WIDTH_O - 1,
>   .v_dif = 256,
>   .v_typ_y = VPFE_RSZ_INTP_CUBIC,
> - .h_typ_c = VPFE_RSZ_INTP_CUBIC,
> +         .v_typ_c = VPFE_RSZ_INTP_CUBIC,
>   .h_dif = 256,
>   .h_typ_y = VPFE_RSZ_INTP_CUBIC,
>   .h_typ_c = VPFE_RSZ_INTP_CUBIC,

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: davinci_vpfe: Fix spelling error on a comment

[Laurent Pinchart]

Hi Manuel,

Thank you for the patch and sorry for the late reply.

On Tuesday 08 Mar 2016 01:16:06 Manuel Rodriguez wrote:
> Fix spelling error on a comment, change 'wether' to 'whether'
> 
> Signed-off-by: Manuel Rodriguez <manuel2...@gmail.com>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

and applied to my tree. I will send a pull request for v4.11.

> ---
>  drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index 0a65405..e4b953a
> 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -195,7 +195,7 @@ static int vpfe_update_pipe_state(struct
> vpfe_video_device *video) return 0;
>  }
> 
> -/* checks wether pipeline is ready for enabling */
> +/* checks whether pipeline is ready for enabling */
>  int vpfe_video_is_pipe_ready(struct vpfe_pipeline *pipe)
>  {
>   int i;

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] drivers: staging: media: davinci_vpfe: dm365_resizer: fixed some spelling mistakes

[Laurent Pinchart]

put = RESIZER_OUTPUT_MEMORY;
>   break;
> 
>   default:
> @@ -1747,7 +1747,7 @@ static int resizer_link_setup(struct media_entity
> *entity, }
>   if (resizer->resizer_b.output != RESIZER_OUTPUT_NONE)
>   return -EBUSY;
> - resizer->resizer_b.output = RESIZER_OUPUT_MEMORY;
> + resizer->resizer_b.output = RESIZER_OUTPUT_MEMORY;
>   break;
> 
>   default:
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.h
> b/drivers/staging/media/davinci_vpfe/dm365_resizer.h index 93b0f44..00e64b0
> 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.h
> +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.h
> @@ -210,7 +210,7 @@ enum resizer_input_entity {
> 
>  enum resizer_output_entity {
>   RESIZER_OUTPUT_NONE = 0,
> - RESIZER_OUPUT_MEMORY = 1,
> + RESIZER_OUTPUT_MEMORY = 1,
>  };
> 
>  struct dm365_resizer_device {

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Greybus Future

[Laurent Pinchart]

Hi Alex,

On Monday 31 Oct 2016 08:50:53 Alex Elder wrote:
> The Greybus kernel code, developed as part of Google's Project Ara,
> is in the upstream Linux kernel tree (under drivers/staging).  The
> cancellation of that project makes the future for Greybus a bit less
> certain.  There is interest among the core developers of Greybus
> (and others) to do what we can to preserve the value of the Greybus
> implementation for use beyond its original target platform.  For
> that to have any chance of success, we need to establish some
> organization, and basically form a community of developers and
> interested parties.
> 
> I'm proposing below a few things, which I'll implement this week
> unless I hear people express strong opposition (or clearly better
> suggestions).  If you have comments, please say something.
> 
> Git repositories.  Public git repositories related to Project Ara
> are all hosted here:
> https://github.com/projectara
> At this time I see no reason to move away from this, but it would
> not surprise me if we decided to host the code and documentation
> somewhere else at some future date.
> 
> Mailing List.  Because the Greybus kernel code sits in the staging
> tree, mail about it should go to the driver-devel mailing list
> (de...@driverdev.osuosl.org).  I know that some people prefer better
> mail filters rather than more mailing lists, but I think Greybus
> discussion warrants a separate list.  Its code spans multiple code
> bases, and I think we're going to need some dedicated and ongoing
> strategy and design discussions.  So I'd like to create a Greybus
> mailing list as a home for all Greybus-related discussion, including
> patch traffic.  My suggestion is to create a majordomo list:
> grey...@kernel.org
> 
> Patchwork.  In the past I have found Patchwork to be a very useful
> tool in managing incoming patches.  I'd like to set up a patchwork
> instance for Greybus, monitoring the greybus mailing list, again
> at kernel.org.

I definitely second that as it doesn't involve Gerrit ;-)

> Wiki page.  If we want a Wiki page, we could set one up at
> kernel.org.  Thoughts?
> 
> Web home page.  I have secured the "greybus.org" domain, so if there
> is any value in populating that page it could serve as the home page
> for the project.  It currently has no content.
> 
> Are there any other important resources I've missed?  Once we get
> a list going (or not) I've got a few other things to talk about.
> 
> Thanks.
> 
>   -Alex
> 
> PS  I have addressed this message to a set of interested people
> whose e-mail addresses I knew; the set is definitely incomplete.
> This will form the initial membership of the mailing list.  If
> you do not want to be on that list, or if you know others I
> should include, please send me contact information by private
> message.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: omap4iss: fixed coding style issues

[Laurent Pinchart]

Hi Hector,

Thank you for the patch.

On Sunday 16 Oct 2016 17:18:56 Hector Roussille wrote:
> Fixed coding style issues

What coding style issues ?

> 
> Signed-off-by: Hector Roussille <hector.roussi...@gmail.com>
> ---
>  drivers/staging/media/omap4iss/iss_video.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..8f2d374 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -297,8 +297,10 @@ iss_video_check_format(struct iss_video *video, struct
> iss_video_fh *vfh) */
> 
>  static int iss_video_queue_setup(struct vb2_queue *vq,
> -  unsigned int *count, unsigned int 
*num_planes,

This line doesn't exceed the 80 columns limit, no need to split it.

> -  unsigned int sizes[], struct device 
*alloc_devs[])
> +  unsigned int *count,
> +  unsigned int *num_planes,
> +  unsigned int sizes[],
> +  struct device *alloc_devs[])
>  {
>   struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
>   struct iss_video *video = vfh->video;
> @@ -678,9 +680,10 @@ iss_video_get_selection(struct file *file, void *fh,
> struct v4l2_selection *sel) if (subdev == NULL)
>   return -EINVAL;
> 
> - /* Try the get selection operation first and fallback to get format if 
not
> -  * implemented.
> + /* Try the get selection operation first and fallback to

while do you split the line here and not right before the 80 columns limit ?

> +  * get format if not implemented.
>*/

This isn't the preferred comment style for the kernel, see 
http://lkml.iu.edu/hypermail/linux/kernel/1607.1/00627.html. The problem 
doesn't predate your patch, but while at it you might want to fix it through 
the driver.

> +

How does adding a blank line here fix a coding style issue ?

>   sdsel.pad = pad;
>   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
>   if (!ret)

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] [media] : Removing warnings caught by checkpatch.pl

[Laurent Pinchart]

Hi Andrey,

On Monday 03 Oct 2016 22:52:11 Andrey Utkin wrote:
> On Sun, Oct 02, 2016 at 02:30:45AM +0530, Harman Kalra wrote:
> >  static int iss_video_queue_setup(struct vb2_queue *vq,
> > 
> > -unsigned int *count, unsigned int 
*num_planes,
> > -unsigned int sizes[], struct device 
*alloc_devs[])
> > +   unsigned int *count, unsigned int *num_planes,
> > +   unsigned int sizes[], struct device *alloc_devs[])
> 
> 2 spaces + 3 tabs -> 2 spaces + 2 tabs? Am I seeing this correctly?
> Both ways are against CodingStyle.

It's 4 tabs + 1 space -> 3 tabs as far as I can see.

> > -   /* Try the get selection operation first and fallback to get format if
> > not -* implemented.
> > +   /* Try the get selection operation first and
> > +* fallback to get format if not implemented.
> > 
> >  */
> 
> This comment style is discouraged so this is at lease not perfect.
> Doesn't checkpatch complain with this change? If it doesn't, could you
> please also check with --strict, as long as you're working on style.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] [media] v4l: omap4iss: Fix using BIT macro

[Laurent Pinchart]

On Monday 03 Oct 2016 06:58:22 Mauro Carvalho Chehab wrote:
> Em Sat, 1 Oct 2016 16:37:46 -0700 Wayne Porter escreveu:
> > Checks found by checkpatch
> > 
> > Signed-off-by: Wayne Porter <wporte...@gmail.com>
> > ---
> > 
> >  drivers/staging/media/omap4iss/iss_regs.h | 76 --
> >  1 file changed, 38 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/staging/media/omap4iss/iss_regs.h
> > b/drivers/staging/media/omap4iss/iss_regs.h index cb415e8..c675212 100644
> > --- a/drivers/staging/media/omap4iss/iss_regs.h
> > +++ b/drivers/staging/media/omap4iss/iss_regs.h
> > @@ -42,7 +42,7 @@
> >  #define ISS_CTRL_CLK_DIV_MASK  (3 << 4)
> >  #define ISS_CTRL_INPUT_SEL_MASK(3 << 2)
> >  #define ISS_CTRL_INPUT_SEL_CSI2A   (0 << 2)
> > -#define ISS_CTRL_INPUT_SEL_CSI2B   (1 << 2)
> > +#define ISS_CTRL_INPUT_SEL_CSI2B   BIT(2)
> 
> Converting just a few of such macros won't help. Either convert all
> or none.
> 
> Also, as most of the bit masks here have more than one bit, you should
> use GENMASK(), instead of BIT, like:
> 
> #define ISS_CTRL_CLK_DIV_MASK GENMASK(4, 5)
> #define ISS_CTRL_INPUT_SEL_MASK   GENMASK(2, 3)
> #define   ISS_CTRL_INPUT_SEL_CSI2A0
> #define   ISS_CTRL_INPUT_SEL_CSI2BBIT(2)
> 
> Yet, not sure if I would like such patch, as this kind of change
> could easily break the driver if you make any typo at the GENMASK
> parameters.

It would be best to automate such a change with a script than performing it 
manually.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] [media] v4l: omap4iss: Fix using BIT macro

[Laurent Pinchart]

  (1 << 0)
> +#define ISIF_CCOLP_CP3_F0_GR BIT(0)
>  #define ISIF_CCOLP_CP3_F0_B  (3 << 0)
>  #define ISIF_CCOLP_CP3_F0_GB (2 << 0)
> 
> @@ -381,12 +381,12 @@
>  #define IPIPEIF_CFG1 (0x0004)
>  #define IPIPEIF_CFG1_INPSRC1_MASK(3 << 14)
>  #define IPIPEIF_CFG1_INPSRC1_VPORT_RAW   (0 << 14)
> -#define IPIPEIF_CFG1_INPSRC1_SDRAM_RAW   (1 << 14)
> +#define IPIPEIF_CFG1_INPSRC1_SDRAM_RAW   BIT(14)
>  #define IPIPEIF_CFG1_INPSRC1_ISIF_DARKFM (2 << 14)
>  #define IPIPEIF_CFG1_INPSRC1_SDRAM_YUV   (3 << 14)
>  #define IPIPEIF_CFG1_INPSRC2_MASK(3 << 2)
>  #define IPIPEIF_CFG1_INPSRC2_ISIF(0 << 2)
> -#define IPIPEIF_CFG1_INPSRC2_SDRAM_RAW   (1 << 2)
> +#define IPIPEIF_CFG1_INPSRC2_SDRAM_RAW   BIT(2)
>  #define IPIPEIF_CFG1_INPSRC2_ISIF_DARKFM (2 << 2)
>  #define IPIPEIF_CFG1_INPSRC2_SDRAM_YUV   (3 << 2)
> 
> @@ -410,25 +410,25 @@
> 
>  #define IPIPE_SRC_FMT(0x0008)
>  #define IPIPE_SRC_FMT_RAW2YUV(0 << 0)
> -#define IPIPE_SRC_FMT_RAW2RAW(1 << 0)
> +#define IPIPE_SRC_FMT_RAW2RAWBIT(0)
>  #define IPIPE_SRC_FMT_RAW2STATS  (2 << 0)
>  #define IPIPE_SRC_FMT_YUV2YUV(3 << 0)
> 
>  #define IPIPE_SRC_COL(0x000c)
>  #define IPIPE_SRC_COL_OO_R   (0 << 6)
> -#define IPIPE_SRC_COL_OO_GR  (1 << 6)
> +#define IPIPE_SRC_COL_OO_GR  BIT(6)
>  #define IPIPE_SRC_COL_OO_B       (3 << 6)
>  #define IPIPE_SRC_COL_OO_GB  (2 << 6)
>  #define IPIPE_SRC_COL_OE_R   (0 << 4)
> -#define IPIPE_SRC_COL_OE_GR  (1 << 4)
> +#define IPIPE_SRC_COL_OE_GR  BIT(4)
>  #define IPIPE_SRC_COL_OE_B   (3 << 4)
>  #define IPIPE_SRC_COL_OE_GB  (2 << 4)
>  #define IPIPE_SRC_COL_EO_R   (0 << 2)
> -#define IPIPE_SRC_COL_EO_GR  (1 << 2)
> +#define IPIPE_SRC_COL_EO_GR  BIT(2)
>  #define IPIPE_SRC_COL_EO_B   (3 << 2)
>  #define IPIPE_SRC_COL_EO_GB  (2 << 2)
>  #define IPIPE_SRC_COL_EE_R   (0 << 0)
> -#define IPIPE_SRC_COL_EE_GR  (1 << 0)
> +#define IPIPE_SRC_COL_EE_GR  BIT(0)
>  #define IPIPE_SRC_COL_EE_B   (3 << 0)
>  #define IPIPE_SRC_COL_EE_GB  (2 << 0)

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] [media] : Removing warnings caught by checkpatch.pl

[Laurent Pinchart]

Hello Harman,

Thank you for the patch.

The subject of your commit message should at least contain the name of the 
driver. Furthermore, you can mention that the patch originates from warnings 
output by checkpatch.pl, but the subject should describe what you fix (in this 
case what type of warning).

On Sunday 02 Oct 2016 02:30:45 Harman Kalra wrote:
> Removing warnings caught by checkpatch.pl

If the purpose of commit message bodies was to repeat the subject line, we 
wouldn't use them :-) Here you should describe why this change is needed, and 
possibly how it is performed when the patch is complex (which isn't the case 
of this patch).

> Signed-off-by: Harman Kalra <harman4li...@gmail.com>
> ---
>  drivers/staging/media/omap4iss/iss_video.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..7cc1691 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -297,8 +297,8 @@ static void iss_video_pix_to_mbus(const struct
> v4l2_pix_format *pix, */
> 
>  static int iss_video_queue_setup(struct vb2_queue *vq,
> -  unsigned int *count, unsigned int 
*num_planes,
> -  unsigned int sizes[], struct device 
*alloc_devs[])
> + unsigned int *count, unsigned int *num_planes,
> + unsigned int sizes[], struct device *alloc_devs[])

This breaks the coding style of the driver which aligns function arguments to 
the opening parenthesis. You can instead wrap the last line to shorten it.

>  {
>   struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
>   struct iss_video *video = vfh->video;
> @@ -678,8 +678,8 @@ void omap4iss_video_cancel_stream(struct iss_video
> *video) if (subdev == NULL)
>   return -EINVAL;
> 
> - /* Try the get selection operation first and fallback to get format if 
not
> -  * implemented.
> + /* Try the get selection operation first and
> +  * fallback to get format if not implemented.

Lines can be up to 80 characters long, there's no need to wrap them after 52 
characters only.

>*/
>   sdsel.pad = pad;
>   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
> --
> 1.7.9.5

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: media: omap4iss: mark omap4iss_flush() static

[Laurent Pinchart]

Hi Baoyou,

Thank you for the patch.

On Sunday 04 Sep 2016 14:41:41 Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/staging/media/omap4iss/iss.c:64:6: warning: no previous prototype
> for 'omap4iss_flush' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> so this patch marks this function with 'static'.
> 
> Signed-off-by: Baoyou Xie <baoyou@linaro.org>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

> ---
>  drivers/staging/media/omap4iss/iss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index 6ceb4eb..e27c7a9 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -61,7 +61,7 @@ static void iss_print_status(struct iss_device *iss)
>   * See this link for reference:
>   *   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08149.html
>   */
> -void omap4iss_flush(struct iss_device *iss)
> +static void omap4iss_flush(struct iss_device *iss)
>  {
>   iss_reg_write(iss, OMAP4_ISS_MEM_TOP, ISS_HL_REVISION, 0);
>   iss_reg_read(iss, OMAP4_ISS_MEM_TOP, ISS_HL_REVISION);

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] [media] v4l: vsp1: Split pad operations between rpf and wpf

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Wednesday 22 Jun 2016 02:19:24 Niklas Söderlund wrote:
> This is done in preparation to move s_stream from v4l2_subdev_video_ops
> to v4l2_subdev_pad_ops. Only wpf implements s_stream so it will no
> longer be possible to share the v4l2_subdev_pad_ops once s_stream is
> moved.
> 
> Suggested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/platform/vsp1/vsp1_rpf.c  | 12 +-
>  drivers/media/platform/vsp1/vsp1_rwpf.c | 40 +++--
>  drivers/media/platform/vsp1/vsp1_rwpf.h | 20 +
>  drivers/media/platform/vsp1/vsp1_wpf.c  | 12 +-
>  4 files changed, 57 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
> b/drivers/media/platform/vsp1/vsp1_rpf.c index 49168db..fabe8b2 100644
> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> @@ -38,8 +38,18 @@ static inline void vsp1_rpf_write(struct vsp1_rwpf *rpf,
>   * V4L2 Subdevice Operations
>   */
> 
> +const struct v4l2_subdev_pad_ops vsp1_rpf_pad_ops = {

This should be static const.

> + .init_cfg = vsp1_entity_init_cfg,
> + .enum_mbus_code = vsp1_rwpf_enum_mbus_code,
> + .enum_frame_size = vsp1_rwpf_enum_frame_size,
> + .get_fmt = vsp1_subdev_get_pad_format,
> + .set_fmt = vsp1_rwpf_set_format,
> + .get_selection = vsp1_rwpf_get_selection,
> + .set_selection = vsp1_rwpf_set_selection,
> +};
> +
>  static struct v4l2_subdev_ops rpf_ops = {
> - .pad= _rwpf_pad_ops,
> + .pad= _rpf_pad_ops,
>  };
> 
>  /*
> ---
> -- diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c
> b/drivers/media/platform/vsp1/vsp1_rwpf.c index 3b6e032..ff03b9c 100644
> --- a/drivers/media/platform/vsp1/vsp1_rwpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
> @@ -31,9 +31,9 @@ struct v4l2_rect *vsp1_rwpf_get_crop(struct vsp1_rwpf
> *rwpf, * V4L2 Subdevice Pad Operations
>   */
> 
> -static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev *subdev,
> - struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_mbus_code_enum *code)
> +int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev *subdev,
> +  struct v4l2_subdev_pad_config *cfg,
> +  struct v4l2_subdev_mbus_code_enum *code)
>  {
>   static const unsigned int codes[] = {
>   MEDIA_BUS_FMT_ARGB_1X32,
> @@ -48,9 +48,9 @@ static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev
> *subdev, return 0;
>  }
> 
> -static int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
> -  struct v4l2_subdev_pad_config *cfg,
> -  struct v4l2_subdev_frame_size_enum *fse)
> +int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
> +   struct v4l2_subdev_pad_config *cfg,
> +   struct v4l2_subdev_frame_size_enum *fse)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
> 
> @@ -59,9 +59,9 @@ static int vsp1_rwpf_enum_frame_size(struct v4l2_subdev
> *subdev, rwpf->max_height);
>  }
> 
> -static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
> - struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_format *fmt)
> +int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
> +  struct v4l2_subdev_pad_config *cfg,
> +  struct v4l2_subdev_format *fmt)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
>   struct v4l2_subdev_pad_config *config;
> @@ -113,9 +113,9 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev
> *subdev, return 0;
>  }
> 
> -static int vsp1_rwpf_get_selection(struct v4l2_subdev *subdev,
> -struct v4l2_subdev_pad_config *cfg,
> -struct v4l2_subdev_selection *sel)
> +int vsp1_rwpf_get_selection(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_selection *sel)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
>   struct v4l2_subdev_pad_config *config;
> @@ -150,9 +150,9 @@ static int vsp1_rwpf_get_selection(struct v4l2_subdev
> *subdev, return 0;
>  }
> 
> -static int vsp1_rwpf_set_selection(struct v4l2_subdev *subdev,
> -struct v4l2_subdev_pad_config *cfg,
> -

Re: [PATCH v8 36/55] [media] davinci_vbpe: stop MEDIA_ENT_T_V4L2_SUBDEV abuse

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Sunday 30 August 2015 00:06:47 Mauro Carvalho Chehab wrote:
> This driver is abusing MEDIA_ENT_T_V4L2_SUBDEV:
> 
> - it uses a hack to check if the remote entity is a subdev;

Same comment as for "omap4iss: stop MEDIA_ENT_T_V4L2_SUBDEV abuse", this isn't 
a hack.

> - it still uses the legacy entity subtype check macro, that
>   will be removed soon.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c index
> b89a057b8b7e..7fd78329e3e1 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> @@ -1711,8 +1711,11 @@ ipipe_link_setup(struct media_entity *entity, const
> struct media_pad *local, struct vpfe_device *vpfe_dev =
> to_vpfe_device(ipipe);
>   u16 ipipeif_sink = vpfe_dev->vpfe_ipipeif.input;
> 
> - switch (local->index | media_entity_type(remote->entity)) {
> - case IPIPE_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> + if (!is_media_entity_v4l2_subdev(remote->entity))
> + return -EINVAL;

You can drop the check (even though the implementation in the switch looks 
dubious to me, but that's not your fault).

> + switch (local->index) {
> + case IPIPE_PAD_SINK:
>   if (!(flags & MEDIA_LNK_FL_ENABLED)) {
>   ipipe->input = IPIPE_INPUT_NONE;
>   break;
> @@ -1725,7 +1728,7 @@ ipipe_link_setup(struct media_entity *entity, const
> struct media_pad *local, ipipe->input = IPIPE_INPUT_CCDC;
>   break;
> 
> - case IPIPE_PAD_SOURCE | MEDIA_ENT_T_V4L2_SUBDEV:
> + case IPIPE_PAD_SOURCE:
>   /* out to RESIZER */
>   if (flags & MEDIA_LNK_FL_ENABLED)
>   ipipe->output = IPIPE_OUTPUT_RESIZER;
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index
> 9eef64e0f0ab..2dbf14b9bb5f 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -88,7 +88,7 @@ vpfe_video_remote_subdev(struct vpfe_video_device *video,
> u32 *pad) {
>   struct media_pad *remote = media_entity_remote_pad(>pad);
> 
> - if (remote == NULL || remote->entity->type != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
>   return NULL;
>   if (pad)
>   *pad = remote->index;
> @@ -243,8 +243,7 @@ static int vpfe_video_validate_pipeline(struct
> vpfe_pipeline *pipe)
> 
>   /* Retrieve the source format */
>   pad = media_entity_remote_pad(pad);
> - if (pad == NULL ||
> - pad->entity->type != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>   break;
> 
>   subdev = media_entity_to_v4l2_subdev(pad->entity);

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v8 33/55] [media] omap3/omap4/davinci: get rid of MEDIA_ENT_T_V4L2_SUBDEV abuse

[Laurent Pinchart]

 case RESIZER_PAD_SOURCE:
>   if (!(flags & MEDIA_LNK_FL_ENABLED)) {
>   resizer->resizer_b.output = RESIZER_OUTPUT_NONE;
>   break;
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index
> 16763e0831f2..9eef64e0f0ab 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -148,7 +148,7 @@ static void vpfe_prepare_pipeline(struct
> vpfe_video_device *video) while ((entity =
> media_entity_graph_walk_next())) {
>   if (entity == >video_dev.entity)
>   continue;
> - if ((!is_media_entity_v4l2_io(remote->entity))
> + if (!is_media_entity_v4l2_io(entity))
>   continue;
>   far_end = to_vpfe_video(media_entity_to_video_device(entity));
>   if (far_end->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
> @@ -293,7 +293,7 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline
> *pipe) media_entity_graph_walk_start(, entity);
>   while ((entity = media_entity_graph_walk_next())) {
> 
> - if !is_media_entity_v4l2_subdev(entity))
> + if (!is_media_entity_v4l2_subdev(entity))
>   continue;
>   subdev = media_entity_to_v4l2_subdev(entity);
>   ret = v4l2_subdev_call(subdev, video, s_stream, 1);
> diff --git a/drivers/staging/media/omap4iss/iss_csi2.c
> b/drivers/staging/media/omap4iss/iss_csi2.c index
> 6b4dcbfa9425..50a24e8e8129 100644
> --- a/drivers/staging/media/omap4iss/iss_csi2.c
> +++ b/drivers/staging/media/omap4iss/iss_csi2.c
> @@ -1170,14 +1170,19 @@ static int csi2_link_setup(struct media_entity
> *entity, struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>   struct iss_csi2_device *csi2 = v4l2_get_subdevdata(sd);
>   struct iss_csi2_ctrl_cfg *ctrl = >ctrl;
> + int index = local->index;
> +
> + /* FIXME: this is actually a hack! */
> + if (is_media_entity_v4l2_subdev(remote->entity))
> + index |= 2 << 16;
> 
>   /*
>* The ISS core doesn't support pipelines with multiple video outputs.
>* Revisit this when it will be implemented, and return -EBUSY for now.
>*/
> 
> - switch (local->index | media_entity_type(remote->entity)) {
> - case CSI2_PAD_SOURCE | MEDIA_ENT_T_DEVNODE:
> + switch (index) {
> + case CSI2_PAD_SOURCE:
>   if (flags & MEDIA_LNK_FL_ENABLED) {
>   if (csi2->output & ~CSI2_OUTPUT_MEMORY)
>   return -EBUSY;
> @@ -1187,7 +1192,7 @@ static int csi2_link_setup(struct media_entity
> *entity, }
>   break;
> 
> - case CSI2_PAD_SOURCE | MEDIA_ENT_T_V4L2_SUBDEV:
> + case CSI2_PAD_SOURCE | 2 << 16:
>   if (flags & MEDIA_LNK_FL_ENABLED) {
>   if (csi2->output & ~CSI2_OUTPUT_IPIPEIF)
>   return -EBUSY;
> diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c
> b/drivers/staging/media/omap4iss/iss_ipipeif.c index
> 44c432ef2ac5..e46b2c07bd5d 100644
> --- a/drivers/staging/media/omap4iss/iss_ipipeif.c
> +++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
> @@ -662,9 +662,14 @@ static int ipipeif_link_setup(struct media_entity
> *entity, struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>   struct iss_ipipeif_device *ipipeif = v4l2_get_subdevdata(sd);
>   struct iss_device *iss = to_iss_device(ipipeif);
> + int index = local->index;
> 
> - switch (local->index | media_entity_type(remote->entity)) {
> - case IPIPEIF_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> + /* FIXME: this is actually a hack! */
> + if (is_media_entity_v4l2_subdev(remote->entity))
> + index |= 2 << 16;
> +
> + switch (index) {
> + case IPIPEIF_PAD_SINK | 2 << 16:
>   /* Read from the sensor CSI2a or CSI2b. */
>   if (!(flags & MEDIA_LNK_FL_ENABLED)) {
>   ipipeif->input = IPIPEIF_INPUT_NONE;
> @@ -681,7 +686,7 @@ static int ipipeif_link_setup(struct media_entity
> *entity,
> 
>   break;
> 
> - case IPIPEIF_PAD_SOURCE_ISIF_SF | MEDIA_ENT_T_DEVNODE:
> + case IPIPEIF_PAD_SOURCE_ISIF_SF:
>   /* Write to memory */
>   if (flags & MEDIA_LNK_FL_ENABLED) {
>   if (ipipeif->output & ~IPIPEIF_OUTPUT_MEMORY)
> @@ -692,7 +697,7 @@ static int ipipeif_link_setup(struct media_entity
> *entity, }
>   break;
> 
> - case IPIPEIF_PAD_SOURCE_VP | MEDIA_ENT_T_V4L2_SUBDEV:
> + case IPIPEIF_PAD_SOURCE_VP | 2 << 16:
>   /* Send to IPIPE/RESIZER */
>   if (flags & MEDIA_LNK_FL_ENABLED) {
>   if (ipipeif->output & ~IPIPEIF_OUTPUT_VP)
> diff --git a/drivers/staging/media/omap4iss/iss_resizer.c
> b/drivers/staging/media/omap4iss/iss_resizer.c index
> b659e465cb56..bc5001002cc5 100644
> --- a/drivers/staging/media/omap4iss/iss_resizer.c
> +++ b/drivers/staging/media/omap4iss/iss_resizer.c
> @@ -717,9 +717,14 @@ static int resizer_link_setup(struct media_entity
> *entity, struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>   struct iss_resizer_device *resizer = v4l2_get_subdevdata(sd);
>   struct iss_device *iss = to_iss_device(resizer);
> + int index = local->index;
> 
> - switch (local->index | media_entity_type(remote->entity)) {
> - case RESIZER_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> + /* FIXME: this is actually a hack! */
> + if (is_media_entity_v4l2_subdev(remote->entity))
> + index |= 2 << 16;
> +
> + switch (index) {
> + case RESIZER_PAD_SINK | 2 << 16:
>   /* Read from IPIPE or IPIPEIF. */
>   if (!(flags & MEDIA_LNK_FL_ENABLED)) {
>   resizer->input = RESIZER_INPUT_NONE;
> @@ -737,7 +742,7 @@ static int resizer_link_setup(struct media_entity
> *entity,
> 
>   break;
> 
> - case RESIZER_PAD_SOURCE_MEM | MEDIA_ENT_T_DEVNODE:
> + case RESIZER_PAD_SOURCE_MEM :

There's an unneeded space before the :.

>   /* Write to memory */
>   if (flags & MEDIA_LNK_FL_ENABLED) {
>   if (resizer->output & ~RESIZER_OUTPUT_MEMORY)

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v8 32/55] [media] media: use macros to check for V4L2 subdev entities

[Laurent Pinchart]

; diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> b/drivers/media/platform/xilinx/xilinx-dma.c index
> 88cd789cdaf7..8e14841bf445 100644
> --- a/drivers/media/platform/xilinx/xilinx-dma.c
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -49,8 +49,7 @@ xvip_dma_remote_subdev(struct media_pad *local, u32 *pad)
>   struct media_pad *remote;
> 
>   remote = media_entity_remote_pad(local);
> - if (remote == NULL ||
> - media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
>   return NULL;
> 
>   if (pad)
> @@ -113,8 +112,7 @@ static int xvip_pipeline_start_stop(struct xvip_pipeline
> *pipe, bool start) break;
> 
>   pad = media_entity_remote_pad(pad);
> - if (pad == NULL ||
> - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>   break;
> 
>   entity = pad->entity;
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
> b/drivers/media/v4l2-core/v4l2-subdev.c index e6e1115d8215..60da43772de9
> 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -526,7 +526,7 @@ static int
>  v4l2_subdev_link_validate_get_format(struct media_pad *pad,
>struct v4l2_subdev_format *fmt)
>  {
> - if (media_entity_type(pad->entity) == MEDIA_ENT_T_V4L2_SUBDEV) {
> + if (is_media_entity_v4l2_subdev(pad->entity)) {
>   struct v4l2_subdev *sd =
>   media_entity_to_v4l2_subdev(pad->entity);
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index
> 92573fa852a9..16763e0831f2 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -148,7 +148,7 @@ static void vpfe_prepare_pipeline(struct
> vpfe_video_device *video) while ((entity =
> media_entity_graph_walk_next())) {
>   if (entity == >video_dev.entity)
>   continue;
> - if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE)
> + if ((!is_media_entity_v4l2_io(remote->entity))
>   continue;
>   far_end = to_vpfe_video(media_entity_to_video_device(entity));
>   if (far_end->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
> @@ -293,7 +293,7 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline
> *pipe) media_entity_graph_walk_start(, entity);
>   while ((entity = media_entity_graph_walk_next())) {
> 
> - if (media_entity_type(entity) == MEDIA_ENT_T_DEVNODE)
> + if !is_media_entity_v4l2_subdev(entity))

With these two chunks fixed,

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

I'm wondering, however, why you replace some occurrences of == 
MEDIA_ENT_T_DEVNODE with !is_media_entity_v4l2_subdev and some other with 
is_media_entity_v4l2_io.

>   continue;
>   subdev = media_entity_to_v4l2_subdev(entity);
>   ret = v4l2_subdev_call(subdev, video, s_stream, 1);
> @@ -334,7 +334,7 @@ static int vpfe_pipeline_disable(struct vpfe_pipeline
> *pipe)
> 
>   while ((entity = media_entity_graph_walk_next())) {
> 
> - if (media_entity_type(entity) == MEDIA_ENT_T_DEVNODE)
> + if (!is_media_entity_v4l2_subdev(entity))
>   continue;
>   subdev = media_entity_to_v4l2_subdev(entity);
>   ret = v4l2_subdev_call(subdev, video, s_stream, 0);
> diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index 40591963b42b..44b88ff3ba83
> 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -397,7 +397,7 @@ static int iss_pipeline_pm_use_count(struct media_entity
> *entity) media_entity_graph_walk_start(, entity);
> 
>   while ((entity = media_entity_graph_walk_next())) {
> - if (media_entity_type(entity) == MEDIA_ENT_T_DEVNODE)
> + if (is_media_entity_v4l2_io(entity))
>   use += entity->use_count;
>   }
> 
> @@ -419,7 +419,7 @@ static int iss_pipeline_pm_power_one(struct media_entity
> *entity, int change) {
>   struct v4l2_subdev *subdev;
> 
> - subdev = media_entity_type(entity) == MEDIA_ENT_T_V4L2_SUBDEV
> + subdev = is_media_entity_v4l2_subdev(entity)
>  ? media_entity_to_v4l2_subdev(entity) : NULL;
> 
>   if (entity->use_count == 0 && change

Re: [PATCH v8 37/55] [media] omap4iss: stop MEDIA_ENT_T_V4L2_SUBDEV abuse

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Sunday 30 August 2015 00:06:48 Mauro Carvalho Chehab wrote:
> This driver is abusing MEDIA_ENT_T_V4L2_SUBDEV, as it uses a
> hack to check if the remote entity is a subdev. Get rid of it.

While I agree with the idea of the patch I don't think this is a hack, it was 
a totally valid implementation with the existing API.

> Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
> 
> diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c
> b/drivers/staging/media/omap4iss/iss_ipipe.c index
> e1a7b7ba7362..eb91ec48a21e 100644
> --- a/drivers/staging/media/omap4iss/iss_ipipe.c
> +++ b/drivers/staging/media/omap4iss/iss_ipipe.c
> @@ -447,8 +447,11 @@ static int ipipe_link_setup(struct media_entity
> *entity, struct iss_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
>   struct iss_device *iss = to_iss_device(ipipe);
> 
> - switch (local->index | media_entity_type(remote->entity)) {
> - case IPIPE_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> + if (!is_media_entity_v4l2_subdev(remote->entity))
> + return -EINVAL;
> +

Furthermore the ipipe entity is never connected to anything else than a 
subdev, so you can remove this check completely.

I'd rewrite the subject line as "omap4iss: ipipe: Don't check entity type 
needlessly during link setup" and update the commit message accordingly.

> + switch (local->index) {
> + case IPIPE_PAD_SINK:
>   /* Read from IPIPEIF. */
>   if (!(flags & MEDIA_LNK_FL_ENABLED)) {
>   ipipe->input = IPIPE_INPUT_NONE;
> @@ -463,7 +466,7 @@ static int ipipe_link_setup(struct media_entity *entity,
> 
>   break;
> 
> - case IPIPE_PAD_SOURCE_VP | MEDIA_ENT_T_V4L2_SUBDEV:
> + case IPIPE_PAD_SOURCE_VP:
>   /* Send to RESIZER */
>       if (flags & MEDIA_LNK_FL_ENABLED) {
>   if (ipipe->output & ~IPIPE_OUTPUT_VP)

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/5] [media] staging: omap4iss: separate links creation from entities init

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Thursday 03 September 2015 18:00:32 Javier Martinez Canillas wrote:
> The omap4iss driver initializes the entities and creates the pads links
> before the entities are registered with the media device. This does not
> work now that object IDs are used to create links so the media_device
> has to be set.
> 
> Split out the pads links creation from the entity initialization so are
> made after the entities registration.
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> ---
> 
>  drivers/staging/media/omap4iss/iss.c | 101 +++-
>  drivers/staging/media/omap4iss/iss_csi2.c|  35 +++---
>  drivers/staging/media/omap4iss/iss_csi2.h|   1 +
>  drivers/staging/media/omap4iss/iss_ipipeif.c |  29 
>  drivers/staging/media/omap4iss/iss_ipipeif.h |   1 +
>  drivers/staging/media/omap4iss/iss_resizer.c |  29 
>  drivers/staging/media/omap4iss/iss_resizer.h |   1 +
>  7 files changed, 132 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index 44b88ff3ba83..076ddd412201
> 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -1272,6 +1272,68 @@ done:
>   return ret;
>  }
> 
> +/*
> + * iss_create_pads_links() - Pads links creation for the subdevices

Could you please s/pads_links/links/ and s/pads links/links/ ?

Apart from that,

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

> + * @iss : Pointer to ISS device
> + *
> + * return negative error code or zero on success
> + */
> +static int iss_create_pads_links(struct iss_device *iss)
> +{
> + int ret;
> +
> + ret = omap4iss_csi2_create_pads_links(iss);
> + if (ret < 0) {
> + dev_err(iss->dev, "CSI2 pads links creation failed\n");
> + return ret;
> + }
> +
> + ret = omap4iss_ipipeif_create_pads_links(iss);
> + if (ret < 0) {
> + dev_err(iss->dev, "ISP IPIPEIF pads links creation failed\n");
> + return ret;
> + }
> +
> + ret = omap4iss_resizer_create_pads_links(iss);
> + if (ret < 0) {
> + dev_err(iss->dev, "ISP RESIZER pads links creation failed\n");
> + return ret;
> + }
> +
> + /* Connect the submodules. */
> + ret = media_create_pad_link(
> + >csi2a.subdev.entity, CSI2_PAD_SOURCE,
> + >ipipeif.subdev.entity, IPIPEIF_PAD_SINK, 0);
> + if (ret < 0)
> + return ret;
> +
> + ret = media_create_pad_link(
> + >csi2b.subdev.entity, CSI2_PAD_SOURCE,
> + >ipipeif.subdev.entity, IPIPEIF_PAD_SINK, 0);
> + if (ret < 0)
> + return ret;
> +
> + ret = media_create_pad_link(
> + >ipipeif.subdev.entity, IPIPEIF_PAD_SOURCE_VP,
> + >resizer.subdev.entity, RESIZER_PAD_SINK, 0);
> + if (ret < 0)
> + return ret;
> +
> + ret = media_create_pad_link(
> + >ipipeif.subdev.entity, IPIPEIF_PAD_SOURCE_VP,
> + >ipipe.subdev.entity, IPIPE_PAD_SINK, 0);
> + if (ret < 0)
> + return ret;
> +
> + ret = media_create_pad_link(
> + >ipipe.subdev.entity, IPIPE_PAD_SOURCE_VP,
> + >resizer.subdev.entity, RESIZER_PAD_SINK, 0);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +};
> +
>  static void iss_cleanup_modules(struct iss_device *iss)
>  {
>   omap4iss_csi2_cleanup(iss);
> @@ -1314,41 +1376,8 @@ static int iss_initialize_modules(struct iss_device
> *iss) goto error_resizer;
>   }
> 
> - /* Connect the submodules. */
> - ret = media_create_pad_link(
> - >csi2a.subdev.entity, CSI2_PAD_SOURCE,
> - >ipipeif.subdev.entity, IPIPEIF_PAD_SINK, 0);
> - if (ret < 0)
> - goto error_link;
> -
> - ret = media_create_pad_link(
> - >csi2b.subdev.entity, CSI2_PAD_SOURCE,
> - >ipipeif.subdev.entity, IPIPEIF_PAD_SINK, 0);
> - if (ret < 0)
> - goto error_link;
> -
> - ret = media_create_pad_link(
> - >ipipeif.subdev.entity, IPIPEIF_PAD_SOURCE_VP,
> - >resizer.subdev.entity, RESIZER_PAD_SINK, 0);
> - if (ret < 0)
> - goto error_link;
> -
> - ret = media_create_pad_link(
> -   

Re: [PATCH v8 02/55] [media] staging: omap4iss: get entity ID using media_entity_id()

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Sunday 30 August 2015 00:06:13 Mauro Carvalho Chehab wrote:
> From: Javier Martinez Canillas <jav...@osg.samsung.com>
> 
> Assessing media_entity ID should now use media_entity_id() macro to

Did you mean "accessing" ?

> obtain the entity ID, as a next patch will remove the .id field from
> struct media_entity .
> 
> So, get rid of it, otherwise the omap4iss driver will fail to build.
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Acked-by: Hans Verkuil <hans.verk...@cisco.com>
> Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>

With the typo fixed,

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

> diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index 9bfb725b9986..e54a7afd31de
> 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -607,7 +607,7 @@ static int iss_pipeline_disable(struct iss_pipeline
> *pipe, * crashed. Mark it as such, the ISS will be reset when
>* applications will release it.
>*/
> - iss->crashed |= 1U << subdev->entity.id;
> + iss->crashed |= 1U << media_entity_id(>entity);
>   failure = -ETIMEDOUT;
>   }
>   }
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index
> bae67742706f..25e9e7a6b99d 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -784,7 +784,7 @@ iss_video_streamon(struct file *file, void *fh, enum
> v4l2_buf_type type) entity = >video.entity;
>   media_entity_graph_walk_start(, entity);
>   while ((entity = media_entity_graph_walk_next()))
> - pipe->entities |= 1 << entity->id;
> +         pipe->entities |= 1 << media_entity_id(entity);
> 
>   /* Verify that the currently configured format matches the output of
>* the connected subdev.

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] /media/davinci_vpfe/dm365_resizer.c:Bug containing more than 80 characters in a line is fixed.

[Laurent Pinchart]

Hi Ravinder,

Thank you for the patch.

I'm afraid the patch doesn't apply on top of the mainline kernel.

On Wednesday 19 August 2015 21:14:56 Ravinder Atla wrote:
> Signed-off-by: Ravinder Atla <rednivara...@gmail.com>
> ---
>  drivers/staging/media/davinci_vpfe/dm365_resizer.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> b/drivers/staging/media/davinci_vpfe/dm365_resizer.c index 6218230..273aea3
> 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> @@ -1393,8 +1393,8 @@ resizer_try_format(struct v4l2_subdev *sd, struct
> v4l2_subdev_pad_config *cfg, * return -EINVAL or zero on success
>   */
>  static int resizer_set_format(struct v4l2_subdev *sd,
> - struct v4l2_subdev_pad_config *cfg, struct v4l2_subdev_format *
> - fmt)
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *fmt)
>  {
>   struct vpfe_resizer_device *resizer = v4l2_get_subdevdata(sd);
>   struct v4l2_mbus_framefmt *format;
> @@ -1454,8 +1454,8 @@ static int resizer_set_format(struct v4l2_subdev *sd,
>   * return -EINVAL or zero on success
>   */
>  static int resizer_get_format(struct v4l2_subdev *sd,
> - struct v4l2_subdev_pad_config *cfg, struct v4l2_subdev_format *
> - fmt)
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *fmt)
>  {
>   struct v4l2_mbus_framefmt *format;

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/9] drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c: use correct structure type name in sizeof

[Laurent Pinchart]

Hi Julia,

Thank you for the patch.

On Tuesday 29 July 2014 17:16:43 Julia Lawall wrote:
> From: Julia Lawall <julia.law...@lip6.fr>
> 
> Correct typo in the name of the type given to sizeof.  Because it is the
> size of a pointer that is wanted, the typo has no impact on compilation or
> execution.
> 
> This problem was found using Coccinelle (http://coccinelle.lip6.fr/).  The
> semantic patch used can be found in message 0 of this patch series.
> 
> Signed-off-by: Julia Lawall <julia.law...@lip6.fr>
> 
> ---
>  drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
> b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c index
> cda8388..255590f 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
> @@ -227,7 +227,7 @@ static int vpfe_enable_clock(struct vpfe_device
> *vpfe_dev) return 0;
> 
>   vpfe_dev->clks = kzalloc(vpfe_cfg->num_clocks *
> -sizeof(struct clock *), GFP_KERNEL);
> +sizeof(struct clk *), GFP_KERNEL);

I'd use sizeof(*vpfe_dev->clks) to avoid such issues.

Apart from that,

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

I've applied the patch to my tree with the above change, there's no need to 
resubmit if you agree with the proposal.

>   if (vpfe_dev->clks == NULL) {
>   v4l2_err(vpfe_dev->pdev->driver, "Memory allocation failed\n");
>   return -ENOMEM;

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 25/38] staging: media: davinci_vpfe: fix ipipe_mode type

[Laurent Pinchart]

Hi Andrzej,

Thank you for the patch.

On Monday 21 September 2015 15:33:57 Andrzej Hajda wrote:
> The variable can take negative values.
> 
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
> 
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
> 
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

and applied to my tree.

> ---
>  drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c index
> 2a3a56b..b1d5e23 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> @@ -254,7 +254,7 @@ int config_ipipe_hw(struct vpfe_ipipe_device *ipipe)
>   void __iomem *ipipe_base = ipipe->base_addr;
>   struct v4l2_mbus_framefmt *outformat;
>   u32 color_pat;
> - u32 ipipe_mode;
> + int ipipe_mode;
>   u32 data_path;
> 
>   /* enable clock to IPIPE */

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv2 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Laurent Pinchart]

Hi Enric,

On Thursday 10 September 2015 16:11:03 Enric Balletbo Serra wrote:
> 2015-09-09 2:40 GMT+02:00 Rob Herring <r...@kernel.org>:
> > On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> >> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> >> designed for portable devices.
> >> 
> >> You can add support to your board with current binding.
> >> 
> >> Example:
> >>   anx7814: anx7814@38 {
> >>   compatible = "analogix,anx7814";
> >>   reg = <0x38>;
> >>   pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
> >>   reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
> >>   };
> >> 
> >> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> >> ---
> >> 
> >>  .../devicetree/bindings/video/anx7814.txt  | 22 
> >>  1 file changed, 22 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/video/anx7814.txt
> >> 
> >> diff --git a/Documentation/devicetree/bindings/video/anx7814.txt
> >> b/Documentation/devicetree/bindings/video/anx7814.txt new file mode
> >> 100644
> >> index 000..a8cc746
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/video/anx7814.txt
> >> @@ -0,0 +1,22 @@
> >> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
> >> +---
> >> +
> >> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> >> +designed for portable devices.
> >> +
> >> +Required properties:
> >> +
> >> + - compatible: "analogix,anx7814"
> >> + - reg   : I2C address of the device
> >> + - pd-gpios  : Which GPIO to use for power down
> >> + - reset-gpios   : Which GPIO to use for reset
> >> +
> >> +Example:
> >> +
> >> + anx7814: anx7814@38 {
> >> + compatible = "analogix,anx7814";
> >> + reg = <0x38>;
> >> + pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
> >> + reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
> > 
> > No ports needed for describing data connections?
> 
> IMHO I'm not sure if this is applicable here, in this case the bridge
> is transparent so it's not required another device node. For example,
> I've an evaluation board, whre I connect in one side an HDMI input
> signal an in the other side a DP monitor, the driver only configures
> the chip and waits for different events (cable plug, cable unplug, etc
> ..)

But what if the chip is connected to a display controller, for instance to the 
HDMI output of an SoC ? Is that a use case for the hardware ?

-- 
Regards,

Laurent Pinchart

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel