Re: [PATCH v3 00/23] Unrestricted media entity ID range support

[Mauro Carvalho Chehab]

Em Sun, 27 Dec 2015 19:11:36 +0200
Laurent Pinchart <laurent.pinch...@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote:
> > Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu:
> > > On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> > > > This is the third version of the unrestricted media entity ID range
> > > > support set. I've taken Mauro's comments into account and fixed a number
> > > > of bugs as well (omap3isp memory leak and omap4iss stream start).
> > > 
> > > Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
> > > test the OMAP4 ISS with these patches?
> > > 
> > > Thanks.
> > 
> > Sakari,
> > 
> > Testing with OMAP4 is not possible. The driver is broken: it doesn't
> > support DT, and the required pdata definition is missing.
> 
> What do you mean by missing ? struct iss_platform_data is defined in 
> include/media/omap4iss.h.
> 

As this driver is not DT, the platform data has to be part of the Kernel
tree for the driver to work. However, there are no board-specific data nor
any documentation about how to do that inside the Kernel tree. 
That means  that this driver won't work without some OOT patch.

So, on its current state, it is broken. It should either be
converted to DT and have the needed board definitions added to the
existing dts files or be removed.

Another possible approach would be to have a patch like the one
Javier and I tried to craft by adding the needed platform data
into arch/arm/mach-omap2/pdata-quirks.c, but I guess it is better
to just use DT instead.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 00/23] Unrestricted media entity ID range support

[Mauro Carvalho Chehab]

Em Wed, 16 Dec 2015 16:03:01 +0200
Sakari Ailus  escreveu:

> Hi Javier,
> 
> On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> > This is the third version of the unrestricted media entity ID range
> > support set. I've taken Mauro's comments into account and fixed a number
> > of bugs as well (omap3isp memory leak and omap4iss stream start).
> 
> Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
> test the OMAP4 ISS with these patches?
> 
> Thanks.
> 

Sakari,

Testing with OMAP4 is not possible. The driver is broken: it doesn't
support DT, and the required pdata definition is missing.

Both Javier and I tried to fix it in the last couple days, in order to test
it with a PandaBoard. We came with the enclosed patch, but it is still 
incomplete. Based on what's written on this e-mail:
 https://www.mail-archive.com/linux-media@vger.kernel.org/msg89247.html

It seems that this is an already known issue.

So, I'm considering this driver as BROKEN. Not much sense on doing any
tests on it, while this doesn't get fixed.

Regards,
Mauro

PS.: With the enclosed patch, I got this error:
[0.267639] platform omap4iss: failed to claim resource 2

But, even if I comment out the platform code that returns this error,
there are still other missing things:
[7.131622] omap4iss omap4iss: Unable to get iss_fck clock info
[7.137878] omap4iss omap4iss: Unable to get clocks

---

ARM: add a pdata quirks for OMAP4 panda camera

This is a hack to make it to believe that the pandaboard
has a camera.


diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 1dfe34654c43..998bb6936dc0 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -36,6 +36,8 @@
 #include "soc.h"
 #include "hsmmc.h"
 
+#include "../../../drivers/staging/media/omap4iss/iss.h"
+
 struct pdata_init {
const char *compatible;
void (*fn)(void);
@@ -408,6 +410,124 @@ static void __init t410_abort_init(void)
 }
 #endif
 
+#ifdef CONFIG_ARCH_OMAP4
+
+static struct resource panda_iss_resource[] = {
+   {
+   .start = 0x5200,
+   .end = 0x5200 + 0x100,
+   .name = "top",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52001000,
+   .end = 0x52001000 + 0x170,
+   .name = "csi2_a_regs1",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52001170,
+   .end = 0x52001170 + 0x020,
+   .name = "camerarx_core1",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52001400,
+   .end = 0x52001400 + 0x170,
+   .name = "csi2_b_regs1",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52001570,
+   .end = 0x52001570 + 0x020,
+   .name = "camerarx_core2",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52002000,
+   .end = 0x52002000 + 0x200,
+   .name = "bte",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x5201,
+   .end = 0x5201 + 0x0a0,
+   .name = "isp_sys1",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52010400,
+   .end = 0x52010400 + 0x400,
+   .name = "isp_resizer",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52010800,
+   .end = 0x52010800 + 0x800,
+   .name = "isp_ipipe",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52011000,
+   .end = 0x52011000 + 0x200,
+   .name = "isp_isif",
+   .flags = IORESOURCE_MEM,
+   }, {
+   .start = 0x52011200,
+   .end = 0x52011200 + 0x080,
+   .name = "isp_ipipeif",
+   .flags = IORESOURCE_MEM,
+   }
+};
+
+static struct i2c_board_info panda_camera_i2c_device = {
+   I2C_BOARD_INFO("smia", 0x10),
+};
+
+static struct iss_subdev_i2c_board_info panda_camera_subdevs[] = {
+   {
+   .board_info = _camera_i2c_device,
+   .i2c_adapter_id = 3,
+   },
+};
+
+static struct iss_v4l2_subdevs_group iss_subdevs[] = {
+   {
+   .subdevs = panda_camera_subdevs,
+   .interface = ISS_INTERFACE_CSI2A_PHY1,
+   .bus = {
+   .csi2 = {
+   .lanecfg = {
+   .clk = {
+   .pol = 0,
+   .pos = 2,
+   },
+   .data[0] = {
+   .pol = 0,
+   .pos = 

Re: [PATCH v2 3/3] [media] include/media: move platform_data to linux/platform_data/media

[Mauro Carvalho Chehab]

Em Mon, 16 Nov 2015 13:28:10 +0100
Arnd Bergmann  escreveu:

> I think we can also move some of the existing platform data headers to the 
> same
> place, but that could be a separate patch:
> 
> $ git grep linux/platform_data drivers/media/
> drivers/media/platform/coda/coda-common.c:#include 
> 
> drivers/media/platform/soc_camera/mx2_camera.c:#include 
> 
> drivers/media/platform/soc_camera/mx3_camera.c:#include 
> 
> drivers/media/platform/soc_camera/mx3_camera.c:#include 
> 
> drivers/media/platform/soc_camera/pxa_camera.c:#include 
> 
> drivers/media/platform/soc_camera/rcar_vin.c:#include 
> 

Fair enough. Just sent a separate patch to address that.

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

[PATCH v2 3/3] [media] include/media: move platform_data to linux/platform_data/media

[Mauro Carvalho Chehab]

Let's not mix platform_data headers with the core headers. Instead, let's
create a subdir at linux/platform_data and move the headers to that
common place, adding it to MAINTAINERS.

The headers were moved with:
mkdir include/linux/platform_data/media/; git mv 
include/media/gpio-ir-recv.h include/media/ir-rx51.h include/media/mmp-camera.h 
include/media/omap1_camera.h include/media/omap4iss.h include/media/s5p_hdmi.h 
include/media/si4713.h include/media/sii9234.h include/media/smiapp.h 
include/media/soc_camera.h include/media/soc_camera_platform.h 
include/media/timb_radio.h include/media/timb_video.h 
include/linux/platform_data/media/

And the references fixed with this script:
MAIN_DIR="linux/platform_data/"
PREV_DIR="media/"
DIRS="media/"

echo "Checking affected files" >&2
for i in $DIRS; do
for j in $(find include/$MAIN_DIR/$i -type f -name '*.h'); do
 n=`basename $j`
git grep -l $n
done
done|sort|uniq >files && (
echo "Handling files..." >&2;
echo "for i in \$(cat files|grep -v Documentation); do cat \$i | \\";
(
cd include/$MAIN_DIR;
for j in $DIRS; do
for i in $(ls $j); do
echo "perl -ne 's,(include 
[\\\"\\<])$PREV_DIR($i)([\\\"\\>]),\1$MAIN_DIR$j\2\3,; print \$_' |\\";
done;
done;
echo "cat > a && mv a \$i; done";
);
echo "Handling documentation..." >&2;
echo "for i in MAINTAINERS \$(cat files); do cat \$i | \\";
(
cd include/$MAIN_DIR;
for j in $DIRS; do
for i in $(ls $j); do
echo "  perl -ne 
's,include/$PREV_DIR($i)\b,include/$MAIN_DIR$j\1,; print \$_' |\\";
    done;
done;
echo "cat > a && mv a \$i; done"
);
) >script && . ./script

Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
 Documentation/video4linux/omap4_camera.txt| 2 +-
 Documentation/video4linux/si4713.txt  | 2 +-
 MAINTAINERS   | 1 +
 arch/arm/mach-omap1/include/mach/camera.h | 2 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c  | 4 ++--
 arch/arm/plat-samsung/devs.c  | 2 +-
 arch/sh/boards/mach-ap325rxa/setup.c  | 2 +-
 drivers/media/platform/marvell-ccic/mmp-driver.c  | 2 +-
 drivers/media/platform/s5p-tv/hdmi_drv.c  | 2 +-
 drivers/media/platform/s5p-tv/sii9234_drv.c   | 2 +-
 drivers/media/platform/soc_camera/omap1_camera.c  | 2 +-
 drivers/media/platform/soc_camera/soc_camera_platform.c   | 2 +-
 drivers/media/platform/timblogiw.c| 2 +-
 drivers/media/radio/radio-timb.c  | 2 +-
 drivers/media/radio/si4713/radio-usb-si4713.c | 2 +-
 drivers/media/radio/si4713/si4713.h   | 2 +-
 drivers/media/rc/gpio-ir-recv.c   | 2 +-
 drivers/media/rc/ir-rx51.c| 2 +-
 drivers/mfd/timberdale.c  | 4 ++--
 drivers/staging/media/omap4iss/iss.h  | 2 +-
 drivers/staging/media/omap4iss/iss_csiphy.h   | 2 +-
 include/{ => linux/platform_data}/media/gpio-ir-recv.h| 1 -
 include/{ => linux/platform_data}/media/ir-rx51.h | 0
 include/{ => linux/platform_data}/media/mmp-camera.h  | 0
 include/{ => linux/platform_data}/media/omap1_camera.h| 0
 include/{ => linux/platform_data}/media/omap4iss.h| 0
 include/{ => linux/platform_data}/media/s5p_hdmi.h| 1 -
 include/{ => linux/platform_data}/media/si4713.h  | 2 +-
 include/{ => linux/platform_data}/media/sii9234.h | 0
 include/{ => linux/platform_data}/media/soc_camera_platform.h | 0
 include/{ => linux/platform_data}/media/timb_radio.h  | 0
 include/{ => linux/platform_data}/media/timb_video.h  | 0
 32 files changed, 24 insertions(+), 25 deletions(-)
 rename include/{ => linux/platform_data}/media/gpio-ir-recv.h (99%)
 rename include/{ => linux/platform_data}/media/ir-rx51.h (100%)
 rename include/{ => linux/platform_data}/media/mmp-camera.h (100%)
 rename include/{ => linux/platform_data}/media/omap1_camera.h (100%)
 rename include/{ => linux/platform_data}/media/omap4iss.h (100%)
 rename include/{ => linux/platform_data}/media/s5p_

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Mauro Carvalho Chehab]

Em Wed, 11 Nov 2015 21:26:31 +0100
Arnd Bergmann <a...@arndb.de> escreveu:

> On Wednesday 11 November 2015 15:14:48 Mauro Carvalho Chehab wrote:
> >  rename include/media/{ => platform}/exynos-fimc.h (100%)
> >  rename include/media/{ => platform}/mmp-camera.h (100%)
> >  rename include/media/{ => platform}/omap1_camera.h (100%)
> >  rename include/media/{ => platform}/omap4iss.h (100%)
> >  rename include/media/{ => platform}/s3c_camif.h (100%)
> >  rename include/media/{ => platform}/s5p_hdmi.h (100%)
> >  rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
> >  rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
> >  rename include/media/{ => platform}/sh_vou.h (100%)
> >  rename include/media/{ => platform}/sii9234.h (100%)
> >  rename include/media/{ => platform}/soc_camera.h (100%)
> >  rename include/media/{ => platform}/soc_camera_platform.h (98%)
> >  rename include/media/{ => platform}/soc_mediabus.h (100%)
> 
> This still seems to be a mix of various things. Some of these are interfaces
> between drivers, while others declare a foo_platform_data structure that
> is used to interface between platform code and the driver.

True. What about calling putting those driver interfaces under
include/media/drv-intf? That also helps moving the headers for other
non-platform drivers too.

> 
> I think the latter should go into include/linux/platform_data/media/*.h 
> instead.

Agreed.

Please see the enclosed patch:


Subject: [PATCH] [media] include/media: move platform driver headers to a
 separate dirs

Let's not mix headers used by the core with those headers that
are needed by some specific platform drivers or by platform data.

This patch was made via this script:
mkdir include/media/platform mkdir include/media/platform_data
(cd include/media/; git mv $(grep -l platform_data *.h|grep -v v4l2) 
platform_data/)
for i in include/media/*.h; do n=`basename $i`;  (for j in $(git grep 
-l $n); do dirname $j; done)|sort|uniq|grep -ve '^.$' > list; num=$(wc -l 
list|cut -d' ' -f1); if [ $num == 1 ]; then if [ "`grep platform list`" != "" 
]; then git mv $i include/media/drv-intf; fi; fi; done
git mv include/media/exynos* include/media/soc_* include/media/sh_* 
include/media/drv-intf/

And some headers were manually adjusted. Then, this script fixed the
address for those new headers:

for i in $(find include/media/ -type f); do n=`basename $i`; git grep 
-l $n; done|sort|uniq >files && (echo "for i in \$(cat files); do cat \$i | 
\\"; cd include/media; for j in platform/ platform_data/; do for i in $(ls $j); 
do echo "perl -ne 's,(include [\\\"\\<]media/)($i)([\\\"\\>]),\1$j\2\3,; print 
\$_' |\\"; done; done; echo "cat > a && mv a \$i; done") >script&& . ./script

Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>

---

 arch/arm/mach-imx/mach-imx27_visstrim_m10.c  | 2 +-
 arch/arm/mach-imx/mach-mx27_3ds.c| 2 +-
 arch/arm/mach-imx/mach-mx31_3ds.c| 2 +-
 arch/arm/mach-imx/mach-mx35_3ds.c| 2 +-
 arch/arm/mach-imx/mach-pcm037.c  | 2 +-
 arch/arm/mach-imx/mx31moboard-marxbot.c  | 2 +-
 arch/arm/mach-imx/mx31moboard-smartbot.c | 2 +-
 arch/arm/mach-omap1/board-ams-delta.c| 2 +-
 arch/arm/mach-omap1/include/mach/camera.h| 2 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c | 4 ++--
 arch/arm/mach-pxa/em-x270.c  | 2 +-
 arch/arm/mach-pxa/ezx.c  | 2 +-
 arch/arm/mach-pxa/mioa701.c  | 2 +-
 arch/arm/mach-pxa/palmz72.c  | 2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
 arch/arm/mach-shmobile/board-bockw.c | 2 +-
 arch/arm/plat-samsung/devs.c | 2 +-
 arch/sh/boards/mach-ap325rxa/setup.c | 6 +++---
 arch/sh/boards/mach-ecovec24/setup.c | 6 +++---
 arch/sh/boards/mach-kfr2r09/setup.c  | 4 ++--
 arch/sh/boards/mach-migor/setup.c| 4 ++--
 arch/sh/boards/mach-se/7724/setup.c  | 4 ++--
 drivers/media/common/cx2341x.c   | 2 +-
 drivers/media/common/saa7146/saa7146_core.c  | 2 +-
 drivers/media/common/saa7146/saa7146_fops.c  | 2 +-
 drivers/media/common/saa7146/saa7146_hlp.c   | 2 +-
 drivers/media/common/saa7146/saa7146_i2c.c   | 2 +-
 drivers/media/common/saa7146/saa7146_vbi.c   | 2 +-
 drivers/media/common/saa7146/saa7146_video.c | 2 +-
 

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Mauro Carvalho Chehab]

Em Fri, 13 Nov 2015 22:31:15 +0100
Arnd Bergmann <a...@arndb.de> escreveu:

> On Friday 13 November 2015 17:13:41 Mauro Carvalho Chehab wrote:
> > Em Wed, 11 Nov 2015 21:26:31 +0100
> > Arnd Bergmann <a...@arndb.de> escreveu:
> > 
> 
> >  include/media/{ => drv-intf}/cx2341x.h   | 0
> >  include/media/{ => drv-intf}/cx25840.h   | 0
> >  include/media/{ => drv-intf}/exynos-fimc.h   | 0
> >  include/media/{ => drv-intf}/msp3400.h   | 0
> >  include/media/{ => drv-intf}/s3c_camif.h | 0
> >  include/media/{ => drv-intf}/saa7146.h   | 0
> >  include/media/{ => drv-intf}/saa7146_vv.h| 2 +-
> >  include/media/{ => drv-intf}/sh_mobile_ceu.h | 0
> >  include/media/{ => drv-intf}/sh_mobile_csi2.h| 0
> >  include/media/{ => drv-intf}/sh_vou.h| 0
> >  include/media/{ => drv-intf}/si476x.h| 0
> >  include/media/{ => drv-intf}/soc_mediabus.h  | 0
> >  include/media/{ => drv-intf}/tea575x.h   | 0
> >  include/media/i2c/tw9910.h   | 2 +-
> >  include/media/{ => platform_data}/gpio-ir-recv.h | 0
> >  include/media/{ => platform_data}/ir-rx51.h  | 0
> >  include/media/{ => platform_data}/mmp-camera.h   | 0
> >  include/media/{ => platform_data}/omap1_camera.h | 0
> >  include/media/{ => platform_data}/omap4iss.h | 0
> >  include/media/{ => platform_data}/s5p_hdmi.h | 0
> >  include/media/{ => platform_data}/si4713.h   | 0
> >  include/media/{ => platform_data}/sii9234.h  | 0
> >  include/media/{ => platform_data}/smiapp.h   | 0
> >  include/media/{ => platform_data}/soc_camera.h   | 0
> >  include/media/{ => platform_data}/soc_camera_platform.h  | 2 +-
> >  include/media/{ => platform_data}/timb_radio.h   | 0
> >  include/media/{ => platform_data}/timb_video.h   | 0
> >  sound/pci/es1968.c   | 2 +-
> >  sound/pci/fm801.c| 2 +-
> >  155 files changed, 158 insertions(+), 158 deletions(-)
> 
> As Geert said, include/linux/platform_data/media/ would be nicer for
> consistency with other subsystems.

OK! I have a new series of patches almost ready. I'll be sending it
tomorrow, after addressing your concerns.

> 
> > diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
> > b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
> > index ede2bdbb5dd5..44ba1f28bb34 100644
> > --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
> > +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
> > @@ -33,7 +33,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> 
> This looks like a mistake: the header contains the string 'platform_data',
> but it is not actually a platform data header file in the sense
> that it defines the interface between platform and driver.
> 
> Maybe soc_camera.h is important enough to still leave it as a core
> file in the existing location? Or possibly a separate directory for
> media/soc_camera/*.h

Ok, I'll fix it. 

> 
> > @@ -24,7 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  
> >  #include "cx25840-core.h"
> 
> For this case, I think the original patch to move it into include/media/i2c
> was more logical as it mirrors the file structure. I was mainly talking
> about the platform_data being different from the rest.

cx25840 is not (always) an I2C. On most devices, this is actually an IP
block inside the bridge chipset. 

That's why I didn't include it on patch 1/1. There's one thing to
notice about that, though: while most of the header is describing
the driver interface, it does contain one platform_data in the end:

/* pvr150_workaround activates a workaround for a hardware bug that is
   present in Hauppauge PVR-150 (and possibly PVR-500) cards that have
   certain NTSC tuners (tveeprom tuner model numbers 85, 99 and 112). The
   audio autodetect fails on some channels for these models and the workaround
   is to select the audio standard explicitly. Many thanks to Hauppauge for
   providing this information.
   This platform data only needs to be supplied by the ivtv driver. */
struct cx25840_platform_data {
int pvr150_workaround;
};

While we might split it, I guess it is not worth, specially since
I don't think we'll see any new driver using it.

Also, this is actually a hack used only by the ivtv driver.

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

[PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Mauro Carvalho Chehab]

Let's not mix headers used by the core with those headers that
are needed by some specific platform drivers.

This patch was made via this script:

mkdir include/media/platform
for i in include/media/*.h; do n=`basename $i`;  (for j in $(git grep 
-l $n); do dirname $j; done)|sort|uniq|grep -ve '^.$' > list; num=$(wc -l 
list|cut -d' ' -f1); if [ $num == 1 ]; then if [ "`grep platform list`" != "" 
]; then git mv $i include/media/platform; fi; fi; done
git mv include/media/exynos* include/media/s5p* include/media/omap* 
include/media/soc_* include/media/sh_include/media/platform/
for i in $(find include/media/ -type f); do n=`basename $i`; git grep 
-l $n; done|sort|uniq >files && (echo "for i in \$(cat files); do cat \$i | 
\\"; cd include/media; for j in rc/ i2c/ platform/ common_drv/; do for i in 
$(ls $j); do echo "perl -ne 's,(include 
[\\\"\\<]media/)($i)([\\\"\\>]),\1$j\2\3,; print \$_' |\\"; done; done; echo 
"cat > a && mv a \$i; done") >script && . ./script

Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>

 rename include/media/{ => platform}/exynos-fimc.h (100%)
 rename include/media/{ => platform}/mmp-camera.h (100%)
 rename include/media/{ => platform}/omap1_camera.h (100%)
 rename include/media/{ => platform}/omap4iss.h (100%)
 rename include/media/{ => platform}/s3c_camif.h (100%)
 rename include/media/{ => platform}/s5p_hdmi.h (100%)
 rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
 rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
 rename include/media/{ => platform}/sh_vou.h (100%)
 rename include/media/{ => platform}/sii9234.h (100%)
 rename include/media/{ => platform}/soc_camera.h (100%)
 rename include/media/{ => platform}/soc_camera_platform.h (98%)
 rename include/media/{ => platform}/soc_mediabus.h (100%)

diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index ede2bdbb5dd5..99bd64c69a4f 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c 
b/arch/arm/mach-imx/mach-mx27_3ds.c
index 9ef4640f3660..74d073fd4fa6 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c 
b/arch/arm/mach-imx/mach-mx31_3ds.c
index 65a0dc06a97c..5e1b9c335103 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c 
b/arch/arm/mach-imx/mach-mx35_3ds.c
index 7e315f00648d..355b9521f7f0 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -45,7 +45,7 @@
 
 #include 
 
-#include 
+#include 
 
 #include "3ds_debugboard.h"
 #include "common.h"
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index 6d879417db49..02cc07b0a687 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mx31moboard-marxbot.c 
b/arch/arm/mach-imx/mx31moboard-marxbot.c
index 2e895a82a6eb..79ae360a9c8f 100644
--- a/arch/arm/mach-imx/mx31moboard-marxbot.c
+++ b/arch/arm/mach-imx/mx31moboard-marxbot.c
@@ -24,7 +24,7 @@
 
 #include 
 
-#include 
+#include 
 
 #include "common.h"
 #include "devices-imx31.h"
diff --git a/arch/arm/mach-imx/mx31moboard-smartbot.c 
b/arch/arm/mach-imx/mx31moboard-smartbot.c
index 89fc35a64448..00bd100df69a 100644
--- a/arch/arm/mach-imx/mx31moboard-smartbot.c
+++ b/arch/arm/mach-imx/mx31moboard-smartbot.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "board-mx31moboard.h"
 #include "common.h"
diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..7adef38f27c2 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/include/mach/camera.h 
b/arch/arm/mach-omap1/include/mach/camera.h
index 847d00f0bb0a..0df5ebf85de6 100644
--- a/arch/arm/mach-omap1/include/mach/camera.h
+++ b/arch/arm/mach-omap1/include/mach/camera.h
@@ -1,7 +1,7 @@
 #ifndef __ASM_ARCH_CAMERA_H_
 #define __ASM_ARCH_CAMERA_H_
 
-#include 
+#include 
 
 void omap1_camera_init(void *);
 
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-

Re: [PATCH] media: i2c/adp1653: devicetree support for adp1653

[Mauro Carvalho Chehab]

Em Wed, 3 Dec 2014 22:46:41 +0100
Pavel Machek pa...@ucw.cz escreveu:

 
 We are moving to device tree support on OMAP3, but that currently
 breaks ADP1653 driver. This adds device tree support, plus required
 documentation.
 
 Signed-off-by: Pavel Machek pa...@ucw.cz

Please be sure to check your patch with checkpatch. There are several
issues on it:

WARNING: DT compatible string adi,adp1653 appears un-documented -- check 
./Documentation/devicetree/bindings/
#78: FILE: arch/arm/boot/dts/omap3-n900.dts:572:
+   compatible = adi,adp1653;

ERROR: trailing whitespace
#136: FILE: drivers/media/i2c/adp1653.c:332:
+^I^I^I$

ERROR: trailing whitespace
#159: FILE: drivers/media/i2c/adp1653.c:436:
+static int adp1653_of_init(struct i2c_client *client, struct adp1653_flash 
*flash, $

WARNING: line over 80 characters
#159: FILE: drivers/media/i2c/adp1653.c:436:
+static int adp1653_of_init(struct i2c_client *client, struct adp1653_flash 
*flash, 

ERROR: trailing statements should be on next line
#177: FILE: drivers/media/i2c/adp1653.c:454:
+   if (!child) return -EINVAL;

WARNING: line over 80 characters
#178: FILE: drivers/media/i2c/adp1653.c:455:
+   if (of_property_read_u32(child, flash-timeout-microsec, val)) return 
-EINVAL;

ERROR: trailing statements should be on next line
#178: FILE: drivers/media/i2c/adp1653.c:455:
+   if (of_property_read_u32(child, flash-timeout-microsec, val)) return 
-EINVAL;

WARNING: line over 80 characters
#180: FILE: drivers/media/i2c/adp1653.c:457:
+   if (of_property_read_u32(child, flash-max-microamp, val)) return 
-EINVAL;

ERROR: trailing statements should be on next line
#180: FILE: drivers/media/i2c/adp1653.c:457:
+   if (of_property_read_u32(child, flash-max-microamp, val)) return 
-EINVAL;

ERROR: trailing statements should be on next line
#182: FILE: drivers/media/i2c/adp1653.c:459:
+   if (of_property_read_u32(child, max-microamp, val)) return -EINVAL;

ERROR: trailing statements should be on next line
#186: FILE: drivers/media/i2c/adp1653.c:463:
+   if (!child) return -EINVAL;

ERROR: trailing statements should be on next line
#187: FILE: drivers/media/i2c/adp1653.c:464:
+   if (of_property_read_u32(child, max-microamp, val)) return -EINVAL;

ERROR: trailing whitespace
#197: FILE: drivers/media/i2c/adp1653.c:474:
+^I^Idev_err(client-dev, Error getting GPIO\n); $

total: 9 errors, 4 warnings, 199 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
  scripts/cleanfile

 
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
 @@ -0,0 +1,38 @@
 +* Analog Devices ADP1653 flash LED driver
 +
 +Required Properties:
 +
 +  - compatible: Must contain one of the following
 +- adi,adp1653
 +
 +  - reg: I2C slave address
 +
 +  - gpios: References to the GPIO that controls the power for the chip.
 +
 +There are two led outputs available - flash and indicator. One led is
 +represented by one child node, nodes need to be named flash and 
 indicator.
 +
 +Required properties of the LED child node:
 +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 +
 +Required properties of the flash LED child node:
 +
 +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 +- flash-timeout-microsec : see 
 Documentation/devicetree/bindings/leds/common.txt
 +
 +Example:
 +
 +adp1653: led-controller@30 {
 +compatible = adi,adp1653;
 + reg = 0x30;
 +gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
 +
 + flash {
 +flash-timeout-microsec = 50;
 +flash-max-microamp = 32;
 +max-microamp = 5;
 + };
 +indicator {
 +max-microamp = 17500;
 + };
 +};
 diff --git a/arch/arm/boot/dts/omap3-n900.dts 
 b/arch/arm/boot/dts/omap3-n900.dts
 index cfddc3d..11d8afd 100644
 --- a/arch/arm/boot/dts/omap3-n900.dts
 +++ b/arch/arm/boot/dts/omap3-n900.dts
 @@ -560,6 +567,22 @@
  
   ti,usb-charger-detection = isp1704;
   };
 +
 + adp1653: led-controller@30 {
 + compatible = adi,adp1653;
 + reg = 0x30;
 + gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
 +
 + flash {
 + flash-timeout-microsec = 50;
 + flash-max-microamp = 32;
 + max-microamp = 5;
 + };
 +
 + indicator {
 + max-microamp = 17500;
 + };
 + };
  };
  
  i2c3 {
 diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
 index 873fe19..62601b2 100644
 --- a/drivers/media/i2c/adp1653.c
 +++ b/drivers/media/i2c/adp1653.c
 @@ -8,6 +8,7 @@
   * Contributors:
   *   Sakari Ailus sakari.ai...@iki.fi
   *   Tuukka Toivonen tuukka...@gmail.com
 + *  Pavel Machek pa...@ucw.cz
   *
   * This 

Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning

[Mauro Carvalho Chehab]

Em Thu, 04 Dec 2014 08:39:31 -0800
Tony Lindgren t...@atomide.com escreveu:

 * Felipe Balbi ba...@ti.com [141204 07:50]:
  Hi,
  
  On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
   On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
 commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
 si4713 platform data) updated board-rx51-peripherals.c
 so that si4713 could be easily used on DT boot, but
 it ended up introducing a build warning whenever
 si4713 isn't enabled.
 
 This patches fixes that warning:
 
 arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
   ‘rx51_si4713_platform_data’ defined but not used 
 [-Wunused-variable]
  static struct si4713_platform_data rx51_si4713_platform_data = {
 
 Cc: Sebastian Reichel s...@kernel.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Hans Verkuil hans.verk...@cisco.com
 Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
 Signed-off-by: Felipe Balbi ba...@ti.com

a gentle reminder on this one.

   
   Let me add my
   
   Acked-by: Arnd Bergmann a...@arndb.de
   
   You didn't say who you expect to pick up the patch. I assume Mauro
  
  patch author now decides who takes the patch ? That's new :-)

Well, for patches that cross subsystem boundaries, like this one,
the best is to give a hint about whom you expect to pick it.

In this specific case, as commit 68a3c04 is in my tree, the best is
to merge the patch on it, as the patch may not even apply at Tony's
tree.

  
   should take it because he took the patch that caused the problem,
   but he might not be aware that he should look at this now.
  
  He is in Cc, let's ask him :-)
 
 Best that this one goes in along with the other si4713 patches
 to avoid dependencies between trees:
 
 Acked-by: Tony Lindgren t...@atomide.com

Thanks! I'll merge it via my tree.

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

Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning

[Mauro Carvalho Chehab]

Em Thu, 04 Dec 2014 11:03:53 -0600
Felipe Balbi ba...@ti.com escreveu:

 Hi,
 
 On Thu, Dec 04, 2014 at 03:00:12PM -0200, Mauro Carvalho Chehab wrote:
  Em Thu, 04 Dec 2014 08:39:31 -0800
  Tony Lindgren t...@atomide.com escreveu:
  
   * Felipe Balbi ba...@ti.com [141204 07:50]:
Hi,

On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
 On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
  On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
   commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
   si4713 platform data) updated board-rx51-peripherals.c
   so that si4713 could be easily used on DT boot, but
   it ended up introducing a build warning whenever
   si4713 isn't enabled.
   
   This patches fixes that warning:
   
   arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
 ‘rx51_si4713_platform_data’ defined but not used 
   [-Wunused-variable]
static struct si4713_platform_data rx51_si4713_platform_data = {
   
   Cc: Sebastian Reichel s...@kernel.org
   Cc: Tony Lindgren t...@atomide.com
   Cc: Hans Verkuil hans.verk...@cisco.com
   Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
   Signed-off-by: Felipe Balbi ba...@ti.com
  
  a gentle reminder on this one.
  
 
 Let me add my
 
 Acked-by: Arnd Bergmann a...@arndb.de
 
 You didn't say who you expect to pick up the patch. I assume Mauro

patch author now decides who takes the patch ? That's new :-)
  
  Well, for patches that cross subsystem boundaries, like this one,
  the best is to give a hint about whom you expect to pick it.
  
  In this specific case, as commit 68a3c04 is in my tree, the best is
  to merge the patch on it, as the patch may not even apply at Tony's
  tree.
 
 pointing to the commit that caused the problem really isn't enough ? The
 commit short description (which is also on my commit log) clearly
 mentions [media].
 
 Anyway, I'll do that next time.

Ah, and please c/c linux-media ML next time, as I use patchwork there
to track patches for the media tree.

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

Re: [RFCv2 1/8] [media] si4713: switch to devm regulator API

[Mauro Carvalho Chehab]

Em Tue, 21 Oct 2014 17:07:00 +0200
Sebastian Reichel s...@kernel.org escreveu:

 This switches back to the normal regulator API (but use
 managed variant) in preparation for device tree support.

This patch broke compilation. Please be sure that none of the patches in
the series would break it, as otherwise git bisect would be broken.

Thanks,
Mauro

drivers/media/radio/si4713/si4713.c: In function 'si4713_powerup':
drivers/media/radio/si4713/si4713.c:369:10: error: 'struct si4713_device' has 
no member named 'supplies'
 
  ^
drivers/media/radio/si4713/si4713.c:370:35: error: 'struct si4713_device' has 
no member named 'supplies'
  if (sdev-vdd) {
   ^
drivers/media/radio/si4713/si4713.c:370:51: error: 'struct si4713_device' has 
no member named 'supply_data'
  if (sdev-vdd) {
   ^
drivers/media/radio/si4713/si4713.c:402:10: error: 'struct si4713_device' has 
no member named 'supplies'
   v4l2_dbg(1, debug, sdev-sd, Device in power up mode\n);
  ^
drivers/media/radio/si4713/si4713.c:403:36: error: 'struct si4713_device' has 
no member named 'supplies'
   sdev-power_state = POWER_ON;
^
drivers/media/radio/si4713/si4713.c:403:52: error: 'struct si4713_device' has 
no member named 'supply_data'
   sdev-power_state = POWER_ON;
^
drivers/media/radio/si4713/si4713.c: In function 'si4713_powerdown':
drivers/media/radio/si4713/si4713.c:435:11: error: 'struct si4713_device' has 
no member named 'supplies'
  int err;
   ^
drivers/media/radio/si4713/si4713.c:436:37: error: 'struct si4713_device' has 
no member named 'supplies'
  u8 resp[SI4713_PWDN_NRESP];
 ^
drivers/media/radio/si4713/si4713.c:437:16: error: 'struct si4713_device' has 
no member named 'supply_data'
 
^
drivers/media/radio/si4713/si4713.c: In function 'si4713_probe':
drivers/media/radio/si4713/si4713.c:1444:7: error: 'struct si4713_device' has 
no member named 'supplies'
 /* si4713_probe - probe for the device */
   ^
drivers/media/radio/si4713/si4713.c:1447:22: error: 'struct si4713_device' has 
no member named 'supplies'
 {
  ^
drivers/media/radio/si4713/si4713.c:1448:7: error: 'struct si4713_device' has 
no member named 'supply_data'
  struct si4713_device *sdev;
   ^
drivers/media/radio/si4713/si4713.c:1450:46: error: 'struct si4713_device' has 
no member named 'supplies'
  struct v4l2_ctrl_handler *hdl;
  ^
drivers/media/radio/si4713/si4713.c:1451:11: error: 'struct si4713_device' has 
no member named 'supply_data'
  int rval, i;
   ^
drivers/media/radio/si4713/si4713.c:1583:26: error: 'struct si4713_device' has 
no member named 'supplies'
 
  ^
drivers/media/radio/si4713/si4713.c:1583:42: error: 'struct si4713_device' has 
no member named 'supply_data'
 
  ^
drivers/media/radio/si4713/si4713.c: In function 'si4713_remove':
drivers/media/radio/si4713/si4713.c:1607:26: error: 'struct si4713_device' has 
no member named 'supplies'
   goto free_irq;
  ^
drivers/media/radio/si4713/si4713.c:1607:42: error: 'struct si4713_device' has 
no member named 'supply_data'
   goto free_irq;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 1/8] [media] si4713: switch to devm regulator API

[Mauro Carvalho Chehab]

Em Tue, 11 Nov 2014 18:59:31 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:

 Hi Mauro,
 
 On 11/11/2014 12:07 PM, Mauro Carvalho Chehab wrote:
  Em Tue, 21 Oct 2014 17:07:00 +0200
  Sebastian Reichel s...@kernel.org escreveu:
  
  This switches back to the normal regulator API (but use
  managed variant) in preparation for device tree support.
  
  This patch broke compilation. Please be sure that none of the patches in
  the series would break it, as otherwise git bisect would be broken.
 
 Weird, as reported by Sebastian, it works for me.

Weird. Not sure what happened here.

 
 However, after applying this patch I get these new warnings:
 
   CC  drivers/media/radio/si4713/radio-usb-si4713.o
 drivers/media/radio/si4713/si4713.c: In function ‘si4713_probe’:
 drivers/media/radio/si4713/si4713.c:1617:1: warning: label ‘free_gpio’ 
 defined but not used [-Wunused-label]
  free_gpio:
  ^
 drivers/media/radio/si4713/si4713.c:1451:12: warning: unused variable ‘i’ 
 [-Wunused-variable]
   int rval, i;
 ^
 
 So it's probably not a good idea to merge this patch anyway until this is 
 fixed.

Agreed. Also, v3 of this series apparently came after the pull request.

Regards,
Mauro


 Sebastian, can you fix these warnings and repost?
 
 Thanks!
 
   Hans
 
  
  Thanks,
  Mauro
  
  drivers/media/radio/si4713/si4713.c: In function 'si4713_powerup':
  drivers/media/radio/si4713/si4713.c:369:10: error: 'struct si4713_device' 
  has no member named 'supplies'
   
^
  drivers/media/radio/si4713/si4713.c:370:35: error: 'struct si4713_device' 
  has no member named 'supplies'
if (sdev-vdd) {
 ^
  drivers/media/radio/si4713/si4713.c:370:51: error: 'struct si4713_device' 
  has no member named 'supply_data'
if (sdev-vdd) {
 ^
  drivers/media/radio/si4713/si4713.c:402:10: error: 'struct si4713_device' 
  has no member named 'supplies'
 v4l2_dbg(1, debug, sdev-sd, Device in power up mode\n);
^
  drivers/media/radio/si4713/si4713.c:403:36: error: 'struct si4713_device' 
  has no member named 'supplies'
 sdev-power_state = POWER_ON;
  ^
  drivers/media/radio/si4713/si4713.c:403:52: error: 'struct si4713_device' 
  has no member named 'supply_data'
 sdev-power_state = POWER_ON;
  ^
  drivers/media/radio/si4713/si4713.c: In function 'si4713_powerdown':
  drivers/media/radio/si4713/si4713.c:435:11: error: 'struct si4713_device' 
  has no member named 'supplies'
int err;
 ^
  drivers/media/radio/si4713/si4713.c:436:37: error: 'struct si4713_device' 
  has no member named 'supplies'
u8 resp[SI4713_PWDN_NRESP];
   ^
  drivers/media/radio/si4713/si4713.c:437:16: error: 'struct si4713_device' 
  has no member named 'supply_data'
   
  ^
  drivers/media/radio/si4713/si4713.c: In function 'si4713_probe':
  drivers/media/radio/si4713/si4713.c:1444:7: error: 'struct si4713_device' 
  has no member named 'supplies'
   /* si4713_probe - probe for the device */
 ^
  drivers/media/radio/si4713/si4713.c:1447:22: error: 'struct si4713_device' 
  has no member named 'supplies'
   {
^
  drivers/media/radio/si4713/si4713.c:1448:7: error: 'struct si4713_device' 
  has no member named 'supply_data'
struct si4713_device *sdev;
 ^
  drivers/media/radio/si4713/si4713.c:1450:46: error: 'struct si4713_device' 
  has no member named 'supplies'
struct v4l2_ctrl_handler *hdl;
^
  drivers/media/radio/si4713/si4713.c:1451:11: error: 'struct si4713_device' 
  has no member named 'supply_data'
int rval, i;
 ^
  drivers/media/radio/si4713/si4713.c:1583:26: error: 'struct si4713_device' 
  has no member named 'supplies'
   
^
  drivers/media/radio/si4713/si4713.c:1583:42: error: 'struct si4713_device' 
  has no member named 'supply_data'
   
^
  drivers/media/radio/si4713/si4713.c: In function 'si4713_remove':
  drivers/media/radio/si4713/si4713.c:1607:26: error: 'struct si4713_device' 
  has no member named 'supplies'
 goto free_irq;
^
  drivers/media/radio/si4713/si4713.c:1607:42: error: 'struct si4713_device' 
  has no member named 'supply_data'
 goto free_irq;
  --
  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-omap 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] omap-dma: Allow compile-testing omap1_camera driver

[Mauro Carvalho Chehab]

Em Tue, 9 Sep 2014 15:41:58 +0100
Russell King - ARM Linux li...@arm.linux.org.uk escreveu:

 On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
  We want to be able to COMPILE_TEST the omap1_camera driver.
  It compiles fine, but it fails linkediting:
  
  ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] 
  undefined!
  ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] 
  undefined!
  ERROR: omap_dma_link_lch 
  [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
  ERROR: omap_set_dma_dest_burst_mode 
  [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
  ERROR: omap_set_dma_src_params 
  [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
  ERROR: omap_request_dma 
  [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
  ERROR: omap_set_dma_transfer_params 
  [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
  ERROR: omap_set_dma_dest_params 
  [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
  ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] 
  undefined!
  
  So, add some stub functions to avoid it.
 
 The real answer to this is to find someone who still uses it, and convert
 it to the DMA engine API.  If there's no users, the driver might as well
 be killed off.

Hmm... it seems that there are still several drivers still relying on
the functions declared at: omap-dma.h:

$ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if 
(m/extern\s\S+\s(.*)\(/)' funcs  git grep -f funcs -l
arch/arm/mach-omap1/pm.c
arch/arm/mach-omap2/pm24xx.c
arch/arm/plat-omap/dma.c
drivers/dma/omap-dma.c
drivers/media/platform/omap/omap_vout_vrfb.c
drivers/media/platform/omap3isp/isphist.c
drivers/media/platform/soc_camera/omap1_camera.c
drivers/mtd/onenand/omap2.c
drivers/usb/gadget/udc/omap_udc.c
drivers/usb/musb/tusb6010_omap.c
drivers/video/fbdev/omap/omapfb_main.c
include/linux/omap-dma.h

Perhaps we can remove the header and mark all the above as BROKEN.

If nobody fixes, we can strip all of them from the Kernel.

Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] omap-dma: Allow compile-testing omap1_camera driver

[Mauro Carvalho Chehab]

Em Tue, 09 Sep 2014 12:36:54 -0300
Mauro Carvalho Chehab m.che...@samsung.com escreveu:

 Em Tue, 9 Sep 2014 15:41:58 +0100
 Russell King - ARM Linux li...@arm.linux.org.uk escreveu:
 
  On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
   We want to be able to COMPILE_TEST the omap1_camera driver.
   It compiles fine, but it fails linkediting:
   
   ERROR: omap_stop_dma 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_start_dma 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_dma_link_lch 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_set_dma_dest_burst_mode 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_set_dma_src_params 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_request_dma 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_set_dma_transfer_params 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_set_dma_dest_params 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   ERROR: omap_free_dma 
   [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
   
   So, add some stub functions to avoid it.
  
  The real answer to this is to find someone who still uses it, and convert
  it to the DMA engine API.  If there's no users, the driver might as well
  be killed off.
 
 Hmm... it seems that there are still several drivers still relying on
 the functions declared at: omap-dma.h:
 
 $ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if 
 (m/extern\s\S+\s(.*)\(/)' funcs  git grep -f funcs -l
 arch/arm/mach-omap1/pm.c
 arch/arm/mach-omap2/pm24xx.c
 arch/arm/plat-omap/dma.c
 drivers/dma/omap-dma.c
 drivers/media/platform/omap/omap_vout_vrfb.c
 drivers/media/platform/omap3isp/isphist.c
 drivers/media/platform/soc_camera/omap1_camera.c
 drivers/mtd/onenand/omap2.c
 drivers/usb/gadget/udc/omap_udc.c
 drivers/usb/musb/tusb6010_omap.c
 drivers/video/fbdev/omap/omapfb_main.c
 include/linux/omap-dma.h
 
 Perhaps we can remove the header and mark all the above as BROKEN.
 
 If nobody fixes, we can strip all of them from the Kernel.

Are all the functions declared at omap-dma.h part of the
old DMA API that should be deprecated?

If so, it seems that the OMAP2 and OMAP3 also depends on this 
thing, as all the PM code for OMAP depends on the functions
declared inside omap-dma.h, and marking them as BROKEN
causes compilation to failure:

arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents':
:(.text+0x798): undefined reference to `omap3_restore_3630'
:(.text+0x7a8): undefined reference to `omap3_restore'
:(.text+0x7ac): undefined reference to `omap3_restore_es3'
arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context':
:(.text+0x925c): undefined reference to `omap_push_sram_idle'
arch/arm/mach-omap2/built-in.o: In function `option_set':
:(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable'
arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set':
:(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state'
arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get':
:(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state'
arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm':
:(.text+0xc7ec): undefined reference to `omap_sram_idle'
:(.text+0xc848): undefined reference to `pm34xx_errata'
arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late':
:(.init.text+0xf64): undefined reference to `omap2_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late':
:(.init.text+0x1024): undefined reference to `omap2_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap3_init_late':
:(.init.text+0x1248): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late':
:(.init.text+0x1264): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late':
:(.init.text+0x1280): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late':
:(.init.text+0x129c): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late':
:(.init.text+0x12b8): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o::(.init.text+0x12d4): more undefined references 
to `omap3_pm_init' follow

This was compiled with allmodconfig on arm, with COMPILE_TEST
disabled (a few sub-archs disabled too), to avoid spurious
unrelated compilation issues).

Am I missing something?

BTW, CONFIG_PM is auto-selected by ARCH_OMAP3.

And those are the functions that the OMAP3 code uses from omap-dma.h:

arch/arm/mach-omap2/pm34xx.c:92:2: error: implicit declaration of function 
‘omap_dma_global_context_save’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/pm34xx.c:103:2: error

Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Mauro Carvalho Chehab]

Hi Russell,

Em Mon, 30 Sep 2013 13:57:47 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 On 09/19/2013 11:44 PM, Russell King wrote:
  Replace the following sequence:
  
  dma_set_mask(dev, mask);
  dma_set_coherent_mask(dev, mask);
  
  with a call to the new helper dma_set_mask_and_coherent().
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 
 Acked-by: Hans Verkuil hans.verk...@cisco.com

Somehow, I lost your original post (I got unsubscribed on a few days 
from all vger mailing lists at the end of september).

I suspect that you want to sent this via your tree, right?
If so:

Acked-by: Mauro Carvalho Chehab m.che...@samsung.com

 
 Regards,
 
   Hans
 
  ---
   drivers/staging/media/dt3155v4l/dt3155v4l.c |5 +
   1 files changed, 1 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c 
  b/drivers/staging/media/dt3155v4l/dt3155v4l.c
  index 90d6ac4..081407b 100644
  --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
  +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
  @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct 
  pci_device_id *id)
  int err;
  struct dt3155_priv *pd;
   
  -   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
  -   if (err)
  -   return -ENODEV;
  -   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
  +   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
  if (err)
  return -ENODEV;
  pd = kzalloc(sizeof(*pd), GFP_KERNEL);
  
 
 --
 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


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] i2c: move of helpers into the core

[Mauro Carvalho Chehab]

Em Thu, 22 Aug 2013 18:00:14 +0200
Wolfram Sang w...@the-dreams.de escreveu:

 I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
 that it is much cleaner to have this in the core. This also removes a
 circular dependency between the helpers and the core, and so we can
 finally register child nodes in the core instead of doing this manually
 in each driver. So, fix the drivers and documentation, too.
 
 Acked-by: Rob Herring rob.herr...@calxeda.com
 Reviewed-by: Felipe Balbi ba...@ti.com
 Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Wolfram Sang w...@the-dreams.de

Acked-by: Mauro Carvalho Chehab m.che...@samsung.com

 ---
 
 V2-V3: Was trying to be too smart by only fixing includes needed.
   Took a more general approach this time, converting of_i2c.h
   to i2c.h in case i2c.h was not already there. Otherwise
   remove it. Improved my build scripts and no build failures,
   no complaints from buildbot as well.
 
 
  Documentation/acpi/enumeration.txt  |1 -
  arch/powerpc/platforms/44x/warp.c   |1 -
  drivers/gpu/drm/tilcdc/tilcdc_slave.c   |1 -
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c  |1 -
  drivers/gpu/host1x/drm/output.c |2 +-
  drivers/i2c/busses/i2c-at91.c   |3 -
  drivers/i2c/busses/i2c-cpm.c|6 --
  drivers/i2c/busses/i2c-davinci.c|2 -
  drivers/i2c/busses/i2c-designware-platdrv.c |2 -
  drivers/i2c/busses/i2c-gpio.c   |3 -
  drivers/i2c/busses/i2c-i801.c   |2 -
  drivers/i2c/busses/i2c-ibm_iic.c|4 -
  drivers/i2c/busses/i2c-imx.c|3 -
  drivers/i2c/busses/i2c-mpc.c|2 -
  drivers/i2c/busses/i2c-mv64xxx.c|3 -
  drivers/i2c/busses/i2c-mxs.c|3 -
  drivers/i2c/busses/i2c-nomadik.c|3 -
  drivers/i2c/busses/i2c-ocores.c |3 -
  drivers/i2c/busses/i2c-octeon.c |3 -
  drivers/i2c/busses/i2c-omap.c   |3 -
  drivers/i2c/busses/i2c-pnx.c|3 -
  drivers/i2c/busses/i2c-powermac.c   |9 +-
  drivers/i2c/busses/i2c-pxa.c|2 -
  drivers/i2c/busses/i2c-s3c2410.c|2 -
  drivers/i2c/busses/i2c-sh_mobile.c  |2 -
  drivers/i2c/busses/i2c-sirf.c   |3 -
  drivers/i2c/busses/i2c-stu300.c |2 -
  drivers/i2c/busses/i2c-tegra.c  |3 -
  drivers/i2c/busses/i2c-versatile.c  |2 -
  drivers/i2c/busses/i2c-wmt.c|3 -
  drivers/i2c/busses/i2c-xiic.c   |3 -
  drivers/i2c/i2c-core.c  |  109 +-
  drivers/i2c/i2c-mux.c   |3 -
  drivers/i2c/muxes/i2c-arb-gpio-challenge.c  |1 -
  drivers/i2c/muxes/i2c-mux-gpio.c|1 -
  drivers/i2c/muxes/i2c-mux-pinctrl.c |1 -
  drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +-
  drivers/media/platform/exynos4-is/fimc-is.c |2 +-
  drivers/media/platform/exynos4-is/media-dev.c   |1 -
  drivers/of/Kconfig  |6 --
  drivers/of/Makefile |1 -
  drivers/of/of_i2c.c |  114 
 ---
  drivers/staging/imx-drm/imx-tve.c   |2 +-
  include/linux/i2c.h |   20 
  include/linux/of_i2c.h  |   46 -
  sound/soc/fsl/imx-sgtl5000.c|2 +-
  sound/soc/fsl/imx-wm8962.c  |2 +-
  47 files changed, 138 insertions(+), 262 deletions(-)
  delete mode 100644 drivers/of/of_i2c.c
  delete mode 100644 include/linux/of_i2c.h
 
 diff --git a/Documentation/acpi/enumeration.txt 
 b/Documentation/acpi/enumeration.txt
 index d9be7a9..958266e 100644
 --- a/Documentation/acpi/enumeration.txt
 +++ b/Documentation/acpi/enumeration.txt
 @@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
   if (ret)
   /* handle error */
  
 - of_i2c_register_devices(adapter);
   /* Enumerate the slave devices behind this bus via ACPI */
   acpi_i2c_register_devices(adapter);
  
 diff --git a/arch/powerpc/platforms/44x/warp.c 
 b/arch/powerpc/platforms/44x/warp.c
 index 4cfa499..534574a 100644
 --- a/arch/powerpc/platforms/44x/warp.c
 +++ b/arch/powerpc/platforms/44x/warp.c
 @@ -16,7 +16,6 @@
  #include linux/interrupt.h
  #include linux/delay.h
  #include linux/of_gpio.h
 -#include linux/of_i2c.h
  #include linux/slab.h
  #include linux/export.h
  
 diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
 b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
 index dfffaf0..a19f657 100644

Re: [PATCH] omap3isp: Don't include plat/cpu.h

[Mauro Carvalho Chehab]

Em Thu, 3 Jan 2013 14:55:41 -0800
Tony Lindgren t...@atomide.com escreveu:

 * Laurent Pinchart laurent.pinch...@ideasonboard.com [130103 13:24]:
  The plat/*.h headers are not available to drivers in multiplatform
  kernels. As the header isn't needed, just remove it.
 
 Please consider merging this for the -rc cycle, so I can make
 plat/cpu.h produce an error for omap2+ to prevent new drivers
 including it.

Ok, I'll add it to the list of patches for 3.8.

Regards,
Mauro
 
 Acked-by: Tony Lindgren t...@atomide.com
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
   drivers/media/platform/omap3isp/isp.c |2 --
   1 files changed, 0 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/media/platform/omap3isp/isp.c 
  b/drivers/media/platform/omap3isp/isp.c
  index 50cea08..07eea5b 100644
  --- a/drivers/media/platform/omap3isp/isp.c
  +++ b/drivers/media/platform/omap3isp/isp.c
  @@ -71,8 +71,6 @@
   #include media/v4l2-common.h
   #include media/v4l2-device.h
   
  -#include plat/cpu.h
  -
   #include isp.h
   #include ispreg.h
   #include ispccdc.h
  -- 
  Regards,
  
  Laurent Pinchart
  
 --
 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


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] ARM: OMAP2+: Drop plat/cpu.h for omap2plus

[Mauro Carvalho Chehab]

Em Sun, 16 Dec 2012 12:03:17 -0800
Tony Lindgren t...@atomide.com escreveu:

 The cpu_is_omap macros are now local to arch/arm/mach-omap2
 in soc.h and plat/cpu.h can finally be dropped for omap2+.
 Thanks everybody for help with fixing the drivers.
 
 Note that we can now also remove the unused plat/cpu.h from
 smartreflex.c and isp.c as they will cause compile errors
 with ARCH_MULTIPLATFORM enabled.
 
 Cc: Jean Pihet jean.pi...@newoldbits.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/drm.c |1 -
  arch/arm/mach-omap2/dss-common.c  |3 +--
  arch/arm/mach-omap2/prm2xxx.c |3 +--
  arch/arm/mach-omap2/prm3xxx.c |3 +--
  arch/arm/plat-omap/include/plat/cpu.h |4 

  drivers/media/platform/omap3isp/isp.c |2 --

Acked-by: Mauro Carvalho Chehab mche...@redhat.com


  drivers/power/avs/smartreflex.c   |2 --

  7 files changed, 3 insertions(+), 15 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
 index fce5aa3..4c7566c 100644
 --- a/arch/arm/mach-omap2/drm.c
 +++ b/arch/arm/mach-omap2/drm.c
 @@ -27,7 +27,6 @@
  
  #include omap_device.h
  #include omap_hwmod.h
 -#include plat/cpu.h
  
  #if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
  
 diff --git a/arch/arm/mach-omap2/dss-common.c 
 b/arch/arm/mach-omap2/dss-common.c
 index 679a047..4be5cfc 100644
 --- a/arch/arm/mach-omap2/dss-common.c
 +++ b/arch/arm/mach-omap2/dss-common.c
 @@ -31,8 +31,7 @@
  #include video/omap-panel-nokia-dsi.h
  #include video/omap-panel-picodlp.h
  
 -#include plat/cpu.h
 -
 +#include soc.h
  #include dss-common.h
  #include mux.h
  
 diff --git a/arch/arm/mach-omap2/prm2xxx.c b/arch/arm/mach-omap2/prm2xxx.c
 index faeab18..cc0e714 100644
 --- a/arch/arm/mach-omap2/prm2xxx.c
 +++ b/arch/arm/mach-omap2/prm2xxx.c
 @@ -18,9 +18,8 @@
  #include linux/io.h
  #include linux/irq.h
  
 +#include soc.h
  #include common.h
 -#include plat/cpu.h
 -
  #include vp.h
  #include powerdomain.h
  #include clockdomain.h
 diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
 index db198d0..39822aa 100644
 --- a/arch/arm/mach-omap2/prm3xxx.c
 +++ b/arch/arm/mach-omap2/prm3xxx.c
 @@ -18,9 +18,8 @@
  #include linux/io.h
  #include linux/irq.h
  
 +#include soc.h
  #include common.h
 -#include plat/cpu.h
 -
  #include vp.h
  #include powerdomain.h
  #include prm3xxx.h
 diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
 b/arch/arm/plat-omap/include/plat/cpu.h
 index b4516ab..c9a66bf 100644
 --- a/arch/arm/plat-omap/include/plat/cpu.h
 +++ b/arch/arm/plat-omap/include/plat/cpu.h
 @@ -32,8 +32,4 @@
  #include mach/soc.h
  #endif
  
 -#ifdef CONFIG_ARCH_OMAP2PLUS
 -#include ../../mach-omap2/soc.h
 -#endif
 -
  #endif
 diff --git a/drivers/media/platform/omap3isp/isp.c 
 b/drivers/media/platform/omap3isp/isp.c
 index a9f6de5..2e8c0cb 100644
 --- a/drivers/media/platform/omap3isp/isp.c
 +++ b/drivers/media/platform/omap3isp/isp.c
 @@ -71,8 +71,6 @@
  #include media/v4l2-common.h
  #include media/v4l2-device.h
  
 -#include plat/cpu.h
 -
  #include isp.h
  #include ispreg.h
  #include ispccdc.h
 diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
 index a17d084..6b2238b 100644
 --- a/drivers/power/avs/smartreflex.c
 +++ b/drivers/power/avs/smartreflex.c
 @@ -27,8 +27,6 @@
  #include linux/pm_runtime.h
  #include linux/power/smartreflex.h
  
 -#include plat/cpu.h
 -
  #define SMARTREFLEX_NAME_LEN 16
  #define NVALUE_NAME_LEN  40
  #define SR_DISABLE_TIMEOUT   200
 


-- 

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

Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses

[Mauro Carvalho Chehab]

Em Thu, 29 Nov 2012 17:39:45 +0100
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:

 Hi Tony,
 
 On Thursday 29 November 2012 08:29:27 Tony Lindgren wrote:
  * Laurent Pinchart laurent.pinch...@ideasonboard.com [121129 01:37]:
   On Thursday 29 November 2012 11:30:28 Tomi Valkeinen wrote:
On 2012-11-28 17:13, Laurent Pinchart wrote:
 On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote:
 Hi,
 
 This patch removes use of cpu_is_* funcs from omap_vout, and uses
 omapdss's version instead. The other patch removes an unneeded
 plat/dma.h include.
 
 These are based on current omapdss master branch, which has the
 omapdss version code. The omapdss version code is queued for v3.8.
 I'm not sure which is the best way to handle these patches due to the
 dependency to omapdss. The easiest option is to merge these for 3.9.
 
 There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last
 OMAP dependency in the omap_vout driver. I'm not going to touch that,
 as it doesn't look as trivial as this cpu_is_* removal, and I don't
 have much knowledge of the omap_vout driver.
 
 Compiled, but not tested.
 
 Tested on a Beagleboard-xM.
 
 Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Thanks.

 The patches depend on unmerged OMAP DSS patches. Would you like to
 push this series through linuxtv or through your DSS tree ? The later
 might be easier, depending on when the required DSS patches will hit
 mainline.

The DSS patches will be merged for 3.8. I can take this via the omapdss
tree, as there probably won't be any conflicts with other v4l2 stuff.

Or, we can just delay these until 3.9. These patches remove omap
platform dependencies, helping the effort to get common ARM kernel.
However, as there's still the VRFB code in the omap_vout driver, the
dependency remains. Thus, in way, these patches alone don't help
anything, and we could delay these for 3.9 and hope that
omap_vout_vrfb.c gets converted also for that merge window.
   
   OK, I'll queue them for v3.9 then.
  
  Please rather queue the cpu_is_omap removal to v3.8 so I can
  remove plat/cpu.h for omap2+.
 
 In that case the patches should go through the DSS tree. Mauro, are you fine 
 with that ?

Sure.

For both patches:

Acked-by: Mauro Carvalho Chehab mche...@redhat.com

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

Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h

[Mauro Carvalho Chehab]

Tony,

Em Thu, 18 Oct 2012 13:28:42 -0700
Tony Lindgren t...@atomide.com escreveu:

 Looks like the iommu framework does not have generic functions
 exported for all the needs yet. The hardware specific functions
 are defined in files like intel-iommu.h and amd-iommu.h. Follow
 the same standard for omap-iommu.h.
 
 This is needed because we are removing plat and mach includes
 for ARM common zImage support. Further work should continue
 in the iommu framework context as only pure platform data will
 be communicated from arch/arm/*omap*/* code to the iommu
 framework.
 
 Cc: Joerg Roedel joerg.roe...@amd.com
 Cc: Ohad Ben-Cohen o...@wizery.com
 Cc: Ido Yariv i...@wizery.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Omar Ramirez Luna omar.l...@linaro.org
 Cc: linux-me...@vger.kernel.org
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/iommu2.c   |1 
  arch/arm/plat-omap/include/plat/iommu.h|   10 +--
  arch/arm/plat-omap/include/plat/iovmm.h|   89 
 
  drivers/iommu/omap-iommu-debug.c   |2 -
  drivers/iommu/omap-iommu.c |1 
  drivers/iommu/omap-iovmm.c |   46 ++
  drivers/media/platform/omap3isp/isp.c  |1 
  drivers/media/platform/omap3isp/isp.h  |2 -
  drivers/media/platform/omap3isp/ispccdc.c  |1 
  drivers/media/platform/omap3isp/ispstat.c  |1 
  drivers/media/platform/omap3isp/ispvideo.c |2 -

Acked-by: Mauro Carvalho Chehab mche...@redhat.com

It is better if you send this entire series through the ARM tree, keeping
this hole series altogether (and avoiding the risk of breaking bisectability
if it goes through separate trees). So, you can add my ack for those header
moves for drivers/media/platform/*.

Regards,
Mauro

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] [media] omap3isp: Fix compilation error in ispreg.h

[Mauro Carvalho Chehab]

Em Tue, 2 Oct 2012 09:31:58 -0700
Tony Lindgren t...@atomide.com escreveu:

 * Ido Yariv i...@wizery.com [121001 15:48]:
  Commit c49f34bc (ARM: OMAP2+ Move SoC specific headers to be local to
  mach-omap2) moved omap34xx.h to mach-omap2. This broke omap3isp, as it
  includes omap34xx.h.
  
  Instead of moving omap34xx to platform_data, simply add the two
  definitions the driver needs and remove the include altogether.
  
  Signed-off-by: Ido Yariv i...@wizery.com
 
 I'm assuming that Mauro picks this one up, sorry
 for breaking it.

Picked, thanks. 

With regards to the other patches in this series, IMHO, it
makes more sense to go through arm omap tree, so, for the
patches on this series that touch at drivers/media/platform/*:

Acked-by: Mauro Carvalho Chehab mche...@redhat.com

 
 Acked-by: Tony Lindgren t...@atomide.com
 
  ---
   drivers/media/platform/omap3isp/ispreg.h | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/media/platform/omap3isp/ispreg.h 
  b/drivers/media/platform/omap3isp/ispreg.h
  index 084ea77..e2c57f3 100644
  --- a/drivers/media/platform/omap3isp/ispreg.h
  +++ b/drivers/media/platform/omap3isp/ispreg.h
  @@ -27,13 +27,13 @@
   #ifndef OMAP3_ISP_REG_H
   #define OMAP3_ISP_REG_H
   
  -#include plat/omap34xx.h
  -
  -
   #define CM_CAM_MCLK_HZ 17280   /* Hz */
   
   /* ISP Submodules offset */
   
  +#define L4_34XX_BASE   0x4800
  +#define OMAP3430_ISP_BASE  (L4_34XX_BASE + 0xBC000)
  +
   #define OMAP3ISP_REG_BASE  OMAP3430_ISP_BASE
   #define OMAP3ISP_REG(offset)   (OMAP3ISP_REG_BASE + (offset))
   
  -- 
  1.7.11.4
  
  --
  To unsubscribe from this list: send the line unsubscribe linux-omap 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




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

Re: [PATCH 3/3] arm: omap: Move iommu/iovmm headers to platform_data

[Mauro Carvalho Chehab]

Em Fri, 21 Sep 2012 01:14:08 -0400
Ido Yariv i...@wizery.com escreveu:

 Move iommu/iovmm headers from plat/ to platform_data/ as part of the
 single zImage work.
 
 Signed-off-by: Ido Yariv i...@wizery.com
 ---
  arch/arm/mach-omap2/devices.c   | 2 +-
  arch/arm/mach-omap2/iommu2.c| 2 +-
  arch/arm/mach-omap2/omap-iommu.c| 2 +-
  drivers/iommu/omap-iommu-debug.c| 4 ++--
  drivers/iommu/omap-iommu.c  | 2 +-
  drivers/iommu/omap-iovmm.c  | 4 ++--

  drivers/media/platform/omap3isp/isp.h   | 5 +++--
  drivers/media/platform/omap3isp/ispvideo.c  | 6 
 --

Acked-by: Mauro Carvalho Chehab mche...@redhat.com

  .../plat/iommu.h = include/linux/platform_data/iommu-omap.h| 0
  .../plat/iovmm.h = include/linux/platform_data/iovmm-omap.h| 0
  10 files changed, 15 insertions(+), 12 deletions(-)
  rename arch/arm/plat-omap/include/plat/iommu.h = 
 include/linux/platform_data/iommu-omap.h (100%)
  rename arch/arm/plat-omap/include/plat/iovmm.h = 
 include/linux/platform_data/iovmm-omap.h (100%)
 
 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index 1bb2e92..5bde5c2 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
  
  #if defined(CONFIG_IOMMU_API)
  
 -#include plat/iommu.h
 +#include linux/platform_data/iommu-omap.h
  
  static struct resource omap3isp_resources[] = {
   {
 diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
 index eefc379..cab7acc 100644
 --- a/arch/arm/mach-omap2/iommu2.c
 +++ b/arch/arm/mach-omap2/iommu2.c
 @@ -18,7 +18,7 @@
  #include linux/slab.h
  #include linux/stringify.h
  
 -#include plat/iommu.h
 +#include linux/platform_data/iommu-omap.h
  
  /*
   * omap2 architecture specific register bit definitions
 diff --git a/arch/arm/mach-omap2/omap-iommu.c 
 b/arch/arm/mach-omap2/omap-iommu.c
 index df298d4..a6a4ff8 100644
 --- a/arch/arm/mach-omap2/omap-iommu.c
 +++ b/arch/arm/mach-omap2/omap-iommu.c
 @@ -13,7 +13,7 @@
  #include linux/module.h
  #include linux/platform_device.h
  
 -#include plat/iommu.h
 +#include linux/platform_data/iommu-omap.h
  
  #include soc.h
  #include common.h
 diff --git a/drivers/iommu/omap-iommu-debug.c 
 b/drivers/iommu/omap-iommu-debug.c
 index f55fc5d..e6ee7c2 100644
 --- a/drivers/iommu/omap-iommu-debug.c
 +++ b/drivers/iommu/omap-iommu-debug.c
 @@ -19,8 +19,8 @@
  #include linux/platform_device.h
  #include linux/debugfs.h
  
 -#include plat/iommu.h
 -#include plat/iovmm.h
 +#include linux/platform_data/iommu-omap.h
 +#include linux/platform_data/iovmm-omap.h
  
  #include plat/iopgtable.h
  
 diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
 index d0b1234..298ca19 100644
 --- a/drivers/iommu/omap-iommu.c
 +++ b/drivers/iommu/omap-iommu.c
 @@ -24,7 +24,7 @@
  
  #include asm/cacheflush.h
  
 -#include plat/iommu.h
 +#include linux/platform_data/iommu-omap.h
  
  #include plat/iopgtable.h
  
 diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
 index 2e10c3e..ade7c6c 100644
 --- a/drivers/iommu/omap-iovmm.c
 +++ b/drivers/iommu/omap-iovmm.c
 @@ -21,8 +21,8 @@
  #include asm/cacheflush.h
  #include asm/mach/map.h
  
 -#include plat/iommu.h
 -#include plat/iovmm.h
 +#include linux/platform_data/iommu-omap.h
 +#include linux/platform_data/iovmm-omap.h
  
  #include plat/iopgtable.h
  
 diff --git a/drivers/media/platform/omap3isp/isp.h 
 b/drivers/media/platform/omap3isp/isp.h
 index 8be7487..62c76f9 100644
 --- a/drivers/media/platform/omap3isp/isp.h
 +++ b/drivers/media/platform/omap3isp/isp.h
 @@ -34,8 +34,9 @@
  #include linux/platform_device.h
  #include linux/wait.h
  #include linux/iommu.h
 -#include plat/iommu.h
 -#include plat/iovmm.h
 +
 +#include linux/platform_data/iommu-omap.h
 +#include linux/platform_data/iovmm-omap.h
  
  #include ispstat.h
  #include ispccdc.h
 diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
 b/drivers/media/platform/omap3isp/ispvideo.c
 index 3a5085e..1093f07 100644
 --- a/drivers/media/platform/omap3isp/ispvideo.c
 +++ b/drivers/media/platform/omap3isp/ispvideo.c
 @@ -34,8 +34,10 @@
  #include linux/vmalloc.h
  #include media/v4l2-dev.h
  #include media/v4l2-ioctl.h
 -#include plat/iommu.h
 -#include plat/iovmm.h
 +
 +#include linux/platform_data/iommu-omap.h
 +#include linux/platform_data/iovmm-omap.h
 +
  #include plat/omap-pm.h
  
  #include ispvideo.h
 diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
 b/include/linux/platform_data/iommu-omap.h
 similarity index 100%
 rename from arch/arm/plat-omap/include/plat/iommu.h
 rename to include/linux/platform_data/iommu-omap.h
 diff --git a/arch/arm/plat-omap/include/plat/iovmm.h 
 b

[git:v4l-dvb/for_v3.7] [media] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data

[Mauro Carvalho Chehab]

This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
Author:  Timo Kokkonen timo.t.kokko...@iki.fi
Date:Fri Aug 10 06:16:37 2012 -0300

The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.

Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 arch/arm/mach-omap2/board-rx51-peripherals.c |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=322c183cdc5f041d0f6a25fe519c7836649a6c8b

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..ca07264 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
 #include plat/gpmc.h
 #include plat/onenand.h
 #include plat/gpmc-smc91x.h
+#include plat/omap-pm.h
 
 #include mach/board-rx51.h
 
@@ -46,6 +47,10 @@
 #include ../drivers/staging/iio/light/tsl2563.h
 #include linux/lis3lv02d.h
 
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include media/ir-rx51.h
+#endif
+
 #include mux.h
 #include hsmmc.h
 #include common-board-devices.h
@@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
 }
 
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+static struct lirc_rx51_platform_data rx51_lirc_data = {
+   .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
+   .pwm_timer = 9, /* Use GPT 9 for CIR */
+};
+
+static struct platform_device rx51_lirc_device = {
+   .name   = lirc_rx51,
+   .id = -1,
+   .dev= {
+   .platform_data = rx51_lirc_data,
+   },
+};
+
+static void __init rx51_init_lirc(void)
+{
+   platform_device_register(rx51_lirc_device);
+}
+#else
+static void __init rx51_init_lirc(void)
+{
+}
+#endif
+
 void __init rx51_peripherals_init(void)
 {
rx51_i2c_init();
@@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
+   rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver

[Mauro Carvalho Chehab]

This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] media: rc: Introduce RX51 IR transmitter driver
Author:  Timo Kokkonen timo.t.kokko...@iki.fi
Date:Fri Aug 10 06:16:36 2012 -0300

This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.

The following modifications have been made compared to the original
driver version:

- Adopt to the changes that has happen in the kernel during the past
  five years, such as the change in the include paths

- The OMAP DM-timers require much more care nowadays. The timers need
  to be enabled and disabled or otherwise many actions fail. Timers
  must not be freed without first stopping them or otherwise the timer
  cannot be requested again.

The code has been tested with sending IR codes with N900 device
running Debian userland. The device receiving the codes was Anysee
DVB-C USB receiver.

Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: Sakari Ailus sakari.ai...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 drivers/media/rc/Kconfig   |   10 +
 drivers/media/rc/Makefile  |1 +
 drivers/media/rc/ir-rx51.c |  496 
 include/media/ir-rx51.h|   10 +
 4 files changed, 517 insertions(+), 0 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=c332e8472d7db67766bcad33390c607fdd9ac5bc

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 64be610..016f9ab 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -287,6 +287,16 @@ config IR_TTUSBIR
   To compile this driver as a module, choose M here: the module will
   be called ttusbir.
 
+config IR_RX51
+   tristate Nokia N900 IR transmitter diode
+   depends on MACH_NOKIA_RX51  OMAP_DM_TIMER
+   ---help---
+  Say Y or M here if you want to enable support for the IR
+  transmitter diode built in the Nokia N900 (RX51) device.
+
+  The driver uses omap DM timers for gereating the carrier
+  wave and pulses.
+
 config RC_LOOPBACK
tristate Remote Control Loopback Driver
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 66c8bae..56bacf0 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
 obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
 obj-$(CONFIG_IR_ENE) += ene_ir.o
 obj-$(CONFIG_IR_REDRAT3) += redrat3.o
+obj-$(CONFIG_IR_RX51) += ir-rx51.o
 obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
 obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
 obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
new file mode 100644
index 000..9487dd3
--- /dev/null
+++ b/drivers/media/rc/ir-rx51.c
@@ -0,0 +1,496 @@
+/*
+ *  Copyright (C) 2008 Nokia Corporation
+ *
+ *  Based on lirc_serial.c
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/uaccess.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/wait.h
+
+#include plat/dmtimer.h
+#include plat/clock.h
+#include plat/omap-pm.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+#include media/ir-rx51.h
+
+#define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE |  \
+  LIRC_CAN_SET_SEND_CARRIER |  \
+  LIRC_CAN_SEND_PULSE)
+
+#define DRIVER_NAME lirc_rx51
+
+#define WBUF_LEN 256
+
+#define TIMER_MAX_VALUE 0x
+
+struct lirc_rx51 {
+   struct omap_dm_timer *pwm_timer;
+   struct omap_dm_timer *pulse_timer;
+   struct device*dev;
+   struct lirc_rx51_platform_data *pdata;
+   wait_queue_head_t wqueue;
+
+   unsigned long   fclk_khz;
+   unsigned intfreq;   /* carrier frequency */
+   unsigned intduty_cycle; /* carrier duty cycle */
+   unsigned intirq_num;
+   unsigned

Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

[Mauro Carvalho Chehab]

Em 27-09-2011 19:49, Gary Thomas escreveu:
 On 2011-09-27 16:31, Mauro Carvalho Chehab wrote:
 Em 19-09-2011 12:31, Hiremath, Vaibhav escreveu:

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, September 16, 2011 6:36 PM
 To: Ravi, Deepthy
 Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
 linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de;
 Hiremath, Vaibhav
 Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

 Hi Deepthy,

 On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
 On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
 On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
 From: Vaibhav Hiremathhvaib...@ti.com

 In order to support TVP5146 (for that matter any video decoder),
 it is important to support G/S/ENUM_STD ioctl on /dev/videoX
 device node.

 Why so ? Shouldn't it be queried on the subdev output pad directly ?

 Because standard v4l2 application for analog devices will call these std
 ioctls on the streaming device node. So it's done on /dev/video to make
 the
 existing apllication work.

 Existing applications can't work with the OMAP3 ISP (and similar complex
 embedded devices) without userspace support anyway, either in the form of
 a
 GStreamer element or a libv4l plugin. I still believe that analog video
 standard operations should be added to the subdev pad operations and
 exposed
 through subdev device nodes, exactly as done with formats.

 [Hiremath, Vaibhav] Laurent,

 I completely agree with your point that, existing application will not work 
 without setting links properly.
 But I believe the assumption here is, media-controller should set the links 
 (along with pad formants) and
 all existing application should work as is. Isn't it?

 Yes.

 The way it is being done currently is, set the format at the pad level 
 which is same as analog standard resolution and use existing application 
 for streaming...

 Yes.

 I am ok, if we add s/g/enum_std api support at sub-dev level but this 
 should also be supported on streaming device node.

 Agreed. Standards selection should be done at device node, just like any 
 other
 device.
 
 So how do you handle a part like the TVP5150 that is standard agnostic?
 That device can sense the standard from the input signal and sets the
 result appropriately.
 
See the em28xx driver. It uses tvp5150 at the device node, and works properly.

It should be noticed, however, that the implementation at tvp5150 doesn't
implement standards detection properly, due to hardware limitation.

A proper implementation of standards detection is to get the standards mask from
userspace and let the driver detect between the standards that the userspace is
expecting.

So, userspace could, for example, do things like:

v4l2_std_id std = V4L2_STD_PAL_M | V4L2_STD_NTSC_M | V4L2_STD_PAL_DK;

ioctl (fd, VIDIOC_S_STD, std);
msleep (100);
ioctl (fd, VIDIOC_G_STD, std);
if (std  V4L2_STD_625_50)
height = 576;
else
height = 480;

The above code won't work with the current tvp5150 driver, due to two reasons:

1) The tvp5150 register 0x28 doesn't allow an arbitrary standards mask like the 
above.
The driver does support standards detection, if V4L2_STD_ALL is passed into it.

2) even if V4L2_STD_ALL is used, the driver currently doesn't implement a
vidioc_g_std callback. So, the driver cannot return back to userspace and to
the bridge driver what standard were detected. Without this information, 
userspace
might use the wrong number of lines when allocating the buffer, and this won't
work.

Of course, patches for fixing this are welcome.

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

Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

[Mauro Carvalho Chehab]

Em 19-09-2011 12:31, Hiremath, Vaibhav escreveu:
 
 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, September 16, 2011 6:36 PM
 To: Ravi, Deepthy
 Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
 linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de;
 Hiremath, Vaibhav
 Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

 Hi Deepthy,

 On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
 On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
 On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@ti.com

 In order to support TVP5146 (for that matter any video decoder),
 it is important to support G/S/ENUM_STD ioctl on /dev/videoX
 device node.

 Why so ? Shouldn't it be queried on the subdev output pad directly ?

 Because standard v4l2 application for analog devices will call these std
 ioctls on the streaming device node. So it's done on /dev/video to make
 the
 existing apllication work.

 Existing applications can't work with the OMAP3 ISP (and similar complex
 embedded devices) without userspace support anyway, either in the form of
 a
 GStreamer element or a libv4l plugin. I still believe that analog video
 standard operations should be added to the subdev pad operations and
 exposed
 through subdev device nodes, exactly as done with formats.

 [Hiremath, Vaibhav] Laurent,
 
 I completely agree with your point that, existing application will not work 
 without setting links properly.
 But I believe the assumption here is, media-controller should set the links 
 (along with pad formants) and 
 all existing application should work as is. Isn't it?

Yes.

 The way it is being done currently is, set the format at the pad level which 
 is same as analog standard resolution and use existing application for 
 streaming...

Yes.

 I am ok, if we add s/g/enum_std api support at sub-dev level but this should 
 also be supported on streaming device node.

Agreed. Standards selection should be done at device node, just like any other
device.

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

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

[Mauro Carvalho Chehab]

Em 06-09-2011 11:47, Laurent Pinchart escreveu:
 Hi Vaibhav,
 
 On Tuesday 06 September 2011 16:12:35 Hiremath, Vaibhav wrote:
 On Monday, September 05, 2011 6:20 PM Laurent Pinchart wrote:
 On Sunday 04 September 2011 15:32:28 Mauro Carvalho Chehab wrote:

 snip

 I don't mind splitting the config option. An alternative would be to
 compile media_entity_init() and media_entity_cleanup() based on
 CONFIG_MEDIA_SUPPORT instead of CONFIG_MEDIA_CONTROLLER, but that looks a
 bit hackish to me.

 Also, I don't like the idea of increasing drivers complexity for the
 existing drivers that work properly without MC. All those core
 conversions that were done in the last two years caused already too much
 instability to them.

 We should really avoid touching on them again for something that won't
 be adding any new feature nor fixing any known bug.

 We don't have to convert them all in one go right now, we can implement
 pad-level operations support selectively when a subdev driver becomes used
 by an MC-enabled host/bridge driver.

 I completely agree that we should not be duplicating the code just for sake
 of it.

 Isn't the wrapper approach seems feasible here?
 
 As explained in a previous e-mail, a wrapper sounds like a good approach to 
 me, to emulate video::* operations based on pad::* operations. We want to 
 move 
 to pad::* operations, so we should not perform emulation the other way around.

We have 300+ drivers under /drivers/media. Just a few of them need MC API.

Good sense says that we shouldn't touch on 300+ just because of half dozen 
drivers.

So, if a wrapper is needed, it should be done for the other side.

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

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

[Mauro Carvalho Chehab]

Em 04-09-2011 06:01, Laurent Pinchart escreveu:
 Hi Mauro,
 
 On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote:
 Em 24-08-2011 10:25, Laurent Pinchart escreveu:
 On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote:
 On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote:
 On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote:
 On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote:
 On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@ti.com

 Fix the build break caused when CONFIG_MEDIA_CONTROLLER
 option is disabled and if any sensor driver has to be used
 between MC and non MC framework compatible devices.

 For example,if tvp514x video decoder driver migrated to
 MC framework is being built without CONFIG_MEDIA_CONTROLLER
 option enabled, the following error messages will result.
 drivers/built-in.o: In function `tvp514x_remove':
 drivers/media/video/tvp514x.c:1285: undefined reference to
 `media_entity_cleanup'
 drivers/built-in.o: In function `tvp514x_probe':
 drivers/media/video/tvp514x.c:1237: undefined reference to
 `media_entity_init'

 If the tvp514x is migrated to the MC framework, its Kconfig option
 should depend on MEDIA_CONTROLLER.

 The same TVP514x driver is being used for both MC and non MC
 compatible devices, for example OMAP3 and AM35x. So if it is made
 dependent on MEDIA CONTROLLER, we cannot enable the driver for MC
 independent devices.

 Then you should use conditional compilation in the tvp514x driver
 itself. Or

 No. I am not in favor of conditional compilation in driver code.

 Actually, thinking some more about this, you should make the tvp514x
 driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't
 mean that the driver will become unusable by applications that are not
 MC-aware. Hosts/bridges don't have to export subdev nodes, they can just
 call subdev pad-level operations internally and let applications control
 the whole device through a single V4L2 video node.

 better, port the AM35x driver to the MC API.

 Why should we use MC if I have very simple device (like AM35x) which
 only supports single path? I can very well use simple V4L2 sub-dev
 based approach (master - slave), isn't it?

 The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it
 doesn't have to expose them to userspace.

 I don't agree. If AM35x doesn't expose the MC API to userspace,
 CONFIG_MEDIA_CONTROLLER should not be required at all.

 Also, according with the Linux best practices, when  #if tests for config
 symbols are required, developers should put it into the header files, and
 not inside the code, as it helps to improve code readability. From
 Documentation/SubmittingPatches:

  2) #ifdefs are ugly

  Code cluttered with ifdefs is difficult to read and maintain.  Don't do
  it.  Instead, put your ifdefs in a header, and conditionally define
  'static inline' functions, or macros, which are used in the code.
  Let the compiler optimize away the no-op case.

 So, this patch is perfectly fine on my eyes.
 
 I'm sorry, but I don't agree.
 
 Regarding the V4L2 subdev pad-level API, the goal is to convert all host and 
 subdev drivers to it, so that's definitely the way to go. This does *not* 
 mean 
 that subdevs must expose a subdev device node. That's entirely optional. What 
 I'm talking about is switching from video::*_mbus_fmt operations to 
 pad::*_fmt 
 operations. The pad-level format operations are very similar to video-level 
 format operations, and more generic. Drivers shouldn't implement both.

I agree that implementing two ways for doing the same thing is a bad idea, 
but especially since your idea is to convert all subdevs to it, this type 
of conversion should not require enabling CONFIG_MEDIA_CONTROLLER, as this
feature is used to enable the MC userspace API.

 Regarding the MC API, drivers are not required to register a media_device 
 instance. I have no issue with that. However, drivers should initialized the 
 subdev's embedded media_entity, as that's required by subdev pad-level 
 operations to get the number of pads for a subdev.

There are two solutions:

1) add some fallback method at the core to use the video::*_mbus_fmt way, when
MC is disabled;

2) split the config options into two: one configurable by the user to enable
the userspace MC API, and another, used internally that would select the MC
internal API when drivers need it.

As your plan is to convert all drivers to the new way, (2) doesn't make much
sense in long term, as, at the end, all drivers will be selecting it.

Also, I don't like the idea of increasing drivers complexity for the existing
drivers that work properly without MC. All those core conversions that were
done in the last two years caused already too much instability to them.

We should really avoid touching on them again for something that won't be
adding any new feature nor fixing any known bug.
 
 This will result

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

[Mauro Carvalho Chehab]

Em 24-08-2011 10:25, Laurent Pinchart escreveu:
 Hi Vaibhav,
 
 On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote:
 On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: 
 On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote:
 On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote:
 On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@ti.com

 Fix the build break caused when CONFIG_MEDIA_CONTROLLER
 option is disabled and if any sensor driver has to be used
 between MC and non MC framework compatible devices.

 For example,if tvp514x video decoder driver migrated to
 MC framework is being built without CONFIG_MEDIA_CONTROLLER
 option enabled, the following error messages will result.
 drivers/built-in.o: In function `tvp514x_remove':
 drivers/media/video/tvp514x.c:1285: undefined reference to
 `media_entity_cleanup'
 drivers/built-in.o: In function `tvp514x_probe':
 drivers/media/video/tvp514x.c:1237: undefined reference to
 `media_entity_init'

 If the tvp514x is migrated to the MC framework, its Kconfig option
 should depend on MEDIA_CONTROLLER.

 The same TVP514x driver is being used for both MC and non MC compatible
 devices, for example OMAP3 and AM35x. So if it is made dependent on
 MEDIA CONTROLLER, we cannot enable the driver for MC independent
 devices.

 Then you should use conditional compilation in the tvp514x driver itself.
 Or

 No. I am not in favor of conditional compilation in driver code.
 
 Actually, thinking some more about this, you should make the tvp514x driver 
 depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the 
 driver will become unusable by applications that are not MC-aware. 
 Hosts/bridges don't have to export subdev nodes, they can just call subdev 
 pad-level operations internally and let applications control the whole device 
 through a single V4L2 video node.
 
 better, port the AM35x driver to the MC API.

 Why should we use MC if I have very simple device (like AM35x) which only
 supports single path? I can very well use simple V4L2 sub-dev based
 approach (master - slave), isn't it?
 
 The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it 
 doesn't have to expose them to userspace.

I don't agree. If AM35x doesn't expose the MC API to userspace, 
CONFIG_MEDIA_CONTROLLER should not be required at all.

Also, according with the Linux best practices, when  #if tests for config
symbols are required, developers should put it into the header files, and
not inside the code, as it helps to improve code readability. From
Documentation/SubmittingPatches:

2) #ifdefs are ugly

Code cluttered with ifdefs is difficult to read and maintain.  Don't do
it.  Instead, put your ifdefs in a header, and conditionally define
'static inline' functions, or macros, which are used in the code.
Let the compiler optimize away the no-op case.

So, this patch is perfectly fine on my eyes.

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

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Mauro Carvalho Chehab]

Em 22-03-2011 14:32, Mythri P K escreveu:
 Adding support for common EDID parsing in kernel.
 
 EDID - Extended display identification data is a data structure provided by
 a digital display to describe its capabilities to a video source, This a 
 standard supported by CEA and VESA.
 
 There are several custom implementations for parsing EDID in kernel, some
 of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
 parsing of EDID should be done in a library, which is agnostic of the
 framework (V4l2, DRM, FB)  which is using the functionality, just based on 
 the raw EDID pointer with size/segment information.
 
 With other RFC's such as the one below, which tries to standardize HDMI API's
 It would be better to have a common EDID code in one place.It also helps to
 provide better interoperability with variety of TV/Monitor may be even by
 listing out quirks which might get missed with several custom implementation
 of EDID.
 http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
 
 This patch tries to add functions to parse some portion EDID (detailed timing,
 monitor limits, AV delay information, deep color mode support, Audio and VSDB)
 If we can align on this library approach i can enhance this library to parse
 other blocks and probably we could also add quirks from other implementation
 as well.
 
 Signed-off-by: Mythri P K mythr...@ti.com
 ---
  arch/arm/include/asm/edid.h |  243 ++
  drivers/video/edid.c|  340 
 +++

Hmm... if you want this to be agnostic, the header file should not be inside
arch/arm, but on some other place, like include/video/.

  2 files changed, 583 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/include/asm/edid.h
  create mode 100644 drivers/video/edid.c
 
 diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
 new file mode 100644
 index 000..843346a
 --- /dev/null
 +++ b/arch/arm/include/asm/edid.h
 @@ -0,0 +1,243 @@
 +/*
 + * edid.h
 + *
 + * Copyright (C) 2011 Texas Instruments
 + * Author: Mythri P K mythr...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 as published 
 by
 + * the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but 
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License along 
 with
 + * this program.  If not, see http://www.gnu.org/licenses/.
 + * History:
 + */
 +
 +#ifndef _EDID_H_
 +#define _EDID_H_
 +
 +/* HDMI EDID Length */
 +#define HDMI_EDID_MAX_LENGTH 512
 +
 +/* HDMI EDID Extension Data Block Tags  */
 +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK  0xE0
 +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK  0x1F
 +
 +#define EDID_TIMING_DESCRIPTOR_SIZE  0x12
 +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS   0x36
 +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS   0x80
 +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR   4
 +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR   4
 +
 +/* EDID Detailed Timing  Info 0 begin offset */
 +#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
 +
 +#define HDMI_EDID_PIX_CLK_OFFSET 0
 +#define HDMI_EDID_H_ACTIVE_OFFSET2
 +#define HDMI_EDID_H_BLANKING_OFFSET  3
 +#define HDMI_EDID_V_ACTIVE_OFFSET5
 +#define HDMI_EDID_V_BLANKING_OFFSET  6
 +#define HDMI_EDID_H_SYNC_OFFSET  8
 +#define HDMI_EDID_H_SYNC_PW_OFFSET   9
 +#define HDMI_EDID_V_SYNC_OFFSET  10
 +#define HDMI_EDID_V_SYNC_PW_OFFSET   11
 +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET12
 +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET13
 +#define HDMI_EDID_H_BORDER_OFFSET15
 +#define HDMI_EDID_V_BORDER_OFFSET16
 +#define HDMI_EDID_FLAGS_OFFSET   17
 +
 +/* HDMI EDID DTDs */
 +#define HDMI_EDID_MAX_DTDS   4
 +
 +/* HDMI EDID DTD Tags */
 +#define HDMI_EDID_DTD_TAG_MONITOR_NAME   0xFC
 +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM  0xFF
 +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
 +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA   0xFA
 +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA   0xFB
 +#define HDMI_EDID_DTD_TAG_ASCII_STRING   0xFE
 +
 +#define HDMI_IMG_FORMAT_MAX_LENGTH   20
 +#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
 +
 +/* HDMI EDID Extenion Data Block Values: Video */
 +#define HDMI_EDID_EX_VIDEO_NATIVE0x80
 +#define HDMI_EDID_EX_VIDEO_MASK  0x7F
 +#define HDMI_EDID_EX_VIDEO_MAX   35
 +
 +#define STANDARD_HDMI_TIMINGS_NB 34
 

Re: [RFC] How to pass camera Orientation to userspace

[Mauro Carvalho Chehab]

On Tue, 24 Feb 2009, kilg...@banach.math.auburn.edu wrote:




On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:


 On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:



big snip



 Theodore,

 You're considering just one subset of the V4L usages: notebook webcams.


Actually, the sq905 cameras are not notebook webcams. They are cheap, 
consumer entry level dual-mode cameras. They can be used as hand-held still 
cameras, to shoot still photos, and they can also be used as webcams. When 
sold, they usually came with some kind of mounting device that could hold 
them rigidly for webcam use. There are lots of similar cameras. Mercifully, 
not all of those others have the problems of the sq905, which have led to 
the present impasse.



If

 you think about non-notebook webcams [1] or about security cams, you'll
 see that the only way for you to have the flipping information is inside
 some userspace file.


However, there are obvious differences. For those cameras the question might 
well come up about how to control the movement of the camera, or, at least, 
to be aware of which way the camera is pointing. For these, the topic is an 
inherent property of the particular model of the camera -- or a defect, if 
someone wants to say so. Since the property is not determined by USB number, 
it is inherently impossible outside of the module to create a table which 
contains the needed information.


My intention here was to re-focus attention on the original problem which 
brought up the current discussion, and to that end the problem must be 
clearly understood. To have the flipping information inside some userspace 
file might solve some other problem and may be a generally very good idea. 
But it will not, can not, and never will be able to solve this problem.




 For example, I have here one video input bttv board with 16 cameras,
 connected on 4 bttv chips. I have also a Pelco camera, that has just one
 support socket. Depending on the place you mount it, the camera has to be
 rotated by 180 degrees. It can also be useful to mount it rotated by 90
 degrees.


Good. So one needs external controls and userspace tools. Did I ever say 
that such things should never be done? No. All I said was that there is a 
problem, presently on the table, and those kinds of things are not, can not 
be, never were, and never will be solutions for _this_ problem.




 After mounting the cameras, no matter what apps you are using (a
 streaming video app to broadcast it via internet, a security app, etc),
 the rotation
 information for that input, on that particular PCI, bus won't change.

 As we've standardized the VIDIOC_QUERYCAP bus_info, now, the information
 for the camera at input 3 of bttv hardware at PCI addres 03:00.3 is
 unique. It is also unique the same information for a notebook mounted
 webcam (since the USB bus ID won't change for that devices).


Errrm... Again, the cameras in question here are not notebook mounted 
webcams.




 So, if we standardize where this information is stored, for example, at
 /etc/libv4l and/or at ~/.libv4lrc, and let libv4l handle such info, this
 will be something consistent for all applications using libv4l. Other
 apps that might not want to trust on libv4l can also read the info at the
 same file.


Sorry, this will not work here. It may solve some other problem, but not 
this problem. Or, if one wants to store the information there, I don't 
care, really, but then there needs to be a way to get the information from 
the module, where it is, and get written into said table, which is where you 
want it, and this needs to happen every time an sq905 camera gets plugged in 
-- without pestering the user about the matter every time that such a camera 
gets hooked up.


Comparison: I have tossed a coin. Is it going to come up heads? Or tails? It 
is possible to know which, because the coin has been tossed. It would not 
even be cheating to look at it, or allow someone who did look at it, to pass 
to us the information. But we are not going to look, and if someone tells us 
we will not listen because we have not agreed on what language to use for 
communication. Instead, we will put a guess about the outcome into a table. 
We will make it a nice table, which can be revised using nice GUI tools, so 
it is easy for the user. So if our guess is wrong let the user fix it. Then 
next time we toss the coin the table entry will be right because either it 
was right before, or now someone fixed it???




 So, I really think that this should be part of the approach.


I was not even addressing what should or should not be part of the approach 
to some other problems. My point was that such discussion is not germane to 
the problem of how to pass on the correct orientation of the sensor, for the 
sq905 cameras. There are lots of other problems out there to solve. No 
denying that.


Also an overview is often very helpful. Also trying to visualize what might 
be needed in the future

Re: [RFC] How to pass camera Orientation to userspace

[Mauro Carvalho Chehab]

On Sat, 21 Feb 2009 12:53:57 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 Hi Adam,
 
 Sorry for the late reply, it's been very busy.

Me too.

  1) Reuse the existing HFLIP and VFLIP controls, marking them as read-only
  Pros : No change needed to videodev2.h
  Cons: It is confusing to have controls that have a subtly different
  meaning if they are read only. Existing apps that support those controls
  might get confused. Would require polling to support the case of a camera
  being turned toward / away from the user while streaming.

Reusing an existing control for a different meaning seems wrong. What happens
when some cam has the capability of doing hardware flipping, and have the cam
flipped?

  2) Introduce a new orientation control (possibly in a new
  CAMERA_PROPERTIES class)
  Pros: libv4l can easily tell if the driver supports the control.
  Cons: It is really a property, not a control so calling it a control is
  wrong. Controls add lots of overhead in terms of driver code. Would
  require polling to support the case of a camera being turned toward /
  away from the user while streaming.

I think this could be a good idea, but I agree with Hans Verkuil comments: since
this is a characteristics for a given input, using a control here would mean
that the driver will return it based on the selected input. Seems a little
messy. Also, a mounted characteristics of the device, is not really a sensor,
as Hans de Goede pointed.

  3) Use an extra couple of bits in V4L2_BUF_FLAGS
  Pros: Simple to implement. Can change per frame without needing polling.
  Cons: Doesn't work for non libv4l apps that try to use the read()
  interface. Can't easily identify drivers that don't support it (does 0
  mean not rotated or just not implemented). Can only be read when
  streaming (does that matter?)
 
 I think that matters, yes.

I don't think this is a good idea. The metadata at the frame polling is meant
to return the stream info. We shouldn't mix sensor position here.

  4) Use some reserved bits from the v4l2_capability structure
  Pros: Less overhead than controls.
  Cons: Would require polling to support the case of a camera being turned
  toward / away from the user while streaming. Can't easily identify
  drivers that don't support it.
  5) Use some reserved bits from the v4l2_input structure (or possibly the
  status word but that is normally only valid for current input)
  Pros: Less overhead than controls. Could support multiple sensors in one
  camera if such a beast exists.
 What does exist is devices with a video input (e.g. composite) and a camera 
 input: each input will have different flags. Since these vflip/hflip 
 properties do not change they can be enumerated in advance and you know 
 what each input supports.
 
  Cons: Would require polling to support the case of a camera being turned
  toward / away from the user while streaming.
 
 Polling applies only to the bits that tell the orientation of the camera. 
 See below for a discussion of this.

Analog tv does polling for signal strength, since userspace apps do mute and
stops presenting video, if the signal is too weak. IMO, a similar mechanism
should be used by pivoting.

IMO, this would be better addressed as a property of v4l2_input. So, I think
that (5) is better than (4).

  Can't easily identify drivers that don't support it.
 
 Not too difficult to add through the use of a capability bit. Either in 
 v4l2_input or (perhaps) v4l2_capability.
 
 Another Pro is that this approach will also work for v4l2_output in the case 
 of, say, rotated LCD displays. Using camera orientation bits in v4l2_buffer 
 while capturing will work, but using similar bits for output will fail 
 since the data is going in the wrong direction.
 
  The interest in detecting if a driver provides this informnation is to
  allow libv4l to know when it should use the driver provided information
  and when it should use its internal table (which needs to be retained for
  backward compatibility). With no detection capability the driver provided
  info should be ignored for USB IDs in the built in table.
 
  Thoughts please

There is a case that we should think: at libv4l, we may need to override the
default orientation, by a custom one. For example: Surveillance systems have
cameras mounted on a fixed position. Depending on the camera, and the desired
position, some cameras may needed to be mounted rotated (the same case also
applies to some embedded hardware like ATM machines, where a webcam maybe
mounted with 180 degrees, due to hardware constraints).

Ok, this is nothing that kernel needs to handle, but, at userspace, we need to
have a file where the user could edit and store the camera position, to
override whatever we have in kernel.

 
 Is polling bad in this case? It is not something that needs immediate 
 attention IMHO. The overhead for checking once every X seconds is quite 
 low. Furthermore, it is only needed on devices that cannot do v/hflipping 
 in 

Re: Patch series in Tarball submitted (RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2)

[Mauro Carvalho Chehab]

On Wed, 14 Jan 2009 08:55:08 -0600
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote:

 
 
  -Original Message-
  From: Hiremath, Vaibhav
  Sent: Wednesday, January 14, 2009 8:51 AM
 
 snip
 
  [Hiremath, Vaibhav] I tried to build camera driver as module and got
  following error -
  
  ERROR: ispmmu_get_mapeable_space [drivers/media/video/omap34xxcam.ko]
  undefined!
  make[1]: *** [__modpost] Error 1
  make: *** [modules] Error 2
  
  You have missed to export this symbol, please correct in next version of
  patches.
  
 
 Oops, good catch. Thanks, I'll correct that. No problem.

Better to wait a little bit before posting the new version... I'm still
analyzing the current posting. 

It would be useful if you could document the private ioctls you've added, to
help me to better analyse the remaining patches.


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

Re: [REVIEW PATCH 01/14] V4L: Int if: Dummy slave

[Mauro Carvalho Chehab]

On Mon, 12 Jan 2009 20:03:08 -0600
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote:


 +static struct v4l2_int_slave dummy_slave = {
 + /* Dummy pointer to avoid underflow in find_ioctl. */
 + .ioctls = (void *)0x8000,

Why are you using here a magic number?

 + .num_ioctls = 0,
 +};

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

Re: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support

[Mauro Carvalho Chehab]

On Sat, 10 Jan 2009 04:41:21 +0300
Alexey Klimov klimov.li...@gmail.com wrote:

 On Wed, 2009-01-07 at 11:37 +0530, hvaib...@ti.com wrote:
  [...]  
 
 You have a lot of dprintk messages. May be it's better to move \n to
 dprintk definition? And use dprintk without \n.
 Probably, makes your life easier :)

Please, don't. On almost all places where *print* is used, \n is required.
Moving the end of line character into dprintk will just be something 
non-standard.

  +   return -EPERM;
  +   }
  +
  +
  +   switch (mux_id) {
  +   case MUX_TVP5146:
  +   /* active low signal. set 0 to enable, 1 to disable */
  +   if (ENABLE_MUX == value) {
  +   /* pull down the GPIO GPIO134 = 0 */
  +   gpio_set_value(GPIO134_SEL_Y, 0);
  +   /* pull up the GPIO GPIO54 = 1 */
  +   gpio_set_value(GPIO54_SEL_EXP_CAM, 1);
  +   /* pull up the GPIO GPIO136 = 1 */
  +   gpio_set_value(GPIO136_SEL_CAM, 1);
  +   } else
  +   /* pull up the GPIO GPIO134 = 0 */
  +   gpio_set_value(GPIO134_SEL_Y, 1);  
 
 Well, please chech the Documentation/CodingStyle file.
 Comments there say that you should use bracers with else expression
 (statement?) also. Care to reformat the patch that it will look like:

Agreed, but, in this specific case, just remove above the comments, or replace
to something more useful. 
Currently, they are just repeating what the code is saying. The comments should
document why you need to change the gpio. Something like:

/* Enable device foo */
gpio_set_value(GPIO136_bar, 1);

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

Re: [REVIEW PATCH 1/2] OMAP3 ISP-Camera: Added BT656 support

[Mauro Carvalho Chehab]

On Wed,  7 Jan 2009 11:37:20 +0530
hvaib...@ti.com wrote:

 From: Vaibhav Hiremath hvaib...@ti.com
 
 Support for BT656 through TVP5146 decoder, works on top of
 ISP-Camera patches posted by Sergio on 12th Dec 2008.
 
 The TVP514x driver patch has been accepted under V4L, will
 be part of O-L in the next merge window. As of now you can
 access the patches from -
 
 http://markmail.org/search/?q=TVP514x#query:TVP514x%20from%3A%22Hiremath%2C%20Vaibhav%22%20extension%3Apatch+page:1+mid:b5pcj3sriwknm2cv+state:results
 
 ToDO List:
 - Add support for scaling and cropping
 
 Signed-off-by: Brijesh Jadav brijes...@ti.com
 Signed-off-by: Hardik Shah hardik.s...@ti.com
 Signed-off-by: Manjunath Hadli m...@ti.com
 Signed-off-by: R Sivaraj siva...@ti.com
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  drivers/media/video/isp/isp.c |  118 ---
  drivers/media/video/isp/isp.h |7 +-
  drivers/media/video/isp/ispccdc.c |  146 +++
  drivers/media/video/isp/ispccdc.h |9 ++
  drivers/media/video/omap34xxcam.c |  197 
 +
  drivers/media/video/omap34xxcam.h |5 +
  6 files changed, 428 insertions(+), 54 deletions(-)
  mode change 100644 = 100755 drivers/media/video/isp/isp.c
  mode change 100644 = 100755 drivers/media/video/omap34xxcam.c
 
Your patch looks OK, but it touched drivers/media/video/omap34xxcam.c, that
doesn't exist yet on my tree, so I can't apply it.

Could you please submit first the opam34 patch on linux-me...@vger.kernel.org,
in order to allow patchwork.kernel.org to track it also, and allow me to merge
the files?

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

Re: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support

[Mauro Carvalho Chehab]

On Wed,  7 Jan 2009 11:37:50 +0530
hvaib...@ti.com wrote:

  arch/arm/mach-omap2/Kconfig |4 +
  arch/arm/mach-omap2/Makefile|1 +
  arch/arm/mach-omap2/. |  417 +++
  arch/arm/mach-omap2/board-omap3evm-dc.h |   43 
  arch/arm/mach-omap2/mux.c   |7 +
  arch/arm/plat-omap/include/mach/mux.h   |4 +


 +#if defined(CONFIG_VIDEO_TVP514X) || defined(CONFIG_VIDEO_TVP514X_MODULE)
 +#include linux/videodev2.h
 +#include media/v4l2-int-device.h
 +#include media/tvp514x.h

This smells like a V4L driver, not an arch driver. 
We shoud take some care here, to avoid having the drivers on wrong place.
The proper place on kernel tree for V4L driver is under drivers/media/video,
not under arch/arm. All other architecture-specific V4L drivers are there.

 +/* include V4L2 camera driver related header file */
 +#if defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
 +#include ../drivers/media/video/omap34xxcam.h
 +#include ../drivers/media/video/isp/ispreg.h
 +#endif   /* #ifdef CONFIG_VIDEO_OMAP3 */
 +#endif   /* #ifdef CONFIG_VIDEO_TVP514X*/

Please, don't use ../* at your includes. IMO, the better is to create a
drivers/media/video/omap dir, and put omap2/omap3 files there, including 
board-omap3evm-dc.c.
This will avoid those ugly includes.

Btw, drivers/media/video/isp/ currently doesn't exist. Please submit the patch 
for it first.

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

Re: [REVIEW] v4l2 debugging: match drivers by name instead of the deprecated ID

[Mauro Carvalho Chehab]

On Mon, 22 Dec 2008 13:28:37 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 On Monday 22 December 2008 12:11:33 Mauro Carvalho Chehab wrote:
  On Sat, 20 Dec 2008 13:45:56 +0100
 
  Hans Verkuil hverk...@xs4all.nl wrote:
   Hi all,
  
   Jean Delvare has stated repeatedly that the I2C driver IDs will have to
   go. However, one major user inside V4L2 are the VIDIOC_G_CHIP_IDENT and
   VIDIOC_DBG_G/S_REGISTER ioctls.
  
   These ioctls are meant as debugging and testing ioctls and (in the case
   of G_CHIP_IDENT) for internal use in the kernel (e.g. a bridge driver
   that needs to know which I2C chip variant is present).
  
   These ioctls should not be used in applications and luckily this is
   indeed the case. I scanned the major applications and did a google
   search and everything came up clean.
  
   I made the following changes:
  
   #define V4L2_CHIP_MATCH_HOST   0  /* Match against chip ID on host
   (0 for the host) */
   #define V4L2_CHIP_MATCH_I2C_DRIVER 1  /* Match against I2C driver name
   */ #define V4L2_CHIP_MATCH_I2C_ADDR   2  /* Match against I2C 7-bit
   address */
  
   struct v4l2_match_info {
   __u32 type; /* Match type */
   union {
   __u32 addr;
   char name[32];
   };
   } __attribute__ ((packed));
  
   struct v4l2_register {
   struct v4l2_match_info match;
   __u64 reg;
   __u64 val;
   } __attribute__ ((packed));
  
   /* VIDIOC_DBG_G_CHIP_IDENT */
   struct v4l2_chip_ident {
   struct v4l2_match_info match;
   __u32 ident;
   __u32 revision;
   } __attribute__ ((packed));
  
   So the match will now be done against either a chip address or a driver
   name.
  
   I also added additional comments in videodev2.h, warning against ever
   using it in applications:
  
   #if 1 /*KEEP*/
   /* Experimental, meant for debugging, testing and internal use.
  Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
  You must be root to use these ioctls. Never use these in
   applications! */ #define VIDIOC_DBG_S_REGISTER_IOW('V', 79, struct
   v4l2_register) #define VIDIOC_DBG_G_REGISTER   _IOWR('V', 80, struct
   v4l2_register)
  
   /* Experimental, meant for debugging, testing and internal use.
  Never use this ioctl in applications! */
   #define VIDIOC_DBG_G_CHIP_IDENT _IOWR('V', 81, struct v4l2_chip_ident)
   #endif
  
   And VIDIOC_G_CHIP_IDENT was renamed to VIDIOC_DBG_G_CHIP_IDENT, again
   to clearly mark this as a debugging API.
  
   All this is available in this tree:
   http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-drvid
 
  Seems ok to me, but, while you're there, you should add another field to
  get/set register routines, in order to provide the size of the register.
  This will allow removing some hacks at the debug application needed by
  some usb devices.
 
 Good idea. I'll do that.

Btw, I'm fixing some troubles with v4l2-dbg, and I'll add a handler for AC97
registers on em28xx. I'll probably add another type of debug - something like:

#define V4L2_CHIP_MATCH_AC97   3

For accessing the AC97 chip connected into em28xx AC97 port.

   Now, the main question I have is whether I should keep the old
   VIDIOC_G_CHIP_IDENT around for 2.6.29 with a big warning if someone
   tries to use it, or do we just change it since 1) it is marked
   experimental and for debugging purposes only, and 2) I cannot find a
   single application that uses it and even Google throws up only a
   handful of pages.
 
  IMO, return -EINVAL and print an error at dmesg.
 
 OK. Should I mark it in the feature-removal document as well for removal in 
 2.6.30? I think that would be a good idea otherwise we'll be stuck with it 
 forever.

Sure.

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

Re: [PATCH] Add OMAP2 camera driver

[Mauro Carvalho Chehab]

On Wed, 3 Dec 2008 12:35:08 +0530
Hiremath, Vaibhav [EMAIL PROTECTED] wrote:

 I can tell you that for OMAP3 we do have lot of files coming in, and it 
 really brings more confusion if we have OMAP1 and OMAP2 lying outside and 
 OMAP3 code (Display + capture) say under omap/ or omap3/.
 
 It makes sense to have omap/ directory, and all the versions/devices of OMAP 
 get handled from omap/Kconfig and omap/Makefile. Even if they have single 
 file it would be nice to follow directory layers.
 
 Hans, Sakari or Mauro can provide their opinion on this, and decide how to 
 handle this. 
 
 I am just providing details, so that it would be easy to take decision - 
 
 OMAP1 - (I have listed names from old O-L tree)
   - omap16xxcam.c
   - camera_core.c
   - camera_hw_if.h
   - omap16xxcam.h
   - camera_core.h
 
 OMAP2 - (I have listed names from old O-L tree)
   - omap24xxcam.c
   - omap24xxcam-dma.c
   - omap24xxcam.h
 
 In future may be display will add here.
 
 OMAP3 - 
   Display - (Posted twice with old DSS library)
   - omap_vout.c
   - omap_voutlib.c
   - omap_voutlib.h
   - omap_voutdef.h
   Camera - (Will come soon)
   - omap34xxcam.c
   - omap34xxcam.h
   ISP - (Will come soon)
   - Here definitely we will plenty number of files.

I prefer to have a separate directory for omap drivers. This helps to confine 
Kconfig/Makefile changes internally to the driver sub-dir, avoiding merge 
conflicts with other drivers.

Also, it helps to better organize the files.

By listening to Trilok arguments that this would be converted into just two
files for each omap version in the long run, Maybe we can just add all thee
drivers into /omap.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add OMAP2 camera driver

[Mauro Carvalho Chehab]

On Thu, 27 Nov 2008 00:14:51 +0530
Trilok Soni [EMAIL PROTECTED] wrote:

 +
 +/*
 + *
 + * DMA hardware.
 + *
 + */
 +
 +/* Ack all interrupt on CSR and IRQSTATUS_L0 */
 +static void omap24xxcam_dmahw_ack_all(unsigned long base)

Oh, no! yet another dma video buffers handling...

Soni, couldn't this be converted to use videobuf?

Each time I see a driver implementing a different buffer schema I want to cry...

Those handlers seem to be very complex and different buffers implementations
lead to different errors that requires lots of time to fix. We should really
work to improve a common buffer handler that work fine for all drivers.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add OMAP2 camera driver

[Mauro Carvalho Chehab]

On Mon, 8 Dec 2008 19:42:35 -0200
Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:

 On Thu, 27 Nov 2008 00:14:51 +0530
 Trilok Soni [EMAIL PROTECTED] wrote:
 
  +
  +/*
  + *
  + * DMA hardware.
  + *
  + */
  +
  +/* Ack all interrupt on CSR and IRQSTATUS_L0 */
  +static void omap24xxcam_dmahw_ack_all(unsigned long base)
 
 Oh, no! yet another dma video buffers handling...
 
 Soni, couldn't this be converted to use videobuf?
 

Just explaining myself: I can see two different parts on your omap driver:

1) omap specific functions (like omap register setups);

2) a scatter/gather DMA driver that seems to be tailored specifically to omap2.

I'm not sure why you didn't just use videobuf-dma-sg for (2). You should
have your reasons. 

However, instead of adding a new DMA S/G handler inside the
driver, the better would be either to:

a) patch the existing one to attend your needs; 
b) if what you need is so different than the existing driver, you may write
another videobuf-dma-sg-foo driver, clearly documenting why you couldn't use
the existing driver, and making it generic enough to be used by other drivers.

Splitting this into two files/drivers make easier for it to be analyzed and
understood.

Btw, I'm now reviewing all the patches from the pending pull request. I may
have other comments later, since this is a big series of patches, and will
require me some time to deeply inspect each one.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

[Mauro Carvalho Chehab]

On Tue, 2 Dec 2008 17:58:35 +0100
Laurent Pinchart [EMAIL PROTECTED] wrote:

  Are you meaning marking this as experimental at Kconfig? This seems too
  complex, since we'll need to test for some var on every driver that were
  converted, providing two KABI options for each converted driver (the legacy
  and the v4l2_device way). This doesn't seem to be a good idea, since will
  add a lot of extra complexity to debug bugs.
 
 Not at the Kconfig level, just in the documentation (and possible headers).

Ah, ok. Good point.

 This is a work in progress. Hans wants the changes to go mainline to get 
 broader testing, which is a valid reason, but I'd like to make sure people 
 understand that more changes are coming.

Maybe instead we should have a TODO list somewhere with the programmed changes,
especially at the subsystem core.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

[Mauro Carvalho Chehab]

On Mon, 1 Dec 2008 12:46:08 +0100
Hans Verkuil [EMAIL PROTECTED] wrote:

 Hi Mauro,
 
 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng for the 
 following:
 
 - v4l2: add v4l2_device and v4l2_subdev structs to the v4l2 framework.
 - v4l2-common: add i2c helper functions
 - cs53l32a: convert to v4l2_subdev.
 - cx25840: convert to v4l2_subdev.
 - m52790: convert to v4l2_subdev.
 - msp3400: convert to v4l2_subdev.
 - saa7115: convert to v4l2_subdev.
 - saa7127: convert to v4l2_subdev.
 - saa717x: convert to v4l2_subdev.
 - tuner: convert to v4l2_subdev.
 - upd64031a: convert to v4l2_subdev.
 - upd64083: convert to v4l2_subdev.
 - vp27smpx: convert to v4l2_subdev.
 - wm8739: convert to v4l2_subdev.
 - wm8775: convert to v4l2_subdev.
 - ivtv/ivtvfb: convert to v4l2_device/v4l2_subdev.
 
 All points raised in reviews are addressed so I think it is time to get 
 this merged so people can start to use it.
 
 Reviewed-by: Laurent Pinchart [EMAIL PROTECTED]
 Reviewed-by: Guennadi Liakhovetski [EMAIL PROTECTED]
 Reviewed-by: Andy Walls [EMAIL PROTECTED]
 Reviewed-by: David Brownell [EMAIL PROTECTED]
 
 Once this is in I'll start on converting the other i2c drivers.

Hmm.. wouldn't this break the other drivers that use the converted i2c drivers
(for example saa7115 and msp3400 are used for other drivers, like em28xx and
bttv).


Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

[Mauro Carvalho Chehab]

Hi Hans,

On Mon, 1 Dec 2008 15:24:43 +0100
Laurent Pinchart [EMAIL PROTECTED] wrote:

   I am all for pushing the changes to the v4l-dvb repository so they
   can get broader testing. I am, however, a bit more concerned about
   pushing the changes to Linus yet.
 
  They will of course go to linux-next and end up in 2.6.29 when the merge
  window opens. It's obviously not for 2.6.28.
 
 I would say 2.6.29 is a bit early, but I can live with that.

It also seems a bit early to me, but it may work. I'll try to schedule some
time this week for a deep review.

  In addition, these changes make it easier as well to use the new i2c API
  in bridge drivers (in 2.6.29 the old-style I2C probing will be
  deprecated, so we need to convert). So we get many benefits with just
  these changes.

IMO, this is one of the top priorities: the old-style i2c used on some bridge
drivers like saa7134 and cx88 are causing malfunctions that can't be easily
solved. I would like to see a fix for this for 2.6.29.

  Of course, I want to add more v4l2 framework support to these new
  structures, but I don't have any code yet for that anyway, just lots of
  ideas. Start simple, then expand.
 
   I don't know if that's possible at all, or if all changes in v4l-dvb
   are automatically selected for a push to the git repository whenever
   Mauro triggers the hg-git process.
 
  Well, they go to linux-next, but is that a problem?

I only send Linus the patches that are already ok, but I generally prefer to
postpone a merge for the end of a merge window, when the patch is not meant to
be at the next version.

 In a few months time (probably even earlier) the v4l2_device structure will 
 be 
 reworked (and possible renamed). 

Hmm... why? it would be better to try to have the KABI changes for it at the
same kernel release if possible.

 I'm fine with it going to linux-next now if 
 we agree on the following.

 - We should only advocate v4l2_device usage for subdevices-aware video 
 devices. Porting all drivers to v4l2_device is currently pointless and will 
 only make future transitions more difficult.

This makes sense to me.

 - v4l2_device should be marked as experimental. I don't want to hear any 
 API/ABI breakage argument in a few months time when the framework will 
 evolve.

Are you meaning marking this as experimental at Kconfig? This seems too
complex, since we'll need to test for some var on every driver that were
converted, providing two KABI options for each converted driver (the legacy and
the v4l2_device way). This doesn't seem to be a good idea, since will add a lot
of extra complexity to debug bugs.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Mauro Carvalho Chehab]

On Mon, 1 Dec 2008 23:44:52 +0530
Trilok Soni [EMAIL PROTECTED] wrote:

 Hi Hans,
 
 On Mon, Dec 1, 2008 at 7:21 PM, Hans Verkuil [EMAIL PROTECTED] wrote:
  Hi Mauro,
 
  Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
  following:
 
 
 I don't understand hg version control tool, but commit shows your
 name as author of this patch, whereas the patch I had sent was having
 --author field as Sakari Ailus. Could you please check this? Thanks.
 
 authorHans Verkuil [EMAIL PROTECTED]

This is one of the lack of the features on mercurial. It doesn't have a meta
tag for committer. On mercurial, the -hg user and the author should be the same
person.

Since we want to identify the patch origin (e.g. whose v4l/dvb maintainer got
the patch), we use the internal user meta-tag as the committer, and an extra
tag, at the patch description for the author (From:).

When creating the -git patch, the From: tag is replaced, by script, for
Author:, I add my SOB there, and, I add myself as the -git committer (on git
we have both meta-tags).




Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes

[Mauro Carvalho Chehab]

On Sun, 05 Oct 2008 07:57:20 -0400
Robert William Fuller [EMAIL PROTECTED] wrote:

  The 80 column rule isn't there for nothing.
 There are legitimate reasons to have lines longer than 80 columns.

True. That's why this is a warning.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes

[Mauro Carvalho Chehab]

On Fri, 3 Oct 2008 20:10:36 +0530
Shah, Hardik [EMAIL PROTECTED] wrote:


  2) Can you describe what the non-standard v4l2 ioctls are used for? I
  suspect that some of these can be done differently. Something like a
  chromakey is already available in v4l2 (through VIDIOC_G/S_FBUF and
  VIDIOC_G/S_FMT), things like mirror is available as a control, and
  rotation should perhaps be a control as well. Ditto for background
  color. These are just ideas, it depends on how it is used exactly.
 [Shah, Hardik] Hans I will revisit the code and will provide you with the 
 sufficient information.

I don't like the idea of having private ioctls. This generally means that only
a very restricted subset of userspace apps that are aware of the that API will
work. This is really bad.

So, I prefer to discuss the need for newer ioctls and add it into the standard
whenever make some sense (ok, maybe you might have some ioctls that are really
very specific for your app and that won't break userspace apps - I've acked
with 2 private ioctls on uvc driver in the past due to that).

  3) Some of the lines are broken up rather badly probably to respect the
  80 column maximum. Note that the 80 column maximum is a recommendation,
  and that readability is more important. So IMHO it's better to have a
  slightly longer line and break it up at a more logical place. However,
  switching to video_ioctl2 will automatically reduce the indentation, so
  this might not be that much of an issue anymore.
 [Shah, Hardik] 80 column was implemented to make the checkpatch pass.  Point 
 noted and will take care of this.

The 80 column rule isn't there for nothing.

It is a sort of checking if some common bad practices aren't used inside the
drivers, like having lots of indentation levels inside the functions, or long
(Pascal like) names for vars.

So, if you are having several points where you're violating the rule, probably
your code is very complex or you are using long names instead of short ones. On
the fisrt case, try to break the complex stuff  into smaller and simpler static
functions. The compiler will deal with those functions like inline, so this
won't cost cpu cycles, but it will make easier for people to understand what
you're doing.

  It is possible to setup a mercurial repository on linuxtv.org? I thought
  that Manju has an account by now.

I don't remember if I created an account for Manju. If not, please ping me. I
prefer to not setup an account for every single developer, since LinuxTV
machine is not meant to be a host server.

Perhaps the better would be for you to have one public machine where you all
can work and merge your work. I'm OK on pulling and seeing patches outside 
LinuxTV.

  This is useful as well for all the
  other omap camera patches. I've seen omap patches popping up all over
  the place for the past six months (if not longer) but it needs to be a
  bit more organized if you want it to be merged. Setting up v4l-dvb
  repositories containing the new patches is a good way of streamlining
  the process.
  
  Obviously the process is more complicated for you since the omap stuff
  relies on various subsystems and platform code. Perhaps someone within
  TI should be coordinating this?
 [Shah, Hardik] we are in process of coordinating this.

One option in the future is to base your work on a git tree. I've changed a lot
the proccess of submitting patches upstream, to avoid having to rebase my tree
(Yet, I had to do two rebases during 2.6.27 cycle). If I can keep my tree
without rebase, the developers may rely on it and start sending me git pull
requests also. Let's see if I can do this for 2.6.28.

I think we should start discussing using git trees as the reference for
v4l/dvb development, and start moving developers tree to git. This would solve
the issues with complex projects like OMAP, where you need to touch not only on
V4L/DVB subsystem.

This topic deserves some more discussion, 

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html