cron job: media_tree daily build: OK

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Thu May  5 04:00:19 CEST 2016
git branch: test
git hash:   68af062b5f38510dc96635314461c6bbe1dbf2fe
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.5.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Ismael Luceno]

On 05/Mai/2016 00:14, Andrey Utkin wrote:
> On Wed, May 04, 2016 at 01:21:20PM -0300, Ismael Luceno wrote:
> > From: Andrey Utkin 
> > 
> > Such frame size is met in practice. Also report oversized frames.
> > 
> > [ismael: Reworked warning and commit message]
> > 
> > Signed-off-by: Ismael Luceno 
> 
> I object against merging the first part.
> 
> > ---
> >  drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c 
> > b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> > index 67a14c4..f98017b 100644
> > --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> > +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> > @@ -33,7 +33,7 @@
> >  #include "solo6x10-jpeg.h"
> >  
> >  #define MIN_VID_BUFFERS2
> > -#define FRAME_BUF_SIZE (196 * 1024)
> > +#define FRAME_BUF_SIZE (200 * 1024)
> 
> Please don't push this.
> It doesn't matter whether there are 196 or 200 KiB because there happen
> bigger frames.
> I don't remember details so I cannot point to all time max frame size.
> AFAIK this issue appeared on one particular customer installation. I
> don't monitor it closely right now. I think I have compiled custom
> package for that setup with FRAME_BUF_SIZE increased much more (maybe
> 10x?).

I don't quite remember the overscan, but the maximum should be around
1.2MB, so yes. If the QM hasn't been tweaked, then the image must
be terrible.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2.1 5/5] media: Support variable size IOCTL arguments

[Sakari Ailus]

Instead of checking for a strict size for the IOCTL arguments, place
minimum and maximum limits.

As an additional bonus, IOCTL handlers will be able to check whether the
caller actually set (using the argument size) the field vs. assigning it
to zero. Separate macro can be provided for that.

This will be easier for applications as well since there is no longer the
problem of setting the reserved fields zero, or at least it is a lesser
problem.

Signed-off-by: Sakari Ailus 
---
since v2:

- Use a list of supported argument sizes instead of a minimum value.

 drivers/media/media-device.c | 52 +++-
 1 file changed, 47 insertions(+), 5 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index e88e6d3..5cfeccf 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -393,32 +393,71 @@ static long copy_arg_to_user_nop(void __user *uarg, void 
*karg,
 /* Do acquire the graph mutex */
 #define MEDIA_IOC_FL_GRAPH_MUTEX   BIT(0)
 
-#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \
+#define MEDIA_IOC_SZ_ARG(__cmd, func, fl, alt_sz, from_user, to_user)  \
[_IOC_NR(MEDIA_IOC_##__cmd)] = {\
.cmd = MEDIA_IOC_##__cmd,   \
.fn = (long (*)(struct media_device *, void *))func,\
.flags = fl,\
+   .alt_arg_sizes = alt_sz,\
.arg_from_user = from_user, \
.arg_to_user = to_user, \
}
 
-#define MEDIA_IOC(__cmd, func, fl) \
-   MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
+#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \
+   MEDIA_IOC_SZ_ARG(__cmd, func, fl, NULL, from_user, to_user)
+
+#define MEDIA_IOC_SZ(__cmd, func, fl, alt_sz)  \
+   MEDIA_IOC_SZ_ARG(__cmd, func, fl, alt_sz,   \
+copy_arg_from_user, copy_arg_to_user)
+
+#define MEDIA_IOC(__cmd, func, fl) \
+   MEDIA_IOC_ARG(__cmd, func, fl,  \
+ copy_arg_from_user, copy_arg_to_user)
 
 /* the table is indexed by _IOC_NR(cmd) */
 struct media_ioctl_info {
unsigned int cmd;
long (*fn)(struct media_device *dev, void *arg);
unsigned short flags;
+   const unsigned short *alt_arg_sizes;
long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd);
long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
 };
 
+#define MASK_IOC_SIZE(cmd) \
+   ((cmd) & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT))
+
 static inline long is_valid_ioctl(const struct media_ioctl_info *info,
  unsigned int len, unsigned int cmd)
 {
-   return (_IOC_NR(cmd) >= len
-   || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0;
+   const unsigned short *alt_arg_sizes;
+
+   if (unlikely(_IOC_NR(cmd) >= len))
+   return -ENOIOCTLCMD;
+
+   info += _IOC_NR(cmd);
+
+   if (info->cmd == cmd)
+   return 0;
+
+   /*
+* Verify that the size-dependent patch of the IOCTL command
+* matches and that the size does not exceed the principal
+* argument size.
+*/
+   if (unlikely(MASK_IOC_SIZE(info->cmd) != MASK_IOC_SIZE(cmd)
+|| _IOC_SIZE(info->cmd) < _IOC_SIZE(cmd)))
+   return -ENOIOCTLCMD;
+
+   alt_arg_sizes = info->alt_arg_sizes;
+   if (unlikely(!alt_arg_sizes))
+   return -ENOIOCTLCMD;
+
+   for (; *alt_arg_sizes; alt_arg_sizes++)
+   if (_IOC_SIZE(cmd) == *alt_arg_sizes)
+   return 0;
+
+   return -ENOIOCTLCMD;
 }
 
 static long __media_device_ioctl(
@@ -445,6 +484,9 @@ static long __media_device_ioctl(
 
info->arg_from_user(karg, arg, cmd);
 
+   /* Set the rest of the argument struct to zero */
+   memset(karg + _IOC_SIZE(cmd), 0, _IOC_SIZE(info->cmd) - _IOC_SIZE(cmd));
+
if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
mutex_lock(>graph_mutex);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL for v4.6-rc1] media updates

[Stefan Lippers-Hollmann]

Hi

On 2016-05-04, Mauro Carvalho Chehab wrote:
> Em Wed, 4 May 2016 13:49:52 -0700
> Linus Torvalds  escreveu:
> > On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann  
> > wrote:  
[...]
> Stefan,
> 
> Could you please test the enclosed patch?
> 
> Regards,
> Mauro
> 
> [media] media-device: fix builds when USB or PCI is compiled as module
> 
> Just checking ifdef CONFIG_USB is not enough, if the USB is compiled
> as module. The same applies to PCI.
> 
> Compile-tested only.
> 
> So, change the logic to use, instead, IS_REACHABLE.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index b84825715f98..8c1f80ff33e3 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -842,11 +842,11 @@ struct media_device *media_device_find_devres(struct 
> device *dev)
>  }
>  EXPORT_SYMBOL_GPL(media_device_find_devres);
>  
> +#if IS_REACHABLE(CONFIG_PCI)
>  void media_device_pci_init(struct media_device *mdev,
>  struct pci_dev *pci_dev,
>  const char *name)
>  {
> -#ifdef CONFIG_PCI
>   mdev->dev = _dev->dev;
>  
>   if (name)
> @@ -862,16 +862,16 @@ void media_device_pci_init(struct media_device *mdev,
>   mdev->driver_version = LINUX_VERSION_CODE;
>  
>   media_device_init(mdev);
> -#endif
>  }
>  EXPORT_SYMBOL_GPL(media_device_pci_init);
> +#endif
>  
> +#if IS_REACHABLE(CONFIG_USB)
>  void __media_device_usb_init(struct media_device *mdev,
>struct usb_device *udev,
>const char *board_name,
>const char *driver_name)
>  {
> -#ifdef CONFIG_USB
>   mdev->dev = >dev;
>  
>   if (driver_name)
> @@ -891,9 +891,9 @@ void __media_device_usb_init(struct media_device *mdev,
>   mdev->driver_version = LINUX_VERSION_CODE;
>  
>   media_device_init(mdev);
> -#endif
>  }
>  EXPORT_SYMBOL_GPL(__media_device_usb_init);
> +#endif
>  
>  
>  #endif /* CONFIG_MEDIA_CONTROLLER */
> 
> 

This fails to build for me with:

[...]
Setup is 16348 bytes (padded to 16384 bytes).
System is 3319 kB
CRC a9178215
Kernel: arch/x86/boot/bzImage is ready  (#1)
ERROR: "__media_device_usb_init" [drivers/media/usb/siano/smsusb.ko] undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/em28xx/em28xx.ko] undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/dvb-usb/dvb-usb.ko] 
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/dvb-usb-v2/dvb_usb_v2.ko] 
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/cx231xx/cx231xx.ko] 
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/au0828/au0828.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[6]: *** [__modpost] Error 1
Makefile:1147: recipe for target 'modules' failed
[...]

I've attached my gzipped kernel configs for amd64 and i386.

Regards
Stefan Lippers-Hollmann


config-686.gz
Description: application/gzip


config-amd64.gz
Description: application/gzip


pgprsfBVBaFy0.pgp
Description: Digitale Signatur von OpenPGP

Re: [GIT PULL for v4.6-rc1] media updates

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 13:49:52 -0700
Linus Torvalds  escreveu:

> On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann  wrote:
> >
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
> >  const char *board_name,
> >  const char *driver_name)
> >  {
> > -#ifdef CONFIG_USB
> > +#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
> 
> Ok, that should be fine. Can you verify that it builds and works even
> if USB isn't compiled in, but the media core code is?
> 
> IOW, can you test the
> 
>   CONFIG_USB=m
>   CONFIG_MEDIA_CONTROLLER=y
>   CONFIG_MEDIA_SUPPORT=y
> 
> case? Judging by your oops stack trace, I think you currently have
> MEDIA_SUPPORT=m.

I think we could use, instead:

#if IS_REACHABLE(CONFIG_USB)

This macro is defined as:
/*
 * IS_REACHABLE(CONFIG_FOO) evaluates to 1 if the currently compiled
 * code can call a function defined in code compiled based on 
CONFIG_FOO.
 * This is similar to IS_ENABLED(), but returns false when invoked from
 * built-in code when CONFIG_FOO is set to 'm'.
 */
#define IS_REACHABLE(option) (config_enabled(option) || \
 (config_enabled(option##_MODULE) && config_enabled(MODULE)))

And we use it already on other places where we have dependencies
like that.



Btw, there are also some helper function there to initialize
for PCI devices.

> Also, I do wonder if we should move that #if to _outside_ the
> function. Because inside the function, things will compile but
> silently not work (like you found), if it is ever mis-used. Outside
> that function, you'll get link-errors if you try to misuse that
> function.

Yeah, that makes sense. This function is a helper function that
it is used only when CONFIG_USB.

The following (untested) patch should do the work.

Stefan,

Could you please test the enclosed patch?

Regards,
Mauro

[media] media-device: fix builds when USB or PCI is compiled as module

Just checking ifdef CONFIG_USB is not enough, if the USB is compiled
as module. The same applies to PCI.

Compile-tested only.

So, change the logic to use, instead, IS_REACHABLE.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index b84825715f98..8c1f80ff33e3 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -842,11 +842,11 @@ struct media_device *media_device_find_devres(struct 
device *dev)
 }
 EXPORT_SYMBOL_GPL(media_device_find_devres);
 
+#if IS_REACHABLE(CONFIG_PCI)
 void media_device_pci_init(struct media_device *mdev,
   struct pci_dev *pci_dev,
   const char *name)
 {
-#ifdef CONFIG_PCI
mdev->dev = _dev->dev;
 
if (name)
@@ -862,16 +862,16 @@ void media_device_pci_init(struct media_device *mdev,
mdev->driver_version = LINUX_VERSION_CODE;
 
media_device_init(mdev);
-#endif
 }
 EXPORT_SYMBOL_GPL(media_device_pci_init);
+#endif
 
+#if IS_REACHABLE(CONFIG_USB)
 void __media_device_usb_init(struct media_device *mdev,
 struct usb_device *udev,
 const char *board_name,
 const char *driver_name)
 {
-#ifdef CONFIG_USB
mdev->dev = >dev;
 
if (driver_name)
@@ -891,9 +891,9 @@ void __media_device_usb_init(struct media_device *mdev,
mdev->driver_version = LINUX_VERSION_CODE;
 
media_device_init(mdev);
-#endif
 }
 EXPORT_SYMBOL_GPL(__media_device_usb_init);
+#endif
 
 
 #endif /* CONFIG_MEDIA_CONTROLLER */


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL for v4.6-rc1] media updates

[Stefan Lippers-Hollmann]

Hi

On 2016-05-04, Linus Torvalds wrote:
> On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann  wrote:
> >
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
> >  const char *board_name,
> >  const char *driver_name)
> >  {
> > -#ifdef CONFIG_USB
> > +#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)  
> 
> Ok, that should be fine. Can you verify that it builds and works even
> if USB isn't compiled in, but the media core code is?
> 
> IOW, can you test the
> 
>   CONFIG_USB=m
>   CONFIG_MEDIA_CONTROLLER=y
>   CONFIG_MEDIA_SUPPORT=y

Builds (without warnings in drivers/media/media-device.*) and works fine
as well.

> case? Judging by your oops stack trace, I think you currently have
> MEDIA_SUPPORT=m.

My usual configuration (which, as mentioned in the previous mail, now 
builds and works as well) is:

CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_USB=m

> Also, I do wonder if we should move that #if to _outside_ the
> function. Because inside the function, things will compile but
> silently not work (like you found), if it is ever mis-used. Outside
> that function, you'll get link-errors if you try to misuse that
> function.

That would probably be the best approach.

Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Andrey Utkin]

On Wed, May 04, 2016 at 01:21:20PM -0300, Ismael Luceno wrote:
> From: Andrey Utkin 
> 
> Such frame size is met in practice. Also report oversized frames.
> 
> [ismael: Reworked warning and commit message]
> 
> Signed-off-by: Ismael Luceno 

I object against merging the first part.

> ---
>  drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c 
> b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> index 67a14c4..f98017b 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> @@ -33,7 +33,7 @@
>  #include "solo6x10-jpeg.h"
>  
>  #define MIN_VID_BUFFERS  2
> -#define FRAME_BUF_SIZE   (196 * 1024)
> +#define FRAME_BUF_SIZE   (200 * 1024)

Please don't push this.
It doesn't matter whether there are 196 or 200 KiB because there happen
bigger frames.
I don't remember details so I cannot point to all time max frame size.
AFAIK this issue appeared on one particular customer installation. I
don't monitor it closely right now. I think I have compiled custom
package for that setup with FRAME_BUF_SIZE increased much more (maybe
10x?).
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL for v4.6-rc1] media updates

[Linus Torvalds]

On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann  wrote:
>
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
>  const char *board_name,
>  const char *driver_name)
>  {
> -#ifdef CONFIG_USB
> +#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)

Ok, that should be fine. Can you verify that it builds and works even
if USB isn't compiled in, but the media core code is?

IOW, can you test the

  CONFIG_USB=m
  CONFIG_MEDIA_CONTROLLER=y
  CONFIG_MEDIA_SUPPORT=y

case? Judging by your oops stack trace, I think you currently have
MEDIA_SUPPORT=m.

Also, I do wonder if we should move that #if to _outside_ the
function. Because inside the function, things will compile but
silently not work (like you found), if it is ever mis-used. Outside
that function, you'll get link-errors if you try to misuse that
function.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/9] i2c mux cleanup and locking update

[Wolfram Sang]

On Wed, May 04, 2016 at 10:15:26PM +0200, Peter Rosin wrote:
> Hi!
> 
> I have a pair of boards with this i2c topology:
> 
>GPIO ---|  -- BAT1
> |  v /
>I2C  -+--B---+ MUX
>  |   \
>EEPROM -- BAT2
> 
>   (B denotes the boundary between the boards)
> 
> The problem with this is that the GPIO controller sits on the same i2c bus
> that it MUXes. For pca954x devices this is worked around by using unlocked
> transfers when updating the MUX. I have no such luck as the GPIO is a general
> purpose IO expander and the MUX is just a random bidirectional MUX, unaware
> of the fact that it is muxing an i2c bus. Extending unlocked transfers
> into the GPIO subsystem is too ugly to even think about. But the general hw
> approach is sane in my opinion, with the number of connections between the
> two boards minimized. To put it plainly, I need support for it.
> 
> So, I observe that while it is needed to have the i2c bus locked during the
> actual MUX update in order to avoid random garbage on the slave side, it
> is not strictly a must to have it locked over the whole sequence of a full
> select-transfer-deselect operation. The MUX itself needs to be locked, so
> transfers to clients behind the mux are serialized, and the MUX needs to be
> stable during all i2c traffic (otherwise individual mux slave segments
> might see garbage).
> 
> This series accomplishes this by adding code to i2c-mux-gpio and
> i2c-mux-pinctrl that determines if all involved devices used to update the
> mux are controlled by the same root i2c adapter that is muxed. When this
> is the case, the select-transfer-deselect operations should be locked
> individually to avoid the deadlock. The i2c bus *is* still locked
> during muxing, since the muxing happens as part of i2c transfers. This
> is true even if the MUX is updated with several transfers to the GPIO (at
> least as long as *all* MUX changes are using the i2c master bus). A lock
> is added to i2c adapters that muxes on that adapter grab, so that transfers
> through the muxes are serialized.
> 
> Concerns:
> - The locking is perhaps too complex?
> - I worry about the priority inheritance aspect of the adapter lock. When
>   the transfers behind the mux are divided into select-transfer-deselect all
>   locked individually, low priority transfers get more chances to interfere
>   with high priority transfers.
> - When doing an i2c_transfer() in_atomic() context or with irqs_disabled(),
>   there is a higher possibility that the mux is not returned to its idle
>   state after a failed (-EAGAIN) transfer due to trylock.
> - Is the detection of i2c-controlled gpios and pinctrls sane (i.e. the
>   usage of the new i2c_root_adapter() function in 18/24)?
> 
> The first half (patches 01-15 in v7) of what was originally part of this
> series have already been scheduled for 4.6. So, this is the second half
> (patches 16-24 in v7, patches 1-9 in v9).
> 
> To summarize the series, there is some preparatory locking changes in
> in 1/9 and the real meat is in 3/9. There is some documentation added in
> 4/9 while 5/9 and after are cleanups to existing drivers utilizing
> the new stuff.
> 
> PS. needs a bunch of testing, I do not have access to all the involved hw.
> 
> This second half of the series is planned to be merged with 4.7 and can
> also be pulled from github, if that is preferred:
> 

Applied all to for-next, thanks for keeping at it!



signature.asc
Description: PGP signature

[PATCH v9 1/9] i2c: allow adapter drivers to override the adapter locking

[Peter Rosin]

Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
unlock_bus ops in the adapter. These funcs/ops take an additional flags
argument that indicates for what purpose the adapter is locked.

There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they
are both implemented the same. For now. Locking the root adapter means
that the whole bus is locked, locking the segment means that only the
current bus segment is locked (i.e. i2c traffic on the parent side of
a mux is still allowed even if the child side of the mux is locked).

Also support a trylock_bus op (but no function to call it, as it is not
expected to be needed outside of the i2c core).

Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking
scheme (i.e. lock with the I2C_LOCK_ROOT_ADAPTER flag).

Locking the root adapter and locking the segment is the same thing for
all root adapters (e.g. in the normal case of a simple topology with no
i2c muxes). The two locking variants are also the same for traditional
muxes (aka parent-locked muxes). These muxes traverse the tree, locking
each level as they go until they reach the root. This patch is preparatory
for a later patch in the series introducing mux-locked muxes, which behave
differently depending on the requested locking. Since all current users
are using i2c_lock_adapter, which is a wrapper for I2C_LOCK_ROOT_ADAPTER,
we only need to annotate the calls that will not need to lock the root
adapter for mux-locked muxes. I.e. the instances that needs to use
I2C_LOCK_SEGMENT instead of i2c_lock_adapter/I2C_LOCK_ROOT_ADAPTER. Those
instances are in the i2c_transfer and i2c_smbus_xfer functions, so that
mux-locked muxes can single out normal i2c accesses to its slave side
and adjust the locking for those accesses.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c | 41 +++--
 include/linux/i2c.h| 44 ++--
 2 files changed, 69 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 4979728f7fb2..7ef5bd085476 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -954,10 +954,13 @@ static int i2c_check_addr_busy(struct i2c_adapter 
*adapter, int addr)
 }
 
 /**
- * i2c_lock_adapter - Get exclusive access to an I2C bus segment
+ * i2c_adapter_lock_bus - Get exclusive access to an I2C bus segment
  * @adapter: Target I2C bus segment
+ * @flags: I2C_LOCK_ROOT_ADAPTER locks the root i2c adapter, I2C_LOCK_SEGMENT
+ * locks only this branch in the adapter tree
  */
-void i2c_lock_adapter(struct i2c_adapter *adapter)
+static void i2c_adapter_lock_bus(struct i2c_adapter *adapter,
+unsigned int flags)
 {
struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
 
@@ -966,27 +969,32 @@ void i2c_lock_adapter(struct i2c_adapter *adapter)
else
rt_mutex_lock(>bus_lock);
 }
-EXPORT_SYMBOL_GPL(i2c_lock_adapter);
 
 /**
- * i2c_trylock_adapter - Try to get exclusive access to an I2C bus segment
+ * i2c_adapter_trylock_bus - Try to get exclusive access to an I2C bus segment
  * @adapter: Target I2C bus segment
+ * @flags: I2C_LOCK_ROOT_ADAPTER trylocks the root i2c adapter, 
I2C_LOCK_SEGMENT
+ * trylocks only this branch in the adapter tree
  */
-static int i2c_trylock_adapter(struct i2c_adapter *adapter)
+static int i2c_adapter_trylock_bus(struct i2c_adapter *adapter,
+  unsigned int flags)
 {
struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
 
if (parent)
-   return i2c_trylock_adapter(parent);
+   return parent->trylock_bus(parent, flags);
else
return rt_mutex_trylock(>bus_lock);
 }
 
 /**
- * i2c_unlock_adapter - Release exclusive access to an I2C bus segment
+ * i2c_adapter_unlock_bus - Release exclusive access to an I2C bus segment
  * @adapter: Target I2C bus segment
+ * @flags: I2C_LOCK_ROOT_ADAPTER unlocks the root i2c adapter, I2C_LOCK_SEGMENT
+ * unlocks only this branch in the adapter tree
  */
-void i2c_unlock_adapter(struct i2c_adapter *adapter)
+static void i2c_adapter_unlock_bus(struct i2c_adapter *adapter,
+  unsigned int flags)
 {
struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
 
@@ -995,7 +1003,6 @@ void i2c_unlock_adapter(struct i2c_adapter *adapter)
else
rt_mutex_unlock(>bus_lock);
 }
-EXPORT_SYMBOL_GPL(i2c_unlock_adapter);
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
 struct i2c_client *client)
@@ -1541,6 +1548,12 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
return -EINVAL;
}
 
+   if (!adap->lock_bus) {
+   adap->lock_bus = i2c_adapter_lock_bus;
+   adap->trylock_bus = i2c_adapter_trylock_bus;
+   

[PATCH v9 4/9] i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology | 370 +
 MAINTAINERS|   1 +
 2 files changed, 371 insertions(+)
 create mode 100644 Documentation/i2c/i2c-topology

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
new file mode 100644
index ..27bfd682808d
--- /dev/null
+++ b/Documentation/i2c/i2c-topology
@@ -0,0 +1,370 @@
+I2C topology
+
+
+There are a couple of reasons for building more complex i2c topologies
+than a straight-forward i2c bus with one adapter and one or more devices.
+
+1. A mux may be needed on the bus to prevent address collisions.
+
+2. The bus may be accessible from some external bus master, and arbitration
+   may be needed to determine if it is ok to access the bus.
+
+3. A device (particularly RF tuners) may want to avoid the digital noise
+   from the i2c bus, at least most of the time, and sits behind a gate
+   that has to be operated before the device can be accessed.
+
+Etc
+
+These constructs are represented as i2c adapter trees by Linux, where
+each adapter has a parent adapter (except the root adapter) and zero or
+more child adapters. The root adapter is the actual adapter that issues
+i2c transfers, and all adapters with a parent are part of an "i2c-mux"
+object (quoted, since it can also be an arbitrator or a gate).
+
+Depending of the particular mux driver, something happens when there is
+an i2c transfer on one of its child adapters. The mux driver can
+obviously operate a mux, but it can also do arbitration with an external
+bus master or open a gate. The mux driver has two operations for this,
+select and deselect. select is called before the transfer and (the
+optional) deselect is called after the transfer.
+
+
+Locking
+===
+
+There are two variants of locking available to i2c muxes, they can be
+mux-locked or parent-locked muxes. As is evident from below, it can be
+useful to know if a mux is mux-locked or if it is parent-locked. The
+following list was correct at the time of writing:
+
+In drivers/i2c/muxes/
+i2c-arb-gpio-challengeParent-locked
+i2c-mux-gpio  Normally parent-locked, mux-locked iff
+  all involved gpio pins are controlled by the
+  same i2c root adapter that they mux.
+i2c-mux-pca9541   Parent-locked
+i2c-mux-pca954x   Parent-locked
+i2c-mux-pinctrl   Normally parent-locked, mux-locked iff
+  all involved pinctrl devices are controlled
+  by the same i2c root adapter that they mux.
+i2c-mux-reg   Parent-locked
+
+In drivers/iio/
+imu/inv_mpu6050/  Parent-locked
+
+In drivers/media/
+dvb-frontends/m88ds3103   Parent-locked
+dvb-frontends/rtl2830 Parent-locked
+dvb-frontends/rtl2832 Parent-locked
+dvb-frontends/si2168  Parent-locked
+usb/cx231xx/  Parent-locked
+
+
+Mux-locked muxes
+
+
+Mux-locked muxes does not lock the entire parent adapter during the
+full select-transfer-deselect transaction, only the muxes on the parent
+adapter are locked. Mux-locked muxes are mostly interesting if the
+select and/or deselect operations must use i2c transfers to complete
+their tasks. Since the parent adapter is not fully locked during the
+full transaction, unrelated i2c transfers may interleave the different
+stages of the transaction. This has the benefit that the mux driver
+may be easier and cleaner to implement, but it has some caveats.
+
+ML1. If you build a topology with a mux-locked mux being the parent
+ of a parent-locked mux, this might break the expectation from the
+ parent-locked mux that the root adapter is locked during the
+ transaction.
+
+ML2. It is not safe to build arbitrary topologies with two (or more)
+ mux-locked muxes that are not siblings, when there are address
+ collisions between the devices on the child adapters of these
+ non-sibling muxes.
+
+ I.e. the select-transfer-deselect transaction targeting e.g. device
+ address 0x42 behind mux-one may be interleaved with a similar
+ operation targeting device address 0x42 behind mux-two. The
+ intension with such a topology would in this hypothetical example
+ be that mux-one and mux-two should not be selected simultaneously,
+ but mux-locked muxes do not guarantee that in all topologies.
+
+ML3. A mux-locked mux cannot be used by a driver for auto-closing
+ gates/muxes, i.e. something that closes automatically after a given
+ number (one, in most cases) of i2c transfers. Unrelated i2c transfers
+ may creep in and close prematurely.
+
+ML4. If any non-i2c operation in the mux driver changes the i2c mux state,
+ the driver has to lock the root adapter during that operation.
+ Otherwise garbage may appear on the bus as seen from devices
+ behind the mux, when an unrelated i2c 

[PATCH v9 5/9] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

[Peter Rosin]

The root i2c adapter lock is then no longer held by the i2c mux during
accesses behind the i2c gate, and such accesses need to take that lock
just like any other ordinary i2c accesses do.

So, declare the i2c gate mux-locked, and zap the code that makes the
unlocked i2c accesses and just use ordinary regmap_write accesses.

This also happens to fix the deadlock described in
http://patchwork.ozlabs.org/patch/584776/ authored by
Adriana Reus  and submitted by
Daniel Baluta 

--8<--
iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock

This deadlock occurs if the accel/gyro and the sensor on the auxiliary
I2C (in my setup it's an ak8975) are working at the same time.

Scenario:

  T1T2
   
inv_mpu6050_read_fifo  aux sensor op (eg. ak8975_read_raw)
| |
mutex_lock(_dev->mlock)   i2c_transfer
| |
i2c transaction i2c adapter lock
| |
i2c adapter locki2c_mux_master_xfer
  |
inv_mpu6050_select_bypass
  |
mutex_lock(_dev->mlock)

When we operate on an mpu sensor the order of locking is mpu lock
followed by the i2c adapter lock. However, when we operate the auxiliary
sensor the order of locking is the other way around.

...
--8<--

The reason this patch fixes the deadlock is that T2 does not grab the
i2c adapter lock until the very end (and grabs the newfangled i2c mux
lock where it previously grabbed the i2c adapter lock).

Acked-by: Jonathan Cameron 
Acked-by: Daniel Baluta 
Tested-by: Crestez Dan Leonard 
Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology|  2 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 52 ++-
 2 files changed, 11 insertions(+), 43 deletions(-)

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
index 27bfd682808d..69b008518454 100644
--- a/Documentation/i2c/i2c-topology
+++ b/Documentation/i2c/i2c-topology
@@ -50,7 +50,7 @@ i2c-mux-pinctrl   Normally parent-locked, mux-locked 
iff
 i2c-mux-reg   Parent-locked
 
 In drivers/iio/
-imu/inv_mpu6050/  Parent-locked
+imu/inv_mpu6050/  Mux-locked
 
 In drivers/media/
 dvb-frontends/m88ds3103   Parent-locked
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index 3a078df84224..e25f7ef7f0ea 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -24,45 +24,16 @@ static const struct regmap_config inv_mpu_regmap_config = {
.val_bits = 8,
 };
 
-/*
- * The i2c read/write needs to happen in unlocked mode. As the parent
- * adapter is common. If we use locked versions, it will fail as
- * the mux adapter will lock the parent i2c adapter, while calling
- * select/deselect functions.
- */
-static int inv_mpu6050_write_reg_unlocked(struct i2c_client *client,
- u8 reg, u8 d)
-{
-   int ret;
-   u8 buf[2] = {reg, d};
-   struct i2c_msg msg[1] = {
-   {
-   .addr = client->addr,
-   .flags = 0,
-   .len = sizeof(buf),
-   .buf = buf,
-   }
-   };
-
-   ret = __i2c_transfer(client->adapter, msg, 1);
-   if (ret != 1)
-   return ret;
-
-   return 0;
-}
-
 static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
 {
-   struct i2c_client *client = i2c_mux_priv(muxc);
-   struct iio_dev *indio_dev = dev_get_drvdata(>dev);
+   struct iio_dev *indio_dev = i2c_mux_priv(muxc);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
int ret = 0;
 
/* Use the same mutex which was used everywhere to protect power-op */
mutex_lock(_dev->mlock);
if (!st->powerup_count) {
-   ret = inv_mpu6050_write_reg_unlocked(client,
-st->reg->pwr_mgmt_1, 0);
+   ret = regmap_write(st->map, st->reg->pwr_mgmt_1, 0);
if (ret)
goto write_error;
 
@@ -71,10 +42,9 @@ static int inv_mpu6050_select_bypass(struct i2c_mux_core 
*muxc, u32 chan_id)
}
if (!ret) {
st->powerup_count++;
-   ret = inv_mpu6050_write_reg_unlocked(client,
-st->reg->int_pin_cfg,
- 

[PATCH v9 2/9] i2c: muxes always lock the parent adapter

[Peter Rosin]

Instead of checking for i2c parent adapters for every lock/unlock, simply
override the locking for muxes to always lock/unlock the parent adapter
directly.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c | 21 +++--
 drivers/i2c/i2c-mux.c  | 30 ++
 2 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 7ef5bd085476..afdee66002db 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -962,12 +962,7 @@ static int i2c_check_addr_busy(struct i2c_adapter 
*adapter, int addr)
 static void i2c_adapter_lock_bus(struct i2c_adapter *adapter,
 unsigned int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   i2c_lock_adapter(parent);
-   else
-   rt_mutex_lock(>bus_lock);
+   rt_mutex_lock(>bus_lock);
 }
 
 /**
@@ -979,12 +974,7 @@ static void i2c_adapter_lock_bus(struct i2c_adapter 
*adapter,
 static int i2c_adapter_trylock_bus(struct i2c_adapter *adapter,
   unsigned int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   return parent->trylock_bus(parent, flags);
-   else
-   return rt_mutex_trylock(>bus_lock);
+   return rt_mutex_trylock(>bus_lock);
 }
 
 /**
@@ -996,12 +986,7 @@ static int i2c_adapter_trylock_bus(struct i2c_adapter 
*adapter,
 static void i2c_adapter_unlock_bus(struct i2c_adapter *adapter,
   unsigned int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   i2c_unlock_adapter(parent);
-   else
-   rt_mutex_unlock(>bus_lock);
+   rt_mutex_unlock(>bus_lock);
 }
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 25e9336b0e6e..5fa8af715e24 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -98,6 +98,33 @@ static unsigned int i2c_mux_parent_classes(struct 
i2c_adapter *parent)
return class;
 }
 
+static void i2c_parent_lock_bus(struct i2c_adapter *adapter,
+   unsigned int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   parent->lock_bus(parent, flags);
+}
+
+static int i2c_parent_trylock_bus(struct i2c_adapter *adapter,
+ unsigned int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   return parent->trylock_bus(parent, flags);
+}
+
+static void i2c_parent_unlock_bus(struct i2c_adapter *adapter,
+ unsigned int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   parent->unlock_bus(parent, flags);
+}
+
 struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent,
   struct device *dev, int max_adapters,
   int sizeof_priv, u32 flags,
@@ -165,6 +192,9 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
priv->adap.retries = parent->retries;
priv->adap.timeout = parent->timeout;
priv->adap.quirks = parent->quirks;
+   priv->adap.lock_bus = i2c_parent_lock_bus;
+   priv->adap.trylock_bus = i2c_parent_trylock_bus;
+   priv->adap.unlock_bus = i2c_parent_unlock_bus;
 
/* Sanity check on class */
if (i2c_mux_parent_classes(parent) & class)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 3/9] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

[Peter Rosin]

With a i2c topology like the following

   GPIO ---|  -- BAT1
|  v /
   I2C  -+--+ MUX
 |   \
   EEPROM -- BAT2

there is a locking problem with the GPIO controller since it is a client
on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
will lock the whole i2c bus prior to attempting to switch the mux to the
correct i2c segment. In the above case, the GPIO device is an I/O expander
with an i2c interface, and since the GPIO subsystem knows nothing (and
rightfully so) about the lockless needs of the i2c mux code, this results
in a deadlock when the GPIO driver issues i2c transfers to modify the
mux.

So, observing that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect mux client operation. The mux itself needs to be
locked, so transfers to clients behind the mux are serialized, and the mux
needs to be stable during all i2c traffic (otherwise individual mux slave
segments might see garbage, or worse).

Introduce this new locking concept as "mux-locked" muxes, and call the
pre-existing mux locking scheme "parent-locked".

Modify the i2c mux locking so that muxes that are "mux-locked" locks only
the muxes on the parent adapter instead of the whole i2c bus when there is
a transfer to the slave side of the mux. This lock serializes transfers to
the slave side of the muxes on the parent adapter.

Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved
gpio/pinctrl devices have a parent that is an i2c adapter in the same
adapter tree that is muxed, and request a "mux-locked mux" if that is the
case.

Modify the select-transfer-deselect code for "mux-locked" muxes so
that each of the select-transfer-deselect ops locks the mux parent
adapter individually.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c  |   1 +
 drivers/i2c/i2c-mux.c   | 152 +---
 drivers/i2c/muxes/i2c-mux-gpio.c|  18 +
 drivers/i2c/muxes/i2c-mux-pinctrl.c |  38 +
 include/linux/i2c-mux.h |   8 ++
 include/linux/i2c.h |   1 +
 6 files changed, 205 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index afdee66002db..9da446162529 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1540,6 +1540,7 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
}
 
rt_mutex_init(>bus_lock);
+   rt_mutex_init(>mux_lock);
mutex_init(>userspace_clients_lock);
INIT_LIST_HEAD(>userspace_clients);
 
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 5fa8af715e24..8eee98634cda 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -35,6 +35,25 @@ struct i2c_mux_priv {
u32 chan_id;
 };
 
+static int __i2c_mux_master_xfer(struct i2c_adapter *adap,
+struct i2c_msg msgs[], int num)
+{
+   struct i2c_mux_priv *priv = adap->algo_data;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
+   int ret;
+
+   /* Switch to the right mux port and perform the transfer. */
+
+   ret = muxc->select(muxc, priv->chan_id);
+   if (ret >= 0)
+   ret = __i2c_transfer(parent, msgs, num);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
+
+   return ret;
+}
+
 static int i2c_mux_master_xfer(struct i2c_adapter *adap,
   struct i2c_msg msgs[], int num)
 {
@@ -47,7 +66,29 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
 
ret = muxc->select(muxc, priv->chan_id);
if (ret >= 0)
-   ret = __i2c_transfer(parent, msgs, num);
+   ret = i2c_transfer(parent, msgs, num);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
+
+   return ret;
+}
+
+static int __i2c_mux_smbus_xfer(struct i2c_adapter *adap,
+   u16 addr, unsigned short flags,
+   char read_write, u8 command,
+   int size, union i2c_smbus_data *data)
+{
+   struct i2c_mux_priv *priv = adap->algo_data;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
+   int ret;
+
+   /* Select the right mux port and perform the transfer. */
+
+   ret = muxc->select(muxc, priv->chan_id);
+   if (ret >= 0)
+   ret = parent->algo->smbus_xfer(parent, addr, flags,
+   read_write, command, size, data);
if (muxc->deselect)
muxc->deselect(muxc, priv->chan_id);
 
@@ -68,8 +109,8 @@ static int 

[PATCH v9 9/9] [media] rtl2832: regmap is aware of lockdep, drop local locking hack

[Peter Rosin]

Tested-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 drivers/media/dvb-frontends/rtl2832.c  | 30 --
 drivers/media/dvb-frontends/rtl2832_priv.h |  1 -
 2 files changed, 31 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 957523f07f61..bfb6beedd40b 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -890,32 +890,6 @@ static bool rtl2832_volatile_reg(struct device *dev, 
unsigned int reg)
return false;
 }
 
-/*
- * FIXME: Hack. Implement own regmap locking in order to silence lockdep
- * recursive lock warning. That happens when regmap I2C client calls I2C mux
- * adapter, which leads demod I2C repeater enable via demod regmap. Operation
- * takes two regmap locks recursively - but those are different regmap 
instances
- * in a two different I2C drivers, so it is not deadlock. Proper fix is to make
- * regmap aware of lockdep.
- */
-static void rtl2832_regmap_lock(void *__dev)
-{
-   struct rtl2832_dev *dev = __dev;
-   struct i2c_client *client = dev->client;
-
-   dev_dbg(>dev, "\n");
-   mutex_lock(>regmap_mutex);
-}
-
-static void rtl2832_regmap_unlock(void *__dev)
-{
-   struct rtl2832_dev *dev = __dev;
-   struct i2c_client *client = dev->client;
-
-   dev_dbg(>dev, "\n");
-   mutex_unlock(>regmap_mutex);
-}
-
 static struct dvb_frontend *rtl2832_get_dvb_frontend(struct i2c_client *client)
 {
struct rtl2832_dev *dev = i2c_get_clientdata(client);
@@ -1082,12 +1056,8 @@ static int rtl2832_probe(struct i2c_client *client,
dev->sleeping = true;
INIT_DELAYED_WORK(>i2c_gate_work, rtl2832_i2c_gate_work);
/* create regmap */
-   mutex_init(>regmap_mutex);
dev->regmap_config.reg_bits =  8,
dev->regmap_config.val_bits =  8,
-   dev->regmap_config.lock = rtl2832_regmap_lock,
-   dev->regmap_config.unlock = rtl2832_regmap_unlock,
-   dev->regmap_config.lock_arg = dev,
dev->regmap_config.volatile_reg = rtl2832_volatile_reg,
dev->regmap_config.max_register = 5 * 0x100,
dev->regmap_config.ranges = regmap_range_cfg,
diff --git a/drivers/media/dvb-frontends/rtl2832_priv.h 
b/drivers/media/dvb-frontends/rtl2832_priv.h
index d8f97d14f6fd..c1a8a69e9015 100644
--- a/drivers/media/dvb-frontends/rtl2832_priv.h
+++ b/drivers/media/dvb-frontends/rtl2832_priv.h
@@ -33,7 +33,6 @@
 struct rtl2832_dev {
struct rtl2832_platform_data *pdata;
struct i2c_client *client;
-   struct mutex regmap_mutex;
struct regmap_config regmap_config;
struct regmap *regmap;
struct i2c_mux_core *muxc;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 7/9] [media] rtl2832: change the i2c gate to be mux-locked

[Peter Rosin]

The root i2c adapter lock is then no longer held by the i2c mux during
accesses behind the i2c gate, and such accesses need to take that lock
just like any other ordinary i2c accesses do.

So, declare the i2c gate mux-locked, and zap the regmap overrides
that makes the i2c accesses unlocked and use plain old regmap
accesses. This also removes the need for the regmap wrappers used by
rtl2832_sdr, so deconvolute the code further and provide the regmap
handle directly instead of the wrapper functions.

Tested-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology|   2 +-
 drivers/media/dvb-frontends/rtl2832.c | 190 --
 drivers/media/dvb-frontends/rtl2832.h |   4 +-
 drivers/media/dvb-frontends/rtl2832_sdr.c |  13 +-
 drivers/media/dvb-frontends/rtl2832_sdr.h |   5 +-
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c   |   5 +-
 6 files changed, 37 insertions(+), 182 deletions(-)

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
index 5e40802f0be2..e0aefeece551 100644
--- a/Documentation/i2c/i2c-topology
+++ b/Documentation/i2c/i2c-topology
@@ -55,7 +55,7 @@ imu/inv_mpu6050/  Mux-locked
 In drivers/media/
 dvb-frontends/m88ds3103   Parent-locked
 dvb-frontends/rtl2830 Parent-locked
-dvb-frontends/rtl2832 Parent-locked
+dvb-frontends/rtl2832 Mux-locked
 dvb-frontends/si2168  Mux-locked
 usb/cx231xx/  Parent-locked
 
diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 1b23788797b5..957523f07f61 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -153,43 +153,6 @@ static const struct rtl2832_reg_entry registers[] = {
[DVBT_REG_4MSEL]= {0x013,  0, 0},
 };
 
-/* Our regmap is bypassing I2C adapter lock, thus we do it! */
-static int rtl2832_bulk_write(struct i2c_client *client, unsigned int reg,
- const void *val, size_t val_count)
-{
-   struct rtl2832_dev *dev = i2c_get_clientdata(client);
-   int ret;
-
-   i2c_lock_adapter(client->adapter);
-   ret = regmap_bulk_write(dev->regmap, reg, val, val_count);
-   i2c_unlock_adapter(client->adapter);
-   return ret;
-}
-
-static int rtl2832_update_bits(struct i2c_client *client, unsigned int reg,
-  unsigned int mask, unsigned int val)
-{
-   struct rtl2832_dev *dev = i2c_get_clientdata(client);
-   int ret;
-
-   i2c_lock_adapter(client->adapter);
-   ret = regmap_update_bits(dev->regmap, reg, mask, val);
-   i2c_unlock_adapter(client->adapter);
-   return ret;
-}
-
-static int rtl2832_bulk_read(struct i2c_client *client, unsigned int reg,
-void *val, size_t val_count)
-{
-   struct rtl2832_dev *dev = i2c_get_clientdata(client);
-   int ret;
-
-   i2c_lock_adapter(client->adapter);
-   ret = regmap_bulk_read(dev->regmap, reg, val, val_count);
-   i2c_unlock_adapter(client->adapter);
-   return ret;
-}
-
 static int rtl2832_rd_demod_reg(struct rtl2832_dev *dev, int reg, u32 *val)
 {
struct i2c_client *client = dev->client;
@@ -204,7 +167,7 @@ static int rtl2832_rd_demod_reg(struct rtl2832_dev *dev, 
int reg, u32 *val)
len = (msb >> 3) + 1;
mask = REG_MASK(msb - lsb);
 
-   ret = rtl2832_bulk_read(client, reg_start_addr, reading, len);
+   ret = regmap_bulk_read(dev->regmap, reg_start_addr, reading, len);
if (ret)
goto err;
 
@@ -234,7 +197,7 @@ static int rtl2832_wr_demod_reg(struct rtl2832_dev *dev, 
int reg, u32 val)
len = (msb >> 3) + 1;
mask = REG_MASK(msb - lsb);
 
-   ret = rtl2832_bulk_read(client, reg_start_addr, reading, len);
+   ret = regmap_bulk_read(dev->regmap, reg_start_addr, reading, len);
if (ret)
goto err;
 
@@ -248,7 +211,7 @@ static int rtl2832_wr_demod_reg(struct rtl2832_dev *dev, 
int reg, u32 val)
for (i = 0; i < len; i++)
writing[i] = (writing_tmp >> ((len - 1 - i) * 8)) & 0xff;
 
-   ret = rtl2832_bulk_write(client, reg_start_addr, writing, len);
+   ret = regmap_bulk_write(dev->regmap, reg_start_addr, writing, len);
if (ret)
goto err;
 
@@ -525,7 +488,8 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
}
 
for (j = 0; j < sizeof(bw_params[0]); j++) {
-   ret = rtl2832_bulk_write(client, 0x11c + j, _params[i][j], 
1);
+   ret = regmap_bulk_write(dev->regmap,
+   0x11c + j, _params[i][j], 1);
if (ret)
goto err;
}
@@ -581,11 +545,11 @@ static int rtl2832_get_frontend(struct dvb_frontend *fe,
if (dev->sleeping)
return 0;
 
-   ret = rtl2832_bulk_read(client, 0x33c, buf, 2);
+   ret = 

[PATCH v9 8/9] [media] rtl2832_sdr: get rid of empty regmap wrappers

[Peter Rosin]

Tested-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 drivers/media/dvb-frontends/rtl2832_sdr.c | 302 +-
 1 file changed, 132 insertions(+), 170 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c 
b/drivers/media/dvb-frontends/rtl2832_sdr.c
index 6a6b1debe277..47a480a7d46c 100644
--- a/drivers/media/dvb-frontends/rtl2832_sdr.c
+++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
@@ -120,6 +120,7 @@ struct rtl2832_sdr_dev {
unsigned long flags;
 
struct platform_device *pdev;
+   struct regmap *regmap;
 
struct video_device vdev;
struct v4l2_device v4l2_dev;
@@ -164,47 +165,6 @@ struct rtl2832_sdr_dev {
unsigned long jiffies_next;
 };
 
-/* write multiple registers */
-static int rtl2832_sdr_wr_regs(struct rtl2832_sdr_dev *dev, u16 reg,
-   const u8 *val, int len)
-{
-   struct platform_device *pdev = dev->pdev;
-   struct rtl2832_sdr_platform_data *pdata = pdev->dev.platform_data;
-   struct regmap *regmap = pdata->regmap;
-
-   return regmap_bulk_write(regmap, reg, val, len);
-}
-
-#if 0
-/* read multiple registers */
-static int rtl2832_sdr_rd_regs(struct rtl2832_sdr_dev *dev, u16 reg, u8 *val,
-   int len)
-{
-   struct platform_device *pdev = dev->pdev;
-   struct rtl2832_sdr_platform_data *pdata = pdev->dev.platform_data;
-   struct regmap *regmap = pdata->regmap;
-
-   return regmap_bulk_read(regmap, reg, val, len);
-}
-#endif
-
-/* write single register */
-static int rtl2832_sdr_wr_reg(struct rtl2832_sdr_dev *dev, u16 reg, u8 val)
-{
-   return rtl2832_sdr_wr_regs(dev, reg, , 1);
-}
-
-/* write single register with mask */
-static int rtl2832_sdr_wr_reg_mask(struct rtl2832_sdr_dev *dev, u16 reg,
-   u8 val, u8 mask)
-{
-   struct platform_device *pdev = dev->pdev;
-   struct rtl2832_sdr_platform_data *pdata = pdev->dev.platform_data;
-   struct regmap *regmap = pdata->regmap;
-
-   return regmap_update_bits(regmap, reg, mask, val);
-}
-
 /* Private functions */
 static struct rtl2832_sdr_frame_buf *rtl2832_sdr_get_next_fill_buf(
struct rtl2832_sdr_dev *dev)
@@ -559,11 +519,11 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev 
*dev)
 
f_sr = dev->f_adc;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x13e, "\x00\x00", 2);
+   ret = regmap_bulk_write(dev->regmap, 0x13e, "\x00\x00", 2);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x115, "\x00\x00\x00\x00", 4);
+   ret = regmap_bulk_write(dev->regmap, 0x115, "\x00\x00\x00\x00", 4);
if (ret)
goto err;
 
@@ -589,7 +549,7 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev *dev)
buf[1] = (u32tmp >>  8) & 0xff;
buf[2] = (u32tmp >>  0) & 0xff;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x119, buf, 3);
+   ret = regmap_bulk_write(dev->regmap, 0x119, buf, 3);
if (ret)
goto err;
 
@@ -603,15 +563,15 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev 
*dev)
u8tmp2 = 0xcd; /* enable ADC I, ADC Q */
}
 
-   ret = rtl2832_sdr_wr_reg(dev, 0x1b1, u8tmp1);
+   ret = regmap_write(dev->regmap, 0x1b1, u8tmp1);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_reg(dev, 0x008, u8tmp2);
+   ret = regmap_write(dev->regmap, 0x008, u8tmp2);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_reg(dev, 0x006, 0x80);
+   ret = regmap_write(dev->regmap, 0x006, 0x80);
if (ret)
goto err;
 
@@ -622,168 +582,169 @@ static int rtl2832_sdr_set_adc(struct rtl2832_sdr_dev 
*dev)
buf[1] = (u32tmp >> 16) & 0xff;
buf[2] = (u32tmp >>  8) & 0xff;
buf[3] = (u32tmp >>  0) & 0xff;
-   ret = rtl2832_sdr_wr_regs(dev, 0x19f, buf, 4);
+   ret = regmap_bulk_write(dev->regmap, 0x19f, buf, 4);
if (ret)
goto err;
 
/* low-pass filter */
-   ret = rtl2832_sdr_wr_regs(dev, 0x11c,
-   
"\xca\xdc\xd7\xd8\xe0\xf2\x0e\x35\x06\x50\x9c\x0d\x71\x11\x14\x71\x74\x19\x41\xa5",
-   20);
+   ret = regmap_bulk_write(dev->regmap, 0x11c,
+   
"\xca\xdc\xd7\xd8\xe0\xf2\x0e\x35\x06\x50\x9c\x0d\x71\x11\x14\x71\x74\x19\x41\xa5",
+   20);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x017, "\x11\x10", 2);
+   ret = regmap_bulk_write(dev->regmap, 0x017, "\x11\x10", 2);
if (ret)
goto err;
 
/* mode */
-   ret = rtl2832_sdr_wr_regs(dev, 0x019, "\x05", 1);
+   ret = regmap_write(dev->regmap, 0x019, 0x05);
if (ret)
goto err;
 
-   ret = rtl2832_sdr_wr_regs(dev, 0x01a, "\x1b\x16\x0d\x06\x01\xff", 6);
+   ret = regmap_bulk_write(dev->regmap, 0x01a,

[PATCH v9 6/9] [media] si2168: change the i2c gate to be mux-locked

[Peter Rosin]

From: Antti Palosaari 

The root i2c adapter lock is then no longer held by the i2c mux during
accesses behind the i2c gate, and such accesses need to take that lock
just like any other ordinary i2c accesses do.

So, declare the i2c gate mux-locked, and zap the code that makes the
i2c accesses unlocked. But add a mutex so that firmware commands are
still serialized.

Signed-off-by: Antti Palosaari 
Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology|  2 +-
 drivers/media/dvb-frontends/si2168.c  | 83 ---
 drivers/media/dvb-frontends/si2168_priv.h |  1 +
 3 files changed, 22 insertions(+), 64 deletions(-)

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
index 69b008518454..5e40802f0be2 100644
--- a/Documentation/i2c/i2c-topology
+++ b/Documentation/i2c/i2c-topology
@@ -56,7 +56,7 @@ In drivers/media/
 dvb-frontends/m88ds3103   Parent-locked
 dvb-frontends/rtl2830 Parent-locked
 dvb-frontends/rtl2832 Parent-locked
-dvb-frontends/si2168  Parent-locked
+dvb-frontends/si2168  Mux-locked
 usb/cx231xx/  Parent-locked
 
 
diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 5583827c386e..108a069fa1ae 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -18,53 +18,23 @@
 
 static const struct dvb_frontend_ops si2168_ops;
 
-/* Own I2C adapter locking is needed because of I2C gate logic. */
-static int si2168_i2c_master_send_unlocked(const struct i2c_client *client,
-  const char *buf, int count)
-{
-   int ret;
-   struct i2c_msg msg = {
-   .addr = client->addr,
-   .flags = 0,
-   .len = count,
-   .buf = (char *)buf,
-   };
-
-   ret = __i2c_transfer(client->adapter, , 1);
-   return (ret == 1) ? count : ret;
-}
-
-static int si2168_i2c_master_recv_unlocked(const struct i2c_client *client,
-  char *buf, int count)
-{
-   int ret;
-   struct i2c_msg msg = {
-   .addr = client->addr,
-   .flags = I2C_M_RD,
-   .len = count,
-   .buf = buf,
-   };
-
-   ret = __i2c_transfer(client->adapter, , 1);
-   return (ret == 1) ? count : ret;
-}
-
 /* execute firmware command */
-static int si2168_cmd_execute_unlocked(struct i2c_client *client,
-  struct si2168_cmd *cmd)
+static int si2168_cmd_execute(struct i2c_client *client, struct si2168_cmd 
*cmd)
 {
+   struct si2168_dev *dev = i2c_get_clientdata(client);
int ret;
unsigned long timeout;
 
+   mutex_lock(>i2c_mutex);
+
if (cmd->wlen) {
/* write cmd and args for firmware */
-   ret = si2168_i2c_master_send_unlocked(client, cmd->args,
- cmd->wlen);
+   ret = i2c_master_send(client, cmd->args, cmd->wlen);
if (ret < 0) {
-   goto err;
+   goto err_mutex_unlock;
} else if (ret != cmd->wlen) {
ret = -EREMOTEIO;
-   goto err;
+   goto err_mutex_unlock;
}
}
 
@@ -73,13 +43,12 @@ static int si2168_cmd_execute_unlocked(struct i2c_client 
*client,
#define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
-   ret = si2168_i2c_master_recv_unlocked(client, cmd->args,
- cmd->rlen);
+   ret = i2c_master_recv(client, cmd->args, cmd->rlen);
if (ret < 0) {
-   goto err;
+   goto err_mutex_unlock;
} else if (ret != cmd->rlen) {
ret = -EREMOTEIO;
-   goto err;
+   goto err_mutex_unlock;
}
 
/* firmware ready? */
@@ -94,32 +63,23 @@ static int si2168_cmd_execute_unlocked(struct i2c_client 
*client,
/* error bit set? */
if ((cmd->args[0] >> 6) & 0x01) {
ret = -EREMOTEIO;
-   goto err;
+   goto err_mutex_unlock;
}
 
if (!((cmd->args[0] >> 7) & 0x01)) {
ret = -ETIMEDOUT;
-   goto err;
+   goto err_mutex_unlock;
}
}
 
+   mutex_unlock(>i2c_mutex);
return 0;
-err:
+err_mutex_unlock:
+   mutex_unlock(>i2c_mutex);
dev_dbg(>dev, "failed=%d\n", ret);
return ret;
 }

[PATCH v9 0/9] i2c mux cleanup and locking update

[Peter Rosin]

Hi!

I have a pair of boards with this i2c topology:

   GPIO ---|  -- BAT1
|  v /
   I2C  -+--B---+ MUX
 |   \
   EEPROM -- BAT2

(B denotes the boundary between the boards)

The problem with this is that the GPIO controller sits on the same i2c bus
that it MUXes. For pca954x devices this is worked around by using unlocked
transfers when updating the MUX. I have no such luck as the GPIO is a general
purpose IO expander and the MUX is just a random bidirectional MUX, unaware
of the fact that it is muxing an i2c bus. Extending unlocked transfers
into the GPIO subsystem is too ugly to even think about. But the general hw
approach is sane in my opinion, with the number of connections between the
two boards minimized. To put it plainly, I need support for it.

So, I observe that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect operation. The MUX itself needs to be locked, so
transfers to clients behind the mux are serialized, and the MUX needs to be
stable during all i2c traffic (otherwise individual mux slave segments
might see garbage).

This series accomplishes this by adding code to i2c-mux-gpio and
i2c-mux-pinctrl that determines if all involved devices used to update the
mux are controlled by the same root i2c adapter that is muxed. When this
is the case, the select-transfer-deselect operations should be locked
individually to avoid the deadlock. The i2c bus *is* still locked
during muxing, since the muxing happens as part of i2c transfers. This
is true even if the MUX is updated with several transfers to the GPIO (at
least as long as *all* MUX changes are using the i2c master bus). A lock
is added to i2c adapters that muxes on that adapter grab, so that transfers
through the muxes are serialized.

Concerns:
- The locking is perhaps too complex?
- I worry about the priority inheritance aspect of the adapter lock. When
  the transfers behind the mux are divided into select-transfer-deselect all
  locked individually, low priority transfers get more chances to interfere
  with high priority transfers.
- When doing an i2c_transfer() in_atomic() context or with irqs_disabled(),
  there is a higher possibility that the mux is not returned to its idle
  state after a failed (-EAGAIN) transfer due to trylock.
- Is the detection of i2c-controlled gpios and pinctrls sane (i.e. the
  usage of the new i2c_root_adapter() function in 18/24)?

The first half (patches 01-15 in v7) of what was originally part of this
series have already been scheduled for 4.6. So, this is the second half
(patches 16-24 in v7, patches 1-9 in v9).

To summarize the series, there is some preparatory locking changes in
in 1/9 and the real meat is in 3/9. There is some documentation added in
4/9 while 5/9 and after are cleanups to existing drivers utilizing
the new stuff.

PS. needs a bunch of testing, I do not have access to all the involved hw.

This second half of the series is planned to be merged with 4.7 and can
also be pulled from github, if that is preferred:

-
The following changes since commit b3b85922534861445a24f48f1d6125a99c6f3aa2:

  Merge branch 'i2c/for-4.7' into i2c/for-next (2016-04-27 19:11:32 +0200)

are available in the git repository at:

  https://github.com/peda-r/i2c-mux.git mux-core-and-locking-9

for you to fetch changes up to ce3cf4098f0bb41fa9fc9a87bb5d4d64ec90074f:

  [media] rtl2832: regmap is aware of lockdep, drop local locking hack 
(2016-05-04 21:05:53 +0200)
-

v9 compared to v8:
- Drop patches 01-15, since they are in the pipe anyway.
- Change the name of the I2C_LOCK_ADAPTER flag to I2C_LOCK_ROOT_ADAPTER.
- Do not change the locking in i2c_slave_register and i2c_slave_unregister.
  That cannot possibly work for muxes anyway, so the changes were somewhere
  between pointless and silly.
- The the BIT macro to specify bits for flags.
- Add kerneldoc for i2c_lock_bus and i2c_unlock_bus.
- Add some comments in i2c_mux_trylock_bus and i2c_parent_trylock_bus.
- Use true instead of 1 for a bool variable.
- Whitespace issues fixed as indicated by --strict checkpatching.
- Updated commit message for the first patch.

v8 compared to v7:
- Do not change i2c_get_clientdata() into dev_get_drvdata() in the mpu6050
  driver.

v7 compared to v6:
- Removed i2c_mux_reserve_adapters, and all realloc attempts in
  i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc
  instead.
- Removed i2c_mux_one_adapter since it is was hard to use correctly, which
  was evident from the crash in the mpu6050 driver (on a mpu9150 chip) reported
  by Crestez Dan Leonard. Also, it didn't make things all that much simpler
  anyway (even if used correctly).
- Rename 

[PATCH v3] media: fix use-after-free in cdev_put() when app exits after driver unbind

[Shuah Khan]

When driver unbinds while media_ioctl is in progress, cdev_put() fails with
when app exits after driver unbinds.

Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets
a reference to it and releases it in cdev_del() ensuring that the devnode
is not deallocated as long as the application has the device file open.

media_devnode_register() initializes the struct device kobj before calling
cdev_add(). media_devnode_unregister() does cdev_del() and then deletes the
device. devnode is released when the last reference to the struct device is
gone.

This problem is found on uvcvideo, em28xx, and au0828 drivers and fix has
been tested on all three.

kernel: [  193.599736] BUG: KASAN: use-after-free in cdev_put+0x4e/0x50
kernel: [  193.599745] Read of size 8 by task media_device_te/1851
kernel: [  193.599792] INFO: Allocated in __media_device_register+0x54
kernel: [  193.599951] INFO: Freed in media_devnode_release+0xa4/0xc0

kernel: [  193.601083] Call Trace:
kernel: [  193.601093]  [] dump_stack+0x67/0x94
kernel: [  193.601102]  [] print_trailer+0x112/0x1a0
kernel: [  193.60]  [] object_err+0x34/0x40
kernel: [  193.601119]  [] kasan_report_error+0x224/0x530
kernel: [  193.601128]  [] ? kzfree+0x2d/0x40
kernel: [  193.601137]  [] ? kfree+0x1d2/0x1f0
kernel: [  193.601154]  [] ? cdev_put+0x4e/0x50
kernel: [  193.601162]  [] cdev_put+0x4e/0x50
kernel: [  193.601170]  [] __fput+0x52b/0x6c0
kernel: [  193.601179]  [] ? switch_task_namespaces+0x2a
kernel: [  193.601188]  [] fput+0xe/0x10
kernel: [  193.601196]  [] task_work_run+0x133/0x1f0
kernel: [  193.601204]  [] ? switch_task_namespaces+0x5e
kernel: [  193.601213]  [] do_exit+0x72c/0x2c20
kernel: [  193.601224]  [] ? release_task+0x1250/0x1250
-
-
-
kernel: [  193.601360]  [] ? exit_to_usermode_loop+0xe7
kernel: [  193.601368]  [] exit_to_usermode_loop+0x120
kernel: [  193.601376]  [] syscall_return_slowpath+0x16a
kernel: [  193.601386]  [] entry_SYSCALL_64_fastpath+0xa6

Signed-off-by: Shuah Khan 
---

Changes since v2:
- Changed pr_info()s to pr_debug()s
Changes since v1:
- Addressed review comments from Lars-Peter Clausen

 drivers/media/media-device.c  |  6 --
 drivers/media/media-devnode.c | 45 ++-
 2 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 84e6a0b..a853384 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -742,16 +742,16 @@ int __must_check __media_device_register(struct 
media_device *mdev,
 
ret = media_devnode_register(mdev, devnode, owner);
if (ret < 0) {
+   /* devnode free is handled in media_devnode_*() */
mdev->devnode = NULL;
-   kfree(devnode);
return ret;
}
 
ret = device_create_file(>dev, _attr_model);
if (ret < 0) {
+   /* devnode free is handled in media_devnode_*() */
mdev->devnode = NULL;
media_devnode_unregister(devnode);
-   kfree(devnode);
return ret;
}
 
@@ -829,6 +829,8 @@ void media_device_unregister(struct media_device *mdev)
if (media_devnode_is_registered(mdev->devnode)) {
device_remove_file(>devnode->dev, _attr_model);
media_devnode_unregister(mdev->devnode);
+   /* devnode free is handled in media_devnode_*() */
+   mdev->devnode = NULL;
}
 
dev_dbg(mdev->dev, "Media device unregistered\n");
diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
index ca7c4b9..eedf658 100644
--- a/drivers/media/media-devnode.c
+++ b/drivers/media/media-devnode.c
@@ -63,13 +63,8 @@ static void media_devnode_release(struct device *cd)
struct media_devnode *devnode = to_media_devnode(cd);
 
mutex_lock(_devnode_lock);
-
-   /* Delete the cdev on this minor as well */
-   cdev_del(>cdev);
-
/* Mark device node number as free */
clear_bit(devnode->minor, media_devnode_nums);
-
mutex_unlock(_devnode_lock);
 
/* Release media_devnode and perform other cleanups as needed. */
@@ -77,6 +72,7 @@ static void media_devnode_release(struct device *cd)
devnode->release(devnode);
 
kfree(devnode);
+   pr_debug("%s: Media Devnode Deallocated\n", __func__);
 }
 
 static struct bus_type media_bus_type = {
@@ -204,6 +200,7 @@ static int media_release(struct inode *inode, struct file 
*filp)
   return value is ignored. */
put_device(>dev);
filp->private_data = NULL;
+   pr_debug("%s: Media Release\n", __func__);
return 0;
 }
 
@@ -234,6 +231,7 @@ int __must_check media_devnode_register(struct media_device 
*mdev,
if (minor == MEDIA_NUM_DEVICES) {
mutex_unlock(_devnode_lock);
pr_err("could not get a free minor\n");
+   

Re: [GIT PULL for v4.6-rc1] media updates

[Stefan Lippers-Hollmann]

Hi

On 2016-05-04, Linus Torvalds wrote:
> On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann  wrote:
> >
> > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
> > aren't needed/ loaded on my system) crude revert avoids the problem for
> > me on v4.6-rc6-113-g83858a7.  
> 
> Hmm.
> 
> That just open-codes __media_device_usb_init().
> 
> The main difference seems to be that __media_device_usb_init() ends up
> having that
> 
>  #ifdef CONFIG_USB
>  #endif
> 
> around it.
> 
> I think that is bogus.
> 
> What happens if you replace that #ifdef CONFIG_USB in
> __media_device_usb_init() with
> 
> #if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)
[...]

that throws

drivers/media/media-device.c: In function '__media_device_usb_init':
drivers/media/media-device.c:878:5: warning: "CONFIG_USB" is not defined 
[-Wundef]
 #if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)
 ^

however, taking arch/arm/mach-omap1/include/mach/usb.h as example, 
changing it to 

--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
 const char *board_name,
 const char *driver_name)
 {
-#ifdef CONFIG_USB
+#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
mdev->dev = >dev;
 
if (driver_name)

indeed fixes the problem for me

Thanks a lot!

Regards
Stefan Lippers-Hollmann


pgpXpKCknCiwV.pgp
Description: Digitale Signatur von OpenPGP

Re: [GIT PULL for v4.6-rc1] media updates

[Linus Torvalds]

On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann  wrote:
>
> Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
> aren't needed/ loaded on my system) crude revert avoids the problem for
> me on v4.6-rc6-113-g83858a7.

Hmm.

That just open-codes __media_device_usb_init().

The main difference seems to be that __media_device_usb_init() ends up
having that

 #ifdef CONFIG_USB
 #endif

around it.

I think that is bogus.

What happens if you replace that #ifdef CONFIG_USB in
__media_device_usb_init() with

#if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)

or alternatively just build with USB compiled in?

Mauro: that __media_device_usb_init() thing does seem to be completely
buggered for the modular USB case.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 10:59:36 -0600
Jonathan Corbet  escreveu:

> On Wed, 4 May 2016 13:50:35 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > Em Wed, 4 May 2016 19:13:21 +0300
> > Jani Nikula  escreveu:  
> > > I think we should go for vanilla sphinx at first, to make the setup step
> > > as easy as possible for everyone.
> > 
> > Vanilla Sphinx doesn't work, as reST markup language is too limited
> > to support the docs we have. So, we should either push the needed
> > extensions to Sphinx reST or find a way to put it at Kernel tree
> > without causing too much pain for the developers, e. g. as something
> > that just doing "make htmldoc" would automatically use such extensions
> > without needing to actually install the extensions.  
> 
> It works for everything except the extended media book, right?  Or is there
> something I'm missing here?

As far as I know, yes, but I didn't check the other documentation
to be sure.

>  I am very much interested in having one system
> for *all* our docs, but we wouldn't attempt to convert a document can't be
> expressed in sphinx.

Looking from the other side, keeping only one document as DocBook
and having everything else converted to some markup solution seem
equally a bad solution, as, in the end of the day, we'll become
dependent of two different tool chains to produce document.

Also, media documentation is not just one more documentation. It is
the biggest one we have, and that has more changes than any other
documentation under Documentation/DocBook:

$ git lg --since 01/01/2015 ` ls *.tmpl|grep -v media`|wc -l
116
$ git lg --since 01/01/2015 ` ls *.tmpl|grep media` `find media/ -type f`|wc -l
179

It also is more than twice the size of the other DocBook docs:

$ wc -l $(ls *.tmpl|grep  media) `find media/ -type f`|tail -1
  82275 total
$ wc -l $(ls *.tmpl|grep -v media)|tail -1
  29568 total

E. g. media corresponds to 60% of the number of patches and 73% of
the DocBook stuff.

Not converting it to the new "official" Kernel markup language
would would mean that developers that work on more than the
media subsystem would need to know two different, incompatible
dialects to produce documentation (plus kernel-doc). That sounds
messy and it is an extra penalty to media developers. Some may
even start to think that that writing bad docs would be a good thing.

> > > Even if it means still doing that ugly
> > > docproc step to call kernel-doc. We can improve from there, and I
> > > definitely appreciate your work on making this work with sphinx
> > > extensions.
> > 
> > I disagree: We should not cause documentation regressions by
> > producing incomplete documentation and losing tables because of
> > such conversion.  
> 
> > The quality of the documentation after the change should be *at least*
> > equal to the one we current produce, never worse.  
> 
> Agreed; that's why I think the existing DocBook mechanism should stay in
> place until that document will be improved by the change. But I'd rather
> not hold up the entire process for one book, especially since pushing that
> process forward can only help in dealing with those final problems.

Yeah, in practice, we won't be converting everything on just one
Kernel version. Yet, we need at least an strategy and a plan that would
allow converting everything to the new markup language.

Provided that we would merge Sphinx support on 4.8, I would like to convert
the media documentation just after merging the new toolchain upstream, 
in order to minimize the conversion impact and to not lose developers
and good developer's documentation in the process.

However, such work can only be started if we have a way to work with the
required extensions, as we're deciding to use a markup language that has
incomplete table support.

So, IMHO, we should have a way to run the required extensions in a
painless way before doing the merge.

> > > That said, how would it work to include the kernel-doc extension in the
> > > kernel source tree? Having things just work if sphinx is installed is
> > > preferred over requiring installation of something extra from pypi. (I
> > > know this may sound backwards for a lot of projects, but for kernel I'm
> > > pretty sure this is how it should be done.)
> > 
> > Yeah, using pypi seems an additional undesired step. Aren't there
> > any way to make python to use an additional extension at the
> > Kernel tree without needing to install it?  
> 
> Well, sphinx has to come from somewhere too.  But yes, we should be able to
> carry extensions in the kernel tree.  But I would still rather upstream it
> (to sphinx) if possible, so we're not stuck trying to maintain it across
> several sphinx releases.  I don't know how volatile their interfaces are,
> but it would be, in any case, the analog of an out-of-tree module...

Yeah, the best would be to put everything we need at Sphinx upstream,
but assuming that they agree today to add 

[PATCH v2 1/8] Input: atmel_mxt_ts - add support for T37 diagnostic data

[Nick Dyer]

Atmel maXTouch devices have a T37 object which can be used to read raw
touch deltas from the device. This consists of an array of 16-bit
integers, one for each node on the touchscreen matrix.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 152 +++
 1 file changed, 152 insertions(+)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2160512..cd97713 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -124,6 +124,17 @@ struct t9_range {
 #define MXT_COMMS_CTRL 0
 #define MXT_COMMS_CMD  1
 
+/* MXT_DEBUG_DIAGNOSTIC_T37 */
+#define MXT_DIAGNOSTIC_PAGEUP  0x01
+#define MXT_DIAGNOSTIC_DELTAS  0x10
+#define MXT_DIAGNOSTIC_SIZE128
+
+struct t37_debug {
+   u8 mode;
+   u8 page;
+   u8 data[MXT_DIAGNOSTIC_SIZE];
+};
+
 /* Define for MXT_GEN_COMMAND_T6 */
 #define MXT_BOOT_VALUE 0xa5
 #define MXT_RESET_VALUE0x01
@@ -205,6 +216,14 @@ struct mxt_object {
u8 num_report_ids;
 } __packed;
 
+struct mxt_dbg {
+   u16 t37_address;
+   u16 diag_cmd_address;
+   struct t37_debug *t37_buf;
+   unsigned int t37_pages;
+   unsigned int t37_nodes;
+};
+
 /* Each client has this additional data */
 struct mxt_data {
struct i2c_client *client;
@@ -233,6 +252,7 @@ struct mxt_data {
u8 num_touchids;
u8 multitouch;
struct t7_config t7_cfg;
+   struct mxt_dbg dbg;
 
/* Cached parameters from object table */
u16 T5_address;
@@ -2043,6 +2063,136 @@ recheck:
return 0;
 }
 
+static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
+  unsigned int y)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int ofs, page;
+
+   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   page = ofs / MXT_DIAGNOSTIC_SIZE;
+   ofs %= MXT_DIAGNOSTIC_SIZE;
+
+   return get_unaligned_le16(>t37_buf[page].data[ofs]);
+}
+
+static int mxt_convert_debug_pages(struct mxt_data *data, u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int x = 0;
+   unsigned int y = 0;
+   unsigned int i;
+
+   for (i = 0; i < dbg->t37_nodes; i++) {
+   outbuf[i] = mxt_get_debug_value(data, x, y);
+
+   /* Next value */
+   if (++x >= data->info.matrix_xsize) {
+   x = 0;
+   y++;
+   }
+   }
+
+   return 0;
+}
+
+static int mxt_read_diagnostic_debug(struct mxt_data *data, u8 mode,
+u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   int retries = 0;
+   int page;
+   int ret;
+   u8 cmd = mode;
+   struct t37_debug *p;
+   u8 cmd_poll;
+
+   for (page = 0; page < dbg->t37_pages; page++) {
+   p = dbg->t37_buf + page;
+
+   ret = mxt_write_reg(data->client, dbg->diag_cmd_address,
+   cmd);
+   if (ret)
+   return ret;
+
+   retries = 0;
+   msleep(20);
+wait_cmd:
+   /* Read back command byte */
+   ret = __mxt_read_reg(data->client, dbg->diag_cmd_address,
+sizeof(cmd_poll), _poll);
+   if (ret)
+   return ret;
+
+   /* Field is cleared once the command has been processed */
+   if (cmd_poll) {
+   if (retries++ > 100)
+   return -EINVAL;
+
+   msleep(20);
+   goto wait_cmd;
+   }
+
+   /* Read T37 page */
+   ret = __mxt_read_reg(data->client, dbg->t37_address,
+   sizeof(struct t37_debug), p);
+   if (ret)
+   return ret;
+
+   if ((p->mode != mode) || (p->page != page)) {
+   dev_err(>client->dev, "T37 page mismatch\n");
+   return -EINVAL;
+   }
+
+   dev_dbg(>client->dev, "%s page:%d retries:%d\n",
+   __func__, page, retries);
+
+   /* For remaining pages, write PAGEUP rather than mode */
+   cmd = MXT_DIAGNOSTIC_PAGEUP;
+   }
+
+   return mxt_convert_debug_pages(data, outbuf);
+}
+
+static void mxt_debug_init(struct mxt_data *data)
+{
+   struct mxt_dbg *dbg = >dbg;
+   struct mxt_object *object;
+
+   object = mxt_get_object(data, MXT_GEN_COMMAND_T6);
+   if (!object)
+   return;
+
+   dbg->diag_cmd_address = object->start_address + MXT_COMMAND_DIAGNOSTIC;
+
+   object = mxt_get_object(data, MXT_DEBUG_DIAGNOSTIC_T37);
+   if (!object)
+   return;
+
+   if (mxt_obj_size(object) != sizeof(struct t37_debug)) {
+ 

[PATCH v2 3/8] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

[Nick Dyer]

Some touch controllers send out raw touch data in a similar way to a
greyscale frame grabber. Add a new device type for these devices.

Use a new device prefix v4l-touch for these devices, to stop generic
capture software from treating them as webcams.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/sur40.c|  2 +-
 drivers/media/v4l2-core/v4l2-dev.c   | 13 ++---
 drivers/media/v4l2-core/v4l2-ioctl.c |  6 --
 include/media/v4l2-dev.h |  3 ++-
 4 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index 880c40b..7e5fe2b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -599,7 +599,7 @@ static int sur40_probe(struct usb_interface *interface,
sur40->vdev.queue = >queue;
video_set_drvdata(>vdev, sur40);
 
-   error = video_register_device(>vdev, VFL_TYPE_GRABBER, -1);
+   error = video_register_device(>vdev, VFL_TYPE_TOUCH_SENSOR, -1);
if (error) {
dev_err(>dev,
"Unable to register video subdevice.");
diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index d8e5994..8d41248 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -529,6 +529,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
bool is_sdr = vdev->vfl_type == VFL_TYPE_SDR;
bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
+   bool is_touch = vdev->vfl_type == VFL_TYPE_TOUCH_SENSOR;
 
bitmap_zero(valid_ioctls, BASE_VIDIOC_PRIVATE);
 
@@ -573,7 +574,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
if (ops->vidioc_enum_freq_bands || ops->vidioc_g_tuner || 
ops->vidioc_g_modulator)
set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
 
-   if (is_vid) {
+   if (is_vid || is_touch) {
/* video specific ioctls */
if ((is_rx && (ops->vidioc_enum_fmt_vid_cap ||
   ops->vidioc_enum_fmt_vid_cap_mplane ||
@@ -662,7 +663,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
}
 
-   if (is_vid || is_vbi || is_sdr) {
+   if (is_vid || is_vbi || is_sdr || is_touch) {
/* ioctls valid for video, vbi or sdr */
SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
@@ -675,7 +676,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
}
 
-   if (is_vid || is_vbi) {
+   if (is_vid || is_vbi || is_touch) {
/* ioctls valid for video or vbi */
if (ops->vidioc_s_std)
set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls);
@@ -738,6 +739,7 @@ static int video_register_media_controller(struct 
video_device *vdev, int type)
vdev->entity.function = MEDIA_ENT_F_UNKNOWN;
 
switch (type) {
+   case VFL_TYPE_TOUCH_SENSOR:
case VFL_TYPE_GRABBER:
intf_type = MEDIA_INTF_T_V4L_VIDEO;
vdev->entity.function = MEDIA_ENT_F_IO_V4L;
@@ -844,6 +846,8 @@ static int video_register_media_controller(struct 
video_device *vdev, int type)
  * %VFL_TYPE_SUBDEV - A subdevice
  *
  * %VFL_TYPE_SDR - Software Defined Radio
+ *
+ * %VFL_TYPE_TOUCH_SENSOR - A touch sensor
  */
 int __video_register_device(struct video_device *vdev, int type, int nr,
int warn_if_nr_in_use, struct module *owner)
@@ -887,6 +891,9 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
/* Use device name 'swradio' because 'sdr' was already taken. */
name_base = "swradio";
break;
+   case VFL_TYPE_TOUCH_SENSOR:
+   name_base = "v4l-touch";
+   break;
default:
printk(KERN_ERR "%s called with unknown type: %d\n",
   __func__, type);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index c7dabaa..4a1093a 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -925,13 +925,14 @@ static int check_fmt(struct file *file, enum 
v4l2_buf_type type)
bool is_sdr = vfd->vfl_type == VFL_TYPE_SDR;
bool is_rx = vfd->vfl_dir != VFL_DIR_TX;
bool is_tx = vfd->vfl_dir != VFL_DIR_RX;
+   bool is_touch = vfd->vfl_type == VFL_TYPE_TOUCH_SENSOR;
 
if (ops == NULL)
return -EINVAL;
 
switch (type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
-   if (is_vid && is_rx &&
+   if ((is_vid || is_touch) 

[PATCH v2 8/8] Input: atmel_mxt_ts - add support for reference data

[Nick Dyer]

There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 66 +++-
 1 file changed, 56 insertions(+), 10 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index fca1096..1d9909f 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -135,6 +135,7 @@ struct t9_range {
 /* MXT_DEBUG_DIAGNOSTIC_T37 */
 #define MXT_DIAGNOSTIC_PAGEUP  0x01
 #define MXT_DIAGNOSTIC_DELTAS  0x10
+#define MXT_DIAGNOSTIC_REFS0x11
 #define MXT_DIAGNOSTIC_SIZE128
 
 #define MXT_FAMILY_1386160
@@ -247,6 +248,12 @@ struct mxt_dbg {
int input;
 };
 
+enum v4l_dbg_inputs {
+   MXT_V4L_INPUT_DELTAS,
+   MXT_V4L_INPUT_REFS,
+   MXT_V4L_INPUT_MAX,
+};
+
 static const struct v4l2_file_operations mxt_video_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
@@ -2270,6 +2277,7 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
u16 *ptr;
int ret;
+   u8 mode;
 
ptr = vb2_plane_vaddr(vb, 0);
if (!ptr) {
@@ -2277,7 +2285,18 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
goto fault;
}
 
-   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   switch (data->dbg.input) {
+   case MXT_V4L_INPUT_DELTAS:
+   default:
+   mode = MXT_DIAGNOSTIC_DELTAS;
+   break;
+
+   case MXT_V4L_INPUT_REFS:
+   mode = MXT_DIAGNOSTIC_REFS;
+   break;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, mode, ptr);
if (ret)
goto fault;
 
@@ -2327,13 +2346,22 @@ static int mxt_vidioc_querycap(struct file *file, void 
*priv,
 static int mxt_vidioc_enum_input(struct file *file, void *priv,
   struct v4l2_input *i)
 {
-   if (i->index > 0)
+   if (i->index >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
i->type = V4L2_INPUT_TYPE_CAMERA;
i->std = V4L2_STD_UNKNOWN;
i->capabilities = 0;
-   strlcpy(i->name, "Mutual References", sizeof(i->name));
+
+   switch (i->index) {
+   case MXT_V4L_INPUT_REFS:
+   strlcpy(i->name, "Mutual References", sizeof(i->name));
+   break;
+   case MXT_V4L_INPUT_DELTAS:
+   strlcpy(i->name, "Mutual Deltas", sizeof(i->name));
+   break;
+   }
+
return 0;
 }
 
@@ -2341,12 +2369,16 @@ static int mxt_set_input(struct mxt_data *data, 
unsigned int i)
 {
struct v4l2_pix_format *f = >dbg.format;
 
-   if (i > 0)
+   if (i >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
+   if (i == MXT_V4L_INPUT_DELTAS)
+   f->pixelformat = V4L2_PIX_FMT_YS16;
+   else
+   f->pixelformat = V4L2_PIX_FMT_Y16;
+
f->width = data->xy_switch ? data->ysize : data->xsize;
f->height = data->xy_switch ? data->xsize : data->ysize;
-   f->pixelformat = V4L2_PIX_FMT_YS16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
f->bytesperline = f->width * sizeof(u16);
@@ -2383,12 +2415,26 @@ static int mxt_vidioc_fmt(struct file *file, void 
*priv, struct v4l2_format *f)
 static int mxt_vidioc_enum_fmt(struct file *file, void *priv,
 struct v4l2_fmtdesc *fmt)
 {
-   if (fmt->index > 0 || fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   if (fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   return -EINVAL;
+
+   switch (fmt->index) {
+   case 0:
+   fmt->pixelformat = V4L2_PIX_FMT_Y16;
+   strlcpy(fmt->description, "16-bit unsigned raw debug data",
+   sizeof(fmt->description));
+   break;
+
+   case 1:
+   fmt->pixelformat = V4L2_PIX_FMT_YS16;
+   strlcpy(fmt->description, "16-bit signed raw debug data",
+   sizeof(fmt->description));
+   break;
+
+   default:
return -EINVAL;
+   }
 
-   fmt->pixelformat = V4L2_PIX_FMT_YS16;
-   strlcpy(fmt->description, "16-bit raw debug data",
-   sizeof(fmt->description));
fmt->flags = 0;
return 0;
 }
@@ -2410,7 +2456,7 @@ static int mxt_vidioc_enum_framesizes(struct file *file, 
void *priv,
 static int mxt_vidioc_enum_frameintervals(struct file *file, void *priv,
  struct v4l2_frmivalenum *f)
 {
-   if ((f->index > 0) || (f->pixel_format != V4L2_PIX_FMT_YS16))
+   if (f->index > 0)
return -EINVAL;
 
f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
-- 
2.5.0

--
To unsubscribe from this list: send the line 

[PATCH v2 4/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

[Nick Dyer]

Register a video device to output T37 diagnostic data.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/Kconfig|   2 +
 drivers/input/touchscreen/atmel_mxt_ts.c | 271 +++
 2 files changed, 273 insertions(+)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 1f99e7f..4aa7609 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -105,6 +105,8 @@ config TOUCHSCREEN_AR1021_I2C
 config TOUCHSCREEN_ATMEL_MXT
tristate "Atmel mXT I2C Touchscreen"
depends on I2C
+   depends on VIDEO_V4L2
+   select VIDEOBUF2_VMALLOC
select FW_LOADER
help
  Say Y here if you have Atmel mXT series I2C touchscreen,
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index cd97713..8945235 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /* Firmware files */
 #define MXT_FW_NAME"maxtouch.fw"
@@ -222,6 +226,23 @@ struct mxt_dbg {
struct t37_debug *t37_buf;
unsigned int t37_pages;
unsigned int t37_nodes;
+
+   struct v4l2_device v4l2;
+   struct v4l2_pix_format format;
+   struct video_device vdev;
+   struct vb2_queue queue;
+   struct mutex lock;
+   int input;
+};
+
+static const struct v4l2_file_operations mxt_video_fops = {
+   .owner = THIS_MODULE,
+   .open = v4l2_fh_open,
+   .release = vb2_fop_release,
+   .unlocked_ioctl = video_ioctl2,
+   .read = vb2_fop_read,
+   .mmap = vb2_fop_mmap,
+   .poll = vb2_fop_poll,
 };
 
 /* Each client has this additional data */
@@ -277,6 +298,11 @@ struct mxt_data {
struct completion crc_completion;
 };
 
+struct mxt_vb2_buffer {
+   struct vb2_buffer   vb;
+   struct list_headlist;
+};
+
 static size_t mxt_obj_size(const struct mxt_object *obj)
 {
return obj->size_minus_one + 1;
@@ -1523,6 +1549,9 @@ static void mxt_free_input_device(struct mxt_data *data)
 
 static void mxt_free_object_table(struct mxt_data *data)
 {
+   video_unregister_device(>dbg.vdev);
+   v4l2_device_unregister(>dbg.v4l2);
+
kfree(data->object_table);
data->object_table = NULL;
kfree(data->msg_buf);
@@ -2154,10 +2183,215 @@ wait_cmd:
return mxt_convert_debug_pages(data, outbuf);
 }
 
+static int mxt_queue_setup(struct vb2_queue *q,
+  unsigned int *nbuffers, unsigned int *nplanes,
+  unsigned int sizes[], void *alloc_ctxs[])
+{
+   struct mxt_data *data = q->drv_priv;
+
+   *nbuffers = 1;
+   *nplanes = 1;
+   sizes[0] = data->dbg.t37_nodes * sizeof(u16);
+
+   return 0;
+}
+
+static int mxt_buffer_prepare(struct vb2_buffer *vb)
+{
+   return 0;
+}
+
+static void mxt_buffer_queue(struct vb2_buffer *vb)
+{
+   struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
+   u16 *ptr;
+   int ret;
+
+   ptr = vb2_plane_vaddr(vb, 0);
+   if (!ptr) {
+   dev_err(>client->dev, "Error acquiring frame ptr\n");
+   goto fault;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   if (ret)
+   goto fault;
+
+   vb2_set_plane_payload(vb, 0, data->dbg.t37_nodes * sizeof(u16));
+   vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+   return;
+
+fault:
+   vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+}
+
+/* V4L2 structures */
+static const struct vb2_ops mxt_queue_ops = {
+   .queue_setup= mxt_queue_setup,
+   .buf_prepare= mxt_buffer_prepare,
+   .buf_queue  = mxt_buffer_queue,
+   .wait_prepare   = vb2_ops_wait_prepare,
+   .wait_finish= vb2_ops_wait_finish,
+};
+
+static const struct vb2_queue mxt_queue = {
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+   .io_modes = VB2_MMAP,
+   .buf_struct_size = sizeof(struct mxt_vb2_buffer),
+   .ops = _queue_ops,
+   .mem_ops = _vmalloc_memops,
+   .timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
+   .min_buffers_needed = 1,
+};
+
+static int mxt_vidioc_querycap(struct file *file, void *priv,
+struct v4l2_capability *cap)
+{
+   struct mxt_data *data = video_drvdata(file);
+
+   strlcpy(cap->driver, "atmel_mxt_ts", sizeof(cap->driver));
+   strlcpy(cap->card, "atmel_mxt_ts touch", sizeof(cap->card));
+   strlcpy(cap->bus_info, data->phys, sizeof(cap->bus_info));
+   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE |
+   V4L2_CAP_READWRITE |
+   V4L2_CAP_STREAMING;
+   cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+
+   return 0;
+}
+
+static int mxt_vidioc_enum_input(struct file *file, void 

[PATCH v2 6/8] Input: atmel_mxt_ts - handle diagnostic data orientation

[Nick Dyer]

Invert the diagnostic data to match the orientation of the input device.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index dbe0f2f..b4abd78 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -125,6 +125,8 @@ struct t9_range {
 
 /* MXT_TOUCH_MULTI_T9 orient */
 #define MXT_T9_ORIENT_SWITCH   (1 << 0)
+#define MXT_T9_ORIENT_INVERTX  (1 << 1)
+#define MXT_T9_ORIENT_INVERTY  (1 << 2)
 
 /* MXT_SPT_COMMSCONFIG_T18 */
 #define MXT_COMMS_CTRL 0
@@ -156,6 +158,8 @@ struct t37_debug {
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
+#define MXT_T100_CFG_INVERTY   BIT(6)
+#define MXT_T100_CFG_INVERTX   BIT(7)
 
 #define MXT_T100_TCHAUX_VECT   BIT(0)
 #define MXT_T100_TCHAUX_AMPL   BIT(1)
@@ -260,6 +264,8 @@ struct mxt_data {
unsigned int irq;
unsigned int max_x;
unsigned int max_y;
+   bool invertx;
+   bool inverty;
bool xy_switch;
u8 xsize;
u8 ysize;
@@ -1743,6 +1749,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return error;
 
data->xy_switch = orient & MXT_T9_ORIENT_SWITCH;
+   data->invertx = orient & MXT_T9_ORIENT_INVERTX;
+   data->inverty = orient & MXT_T9_ORIENT_INVERTY;
 
return 0;
 }
@@ -1797,6 +1805,8 @@ static int mxt_read_t100_config(struct mxt_data *data)
return error;
 
data->xy_switch = cfg & MXT_T100_CFG_SWITCHXY;
+   data->invertx = cfg & MXT_T100_CFG_INVERTX;
+   data->inverty = cfg & MXT_T100_CFG_INVERTY;
 
/* allocate aux bytes */
error =  __mxt_read_reg(client,
@@ -2140,13 +2150,19 @@ static int mxt_convert_debug_pages(struct mxt_data 
*data, u16 *outbuf)
struct mxt_dbg *dbg = >dbg;
unsigned int x = 0;
unsigned int y = 0;
-   unsigned int i;
+   unsigned int i, rx, ry;
 
for (i = 0; i < dbg->t37_nodes; i++) {
-   outbuf[i] = mxt_get_debug_value(data, x, y);
+   /* Handle orientation */
+   rx = data->xy_switch ? y : x;
+   ry = data->xy_switch ? x : y;
+   rx = data->invertx ? (data->xsize - 1 - rx) : rx;
+   ry = data->inverty ? (data->ysize - 1 - ry) : ry;
+
+   outbuf[i] = mxt_get_debug_value(data, rx, ry);
 
/* Next value */
-   if (++x >= data->xsize) {
+   if (++x >= (data->xy_switch ? data->ysize : data->xsize)) {
x = 0;
y++;
}
@@ -2310,8 +2326,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->xsize;
-   f->height = data->ysize;
+   f->width = data->xy_switch ? data->ysize : data->xsize;
+   f->height = data->xy_switch ? data->xsize : data->ysize;
f->pixelformat = V4L2_PIX_FMT_YS16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
@@ -2367,8 +2383,8 @@ static int mxt_vidioc_enum_framesizes(struct file *file, 
void *priv,
if (f->index > 0)
return -EINVAL;
 
-   f->discrete.width = data->xsize;
-   f->discrete.height = data->ysize;
+   f->discrete.width = data->xy_switch ? data->ysize : data->xsize;
+   f->discrete.height = data->xy_switch ? data->xsize : data->ysize;
f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
return 0;
 }
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

[Nick Dyer]

This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. It's a rewrite of the previous implementation which output via
debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.

There are significant performance advantages to putting this code into the
driver.  The algorithm for retrieving the data has been fairly consistent
across a range of chips, with the exception of the mXT1386 series (see patch).

We have a utility which can read the data and display it in a useful format:
https://github.com/ndyer/heatmap/commits/heatmap-v4l

These patches are also available from
https://github.com/ndyer/linux/commits/diagnostic-v4l

Changes in v2:
- Split pixfmt changes into separate commit and add DocBook
- Introduce VFL_TYPE_TOUCH_SENSOR and /dev/v4l-touch
- Remove "single node" support for now, it may be better to treat it as 
metadata later
- Explicitly set VFL_DIR_RX
- Fix Kconfig

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/8] Input: atmel_mxt_ts - read touchscreen size

[Nick Dyer]

The touchscreen may have a margin where not all the matrix is used. Read
the parameters from T9 and T100 and take account of the difference.

Note: this does not read the XORIGIN/YORIGIN fields so it assumes that
the touchscreen starts at (0,0)

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 47 ++--
 1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 8945235..dbe0f2f 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -103,6 +103,8 @@ struct t7_config {
 
 /* MXT_TOUCH_MULTI_T9 field */
 #define MXT_T9_CTRL0
+#define MXT_T9_XSIZE   3
+#define MXT_T9_YSIZE   4
 #define MXT_T9_ORIENT  9
 #define MXT_T9_RANGE   18
 
@@ -148,7 +150,9 @@ struct t37_debug {
 #define MXT_T100_CTRL  0
 #define MXT_T100_CFG1  1
 #define MXT_T100_TCHAUX3
+#define MXT_T100_XSIZE 9
 #define MXT_T100_XRANGE13
+#define MXT_T100_YSIZE 20
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
@@ -257,6 +261,8 @@ struct mxt_data {
unsigned int max_x;
unsigned int max_y;
bool xy_switch;
+   u8 xsize;
+   u8 ysize;
bool in_bootloader;
u16 mem_size;
u8 t100_aux_ampl;
@@ -1710,6 +1716,18 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return -EINVAL;
 
error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
   object->start_address + MXT_T9_RANGE,
   sizeof(range), );
if (error)
@@ -1759,6 +1777,18 @@ static int mxt_read_t100_config(struct mxt_data *data)
 
data->max_y = get_unaligned_le16(_y);
 
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
/* read orientation config */
error =  __mxt_read_reg(client,
object->start_address + MXT_T100_CFG1,
@@ -2116,7 +2146,7 @@ static int mxt_convert_debug_pages(struct mxt_data *data, 
u16 *outbuf)
outbuf[i] = mxt_get_debug_value(data, x, y);
 
/* Next value */
-   if (++x >= data->info.matrix_xsize) {
+   if (++x >= data->xsize) {
x = 0;
y++;
}
@@ -2280,8 +2310,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->info.matrix_xsize;
-   f->height = data->info.matrix_ysize;
+   f->width = data->xsize;
+   f->height = data->ysize;
f->pixelformat = V4L2_PIX_FMT_YS16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
@@ -2337,8 +2367,8 @@ static int mxt_vidioc_enum_framesizes(struct file *file, 
void *priv,
if (f->index > 0)
return -EINVAL;
 
-   f->discrete.width = data->info.matrix_xsize;
-   f->discrete.height = data->info.matrix_ysize;
+   f->discrete.width = data->xsize;
+   f->discrete.height = data->ysize;
f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
return 0;
 }
@@ -2411,9 +2441,10 @@ static void mxt_debug_init(struct mxt_data *data)
dbg->t37_address = object->start_address;
 
/* Calculate size of data and allocate buffer */
-   dbg->t37_nodes = data->info.matrix_xsize * data->info.matrix_ysize;
-   dbg->t37_pages = dbg->t37_nodes * sizeof(u16)
-   / sizeof(dbg->t37_buf->data) + 1;
+   dbg->t37_nodes = data->xsize * data->ysize;
+   dbg->t37_pages = ((data->xsize * data->info.matrix_ysize)
+ * sizeof(u16) / sizeof(dbg->t37_buf->data)) + 1;
+
 
dbg->t37_buf = devm_kzalloc(>client->dev,
 sizeof(struct t37_debug) * dbg->t37_pages,
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH v2 7/8] Input: atmel_mxt_ts - add diagnostic data support for mXT1386

[Nick Dyer]

The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index b4abd78..fca1096 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -137,6 +137,10 @@ struct t9_range {
 #define MXT_DIAGNOSTIC_DELTAS  0x10
 #define MXT_DIAGNOSTIC_SIZE128
 
+#define MXT_FAMILY_1386160
+#define MXT1386_COLUMNS3
+#define MXT1386_PAGES_PER_COLUMN   8
+
 struct t37_debug {
u8 mode;
u8 page;
@@ -2135,13 +2139,27 @@ recheck:
 static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
   unsigned int y)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
unsigned int ofs, page;
+   unsigned int col = 0;
+   unsigned int col_width;
+
+   if (info->family_id == MXT_FAMILY_1386) {
+   col_width = info->matrix_ysize / MXT1386_COLUMNS;
+   col = y / col_width;
+   y = y % col_width;
+   } else {
+   col_width = info->matrix_ysize;
+   }
 
-   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   ofs = (y + (x * col_width)) * sizeof(u16);
page = ofs / MXT_DIAGNOSTIC_SIZE;
ofs %= MXT_DIAGNOSTIC_SIZE;
 
+   if (info->family_id == MXT_FAMILY_1386)
+   page += col * MXT1386_PAGES_PER_COLUMN;
+
return get_unaligned_le16(>t37_buf[page].data[ofs]);
 }
 
@@ -2435,6 +2453,7 @@ static const struct video_device mxt_video_device = {
 
 static void mxt_debug_init(struct mxt_data *data)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
struct mxt_object *object;
int error;
@@ -2458,9 +2477,13 @@ static void mxt_debug_init(struct mxt_data *data)
 
/* Calculate size of data and allocate buffer */
dbg->t37_nodes = data->xsize * data->ysize;
-   dbg->t37_pages = ((data->xsize * data->info.matrix_ysize)
- * sizeof(u16) / sizeof(dbg->t37_buf->data)) + 1;
 
+   if (info->family_id == MXT_FAMILY_1386)
+   dbg->t37_pages = MXT1386_COLUMNS * MXT1386_PAGES_PER_COLUMN;
+   else
+   dbg->t37_pages = ((data->xsize * info->matrix_ysize)
+  * sizeof(u16) / sizeof(dbg->t37_buf->data))
+  + 1;
 
dbg->t37_buf = devm_kzalloc(>client->dev,
 sizeof(struct t37_debug) * dbg->t37_pages,
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/8] [media] Add signed 16-bit pixel format

[Nick Dyer]

This will be used for output of raw touch data.

Signed-off-by: Nick Dyer 
---
 Documentation/DocBook/media/v4l/pixfmt-ys16.xml | 79 +
 Documentation/DocBook/media/v4l/pixfmt.xml  |  1 +
 drivers/media/v4l2-core/v4l2-ioctl.c|  1 +
 include/uapi/linux/videodev2.h  |  1 +
 4 files changed, 82 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-ys16.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-ys16.xml 
b/Documentation/DocBook/media/v4l/pixfmt-ys16.xml
new file mode 100644
index 000..f92d65e
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-ys16.xml
@@ -0,0 +1,79 @@
+
+  
+V4L2_PIX_FMT_YS16 ('YS16')
+
+  
+  
+V4L2_PIX_FMT_YS16
+Grey-scale image
+  
+  
+Description
+
+This is a signed grey-scale image with a depth of 16 bits per
+pixel. The most significant byte is stored at higher memory addresses
+(little-endian).
+
+
+  V4L2_PIX_FMT_YS16 4  4
+pixel image
+
+  
+   Byte Order.
+   Each cell is one byte.
+ 
+   
+ 
+ 
+   
+ start+0:
+ Y'00low
+ Y'00high
+ Y'01low
+ Y'01high
+ Y'02low
+ Y'02high
+ Y'03low
+ Y'03high
+   
+   
+ start+8:
+ Y'10low
+ Y'10high
+ Y'11low
+ Y'11high
+ Y'12low
+ Y'12high
+ Y'13low
+ Y'13high
+   
+   
+ start+16:
+ Y'20low
+ Y'20high
+ Y'21low
+ Y'21high
+ Y'22low
+ Y'22high
+ Y'23low
+ Y'23high
+   
+   
+ start+24:
+ Y'30low
+ Y'30high
+ Y'31low
+ Y'31high
+ Y'32low
+ Y'32high
+ Y'33low
+ Y'33high
+   
+ 
+   
+ 
+   
+  
+
+  
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index d871245..6f7aa0e 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -1619,6 +1619,7 @@ information.
 
 
 
+
 
 
 
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 8a018c6..c7dabaa 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1154,6 +1154,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_Y10:  descr = "10-bit Greyscale"; break;
case V4L2_PIX_FMT_Y12:  descr = "12-bit Greyscale"; break;
case V4L2_PIX_FMT_Y16:  descr = "16-bit Greyscale"; break;
+   case V4L2_PIX_FMT_YS16: descr = "16-bit Greyscale (Signed)"; 
break;
case V4L2_PIX_FMT_Y16_BE:   descr = "16-bit Greyscale BE"; break;
case V4L2_PIX_FMT_Y10BPACK: descr = "10-bit Greyscale (Packed)"; 
break;
case V4L2_PIX_FMT_PAL8: descr = "8-bit Palette"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 14cd5eb..ab577dd 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -496,6 +496,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12  Greyscale  
   */
 #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16  Greyscale  
   */
 #define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16  
Greyscale BE  */
+#define V4L2_PIX_FMT_YS16v4l2_fourcc('Y', 'S', '1', '6') /* signed 16-bit 
Greyscale */
 
 /* Grey bit-packed formats */
 #define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10  
Greyscale bit-packed */
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Jonathan Corbet]

On Wed, 4 May 2016 13:50:35 -0300
Mauro Carvalho Chehab  wrote:

> Em Wed, 4 May 2016 19:13:21 +0300
> Jani Nikula  escreveu:
> > I think we should go for vanilla sphinx at first, to make the setup step
> > as easy as possible for everyone.  
> 
> Vanilla Sphinx doesn't work, as reST markup language is too limited
> to support the docs we have. So, we should either push the needed
> extensions to Sphinx reST or find a way to put it at Kernel tree
> without causing too much pain for the developers, e. g. as something
> that just doing "make htmldoc" would automatically use such extensions
> without needing to actually install the extensions.

It works for everything except the extended media book, right?  Or is there
something I'm missing here?  I am very much interested in having one system
for *all* our docs, but we wouldn't attempt to convert a document can't be
expressed in sphinx.

> > Even if it means still doing that ugly
> > docproc step to call kernel-doc. We can improve from there, and I
> > definitely appreciate your work on making this work with sphinx
> > extensions.  
> 
> I disagree: We should not cause documentation regressions by
> producing incomplete documentation and losing tables because of
> such conversion.

> The quality of the documentation after the change should be *at least*
> equal to the one we current produce, never worse.

Agreed; that's why I think the existing DocBook mechanism should stay in
place until that document will be improved by the change.  But I'd rather
not hold up the entire process for one book, especially since pushing that
process forward can only help in dealing with those final problems.

> > That said, how would it work to include the kernel-doc extension in the
> > kernel source tree? Having things just work if sphinx is installed is
> > preferred over requiring installation of something extra from pypi. (I
> > know this may sound backwards for a lot of projects, but for kernel I'm
> > pretty sure this is how it should be done.)  
> 
> Yeah, using pypi seems an additional undesired step. Aren't there
> any way to make python to use an additional extension at the
> Kernel tree without needing to install it?

Well, sphinx has to come from somewhere too.  But yes, we should be able to
carry extensions in the kernel tree.  But I would still rather upstream it
(to sphinx) if possible, so we're not stuck trying to maintain it across
several sphinx releases.  I don't know how volatile their interfaces are,
but it would be, in any case, the analog of an out-of-tree module...

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 19:13:21 +0300
Jani Nikula  escreveu:

> On Wed, 04 May 2016, Markus Heiser  wrote:
> > Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
> > particular with your "MARKDOWNREADY := gpu.xml" process.
> >
> > As I understood, you convert markdown to docbook within the kernel-doc 
> > script using pandoc's executable? ... I don't face this topic. With my 
> > modification of kernel-doc I produced pure reST markup from standardize
> > kernel-doc markup, no intermediate steps or tools required.  
> 
> That pandoc thing is a dead end. Forget about it. I think we've all
> pretty much agreed we should have kernel-doc produce the lightweight
> markup directly since [1].
> 
> [1] 
> http://mid.gmane.org/1453106477-21359-1-git-send-email-jani.nik...@intel.com
> 
> > Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :
> >  
> >> I think all of this makes sense.  It would be really nice to have the
> >> directives in the native sphinx language like that.  I *don't* think we
> >> need to aim for that at the outset; the docproc approach works until we can
> >> properly get rid of it.  What would be *really* nice would be to get
> >> support for the kernel-doc directive into the sphinx upstream.  
> >
> > No need for kernel-doc directive in sphinx upstream, later it will be 
> > an extension which could be installed by a simple command like 
> > "pip install kernel-doc-extensions" or similar.
> >
> > I develop these required extension (and more) within my proof of concept
> > on github ... this takes time ... if I finished all my tests and all is
> > well, I will build the *kernel-doc-extensions* package and deploy it
> > on https://pypi.python.org/pypi from where everyone could install this 
> > with "pip".  
> 
> I think we should go for vanilla sphinx at first, to make the setup step
> as easy as possible for everyone.

Vanilla Sphinx doesn't work, as reST markup language is too limited
to support the docs we have. So, we should either push the needed
extensions to Sphinx reST or find a way to put it at Kernel tree
without causing too much pain for the developers, e. g. as something
that just doing "make htmldoc" would automatically use such extensions
without needing to actually install the extensions.

> Even if it means still doing that ugly
> docproc step to call kernel-doc. We can improve from there, and I
> definitely appreciate your work on making this work with sphinx
> extensions.

I disagree: We should not cause documentation regressions by
producing incomplete documentation and losing tables because of
such conversion.

The quality of the documentation after the change should be *at least*
equal to the one we current produce, never worse.

> That said, how would it work to include the kernel-doc extension in the
> kernel source tree? Having things just work if sphinx is installed is
> preferred over requiring installation of something extra from pypi. (I
> know this may sound backwards for a lot of projects, but for kernel I'm
> pretty sure this is how it should be done.)

Yeah, using pypi seems an additional undesired step. Aren't there
any way to make python to use an additional extension at the
Kernel tree without needing to install it?

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 08:57:13 -0600
Jonathan Corbet  escreveu:

> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter  wrote:
> 
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff with impunity in gpu documentations.
> > 
> > Aside: If we decide this now I could send in a pull request for the
> > rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
> > markdown/asciidoc code I still have). That would be really awesome ...  
> 
> Sorry for my relative absence...I'm still busy dealing with bureaucracy
> an ocean away from home.  I hope to begin emerging from this mess in the
> near future.
> 
> So ... there's the code you have, the work I (+Jani) did, and the work
> Markus has done.  Which would you have me push into 4.7?

IMHO, Markus approach is the one that is providing a better result,
as it added support for missing features that we require for the
media DocBook.

Still, it seems premature to merge it for 4.7.

Markus is getting real progress on converting the media docs to work
with Sphynx, but there are still troubles when the table is big, as,
currently, it is truncating everything that passes the right margin
on some tables.

So, IMHO, the next action item would be to be sure that big tables 
will not be truncated. Assuming that he can fix that in time, we
can merge it for 4.8, and then start porting the documentation to
use it.

Btw, converting the DocBook/media Makefile will require an extra
step, as part of the documentation is generated via scripts (some
C file examples, and include/uapi headers). Those scripts also
warrant that (almost) every API at include/uapi is synchronized
with the DocBook. I use this on my patch review process, in order
to reject patches that don't add the proper documentation updates.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Wolfram Sang]

> A question on best practices here... I already did a v8 (but only as
> a branch) so I think this will be v9, bit that's a minor detail. The
> real question is what I should do about patches 1-15 that are already
> in next? Send them too? If not, should I send 16-24 with the same old
> patch numbers or should they be numbered 1-9 now? And should such a
> shortened series be rebased on 1-15 in next?
> 
> Or does it not really matter?

Easiest for me is:

Send as v9, only the patches not yet applied, numbered from 1-9, based
on my for-next.



signature.asc
Description: PGP signature

Re: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 4, 2016 at 5:02 PM, Daniel Vetter  wrote:
> On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
>> On Wed, 4 May 2016 16:18:27 +0200
>> Daniel Vetter  wrote:
>>
>> > > I'd really like to converge on the markup question, so that we can start
>> > > using all the cool stuff with impunity in gpu documentations.
>> >
>> > Aside: If we decide this now I could send in a pull request for the
>> > rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
>> > markdown/asciidoc code I still have). That would be really awesome ...
>>
>> Sorry for my relative absence...I'm still busy dealing with bureaucracy
>> an ocean away from home.  I hope to begin emerging from this mess in the
>> near future.
>>
>> So ... there's the code you have, the work I (+Jani) did, and the work
>> Markus has done.  Which would you have me push into 4.7?
>>
>> The sphinx/rst approach does seem, to me, to be the right one, with the
>> existing DocBook structure remaining in place for those who want/need
>> it.  I'm inclined toward my stuff as a base to work with, obviously :) But
>> it's hackish at best and needs a lot of cleaning up.  It's a proof of
>> concept, but it's hardly finished (one might say it's barely begun...)
>>
>> In the end, I guess, I feel that anything we might try to push for 4.7 is
>> going to look rushed and not ready, and Linus might react accordingly.
>> I'd be more comfortable aiming for 4.8.  I *will* have more time to focus
>> on things in that time frame...  I suspect you're pretty well fed up with
>> this stuff being pushed back, and rightly so.  All I can do is apologize.
>>
>> That said, if you do think there's something out there that is good
>> enough to consider pushing in a week or two, do tell and we can all take
>> a look.
>
> Well I'd just have taken the asciidoc hacks I have currently in my
> topic/kerneldoc branch, converted to sphinx and looked how it fares. It
> should be fairly minimal, and I think the first step we want to do for the
> long-term plan. I hope I can ready something, and then we can look whether
> it's rushed for 4.7 or not.

Ok, discussed this a bit more with Jani on IRC and he really doesn't
like the old design of that branch (it calls the converter for every
kerneldoc comment). So I guess nothing rushed for 4.7, but hopefully
something for 4.8.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

[Sakari Ailus]

Hi Shuah,

Thanks for the review!

On Wed, May 04, 2016 at 08:50:56AM -0600, Shuah Khan wrote:
> On 05/04/2016 05:20 AM, Sakari Ailus wrote:
> > New IOCTLs (especially for the request API) do not necessarily need the
> > graph mutex acquired. Leave this up to the drivers.
> 
> Sakari,
> 
> Does this mean drivers have to hold the graph mutex as needed?
> My concern with this is that we will have graph_mutex holds in
> driver code in addition to the ones we have now. My concern with
> referencing graph_mutex from driver code is lack of abstraction.
> If we ever need to change grahp-mutex in the media-core, if it
> is exposed to drivers, then there will be lot of changes.
> 
> Could we look into avoiding drivers referencing graph_mutex
> directly?

I think we rather need to get rid of the graph mutex in the end; it's a bit
like the big kernel lock right now: most operations on the graph, whatever
they are, need it.

The case for not acquiring it (I have request API and events in mind, in
particular) for some IOCTLs is there. Drivers may need to acquire other
mutexes while holding the graph mutex, and the locking order has to be
maintained in order to avoid deadlocks.

Dequeueing events does not need the graph mutex, whereas requests changing
the graph state would need it for the time being.

The reason there's a flag to acquire the graph mutex (rather than not
acquiring it) is that it'd be easier to spot where it's needed.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Ismael Luceno]

From: Andrey Utkin 

Such frame size is met in practice. Also report oversized frames.

[ismael: Reworked warning and commit message]

Signed-off-by: Ismael Luceno 
---
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c 
b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 67a14c4..f98017b 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -33,7 +33,7 @@
 #include "solo6x10-jpeg.h"
 
 #define MIN_VID_BUFFERS2
-#define FRAME_BUF_SIZE (196 * 1024)
+#define FRAME_BUF_SIZE (200 * 1024)
 #define MP4_QS 16
 #define DMA_ALIGN  4096
 
@@ -323,8 +323,11 @@ static int solo_send_desc(struct solo_enc_dev *solo_enc, 
int skip,
int i;
int ret;
 
-   if (WARN_ON_ONCE(size > FRAME_BUF_SIZE))
+   if (WARN_ON_ONCE(size > FRAME_BUF_SIZE)) {
+   dev_warn(_dev->pdev->dev,
+"oversized frame (%d bytes)\n", size);
return -EINVAL;
+   }
 
solo_enc->desc_count = 1;
 
-- 
2.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] solo6x10: Simplify solo_enum_ext_input

[Ismael Luceno]

Additionally, now it specifies which channels it's showing.

Signed-off-by: Ismael Luceno 
---
 drivers/media/pci/solo6x10/solo6x10-v4l2.c | 34 ++
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c 
b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
index 721ff53..953d6bf 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
@@ -386,26 +386,24 @@ static int solo_querycap(struct file *file, void  *priv,
 static int solo_enum_ext_input(struct solo_dev *solo_dev,
   struct v4l2_input *input)
 {
-   static const char * const dispnames_1[] = { "4UP" };
-   static const char * const dispnames_2[] = { "4UP-1", "4UP-2" };
-   static const char * const dispnames_5[] = {
-   "4UP-1", "4UP-2", "4UP-3", "4UP-4", "16UP"
-   };
-   const char * const *dispnames;
-
-   if (input->index >= (solo_dev->nr_chans + solo_dev->nr_ext))
-   return -EINVAL;
-
-   if (solo_dev->nr_ext == 5)
-   dispnames = dispnames_5;
-   else if (solo_dev->nr_ext == 2)
-   dispnames = dispnames_2;
-   else
-   dispnames = dispnames_1;
+   int ext = input->index - solo_dev->nr_chans;
+   unsigned int nup, first;
 
-   snprintf(input->name, sizeof(input->name), "Multi %s",
-dispnames[input->index - solo_dev->nr_chans]);
+   if (ext >= solo_dev->nr_ext)
+   return -EINVAL;
 
+   nup   = (ext == 4) ? 16 : 4;
+   first = (ext & 3) << 2; /* first channel in the n-up */
+   snprintf(input->name, sizeof(input->name),
+"Multi %d-up (cameras %d-%d)",
+nup, first + 1, first + nup);
+   /* Possible outputs:
+*  Multi 4-up (cameras 1-4)
+*  Multi 4-up (cameras 5-8)
+*  Multi 4-up (cameras 9-12)
+*  Multi 4-up (cameras 13-16)
+*  Multi 16-up (cameras 1-16)
+*/
return 0;
 }
 
-- 
2.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Wed, 4 May 2016 11:34:08 +0200
Markus Heiser  escreveu:

> Hi all, (hi Jonathan, please take note of my offer below)
> 
> Am 03.05.2016 um 16:31 schrieb Daniel Vetter :
> 
> > Hi all,
> > 
> > So sounds like moving ahead with rst/sphinx is the option that should
> > allow us to address everyone's concerns eventually? Of course the
> > first one won't have it all (media seems really tricky), ...  
> 
> BTW: Mauro mentioned that ASCII-art tables are not diff-friendly ... 
> 
> Am 18.04.2016 um 13:16 schrieb Mauro Carvalho Chehab 
> :
> 
> > With that sense, the "List tables" format is also not good, as
> > one row addition would generate several hunks (one for each column
> > of the table), making harder to review the patch by just looking at
> > the diff.  
> 
> For this, I wrote the "flat-table" reST-directive, which adds 
> missing cells automatically:
> 
> doc:
> http://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table
> source: 
> https://github.com/return42/sphkerneldoc/blob/master/doc/extensions/rstFlatTable.py

Yeah, this should address the lack of a proper way to markup cell/row
spans, providing the additional bits for the tables we have at media.

Yet, there are some issues with table conversions. See below.

> 
> I used "flat-table" to migrate all DocBook-XML documents to reST. With this
> directive, I also managed to migrate the complete media book (no more TODOs)
> incl. the large tables like them from subdev-formats:
> 
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html
> 
> (Rendering large tables is a general discussion which should not take place 
> in this MT)

Some tables, like the one here:

https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/control.html

are truncated (tested with Mozilla and Chrome), and part of the information is
lost due to that.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Wed, 04 May 2016, Markus Heiser  wrote:
> Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
> particular with your "MARKDOWNREADY := gpu.xml" process.
>
> As I understood, you convert markdown to docbook within the kernel-doc 
> script using pandoc's executable? ... I don't face this topic. With my 
> modification of kernel-doc I produced pure reST markup from standardize
> kernel-doc markup, no intermediate steps or tools required.

That pandoc thing is a dead end. Forget about it. I think we've all
pretty much agreed we should have kernel-doc produce the lightweight
markup directly since [1].

[1] http://mid.gmane.org/1453106477-21359-1-git-send-email-jani.nik...@intel.com

> Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :
>
>> I think all of this makes sense.  It would be really nice to have the
>> directives in the native sphinx language like that.  I *don't* think we
>> need to aim for that at the outset; the docproc approach works until we can
>> properly get rid of it.  What would be *really* nice would be to get
>> support for the kernel-doc directive into the sphinx upstream.
>
> No need for kernel-doc directive in sphinx upstream, later it will be 
> an extension which could be installed by a simple command like 
> "pip install kernel-doc-extensions" or similar.
>
> I develop these required extension (and more) within my proof of concept
> on github ... this takes time ... if I finished all my tests and all is
> well, I will build the *kernel-doc-extensions* package and deploy it
> on https://pypi.python.org/pypi from where everyone could install this 
> with "pip".

I think we should go for vanilla sphinx at first, to make the setup step
as easy as possible for everyone. Even if it means still doing that ugly
docproc step to call kernel-doc. We can improve from there, and I
definitely appreciate your work on making this work with sphinx
extensions.

That said, how would it work to include the kernel-doc extension in the
kernel source tree? Having things just work if sphinx is installed is
preferred over requiring installation of something extra from pypi. (I
know this may sound backwards for a lot of projects, but for kernel I'm
pretty sure this is how it should be done.)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Add GS driver (SPI video serializer family)

[Charles-Antoine Couret]

Le 04/05/2016 à 15:46, Hans Verkuil a écrit :
>> Ok, but I should have difficulties to define correctly these standards.
>> I worked on video stream in SMPTE-125M and I don't know if other SMPTE 
>> standards are based on the same characteristics.
>> In addition to this, those standards are not public.
> 
> I have access to the SMPTE standards, I'll take a look next week.

Oh, nice. Thanks. :)

> Regarding timings: I think this requires a separate discussion. I need to 
> loop in 'nohous'
> who is also working on SDI support, but unfortunately I don't have his email 
> handy, otherwise
> I'd have CC-ed him.
> 
> I'm no SDI expert myself, but I think I should set time aside to read up on 
> this
> and figure out together with you guys how this should be handled.
> 
> So I don't have a quick answer here, this requires more R

Ok. I could help a little bit I think.

>>> So, regarding the reset, s_dv_timings and query_dv_timings: it's not clear
>>> what is happening here. The usual way things work is that the timings that
>>> s/g_dv_timings set and get are indepedent of the timings that are detected
>>> (query_dv_timings). The reason is that the explicitly set timings relate to
>>> the buffers that the DMA engine needs to store the frames. Receivers that
>>> spontaneously switch when new timings are detected can be very dangerous
>>> depending on the details of the DMA engine (think buffer overruns when you
>>> go from e.g. 720p to 1080p).
>>
>> It's the case here.
>> s/g_dv_timings are independent of query_detect_timings which reads internal 
>> registers to
>> define the stream detected by the component.
>>
>> The reset function are an error, I think.
>> By default the GS1662 is in auto-mode: it detects the input stream to create 
>> the serialized output stream.
>> The reset was to return in auto-mode selection, but this function should be 
>> to reset the component and not the mode.
>>
>> I don't have idea to define properly the auto-mode, for userspace and the 
>> driver.
>> It's a useful information and I think, the userspace should force this mode. 
>> Define a specific timings for that?
> 
> I think that you can use the s_stream op here: when you start streaming you 
> force
> the mode to whatever the timings set by s_dv_timings() requires. When you 
> stop streaming
> you go back to auto-mode.

Hum. I agree with you.
But, if the stream was starting without previous timings settings, I should use 
a default value or keep the auto-mode?
I prefer the auto-mode solution in this case.

>>> So typically when you set the timings the device is fixed to those timings,
>>> even if it receives something different. If the device supports an 
>>> interrupt,
>>> then it is good practice to hook into that interrupt and, when it detects
>>> that the timings changed, the device sends a V4L2_EVENT_SOURCE_CHANGE event.
>>>
>>> Userspace will then typically stop streaming, query the new timings, setup
>>> the new buffers and restart streaming.
>>
>> GS1662 don't have interruption line to do that.
>>
>>> Some devices cannot query the new timings unless they are in autodetect 
>>> mode.
>>> The correct implementation for that is that query_dv_timings returns EBUSY
>>> while the device is streaming (you hook into the s_stream core op to know 
>>> that),
>>> otherwise it configures itself to autodetect mode and sees what is detected.
>>>
>>> It is not really clear to me from the datasheet how this device behaves. But
>>> having to use the reset op is almost certainly wrong.
>>
>> I don't understand.
>> The GS1662 has a status to say the input format detected. Useful in 
>> auto-detect mode,
>> less in other cases. But, it needs a input, why send EBUSY error when the 
>> device streams?
> 
> Hmm, I don't understand either :-)
> 
> The question is: when the device is streaming video for a specific format (as 
> set
> by s_dv_timings), can it still detect the actual video format it receives? If 
> so,
> then there is no need for EBUSY since query_dv_timings will always work. If 
> not,
> then query_dv_timings should report that it is unable to query the detected 
> timings
> because it is in the wrong mode (EBUSY).

Oh, I see.

I didn't remember my results around that. I will configure like your suggestion.

> BTW, you also need to implement the g_input_status video op. I just realized 
> that
> that is missing. It is used to fill in the status field when calling 
> VIDIOC_ENUMINPUTS.

Ok, I will add that. Thanks.

> Remember that today there are no SDI drivers in the kernel. So you and nohous 
> are the first
> that work on this. So there will be some missing pieces that we need to add. 
> It seems that
> for SDI the timings are one such area.
> 
> It will be useful if you join the #v4l irc room 
> (http://linuxtv.org/lists.php).
> 
> I think that's a good place to have a meeting about this topic together with 
> nohous. I'm
> traveling for a bit but will be back on Tuesday. Perhaps we can schedule 
> something later
> that 

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Am 04.05.2016 um 15:43 schrieb Daniel Vetter :

> On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote:
>>> On Wed, 04 May 2016, Markus Heiser  wrote:
>>> I'd be *very* hesitant about adding the kind of things you do in
>>> reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc
>>> comments must be as simple as possible with basically pass-through of
>>> the comment blocks to sphinx.
>> 
>> Right, but you forgot, that the current markup in the source code comments
>> is based on the  kernel-doc-nano-HOWTO and I guess no one will migrate all
>> these source code comments to reST markup ;-)
>> 
>> So there is a need to differentiate between *vintage* kernel-doc markup 
>> and reST markup.
>> 
>> My suggestion is to add a tag to the comments, here a short example
>> what this might look like.
>> 
>>  --
>> /**
>> * drm_minor_release - Release DRM minor
>> * @minor: Pointer to DRM minor object
>> *
>> * Release a minor that was previously acquired via drm_minor_acquire().
>> */
>>  --
>> 
>> in short: the vintage style does not need any change and 
>> comments with reST markup has a tag ":reST:" in the first 
>> line(s) ...
>> 
>>  --
>> /**
>> * :reST:
>> *
>> * .. c:function:: void drm_minor_release(struct drm_minor *minor)
>> *
>> *Release DRM minor
>> *
>> *:param struct drm_minor \*minor: Pointer to DRM minor object
>> *
>> */
>>  --
>> 
>> Comments with the ":reST:" tag could be exported and pass-through
>> to sphinx.
>> 
>>> Specifically, do not attempt to detect and
>>> parse elements like lists in kernel-doc.
>> 
>> If your markup in the comments is plain reST, no need to parse, but there
>> are markups in the (vintage) comments which made use of individual 
>> text-markups, e.g. the markup of lists or ASCII-art. 
>> 
>> This individual text-markups has not been converted/rendered in the docbook
>> output, but I wanted to convert this individuals to reST, to render them in
>> Sphinx.
> 
> I think we need to unconfuse what's current standardize kerneldoc markup.
> There's three bits:
> - The header with the one-liner and parameters, i.e.

OK, forget my  example, I don't really want to promote
this way ... I agree, it is better to stay with standardize kernel-doc markup
and provide a "pass through" for the section-content (even if it is mixing 
markups).

Am 04.05.2016 um 15:41 schrieb Jani Nikula :

> Kernel-doc the tool should continue to parse kernel-doc comments at the
> high level like they currently are, according to the kernel-doc
> howto. 

The requirement was unclear for me, thanks to Daniel and 
Jani for clarifying this.


Am 04.05.2016 um 15:43 schrieb Daniel Vetter :

> This is already used widely in kerneldoc included by gpu.tmpl, and
> currently it's asciidoc. Those lists and asciiarts though are _not_
> standard kerneldoc at all. But imo any doc toolchain improvement should
> integrate along those lines.
> 
> For reference, this is what it's supposed to look like with the asciidoc
> support enabled:
> 
> https://dri.freedesktop.org/docs/drm/API-struct-drm-display-mode.html
> 
> Fyi those hacked-up patches to make this happen are available in
> 
> https://cgit.freedesktop.org/drm-intel/log/?h=topic/kerneldoc
> 

Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
particular with your "MARKDOWNREADY := gpu.xml" process.

As I understood, you convert markdown to docbook within the kernel-doc 
script using pandoc's executable? ... I don't face this topic. With my 
modification of kernel-doc I produced pure reST markup from standardize
kernel-doc markup, no intermediate steps or tools required.

Am 04.05.2016 um 15:41 schrieb Jani Nikula :

> Overall I think we should promote fixing those in the kernel-doc
> comments. Trying to guesswork in kernel-doc tool will leave the source
> littered with bad examples that get proliferated all around. Instead of
> gradually fixing things, we'll end up gradually messing things up even
> more.

I agree with you, lets drop the reformat_block_rst from my kernel-doc script:

* https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc#L1736

and we should have a plain "pass through".

Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :

> I think all of this makes sense.  It would be really nice to have the
> directives in the native sphinx language like that.  I *don't* think we
> need to aim for that at the outset; the docproc approach works until we can
> properly get rid of it.  What would be *really* nice would be to get
> support for the kernel-doc directive into the sphinx upstream.

No need for kernel-doc directive in sphinx upstream, later it will be 
an extension which could be installed by a simple command like 
"pip install kernel-doc-extensions" or similar.

I develop these required extension (and more) within my proof of 

Re: [PATCH v2] Add GS driver (SPI video serializer family)

[Charles-Antoine Couret]

Le 04/05/2016 à 13:41, Hans Verkuil a écrit :
> Hi Charles-Antoine,

Hi,

> On 04/28/2016 04:10 PM, Charles-Antoine Couret wrote:
>> But this component family support CEA standards and other
>> (SMPTE XXXM in fact). V4L2 seems oriented to manage CEA or
>> VGA formats. So, I used timings structure with CEA values, but I
>> fill timings fields manually for other standards. I don't know if it
>> is the right method or if another interface should be more interesting.
> 
> As long as the timings are part of a standard, then just add them to
> the v4l2-dv-timings.h header. Since these timings aren't part of the CEA-861
> standard or the DMT VESA standard, just add a new SMPTE standard flag.

Ok, but I should have difficulties to define correctly these standards.
I worked on video stream in SMPTE-125M and I don't know if other SMPTE 
standards are based on the same characteristics.
In addition to this, those standards are not public.

For the SMPTE-125M, I have these information:
* Pixelclock : 27 MHz (I set 13.5MHz to have 60 FPS because its a interlaced 
signal, I don't know if it's correct)
* The organization of lines :
Line 1 to 9 : blanking
Line 10 to 19 : options (blanking in my case for example)
Line 20 to 264 : field 1
Line 266 to 272 : blanking
Line 273 to 282 : options
Line 283 to 525 : field 2

The time of blanking are not regular: 19 then 18 lines, how translate that in 
dv_timings?
The size of fields is different too.

The Field signal is changed in 266 line.
* Complete format size (with blanking) ; 858x525
* Image size : 720x487

Organization of horizontal sync :
Pixel 0 to 719 : active pixels
Pixel 720 to 857 : blanking (but the firsts 16 pixels are the front porch, but 
after, no info for sync or back porch timings)

Polarity: V-, H+

And, I don't have info for other standards and the GS1662 don't need that too.
I should create SMPTE format but only for the 125M? And the driver shouldn't 
use / consider other SMPTE formats without a right definition?

>> This patch was tested with GS1662:
>> http://www.c-dis.net/media/871/GS1662_Datasheet.pdf
> 
> A pointer to this datasheet should be in a comment in the source code.

Ok. The commit message should keep the link too?


>>  drivers/media/spi/gs.c | 482 
>> +
> 
> I would just call it gs1662. That's all you've tested with, after all.
> 
> It is very common that drivers named after the first supported model also
> support similar models.

Ok, thanks.

>> +struct gs {
> 
> The gs prefix is rather ugly. I'd just use gs_ instead.

Yes, I agree with you.

>> +static void custom_to_timings(const struct gs_reg_fmt_custom *custom,
>> +  struct v4l2_dv_timings *timings)
>> +{
>> +timings->type = V4L2_DV_BT_656_1120;
>> +timings->bt.width = custom->width;
>> +timings->bt.height = custom->height;
>> +timings->bt.pixelclock = custom->pixelclock;
>> +timings->bt.interlaced = custom->interlaced;
>> +timings->bt.polarities = 0;
>> +timings->bt.hbackporch = 0;
>> +timings->bt.hsync = 0;
>> +timings->bt.hfrontporch = 0;
>> +timings->bt.vbackporch = 0;
>> +timings->bt.vsync = 0;
>> +timings->bt.vfrontporch = 0;
>> +timings->bt.il_vbackporch = 0;
>> +timings->bt.il_vsync = 0;
>> +timings->bt.il_vfrontporch = 0;
> 
> You still need to set the total blanking sizes, right?
> 
> For now assign that to the [hv]frontporch, leaving the sync and
> backporch fields 0. I need to make some rules how this is handled when
> the standard doesn't separate the blanking into back/frontporch and syncs.

Seeing my first comment.
I could precise some info (for 125M) but not for all of them.
And the GS1662 don't care about those information: we can't configure timings, 
only ask a specific format.

And, how manage the case of there are two different timings for vertical 
blanking for one image in the standard?

>> +timings->bt.standards = 0;
> 
> So we need to define a proper standard for this.

Yes.
 
> So, regarding the reset, s_dv_timings and query_dv_timings: it's not clear
> what is happening here. The usual way things work is that the timings that
> s/g_dv_timings set and get are indepedent of the timings that are detected
> (query_dv_timings). The reason is that the explicitly set timings relate to
> the buffers that the DMA engine needs to store the frames. Receivers that
> spontaneously switch when new timings are detected can be very dangerous
> depending on the details of the DMA engine (think buffer overruns when you
> go from e.g. 720p to 1080p).

It's the case here.
s/g_dv_timings are independent of query_detect_timings which reads internal 
registers to
define the stream detected by the component.

The reset function are an error, I think.
By default the GS1662 is in auto-mode: it detects the input stream to create 
the serialized output stream.
The reset was to return in auto-mode selection, but this function should be to 

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Wed, 04 May 2016, Jonathan Corbet  wrote:
> The sphinx/rst approach does seem, to me, to be the right one, with the
> existing DocBook structure remaining in place for those who want/need
> it.  I'm inclined toward my stuff as a base to work with, obviously :) But
> it's hackish at best and needs a lot of cleaning up.  It's a proof of
> concept, but it's hardly finished (one might say it's barely begun...)

Thanks. I'll start looking at how to make it less hackish and more
upstreamable.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Hans Verkuil]

On 05/04/2016 04:22 PM, Andrey Utkin wrote:
> On Wed, May 4, 2016 at 5:04 PM, Hans Verkuil  wrote:
>> BTW, looking at the MAINTAINERS file I see two email addresses for Andrey,
>> neither of which is the fastmail.com address this email came from.
> 
> Now I'm replying from corporate email.
> 
>> Andrey, it might be a good idea to post such fixes to the mailinglist sooner,
>> both to prevent situations like this and to keep the diffs between mainline
>> and your internal code as small as possible.
> 
> In a word - we would do what is possible to achieve that, but there's
> little time
> and little incentive for that.
> The codebases have already diverged a lot, having unique sets of runtime bugs.
> And this exact issue alone is not resolved yet in a good way and is
> not actually critical.
> Merging would require a lot of working time. And it is complicated by
> the fact that
> there's not going to be any new manufacturing orders (the minimal order 
> quantity
> is too high for Bluecherry), and that we have picked tw5864 as
> reachable for retail orders.
> 

It sounds more like the status of this driver is "Odd Fixes" and not "Supported"
as it says today. From the MAINTAINERS file:

S: Status, one of the following:
   Supported:   Someone is actually paid to look after this.
   Maintained:  Someone actually looks after it.
   Odd Fixes:   It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
   Orphan:  No current maintainer [but maybe you could take the
role as you write your new code].
   Obsolete:Old code. Something tagged obsolete generally means
it has been replaced by a better system and you
should be using that.

Yes, Ismael should have kept your authorship, but it won't be the first time
someone forgets that. Heck, I've forgotten it on occasion. Just point that out
politely and let Ismael post a new version of this patch.

Don't look for conspiracies when it is just a mistake. Relax, peace on earth,
don't worry, be happy and all that. Bad for everyone's blood pressure to get
so worked up about these things.

Looking at the recent history of this driver the patch contributions seem to
be more-or-less equally distributed between Krzysztof, Andrey and Ismael, not
that there are all that many.

So if Ismael is merging in some of your patches for free in his own time, then
I'd say why not? Again, provided correct authorship is maintained.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Ismael Luceno]

On 04/May/2016 17:22, Andrey Utkin wrote:
> On Wed, May 4, 2016 at 5:04 PM, Hans Verkuil  wrote:
> > BTW, looking at the MAINTAINERS file I see two email addresses for Andrey,
> > neither of which is the fastmail.com address this email came from.
> 
> Now I'm replying from corporate email.
> 
> > Andrey, it might be a good idea to post such fixes to the mailinglist 
> > sooner,
> > both to prevent situations like this and to keep the diffs between mainline
> > and your internal code as small as possible.
> 
> In a word - we would do what is possible to achieve that, but
> there's little time and little incentive for that.
> The codebases have already diverged a lot, having unique sets of runtime bugs.

The divergence is due to the vb2 porting effort by Hans. History
was not properly conserved, but it is otherwise compatible, and most
changes can still be ported back and forth without trouble.

> And this exact issue alone is not resolved yet in a good way and is
> not actually critical.
> Merging would require a lot of working time. And it is complicated by
> the fact that there's not going to be any new manufacturing orders
> (the minimal order quantity is too high for Bluecherry), and that
> we have picked tw5864 as reachable for retail orders.

Right now it would be easy to keep the two in sync, there has been
not many changes since I left, and if changes are integrated into
mainline first, there will be no further issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Jonathan Corbet]

On Wed, 04 May 2016 16:41:50 +0300
Jani Nikula  wrote:

> On Wed, 04 May 2016, Markus Heiser  wrote:
> > In reST the directive might look like:
> >
> >  -
> > Device Instance and Driver Handling
> > ===
> >
> > .. kernel-doc::  drivers/gpu/drm/drm_drv.c
> >:doc:  driver instance overview
> >:exported:
> >
> >  -  
> 
> Yes, I think something like this, parsed by sphinx directly (via some
> extension perhaps), should be the end goal. I am not sure if it should
> be the immediate first goal though or whether we should reuse the
> existing docproc for now.

I think all of this makes sense.  It would be really nice to have the
directives in the native sphinx language like that.  I *don't* think we
need to aim for that at the outset; the docproc approach works until we can
properly get rid of it.  What would be *really* nice would be to get
support for the kernel-doc directive into the sphinx upstream.

> >  --
> >
> > Comments with the ":reST:" tag could be exported and pass-through
> > to sphinx.  
> 
> Disagreed on most of the above.

Agreed with the disagreement here.  We can't be adding ":reST:" tags to
comments; I anticipate a wee bit of pushback if we try.  It needs to work
with the comments as they are now.  It seems that should be possible.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter  wrote:
> 
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff with impunity in gpu documentations.  
> > 
> > Aside: If we decide this now I could send in a pull request for the
> > rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
> > markdown/asciidoc code I still have). That would be really awesome ...
> 
> Sorry for my relative absence...I'm still busy dealing with bureaucracy
> an ocean away from home.  I hope to begin emerging from this mess in the
> near future.
> 
> So ... there's the code you have, the work I (+Jani) did, and the work
> Markus has done.  Which would you have me push into 4.7?
> 
> The sphinx/rst approach does seem, to me, to be the right one, with the
> existing DocBook structure remaining in place for those who want/need
> it.  I'm inclined toward my stuff as a base to work with, obviously :) But
> it's hackish at best and needs a lot of cleaning up.  It's a proof of
> concept, but it's hardly finished (one might say it's barely begun...)
> 
> In the end, I guess, I feel that anything we might try to push for 4.7 is
> going to look rushed and not ready, and Linus might react accordingly.
> I'd be more comfortable aiming for 4.8.  I *will* have more time to focus
> on things in that time frame...  I suspect you're pretty well fed up with
> this stuff being pushed back, and rightly so.  All I can do is apologize.
> 
> That said, if you do think there's something out there that is good
> enough to consider pushing in a week or two, do tell and we can all take
> a look.

Well I'd just have taken the asciidoc hacks I have currently in my
topic/kerneldoc branch, converted to sphinx and looked how it fares. It
should be fairly minimal, and I think the first step we want to do for the
long-term plan. I hope I can ready something, and then we can look whether
it's rushed for 4.7 or not.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Jonathan Corbet]

On Wed, 4 May 2016 16:18:27 +0200
Daniel Vetter  wrote:

> > I'd really like to converge on the markup question, so that we can start
> > using all the cool stuff with impunity in gpu documentations.  
> 
> Aside: If we decide this now I could send in a pull request for the
> rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
> markdown/asciidoc code I still have). That would be really awesome ...

Sorry for my relative absence...I'm still busy dealing with bureaucracy
an ocean away from home.  I hope to begin emerging from this mess in the
near future.

So ... there's the code you have, the work I (+Jani) did, and the work
Markus has done.  Which would you have me push into 4.7?

The sphinx/rst approach does seem, to me, to be the right one, with the
existing DocBook structure remaining in place for those who want/need
it.  I'm inclined toward my stuff as a base to work with, obviously :) But
it's hackish at best and needs a lot of cleaning up.  It's a proof of
concept, but it's hardly finished (one might say it's barely begun...)

In the end, I guess, I feel that anything we might try to push for 4.7 is
going to look rushed and not ready, and Linus might react accordingly.
I'd be more comfortable aiming for 4.8.  I *will* have more time to focus
on things in that time frame...  I suspect you're pretty well fed up with
this stuff being pushed back, and rightly so.  All I can do is apologize.

That said, if you do think there's something out there that is good
enough to consider pushing in a week or two, do tell and we can all take
a look.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Ismael Luceno]

On 04/May/2016 16:34, Andrey Utkin wrote:
> On Sat, Apr 30, 2016 at 12:17:08AM -0300, Ismael Luceno wrote:
> > Such frame size is met in practice. Also report oversized frames.
> > 
> > Based on patches by Andrey Utkin .
> 
> If it is based on my patches([1] [2]), then why you claim authorship and
> why you don't let me know (at last CCing me)?

Wasn't my intention, I gave you credit, I just merged the changes
and reworked the warning and commit message.

The whole point to have solo6x10 mainlined was to get rid of the
out-of-tree driver and convert the DKMS package to use media_build,
thus mainline should be kept in sync, so why are you not submitting
the patches yourself? I should have nothing to do with that.

> Do you know that 200 KiB is not the limit, just as previous value? I
> haven't researched subj deep enough to figure out proven good value for
> new buffer size.

I know, I know it depends on the quantization matrix, and it should
be possible to infer the limit, but like you I didn't do the research,
the difference is that I don't get paid to do it anymore.

> It's both laughable and infuriating for me to spectate your behaviour of
> "stealth driver developer".
> You have added yourself back to driver maintainers in MAINTAINERS file
> after your quit without letting us know.

Why the attack?

I didn't quit, I was dismissed, and the remaining ~5k USD I'm owed
was never paid. Curtis: any comment on that?

Also, I don't see what's the problem in re-adding myself, and I
don't understand why I was removed in the first place, it's not up
to Bluecherry, is it?

> You are not affiliated with Bluecherry for two years, and you are not
> informed about how the driver is working in production on customers
> setups. So you are not aware what are real issues with it. BTW do you
> still have a sample of actual hardware? Yeah, I agree that this can be
> argument against Bluecherry and lack of openness in its bug tracking.

You attend Bluecherry customers' needs because you're part of
Bluecherry; like you said I'm not, and I certainly don't get paid to
care about the out-of-tree driver issues or it's bug tracker.

And yes, I still have the hardware.

> But you are also not open and not collaborating.

What do you think I should do? Seriously, I don't get it.

> The point of my accusation to you is that you seem to be just gaining
> "kernel developer" score for nobody's (except your CV's) benefit.
> Development and maintenance is what Hans Verkuil, Krzysztof Halasa and
> others do to this driver, but not this.
> 
> Sorry to be harsh.

I think you're the only one keeping such a score, and I never claimed
my work being more or superior to anyone's else.

You're out of your mind, man.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

[Shuah Khan]

On 05/04/2016 05:20 AM, Sakari Ailus wrote:
> New IOCTLs (especially for the request API) do not necessarily need the
> graph mutex acquired. Leave this up to the drivers.

Sakari,

Does this mean drivers have to hold the graph mutex as needed?
My concern with this is that we will have graph_mutex holds in
driver code in addition to the ones we have now. My concern with
referencing graph_mutex from driver code is lack of abstraction.
If we ever need to change grahp-mutex in the media-core, if it
is exposed to drivers, then there will be lot of changes.

Could we look into avoiding drivers referencing graph_mutex
directly?

thanks,
-- Shuah

> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/media-device.c | 47 
> ++--
>  1 file changed, 28 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 39fe07f..8aef5b8 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -390,21 +390,26 @@ static long copy_arg_to_user_nop(void __user *uarg, 
> void *karg,
>  }
>  #endif
>  
> -#define MEDIA_IOC_ARG(__cmd, func, from_user, to_user)   \
> - [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
> - .cmd = MEDIA_IOC_##__cmd,   \
> +/* Do acquire the graph mutex */
> +#define MEDIA_IOC_FL_GRAPH_MUTEX BIT(0)
> +
> +#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user)   \
> + [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
> + .cmd = MEDIA_IOC_##__cmd,   \
>   .fn = (long (*)(struct media_device *, void *))func,\
> - .arg_from_user = from_user, \
> - .arg_to_user = to_user, \
> + .flags = fl,\
> + .arg_from_user = from_user, \
> + .arg_to_user = to_user, \
>   }
>  
> -#define MEDIA_IOC(__cmd, func)   
> \
> - MEDIA_IOC_ARG(__cmd, func, copy_arg_from_user, copy_arg_to_user)
> +#define MEDIA_IOC(__cmd, func, fl)   \
> + MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
>  
>  /* the table is indexed by _IOC_NR(cmd) */
>  struct media_ioctl_info {
>   unsigned int cmd;
>   long (*fn)(struct media_device *dev, void *arg);
> + unsigned short flags;
>   long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd);
>   long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
>  };
> @@ -449,9 +454,13 @@ static long __media_device_ioctl(
>  
>   info->arg_from_user(karg, arg, cmd);
>  
> - mutex_lock(>graph_mutex);
> + if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
> + mutex_lock(>graph_mutex);
> +
>   ret = info->fn(dev, karg);
> - mutex_unlock(>graph_mutex);
> +
> + if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
> + mutex_unlock(>graph_mutex);
>  
>   if (ret)
>   return ret;
> @@ -460,11 +469,11 @@ static long __media_device_ioctl(
>  }
>  
>  static const struct media_ioctl_info ioctl_info[] = {
> - MEDIA_IOC(DEVICE_INFO, media_device_get_info),
> - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
> - MEDIA_IOC(ENUM_LINKS, media_device_enum_links),
> - MEDIA_IOC(SETUP_LINK, media_device_setup_link),
> - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
> + MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>  };
>  
>  static long media_device_ioctl(struct file *filp, unsigned int cmd,
> @@ -510,11 +519,11 @@ static long from_user_enum_links32(void *karg, void 
> __user *uarg,
>  #define MEDIA_IOC_ENUM_LINKS32   _IOWR('|', 0x02, struct 
> media_links_enum32)
>  
>  static const struct media_ioctl_info compat_ioctl_info[] = {
> - MEDIA_IOC(DEVICE_INFO, media_device_get_info),
> - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
> - MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, 
> from_user_enum_links32, copy_arg_to_user_nop),
> - MEDIA_IOC(SETUP_LINK, media_device_setup_link),
> - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
> + MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX, 

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Andrey Utkin]

On Wed, May 4, 2016 at 5:04 PM, Hans Verkuil  wrote:
> BTW, looking at the MAINTAINERS file I see two email addresses for Andrey,
> neither of which is the fastmail.com address this email came from.

Now I'm replying from corporate email.

> Andrey, it might be a good idea to post such fixes to the mailinglist sooner,
> both to prevent situations like this and to keep the diffs between mainline
> and your internal code as small as possible.

In a word - we would do what is possible to achieve that, but there's
little time
and little incentive for that.
The codebases have already diverged a lot, having unique sets of runtime bugs.
And this exact issue alone is not resolved yet in a good way and is
not actually critical.
Merging would require a lot of working time. And it is complicated by
the fact that
there's not going to be any new manufacturing orders (the minimal order quantity
is too high for Bluecherry), and that we have picked tw5864 as
reachable for retail orders.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 4, 2016 at 3:43 PM, Daniel Vetter  wrote:
> I'd really like to converge on the markup question, so that we can start
> using all the cool stuff with impunity in gpu documentations.

Aside: If we decide this now I could send in a pull request for the
rst/sphinx kernel-doc support still for 4.7 (based upon the minimal
markdown/asciidoc code I still have). That would be really awesome ...

Jon?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Peter Rosin]

On 2016-05-03 23:39, Wolfram Sang wrote:
>> Yes, they look like reasonable complaints.
> 
> Thanks for fixing them. I just sent out my latest comments and when you
> fix those and send V8, I'll apply that right away. I think we are safe
> to fix the rest incrementally if needed. Note that I didn't review the

Sounds like a plan.

> IIO and media patches, I trust the reviewers on those.
> 
> Thanks for your work on this! I need a break now, this is
> mind-boggling...

And thanks for reviewing it!

A question on best practices here... I already did a v8 (but only as
a branch) so I think this will be v9, bit that's a minor detail. The
real question is what I should do about patches 1-15 that are already
in next? Send them too? If not, should I send 16-24 with the same old
patch numbers or should they be numbered 1-9 now? And should such a
shortened series be rebased on 1-15 in next?

Or does it not really matter?

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Hans Verkuil]

OK, I've dropped Ismael's patch from my pull request to Mauro until this
is resolved.

Who actually maintains this driver? I would say Andrey since he works for
bluecherry. If Ismael is no longer affiliated (either officially or 
unofficially)
with bluecherry, then his name should be removed.

BTW, looking at the MAINTAINERS file I see two email addresses for Andrey,
neither of which is the fastmail.com address this email came from.

Ismael, please keep the correct author if it isn't you. And a CC to Andrey
certainly doesn't hurt.

Andrey, it might be a good idea to post such fixes to the mailinglist sooner,
both to prevent situations like this and to keep the diffs between mainline
and your internal code as small as possible.

I don't really care who posts fixes as long as authorship info etc. remains
intact and the code is obviously an improvement.

Regards,

Hans

On 05/04/2016 03:34 PM, Andrey Utkin wrote:
> On Sat, Apr 30, 2016 at 12:17:08AM -0300, Ismael Luceno wrote:
>> Such frame size is met in practice. Also report oversized frames.
>>
>> Based on patches by Andrey Utkin .
> 
> If it is based on my patches([1] [2]), then why you claim authorship and
> why you don't let me know (at last CCing me)?
> 
> Do you know that 200 KiB is not the limit, just as previous value? I
> haven't researched subj deep enough to figure out proven good value for
> new buffer size.
> 
> It's both laughable and infuriating for me to spectate your behaviour of
> "stealth driver developer".
> You have added yourself back to driver maintainers in MAINTAINERS file
> after your quit without letting us know.
> You are not affiliated with Bluecherry for two years, and you are not
> informed about how the driver is working in production on customers
> setups. So you are not aware what are real issues with it. BTW do you
> still have a sample of actual hardware? Yeah, I agree that this can be
> argument against Bluecherry and lack of openness in its bug tracking.
> But you are also not open and not collaborating.
> 
> The point of my accusation to you is that you seem to be just gaining
> "kernel developer" score for nobody's (except your CV's) benefit.
> Development and maintenance is what Hans Verkuil, Krzysztof Halasa and
> others do to this driver, but not this.
> 
> Sorry to be harsh.
> 
> [1] 
> https://github.com/bluecherrydvr/solo6x10/commit/5cd985087362e2e524b3e44504eea791ae7cda7e
> [2] 
> https://github.com/bluecherrydvr/solo6x10/commit/3b437f79c40438eb09bb2d5dbcfe67dbc94648ed
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.7] Various fixes

[Hans Verkuil]

(Superseeds https://patchwork.linuxtv.org/patch/34178/, dropping Ismael's patch
due to confused patch provenance)

The following changes since commit 68af062b5f38510dc96635314461c6bbe1dbf2fe:

  Merge tag 'v4.6-rc6' into patchwork (2016-05-02 07:48:23 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.7d

for you to fetch changes up to 3b97cd1d95c24647842359ac9515295ce5c97038:

  media: vb2-dma-contig: configure DMA max segment size properly (2016-05-04 
15:48:45 +0200)


Hans Verkuil (1):
  v4l2-ioctl.c: improve cropcap compatibility code

Marek Szyprowski (1):
  media: vb2-dma-contig: configure DMA max segment size properly

 drivers/media/v4l2-core/v4l2-ioctl.c   | 70 
+++---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 53 
+++--
 2 files changed, 94 insertions(+), 29 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Add GS driver (SPI video serializer family)

[Hans Verkuil]

Hi Charles-Antoine,

On 05/04/2016 03:27 PM, Charles-Antoine Couret wrote:
> Le 04/05/2016 à 13:41, Hans Verkuil a écrit :
>> Hi Charles-Antoine,
> 
> Hi,
> 
>> On 04/28/2016 04:10 PM, Charles-Antoine Couret wrote:
>>> But this component family support CEA standards and other
>>> (SMPTE XXXM in fact). V4L2 seems oriented to manage CEA or
>>> VGA formats. So, I used timings structure with CEA values, but I
>>> fill timings fields manually for other standards. I don't know if it
>>> is the right method or if another interface should be more interesting.
>>
>> As long as the timings are part of a standard, then just add them to
>> the v4l2-dv-timings.h header. Since these timings aren't part of the CEA-861
>> standard or the DMT VESA standard, just add a new SMPTE standard flag.
> 
> Ok, but I should have difficulties to define correctly these standards.
> I worked on video stream in SMPTE-125M and I don't know if other SMPTE 
> standards are based on the same characteristics.
> In addition to this, those standards are not public.

I have access to the SMPTE standards, I'll take a look next week.

Regarding timings: I think this requires a separate discussion. I need to loop 
in 'nohous'
who is also working on SDI support, but unfortunately I don't have his email 
handy, otherwise
I'd have CC-ed him.

I'm no SDI expert myself, but I think I should set time aside to read up on this
and figure out together with you guys how this should be handled.

So I don't have a quick answer here, this requires more R

> 
> For the SMPTE-125M, I have these information:
> * Pixelclock : 27 MHz (I set 13.5MHz to have 60 FPS because its a interlaced 
> signal, I don't know if it's correct)
> * The organization of lines :
> Line 1 to 9 : blanking
> Line 10 to 19 : options (blanking in my case for example)
> Line 20 to 264 : field 1
> Line 266 to 272 : blanking
> Line 273 to 282 : options
> Line 283 to 525 : field 2
> 
> The time of blanking are not regular: 19 then 18 lines, how translate that in 
> dv_timings?
> The size of fields is different too.
> 
> The Field signal is changed in 266 line.
> * Complete format size (with blanking) ; 858x525
> * Image size : 720x487
> 
> Organization of horizontal sync :
> Pixel 0 to 719 : active pixels
> Pixel 720 to 857 : blanking (but the firsts 16 pixels are the front porch, 
> but after, no info for sync or back porch timings)
> 
> Polarity: V-, H+
> 
> And, I don't have info for other standards and the GS1662 don't need that too.
> I should create SMPTE format but only for the 125M? And the driver shouldn't 
> use / consider other SMPTE formats without a right definition?
> 
>>> This patch was tested with GS1662:
>>> http://www.c-dis.net/media/871/GS1662_Datasheet.pdf
>>
>> A pointer to this datasheet should be in a comment in the source code.
> 
> Ok. The commit message should keep the link too?

It doesn't hurt.

> 
> 
>>>  drivers/media/spi/gs.c | 482 
>>> +
>>
>> I would just call it gs1662. That's all you've tested with, after all.
>>
>> It is very common that drivers named after the first supported model also
>> support similar models.
> 
> Ok, thanks.
> 
>>> +struct gs {
>>
>> The gs prefix is rather ugly. I'd just use gs_ instead.
> 
> Yes, I agree with you.
> 
>>> +static void custom_to_timings(const struct gs_reg_fmt_custom *custom,
>>> + struct v4l2_dv_timings *timings)
>>> +{
>>> +   timings->type = V4L2_DV_BT_656_1120;
>>> +   timings->bt.width = custom->width;
>>> +   timings->bt.height = custom->height;
>>> +   timings->bt.pixelclock = custom->pixelclock;
>>> +   timings->bt.interlaced = custom->interlaced;
>>> +   timings->bt.polarities = 0;
>>> +   timings->bt.hbackporch = 0;
>>> +   timings->bt.hsync = 0;
>>> +   timings->bt.hfrontporch = 0;
>>> +   timings->bt.vbackporch = 0;
>>> +   timings->bt.vsync = 0;
>>> +   timings->bt.vfrontporch = 0;
>>> +   timings->bt.il_vbackporch = 0;
>>> +   timings->bt.il_vsync = 0;
>>> +   timings->bt.il_vfrontporch = 0;
>>
>> You still need to set the total blanking sizes, right?
>>
>> For now assign that to the [hv]frontporch, leaving the sync and
>> backporch fields 0. I need to make some rules how this is handled when
>> the standard doesn't separate the blanking into back/frontporch and syncs.
> 
> Seeing my first comment.
> I could precise some info (for 125M) but not for all of them.
> And the GS1662 don't care about those information: we can't configure 
> timings, only ask a specific format.
> 
> And, how manage the case of there are two different timings for vertical 
> blanking for one image in the standard?
> 
>>> +   timings->bt.standards = 0;
>>
>> So we need to define a proper standard for this.
> 
> Yes.
>  
>> So, regarding the reset, s_dv_timings and query_dv_timings: it's not clear
>> what is happening here. The usual way things work is that the timings that
>> s/g_dv_timings set and get are indepedent of the timings that are 

Re: Kernel docs: muddying the waters a bit

[Daniel Vetter]

On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote:
> > On Wed, 04 May 2016, Markus Heiser  wrote:
> > I'd be *very* hesitant about adding the kind of things you do in
> > reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc
> > comments must be as simple as possible with basically pass-through of
> > the comment blocks to sphinx.
> 
> Right, but you forgot, that the current markup in the source code comments
> is based on the  kernel-doc-nano-HOWTO and I guess no one will migrate all
> these source code comments to reST markup ;-)
> 
> So there is a need to differentiate between *vintage* kernel-doc markup 
> and reST markup.
> 
> My suggestion is to add a tag to the comments, here a short example
> what this might look like.
> 
>  --
> /**
>  * drm_minor_release - Release DRM minor
>  * @minor: Pointer to DRM minor object
>  *
>  * Release a minor that was previously acquired via drm_minor_acquire().
>  */
>  --
> 
> in short: the vintage style does not need any change and 
> comments with reST markup has a tag ":reST:" in the first 
> line(s) ...
> 
>  --
> /**
>  * :reST:
>  *
>  * .. c:function:: void drm_minor_release(struct drm_minor *minor)
>  *
>  *Release DRM minor
>  *
>  *:param struct drm_minor \*minor: Pointer to DRM minor object
>  *
>  */
>  --
> 
> Comments with the ":reST:" tag could be exported and pass-through
> to sphinx.
> 
> > Specifically, do not attempt to detect and
> > parse elements like lists in kernel-doc.
> 
> If your markup in the comments is plain reST, no need to parse, but there
> are markups in the (vintage) comments which made use of individual 
> text-markups, e.g. the markup of lists or ASCII-art. 
> 
> This individual text-markups has not been converted/rendered in the docbook
> output, but I wanted to convert this individuals to reST, to render them in
> Sphinx.

I think we need to unconfuse what's current standardize kerneldoc markup.
There's three bits:
- The header with the one-liner and parameters, i.e.

/**
 * drm_minor_release - Release DRM minor
 * @minor: Pointer to DRM minor object

  There's thousands of those, and we cant realistically change them. This
  means we need to teach kernel-doc to parse those and convert them to
  rest/shpinx layout. Any approach that expects a conversion of all the
  existing comments over to sphinx/rst is imo unworkable.

- References for function(), , #constants and @parameters.
  Again for the same reasons of being here already, we can't change those
  at all. On top of that these markers are also used to generate
  hyperlinks in the final docs. The kernel-doc script therefor not only
  needs to generate the right markup, but also correct links. Without
  generating links to functions/structures outside of a given document.

- kernel-doc also does paragraph splitting and minimalistic headers like

 * Returns:
 * 
 * This will be under a separate Returns: heading in the text.

  afaict at least the paragraph splitting would be identical between all
  proposed markup languages.

Now what all current proposals have done is simply allow pass-through of
asciidoc or rst markup in those paragraphs, so that the final processor
could make stuff pretty.

This is already used widely in kerneldoc included by gpu.tmpl, and
currently it's asciidoc. Those lists and asciiarts though are _not_
standard kerneldoc at all. But imo any doc toolchain improvement should
integrate along those lines.
 
For reference, this is what it's supposed to look like with the asciidoc
support enabled:

https://dri.freedesktop.org/docs/drm/API-struct-drm-display-mode.html

Fyi those hacked-up patches to make this happen are available in

https://cgit.freedesktop.org/drm-intel/log/?h=topic/kerneldoc

Note that this isn't upstream, but we did start using this support all
over in gpu documentation simply because we really, really need it. And
I'm willing to throw all the comments into a converter to end up with
whatever markup we decide upon.

But what will not work is to throw the existing kernel-doc standard into
the shredder. So all the stuff with @, (), & and # must keep working.

> E.g. compare the member & description section of struct drm-display-mode ...
> 
> DocBook: 
> 
>   * https://www.kernel.org/doc/htmldocs/gpu/API-struct-drm-display-mode.html
> 
> kernel-doc reST with the additional reformat_block_rst function:
> 
>   * 
> http://return42.github.io/sphkerneldoc/linux_src_doc/include/drm/drm_modes_h.html#struct-drm-display-mode

So we have this already. The two things I thought this entire discussion
was about:

- also throw out the docbook .xml and replace it with something else. That
  was jani's prototype on top of asciidoc, and it sounds like we could do
  something similar with rst/sphinx. Everyone pretty much agrees that
  this would be a second step, and the first step would be to simply
  integrate more advanced markup into the 

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Wed, 04 May 2016, Markus Heiser  wrote:
>> What do you mean by ".tmpl workflow"?
>
> Sorry for bad naming, I addressed the DOCPROC build process which builds
> the .xml files from .tmpl files ...

Yeah, I know more about this part than I care. I was just wondering what
you refer to with that in the sphinx context.

> In reST the directive might look like:
>
>  -
> Device Instance and Driver Handling
> ===
>
> .. kernel-doc::  drivers/gpu/drm/drm_drv.c
>:doc:  driver instance overview
>:exported:
>
>  -

Yes, I think something like this, parsed by sphinx directly (via some
extension perhaps), should be the end goal. I am not sure if it should
be the immediate first goal though or whether we should reuse the
existing docproc for now.

> Right, but you forgot, that the current markup in the source code comments
> is based on the  kernel-doc-nano-HOWTO and I guess no one will migrate all
> these source code comments to reST markup ;-)
>
> So there is a need to differentiate between *vintage* kernel-doc markup 
> and reST markup.
>
> My suggestion is to add a tag to the comments, here a short example
> what this might look like.
>
>  --
> /**
>  * drm_minor_release - Release DRM minor
>  * @minor: Pointer to DRM minor object
>  *
>  * Release a minor that was previously acquired via drm_minor_acquire().
>  */
>  --
>
> in short: the vintage style does not need any change and 
> comments with reST markup has a tag ":reST:" in the first 
> line(s) ...
>
>  --
> /**
>  * :reST:
>  *
>  * .. c:function:: void drm_minor_release(struct drm_minor *minor)
>  *
>  *Release DRM minor
>  *
>  *:param struct drm_minor \*minor: Pointer to DRM minor object
>  *
>  */
>  --
>
> Comments with the ":reST:" tag could be exported and pass-through
> to sphinx.

Disagreed on most of the above.

Maybe I was unclear in my previous mail, and I've probably worked on
this so much previously that I thought it was clear how we should handle
lightweight markup in kernel-doc comments.

Kernel-doc the tool should continue to parse kernel-doc comments at the
high level like they currently are, according to the kernel-doc
howto. The first heading line, the parameter/member lines with @param:,
and references within the text with @param, function(), 
structures, etc. For those, kernel-doc should produce appropriate rst
elements.

Beyond that, kernel-doc should *not* try to make guesses about the
formatting of the documentation comments. It should just pass the rest
of the formatting through. If the ad-hoc lists etc. in the current
comments don't turn into proper rst lists, then so be it. If it bugs
people, the comments will gradually be converted to proper rst. The
worst we could do is promote a sloppy style that kernel-doc fixes for
you, possibly "fixing" things you'd want to pass through to sphinx.

What you have in  example above will not fly. The
documentation comment style must remain as is defined in the kernel-doc
how, i.e.  example. It is imperative that the
kernel-doc comments remain as readable as they currently are in the
source code.

>> Specifically, do not attempt to detect and
>> parse elements like lists in kernel-doc.
>
> If your markup in the comments is plain reST, no need to parse, but there
> are markups in the (vintage) comments which made use of individual 
> text-markups, e.g. the markup of lists or ASCII-art. 
>
> This individual text-markups has not been converted/rendered in the docbook
> output, but I wanted to convert this individuals to reST, to render them in
> Sphinx.
>
> E.g. compare the member & description section of struct drm-display-mode ...
>
> DocBook: 
>
>   * https://www.kernel.org/doc/htmldocs/gpu/API-struct-drm-display-mode.html
>
> kernel-doc reST with the additional reformat_block_rst function:
>
>   * 
> http://return42.github.io/sphkerneldoc/linux_src_doc/include/drm/drm_modes_h.html#struct-drm-display-mode

Overall I think we should promote fixing those in the kernel-doc
comments. Trying to guesswork in kernel-doc tool will leave the source
littered with bad examples that get proliferated all around. Instead of
gradually fixing things, we'll end up gradually messing things up even
more.

For those specific examples, IIRC the last time I played with that,
simply leaving the prefix whitespace in place went a long way (just eat
" * " from the lines). The asciiart just worked.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

[Andrey Utkin]

On Sat, Apr 30, 2016 at 12:17:08AM -0300, Ismael Luceno wrote:
> Such frame size is met in practice. Also report oversized frames.
> 
> Based on patches by Andrey Utkin .

If it is based on my patches([1] [2]), then why you claim authorship and
why you don't let me know (at last CCing me)?

Do you know that 200 KiB is not the limit, just as previous value? I
haven't researched subj deep enough to figure out proven good value for
new buffer size.

It's both laughable and infuriating for me to spectate your behaviour of
"stealth driver developer".
You have added yourself back to driver maintainers in MAINTAINERS file
after your quit without letting us know.
You are not affiliated with Bluecherry for two years, and you are not
informed about how the driver is working in production on customers
setups. So you are not aware what are real issues with it. BTW do you
still have a sample of actual hardware? Yeah, I agree that this can be
argument against Bluecherry and lack of openness in its bug tracking.
But you are also not open and not collaborating.

The point of my accusation to you is that you seem to be just gaining
"kernel developer" score for nobody's (except your CV's) benefit.
Development and maintenance is what Hans Verkuil, Krzysztof Halasa and
others do to this driver, but not this.

Sorry to be harsh.

[1] 
https://github.com/bluecherrydvr/solo6x10/commit/5cd985087362e2e524b3e44504eea791ae7cda7e
[2] 
https://github.com/bluecherrydvr/solo6x10/commit/3b437f79c40438eb09bb2d5dbcfe67dbc94648ed
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

[Sakari Ailus]

Refactor copying the IOCTL argument structs from the user space and back,
in order to reduce code copied around and make the implementation more
robust.

As a result, the copying is done while not holding the graph mutex.

Signed-off-by: Sakari Ailus 
---
since v2:

- Remove function to calculate maximum argument size, replace by a char
  array of 256 or kmalloc() if that's too small.

 drivers/media/media-device.c | 194 +--
 1 file changed, 94 insertions(+), 100 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 9b5a88d..0797e4b 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -59,27 +59,24 @@ static int media_device_close(struct file *filp)
 }
 
 static int media_device_get_info(struct media_device *dev,
-struct media_device_info __user *__info)
+struct media_device_info *info)
 {
-   struct media_device_info info;
-
-   memset(, 0, sizeof(info));
+   memset(info, 0, sizeof(*info));
 
if (dev->driver_name[0])
-   strlcpy(info.driver, dev->driver_name, sizeof(info.driver));
+   strlcpy(info->driver, dev->driver_name, sizeof(info->driver));
else
-   strlcpy(info.driver, dev->dev->driver->name, 
sizeof(info.driver));
+   strlcpy(info->driver, dev->dev->driver->name,
+   sizeof(info->driver));
 
-   strlcpy(info.model, dev->model, sizeof(info.model));
-   strlcpy(info.serial, dev->serial, sizeof(info.serial));
-   strlcpy(info.bus_info, dev->bus_info, sizeof(info.bus_info));
+   strlcpy(info->model, dev->model, sizeof(info->model));
+   strlcpy(info->serial, dev->serial, sizeof(info->serial));
+   strlcpy(info->bus_info, dev->bus_info, sizeof(info->bus_info));
 
-   info.media_version = MEDIA_API_VERSION;
-   info.hw_revision = dev->hw_revision;
-   info.driver_version = dev->driver_version;
+   info->media_version = MEDIA_API_VERSION;
+   info->hw_revision = dev->hw_revision;
+   info->driver_version = dev->driver_version;
 
-   if (copy_to_user(__info, , sizeof(*__info)))
-   return -EFAULT;
return 0;
 }
 
@@ -101,29 +98,25 @@ static struct media_entity *find_entity(struct 
media_device *mdev, u32 id)
 }
 
 static long media_device_enum_entities(struct media_device *mdev,
-  struct media_entity_desc __user *uent)
+  struct media_entity_desc *entd)
 {
struct media_entity *ent;
-   struct media_entity_desc u_ent;
-
-   memset(_ent, 0, sizeof(u_ent));
-   if (copy_from_user(_ent.id, >id, sizeof(u_ent.id)))
-   return -EFAULT;
-
-   ent = find_entity(mdev, u_ent.id);
 
+   ent = find_entity(mdev, entd->id);
if (ent == NULL)
return -EINVAL;
 
-   u_ent.id = media_entity_id(ent);
+   memset(entd, 0, sizeof(*entd));
+
+   entd->id = media_entity_id(ent);
if (ent->name)
-   strlcpy(u_ent.name, ent->name, sizeof(u_ent.name));
-   u_ent.type = ent->function;
-   u_ent.revision = 0; /* Unused */
-   u_ent.flags = ent->flags;
-   u_ent.group_id = 0; /* Unused */
-   u_ent.pads = ent->num_pads;
-   u_ent.links = ent->num_links - ent->num_backlinks;
+   strlcpy(entd->name, ent->name, sizeof(entd->name));
+   entd->type = ent->function;
+   entd->revision = 0; /* Unused */
+   entd->flags = ent->flags;
+   entd->group_id = 0; /* Unused */
+   entd->pads = ent->num_pads;
+   entd->links = ent->num_links - ent->num_backlinks;
 
/*
 * Workaround for a bug at media-ctl <= v1.10 that makes it to
@@ -139,14 +132,13 @@ static long media_device_enum_entities(struct 
media_device *mdev,
if (ent->function < MEDIA_ENT_F_OLD_BASE ||
ent->function > MEDIA_ENT_T_DEVNODE_UNKNOWN) {
if (is_media_entity_v4l2_subdev(ent))
-   u_ent.type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
+   entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
else if (ent->function != MEDIA_ENT_F_IO_V4L)
-   u_ent.type = MEDIA_ENT_T_DEVNODE_UNKNOWN;
+   entd->type = MEDIA_ENT_T_DEVNODE_UNKNOWN;
}
 
-   memcpy(_ent.raw, >info, sizeof(ent->info));
-   if (copy_to_user(uent, _ent, sizeof(u_ent)))
-   return -EFAULT;
+   memcpy(>raw, >info, sizeof(ent->info));
+
return 0;
 }
 
@@ -158,8 +150,8 @@ static void media_device_kpad_to_upad(const struct 
media_pad *kpad,
upad->flags = kpad->flags;
 }
 
-static long __media_device_enum_links(struct media_device *mdev,
- struct media_links_enum *links)
+static long 

[PATCH 1/3] media: Move media_device link_notify operation to an ops structure

[Sakari Ailus]

From: Laurent Pinchart 

This will allow adding new operations without increasing the
media_device structure size for drivers that don't implement any media
device operation.

Signed-off-by: Laurent Pinchart 

Fix compilation error for the omap3isp driver.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c  | 11 ++-
 drivers/media/platform/exynos4-is/media-dev.c |  6 +-
 drivers/media/platform/omap3isp/isp.c |  6 +-
 drivers/staging/media/omap4iss/iss.c  |  6 +-
 include/media/media-device.h  | 16 
 5 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index c53c1d5..301fd4f 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -806,17 +806,18 @@ int __media_entity_setup_link(struct media_link *link, 
u32 flags)
 
mdev = source->graph_obj.mdev;
 
-   if (mdev->link_notify) {
-   ret = mdev->link_notify(link, flags,
-   MEDIA_DEV_NOTIFY_PRE_LINK_CH);
+   if (mdev->ops && mdev->ops->link_notify) {
+   ret = mdev->ops->link_notify(link, flags,
+MEDIA_DEV_NOTIFY_PRE_LINK_CH);
if (ret < 0)
return ret;
}
 
ret = __media_entity_setup_link_notify(link, flags);
 
-   if (mdev->link_notify)
-   mdev->link_notify(link, flags, MEDIA_DEV_NOTIFY_POST_LINK_CH);
+   if (mdev->ops && mdev->ops->link_notify)
+   mdev->ops->link_notify(link, flags,
+  MEDIA_DEV_NOTIFY_POST_LINK_CH);
 
return ret;
 }
diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index 04348b5..1ed1a9e 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1190,6 +1190,10 @@ static int fimc_md_link_notify(struct media_link *link, 
unsigned int flags,
return ret ? -EPIPE : 0;
 }
 
+static const struct media_device_ops fimc_md_ops = {
+   .link_notify = fimc_md_link_notify,
+};
+
 static ssize_t fimc_md_sysfs_show(struct device *dev,
  struct device_attribute *attr, char *buf)
 {
@@ -1416,7 +1420,7 @@ static int fimc_md_probe(struct platform_device *pdev)
 
strlcpy(fmd->media_dev.model, "SAMSUNG S5P FIMC",
sizeof(fmd->media_dev.model));
-   fmd->media_dev.link_notify = fimc_md_link_notify;
+   fmd->media_dev.ops = _md_ops;
fmd->media_dev.dev = dev;
 
v4l2_dev = >v4l2_dev;
diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 5d54e2c..0321d84 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -657,6 +657,10 @@ static irqreturn_t isp_isr(int irq, void *_isp)
return IRQ_HANDLED;
 }
 
+static const struct media_device_ops isp_media_ops = {
+   .link_notify = v4l2_pipeline_link_notify,
+};
+
 /* 
-
  * Pipeline stream management
  */
@@ -1680,7 +1684,7 @@ static int isp_register_entities(struct isp_device *isp)
strlcpy(isp->media_dev.model, "TI OMAP3 ISP",
sizeof(isp->media_dev.model));
isp->media_dev.hw_revision = isp->revision;
-   isp->media_dev.link_notify = v4l2_pipeline_link_notify;
+   isp->media_dev.ops = _media_ops;
media_device_init(>media_dev);
 
isp->v4l2_dev.mdev = >media_dev;
diff --git a/drivers/staging/media/omap4iss/iss.c 
b/drivers/staging/media/omap4iss/iss.c
index c5a5138..355a704 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -362,6 +362,10 @@ static irqreturn_t iss_isr(int irq, void *_iss)
return IRQ_HANDLED;
 }
 
+static const struct media_device_ops iss_media_ops = {
+   .link_notify = v4l2_pipeline_link_notify,
+};
+
 /* 
-
  * Pipeline stream management
  */
@@ -988,7 +992,7 @@ static int iss_register_entities(struct iss_device *iss)
strlcpy(iss->media_dev.model, "TI OMAP4 ISS",
sizeof(iss->media_dev.model));
iss->media_dev.hw_revision = iss->revision;
-   iss->media_dev.link_notify = v4l2_pipeline_link_notify;
+   iss->media_dev.ops = _media_ops;
ret = media_device_register(>media_dev);
if (ret < 0) {
dev_err(iss->dev, "Media device registration failed (%d)\n",
diff --git a/include/media/media-device.h b/include/media/media-device.h
index a9b33c4..19c8ed4 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -280,6 

Re: [PATCH 3/3] v4l: subdev: Call pad init_cfg operation when opening subdevs

[Hans Verkuil]

On 05/04/2016 01:25 PM, Sakari Ailus wrote:
> From: Laurent Pinchart 
> 
> The subdev core code currently rely on the subdev open handler to
> initialize the file handle's pad configuration, even though subdevs now
> have a pad operation dedicated for that purpose.
> 
> As a first step towards migration to init_cfg, call the operation
> operation in the subdev core open implementation. Subdevs that are
> haven't been moved to init_cfg yet will just continue implementing pad
> config initialization in their open handler.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Hans Verkuil 

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] media: Add per-file-handle data support

[Hans Verkuil]

On 05/04/2016 01:25 PM, Sakari Ailus wrote:
> From: Laurent Pinchart 
> 
> The media devnode core associates devnodes with files by storing the
> devnode pointer in the file structure private_data field. In order to
> allow tracking of per-file-handle data introduce a new media devnode
> file handle structure that stores the devnode pointer, and store a
> pointer to that structure in the file private_data field.
> 
> Users of the media devnode code (the only existing user being
> media_device) are responsible for managing their own subclass of the
> media_devnode_fh structure.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Hans Verkuil 

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] media: Move media_device link_notify operation to an ops structure

[Hans Verkuil]

On 05/04/2016 02:26 PM, Sakari Ailus wrote:
> From: Laurent Pinchart 
> 
> This will allow adding new operations without increasing the
> media_device structure size for drivers that don't implement any media
> device operation.
> 
> Signed-off-by: Laurent Pinchart 
> 
> Fix compilation error for the omap3isp driver.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi Jani,

Am 04.05.2016 um 11:58 schrieb Jani Nikula :

> On Wed, 04 May 2016, Markus Heiser  wrote:
>> but I think this will not by very helpful, as long as you miss 
>> a similar ".tmpl" workflow for reST documents.
>> 
>> I'am working on a reST directive (named: "kernel-doc") to provide a
>> similar ".tmpl" workflow within plain reST. The first step towards
>> is done with (my) modified kernel-doc script ...
>> 
>> * 
>> https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc#L1736
>> 
>> which produce reST from source code comments. E.g. this content is 
>> generated with it.
> 
> What do you mean by ".tmpl workflow"?

Sorry for bad naming, I addressed the DOCPROC build process which builds
the .xml files from .tmpl files ...

 
###
# The build process is as follows (targets):
#  (xmldocs) [by docproc]
# file.tmpl --> file.xml +--> file.ps   (psdocs)   [by db2ps or xmlto]
#+--> file.pdf  (pdfdocs)  [by db2pdf or xmlto]
#+--> DIR=file  (htmldocs) [by xmlto]
#+--> man/  (mandocs)  [by xmlto]

###
# DOCPROC is used for two purposes:
# 1) To generate a dependency list for a .tmpl file
# 2) To preprocess a .tmpl file and call kernel-doc with
# appropriate parameters.
# The following rules are used to generate the .xml documentation
# required to generate the final targets. (ps, pdf, html).
 -


The DOCPROC markup directives are described in the kernel-doc-nano-HOWTO:

https://github.com/torvalds/linux/blob/master/Documentation/kernel-doc-nano-HOWTO.txt#L332

My aim is to implement a reST-directive which is similar. E.g: 
 
 -

  Device Instance and Driver Handling
!Pdrivers/gpu/drm/drm_drv.c driver instance overview
!Edrivers/gpu/drm/drm_drv.c


 -

In reST the directive might look like:

 -
Device Instance and Driver Handling
===

.. kernel-doc::  drivers/gpu/drm/drm_drv.c
   :doc:  driver instance overview
   :exported:

 -


> I'd be *very* hesitant about adding the kind of things you do in
> reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc
> comments must be as simple as possible with basically pass-through of
> the comment blocks to sphinx.

Right, but you forgot, that the current markup in the source code comments
is based on the  kernel-doc-nano-HOWTO and I guess no one will migrate all
these source code comments to reST markup ;-)

So there is a need to differentiate between *vintage* kernel-doc markup 
and reST markup.

My suggestion is to add a tag to the comments, here a short example
what this might look like.

 --
/**
 * drm_minor_release - Release DRM minor
 * @minor: Pointer to DRM minor object
 *
 * Release a minor that was previously acquired via drm_minor_acquire().
 */
 --

in short: the vintage style does not need any change and 
comments with reST markup has a tag ":reST:" in the first 
line(s) ...

 --
/**
 * :reST:
 *
 * .. c:function:: void drm_minor_release(struct drm_minor *minor)
 *
 *Release DRM minor
 *
 *:param struct drm_minor \*minor: Pointer to DRM minor object
 *
 */
 --

Comments with the ":reST:" tag could be exported and pass-through
to sphinx.

> Specifically, do not attempt to detect and
> parse elements like lists in kernel-doc.

If your markup in the comments is plain reST, no need to parse, but there
are markups in the (vintage) comments which made use of individual 
text-markups, e.g. the markup of lists or ASCII-art. 

This individual text-markups has not been converted/rendered in the docbook
output, but I wanted to convert this individuals to reST, to render them in
Sphinx.

E.g. compare the member & description section of struct drm-display-mode ...

DocBook: 

  * https://www.kernel.org/doc/htmldocs/gpu/API-struct-drm-display-mode.html

kernel-doc reST with the additional reformat_block_rst function:

  * 
http://return42.github.io/sphkerneldoc/linux_src_doc/include/drm/drm_modes_h.html#struct-drm-display-mode


-- Markus--

> -- 
> Jani Nikula, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] media: Support variable size IOCTL arguments

[Hans Verkuil]

Hi Sakari,

On 05/04/2016 01:20 PM, Sakari Ailus wrote:
> Instead of checking for a strict size for the IOCTL arguments, place
> minimum and maximum limits.
> 
> As an additional bonus, IOCTL handlers will be able to check whether the
> caller actually set (using the argument size) the field vs. assigning it
> to zero. Separate macro can be provided for that.
> 
> This will be easier for applications as well since there is no longer the
> problem of setting the reserved fields zero, or at least it is a lesser
> problem.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/media-device.c | 45 
> +---
>  1 file changed, 30 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 8aef5b8..c638d3b 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -393,32 +393,44 @@ static long copy_arg_to_user_nop(void __user *uarg, 
> void *karg,
>  /* Do acquire the graph mutex */
>  #define MEDIA_IOC_FL_GRAPH_MUTEX BIT(0)
>  
> -#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user)   \
> +#define MEDIA_IOC_ARG(__cmd, arg_type, func, fl, from_user, to_user) \
>   [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
>   .cmd = MEDIA_IOC_##__cmd,   \
>   .fn = (long (*)(struct media_device *, void *))func,\
>   .flags = fl,\
> + .min_arg_size = sizeof(arg_type),   \

Hmm. I would prefer to change this to a pointer to an array of possible sizes.

E.g.

u16 media_ioc_foo_sizes[] = {
sizeof(struct foo_v1),
sizeof(struct foo_v2),
sizeof(struct foo_v3),
0
};

And pass this array to MEDIA_IOC_ARG, or NULL if there are no other versions.
In that case the code can use _IOC_SIZE.

That way the ioctl check is precise instead of a simple range check.

So add a size field for the default handling:

.size = _IOC_SIZE(MEDIA_IOC_##__cmd),

and a old_sizes pointer:

.old_sizes = oldsizesptr,

In the ioctl check code first compare _IOC_SIZE with the size field, and
if different walk the old_sizes array (if that pointer is != NULL).

Regards,

Hans

>   .arg_from_user = from_user, \
>   .arg_to_user = to_user, \
>   }
>  
> -#define MEDIA_IOC(__cmd, func, fl)   \
> - MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
> +#define MEDIA_IOC(__cmd, arg_type, func, fl) \
> + MEDIA_IOC_ARG(__cmd, arg_type, func, fl,\
> +   copy_arg_from_user, copy_arg_to_user)
>  
>  /* the table is indexed by _IOC_NR(cmd) */
>  struct media_ioctl_info {
>   unsigned int cmd;
>   long (*fn)(struct media_device *dev, void *arg);
>   unsigned short flags;
> + unsigned short min_arg_size;
>   long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd);
>   long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
>  };
>  
> +#define MASK_IOC_SIZE(cmd) \
> + ((cmd) & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT))
> +
>  static inline long is_valid_ioctl(const struct media_ioctl_info *info,
> unsigned int len, unsigned int cmd)
>  {
> - return (_IOC_NR(cmd) >= len
> - || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0;
> + if (_IOC_NR(cmd) >= len)
> + return -ENOIOCTLCMD;
> +
> + info += _IOC_NR(cmd);
> +
> + return (MASK_IOC_SIZE(info->cmd) != MASK_IOC_SIZE(cmd)
> + || _IOC_SIZE(cmd) < info->min_arg_size
> + || _IOC_SIZE(cmd) > _IOC_SIZE(info->cmd)) ? -ENOIOCTLCMD : 0;
>  }
>  
>  static unsigned int media_ioctl_max_arg_size(
> @@ -454,6 +466,9 @@ static long __media_device_ioctl(
>  
>   info->arg_from_user(karg, arg, cmd);
>  
> + /* Set the rest of the argument struct to zero */
> + memset(karg + _IOC_SIZE(cmd), 0, _IOC_SIZE(info->cmd) - _IOC_SIZE(cmd));
> +
>   if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
>   mutex_lock(>graph_mutex);
>  
> @@ -469,11 +484,11 @@ static long __media_device_ioctl(
>  }
>  
>  static const struct media_ioctl_info ioctl_info[] = {
> - MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
> - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> - MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> - MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(DEVICE_INFO, struct media_device_info, 

Re: [PATCH v2 3/5] media: Refactor copying IOCTL arguments from and to user space

[Sakari Ailus]

Hi Hans,

On Wed, May 04, 2016 at 02:24:47PM +0200, Hans Verkuil wrote:
> Hi Sakari,
> 
> Thanks for working on this!
> 
> I've got one comment:
> 
> On 05/04/2016 01:20 PM, Sakari Ailus wrote:
> > Refactor copying the IOCTL argument structs from the user space and back,
> > in order to reduce code copied around and make the implementation more
> > robust.
> > 
> > As a result, the copying is done while not holding the graph mutex.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/media-device.c | 214 
> > ++-
> >  1 file changed, 110 insertions(+), 104 deletions(-)
> > 
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index 9b5a88d..39fe07f 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> 
> 
> 
> >  static long __media_device_ioctl(
> > struct file *filp, unsigned int cmd, void __user *arg,
> > -   const struct media_ioctl_info *info_array, unsigned int info_array_len)
> > +   const struct media_ioctl_info *info_array, unsigned int info_array_len,
> > +   unsigned int *max_arg_size)
> >  {
> > struct media_devnode *devnode = media_devnode_data(filp);
> > struct media_device *dev = to_media_device(devnode);
> > const struct media_ioctl_info *info;
> > +   char karg[media_ioctl_max_arg_size(info_array, info_array_len,
> > +  max_arg_size)];
> 
> This isn't going to work. Sparse (and/or smatch) will complain about this. I 
> recommend
> doing the same as videodev does: have a fixed array on the stack, and use 
> kmalloc if
> more is needed.
> 
> I don't like the max_arg_size anyway :-)

Sparse might warn, yes, but it doesn't make the solution worse. :-)

That would leave it up to the developers to maintain the argument size sane.
Sure I can change this.

-- 
Cheers,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] media: Move media_device link_notify operation to an ops structure

[Sakari Ailus]

From: Laurent Pinchart 

This will allow adding new operations without increasing the
media_device structure size for drivers that don't implement any media
device operation.

Signed-off-by: Laurent Pinchart 

Fix compilation error for the omap3isp driver.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c  | 11 ++-
 drivers/media/platform/exynos4-is/media-dev.c |  6 +-
 drivers/media/platform/omap3isp/isp.c |  6 +-
 drivers/staging/media/omap4iss/iss.c  |  6 +-
 include/media/media-device.h  | 16 
 5 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index c53c1d5..301fd4f 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -806,17 +806,18 @@ int __media_entity_setup_link(struct media_link *link, 
u32 flags)
 
mdev = source->graph_obj.mdev;
 
-   if (mdev->link_notify) {
-   ret = mdev->link_notify(link, flags,
-   MEDIA_DEV_NOTIFY_PRE_LINK_CH);
+   if (mdev->ops && mdev->ops->link_notify) {
+   ret = mdev->ops->link_notify(link, flags,
+MEDIA_DEV_NOTIFY_PRE_LINK_CH);
if (ret < 0)
return ret;
}
 
ret = __media_entity_setup_link_notify(link, flags);
 
-   if (mdev->link_notify)
-   mdev->link_notify(link, flags, MEDIA_DEV_NOTIFY_POST_LINK_CH);
+   if (mdev->ops && mdev->ops->link_notify)
+   mdev->ops->link_notify(link, flags,
+  MEDIA_DEV_NOTIFY_POST_LINK_CH);
 
return ret;
 }
diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index 04348b5..1ed1a9e 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1190,6 +1190,10 @@ static int fimc_md_link_notify(struct media_link *link, 
unsigned int flags,
return ret ? -EPIPE : 0;
 }
 
+static const struct media_device_ops fimc_md_ops = {
+   .link_notify = fimc_md_link_notify,
+};
+
 static ssize_t fimc_md_sysfs_show(struct device *dev,
  struct device_attribute *attr, char *buf)
 {
@@ -1416,7 +1420,7 @@ static int fimc_md_probe(struct platform_device *pdev)
 
strlcpy(fmd->media_dev.model, "SAMSUNG S5P FIMC",
sizeof(fmd->media_dev.model));
-   fmd->media_dev.link_notify = fimc_md_link_notify;
+   fmd->media_dev.ops = _md_ops;
fmd->media_dev.dev = dev;
 
v4l2_dev = >v4l2_dev;
diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 5d54e2c..0321d84 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -657,6 +657,10 @@ static irqreturn_t isp_isr(int irq, void *_isp)
return IRQ_HANDLED;
 }
 
+static const struct media_device_ops isp_media_ops = {
+   .link_notify = v4l2_pipeline_link_notify,
+};
+
 /* 
-
  * Pipeline stream management
  */
@@ -1680,7 +1684,7 @@ static int isp_register_entities(struct isp_device *isp)
strlcpy(isp->media_dev.model, "TI OMAP3 ISP",
sizeof(isp->media_dev.model));
isp->media_dev.hw_revision = isp->revision;
-   isp->media_dev.link_notify = v4l2_pipeline_link_notify;
+   isp->media_dev.ops = _media_ops;
media_device_init(>media_dev);
 
isp->v4l2_dev.mdev = >media_dev;
diff --git a/drivers/staging/media/omap4iss/iss.c 
b/drivers/staging/media/omap4iss/iss.c
index c5a5138..355a704 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -362,6 +362,10 @@ static irqreturn_t iss_isr(int irq, void *_iss)
return IRQ_HANDLED;
 }
 
+static const struct media_device_ops iss_media_ops = {
+   .link_notify = v4l2_pipeline_link_notify,
+};
+
 /* 
-
  * Pipeline stream management
  */
@@ -988,7 +992,7 @@ static int iss_register_entities(struct iss_device *iss)
strlcpy(iss->media_dev.model, "TI OMAP4 ISS",
sizeof(iss->media_dev.model));
iss->media_dev.hw_revision = iss->revision;
-   iss->media_dev.link_notify = v4l2_pipeline_link_notify;
+   iss->media_dev.ops = _media_ops;
ret = media_device_register(>media_dev);
if (ret < 0) {
dev_err(iss->dev, "Media device registration failed (%d)\n",
diff --git a/include/media/media-device.h b/include/media/media-device.h
index a9b33c4..19c8ed4 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -280,6 

Re: [PATCH v2 3/5] media: Refactor copying IOCTL arguments from and to user space

[Hans Verkuil]

Hi Sakari,

Thanks for working on this!

I've got one comment:

On 05/04/2016 01:20 PM, Sakari Ailus wrote:
> Refactor copying the IOCTL argument structs from the user space and back,
> in order to reduce code copied around and make the implementation more
> robust.
> 
> As a result, the copying is done while not holding the graph mutex.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/media-device.c | 214 
> ++-
>  1 file changed, 110 insertions(+), 104 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 9b5a88d..39fe07f 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c



>  static long __media_device_ioctl(
>   struct file *filp, unsigned int cmd, void __user *arg,
> - const struct media_ioctl_info *info_array, unsigned int info_array_len)
> + const struct media_ioctl_info *info_array, unsigned int info_array_len,
> + unsigned int *max_arg_size)
>  {
>   struct media_devnode *devnode = media_devnode_data(filp);
>   struct media_device *dev = to_media_device(devnode);
>   const struct media_ioctl_info *info;
> + char karg[media_ioctl_max_arg_size(info_array, info_array_len,
> +max_arg_size)];

This isn't going to work. Sparse (and/or smatch) will complain about this. I 
recommend
doing the same as videodev does: have a fixed array on the stack, and use 
kmalloc if
more is needed.

I don't like the max_arg_size anyway :-)

>   long ret;
>  
>   ret = is_valid_ioctl(info_array, info_array_len, cmd);

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Wolfram Sang]

Hi Peter,

thanks for the detailed explanation!

> So maybe there should be only one flag, e.g. I2C_LOCK_ROOT_ADAPTER?
> I.e. perhaps leave the future for later?

I think this makes the current code easier understandable at this point,
but I'll leave the decision to you. I am fine with both. Maybe a few
words of explanation would be good if you want to keep both flags.

> Hmmm, I just now realized that you were not really suggesting any
> changes other than to the commit message. Oh well, I can perhaps
> rephrase some of the above in the commit message if you think that
> we should not unnecessarily touch the code at this point...

Yes, updated commit description is enough for me now. If you want to
change to one flag, we should do it incrementally. I think I can apply
this as a fixup until around rc3 I'd say.

> > I think this kerneldoc should be moved to i2c_lock_adapter and/or
> > i2c_lock_bus() which are now in i2c.h. This is what users will use, not
> > this static, adapter-specific implementation. I think it is enough to
> > have a comment here explaining what is special in handling adapters.
> 
> Yes, I was not really satisfied with having documentation on static
> functions. But if I move it, there is no natural home for the current
> i2c_trylock_adapter docs, and I'd hate killing documentation that
> still applies. Do you have a suggestion? Maybe keep that one doc at
> the static i2c_trylock_adapter for now and move it to ->trylock_bus
> when someone decides to write kerneldoc for struct i2c_adapter?

Well, because I think redundancy is acceptable when it comes to
documentation, how about keeping the chunks you already have and copy an
adapted one over to the functions in i2c.h?

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

[Hans Verkuil]

On 05/04/2016 01:42 PM, Ismael Luceno wrote:
> On 04/Mai/2016 10:02, Hans Verkuil wrote:
>> Hi Ismael,
>>
>> On 04/30/2016 05:17 AM, Ismael Luceno wrote:
>>> Additionally, now it specifies which channels it's showing.
>>>
>>> Signed-off-by: Ismael Luceno 
>>> ---
>>>  drivers/media/pci/solo6x10/solo6x10-v4l2.c | 27 +--
>>>  1 file changed, 9 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c 
>>> b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
>>> index 721ff53..935c1b6 100644
>>> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c
>>> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
>>> @@ -386,26 +386,17 @@ static int solo_querycap(struct file *file, void  
>>> *priv,
>>>  static int solo_enum_ext_input(struct solo_dev *solo_dev,
>>>struct v4l2_input *input)
>>>  {
>>> -   static const char * const dispnames_1[] = { "4UP" };
>>> -   static const char * const dispnames_2[] = { "4UP-1", "4UP-2" };
>>> -   static const char * const dispnames_5[] = {
>>> -   "4UP-1", "4UP-2", "4UP-3", "4UP-4", "16UP"
>>> -   };
>>> -   const char * const *dispnames;
>>> -
>>> -   if (input->index >= (solo_dev->nr_chans + solo_dev->nr_ext))
>>> -   return -EINVAL;
>>> -
>>> -   if (solo_dev->nr_ext == 5)
>>> -   dispnames = dispnames_5;
>>> -   else if (solo_dev->nr_ext == 2)
>>> -   dispnames = dispnames_2;
>>> -   else
>>> -   dispnames = dispnames_1;
>>> +   int ext = input->index - solo_dev->nr_chans;
>>> +   unsigned int nup, first;
>>>  
>>> -   snprintf(input->name, sizeof(input->name), "Multi %s",
>>> -dispnames[input->index - solo_dev->nr_chans]);
>>> +   if (ext >= solo_dev->nr_ext)
>>> +   return -EINVAL;
>>>  
>>> +   nup   = (ext == 4) ? 16 : 4;
>>> +   first = (ext & 3) << 2;
>>> +   snprintf(input->name, sizeof(input->name),
>>> +"Multi %d-up (cameras %d-%d)",
>>> +nup, first + 1, first + nup);
>>
>> Shouldn't this be: nup, first + 1, nup);
>>
>> Now it displays cameras as 1-5, 2-6, 3-7, 4-8 if I am not mistaken.
> 
> Hi Hans.
> 
> The var "first" takes the values {0, 4, 8, 12}, so the code is correct,
> it displays: 1-4, 5-8, 9-12, 13-16, or 1-16.

Ah, now I see what you do. Can you add a little comment here? For example:

/* Construct the text: cameras 1-4, 5-8, 9-12, 13-16, or 1-16 */

It's a bit obfuscated otherwise.

Thanks!

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

[Ismael Luceno]

On 04/Mai/2016 10:02, Hans Verkuil wrote:
> Hi Ismael,
> 
> On 04/30/2016 05:17 AM, Ismael Luceno wrote:
> > Additionally, now it specifies which channels it's showing.
> > 
> > Signed-off-by: Ismael Luceno 
> > ---
> >  drivers/media/pci/solo6x10/solo6x10-v4l2.c | 27 +--
> >  1 file changed, 9 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c 
> > b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
> > index 721ff53..935c1b6 100644
> > --- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c
> > +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
> > @@ -386,26 +386,17 @@ static int solo_querycap(struct file *file, void  
> > *priv,
> >  static int solo_enum_ext_input(struct solo_dev *solo_dev,
> >struct v4l2_input *input)
> >  {
> > -   static const char * const dispnames_1[] = { "4UP" };
> > -   static const char * const dispnames_2[] = { "4UP-1", "4UP-2" };
> > -   static const char * const dispnames_5[] = {
> > -   "4UP-1", "4UP-2", "4UP-3", "4UP-4", "16UP"
> > -   };
> > -   const char * const *dispnames;
> > -
> > -   if (input->index >= (solo_dev->nr_chans + solo_dev->nr_ext))
> > -   return -EINVAL;
> > -
> > -   if (solo_dev->nr_ext == 5)
> > -   dispnames = dispnames_5;
> > -   else if (solo_dev->nr_ext == 2)
> > -   dispnames = dispnames_2;
> > -   else
> > -   dispnames = dispnames_1;
> > +   int ext = input->index - solo_dev->nr_chans;
> > +   unsigned int nup, first;
> >  
> > -   snprintf(input->name, sizeof(input->name), "Multi %s",
> > -dispnames[input->index - solo_dev->nr_chans]);
> > +   if (ext >= solo_dev->nr_ext)
> > +   return -EINVAL;
> >  
> > +   nup   = (ext == 4) ? 16 : 4;
> > +   first = (ext & 3) << 2;
> > +   snprintf(input->name, sizeof(input->name),
> > +"Multi %d-up (cameras %d-%d)",
> > +nup, first + 1, first + nup);
> 
> Shouldn't this be: nup, first + 1, nup);
> 
> Now it displays cameras as 1-5, 2-6, 3-7, 4-8 if I am not mistaken.

Hi Hans.

The var "first" takes the values {0, 4, 8, 12}, so the code is correct,
it displays: 1-4, 5-8, 9-12, 13-16, or 1-16.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Add GS driver (SPI video serializer family)

[Hans Verkuil]

Hi Charles-Antoine,

On 04/28/2016 04:10 PM, Charles-Antoine Couret wrote:
> Hello,
> Here my second patch version about GS serializer.
> It should be easy to add support for GS1582 and GS1572.
> I am not sure about V4L2 interfaces to set/get timings.
> I tested with GS1662 component and v4l2-dbg and v4l2-ctl tools.
> 
> But this component family support CEA standards and other
> (SMPTE XXXM in fact). V4L2 seems oriented to manage CEA or
> VGA formats. So, I used timings structure with CEA values, but I
> fill timings fields manually for other standards. I don't know if it
> is the right method or if another interface should be more interesting.

As long as the timings are part of a standard, then just add them to
the v4l2-dv-timings.h header. Since these timings aren't part of the CEA-861
standard or the DMT VESA standard, just add a new SMPTE standard flag.

> 
> And I used the reset method which seems deprecated. But for this
> component, it should be the right way to reset in auto-detection mode
> instead of "timings forced by user".
> 
> Thank you in advance for your comments.
> Regards.
> Charles-Antoine Couret
> 
> From a1bc59b8b18dc75bbf3a70483f57d4ccd190b5f9 Mon Sep 17 00:00:00 2001
> From: Charles-Antoine Couret 
> Date: Fri, 1 Apr 2016 17:19:26 +0200
> Subject: [PATCH] Add GS driver (SPI video serializer family)
> 
> This patch was tested with GS1662:
> http://www.c-dis.net/media/871/GS1662_Datasheet.pdf

A pointer to this datasheet should be in a comment in the source code.

> 
> It is a v4l2-subdev which serializes some CEA formats
> and other. The driver could receive some custom timings and
> other supported format.
> 
> Signed-off-by: Charles-Antoine Couret 
> ---
>  drivers/media/Kconfig  |   1 +
>  drivers/media/Makefile |   2 +-
>  drivers/media/spi/Kconfig  |   5 +
>  drivers/media/spi/Makefile |   1 +
>  drivers/media/spi/gs.c | 482 
> +

I would just call it gs1662. That's all you've tested with, after all.

It is very common that drivers named after the first supported model also
support similar models.

>  5 files changed, 490 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/spi/Kconfig
>  create mode 100644 drivers/media/spi/Makefile
>  create mode 100644 drivers/media/spi/gs.c
> 
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index a8518fb..d2fa6e7 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -215,5 +215,6 @@ config MEDIA_ATTACH
>  source "drivers/media/i2c/Kconfig"
>  source "drivers/media/tuners/Kconfig"
>  source "drivers/media/dvb-frontends/Kconfig"
> +source "drivers/media/spi/Kconfig"
>  
>  endif # MEDIA_SUPPORT
> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index e608bbc..75bc82e 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -28,6 +28,6 @@ obj-y += rc/
>  # Finally, merge the drivers that require the core
>  #
>  
> -obj-y += common/ platform/ pci/ usb/ mmc/ firewire/
> +obj-y += common/ platform/ pci/ usb/ mmc/ firewire/ spi/
>  obj-$(CONFIG_VIDEO_DEV) += radio/
>  
> diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
> new file mode 100644
> index 000..19a257c
> --- /dev/null
> +++ b/drivers/media/spi/Kconfig
> @@ -0,0 +1,5 @@
> +config VIDEO_GS
> + tristate "Gennum Serializers video"
> + depends on SPI
> + ---help---
> +   Enable the GS driver which serializes video streams.
> diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
> new file mode 100644
> index 000..a67df8d
> --- /dev/null
> +++ b/drivers/media/spi/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_GS) += gs.o
> diff --git a/drivers/media/spi/gs.c b/drivers/media/spi/gs.c
> new file mode 100644
> index 000..0745ef9
> --- /dev/null
> +++ b/drivers/media/spi/gs.c
> @@ -0,0 +1,482 @@
> +/*
> + * GS device registration. Tested with GS1662 device.
> + *
> + * Copyright (C) 2015-2016 Nexvision
> + * Author: Charles-Antoine Couret 
> + *
> + * 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 
> +
> +
> +#define REG_STATUS   0x04
> +#define REG_FORCE_FMT0x06
> +#define REG_LINES_PER_FRAME  0x12
> +#define REG_WORDS_PER_LINE   0x13
> +#define REG_WORDS_PER_ACT_LINE   0x14
> +#define REG_ACT_LINES_PER_FRAME  0x15
> +
> +#define MASK_H_LOCK  0x001
> +#define MASK_V_LOCK 

[PATCH 3/3] v4l: subdev: Call pad init_cfg operation when opening subdevs

[Sakari Ailus]

From: Laurent Pinchart 

The subdev core code currently rely on the subdev open handler to
initialize the file handle's pad configuration, even though subdevs now
have a pad operation dedicated for that purpose.

As a first step towards migration to init_cfg, call the operation
operation in the subdev core open implementation. Subdevs that are
haven't been moved to init_cfg yet will just continue implementing pad
config initialization in their open handler.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/v4l2-subdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index 224ea60..9cbd011 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -85,6 +85,8 @@ static int subdev_open(struct file *file)
}
 #endif
 
+   v4l2_subdev_call(sd, pad, init_cfg, subdev_fh->pad);
+
if (sd->internal_ops && sd->internal_ops->open) {
ret = sd->internal_ops->open(sd, subdev_fh);
if (ret < 0)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] media: Add per-file-handle data support

[Sakari Ailus]

From: Laurent Pinchart 

The media devnode core associates devnodes with files by storing the
devnode pointer in the file structure private_data field. In order to
allow tracking of per-file-handle data introduce a new media devnode
file handle structure that stores the devnode pointer, and store a
pointer to that structure in the file private_data field.

Users of the media devnode code (the only existing user being
media_device) are responsible for managing their own subclass of the
media_devnode_fh structure.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/media-device.c  | 21 +
 drivers/media/media-devnode.c | 21 ++---
 include/media/media-devnode.h | 18 +-
 3 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 898a3cf..89602a7 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -39,6 +39,15 @@
 
 #ifdef CONFIG_MEDIA_CONTROLLER
 
+struct media_device_fh {
+   struct media_devnode_fh fh;
+};
+
+static inline struct media_device_fh *media_device_fh(struct file *filp)
+{
+   return container_of(filp->private_data, struct media_device_fh, fh);
+}
+
 /* 
-
  * Userspace API
  */
@@ -50,11 +59,23 @@ static inline void __user *media_get_uptr(__u64 arg)
 
 static int media_device_open(struct file *filp)
 {
+   struct media_device_fh *fh;
+
+   fh = kzalloc(sizeof(*fh), GFP_KERNEL);
+   if (!fh)
+   return -ENOMEM;
+
+   filp->private_data = >fh;
+
return 0;
 }
 
 static int media_device_close(struct file *filp)
 {
+   struct media_device_fh *fh = media_device_fh(filp);
+
+   kfree(fh);
+
return 0;
 }
 
diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
index 64a4b1e..d4d2917 100644
--- a/drivers/media/media-devnode.c
+++ b/drivers/media/media-devnode.c
@@ -154,6 +154,7 @@ static long media_compat_ioctl(struct file *filp, unsigned 
int cmd,
 /* Override for the open function */
 static int media_open(struct inode *inode, struct file *filp)
 {
+   struct media_devnode_fh *fh;
struct media_devnode *mdev;
int ret;
 
@@ -175,17 +176,16 @@ static int media_open(struct inode *inode, struct file 
*filp)
get_device(>dev);
mutex_unlock(_devnode_lock);
 
-   filp->private_data = mdev;
-
-   if (mdev->fops->open) {
-   ret = mdev->fops->open(filp);
-   if (ret) {
-   put_device(>dev);
-   filp->private_data = NULL;
-   return ret;
-   }
+   ret = mdev->fops->open(filp);
+   if (ret) {
+   put_device(>dev);
+   filp->private_data = NULL;
+   return ret;
}
 
+   fh = filp->private_data;
+   fh->devnode = mdev;
+
return 0;
 }
 
@@ -194,8 +194,7 @@ static int media_release(struct inode *inode, struct file 
*filp)
 {
struct media_devnode *mdev = media_devnode_data(filp);
 
-   if (mdev->fops->release)
-   mdev->fops->release(filp);
+   mdev->fops->release(filp);
 
/* decrease the refcount unconditionally since the release()
   return value is ignored. */
diff --git a/include/media/media-devnode.h b/include/media/media-devnode.h
index fe42f08..09aafc3 100644
--- a/include/media/media-devnode.h
+++ b/include/media/media-devnode.h
@@ -66,6 +66,20 @@ struct media_file_operations {
 };
 
 /**
+ * struct media_devnode_fh - Media device node file handle
+ * @devnode:   pointer to the media device node
+ *
+ * This structure serves as a base for per-file-handle data storage. Media
+ * device node users embed media_devnode_fh in their custom file handle data
+ * structures and store the media_devnode_fh in the file private_data in order
+ * to let the media device node core locate the media_devnode corresponding to 
a
+ * file handle.
+ */
+struct media_devnode_fh {
+   struct media_devnode *devnode;
+};
+
+/**
  * struct media_devnode - Media device node
  * @fops:  pointer to struct _file_operations with media device ops
  * @dev:   struct device pointer for the media controller device
@@ -138,7 +152,9 @@ void media_devnode_unregister(struct media_devnode *mdev);
  */
 static inline struct media_devnode *media_devnode_data(struct file *filp)
 {
-   return filp->private_data;
+   struct media_devnode_fh *fh = filp->private_data;
+
+   return fh->devnode;
 }
 
 /**
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Media device file handle support, prepare for requests

[Sakari Ailus]

Hi everyone,

These patches add support for media device file handle and make it more
practical to have callback functions in the media device. Also pad
init_cfg() operation is called at sub-device open.

While not directly related to the request API, these will be needed, or
are at least beneficial in implementing it.

I believe we could merge them before the request API as I don't think they
contain controversial aspects (there will be enough of them in the request
API patches themselves) so we could better focus on the problem at hand.

The patches have been written by Laurent, I've rebased them and fixed
minor issues as well.

-- 
Kind regards,
Sakari

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] media: Determine early whether an IOCTL is supported

[Sakari Ailus]

Preparation for refactoring media IOCTL handling to unify common parts.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 52 +---
 1 file changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 898a3cf..c24149d 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -419,13 +419,33 @@ static long media_device_get_topology(struct media_device 
*mdev,
return 0;
 }
 
-static long media_device_ioctl(struct file *filp, unsigned int cmd,
-  unsigned long arg)
+#define MEDIA_IOC(__cmd) \
+   [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd }
+
+/* the table is indexed by _IOC_NR(cmd) */
+struct media_ioctl_info {
+   unsigned int cmd;
+};
+
+static inline long is_valid_ioctl(const struct media_ioctl_info *info,
+ unsigned int len, unsigned int cmd)
+{
+   return (_IOC_NR(cmd) >= len
+   || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0;
+}
+
+static long __media_device_ioctl(
+   struct file *filp, unsigned int cmd, void __user *arg,
+   const struct media_ioctl_info *info_array, unsigned int info_array_len)
 {
struct media_devnode *devnode = media_devnode_data(filp);
struct media_device *dev = to_media_device(devnode);
long ret;
 
+   ret = is_valid_ioctl(info_array, info_array_len, cmd);
+   if (ret)
+   return ret;
+
mutex_lock(>graph_mutex);
switch (cmd) {
case MEDIA_IOC_DEVICE_INFO:
@@ -461,6 +481,22 @@ static long media_device_ioctl(struct file *filp, unsigned 
int cmd,
return ret;
 }
 
+static const struct media_ioctl_info ioctl_info[] = {
+   MEDIA_IOC(DEVICE_INFO),
+   MEDIA_IOC(ENUM_ENTITIES),
+   MEDIA_IOC(ENUM_LINKS),
+   MEDIA_IOC(SETUP_LINK),
+   MEDIA_IOC(G_TOPOLOGY),
+};
+
+static long media_device_ioctl(struct file *filp, unsigned int cmd,
+  unsigned long arg)
+{
+   return __media_device_ioctl(
+   filp, cmd, (void __user *)arg,
+   ioctl_info, ARRAY_SIZE(ioctl_info));
+}
+
 #ifdef CONFIG_COMPAT
 
 struct media_links_enum32 {
@@ -491,6 +527,14 @@ static long media_device_enum_links32(struct media_device 
*mdev,
 
 #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct 
media_links_enum32)
 
+static const struct media_ioctl_info compat_ioctl_info[] = {
+   MEDIA_IOC(DEVICE_INFO),
+   MEDIA_IOC(ENUM_ENTITIES),
+   MEDIA_IOC(ENUM_LINKS32),
+   MEDIA_IOC(SETUP_LINK),
+   MEDIA_IOC(G_TOPOLOGY),
+};
+
 static long media_device_compat_ioctl(struct file *filp, unsigned int cmd,
  unsigned long arg)
 {
@@ -503,7 +547,9 @@ static long media_device_compat_ioctl(struct file *filp, 
unsigned int cmd,
case MEDIA_IOC_ENUM_ENTITIES:
case MEDIA_IOC_SETUP_LINK:
case MEDIA_IOC_G_TOPOLOGY:
-   return media_device_ioctl(filp, cmd, arg);
+   return __media_device_ioctl(
+   filp, cmd, (void __user *)arg,
+   compat_ioctl_info, ARRAY_SIZE(compat_ioctl_info));
 
case MEDIA_IOC_ENUM_LINKS32:
mutex_lock(>graph_mutex);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

[Sakari Ailus]

New IOCTLs (especially for the request API) do not necessarily need the
graph mutex acquired. Leave this up to the drivers.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 47 ++--
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 39fe07f..8aef5b8 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -390,21 +390,26 @@ static long copy_arg_to_user_nop(void __user *uarg, void 
*karg,
 }
 #endif
 
-#define MEDIA_IOC_ARG(__cmd, func, from_user, to_user) \
-   [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
-   .cmd = MEDIA_IOC_##__cmd,   \
+/* Do acquire the graph mutex */
+#define MEDIA_IOC_FL_GRAPH_MUTEX   BIT(0)
+
+#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \
+   [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
+   .cmd = MEDIA_IOC_##__cmd,   \
.fn = (long (*)(struct media_device *, void *))func,\
-   .arg_from_user = from_user, \
-   .arg_to_user = to_user, \
+   .flags = fl,\
+   .arg_from_user = from_user, \
+   .arg_to_user = to_user, \
}
 
-#define MEDIA_IOC(__cmd, func) \
-   MEDIA_IOC_ARG(__cmd, func, copy_arg_from_user, copy_arg_to_user)
+#define MEDIA_IOC(__cmd, func, fl) \
+   MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
 
 /* the table is indexed by _IOC_NR(cmd) */
 struct media_ioctl_info {
unsigned int cmd;
long (*fn)(struct media_device *dev, void *arg);
+   unsigned short flags;
long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd);
long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
 };
@@ -449,9 +454,13 @@ static long __media_device_ioctl(
 
info->arg_from_user(karg, arg, cmd);
 
-   mutex_lock(>graph_mutex);
+   if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
+   mutex_lock(>graph_mutex);
+
ret = info->fn(dev, karg);
-   mutex_unlock(>graph_mutex);
+
+   if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
+   mutex_unlock(>graph_mutex);
 
if (ret)
return ret;
@@ -460,11 +469,11 @@ static long __media_device_ioctl(
 }
 
 static const struct media_ioctl_info ioctl_info[] = {
-   MEDIA_IOC(DEVICE_INFO, media_device_get_info),
-   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
-   MEDIA_IOC(ENUM_LINKS, media_device_enum_links),
-   MEDIA_IOC(SETUP_LINK, media_device_setup_link),
-   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
+   MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
MEDIA_IOC_FL_GRAPH_MUTEX),
 };
 
 static long media_device_ioctl(struct file *filp, unsigned int cmd,
@@ -510,11 +519,11 @@ static long from_user_enum_links32(void *karg, void 
__user *uarg,
 #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct 
media_links_enum32)
 
 static const struct media_ioctl_info compat_ioctl_info[] = {
-   MEDIA_IOC(DEVICE_INFO, media_device_get_info),
-   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
-   MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, 
from_user_enum_links32, copy_arg_to_user_nop),
-   MEDIA_IOC(SETUP_LINK, media_device_setup_link),
-   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
+   MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, 
MEDIA_IOC_FL_GRAPH_MUTEX, from_user_enum_links32, copy_arg_to_user_nop),
+   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
MEDIA_IOC_FL_GRAPH_MUTEX),
 };
 
 static long media_device_compat_ioctl(struct file *filp, unsigned int cmd,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] media: Unify IOCTL handler calling

[Sakari Ailus]

Each IOCTL handler can be listed in an array instead of using a large and
cumbersome switch. Do that.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 89 
 1 file changed, 23 insertions(+), 66 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index c24149d..9b5a88d 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -419,12 +419,16 @@ static long media_device_get_topology(struct media_device 
*mdev,
return 0;
 }
 
-#define MEDIA_IOC(__cmd) \
-   [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd }
+#define MEDIA_IOC(__cmd, func) \
+   [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
+   .cmd = MEDIA_IOC_##__cmd,   \
+   .fn = (long (*)(struct media_device *, void __user *))func,\
+   }
 
 /* the table is indexed by _IOC_NR(cmd) */
 struct media_ioctl_info {
unsigned int cmd;
+   long (*fn)(struct media_device *dev, void __user *arg);
 };
 
 static inline long is_valid_ioctl(const struct media_ioctl_info *info,
@@ -440,53 +444,28 @@ static long __media_device_ioctl(
 {
struct media_devnode *devnode = media_devnode_data(filp);
struct media_device *dev = to_media_device(devnode);
+   const struct media_ioctl_info *info;
long ret;
 
ret = is_valid_ioctl(info_array, info_array_len, cmd);
if (ret)
return ret;
 
+   info = _array[_IOC_NR(cmd)];
+
mutex_lock(>graph_mutex);
-   switch (cmd) {
-   case MEDIA_IOC_DEVICE_INFO:
-   ret = media_device_get_info(dev,
-   (struct media_device_info __user *)arg);
-   break;
-
-   case MEDIA_IOC_ENUM_ENTITIES:
-   ret = media_device_enum_entities(dev,
-   (struct media_entity_desc __user *)arg);
-   break;
-
-   case MEDIA_IOC_ENUM_LINKS:
-   ret = media_device_enum_links(dev,
-   (struct media_links_enum __user *)arg);
-   break;
-
-   case MEDIA_IOC_SETUP_LINK:
-   ret = media_device_setup_link(dev,
-   (struct media_link_desc __user *)arg);
-   break;
-
-   case MEDIA_IOC_G_TOPOLOGY:
-   ret = media_device_get_topology(dev,
-   (struct media_v2_topology __user *)arg);
-   break;
-
-   default:
-   ret = -ENOIOCTLCMD;
-   }
+   ret = info->fn(dev, arg);
mutex_unlock(>graph_mutex);
 
return ret;
 }
 
 static const struct media_ioctl_info ioctl_info[] = {
-   MEDIA_IOC(DEVICE_INFO),
-   MEDIA_IOC(ENUM_ENTITIES),
-   MEDIA_IOC(ENUM_LINKS),
-   MEDIA_IOC(SETUP_LINK),
-   MEDIA_IOC(G_TOPOLOGY),
+   MEDIA_IOC(DEVICE_INFO, media_device_get_info),
+   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
+   MEDIA_IOC(ENUM_LINKS, media_device_enum_links),
+   MEDIA_IOC(SETUP_LINK, media_device_setup_link),
+   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
 };
 
 static long media_device_ioctl(struct file *filp, unsigned int cmd,
@@ -528,41 +507,19 @@ static long media_device_enum_links32(struct media_device 
*mdev,
 #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct 
media_links_enum32)
 
 static const struct media_ioctl_info compat_ioctl_info[] = {
-   MEDIA_IOC(DEVICE_INFO),
-   MEDIA_IOC(ENUM_ENTITIES),
-   MEDIA_IOC(ENUM_LINKS32),
-   MEDIA_IOC(SETUP_LINK),
-   MEDIA_IOC(G_TOPOLOGY),
+   MEDIA_IOC(DEVICE_INFO, media_device_get_info),
+   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
+   MEDIA_IOC(ENUM_LINKS32, media_device_enum_links32),
+   MEDIA_IOC(SETUP_LINK, media_device_setup_link),
+   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
 };
 
 static long media_device_compat_ioctl(struct file *filp, unsigned int cmd,
  unsigned long arg)
 {
-   struct media_devnode *devnode = media_devnode_data(filp);
-   struct media_device *dev = to_media_device(devnode);
-   long ret;
-
-   switch (cmd) {
-   case MEDIA_IOC_DEVICE_INFO:
-   case MEDIA_IOC_ENUM_ENTITIES:
-   case MEDIA_IOC_SETUP_LINK:
-   case MEDIA_IOC_G_TOPOLOGY:
-   return __media_device_ioctl(
-   filp, cmd, (void __user *)arg,
-   compat_ioctl_info, ARRAY_SIZE(compat_ioctl_info));
-
-   case MEDIA_IOC_ENUM_LINKS32:
-   mutex_lock(>graph_mutex);
-   ret = media_device_enum_links32(dev,
-   (struct media_links_enum32 __user *)arg);
-   mutex_unlock(>graph_mutex);
-   break;
-
-   default:
-   ret = -ENOIOCTLCMD;

[PATCH v2 3/5] media: Refactor copying IOCTL arguments from and to user space

[Sakari Ailus]

Refactor copying the IOCTL argument structs from the user space and back,
in order to reduce code copied around and make the implementation more
robust.

As a result, the copying is done while not holding the graph mutex.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 214 ++-
 1 file changed, 110 insertions(+), 104 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 9b5a88d..39fe07f 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -59,27 +59,24 @@ static int media_device_close(struct file *filp)
 }
 
 static int media_device_get_info(struct media_device *dev,
-struct media_device_info __user *__info)
+struct media_device_info *info)
 {
-   struct media_device_info info;
-
-   memset(, 0, sizeof(info));
+   memset(info, 0, sizeof(*info));
 
if (dev->driver_name[0])
-   strlcpy(info.driver, dev->driver_name, sizeof(info.driver));
+   strlcpy(info->driver, dev->driver_name, sizeof(info->driver));
else
-   strlcpy(info.driver, dev->dev->driver->name, 
sizeof(info.driver));
+   strlcpy(info->driver, dev->dev->driver->name,
+   sizeof(info->driver));
 
-   strlcpy(info.model, dev->model, sizeof(info.model));
-   strlcpy(info.serial, dev->serial, sizeof(info.serial));
-   strlcpy(info.bus_info, dev->bus_info, sizeof(info.bus_info));
+   strlcpy(info->model, dev->model, sizeof(info->model));
+   strlcpy(info->serial, dev->serial, sizeof(info->serial));
+   strlcpy(info->bus_info, dev->bus_info, sizeof(info->bus_info));
 
-   info.media_version = MEDIA_API_VERSION;
-   info.hw_revision = dev->hw_revision;
-   info.driver_version = dev->driver_version;
+   info->media_version = MEDIA_API_VERSION;
+   info->hw_revision = dev->hw_revision;
+   info->driver_version = dev->driver_version;
 
-   if (copy_to_user(__info, , sizeof(*__info)))
-   return -EFAULT;
return 0;
 }
 
@@ -101,29 +98,25 @@ static struct media_entity *find_entity(struct 
media_device *mdev, u32 id)
 }
 
 static long media_device_enum_entities(struct media_device *mdev,
-  struct media_entity_desc __user *uent)
+  struct media_entity_desc *entd)
 {
struct media_entity *ent;
-   struct media_entity_desc u_ent;
-
-   memset(_ent, 0, sizeof(u_ent));
-   if (copy_from_user(_ent.id, >id, sizeof(u_ent.id)))
-   return -EFAULT;
-
-   ent = find_entity(mdev, u_ent.id);
 
+   ent = find_entity(mdev, entd->id);
if (ent == NULL)
return -EINVAL;
 
-   u_ent.id = media_entity_id(ent);
+   memset(entd, 0, sizeof(*entd));
+
+   entd->id = media_entity_id(ent);
if (ent->name)
-   strlcpy(u_ent.name, ent->name, sizeof(u_ent.name));
-   u_ent.type = ent->function;
-   u_ent.revision = 0; /* Unused */
-   u_ent.flags = ent->flags;
-   u_ent.group_id = 0; /* Unused */
-   u_ent.pads = ent->num_pads;
-   u_ent.links = ent->num_links - ent->num_backlinks;
+   strlcpy(entd->name, ent->name, sizeof(entd->name));
+   entd->type = ent->function;
+   entd->revision = 0; /* Unused */
+   entd->flags = ent->flags;
+   entd->group_id = 0; /* Unused */
+   entd->pads = ent->num_pads;
+   entd->links = ent->num_links - ent->num_backlinks;
 
/*
 * Workaround for a bug at media-ctl <= v1.10 that makes it to
@@ -139,14 +132,13 @@ static long media_device_enum_entities(struct 
media_device *mdev,
if (ent->function < MEDIA_ENT_F_OLD_BASE ||
ent->function > MEDIA_ENT_T_DEVNODE_UNKNOWN) {
if (is_media_entity_v4l2_subdev(ent))
-   u_ent.type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
+   entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
else if (ent->function != MEDIA_ENT_F_IO_V4L)
-   u_ent.type = MEDIA_ENT_T_DEVNODE_UNKNOWN;
+   entd->type = MEDIA_ENT_T_DEVNODE_UNKNOWN;
}
 
-   memcpy(_ent.raw, >info, sizeof(ent->info));
-   if (copy_to_user(uent, _ent, sizeof(u_ent)))
-   return -EFAULT;
+   memcpy(>raw, >info, sizeof(ent->info));
+
return 0;
 }
 
@@ -158,8 +150,8 @@ static void media_device_kpad_to_upad(const struct 
media_pad *kpad,
upad->flags = kpad->flags;
 }
 
-static long __media_device_enum_links(struct media_device *mdev,
- struct media_links_enum *links)
+static long media_device_enum_links(struct media_device *mdev,
+   struct media_links_enum *links)
 {
struct 

[PATCH v2 0/5] Refactor media IOCTL handling, add variable length arguments

[Sakari Ailus]

Hi everyone,

I've updated my patchset for refactoring the media device IOCTL handling.

The original set is here:



The patches themselves have been reworked so I don't detail the changes
in this set. What's noteworthy however is that the set adds support for
variable length IOCTL arguments.

The patches have been tested on x86_64 and ARM and compat code has been
tested on x86_64. The variable length argument support (in case a struct
grows due to added fields) has been tested, including returning
-ENOIOCTLCMD on bad argument length, on x86_64 with the request API
patches I'll post in the near future.

(The motivation for these patches is having found myself pondering whether
to have nine or thirteen reserved fields for the request IOCTL. I decided
to address the problem instead. If this is found workable on the media
controller we could follow the same model on V4L2.)

Reviews would be very welcome.

-- 
Kind regards,
Sakari

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] media: Support variable size IOCTL arguments

[Sakari Ailus]

Instead of checking for a strict size for the IOCTL arguments, place
minimum and maximum limits.

As an additional bonus, IOCTL handlers will be able to check whether the
caller actually set (using the argument size) the field vs. assigning it
to zero. Separate macro can be provided for that.

This will be easier for applications as well since there is no longer the
problem of setting the reserved fields zero, or at least it is a lesser
problem.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 45 +---
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 8aef5b8..c638d3b 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -393,32 +393,44 @@ static long copy_arg_to_user_nop(void __user *uarg, void 
*karg,
 /* Do acquire the graph mutex */
 #define MEDIA_IOC_FL_GRAPH_MUTEX   BIT(0)
 
-#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \
+#define MEDIA_IOC_ARG(__cmd, arg_type, func, fl, from_user, to_user)   \
[_IOC_NR(MEDIA_IOC_##__cmd)] = {\
.cmd = MEDIA_IOC_##__cmd,   \
.fn = (long (*)(struct media_device *, void *))func,\
.flags = fl,\
+   .min_arg_size = sizeof(arg_type),   \
.arg_from_user = from_user, \
.arg_to_user = to_user, \
}
 
-#define MEDIA_IOC(__cmd, func, fl) \
-   MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
+#define MEDIA_IOC(__cmd, arg_type, func, fl)   \
+   MEDIA_IOC_ARG(__cmd, arg_type, func, fl,\
+ copy_arg_from_user, copy_arg_to_user)
 
 /* the table is indexed by _IOC_NR(cmd) */
 struct media_ioctl_info {
unsigned int cmd;
long (*fn)(struct media_device *dev, void *arg);
unsigned short flags;
+   unsigned short min_arg_size;
long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd);
long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
 };
 
+#define MASK_IOC_SIZE(cmd) \
+   ((cmd) & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT))
+
 static inline long is_valid_ioctl(const struct media_ioctl_info *info,
  unsigned int len, unsigned int cmd)
 {
-   return (_IOC_NR(cmd) >= len
-   || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0;
+   if (_IOC_NR(cmd) >= len)
+   return -ENOIOCTLCMD;
+
+   info += _IOC_NR(cmd);
+
+   return (MASK_IOC_SIZE(info->cmd) != MASK_IOC_SIZE(cmd)
+   || _IOC_SIZE(cmd) < info->min_arg_size
+   || _IOC_SIZE(cmd) > _IOC_SIZE(info->cmd)) ? -ENOIOCTLCMD : 0;
 }
 
 static unsigned int media_ioctl_max_arg_size(
@@ -454,6 +466,9 @@ static long __media_device_ioctl(
 
info->arg_from_user(karg, arg, cmd);
 
+   /* Set the rest of the argument struct to zero */
+   memset(karg + _IOC_SIZE(cmd), 0, _IOC_SIZE(info->cmd) - _IOC_SIZE(cmd));
+
if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
mutex_lock(>graph_mutex);
 
@@ -469,11 +484,11 @@ static long __media_device_ioctl(
 }
 
 static const struct media_ioctl_info ioctl_info[] = {
-   MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(DEVICE_INFO, struct media_device_info, media_device_get_info, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(ENUM_ENTITIES, struct media_entity_desc, 
media_device_enum_entities, MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(ENUM_LINKS, struct media_links_enum, media_device_enum_links, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(SETUP_LINK, struct media_link_desc, media_device_setup_link, 
MEDIA_IOC_FL_GRAPH_MUTEX),
+   MEDIA_IOC(G_TOPOLOGY, struct media_v2_topology, 
media_device_get_topology, MEDIA_IOC_FL_GRAPH_MUTEX),
 };
 
 static long media_device_ioctl(struct file *filp, unsigned int cmd,
@@ -519,11 +534,11 @@ static long from_user_enum_links32(void *karg, void 
__user *uarg,
 #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct 
media_links_enum32)
 
 static const struct media_ioctl_info compat_ioctl_info[] = {
-   MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Peter Rosin]

Hi!

On 2016-05-03 23:38, Wolfram Sang wrote:
> On Wed, Apr 20, 2016 at 05:17:56PM +0200, Peter Rosin wrote:
>> Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
>> unlock_bus ops in the adapter. These funcs/ops take an additional flags
>> argument that indicates for what purpose the adapter is locked.
>>
>> There are two flags, I2C_LOCK_ADAPTER and I2C_LOCK_SEGMENT, but they are
>> both implemented the same. For now. Locking the adapter means that the
>> whole bus is locked, locking the segment means that only the current bus
>> segment is locked (i.e. i2c traffic on the parent side of mux is still
>> allowed even if the child side of the mux is locked.
>>
>> Also support a trylock_bus op (but no function to call it, as it is not
>> expected to be needed outside of the i2c core).
>>
>> Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking
>> scheme (i.e. lock with the I2C_LOCK_ADAPTER flag).
>>
>> Annotate some of the locking with explicit I2C_LOCK_SEGMENT flags.
> 
> Can you explain a little why it is SEGMENT and not ADAPTER here? That
> probably makes it easier to get into this patch.
> 
> And to double check my understanding: I was surprised to not see any
> i2c_lock_adapter() or I2C_LOCK_ADAPTER in action. This is because muxes
> call I2C_LOCK_SEGMENT on their parent which in case of the parent being
> the root adapter is essentially the same as I2C_LOCK_ADAPTER. Correct?

Correct. Locking the ADAPTER and the SEGMENT is the same thing for
the root adapter and for traditional muxes (i.e. not mux-locked).
Traditional muxes simply feed the locking request upwards to the
root adapter. The new mux-locked muxes behave the same for ADAPTER
locking; all locks all the way up to the root adapter are grabbed
instantly. If you instead lock SEGMENT on a mux-locked mux, only
the new mux lock in the parent adapter is grabbed right away, but
when the mux then fires off accesses on its parent adapter, that
triggers SEGMENT locks one level up in the tree and the process
recurses.

So, SEGMENT locking is the normal thing that happens when e.g. normal
i2c_transfer calls are made. ADAPTER locking is used for transactions.
The patch enables muxes to use more relaxed locking compared to
locking the ADAPTER for its transations.

The naming can probably be improved. SEGMENT made more sense when
it did not lock all mux accesses one level up (that changed in v6,
but I didn't change the I2C_LOCK_SEGMENT name at that time), so it
is kind of outdated. I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_MUXES instead
of I2C_LOCK_ADAPTER and L2C_LOCK_SEGMENT perhaps?

But I don't really like I2C_LOCK_MUXES as I find it a bit too specific,
and people not thinking about i2c muxes at all (most people I gather,
ignorance is bliss) will not think that it is something for them...

It is also the case that the two flags are mutually exclusive, and
at this point there is no valid uses of using neither flag, nor for
using both. It is a binary decision and one flag would technically be
enough. So, not setting e.g. I2C_LOCK_ADAPTER could in theory imply
I2C_LOCK_SEGMENT. I did it as two separate flags since there might
be a third (or fourth even) option in the future (I don't see what
it would be though, I have no crystal ball...)

So maybe there should be only one flag, e.g. I2C_LOCK_ROOT_ADAPTER?
I.e. perhaps leave the future for later?

Hmmm, I just now realized that you were not really suggesting any
changes other than to the commit message. Oh well, I can perhaps
rephrase some of the above in the commit message if you think that
we should not unnecessarily touch the code at this point...

>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/i2c/i2c-core.c | 46 --
>>  include/linux/i2c.h| 28 ++--
>>  2 files changed, 54 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index 0f2f8484e8ec..21f46d011c33 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -960,10 +960,12 @@ static int i2c_check_addr_busy(struct i2c_adapter 
>> *adapter, int addr)
>>  }
>>  
>>  /**
>> - * i2c_lock_adapter - Get exclusive access to an I2C bus segment
>> + * i2c_adapter_lock_bus - Get exclusive access to an I2C bus segment
>>   * @adapter: Target I2C bus segment
>> + * @flags: I2C_LOCK_ADAPTER locks the root i2c adapter, I2C_LOCK_SEGMENT
>> + *  locks only this branch in the adapter tree
>>   */
> 
> I think this kerneldoc should be moved to i2c_lock_adapter and/or
> i2c_lock_bus() which are now in i2c.h. This is what users will use, not
> this static, adapter-specific implementation. I think it is enough to
> have a comment here explaining what is special in handling adapters.

Yes, I was not really satisfied with having documentation on static
functions. But if I move it, there is no natural home for the current
i2c_trylock_adapter docs, and I'd hate killing 

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Wed, 04 May 2016, Markus Heiser  wrote:
> but I think this will not by very helpful, as long as you miss 
> a similar ".tmpl" workflow for reST documents.
>
> I'am working on a reST directive (named: "kernel-doc") to provide a
> similar ".tmpl" workflow within plain reST. The first step towards
> is done with (my) modified kernel-doc script ...
>
> * 
> https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc#L1736
>
> which produce reST from source code comments. E.g. this content is 
> generated with it.

What do you mean by ".tmpl workflow"?

I'd be *very* hesitant about adding the kind of things you do in
reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc
comments must be as simple as possible with basically pass-through of
the comment blocks to sphinx. Specifically, do not attempt to detect and
parse elements like lists in kernel-doc.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi all, (hi Jonathan, please take note of my offer below)

Am 03.05.2016 um 16:31 schrieb Daniel Vetter :

> Hi all,
> 
> So sounds like moving ahead with rst/sphinx is the option that should
> allow us to address everyone's concerns eventually? Of course the
> first one won't have it all (media seems really tricky), ...

BTW: Mauro mentioned that ASCII-art tables are not diff-friendly ... 

Am 18.04.2016 um 13:16 schrieb Mauro Carvalho Chehab :

> With that sense, the "List tables" format is also not good, as
> one row addition would generate several hunks (one for each column
> of the table), making harder to review the patch by just looking at
> the diff.

For this, I wrote the "flat-table" reST-directive, which adds 
missing cells automatically:

doc:
http://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table
source: 
https://github.com/return42/sphkerneldoc/blob/master/doc/extensions/rstFlatTable.py

I used "flat-table" to migrate all DocBook-XML documents to reST. With this
directive, I also managed to migrate the complete media book (no more TODOs)
incl. the large tables like them from subdev-formats:

https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html

(Rendering large tables is a general discussion which should not take place in 
this MT)

>  but I'd like
> to get something awesome in this area closer to mainline. I'm stalling
> on typing more fancyful gpu docs right now (with tables, pictures and
> stuff) since that would require a pile of needless work to redo when
> we switch a few times more ;-)

Are your "fancyful gpu" written from scratch, or will it be an rewrite
of the Documentation/DocBook/gpu.tmpl?

If it is the last; as starting point you can use a copy of:

https://github.com/return42/sphkerneldoc/tree/master/doc/books/gpu

but I think this will not by very helpful, as long as you miss 
a similar ".tmpl" workflow for reST documents.

I'am working on a reST directive (named: "kernel-doc") to provide a
similar ".tmpl" workflow within plain reST. The first step towards
is done with (my) modified kernel-doc script ...

* https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc#L1736

which produce reST from source code comments. E.g. this content is 
generated with it.

* http://return42.github.io/sphkerneldoc/linux_src_doc/index.html

> And Jani also wants to get this in, but he doesn't really want to
> spend more effort on a system that can't be merged.
> 
> So sphinx/rst y/n? Jon, is that ok with you from the doc maintainer pov?

My recommendation is to start with reST-markup if you are 
writing new docs from scratch. Workflows like the .tmpl one
can be added to the kernel build process step by step and
there is no need to drop the DocBook-XML process. Every author
should be free to decide by himself, when it is time to
migrate his DocBook sources into a reST building process.

I'am new to the kernel, my aim is to support the doc maintainer
(contact me), e.g. to migrate existing DocBooks to reST,
elaborate (build) procedures for improved reST support
within the kernel sources and to give recommendation to 
infrastructures.

@Jonathan: I know, you have no time right now. If it is OK
for you, I elaborate all these reST stuff within my POC
at github (this will take some time). Later, if you have
time, we can merge the made experience and tools to the
kernel build process .. is that okay for you?

-- Markus --


> 
> Cheers, Daniel
> 
> On Wed, Apr 27, 2016 at 4:28 PM, Grant Likely  
> wrote:
>> On Tue, Apr 12, 2016 at 4:46 PM, Jonathan Corbet  wrote:
>>> On Fri, 8 Apr 2016 17:12:27 +0200
>>> Markus Heiser  wrote:
>>> 
 motivated by this MT, I implemented a toolchain to migrate the kernel’s
 DocBook XML documentation to reST markup.
 
 It converts 99% of the docs well ... to gain an impression how
 kernel-docs could benefit from, visit my sphkerneldoc project page
 on github:
 
  http://return42.github.io/sphkerneldoc/
>>> 
>>> So I've obviously been pretty quiet on this recently.  Apologies...I've
>>> been dealing with an extended death-in-the-family experience, and there is
>>> still a fair amount of cleanup to be done.
>>> 
>>> Looking quickly at this work, it seems similar to the results I got.  But
>>> there's a lot of code there that came from somewhere?  I'd put together a
>>> fairly simple conversion using pandoc and a couple of short sed scripts;
>>> is there a reason for a more complex solution?
>>> 
>>> Thanks for looking into this, anyway; I hope to be able to focus more on
>>> it shortly.
>> 
>> Hi Jon,
>> 
>> Thanks for digging into this. FWIW, here is my $0.02. I've been
>> working on restarting the devicetree specification, and after looking
>> at both reStructuredText and Asciidoc(tor) I thought I liked the
>> Asciidoc markup better, so chose that. I 

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[tiffany lin]

Hi Hans,

On Wed, 2016-05-04 at 10:25 +0200, Hans Verkuil wrote:
> 
> On 05/04/2016 10:19 AM, tiffany lin wrote:
> > Hi Hans,
> > 
> > On Wed, 2016-05-04 at 09:32 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> On 05/03/2016 12:11 PM, Tiffany Lin wrote:
> >>> ==
> >>>  Introduction
> >>> ==
> >>>
> >>> The purpose of this series is to add the driver for video codec hw 
> >>> embedded in the Mediatek's MT8173 SoCs.
> >>> Mediatek Video Codec is able to handle video encoding of in a range of 
> >>> formats.
> >>>
> >>> This patch series also include VPU driver. Mediatek Video Codec driver 
> >>> rely on VPU driver to load,
> >>> communicate with VPU.
> >>>
> >>> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI 
> >>> both have been merged in v4.6-rc1.
> >>> This patch series need [PATCH v15 8/8] memory: mtk-smi: export 
> >>> mtk_smi_larb_get/put[1] to build as module
> >>>
> >>> [1]http://lists.infradead.org/pipermail/linux-mediatek/2016-April/005173.html
> >>>
> >>> ==
> >>>  Device interface
> >>> ==
> >>>
> >>> In principle the driver bases on v4l2 memory-to-memory framework:
> >>> it provides a single video node and each opened file handle gets its own 
> >>> private context with separate
> >>> buffer queues. Each context consist of 2 buffer queues: OUTPUT (for 
> >>> source buffers, i.e. raw video
> >>> frames) and CAPTURE (for destination buffers, i.e. encoded video frames).
> >>>
> >>> ==
> >>>  VPU (Video Processor Unit)
> >>> ==
> >>> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> >>> It is able to handle video decoding/encoding in a range of formats.
> >>> The driver provides with VPU firmware download, memory management and the 
> >>> communication interface between CPU and VPU.
> >>> For VPU initialization, it will create virtual memory for CPU access and 
> >>> physical address for VPU hw device access. 
> >>> When a decode/encode instance opens a device node, vpu driver will 
> >>> download vpu firmware to the device.
> >>> A decode/encode instant will decode/encode a frame using VPU interface to 
> >>> interrupt vpu to handle decoding/encoding jobs.
> >>>
> >>> Please have a look at the code and comments will be very much appreciated.
> >>>
> >>> Change in v10:
> >>> 1. Fix smatch/sparse error message
> >>> 2. Add depends on ARM || ARM64 and MTK_IOMMU in Kconfig
> >>
> >> I don't like the ARM or ARM64 dependency since that makes COMPILE_TEST 
> >> harder.
> >>
> >> I removed it here and for the VPU and everything still compiles fine with
> >> sparse and smatch. So I'll drop those dependencies.
> >>
> >> Why is the MTK_IOMMU dependency needed? Just curious.
> >>
> > This is because we need MTK_IOMMU module to get dma continuous memory
> > for HW.
> > 
> >> Note that sparse still complains about this:
> >>
> >> media-git/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:261:24: 
> >> warning: incorrect type in assignment (different base types)
> >>
> >> I think this code should be rewritten. Something like this would work
> >> (if I understand the code correctly):
> >>
> >> u32 tag = (bs_hdr_len << 5) | 0x10 | not_key;
> >>
> >> ac_tag[0] = tag & 0xff;
> >> ac_tag[1] = (tag >> 8) & 0xff;
> >> ac_tag[2] = (tag >> 16) & 0xff;
> >>
> >> It's perhaps a bit more verbose, but a lot easier to understand.
> >>
> > 
> >> I'm accepting this driver but I'll remove the ARM || ARM64 dependency. Can
> >> you post a follow-up patch for this sparse warning?
> >>
> > 
> > Got it. We will provide a patch to fix this.
> > I was curious why my sparse do not show this warning.
> > Is there any parameter I need to set except C=1?
> 
> I'm running it with these parameters: C=2 CF="-D__CHECK_ENDIAN__"
> 
> I suspect it is the CHECK_ENDIAN flag that does it.
> 
Got it, thanks for the information.

best regards,
Tiffany
> Regards,
> 
>   Hans


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.7] Various fixes

[Hans Verkuil]

The following changes since commit 68af062b5f38510dc96635314461c6bbe1dbf2fe:

  Merge tag 'v4.6-rc6' into patchwork (2016-05-02 07:48:23 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.7d

for you to fetch changes up to 416997d02013936b65c9d7a3d05d2030027fac0c:

  media: vb2-dma-contig: configure DMA max segment size properly (2016-05-04 
11:08:13 +0200)


Hans Verkuil (1):
  v4l2-ioctl.c: improve cropcap compatibility code

Ismael Luceno (1):
  solo6x10: Set FRAME_BUF_SIZE to 200KB

Marek Szyprowski (1):
  media: vb2-dma-contig: configure DMA max segment size properly

 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c |  7 +--
 drivers/media/v4l2-core/v4l2-ioctl.c   | 70 
+++---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 53 
+++--
 3 files changed, 99 insertions(+), 31 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] media: vb2-dma-contig: configure DMA max segment size properly

[Marek Szyprowski]

This patch lets vb2-dma-contig memory allocator to configure DMA max
segment size properly for the client device. Setting it is needed to let
DMA-mapping subsystem to create a single, contiguous mapping in DMA
address space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes
of operations).

Signed-off-by: Marek Szyprowski 
Acked-by: Sakari Ailus 
---
Hello,

This patch is a follow-up of my previous attempts to let Exynos
multimedia devices to work properly with shared buffers when IOMMU is
enabled:
1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html
2. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316
3. https://patchwork.linuxtv.org/patch/30870/

As sugested by Hans, configuring DMA max segment size should be done by
videobuf2-dma-contig module instead of requiring all device drivers to
do it on their own.

Here is some backgroud why this is done in videobuf2-dc not in the
respective generic bus code:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html

Best regards,
Marek Szyprowski

changelog:
v4:
- rebased onto media master tree
- call vb2_dc_set_max_seg_size after allocating vb2 buf object

v3:
- added FIXME note about possible memory leak

v2:
- fixes typos and other language issues in the comments

v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 53 +-
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 5361197f3e57..6291842a889f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -448,6 +448,42 @@ static void vb2_dc_put_userptr(void *buf_priv)
 }
 
 /*
+ * To allow mapping the scatter-list into a single chunk in the DMA
+ * address space, the device is required to have the DMA max segment
+ * size parameter set to a value larger than the buffer size. Otherwise,
+ * the DMA-mapping subsystem will split the mapping into max segment
+ * size chunks. This function increases the DMA max segment size
+ * parameter to let DMA-mapping map a buffer as a single chunk in DMA
+ * address space.
+ * This code assumes that the DMA-mapping subsystem will merge all
+ * scatterlist segments if this is really possible (for example when
+ * an IOMMU is available and enabled).
+ * Ideally, this parameter should be set by the generic bus code, but it
+ * is left with the default 64KiB value due to historical litmiations in
+ * other subsystems (like limited USB host drivers) and there no good
+ * place to set it to the proper value. It is done here to avoid fixing
+ * all the vb2-dc client drivers.
+ *
+ * FIXME: the allocated dma_params structure is leaked because there
+ * is completely no way to determine when to free it (dma_params might have
+ * been also already allocated by the bus code). However in typical
+ * use cases this function will be called for platform devices, which are
+ * not hot-plugged and exist all the time in the target system.
+ */
+static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size)
+{
+   if (!dev->dma_parms) {
+   dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   if (dma_get_max_seg_size(dev) < size)
+   return dma_set_max_seg_size(dev, size);
+
+   return 0;
+}
+
+/*
  * For some kind of reserved memory there might be no struct page available,
  * so all that can be done to support such 'pages' is to try to convert
  * pfn to dma address or at the last resort just assume that
@@ -509,6 +545,10 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned 
long vaddr,
if (!buf)
return ERR_PTR(-ENOMEM);
 
+   ret = vb2_dc_set_max_seg_size(conf->dev, PAGE_ALIGN(size + PAGE_SIZE));
+   if (!ret)
+   goto fail_buf;
+
buf->dev = conf->dev;
buf->dma_dir = dma_dir;
 
@@ -682,6 +722,7 @@ static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct 
dma_buf *dbuf,
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
struct dma_buf_attachment *dba;
+   int ret;
 
if (dbuf->size < size)
return ERR_PTR(-EFAULT);
@@ -690,13 +731,17 @@ static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct 
dma_buf *dbuf,
if (!buf)
return ERR_PTR(-ENOMEM);
 
+   ret = vb2_dc_set_max_seg_size(conf->dev, PAGE_ALIGN(size));
+   if (!ret)
+   goto fail_buf;
+
buf->dev = conf->dev;
/* create attachment for the dmabuf with the user device */
dba = dma_buf_attach(dbuf, buf->dev);
if (IS_ERR(dba)) {
  

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

[Marek Szyprowski]

Hi Hans


On 2016-05-04 10:32, Hans Verkuil wrote:

Hi Marek,

On 05/04/2016 10:28 AM, Marek Szyprowski wrote:

Hi Hans,


On 2016-05-04 10:22, Hans Verkuil wrote:

Hi Marek,

On 05/02/2016 12:59 PM, Marek Szyprowski wrote:

This patch lets vb2-dma-contig memory allocator to configure DMA max
segment size properly for the client device. Setting it is needed to let
DMA-mapping subsystem to create a single, contiguous mapping in DMA
address space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes
of operations).

Signed-off-by: Marek Szyprowski 
---
Hello,

This patch is a follow-up of my previous attempts to let Exynos
multimedia devices to work properly with shared buffers when IOMMU is
enabled:
1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html
2. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316
3. https://patchwork.linuxtv.org/patch/30870/

As sugested by Hans, configuring DMA max segment size should be done by
videobuf2-dma-contig module instead of requiring all device drivers to
do it on their own.

Here is some backgroud why this is done in videobuf2-dc not in the
respective generic bus code:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html

Best regards,
Marek Szyprowski

changelog:
v3:
- added FIXME note about possible memory leak

v2:
- fixes typos and other language issues in the comments

v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690
---
   drivers/media/v4l2-core/videobuf2-dma-contig.c | 45 
++
   1 file changed, 45 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 461ae55eaa98..2ca7e798f394 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -443,6 +443,42 @@ static void vb2_dc_put_userptr(void *buf_priv)
   }
   
   /*

+ * To allow mapping the scatter-list into a single chunk in the DMA
+ * address space, the device is required to have the DMA max segment
+ * size parameter set to a value larger than the buffer size. Otherwise,
+ * the DMA-mapping subsystem will split the mapping into max segment
+ * size chunks. This function increases the DMA max segment size
+ * parameter to let DMA-mapping map a buffer as a single chunk in DMA
+ * address space.
+ * This code assumes that the DMA-mapping subsystem will merge all
+ * scatterlist segments if this is really possible (for example when
+ * an IOMMU is available and enabled).
+ * Ideally, this parameter should be set by the generic bus code, but it
+ * is left with the default 64KiB value due to historical litmiations in
+ * other subsystems (like limited USB host drivers) and there no good
+ * place to set it to the proper value. It is done here to avoid fixing
+ * all the vb2-dc client drivers.
+ *
+ * FIXME: the allocated dma_params structure is leaked because there
+ * is completely no way to determine when to free it (dma_params might have
+ * been also already allocated by the bus code). However in typical
+ * use cases this function will be called for platform devices, which are
+ * not how-plugged and exist all the time in the target system.
+ */
+static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size)
+{
+   if (!dev->dma_parms) {
+   dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   if (dma_get_max_seg_size(dev) < size)
+   return dma_set_max_seg_size(dev, size);
+
+   return 0;
+}
+
+/*
* For some kind of reserved memory there might be no struct page available,
* so all that can be done to support such 'pages' is to try to convert
* pfn to dma address or at the last resort just assume that
@@ -499,6 +535,10 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
return ERR_PTR(-EINVAL);
}
   
+	ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size + PAGE_SIZE));

Huh? Against which kernel do you compile? The get_userptr prototype is different
from the latest mainline kernel. Specifically, dev is now conf->dev.

I prepared it on top of your 'context3' branch, as you requested not to
use the
allocator context related functions, which best suit for this purpose.

That's not quite what I meant, sorry for the confusion. My reference to the
context3 branch was just that: to show upcoming changes and why it was not a
good idea to call this function from the context allocate/free functions. Since
those will disappear.

The context3 branch isn't for 4.7 (too late for that), but I want to get it
in early in the 4.8 cycle.

So just base this patch on the latest media_tree master.


I will send a version based on media tree in a few minutes.

Best regards
--
Marek 

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

[Hans Verkuil]

Hi Marek,

On 05/04/2016 10:28 AM, Marek Szyprowski wrote:
> Hi Hans,
> 
> 
> On 2016-05-04 10:22, Hans Verkuil wrote:
>> Hi Marek,
>>
>> On 05/02/2016 12:59 PM, Marek Szyprowski wrote:
>>> This patch lets vb2-dma-contig memory allocator to configure DMA max
>>> segment size properly for the client device. Setting it is needed to let
>>> DMA-mapping subsystem to create a single, contiguous mapping in DMA
>>> address space. This is essential for all devices, which use dma-contig
>>> videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes
>>> of operations).
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> ---
>>> Hello,
>>>
>>> This patch is a follow-up of my previous attempts to let Exynos
>>> multimedia devices to work properly with shared buffers when IOMMU is
>>> enabled:
>>> 1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html
>>> 2. 
>>> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316
>>> 3. https://patchwork.linuxtv.org/patch/30870/
>>>
>>> As sugested by Hans, configuring DMA max segment size should be done by
>>> videobuf2-dma-contig module instead of requiring all device drivers to
>>> do it on their own.
>>>
>>> Here is some backgroud why this is done in videobuf2-dc not in the
>>> respective generic bus code:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html
>>>
>>> Best regards,
>>> Marek Szyprowski
>>>
>>> changelog:
>>> v3:
>>> - added FIXME note about possible memory leak
>>>
>>> v2:
>>> - fixes typos and other language issues in the comments
>>>
>>> v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690
>>> ---
>>>   drivers/media/v4l2-core/videobuf2-dma-contig.c | 45 
>>> ++
>>>   1 file changed, 45 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
>>> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> index 461ae55eaa98..2ca7e798f394 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> @@ -443,6 +443,42 @@ static void vb2_dc_put_userptr(void *buf_priv)
>>>   }
>>>   
>>>   /*
>>> + * To allow mapping the scatter-list into a single chunk in the DMA
>>> + * address space, the device is required to have the DMA max segment
>>> + * size parameter set to a value larger than the buffer size. Otherwise,
>>> + * the DMA-mapping subsystem will split the mapping into max segment
>>> + * size chunks. This function increases the DMA max segment size
>>> + * parameter to let DMA-mapping map a buffer as a single chunk in DMA
>>> + * address space.
>>> + * This code assumes that the DMA-mapping subsystem will merge all
>>> + * scatterlist segments if this is really possible (for example when
>>> + * an IOMMU is available and enabled).
>>> + * Ideally, this parameter should be set by the generic bus code, but it
>>> + * is left with the default 64KiB value due to historical litmiations in
>>> + * other subsystems (like limited USB host drivers) and there no good
>>> + * place to set it to the proper value. It is done here to avoid fixing
>>> + * all the vb2-dc client drivers.
>>> + *
>>> + * FIXME: the allocated dma_params structure is leaked because there
>>> + * is completely no way to determine when to free it (dma_params might have
>>> + * been also already allocated by the bus code). However in typical
>>> + * use cases this function will be called for platform devices, which are
>>> + * not how-plugged and exist all the time in the target system.
>>> + */
>>> +static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size)
>>> +{
>>> +   if (!dev->dma_parms) {
>>> +   dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
>>> +   if (!dev->dma_parms)
>>> +   return -ENOMEM;
>>> +   }
>>> +   if (dma_get_max_seg_size(dev) < size)
>>> +   return dma_set_max_seg_size(dev, size);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +/*
>>>* For some kind of reserved memory there might be no struct page 
>>> available,
>>>* so all that can be done to support such 'pages' is to try to convert
>>>* pfn to dma address or at the last resort just assume that
>>> @@ -499,6 +535,10 @@ static void *vb2_dc_get_userptr(struct device *dev, 
>>> unsigned long vaddr,
>>> return ERR_PTR(-EINVAL);
>>> }
>>>   
>>> +   ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size + PAGE_SIZE));
>> Huh? Against which kernel do you compile? The get_userptr prototype is 
>> different
>> from the latest mainline kernel. Specifically, dev is now conf->dev.
> 
> I prepared it on top of your 'context3' branch, as you requested not to 
> use the
> allocator context related functions, which best suit for this purpose.

That's not quite what I meant, sorry for the confusion. My reference to the
context3 branch was just that: to show upcoming changes and why it was not a
good idea to call this function from 

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

[Marek Szyprowski]

Hi Hans,


On 2016-05-04 10:22, Hans Verkuil wrote:

Hi Marek,

On 05/02/2016 12:59 PM, Marek Szyprowski wrote:

This patch lets vb2-dma-contig memory allocator to configure DMA max
segment size properly for the client device. Setting it is needed to let
DMA-mapping subsystem to create a single, contiguous mapping in DMA
address space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes
of operations).

Signed-off-by: Marek Szyprowski 
---
Hello,

This patch is a follow-up of my previous attempts to let Exynos
multimedia devices to work properly with shared buffers when IOMMU is
enabled:
1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html
2. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316
3. https://patchwork.linuxtv.org/patch/30870/

As sugested by Hans, configuring DMA max segment size should be done by
videobuf2-dma-contig module instead of requiring all device drivers to
do it on their own.

Here is some backgroud why this is done in videobuf2-dc not in the
respective generic bus code:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html

Best regards,
Marek Szyprowski

changelog:
v3:
- added FIXME note about possible memory leak

v2:
- fixes typos and other language issues in the comments

v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690
---
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 45 ++
  1 file changed, 45 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 461ae55eaa98..2ca7e798f394 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -443,6 +443,42 @@ static void vb2_dc_put_userptr(void *buf_priv)
  }
  
  /*

+ * To allow mapping the scatter-list into a single chunk in the DMA
+ * address space, the device is required to have the DMA max segment
+ * size parameter set to a value larger than the buffer size. Otherwise,
+ * the DMA-mapping subsystem will split the mapping into max segment
+ * size chunks. This function increases the DMA max segment size
+ * parameter to let DMA-mapping map a buffer as a single chunk in DMA
+ * address space.
+ * This code assumes that the DMA-mapping subsystem will merge all
+ * scatterlist segments if this is really possible (for example when
+ * an IOMMU is available and enabled).
+ * Ideally, this parameter should be set by the generic bus code, but it
+ * is left with the default 64KiB value due to historical litmiations in
+ * other subsystems (like limited USB host drivers) and there no good
+ * place to set it to the proper value. It is done here to avoid fixing
+ * all the vb2-dc client drivers.
+ *
+ * FIXME: the allocated dma_params structure is leaked because there
+ * is completely no way to determine when to free it (dma_params might have
+ * been also already allocated by the bus code). However in typical
+ * use cases this function will be called for platform devices, which are
+ * not how-plugged and exist all the time in the target system.
+ */
+static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size)
+{
+   if (!dev->dma_parms) {
+   dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   if (dma_get_max_seg_size(dev) < size)
+   return dma_set_max_seg_size(dev, size);
+
+   return 0;
+}
+
+/*
   * For some kind of reserved memory there might be no struct page available,
   * so all that can be done to support such 'pages' is to try to convert
   * pfn to dma address or at the last resort just assume that
@@ -499,6 +535,10 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
return ERR_PTR(-EINVAL);
}
  
+	ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size + PAGE_SIZE));

Huh? Against which kernel do you compile? The get_userptr prototype is different
from the latest mainline kernel. Specifically, dev is now conf->dev.


I prepared it on top of your 'context3' branch, as you requested not to 
use the

allocator context related functions, which best suit for this purpose.


+   if (!ret)
+   return ERR_PTR(ret);
+
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);

I'd move the vb2_dc_set_max_seg_size call to after the buf is allocated. Since 
this call
has side-effects I would only call it when it is really needed.


OKay.




@@ -675,10 +715,15 @@ static void *vb2_dc_attach_dmabuf(struct device *dev, 
struct dma_buf *dbuf,
  {
struct vb2_dc_buf *buf;
struct dma_buf_attachment *dba;
+   int ret;
  
  	if (dbuf->size < size)

return ERR_PTR(-EFAULT);
  
+	ret = 

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[Hans Verkuil]

On 05/04/2016 10:19 AM, tiffany lin wrote:
> Hi Hans,
> 
> On Wed, 2016-05-04 at 09:32 +0200, Hans Verkuil wrote:
>> Hi Tiffany,
>>
>> On 05/03/2016 12:11 PM, Tiffany Lin wrote:
>>> ==
>>>  Introduction
>>> ==
>>>
>>> The purpose of this series is to add the driver for video codec hw embedded 
>>> in the Mediatek's MT8173 SoCs.
>>> Mediatek Video Codec is able to handle video encoding of in a range of 
>>> formats.
>>>
>>> This patch series also include VPU driver. Mediatek Video Codec driver rely 
>>> on VPU driver to load,
>>> communicate with VPU.
>>>
>>> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI 
>>> both have been merged in v4.6-rc1.
>>> This patch series need [PATCH v15 8/8] memory: mtk-smi: export 
>>> mtk_smi_larb_get/put[1] to build as module
>>>
>>> [1]http://lists.infradead.org/pipermail/linux-mediatek/2016-April/005173.html
>>>
>>> ==
>>>  Device interface
>>> ==
>>>
>>> In principle the driver bases on v4l2 memory-to-memory framework:
>>> it provides a single video node and each opened file handle gets its own 
>>> private context with separate
>>> buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source 
>>> buffers, i.e. raw video
>>> frames) and CAPTURE (for destination buffers, i.e. encoded video frames).
>>>
>>> ==
>>>  VPU (Video Processor Unit)
>>> ==
>>> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
>>> It is able to handle video decoding/encoding in a range of formats.
>>> The driver provides with VPU firmware download, memory management and the 
>>> communication interface between CPU and VPU.
>>> For VPU initialization, it will create virtual memory for CPU access and 
>>> physical address for VPU hw device access. 
>>> When a decode/encode instance opens a device node, vpu driver will download 
>>> vpu firmware to the device.
>>> A decode/encode instant will decode/encode a frame using VPU interface to 
>>> interrupt vpu to handle decoding/encoding jobs.
>>>
>>> Please have a look at the code and comments will be very much appreciated.
>>>
>>> Change in v10:
>>> 1. Fix smatch/sparse error message
>>> 2. Add depends on ARM || ARM64 and MTK_IOMMU in Kconfig
>>
>> I don't like the ARM or ARM64 dependency since that makes COMPILE_TEST 
>> harder.
>>
>> I removed it here and for the VPU and everything still compiles fine with
>> sparse and smatch. So I'll drop those dependencies.
>>
>> Why is the MTK_IOMMU dependency needed? Just curious.
>>
> This is because we need MTK_IOMMU module to get dma continuous memory
> for HW.
> 
>> Note that sparse still complains about this:
>>
>> media-git/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:261:24: 
>> warning: incorrect type in assignment (different base types)
>>
>> I think this code should be rewritten. Something like this would work
>> (if I understand the code correctly):
>>
>> u32 tag = (bs_hdr_len << 5) | 0x10 | not_key;
>>
>> ac_tag[0] = tag & 0xff;
>> ac_tag[1] = (tag >> 8) & 0xff;
>> ac_tag[2] = (tag >> 16) & 0xff;
>>
>> It's perhaps a bit more verbose, but a lot easier to understand.
>>
> 
>> I'm accepting this driver but I'll remove the ARM || ARM64 dependency. Can
>> you post a follow-up patch for this sparse warning?
>>
> 
> Got it. We will provide a patch to fix this.
> I was curious why my sparse do not show this warning.
> Is there any parameter I need to set except C=1?

I'm running it with these parameters: C=2 CF="-D__CHECK_ENDIAN__"

I suspect it is the CHECK_ENDIAN flag that does it.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

[Hans Verkuil]

Hi Marek,

On 05/02/2016 12:59 PM, Marek Szyprowski wrote:
> This patch lets vb2-dma-contig memory allocator to configure DMA max
> segment size properly for the client device. Setting it is needed to let
> DMA-mapping subsystem to create a single, contiguous mapping in DMA
> address space. This is essential for all devices, which use dma-contig
> videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes
> of operations).
> 
> Signed-off-by: Marek Szyprowski 
> ---
> Hello,
> 
> This patch is a follow-up of my previous attempts to let Exynos
> multimedia devices to work properly with shared buffers when IOMMU is
> enabled:
> 1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html
> 2. 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316
> 3. https://patchwork.linuxtv.org/patch/30870/
> 
> As sugested by Hans, configuring DMA max segment size should be done by
> videobuf2-dma-contig module instead of requiring all device drivers to
> do it on their own.
> 
> Here is some backgroud why this is done in videobuf2-dc not in the
> respective generic bus code:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html
> 
> Best regards,
> Marek Szyprowski
> 
> changelog:
> v3:
> - added FIXME note about possible memory leak
> 
> v2:
> - fixes typos and other language issues in the comments
> 
> v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 45 
> ++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 461ae55eaa98..2ca7e798f394 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -443,6 +443,42 @@ static void vb2_dc_put_userptr(void *buf_priv)
>  }
>  
>  /*
> + * To allow mapping the scatter-list into a single chunk in the DMA
> + * address space, the device is required to have the DMA max segment
> + * size parameter set to a value larger than the buffer size. Otherwise,
> + * the DMA-mapping subsystem will split the mapping into max segment
> + * size chunks. This function increases the DMA max segment size
> + * parameter to let DMA-mapping map a buffer as a single chunk in DMA
> + * address space.
> + * This code assumes that the DMA-mapping subsystem will merge all
> + * scatterlist segments if this is really possible (for example when
> + * an IOMMU is available and enabled).
> + * Ideally, this parameter should be set by the generic bus code, but it
> + * is left with the default 64KiB value due to historical litmiations in
> + * other subsystems (like limited USB host drivers) and there no good
> + * place to set it to the proper value. It is done here to avoid fixing
> + * all the vb2-dc client drivers.
> + *
> + * FIXME: the allocated dma_params structure is leaked because there
> + * is completely no way to determine when to free it (dma_params might have
> + * been also already allocated by the bus code). However in typical
> + * use cases this function will be called for platform devices, which are
> + * not how-plugged and exist all the time in the target system.
> + */
> +static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size)
> +{
> + if (!dev->dma_parms) {
> + dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
> + if (!dev->dma_parms)
> + return -ENOMEM;
> + }
> + if (dma_get_max_seg_size(dev) < size)
> + return dma_set_max_seg_size(dev, size);
> +
> + return 0;
> +}
> +
> +/*
>   * For some kind of reserved memory there might be no struct page available,
>   * so all that can be done to support such 'pages' is to try to convert
>   * pfn to dma address or at the last resort just assume that
> @@ -499,6 +535,10 @@ static void *vb2_dc_get_userptr(struct device *dev, 
> unsigned long vaddr,
>   return ERR_PTR(-EINVAL);
>   }
>  
> + ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size + PAGE_SIZE));

Huh? Against which kernel do you compile? The get_userptr prototype is different
from the latest mainline kernel. Specifically, dev is now conf->dev.

> + if (!ret)
> + return ERR_PTR(ret);
> +
>   buf = kzalloc(sizeof *buf, GFP_KERNEL);
>   if (!buf)
>   return ERR_PTR(-ENOMEM);

I'd move the vb2_dc_set_max_seg_size call to after the buf is allocated. Since 
this call
has side-effects I would only call it when it is really needed.

> @@ -675,10 +715,15 @@ static void *vb2_dc_attach_dmabuf(struct device *dev, 
> struct dma_buf *dbuf,
>  {
>   struct vb2_dc_buf *buf;
>   struct dma_buf_attachment *dba;
> + int ret;
>  
>   if (dbuf->size < size)
>   return ERR_PTR(-EFAULT);
>  
> + ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size));

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[tiffany lin]

Hi Hans,

On Wed, 2016-05-04 at 09:32 +0200, Hans Verkuil wrote:
> Hi Tiffany,
> 
> On 05/03/2016 12:11 PM, Tiffany Lin wrote:
> > ==
> >  Introduction
> > ==
> > 
> > The purpose of this series is to add the driver for video codec hw embedded 
> > in the Mediatek's MT8173 SoCs.
> > Mediatek Video Codec is able to handle video encoding of in a range of 
> > formats.
> > 
> > This patch series also include VPU driver. Mediatek Video Codec driver rely 
> > on VPU driver to load,
> > communicate with VPU.
> > 
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI 
> > both have been merged in v4.6-rc1.
> > This patch series need [PATCH v15 8/8] memory: mtk-smi: export 
> > mtk_smi_larb_get/put[1] to build as module
> > 
> > [1]http://lists.infradead.org/pipermail/linux-mediatek/2016-April/005173.html
> > 
> > ==
> >  Device interface
> > ==
> > 
> > In principle the driver bases on v4l2 memory-to-memory framework:
> > it provides a single video node and each opened file handle gets its own 
> > private context with separate
> > buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source 
> > buffers, i.e. raw video
> > frames) and CAPTURE (for destination buffers, i.e. encoded video frames).
> > 
> > ==
> >  VPU (Video Processor Unit)
> > ==
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding in a range of formats.
> > The driver provides with VPU firmware download, memory management and the 
> > communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and 
> > physical address for VPU hw device access. 
> > When a decode/encode instance opens a device node, vpu driver will download 
> > vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU interface to 
> > interrupt vpu to handle decoding/encoding jobs.
> > 
> > Please have a look at the code and comments will be very much appreciated.
> > 
> > Change in v10:
> > 1. Fix smatch/sparse error message
> > 2. Add depends on ARM || ARM64 and MTK_IOMMU in Kconfig
> 
> I don't like the ARM or ARM64 dependency since that makes COMPILE_TEST harder.
> 
> I removed it here and for the VPU and everything still compiles fine with
> sparse and smatch. So I'll drop those dependencies.
> 
> Why is the MTK_IOMMU dependency needed? Just curious.
> 
This is because we need MTK_IOMMU module to get dma continuous memory
for HW.

> Note that sparse still complains about this:
> 
> media-git/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:261:24: 
> warning: incorrect type in assignment (different base types)
> 
> I think this code should be rewritten. Something like this would work
> (if I understand the code correctly):
> 
> u32 tag = (bs_hdr_len << 5) | 0x10 | not_key;
> 
> ac_tag[0] = tag & 0xff;
> ac_tag[1] = (tag >> 8) & 0xff;
> ac_tag[2] = (tag >> 16) & 0xff;
> 
> It's perhaps a bit more verbose, but a lot easier to understand.
> 

> I'm accepting this driver but I'll remove the ARM || ARM64 dependency. Can
> you post a follow-up patch for this sparse warning?
> 

Got it. We will provide a patch to fix this.
I was curious why my sparse do not show this warning.
Is there any parameter I need to set except C=1?

best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> 
> > 
> > VPU part
> > 1. Fix smatch/sparse error message
> > 2. Use totalram_pages instead of max_pfn to decide VPU 4GB mode
> > 3. Protect variable "fw_load"
> > 4. Add depends on ARM || ARM64 in Kconfig
> > 
> > Change in v9:
> > 1. Rename idx in mtk_vcodec_ctx to id and curr_max_idx in mtk_vcodec_dev to 
> > id_counter.
> > 2. Refine fops_vcodec_open
> > 
> > VPU part
> > Merge Julia Lawall's fixes to "[PATCH v9 2/8] [media] VPU: mediatek: 
> > support Mediatek VPU"
> > 1.[PATCH] VPU: mediatek: fix simple_open.cocci warnings 
> > 2.[PATCH] VPU: mediatek: fix platform_no_drv_owner.cocci warnings
> > 
> > Change in v8:
> > 1. Refine indentation
> > 2. Refine colorspace information process vidioc_try_fmt_vid_out_mplane
> > 3. Remove instance_mask in mtk_vcodec_dev, use curr_max_idx for instance 
> > index
> > 4. Use kzalloc to allocate ctx
> > 5. Refine fops_vcodec_open
> > 
> > VPU Part
> > 1. Refine vpu_load_firmware
> > 
> > Change in v7:
> > 1. Rebase against the master branch of git://linuxtv.org/media_tree.git
> > 2. Add ycbcr_enc, quantization and xfer_func in try_fmt, g_fmt, s_fmt
> > 3. Merge h264_enc and vp8_enc to venc directory
> > 
> > Change in v6:
> > 1. Add synchronization access protect between irq handler and work thread
> > 2. Add DMA_ATTR_ALLOC_SINGLE_PAGES support
> > 3. S_FMT will return coded_width, coded_height, so user space could 
> > allocate correct size memory that HW required
> > 4. merge h264/vp8 enc ap and md32 ipi msg
> > 5. separate h264/vp8 enc gop_size and 

Re: [PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

[Hans Verkuil]

Hi Ismael,

On 04/30/2016 05:17 AM, Ismael Luceno wrote:
> Additionally, now it specifies which channels it's showing.
> 
> Signed-off-by: Ismael Luceno 
> ---
>  drivers/media/pci/solo6x10/solo6x10-v4l2.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c 
> b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
> index 721ff53..935c1b6 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
> @@ -386,26 +386,17 @@ static int solo_querycap(struct file *file, void  *priv,
>  static int solo_enum_ext_input(struct solo_dev *solo_dev,
>  struct v4l2_input *input)
>  {
> - static const char * const dispnames_1[] = { "4UP" };
> - static const char * const dispnames_2[] = { "4UP-1", "4UP-2" };
> - static const char * const dispnames_5[] = {
> - "4UP-1", "4UP-2", "4UP-3", "4UP-4", "16UP"
> - };
> - const char * const *dispnames;
> -
> - if (input->index >= (solo_dev->nr_chans + solo_dev->nr_ext))
> - return -EINVAL;
> -
> - if (solo_dev->nr_ext == 5)
> - dispnames = dispnames_5;
> - else if (solo_dev->nr_ext == 2)
> - dispnames = dispnames_2;
> - else
> - dispnames = dispnames_1;
> + int ext = input->index - solo_dev->nr_chans;
> + unsigned int nup, first;
>  
> - snprintf(input->name, sizeof(input->name), "Multi %s",
> -  dispnames[input->index - solo_dev->nr_chans]);
> + if (ext >= solo_dev->nr_ext)
> + return -EINVAL;
>  
> + nup   = (ext == 4) ? 16 : 4;
> + first = (ext & 3) << 2;
> + snprintf(input->name, sizeof(input->name),
> +  "Multi %d-up (cameras %d-%d)",
> +  nup, first + 1, first + nup);

Shouldn't this be: nup, first + 1, nup);

Now it displays cameras as 1-5, 2-6, 3-7, 4-8 if I am not mistaken.

Regards,

Hans

>   return 0;
>  }
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.7] Add support for MT8173 video encoder

[Hans Verkuil]

>From the cover letter of the patch series (https://lkml.org/lkml/2016/5/3/279):

The purpose of this series is to add the driver for video codec hw embedded in 
the Mediatek's MT8173 SoCs.
Mediatek Video Codec is able to handle video encoding of in a range of formats.

This patch series also include VPU driver. Mediatek Video Codec driver rely on 
VPU driver to load,
communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
have been merged in v4.6-rc1.
This patch series need [PATCH v15 8/8] memory: mtk-smi: export 
mtk_smi_larb_get/put[1] to build as module

[1]http://lists.infradead.org/pipermail/linux-mediatek/2016-April/005173.html

Mauro, please note this dependency, so if this is in time to get merged for 
4.7, then
the pull request for this has to wait until that mtk-smi patch is merged first.

Regards,

Hans


The following changes since commit 68af062b5f38510dc96635314461c6bbe1dbf2fe:

  Merge tag 'v4.6-rc6' into patchwork (2016-05-02 07:48:23 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git mtenc

for you to fetch changes up to 7aebdc45d79743eedddbfd2a7d488ff1f6ee93b9:

  arm64: dts: mediatek: Add Video Encoder for MT8173 (2016-05-04 09:33:50 +0200)


Andrew-CT Chen (3):
  dt-bindings: Add a binding for Mediatek Video Processor
  VPU: mediatek: support Mediatek VPU
  arm64: dts: mediatek: Add node for Mediatek Video Processor Unit

Tiffany Lin (5):
  dt-bindings: Add a binding for Mediatek Video Encoder
  vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
  vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
  vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
  arm64: dts: mediatek: Add Video Encoder for MT8173

 Documentation/devicetree/bindings/media/mediatek-vcodec.txt |   59 +++
 Documentation/devicetree/bindings/media/mediatek-vpu.txt|   31 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   62 +++
 drivers/media/platform/Kconfig  |   30 ++
 drivers/media/platform/Makefile |4 +
 drivers/media/platform/mtk-vcodec/Makefile  |   19 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h  |  338 

 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c  | 1288 
+
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h  |   58 +++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |  454 
++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c   |  137 +++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h   |   26 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c |   54 +++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h |   27 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c |   94 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h |   87 +
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c   |  679 

 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c|  481 
+++
 drivers/media/platform/mtk-vcodec/venc_drv_base.h   |   62 +++
 drivers/media/platform/mtk-vcodec/venc_drv_if.c |  113 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.h |  163 
 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h|  210 ++
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c |  237 
 drivers/media/platform/mtk-vcodec/venc_vpu_if.h |   61 +++
 drivers/media/platform/mtk-vpu/Makefile |3 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c|  950 
+
 drivers/media/platform/mtk-vpu/mtk_vpu.h|  162 
 27 files changed, 5889 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
 create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
 create mode 100644 

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[Hans Verkuil]

Hi Tiffany,

On 05/03/2016 12:11 PM, Tiffany Lin wrote:
> ==
>  Introduction
> ==
> 
> The purpose of this series is to add the driver for video codec hw embedded 
> in the Mediatek's MT8173 SoCs.
> Mediatek Video Codec is able to handle video encoding of in a range of 
> formats.
> 
> This patch series also include VPU driver. Mediatek Video Codec driver rely 
> on VPU driver to load,
> communicate with VPU.
> 
> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
> have been merged in v4.6-rc1.
> This patch series need [PATCH v15 8/8] memory: mtk-smi: export 
> mtk_smi_larb_get/put[1] to build as module
> 
> [1]http://lists.infradead.org/pipermail/linux-mediatek/2016-April/005173.html
> 
> ==
>  Device interface
> ==
> 
> In principle the driver bases on v4l2 memory-to-memory framework:
> it provides a single video node and each opened file handle gets its own 
> private context with separate
> buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source 
> buffers, i.e. raw video
> frames) and CAPTURE (for destination buffers, i.e. encoded video frames).
> 
> ==
>  VPU (Video Processor Unit)
> ==
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding in a range of formats.
> The driver provides with VPU firmware download, memory management and the 
> communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and 
> physical address for VPU hw device access. 
> When a decode/encode instance opens a device node, vpu driver will download 
> vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU interface to 
> interrupt vpu to handle decoding/encoding jobs.
> 
> Please have a look at the code and comments will be very much appreciated.
> 
> Change in v10:
> 1. Fix smatch/sparse error message
> 2. Add depends on ARM || ARM64 and MTK_IOMMU in Kconfig

I don't like the ARM or ARM64 dependency since that makes COMPILE_TEST harder.

I removed it here and for the VPU and everything still compiles fine with
sparse and smatch. So I'll drop those dependencies.

Why is the MTK_IOMMU dependency needed? Just curious.

Note that sparse still complains about this:

media-git/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:261:24: warning: 
incorrect type in assignment (different base types)

I think this code should be rewritten. Something like this would work
(if I understand the code correctly):

u32 tag = (bs_hdr_len << 5) | 0x10 | not_key;

ac_tag[0] = tag & 0xff;
ac_tag[1] = (tag >> 8) & 0xff;
ac_tag[2] = (tag >> 16) & 0xff;

It's perhaps a bit more verbose, but a lot easier to understand.

I'm accepting this driver but I'll remove the ARM || ARM64 dependency. Can
you post a follow-up patch for this sparse warning?

Regards,

Hans


> 
> VPU part
> 1. Fix smatch/sparse error message
> 2. Use totalram_pages instead of max_pfn to decide VPU 4GB mode
> 3. Protect variable "fw_load"
> 4. Add depends on ARM || ARM64 in Kconfig
> 
> Change in v9:
> 1. Rename idx in mtk_vcodec_ctx to id and curr_max_idx in mtk_vcodec_dev to 
> id_counter.
> 2. Refine fops_vcodec_open
> 
> VPU part
> Merge Julia Lawall's fixes to "[PATCH v9 2/8] [media] VPU: mediatek: support 
> Mediatek VPU"
> 1.[PATCH] VPU: mediatek: fix simple_open.cocci warnings 
> 2.[PATCH] VPU: mediatek: fix platform_no_drv_owner.cocci warnings
> 
> Change in v8:
> 1. Refine indentation
> 2. Refine colorspace information process vidioc_try_fmt_vid_out_mplane
> 3. Remove instance_mask in mtk_vcodec_dev, use curr_max_idx for instance index
> 4. Use kzalloc to allocate ctx
> 5. Refine fops_vcodec_open
> 
> VPU Part
> 1. Refine vpu_load_firmware
> 
> Change in v7:
> 1. Rebase against the master branch of git://linuxtv.org/media_tree.git
> 2. Add ycbcr_enc, quantization and xfer_func in try_fmt, g_fmt, s_fmt
> 3. Merge h264_enc and vp8_enc to venc directory
> 
> Change in v6:
> 1. Add synchronization access protect between irq handler and work thread
> 2. Add DMA_ATTR_ALLOC_SINGLE_PAGES support
> 3. S_FMT will return coded_width, coded_height, so user space could allocate 
> correct size memory that HW required
> 4. merge h264/vp8 enc ap and md32 ipi msg
> 5. separate h264/vp8 enc gop_size and intra_period handle
> 6. remove sizeimage relative code in work buffer function
> 7. Refine makefile to build as an module
> 8. Code clean up
> 
> VPU Part
> 1. export symbols for building VPU as an module
> 2. change function from "wait_event_interruptible_timeout" to 
> "wait_event_timeout" since
>CPU needs to wait for ACK from VPU even if it was interrupted by a signal
> 
> v4l2-compliance test output:
> localhost Encode # ./v4l2-compliance -d /dev/video1
> Driver Info:
> Driver name   : mtk-vcodec-enc
> Card type : platform:mt8173
>