RE: [PATCH] [media] davinci: vpfe: Add documentation
Laurent,
Thank you for your comments.
On Thu, Jul 26, 2012 at 05:55:31, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
> > On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
> > > On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
> > > > Add documentation on the Davinci VPFE driver. Document the subdevs,
> > > > and private IOTCLs the driver implements
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > Signed-off-by: Lad, Prabhakar
>
> [snip]
>
> > > > +Private IOCTLs
> > > > +==
> > > > +
> > > > +The Davinci Video processing Front End (VPFE) driver supports standard
> > > > V4L2 +IOCTLs and controls where possible and practical. Much of the
> > > > functions provided
> > > > +by the VPFE, however, does not fall under the standard IOCTLs.
> > > > +
> > > > +In general, there is a private ioctl for configuring each of the blocks
> > > > +containing hardware-dependent functions.
> > > > +
> > > > +The following private IOCTLs are supported:
> > > > +
> > > > +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> > > > +Description:
> > > > + Sets/Gets the parameters required by the previewer module
> > > > +Parameter:
> > > > + /**
> > > > +* struct prev_module_param- structure to configure preview
> > > > modules
> > > > +* @version: Version of the preview module
> > >
> > > Who is responsible for filling this field, the application or the driver ?
> >
> > The application is responsible for filling this info. He would enumerate the
> > capabilities first and set them using S_PARAM/G_PARAM.
>
> And what's the point of the application setting the version field ? How does
> the driver use it ?
The version may not be required. Will remove it.
>
> > > > +* @len: Length of the module config structure
> > > > +* @module_id: Module id
> > > > +* @param: pointer to module config parameter.
> > >
> > > What is module_id for ? What does param point to ?
> >
> > There are a lot of tiny modules in the previewer/resizer which are
> > enumerated as individual modules. The param points to the parameter set
> > that the module expects to be set.
>
> Why don't you implement something similar to
> VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?
I feel if we implement direct IOCTLS there might be many of them. To make sure
than independent of the number of internal modules present, having the same
IOCTL used for all modules is a good idea.
>
> > > > +*/
> > > > + struct prev_module_param {
> > > > + char version[IMP_MAX_NAME_SIZE];
> > >
> > > Is there a need to express the version as a string instead of an integer ?
> >
> > It could be integer. It is generally a fixed point num, and easy to read it
> > as a string than an integer. Can I keep it as a string?
>
> Let's first decide whether a version field is needed at all :-)
Will remove.
>
> > > > + unsigned short len;
> > > > + unsigned short module_id;
> > > > + void *param;
> > > > + };
> > > > +
> > > > +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
> > > > +Description:
> > > > + Sets/Gets the configuration required by the previewer channel
> > > > +Parameter:
> > > > + /**
> > > > +* struct prev_channel_config - structure for configuring the
> > > > previewer
> > > > channel
> > > > +* @len: Length of the user configuration
> > > > +* @config: pointer to either single shot config or continuous
> > > > +*/
> > > > + struct prev_channel_config {
> > > > + unsigned short len;
> > > > + void *config;
> > > > + };
> > >
> > > What's the difference between parameters and configuration ? What does
> > > config point to ?
> >
> > Config is setting which is required for a subdev to function based on what
> > it is set for (single shot/continuous.) common to all platforms. Parameters
> > are the settings for individual small sub-ips which might be slightly
> > different from one
RE: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Laurent, On Wed, Jul 18, 2012 at 16:35:18, Laurent Pinchart wrote: > Hi Manjunath, > > On Tuesday 17 July 2012 12:22:42 Hadli, Manjunath wrote: > > On Tue, Jul 17, 2012 at 17:25:42, Laurent Pinchart wrote: > > > On Tuesday 17 July 2012 11:41:11 Hadli, Manjunath wrote: > > > > On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: > > > > > On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: > > > > > > add new enum entries for supporting the media-bus formats on dm365. > > > > > > These include some bayer and some non-bayer formats. > > > > > > V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > > > > > internal to the hardware by the resizer. > > > > > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > > > > > that is supported by dm365 hardware. > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > Cc: Laurent Pinchart > > > > > > Cc: Sakari Ailus > > > > > > Cc: Hans Verkuil > > > > > > --- > > > > > > > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 171 > > > > > > > > > > > > include/linux/v4l2-mediabus.h | 10 +- > > > > > > 2 files changed, 179 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > > > > 49c532e..48d92bb > > > > > > 100644 > > > > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > > [snip] > > > > > > > > > @@ -965,6 +1036,56 @@ > > > > > > > > > > > > y1 > > > > > > y0 > > > > > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > That's a weird one. Just out of curiosity, what's the point of > > > > > transferring chroma information without luma ? > > > > > > > > DM365 supports this format. > > > > > > Right, but what is it used for ? > > > > Sorry about that. The Resizer in Dm365 can take only chroma and resize the > > buffer. It can also take luma of course. In general it can take UV8, Y8 and > > also UYVY. > > So UV8 is used to resize an NV buffer in two passes (first Y8 then UV8) ? > No. The resizer can take has a capability to resize UV8 alone. Apart from this I don't see any use case for UV8. (Hans, Sakari, Guennadi, any opinion on exposing UV8 to user?) > > > [snip] > > > > > > > > > @@ -2415,6 +2536,56 @@ > > > > > > > > > > > > u1 > > > > > > u0 > > > > > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > What is this beast ? We at least need a textual description, as I have > > > > > no > > > > > idea what the format corresponds to. > > > > > > > > This was discussed earlier over here > > > > http://patchwork.linuxtv.org/patch/8843/ > > > > > > My bad, I should have remembered that. Please add a textual description of > > > the format, it's not clear from the name what D and C are. > > > > I see no description for individual MBUS formats but a collective para on > > everything together. Would you like me to add in the same or otherwise can > > you point to me where I can add this description? > > What about the following patch ? Note that I've renamed YDYC to YDYU, as we > might later need a YDYV format. > > (Hans, Sakari, any opinion ?) > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > b/Documentation/DocBook/media/v4l/subdev-formats.xml > index 49c532e..47a485e 100644 > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > @@ -853,10 +853,15 @@ >Packed YUV Formats > >Those data formats transfer pixel data as (possibly downsampled) > Y, U > - and
RE: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Laurent, On Tue, Jul 17, 2012 at 17:25:42, Laurent Pinchart wrote: > Hi Manjunath, > > On Tuesday 17 July 2012 11:41:11 Hadli, Manjunath wrote: > > On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: > > > On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: > > > > add new enum entries for supporting the media-bus formats on dm365. > > > > These include some bayer and some non-bayer formats. > > > > V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > > > internal to the hardware by the resizer. > > > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > > > that is supported by dm365 hardware. > > > > > > > > Signed-off-by: Manjunath Hadli > > > > Cc: Laurent Pinchart > > > > Cc: Sakari Ailus > > > > Cc: Hans Verkuil > > > > --- > > > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 171 > > > > include/linux/v4l2-mediabus.h | 10 +- > > > > 2 files changed, 179 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > > 49c532e..48d92bb > > > > 100644 > > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > [snip] > > > > > @@ -965,6 +1036,56 @@ > > > > y1 > > > > y0 > > > > > > > > + > > > > > > That's a weird one. Just out of curiosity, what's the point of > > > transferring chroma information without luma ? > > > > DM365 supports this format. > > Right, but what is it used for ? > Sorry about that. The Resizer in Dm365 can take only chroma and resize the buffer. It can also take luma of course.In general it can take UV8, Y8 and also UYVY. > [snip] > > > > > @@ -2415,6 +2536,56 @@ > > > > u1 > > > > u0 > > > > > > > > + > > > > > > What is this beast ? We at least need a textual description, as I have no > > > idea what the format corresponds to. > > > > This was discussed earlier over here > > http://patchwork.linuxtv.org/patch/8843/ > > My bad, I should have remembered that. Please add a textual description of > the > format, it's not clear from the name what D and C are. > I see no description for individual MBUS formats but a collective para on everything together. Would you like me to add in the same or otherwise can you point to me where I can add this description? Thx, --Manju > -- > 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
RE: [PATCH v4 2/2] v4l2: add new pixel formats supported on dm365
Hi Laurent,
On Tue, Jul 17, 2012 at 16:29:44, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thank you for the patch.
>
> A couple of comments below.
>
> On Friday 30 March 2012 10:09:14 Hadli, Manjunath wrote:
> > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
> > to represent Bayer format frames compressed by A-LAW algorithm,
> > add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
> > only.
> >
> > Signed-off-by: Manjunath Hadli
> > Cc: Laurent Pinchart
> > Cc: Sakari Ailus
> > Cc: Hans Verkuil
> > ---
> > .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
> > Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
> > Documentation/DocBook/media/v4l/pixfmt.xml |
> > 2 +
> > include/linux/videodev2.h |8 +++
> > 4 files changed, 106 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> >
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode
> > 100644
> > index 000..9b5c80d
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > @@ -0,0 +1,34 @@
> > +
> > +
> > +
> > + V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
> > + V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
> > + V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
> > + V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
> > +
> > + &manvol;
> > +
> > +
> > +
> > + V4L2_PIX_FMT_SRGGB10ALAW8
> > +
> > +
> > + V4L2_PIX_FMT_SGRBG10ALAW8
> > +
> > +
> > + V4L2_PIX_FMT_SGBRG10ALAW8
> > +
> > +
> > + V4L2_PIX_FMT_SBGGR10ALAW8
> > +
> > + 10-bit Bayer formats compressed to 8 bits
> > +
> > +
> > + Description
> > + The following four pixel formats are raw sRGB / Bayer
> > + formats with 10 bits per colour compressed to 8 bits each,
> > + using the A-LAW algorithm. Each colour component consumes 8
> > + bits of memory. In other respects this format is similar to
> > + .
> > +
> > +
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> > b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644
> > index 000..c507c1f
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> > @@ -0,0 +1,62 @@
> > +
> > +
> > + V4L2_PIX_FMT_UV8 ('UV8')
> > + &manvol;
> > +
> > +
> > + V4L2_PIX_FMT_UV8
> > + UV plane interleaved
> > +
> > +
> > + Description
> > + In this format there is no Y plane, Only CbCr plane. ie
> > + (UV interleaved)
> > +
> > +
> > + V4L2_PIX_FMT_UV8
> > + pixel image
> > +
> > +
> > +
> > + Byte Order.
> > + Each cell is one byte.
> > +
> > +
> > +
> > +
> > +
> > + start + 0:
> > + Cb00
> > + Cr00
> > + Cb01
> > + Cr01
> > +
> > +
> > + start + 4:
> > + Cb10
> > + Cr10
> > + Cb11
> > + Cr11
> > +
> > +
> > + start + 8:
> > + Cb20
> > + Cr20
> > + Cb21
> > + Cr21
> > +
> > +
> > + start + 12:
> > + Cb30
> > + Cr30
> > + Cb31
> > + Cr31
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
> > b/Documentation/DocBook/media/v4l/pixfmt.xml index 74d4fcd..9dc3024 100644
> > ---
RE: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Laurent, Thanks for the review. On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: > Hi Manjunath, > > Thank you for the patch. > > Just some nitpicking, please see below. > > On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: > > add new enum entries for supporting the media-bus formats on dm365. > > These include some bayer and some non-bayer formats. > > V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > internal to the hardware by the resizer. > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > that is supported by dm365 hardware. > > > > Signed-off-by: Manjunath Hadli > > Cc: Laurent Pinchart > > Cc: Sakari Ailus > > Cc: Hans Verkuil > > --- > > Documentation/DocBook/media/v4l/subdev-formats.xml | 171 + > > include/linux/v4l2-mediabus.h | 10 +- > > 2 files changed, 179 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb > > 100644 > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > @@ -356,6 +356,9 @@ > > If the pixel components are DPCM-compressed, a mention > > of > > the DPCM compression and the number of bits per compressed pixel > > component. > > + If the pixel components are ALAW-compressed, a mention > > of > > the > > + ALAW compression and the number of bits per compressed pixel > > component. > > + > > I would group ALAW and DPCM compression, as they're mutally exclusive. > Something like > > transferred on the same number of bits. Common values are 8, 10 and 12. > > > - If the pixel components are DPCM-compressed, a mention of > - the DPCM compression and the number of bits per compressed pixel > - component. > - > + The compression (optional). If the pixel components are > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > + number of bits per compressed pixel component. > The number of bus samples per pixel. Pixels that are wider > than the bus width must be transferred in multiple samples. Common values > are 1 and 2. > Ok. > > > The number of bus samples per pixel. Pixels that are > wider > > than the bus width must be transferred in multiple samples. Common values > > are 1 and 2. > > @@ -572,6 +575,74 @@ > > r1 > > r0 > > > > + > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 > > + 0x3015 > > + > > + - > > + - > > + - > > + - > > + b7 > > + b6 > > + b5 > > + b4 > > + b3 > > + b2 > > + b1 > > + b0 > > + > > + > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 > > + 0x3016 > > + > > + - > > + - > > + - > > + - > > + g7 > > + g6 > > + g5 > > + g4 > > + g3 > > + g2 > > + g1 > > + g0 > > + > > + > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 > > + 0x3017 > > + > > + - > > + - > > + - > > + - > > + g7 > > + g6 > > + g5 > > + g4 > > + g3 > > + g2 > > + g1 > > + g0 > > + > > + > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 > > + 0x3018 > > + > > + - > > + - > > + - > > + - > > + r7 > > + r6 > > + r5 > > + r4 > > + r3 > > + r2 > > + r1 > > + r0 > > + > > Please move the ALAW formats above the DPCM formats to keep them > alphabetically sorted. > Ok. > > > > V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE > > 0x3003 > > @@ -965,6 +1036,56 @@ > > y1 > > y0 > > > > + > > That's a weird one. Just out of curiosity, what's the point of transferring > chroma information without luma ? > DM365 supports th
RE: [PATCH] [media] davinci: vpfe: Add documentation
Hi Laurent,
Thank you for your comments.
On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thanks for the patch.
>
> On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
> > Add documentation on the Davinci VPFE driver. Document the subdevs,
> > and private IOTCLs the driver implements
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Lad, Prabhakar
> > ---
> > Documentation/video4linux/davinci-vpfe-mc.txt | 263
> > + 1 files changed, 263 insertions(+), 0
> > deletions(-)
> > create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
> >
> > diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
> > b/Documentation/video4linux/davinci-vpfe-mc.txt new file mode 100644
> > index 000..968194f
> > --- /dev/null
> > +++ b/Documentation/video4linux/davinci-vpfe-mc.txt
> > @@ -0,0 +1,263 @@
> > +Davinci Video processing Front End (VPFE) driver
> > +
> > +Copyright (C) 2012 Texas Instruments Inc
> > +
> > +Contacts: Manjunath Hadli
> > +
> > +Introduction
> > +
> > +
> > +This file documents the Texas Instruments Davinci Video processing Front
> > End
> > +(VPFE) driver located under drivers/media/video/davinci. The original
> > driver
> > +exists for Davinci VPFE, which is now being changed to Media Controller
> > +Framework.
> > +
> > +Currently the driver has been successfully used on the following version of
> > Davinci:
> > +
> > + DM365/DM368
>
> Does the driver still support the DM644x ?
Yes. The driver supports DM6446. We will add the Dm6446x patches on these.
>
> > +The driver implements V4L2, Media controller and v4l2_subdev interfaces.
> > +Sensor, lens and flash drivers using the v4l2_subdev interface in the
> > kernel
> > +are supported.
> > +
> > +
> > +Split to subdevs
> > +
> > +
> > +The Davinic VPFE is split into V4L2 subdevs, each of the blocks inside the
>
> s/Davinic/Davinci/
OK. Thanks.
>
> > VPFE
> > +having one subdev to represent it. Each of the subdevs provide a V4L2
> > subdev
> > +interface to userspace.
> > +
> > + DAVINCI CCDC
> > + DAVINCI PREVIEWER
> > + DAVINCI RESIZER
>
> the DM36x VPFE documentation doesn't split the hardware in CCDC, PREVIEWER
> and
> RESIZER modules, but in ISIF, IPIPEIF and IPIPE. Why don't you use those
> names
> ? It looks like you're introducing an abstraction layer on top of the
> existing
> driver. Why is that needed, why don't you just port the driver to the MC API
> instead ?
Please see below my comment for "enumerating internal modules".
>
> > + DAVINCI AEW
> > + DAVINCI AF
> > +
> > +Each possible link in the VPFE is modeled by a link in the Media controller
> > +interface. For an example program see [1].
> > +
> > +
> > +Private IOCTLs
> > +==
> > +
> > +The Davinci Video processing Front End (VPFE) driver supports standard V4L2
> > +IOCTLs and controls where possible and practical. Much of the functions
> > provided
> > +by the VPFE, however, does not fall under the standard IOCTLs.
> > +
> > +In general, there is a private ioctl for configuring each of the blocks
> > +containing hardware-dependent functions.
> > +
> > +The following private IOCTLs are supported:
> > +
> > +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> > +Description:
> > + Sets/Gets the parameters required by the previewer module
> > +Parameter:
> > + /**
> > +* struct prev_module_param- structure to configure preview modules
> > +* @version: Version of the preview module
>
> Who is responsible for filling this field, the application or the driver ?
The application is responsible for filling this info. He would enumerate the
capabilities first and set them using S_PARAM/G_PARAM.
>
> > +* @len: Length of the module config structure
> > +* @module_id: Module id
> > +* @param: pointer to module config parameter.
>
> What is module_id for ? What does param point to ?
There are a lot of tiny modules in the previewer/resizer which are enumerated
as individual modules. The param points to the parameter set that the module
expects to be set.
>
> > +*/
> > + struct prev_module_param {
> > + char version[IMP_MAX_NAME_SIZE];
>
> Is there a need to express the version as a string instead of an integer ?
It could be integer. It is generally a fixed point num, and easy to read it
as a string than an integer. Can I keep it as a string?
>
> > + unsigned short len;
> > + unsigned short module_id;
> > + void *param;
> > + };
> > +
> > +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
> > +Description:
> > + Sets/Gets the configuration required by the previewer channel
> > +Parameter:
> > + /**
> > +* struct prev_channel_config - structure for configuring the previewer
> > channel
> > +* @len: Length of the user configuration
> > +* @config: pointer to either single shot config or continuous
> > +*/
> > + struct prev_channel_config {
> > + unsigne
RE: [GIT PULL FOR v3.5] davicni: vpfe:media controller based capture driver for dm365
Hi Mauro, On Thu, Jul 05, 2012 at 22:17:10, Mauro Carvalho Chehab wrote: > Em 04-07-2012 02:01, Hadli, Manjunath escreveu: > > Mauro, > > Can you please pull the patches? Let me know if anything needs to be done > > from my side. > > > > -Manju > > > > > > On Thu, May 31, 2012 at 17:42:24, Hadli, Manjunath wrote: > >> Mauro, > >> The following patch set adds the media controller based driver TI dm365 > >> SoC. > >> Patches have gone through RFC and reviews and are pending for some time. > >> > >> The main support added here: > >> -CCDC capture > >> -Previewer > >> -Resizer > >> -AEW/AF > >> -Some media formats supported on dm365 > >> -PIX_FORMATs supported on dm365 > >> > >> > >> --- > >> The following changes since commit > >> a01ee165a132fadb57659d26246e340d6ac53265: > >> > >>Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd > >> (2012-05-28 13:10:41 -0700) > >> > >> are available in the git repository at: > >> > >>git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git > >> pull_dm365_mc_for_mauro > >> > >> Manjunath Hadli (19): > >>media: add new mediabus format enums for dm365 > >>v4l2: add new pixel formats supported on dm365 > >>davinci: vpfe: add dm3xx IPIPEIF hardware support module > >>davinci: vpfe: add IPIPE hardware layer support > >>davinci: vpfe: add IPIPE support for media controller driver > > $ grep copy_ `quilt next`|wc -l > 53 > > Wow! There's a lot of undocumented userspace API stuff there! Am I missing > something? > As discussed on IRC, I'll send a documentation patch to the mailing list and on acceptance of this patch I'll issue a new pull request along with the documentation patch and current patch set. Thx, --Manju > Regards, > Mauro > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL FOR v3.5] davicni: vpfe:media controller based capture driver for dm365
Mauro, Can you please pull the patches? Let me know if anything needs to be done from my side. -Manju On Thu, May 31, 2012 at 17:42:24, Hadli, Manjunath wrote: > Mauro, > The following patch set adds the media controller based driver TI dm365 SoC. > Patches have gone through RFC and reviews and are pending for some time. > > The main support added here: > -CCDC capture > -Previewer > -Resizer > -AEW/AF > -Some media formats supported on dm365 > -PIX_FORMATs supported on dm365 > > > --- > The following changes since commit a01ee165a132fadb57659d26246e340d6ac53265: > > Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd > (2012-05-28 13:10:41 -0700) > > are available in the git repository at: > > git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git pull_dm365_mc_for_mauro > > Manjunath Hadli (19): > media: add new mediabus format enums for dm365 > v4l2: add new pixel formats supported on dm365 > davinci: vpfe: add dm3xx IPIPEIF hardware support module > davinci: vpfe: add IPIPE hardware layer support > davinci: vpfe: add IPIPE support for media controller driver > davinci: vpfe: add support for CCDC hardware for dm365 > davinci: vpfe: add ccdc driver with media controller interface > davinci: vpfe: add v4l2 video driver support > davinci: vpfe: v4l2 capture driver with media interface > davinci: vpfe: previewer driver based on v4l2 media controller framework > davinci: vpfe: resizer driver based on media framework > davinci: vpfe: add DM365 autofoucus(AF) hardware interface > davinci: vpfe: add autofocus driver based on media framework > davinci: vpfe: add hardware interface for dm365 aew > davinci: vpfe: add aew driver based on v4l2 media framework > dm365: vpss: setup ISP registers > dm365: vpss: set vpss clk ctrl > dm365: vpss: add helper functions for setting hardware parameters used > by main driver > davinci: vpfe: build infrastructure for dm365 > > .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 + > Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 + > Documentation/DocBook/media/v4l/pixfmt.xml |2 + > Documentation/DocBook/media/v4l/subdev-formats.xml | 171 + > drivers/media/video/davinci/Kconfig| 72 +- > drivers/media/video/davinci/Makefile | 17 + > drivers/media/video/davinci/ccdc_hw_device.h |2 +- > drivers/media/video/davinci/dm355_ccdc.c |2 +- > drivers/media/video/davinci/dm365_a3_hw.c | 389 ++ > drivers/media/video/davinci/dm365_a3_hw.h | 253 ++ > drivers/media/video/davinci/dm365_aew.c| 544 +++ > drivers/media/video/davinci/dm365_aew.h| 55 + > drivers/media/video/davinci/dm365_af.c | 563 +++ > drivers/media/video/davinci/dm365_af.h | 59 + > drivers/media/video/davinci/dm365_ccdc.c | 1453 > drivers/media/video/davinci/dm365_ccdc.h | 91 + > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ > drivers/media/video/davinci/dm365_def_para.c | 310 ++ > drivers/media/video/davinci/dm365_def_para.h | 39 + > drivers/media/video/davinci/dm365_ipipe.c | 3844 > > drivers/media/video/davinci/dm365_ipipe.h | 378 ++ > drivers/media/video/davinci/dm365_ipipe_hw.c | 935 + > drivers/media/video/davinci/dm365_ipipe_hw.h | 539 +++ > drivers/media/video/davinci/dm3xx_ipipeif.c| 313 ++ > drivers/media/video/davinci/dm3xx_ipipeif.h| 256 ++ > drivers/media/video/davinci/dm644x_ccdc.c |2 +- > drivers/media/video/davinci/imp_common.h | 87 + > drivers/media/video/davinci/imp_hw_if.h| 170 + > drivers/media/video/davinci/isif.c |2 +- > drivers/media/video/davinci/vpfe_aew.c | 238 ++ > drivers/media/video/davinci/vpfe_aew.h | 51 + > drivers/media/video/davinci/vpfe_af.c | 240 ++ > drivers/media/video/davinci/vpfe_af.h | 47 + > drivers/media/video/davinci/vpfe_capture.c |2 +- > drivers/media/video/davinci/vpfe_ccdc.c| 817 + > drivers/media/video/davinci/vpfe_ccdc.h| 86 + > drivers/media/video/davinci/vpfe_mc_capture.c | 801 > drivers/media/video/davinci/vpfe_mc_capture.h | 99 + > drivers/media/video/davinci/vpfe_previewer.c | 1066 ++ > drivers/media/video/davinci/vpfe_previewer.h | 65 + > drivers/media/video/davinci/vpfe_resizer.c | 1076 ++ > drivers/med
RE: [PATCH v3 09/13] davinci: vpif display: Add power management support
Hi Laurent,
On Mon, Jun 25, 2012 at 18:26:22, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thank you for the patch.
>
> On Monday 25 June 2012 16:37:31 Manjunath Hadli wrote:
> > Implement power management operations - suspend and resume as part of
> > dev_pm_ops for VPIF display driver.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Lad, Prabhakar
> > ---
> > drivers/media/video/davinci/vpif_display.c | 75 +
> > 1 files changed, 75 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/davinci/vpif_display.c
> > b/drivers/media/video/davinci/vpif_display.c index 4436ef6..7408733 100644
> > --- a/drivers/media/video/davinci/vpif_display.c
> > +++ b/drivers/media/video/davinci/vpif_display.c
> > @@ -1807,10 +1807,85 @@ static int vpif_remove(struct platform_device
> > *device) return 0;
> > }
> >
> > +#ifdef CONFIG_PM
> > +static int vpif_suspend(struct device *dev)
> > +{
> > + struct common_obj *common;
> > + struct channel_obj *ch;
> > + int i;
> > +
> > + for (i = 0; i < VPIF_DISPLAY_MAX_DEVICES; i++) {
> > + /* Get the pointer to the channel object */
> > + ch = vpif_obj.dev[i];
> > + common = &ch->common[VPIF_VIDEO_INDEX];
> > + if (mutex_lock_interruptible(&common->lock))
> > + return -ERESTARTSYS;
>
> I might be wrong, but I don't think the suspend/resume handlers react
> correctly to -ERESTARTSYS. If that's correct you should use mutex_lock()
> instead of mutex_lock_interruptible().
>
I'll replace it with mutex_lock().
Thx,
--Manju
> > +
> > + if (atomic_read(&ch->usrs) && common->io_usrs) {
> > + /* Disable channel */
> > + if (ch->channel_id == VPIF_CHANNEL2_VIDEO) {
> > + enable_channel2(0);
> > + channel2_intr_enable(0);
> > + }
> > + if (ch->channel_id == VPIF_CHANNEL3_VIDEO ||
> > + common->started == 2) {
> > + enable_channel3(0);
> > + channel3_intr_enable(0);
> > + }
> > + }
> > + mutex_unlock(&common->lock);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int vpif_resume(struct device *dev)
> > +{
> > +
> > + struct common_obj *common;
> > + struct channel_obj *ch;
> > + int i;
> > +
> > + for (i = 0; i < VPIF_DISPLAY_MAX_DEVICES; i++) {
> > + /* Get the pointer to the channel object */
> > + ch = vpif_obj.dev[i];
> > + common = &ch->common[VPIF_VIDEO_INDEX];
> > + if (mutex_lock_interruptible(&common->lock))
> > + return -ERESTARTSYS;
> > +
> > + if (atomic_read(&ch->usrs) && common->io_usrs) {
> > + /* Enable channel */
> > + if (ch->channel_id == VPIF_CHANNEL2_VIDEO) {
> > + enable_channel2(1);
> > + channel2_intr_enable(1);
> > + }
> > + if (ch->channel_id == VPIF_CHANNEL3_VIDEO ||
> > + common->started == 2) {
> > + enable_channel3(1);
> > + channel3_intr_enable(1);
> > + }
> > + }
> > + mutex_unlock(&common->lock);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct dev_pm_ops vpif_pm = {
> > + .suspend= vpif_suspend,
> > + .resume = vpif_resume,
> > +};
> > +
> > +#define vpif_pm_ops (&vpif_pm)
> > +#else
> > +#define vpif_pm_ops NULL
> > +#endif
> > +
> > static __refdata struct platform_driver vpif_driver = {
> > .driver = {
> > .name = "vpif_display",
> > .owner = THIS_MODULE,
> > + .pm = vpif_pm_ops,
> > },
> > .probe = vpif_probe,
> > .remove = vpif_remove,
> --
> 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
RE: [PATCH v3 10/13] davinci: vpif capture:Add power management support
Hi Laurent,
On Mon, Jun 25, 2012 at 18:27:23, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thank you for the patch.
>
> On Monday 25 June 2012 16:37:32 Manjunath Hadli wrote:
> > Implement power management operations - suspend and resume as part of
> > dev_pm_ops for VPIF capture driver.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Lad, Prabhakar
> > ---
> > drivers/media/video/davinci/vpif_capture.c | 77 +
> > 1 files changed, 65 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/media/video/davinci/vpif_capture.c
> > b/drivers/media/video/davinci/vpif_capture.c index 097e136..f1ee137
> > 100644
> > --- a/drivers/media/video/davinci/vpif_capture.c
> > +++ b/drivers/media/video/davinci/vpif_capture.c
> > @@ -2300,26 +2300,74 @@ static int vpif_remove(struct platform_device
> > *device) return 0;
> > }
> >
> > +#ifdef CONFIG_PM
> > /**
> > * vpif_suspend: vpif device suspend
> > - *
> > - * TODO: Add suspend code here
> > */
> > -static int
> > -vpif_suspend(struct device *dev)
> > +static int vpif_suspend(struct device *dev)
> > {
> > - return -1;
> > +
> > + struct common_obj *common;
> > + struct channel_obj *ch;
> > + int i;
> > +
> > + for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
> > + /* Get the pointer to the channel object */
> > + ch = vpif_obj.dev[i];
> > + common = &ch->common[VPIF_VIDEO_INDEX];
> > + if (mutex_lock_interruptible(&common->lock))
> > + return -ERESTARTSYS;
>
> As for the display driver, this should probably be replaced by mutex_lock().
>
Ok, I'll replace it with mutex_lock().
Thx,
--Manju
> > + if (ch->usrs && common->io_usrs) {
> > + /* Disable channel */
> > + if (ch->channel_id == VPIF_CHANNEL0_VIDEO) {
> > + enable_channel0(0);
> > + channel0_intr_enable(0);
> > + }
> > + if (ch->channel_id == VPIF_CHANNEL1_VIDEO ||
> > + common->started == 2) {
> > + enable_channel1(0);
> > + channel1_intr_enable(0);
> > + }
> > + }
> > + mutex_unlock(&common->lock);
> > + }
> > +
> > + return 0;
> > }
> >
> > -/**
> > +/*
> > * vpif_resume: vpif device suspend
> > - *
> > - * TODO: Add resume code here
> > */
> > -static int
> > -vpif_resume(struct device *dev)
> > +static int vpif_resume(struct device *dev)
> > {
> > - return -1;
> > + struct common_obj *common;
> > + struct channel_obj *ch;
> > + int i;
> > +
> > + for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
> > + /* Get the pointer to the channel object */
> > + ch = vpif_obj.dev[i];
> > + common = &ch->common[VPIF_VIDEO_INDEX];
> > + if (mutex_lock_interruptible(&common->lock))
> > + return -ERESTARTSYS;
> > +
> > + if (ch->usrs && common->io_usrs) {
> > + /* Disable channel */
> > + if (ch->channel_id == VPIF_CHANNEL0_VIDEO) {
> > + enable_channel0(1);
> > + channel0_intr_enable(1);
> > + }
> > + if (ch->channel_id == VPIF_CHANNEL1_VIDEO ||
> > + common->started == 2) {
> > + enable_channel1(1);
> > + channel1_intr_enable(1);
> > + }
> > + }
> > + mutex_unlock(&common->lock);
> > + }
> > +
> > + return 0;
> > }
> >
> > static const struct dev_pm_ops vpif_dev_pm_ops = { @@ -2327,11
> > +2375,16 @@ static const struct dev_pm_ops vpif_dev_pm_ops = {
> > .resume = vpif_resume,
> > };
> >
> > +#define vpif_pm_ops (&vpif_dev_pm_ops) #else #define vpif_pm_ops NULL
> > +#endif
> > +
> > static __refdata struct platform_driver vpif_driver = {
> > .driver = {
> > .name = "vpif_capture",
> > .owner = THIS_MODULE,
> > - .pm = &vpif_dev_pm_ops,
> > + .pm = vpif_pm_ops,
> > },
> > .probe = vpif_probe,
> > .remove = vpif_remove,
> --
> 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
RE: [PATCH v3 04/13] davinci: vpif: fix setting of data width in config_vpif_params() function
Hi Sergei, On Tue, Jun 26, 2012 at 16:06:01, Sergei Shtylyov wrote: > Hello. > > On 25-06-2012 15:07, Manjunath Hadli wrote: > > > fix setting of data width in config_vpif_params() function, > > which was wrongly set. > > > Signed-off-by: Manjunath Hadli > > Signed-off-by: Lad, Prabhakar > > --- > > drivers/media/video/davinci/vpif.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/drivers/media/video/davinci/vpif.c > > b/drivers/media/video/davinci/vpif.c > > index 774bcd3..08fb81f 100644 > > --- a/drivers/media/video/davinci/vpif.c > > +++ b/drivers/media/video/davinci/vpif.c > > @@ -346,7 +346,7 @@ static void config_vpif_params(struct vpif_params > > *vpifparams, > > > > value = regr(reg); > > /* Set data width */ > > - value&= ((~(unsigned int)(0x3))<< > > + value&= ~(((unsigned int)(0x3))<< > > Why not just 0x3u instead of (unsigned int)(0x3)? > Ok. Thx, --Manju > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 08/13] davinci: vpif: add support for clipping on output data
Hi,
On Mon, Jun 25, 2012 at 18:53:20, Hans Verkuil wrote:
> On Mon 25 June 2012 15:18:41 Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Monday 25 June 2012 15:08:10 Hans Verkuil wrote:
> > > On Mon 25 June 2012 14:54:39 Laurent Pinchart wrote:
> > > > On Monday 25 June 2012 16:37:30 Manjunath Hadli wrote:
> > > > > add hardware clipping support for VPIF output data. This
> > > > > is needed as it is possible that the external encoder
> > > > > might get confused between the FF or 00 which are a part
> > > > > of the data and that of the SAV or EAV codes.
> > > > >
> > > > > Signed-off-by: Manjunath Hadli
> > > > > Signed-off-by: Lad, Prabhakar
> > > > > ---
> > > > >
> > > > > drivers/media/video/davinci/vpif.h | 30
> > > > > +
> > > > > drivers/media/video/davinci/vpif_display.c | 10 +
> > > > > include/media/davinci/vpif_types.h |2 +
> > > > > 3 files changed, 42 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/video/davinci/vpif.h
> > > > > b/drivers/media/video/davinci/vpif.h index a4d2141..c2ce4d9 100644
> > > > > --- a/drivers/media/video/davinci/vpif.h
> > > > > +++ b/drivers/media/video/davinci/vpif.h
> > > > > @@ -211,6 +211,12 @@ static inline void vpif_clr_bit(u32 reg, u32 bit)
> > > > >
> > > > > #define VPIF_CH3_INT_CTRL_SHIFT (6)
> > > > > #define VPIF_CH_INT_CTRL_SHIFT (6)
> > > > >
> > > > > +#define VPIF_CH2_CLIP_ANC_EN 14
> > > > > +#define VPIF_CH2_CLIP_ACTIVE_EN 13
> > > > > +
> > > > > +#define VPIF_CH3_CLIP_ANC_EN 14
> > > > > +#define VPIF_CH3_CLIP_ACTIVE_EN 13
> > > > > +
> > > > >
> > > > > /* enabled interrupt on both the fields on vpid_ch0_ctrl register */
> > > > > #define channel0_intr_assert() (regw((regr(VPIF_CH0_CTRL)|\
> > > > >
> > > > > (VPIF_INT_BOTH << VPIF_CH0_INT_CTRL_SHIFT)), VPIF_CH0_CTRL))
> > > > >
> > > > > @@ -515,6 +521,30 @@ static inline void channel3_raw_enable(int
> > > > > enable,
> > > > > u8
> > > > > index) vpif_clr_bit(VPIF_CH3_CTRL, mask);
> > > > >
> > > > > }
> > > > >
> > > > > +/* function to enable clipping (for both active and blanking regions)
> > > > > on ch 2 */ +static inline void channel2_clipping_enable(int enable)
> > > > > +{
> > > > > + if (enable) {
> > > > > + vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
> > > > > + vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
> > > > > + } else {
> > > > > + vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
> > > > > + vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +/* function to enable clipping (for both active and blanking regions)
> > > > > on ch 2 */ +static inline void channel3_clipping_enable(int enable)
> > > > > +{
> > > > > + if (enable) {
> > > > > + vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
> > > > > + vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
> > > > > + } else {
> > > > > + vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
> > > > > + vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
> > > > > + }
> > > > > +}
> > > > > +
> > > > >
> > > > > /* inline function to set buffer addresses in case of Y/C non mux
> > > > > mode
> > > > > */
> > > > > static inline void ch2_set_videobuf_addr_yc_nmux(unsigned long
> > > > >
> > > > > top_strt_luma, unsigned long btm_strt_luma,
> > > > > diff --git a/drivers/media/video/davinci/vpif_display.c
> > > > > b/drivers/media/video/davinci/vpif_display.c index 61ea8bc..4436ef6
> > > > > 100644
> > > > > --- a/drivers/media/video/davinci/vpif_display.c
> > > > > +++ b/drivers/media/video/davinci/vpif_display.c
> > > > > @@ -1046,6 +1046,8 @@ static int vpif_streamon(struct file *file, void
> > > > > *priv, channel2_intr_assert();
> > > > >
> > > > > channel2_intr_enable(1);
> > > > > enable_channel2(1);
> > > > >
> > > > > + if (vpif_config_data->ch2_clip_en)
> > > > > + channel2_clipping_enable(1);
> > > > >
> > > > > }
> > > > >
> > > > > if ((VPIF_CHANNEL3_VIDEO == ch->channel_id)
> > > > >
> > > > > @@ -1053,6 +1055,8 @@ static int vpif_streamon(struct file *file, void
> > > > > *priv, channel3_intr_assert();
> > > > >
> > > > > channel3_intr_enable(1);
> > > > > enable_channel3(1);
> > > > >
> > > > > + if (vpif_config_data->ch3_clip_en)
> > > > > + channel3_clipping_enable(1);
> > > > >
> > > > > }
> > > > > channel_first_int[VPIF_VIDEO_INDEX][ch->channel_id] = 1;
> > > > >
> > > > > }
> > > > >
> > > > > @@ -1065,6 +1069,8 @@ static int vpif_streamoff(struct file *file,
> > > > > void
> > > > > *priv, struct vpif_fh *fh
RE: [PATCH v2 01/13] davinci: vpif: add check for genuine interrupts in the isr
Hi Laurent,
On Mon, May 14, 2012 at 13:19:40, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Friday 11 May 2012 05:32:13 Hadli, Manjunath wrote:
> > On Tue, Apr 17, 2012 at 15:36:16, Laurent Pinchart wrote:
> > > On Tuesday 17 April 2012 14:22:59 Manjunath Hadli wrote:
> > > > As the same interrupt is shared between capture and display devices,
> > > > sometimes we get isr calls where the interrupt might not genuinely
> > > > belong to capture or display. Hence, add a condition in the isr to
> > > > check for interrupt ownership and channel number to make sure we do
> > > > not service wrong interrupts.
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > ---
> > > >
> > > > drivers/media/video/davinci/vpif_capture.c |5 +
> > > > drivers/media/video/davinci/vpif_display.c |5 +
> > > > include/media/davinci/vpif_types.h |2 ++
> > > > 3 files changed, 12 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/media/video/davinci/vpif_capture.c
> > > > b/drivers/media/video/davinci/vpif_capture.c index 6504e40..33d865d
> > > > 100644
> > > > --- a/drivers/media/video/davinci/vpif_capture.c
> > > > +++ b/drivers/media/video/davinci/vpif_capture.c
> > > > @@ -333,6 +333,7 @@ static void vpif_schedule_next_buffer(struct
> > > > common_obj
> > > > *common) */
> > > >
> > > > static irqreturn_t vpif_channel_isr(int irq, void *dev_id) {
> > > >
> > > > + struct vpif_capture_config *config = vpif_dev->platform_data;
> > > >
> > > > struct vpif_device *dev = &vpif_obj;
> > > > struct common_obj *common;
> > > > struct channel_obj *ch;
> > > >
> > > > @@ -341,6 +342,10 @@ static irqreturn_t vpif_channel_isr(int irq, void
> > > > *dev_id) int fid = -1, i;
> > > >
> > > > channel_id = *(int *)(dev_id);
> > > >
> > > > + if (!config->intr_status ||
> > > > + !config->intr_status(vpif_base, channel_id))
> > > > + return IRQ_NONE;
> > > > +
> > >
> > > I don't think this is the right way to handle the situation. You should
> > > instead read the interrupt source register for the VPIF capture device,
> > > and return IRQ_NONE if you find that no interrupt source has been flagged
> > > (and similarly for the display device below).
> >
> > Agreed, and this is what is being done in intr_status() function, which
> > is implemented in the board file. This function checks the interrupt source
> > register for VPIF capture and display devices the way you mentioned.
>
> Why do you need to do that in board code ? You can just check whether the
> VPIF
> capture hardware has generated an interrupt here exactly the same way as you
> do in your board code, and return IRQ_NONE if it hasn't. There's no need for
> the VPIF capture driver to be aware of the VPIF display driver (and vice
> versa).
>
Ok I'll add this in the driver itself.
Thx,
--Manju
> > > > ch = dev->dev[channel_id];
> > > >
> > > > field = ch->common[VPIF_VIDEO_INDEX].fmt.fmt.pix.field;
>
> --
> 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
RE: [PATCH v2 05/13] davinci: vpif display: declare contiguous region of memory handled by dma_alloc_coherent
Hi Laurent,
On Mon, May 14, 2012 at 13:16:27, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Friday 11 May 2012 05:30:43 Hadli, Manjunath wrote:
> > On Tue, Apr 17, 2012 at 15:32:55, Laurent Pinchart wrote:
> > > On Tuesday 17 April 2012 14:23:03 Manjunath Hadli wrote:
> > > > add support to declare contiguous region of memory to be handled when
> > > > requested by dma_alloc_coherent call. The user can specify the size of
> > > > the buffers with an offset from the kernel image using cont_bufsize
> > > > and cont_bufoffset module parameters respectively.
>
> [snip]
>
> > > > @@ -1686,12 +1710,14 @@ static __init int vpif_probe(struct
> > > > platform_device *pdev) struct vpif_subdev_info *subdevdata;
> > > >
> > > > struct vpif_display_config *config;
> > > > int i, j = 0, k, q, m, err = 0;
> > > >
> > > > + unsigned long phys_end_kernel;
> > > >
> > > > struct i2c_adapter *i2c_adap;
> > > > struct common_obj *common;
> > > > struct channel_obj *ch;
> > > > struct video_device *vfd;
> > > > struct resource *res;
> > > > int subdev_count;
> > > >
> > > > + size_t size;
> > > >
> > > > vpif_dev = &pdev->dev;
> > > >
> > > > @@ -1749,6 +1775,41 @@ static __init int vpif_probe(struct
> > > > platform_device
> > > > *pdev) ch->video_dev = vfd;
> > > >
> > > > }
> > > >
> > > > + /* Initialising the memory from the input arguments file for
> > > > +* contiguous memory buffers and avoid defragmentation
> > > > +*/
> > > > + if (cont_bufsize) {
> > > > + /* attempt to determine the end of Linux kernel memory
> > > > */
> > > > + phys_end_kernel = virt_to_phys((void *)PAGE_OFFSET) +
> > > > + (num_physpages << PAGE_SHIFT);
> > > > + phys_end_kernel += cont_bufoffset;
> > > > + size = cont_bufsize;
> > > > +
> > > > + err = dma_declare_coherent_memory(&pdev->dev,
> > > > phys_end_kernel,
> > > > + phys_end_kernel, size,
> > > > + DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> > >
> > > This is a pretty dangerous hack. You should compute the memory address and
> > > size in board code, and pass it to the driver through a device resource
> > > (don't forget to call request_mem_region on the resource). I think the
> > > dma_declare_coherent_memory() call should be moved to board code as well.
> >
> > I don't think it is a hack. Since the device does not support scatter gather
> > MMU, we need to make sure that the requirement of memory scucceeds for the
> > Driver buffers.
>
> If two drivers attempt to do the same you're screwed. That's why this should
> be moved to board code, where memory reservation for all devices that need it
> can be coordinated. You should call dma_declare_coherent_memory() there, not
> in the VPIF driver.
>
Ok I'll move dma_declare_coherent_memory() to board file.
> > Here the size is taken as part of module parameters, which If I am right,
> > cannot be moved to board file.
>
> Depending on how early you need the information in board code you can use
> early_param(), __setup() or normal module parameter macros in the board code.
>
Ok I'll fix this.
Thx,
--Manju
> > > > + if (!err) {
> > > > + dev_err(&pdev->dev, "Unable to declare MMAP
> > > > memory.\n");
> > > > + err = -ENOMEM;
> > > > + goto probe_out;
> > > > + }
> > > > +
> > > > + /* The resources are divided into two equal memory and
> > > > when
> > > > +* we have HD output we can add them together
> > > > +*/
> > > > + for (j = 0; j < VPIF_DISPLAY_MAX_DEVICES; j++) {
> > > > + ch = vpif_obj.dev[j];
> > > > + ch->channel_id = j;
> > > > +
> > > > + /* only enabled if second resource exists */
> > > > + config_params.video_limit[ch->channel_id] = 0;
> > > > + if (cont_bufsize)
> > > > +
> > > > config_params.video_limit[ch->channel_id] =
> > > > +
> > > > size/2;
> > > > + }
> > > > + }
> > > > +
> > > >
> > > > for (j = 0; j < VPIF_DISPLAY_MAX_DEVICES; j++) {
> > > >
> > > > ch = vpif_obj.dev[j];
> > > > /* Initialize field of the channel objects */ diff --git
>
> --
> 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
[GIT PULL FOR v3.5] davicni: vpfe:media controller based capture driver for dm365
Mauro, The following patch set adds the media controller based driver TI dm365 SoC. Patches have gone through RFC and reviews and are pending for some time. The main support added here: -CCDC capture -Previewer -Resizer -AEW/AF -Some media formats supported on dm365 -PIX_FORMATs supported on dm365 --- The following changes since commit a01ee165a132fadb57659d26246e340d6ac53265: Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd (2012-05-28 13:10:41 -0700) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git pull_dm365_mc_for_mauro Manjunath Hadli (19): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 davinci: vpfe: add dm3xx IPIPEIF hardware support module davinci: vpfe: add IPIPE hardware layer support davinci: vpfe: add IPIPE support for media controller driver davinci: vpfe: add support for CCDC hardware for dm365 davinci: vpfe: add ccdc driver with media controller interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: v4l2 capture driver with media interface davinci: vpfe: previewer driver based on v4l2 media controller framework davinci: vpfe: resizer driver based on media framework davinci: vpfe: add DM365 autofoucus(AF) hardware interface davinci: vpfe: add autofocus driver based on media framework davinci: vpfe: add hardware interface for dm365 aew davinci: vpfe: add aew driver based on v4l2 media framework dm365: vpss: setup ISP registers dm365: vpss: set vpss clk ctrl dm365: vpss: add helper functions for setting hardware parameters used by main driver davinci: vpfe: build infrastructure for dm365 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 + Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 + Documentation/DocBook/media/v4l/pixfmt.xml |2 + Documentation/DocBook/media/v4l/subdev-formats.xml | 171 + drivers/media/video/davinci/Kconfig| 72 +- drivers/media/video/davinci/Makefile | 17 + drivers/media/video/davinci/ccdc_hw_device.h |2 +- drivers/media/video/davinci/dm355_ccdc.c |2 +- drivers/media/video/davinci/dm365_a3_hw.c | 389 ++ drivers/media/video/davinci/dm365_a3_hw.h | 253 ++ drivers/media/video/davinci/dm365_aew.c| 544 +++ drivers/media/video/davinci/dm365_aew.h| 55 + drivers/media/video/davinci/dm365_af.c | 563 +++ drivers/media/video/davinci/dm365_af.h | 59 + drivers/media/video/davinci/dm365_ccdc.c | 1453 drivers/media/video/davinci/dm365_ccdc.h | 91 + drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ drivers/media/video/davinci/dm365_def_para.c | 310 ++ drivers/media/video/davinci/dm365_def_para.h | 39 + drivers/media/video/davinci/dm365_ipipe.c | 3844 drivers/media/video/davinci/dm365_ipipe.h | 378 ++ drivers/media/video/davinci/dm365_ipipe_hw.c | 935 + drivers/media/video/davinci/dm365_ipipe_hw.h | 539 +++ drivers/media/video/davinci/dm3xx_ipipeif.c| 313 ++ drivers/media/video/davinci/dm3xx_ipipeif.h| 256 ++ drivers/media/video/davinci/dm644x_ccdc.c |2 +- drivers/media/video/davinci/imp_common.h | 87 + drivers/media/video/davinci/imp_hw_if.h| 170 + drivers/media/video/davinci/isif.c |2 +- drivers/media/video/davinci/vpfe_aew.c | 238 ++ drivers/media/video/davinci/vpfe_aew.h | 51 + drivers/media/video/davinci/vpfe_af.c | 240 ++ drivers/media/video/davinci/vpfe_af.h | 47 + drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpfe_ccdc.c| 817 + drivers/media/video/davinci/vpfe_ccdc.h| 86 + drivers/media/video/davinci/vpfe_mc_capture.c | 801 drivers/media/video/davinci/vpfe_mc_capture.h | 99 + drivers/media/video/davinci/vpfe_previewer.c | 1066 ++ drivers/media/video/davinci/vpfe_previewer.h | 65 + drivers/media/video/davinci/vpfe_resizer.c | 1076 ++ drivers/media/video/davinci/vpfe_resizer.h | 63 + drivers/media/video/davinci/vpfe_video.c | 1728 + drivers/media/video/davinci/vpfe_video.h | 146 + drivers/media/video/davinci/vpss.c | 56 + include/linux/dm365_aew.h | 153 + include/linux/dm365_af.h | 203 + include/linux/dm365_ccdc.h | 611 include/linux/dm365_ipipe.h| 1029 ++ include/linux/dm3xx_ipipeif.h | 65 + include/linux/imp_common.h | 172 + include/linux/v4l2-mediab
RE: [PATCH v2 01/13] davinci: vpif: add check for genuine interrupts in the isr
Hi Laurent,
On Tue, Apr 17, 2012 at 15:36:16, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thanks for the patch.
>
> On Tuesday 17 April 2012 14:22:59 Manjunath Hadli wrote:
> > As the same interrupt is shared between capture and display devices,
> > sometimes we get isr calls where the interrupt might not genuinely
> > belong to capture or display. Hence, add a condition in the isr to
> > check for interrupt ownership and channel number to make sure we do
> > not service wrong interrupts.
> >
> > Signed-off-by: Manjunath Hadli
> > ---
> > drivers/media/video/davinci/vpif_capture.c |5 +
> > drivers/media/video/davinci/vpif_display.c |5 +
> > include/media/davinci/vpif_types.h |2 ++
> > 3 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/davinci/vpif_capture.c
> > b/drivers/media/video/davinci/vpif_capture.c index 6504e40..33d865d
> > 100644
> > --- a/drivers/media/video/davinci/vpif_capture.c
> > +++ b/drivers/media/video/davinci/vpif_capture.c
> > @@ -333,6 +333,7 @@ static void vpif_schedule_next_buffer(struct
> > common_obj
> > *common) */
> > static irqreturn_t vpif_channel_isr(int irq, void *dev_id) {
> > + struct vpif_capture_config *config = vpif_dev->platform_data;
> > struct vpif_device *dev = &vpif_obj;
> > struct common_obj *common;
> > struct channel_obj *ch;
> > @@ -341,6 +342,10 @@ static irqreturn_t vpif_channel_isr(int irq, void
> > *dev_id) int fid = -1, i;
> >
> > channel_id = *(int *)(dev_id);
> > + if (!config->intr_status ||
> > + !config->intr_status(vpif_base, channel_id))
> > + return IRQ_NONE;
> > +
>
> I don't think this is the right way to handle the situation. You should
> instead read the interrupt source register for the VPIF capture device, and
> return IRQ_NONE if you find that no interrupt source has been flagged (and
> similarly for the display device below).
Agreed, and this is what is being done in intr_status() function, which
is implemented in the board file. This function checks the interrupt source
register for VPIF capture and display devices the way you mentioned.
Thx,
--Manju
>
> > ch = dev->dev[channel_id];
> >
> > field = ch->common[VPIF_VIDEO_INDEX].fmt.fmt.pix.field;
> > diff --git a/drivers/media/video/davinci/vpif_display.c
> > b/drivers/media/video/davinci/vpif_display.c index 7fa34b4..9b59e0b
> > 100644
> > --- a/drivers/media/video/davinci/vpif_display.c
> > +++ b/drivers/media/video/davinci/vpif_display.c
> > @@ -299,6 +299,7 @@ static void process_interlaced_mode(int fid,
> > struct common_obj *common) */ static irqreturn_t vpif_channel_isr(int
> > irq, void *dev_id) {
> > + struct vpif_display_config *config = vpif_dev->platform_data;
> > struct vpif_device *dev = &vpif_obj;
> > struct channel_obj *ch;
> > struct common_obj *common;
> > @@ -307,6 +308,10 @@ static irqreturn_t vpif_channel_isr(int irq, void
> > *dev_id) int channel_id = 0;
> >
> > channel_id = *(int *)(dev_id);
> > + if (!config->intr_status ||
> > + !config->intr_status(vpif_base, channel_id + 2))
> > + return IRQ_NONE;
> > +
> > ch = dev->dev[channel_id];
> > field = ch->common[VPIF_VIDEO_INDEX].fmt.fmt.pix.field;
> > for (i = 0; i < VPIF_NUMOBJECTS; i++) { diff --git
> > a/include/media/davinci/vpif_types.h
> > b/include/media/davinci/vpif_types.h index bd8217c..2845bda 100644
> > --- a/include/media/davinci/vpif_types.h
> > +++ b/include/media/davinci/vpif_types.h
> > @@ -45,6 +45,7 @@ struct vpif_subdev_info {
> >
> > struct vpif_display_config {
> > int (*set_clock)(int, int);
> > + int (*intr_status)(void __iomem *vpif_base, int);
> > struct vpif_subdev_info *subdevinfo;
> > int subdev_count;
> > const char **output;
> > @@ -65,6 +66,7 @@ struct vpif_capture_chan_config { struct
> > vpif_capture_config {
> > int (*setup_input_channel_mode)(int);
> > int (*setup_input_path)(int, const char *);
> > + int (*intr_status)(void __iomem *vpif_base, int);
> > struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
> > struct vpif_subdev_info *subdev_info;
> > int subdev_count;
>
> --
> 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
RE: [PATCH v2 05/13] davinci: vpif display: declare contiguous region of memory handled by dma_alloc_coherent
Hi Laurent,
On Tue, Apr 17, 2012 at 15:32:55, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thanks for the patch.
>
> On Tuesday 17 April 2012 14:23:03 Manjunath Hadli wrote:
> > add support to declare contiguous region of memory to be handled when
> > requested by dma_alloc_coherent call. The user can specify the size of
> > the buffers with an offset from the kernel image using cont_bufsize
> > and cont_bufoffset module parameters respectively.
> >
> > Signed-off-by: Manjunath Hadli
> > ---
> > drivers/media/video/davinci/vpif_display.c | 65 -
> > drivers/media/video/davinci/vpif_display.h |1 +
> > 2 files changed, 64 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/video/davinci/vpif_display.c
> > b/drivers/media/video/davinci/vpif_display.c index 355ad5c..27bc03d
> > 100644
> > --- a/drivers/media/video/davinci/vpif_display.c
> > +++ b/drivers/media/video/davinci/vpif_display.c
> > @@ -57,18 +57,24 @@ static u32 ch2_numbuffers = 3; static u32
> > ch3_numbuffers = 3; static u32 ch2_bufsize = 1920 * 1080 * 2; static
> > u32 ch3_bufsize = 720 * 576 * 2;
> > +static u32 cont_bufoffset;
> > +static u32 cont_bufsize;
> >
> > module_param(debug, int, 0644);
> > module_param(ch2_numbuffers, uint, S_IRUGO);
> > module_param(ch3_numbuffers, uint, S_IRUGO);
> > module_param(ch2_bufsize, uint, S_IRUGO); module_param(ch3_bufsize,
> > uint, S_IRUGO);
> > +module_param(cont_bufoffset, uint, S_IRUGO);
> > +module_param(cont_bufsize, uint, S_IRUGO);
> >
> > MODULE_PARM_DESC(debug, "Debug level 0-1");
> > MODULE_PARM_DESC(ch2_numbuffers, "Channel2 buffer count (default:3)");
> > MODULE_PARM_DESC(ch3_numbuffers, "Channel3 buffer count (default:3)");
> > MODULE_PARM_DESC(ch2_bufsize, "Channel2 buffer size (default:1920 x
> > 1080 x 2)"); MODULE_PARM_DESC(ch3_bufsize, "Channel3 buffer size
> > (default:720 x
> > 576 x 2)"); +MODULE_PARM_DESC(cont_bufoffset, "Display offset(default
> > 0)");
> > +MODULE_PARM_DESC(cont_bufsize, "Display buffer size(default 0)");
> >
> > static struct vpif_config_params config_params = {
> > .min_numbuffers = 3,
> > @@ -187,6 +193,24 @@ static int vpif_buffer_setup(struct
> > videobuf_queue *q, unsigned int *count, return 0;
> >
> > *size = config_params.channel_bufsize[ch->channel_id];
> > +
> > + /*
> > +* Checking if the buffer size exceeds the available buffer
> > +* ycmux_mode = 0 means 1 channel mode HD and
> > +* ycmux_mode = 1 means 2 channels mode SD
> > +*/
> > + if (ch->vpifparams.std_info.ycmux_mode == 0) {
> > + if (config_params.video_limit[ch->channel_id])
> > + while (*size * *count > (config_params.video_limit[0]
> > + + config_params.video_limit[1]))
> > + (*count)--;
> > + } else {
> > + if (config_params.video_limit[ch->channel_id])
> > + while (*size * *count >
> > + config_params.video_limit[ch->channel_id])
> > + (*count)--;
> > + }
> > +
> > if (*count < config_params.min_numbuffers)
> > *count = config_params.min_numbuffers;
> >
> > @@ -830,7 +854,7 @@ static int vpif_reqbufs(struct file *file, void
> > *priv,
> >
> > common = &ch->common[index];
> >
> > - if (common->fmt.type != reqbuf->type)
> > + if (common->fmt.type != reqbuf->type || !vpif_dev)
> > return -EINVAL;
> >
> > if (0 != common->io_usrs)
> > @@ -847,7 +871,7 @@ static int vpif_reqbufs(struct file *file, void
> > *priv,
> >
> > /* Initialize videobuf queue as per the buffer type */
> > videobuf_queue_dma_contig_init(&common->buffer_queue,
> > - &video_qops, NULL,
> > + &video_qops, vpif_dev,
> > &common->irqlock,
> > reqbuf->type, field,
> > sizeof(struct videobuf_buffer), fh,
> > @@ -1686,12 +1710,14 @@
> > static __init int vpif_probe(struct platform_device
> > *pdev) struct vpif_subdev_info *subdevdata;
> > struct vpif_display_config *config;
> > int i, j = 0, k, q, m, err = 0;
> > + unsigned long phys_end_kernel;
> > struct i2c_adapter *i2c_adap;
> > struct common_obj *common;
> > struct channel_obj *ch;
> > struct video_device *vfd;
> > struct resource *res;
> > int subdev_count;
> > + size_t size;
> >
> > vpif_dev = &pdev->dev;
> >
> > @@ -1749,6 +1775,41 @@ static __init int vpif_probe(struct
> > platform_device
> > *pdev) ch->video_dev = vfd;
> > }
> >
> > + /* Initialising the memory from the input arguments file for
> > +* contiguous memory buffers and avoid defragmentation
> > +*/
> > + if (cont_bufsize) {
> > + /* attempt to determine the end of Linux kernel memory */
> > + ph
RE: [PATCH v2 07/13] davinci: vpif: add support to use videobuf_iolock()
Hi Laurent, On Tue, Apr 17, 2012 at 15:16:50, Laurent Pinchart wrote: > Hi Manjunath, > > Thanks for the patch. > > On Tuesday 17 April 2012 14:23:05 Manjunath Hadli wrote: > > add support to use videobuf_iolock() instead of VPIF defined > > vpif_uservirt_to_phys API. Use videobuf_to_dma_contig API for both > > memory-mapped and userptr buffer allocations. > > Correspondingly removed vpif_uservirt_to_phys() VPIF defined API. > > What about using videobuf2 instead ? :-) We will definitely migrate to videobuf2 in the near future, but I wish to go ahead with the implementation as of now. Thx, --Manju > -- > 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
RE: [PATCH v3 2/2] v4l2: add new pixel formats supported on dm365
Sakari,
On Sun, Mar 04, 2012 at 20:49:36, Sakari Ailus wrote:
> Hi Manju,
>
> Thanks for the patch.
>
> On Tue, Feb 07, 2012 at 03:35:14PM +0530, Manjunath Hadli wrote:
> > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats to
> > represent Bayer format frames compressed by A-LAW algorithm, add
> > V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleaved) only.
> >
> > Signed-off-by: Manjunath Hadli
> > Cc: Laurent Pinchart
> > ---
> > .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
> > Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
> >
> > Documentation/DocBook/media/v4l/pixfmt.xml |2 +
> > include/linux/videodev2.h |9 +++
> > 4 files changed, 107 insertions(+), 0 deletions(-) create mode
> > 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> >
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > new file mode 100644
> > index 000..b20f525
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
> > @@ -0,0 +1,34 @@
> > +
> > +
> > +
> > + V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
> > + V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
> > + V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
> > + V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
> > +
> > + &manvol;
> > +
> > +
> > +
> > + V4L2_PIX_FMT_SRGGB10ALAW8
> > +
> > +
> > + V4L2_PIX_FMT_SGRBG10ALAW8
> > +
> > +
> > + V4L2_PIX_FMT_SGBRG10ALAW8
> > +
>
> The order here is different than earlier.
I had taken a reference from your v3 patch series (v4l: Add DPCM compressed
formats). Do you want me to change it?
>
> > +
> > + V4L2_PIX_FMT_SBGGR10ALAW8
> > +
> > + 10-bit Bayer formats compressed to 8 bits
> > +
> > +
> > + Description
> > + The following four pixel formats are raw sRGB / Bayer
> > + formats with 10 bits per colour compressed to 8 bits each,
> > + using the A-LAW algorithm. Each colour component consumes 8
> > + bits of memory. In other respects this format is similar to
> > + .
> > +
> > +
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> > b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> > new file mode 100644
> > index 000..e3e6b11
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
> > @@ -0,0 +1,62 @@
> > +
> > +
> > + V4L2_PIX_FMT_UV8 ('UV8')
> > + &manvol;
> > +
> > +
> > + V4L2_PIX_FMT_UV8
> > + UV plane interleaved
> > +
> > +
> > + Description
> > + In this format there is no Y plane, Only C plane. ie
> > + (UV interleaved)
>
> How about referring to "CbCr" instead of "C"?
Ok.
>
> > +
> > +
> > + V4L2_PIX_FMT_UV8
> > + pixel image
> > +
> > +
> > +
> > + Byte Order.
> > + Each cell is one byte.
> > +
> > +
> > +
> > +
> > +
> > + start + 0:
> > + Cb00
> > + Cr00
> > + Cb01
> > + Cr01
> > +
> > +
> > + start + 4:
> > + Cb10
> > + Cr10
> > + Cb11
> > + Cr11
> > +
> > +
> > + start + 8:
> > + Cb20
> > + Cr20
> > + Cb21
> > + Cr21
> > +
> > +
> > + start + 12:
> > + Cb30
> > + Cr30
> > + Cb31
> > + Cr31
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
> > b/Documentation/DocBook/media/v4l/pixfmt.xml
> > index 9ddc57c..0b62750 100644
> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> > @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of
> > the Linux framebuffer API.<
> > &sub-srggb8;
> > &sub-sbggr16;
> > &sub-srggb10;
> > +&sub-srggb10alaw8;
> > &sub-srggb12;
> >
> >
> > @@ -696,6 +697,7 @@ information.
> >
> > &sub-packed-yuv;
> > &sub-grey;
> > +&sub-uv8;
>
> I might put this between the Y' and the rest of the YUV formats.
Ok.
>
> > &sub-y10;
> > &sub-y12;
> > &sub-y10b;
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 012a296..8e6b3f2 100644
> > --- a/include/linux/vide
RE: [GIT PULL] davinci vpif pull request
Mauro, A gentle reminder for the pull request. Cheers, -Manju On Fri, Jan 27, 2012 at 15:43:00, Hadli, Manjunath wrote: > Hi Mauro, > Can you please pull the following patch for v3.3-rc1 which removes some > unnecessary inclusion of machine specific header files from the main driver > files? > > This patch has undergone sufficient review already. It is just a cleanup > patch and I don't expect any functionality to break because of this. > > Thanks and Regards, > -Manju > > > The following changes since commit 74ea15d909b31158f9b63190a95b52bc05586d4b: > Linus Torvalds (1): > Merge branch 'v4l_for_linus' of > git://git.kernel.org/.../mchehab/linux-media > > > are available in the git repository at: > > > git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 > > Manjunath Hadli (1): > davinci: vpif: remove machine specific header file inclusion from the > driver > > > drivers/media/video/davinci/vpif.h |2 -- > drivers/media/video/davinci/vpif_display.c |2 -- > include/media/davinci/vpif_types.h |2 ++ > 3 files changed, 2 insertions(+), 4 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] davinci vpif pull request
Hi Mauro, Can you please pull the following patch for v3.3-rc1 which removes some unnecessary inclusion of machine specific header files from the main driver files? This patch has undergone sufficient review already. It is just a cleanup patch and I don't expect any functionality to break because of this. Thanks and Regards, -Manju The following changes since commit 74ea15d909b31158f9b63190a95b52bc05586d4b: Linus Torvalds (1): Merge branch 'v4l_for_linus' of git://git.kernel.org/.../mchehab/linux-media are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (1): davinci: vpif: remove machine specific header file inclusion from the driver drivers/media/video/davinci/vpif.h |2 -- drivers/media/video/davinci/vpif_display.c |2 -- include/media/davinci/vpif_types.h |2 ++ 3 files changed, 2 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
All,
On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote:
> > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
> > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
> > > > > > > > format frames compressed by A-LAW alogorithm.
> > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV
> > > > > > > > interleved) only.
> > > > > > > >
> > > > > > > > Signed-off-by: Manjunath Hadli
> > > > > > > > Cc: Laurent Pinchart
> > > > > > > > ---
> > > > > > > >
> > > > > > > > include/linux/videodev2.h |6 ++
> > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > > >
> > > > > > > Could you please also document these formats in
> > > > > > > Documentation/DocBook/media/v4l ?
> > > > > >
> > > > > > I will. Sorry to have missed that out.
> > > > > >
> > > > > > > > diff --git a/include/linux/videodev2.h
> > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644
> > > > > > > > --- a/include/linux/videodev2.h
> > > > > > > > +++ b/include/linux/videodev2.h
> > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > > >
> > > > > > > > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2')
> > > > > > > > /* 8 YUV
> > > > > > > >
> > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines
> > > > > > > > y, 1 line uv interleaved */
> > > > > > > >
> > > > > > > > +/* Chrominance formats */
> > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ')
> > > > > > > > /* 8 UV 4:4 */ +
> > > > > > > >
> > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > > > > > > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2')
> > > > > > > > /* 12 Y/CbCr
> > > > > > > >
> > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V',
> > > > > > > > '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@
> > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
> > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
> > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define
> > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > > > +
> > > > > > >
> > > > > > > That's not very future-proof, how would you describe
> > > > > > > SGBRG10ALAW8 for instance ?
> > > > > > >
> > > > > > > Maybe it's time to standardize FOURCCs for Bayer new
> > > > > > > formats. We have 4 characters, we could start with 'B' to
> > > > > > > denote Bayer, followed by one character for the order, one
> > > > > > > for the compression, and one for the number of bits.
&g
RE: [GIT PULL] davinci vpif pull request
Mauro, On Mon, Jan 16, 2012 at 18:47:00, Mauro Carvalho Chehab wrote: > Em 16-01-2012 11:06, Hadli, Manjunath escreveu: > > Mauro, > > On Mon, Jan 16, 2012 at 18:26:25, Mauro Carvalho Chehab wrote: > >> Em 16-01-2012 10:45, Hadli, Manjunath escreveu: > >>> Mauro, > >>> On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: > >>>> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > >>>>> Hi Mauro, > >>>>> Can you please pull the following patch which removes some > >>>>> unnecessary inclusion > >>>>> of machine specific header files from the main driver files? > >>>>> > >>>>> This patch has undergone sufficient review already. It is just a > >>>>> cleanup patch and I don't > >>>>> expect any functionality to break because of this. The reason I did > >>>>> not club this with the > >>>>> 3 previous patches was because one of the previous patches on which > >>>>> this is dependent, > >>>>> is now pulled in by Arnd. > >>>>> > >>>>> Thanks and Regards, > >>>>> -Manju > >>>>> > >>>>> > >>>>> The following changes since commit > >>>>> e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > >>>>> Linus Torvalds (1): > >>>>> Merge tag 'for-linus' of > >>>>> git://git.kernel.org/.../mst/vhost > >>>>> > >>>>> are available in the git repository at: > >>>>> > >>>>> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git > >>>>> for-mauro-v3.3 > >>>>> > >>>>> Manjunath Hadli (1): > >>>>> davinci: vpif: remove machine specific header file inclusion > >>>>> from the driver > >>>> > >>>> This patch is outdated and doesn't apply anymore. Could you please > >>>> rebase it over my tree, branch "staging/for_v3.3"? > >>> This patch needs a recent accepted commit by Arnd which is available > >>> on http://git.linuxtv.org/linux-2.6.git but not on staging. > >> > >> This tree is just a daily-updated copy of Linus one. It is mirrored there > >> just to minimize the object copies at the other local trees. > >> > >>> Are you planning to rebase you staging tree to latest? When you do > >>> that this Patch will apply. Please let me know if there is any other way > >>> you want me to do? > >> > >> Linus doesn't like when someone merge from a random place at his tree. > >> I'll merge from his tree at -rc1, but I'm not intending to merge it > >> earlier than that, except if there are some strong reasons for that. > > Indeed, there are quite a few patches waiting to be pulled which are > > dependent on this patch. I would urge you to pull this as early as possible. > > Are those features target for 3.4? It is late for adding new features for 3.3. > > If they aren't for 3.3, merging at 3.3-rc1 should be ok for your needs. They are intended for 3.4. Merging at v3.3-rc1 is OK. Regards, -Manju > Otherwise, you need to point me the exact patch at Linus tree you need me to > pull, and properly justify the need for this patch, and submit it together > with the other ones you're needing for 3.3. > > > > Rgds, > > -Manju > >> > >> Anyway, if you prefer to send this patch through Arnd's tree, feel free to > >> add my acked-by: on that: > >> > >> Acked-by: Mauro Carvalho Chehab > >>> > >>> Regards, > >>> -Manju > >>>> > >>>> Thanks! > >>>> Mauro > >>>> > >>>>> > >>>>> drivers/media/video/davinci/vpif.h |2 -- > >>>>> drivers/media/video/davinci/vpif_display.c |2 -- > >>>>> include/media/davinci/vpif_types.h |2 ++ > >>>>> 3 files changed, 2 insertions(+), 4 deletions(-) > >>>>> -- > >>>>> To unsubscribe from this list: send the line "unsubscribe linux-media" > >>>>> in the body of a message to majord...@vger.kernel.org More > >>>>> majordomo info at http://vger.kernel.org/majordomo-info.html > >>>> > >>>> > >>> > >> > >> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] davinci vpif pull request
Mauro, On Mon, Jan 16, 2012 at 18:26:25, Mauro Carvalho Chehab wrote: > Em 16-01-2012 10:45, Hadli, Manjunath escreveu: > > Mauro, > > On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: > >> Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > >>> Hi Mauro, > >>> Can you please pull the following patch which removes some unnecessary > >>> inclusion > >>> of machine specific header files from the main driver files? > >>> > >>> This patch has undergone sufficient review already. It is just a > >>> cleanup patch and I don't > >>> expect any functionality to break because of this. The reason I did not > >>> club this with the > >>> 3 previous patches was because one of the previous patches on which > >>> this is dependent, > >>> is now pulled in by Arnd. > >>> > >>> Thanks and Regards, > >>> -Manju > >>> > >>> > >>> The following changes since commit > >>> e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > >>> Linus Torvalds (1): > >>> Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost > >>> > >>> are available in the git repository at: > >>> > >>> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git > >>> for-mauro-v3.3 > >>> > >>> Manjunath Hadli (1): > >>> davinci: vpif: remove machine specific header file inclusion > >>> from the driver > >> > >> This patch is outdated and doesn't apply anymore. Could you please rebase > >> it over my tree, branch "staging/for_v3.3"? > > This patch needs a recent accepted commit by Arnd which is available > > on http://git.linuxtv.org/linux-2.6.git but not on staging. > > This tree is just a daily-updated copy of Linus one. It is mirrored there > just to minimize the object copies at the other local trees. > > > Are you planning to rebase you staging tree to latest? When you do > > that this Patch will apply. Please let me know if there is any other way > > you want me to do? > > Linus doesn't like when someone merge from a random place at his tree. > I'll merge from his tree at -rc1, but I'm not intending to merge it earlier > than that, except if there are some strong reasons for that. Indeed, there are quite a few patches waiting to be pulled which are dependent on this patch. I would urge you to pull this as early as possible. Rgds, -Manju > > Anyway, if you prefer to send this patch through Arnd's tree, feel free to > add my acked-by: on that: > > Acked-by: Mauro Carvalho Chehab > > > > Regards, > > -Manju > >> > >> Thanks! > >> Mauro > >> > >>> > >>> drivers/media/video/davinci/vpif.h |2 -- > >>> drivers/media/video/davinci/vpif_display.c |2 -- > >>> include/media/davinci/vpif_types.h |2 ++ > >>> 3 files changed, 2 insertions(+), 4 deletions(-) > >>> -- > >>> To unsubscribe from this list: send the line "unsubscribe linux-media" > >>> in the body of a message to majord...@vger.kernel.org More majordomo > >>> info at http://vger.kernel.org/majordomo-info.html > >> > >> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] davinci vpif pull request
Mauro, On Mon, Jan 16, 2012 at 17:27:03, Mauro Carvalho Chehab wrote: > Em 11-01-2012 09:39, Hadli, Manjunath escreveu: > > Hi Mauro, > > Can you please pull the following patch which removes some unnecessary > > inclusion > > of machine specific header files from the main driver files? > > > > This patch has undergone sufficient review already. It is just a cleanup > > patch and I don't > > expect any functionality to break because of this. The reason I did not > > club this with the > > 3 previous patches was because one of the previous patches on which this > > is dependent, > > is now pulled in by Arnd. > > > > Thanks and Regards, > > -Manju > > > > > > The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: > > Linus Torvalds (1): > > Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost > > > > are available in the git repository at: > > > > git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 > > > > Manjunath Hadli (1): > > davinci: vpif: remove machine specific header file inclusion > > from the driver > > This patch is outdated and doesn't apply anymore. Could you please rebase it > over my tree, branch "staging/for_v3.3"? This patch needs a recent accepted commit by Arnd which is available on http://git.linuxtv.org/linux-2.6.git but not on staging. Are you planning to rebase you staging tree to latest? When you do that this Patch will apply. Please let me know if there is any other way you want me to do? Regards, -Manju > > Thanks! > Mauro > > > > > drivers/media/video/davinci/vpif.h |2 -- > > drivers/media/video/davinci/vpif_display.c |2 -- > > include/media/davinci/vpif_types.h |2 ++ > > 3 files changed, 2 insertions(+), 4 deletions(-) > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" > > in the body of a message to majord...@vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] davinci vpif pull request
Hi Mauro, Can you please pull the following patch which removes some unnecessary inclusion of machine specific header files from the main driver files? This patch has undergone sufficient review already. It is just a cleanup patch and I don't expect any functionality to break because of this. The reason I did not club this with the 3 previous patches was because one of the previous patches on which this is dependent, is now pulled in by Arnd. Thanks and Regards, -Manju The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244: Linus Torvalds (1): Merge tag 'for-linus' of git://git.kernel.org/.../mst/vhost are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (1): davinci: vpif: remove machine specific header file inclusion from the driver drivers/media/video/davinci/vpif.h |2 -- drivers/media/video/davinci/vpif_display.c |2 -- include/media/davinci/vpif_types.h |2 ++ 3 files changed, 2 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] davinci vpbe pull request
Hi Mauro, Can you please pull these vpbe patches which add the support for DM365 and DM355 display? The 3 vpbe patches were sent to you as a pull request earlier. Please see this mail: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-November/023496.html I have now rebased these to 3.2 since my earlier pull request was not based on commits on Linus's tree. As a result they look like recent commits, but have actually been around for a long time. Thx, -Manju The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610: Linus Torvalds (1): Linux 3.2 are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (3): davinci vpbe: add dm365 VPBE display driver changes davinci vpbe: add dm365 and dm355 specific OSD changes davinci vpbe: add VENC block changes to enable dm365 and dm355 drivers/media/video/davinci/vpbe.c | 48 +++- drivers/media/video/davinci/vpbe_osd.c | 473 --- drivers/media/video/davinci/vpbe_venc.c | 205 -- include/media/davinci/vpbe.h| 16 + include/media/davinci/vpbe_venc.h |4 + 5 files changed, 678 insertions(+), 68 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver
Sergei, On Wed, Jan 04, 2012 at 18:29:13, Sergei Shtylyov wrote: > Hello. > > On 04-01-2012 11:17, Manjunath Hadli wrote: > > > remove unnecessary inclusion of machine specific header files > > mach/dm646x.h, mach/hardware.h from vpif.h and aslo mach/dm646x.h > > from vpif_display.c driver which comes in the way of platform code > > consolidation. > > Add linux/i2c.h header file in vpif_types.h which is required for > > building. > > This last modification should be in a separate patch. Don;t mix changes > having the different purpose. It is part of the same modification of removing the machine specific header. When the header file was removed, it needed the i2c to be included due to a dependency and hence the inclusion. Thx, -Manju > > > Signed-off-by: Manjunath Hadli > > Cc: Mauro Carvalho Chehab > > Cc: LMML > > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Laurent,
On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> Hi Manju,
>
> On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > frames compressed by A-LAW alogorithm.
> > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > Cc: Laurent Pinchart
> > > > ---
> > > >
> > > > include/linux/videodev2.h |6 ++
> > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > Could you please also document these formats in
> > > Documentation/DocBook/media/v4l ?
> >
> > I will. Sorry to have missed that out.
> >
> > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > index 4b752d5..969112d 100644
> > > > --- a/include/linux/videodev2.h
> > > > +++ b/include/linux/videodev2.h
> > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > >
> > > > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8
> > > > YUV
> > > >
> > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line
> > > > uv interleaved */
> > > >
> > > > +/* Chrominance formats */
> > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8
> > > > UV 4:4 */ +
> > > >
> > > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > Y/CbCr
> > > >
> > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1')
> > > > /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format
> > > > { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /*
> > > > 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits
> > > > */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1',
> > > > '0')
> > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > +
> > >
> > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > for instance ?
> > >
> > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > by one character for the order, one for the compression, and one for
> > > the number of bits.
> >
> > I agree.
> > May be ('B', 'G', 'A', '8') is fine for the above?
>
> We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g',
> 'G' and 'R' respectively for the second character. The third character would
> be 'A' for A-law and 'D' for DPCM, and the fourth character could describe
> the bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I
> suspect that we will need 16-bit wide busses for raw Bayer at some point, and
> a 0 width is definitely not useful. We could thus offset the width by some
> value.
>
> This is just a preliminary idea, I'm open to suggestions.
I think it is a very good suggestion that we can go with.
B : BGGR
g : GBRG
G : GRBG
R : RGGB
and 0-F can signify 1-16.
Thx,
-Manju
>
> > > > /*
> > > >
> > > > * 10bit raw bayer, expanded to 16 bits
> > > > * rrgg ggbb...
>
> --
> 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
RE: [PATCH 1/2] media: add new mediabus format enums for dm365
Laurent,
On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote:
> Hi Manju,
>
> On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
> > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
> > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This
> > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> > > > supported on dm365.
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > Cc: Laurent Pinchart
> > > > ---
> > > >
> > > > include/linux/v4l2-mediabus.h | 10 --
> > > > 1 files changed, 8 insertions(+), 2 deletions(-)
> > >
> > > Please also update the documentation in Documentation/DocBook/media/v4l.
> > >
> > > > diff --git a/include/linux/v4l2-mediabus.h
> > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > > > --- a/include/linux/v4l2-mediabus.h
> > > > +++ b/include/linux/v4l2-mediabus.h
> > > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
> > > >
> > > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> > > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
> > > >
> > > > - /* YUV (including grey) - next is 0x2014 */
> > > > + /* YUV (including grey) - next is 0x2016 */
> > > >
> > > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> > > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> > > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > > >
> > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > > >
> > > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > > >
> > > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> > >
> > > NV12, on the bus ? How does that work ? (The documentation should
> > > answer my question :-))
> >
> > Well, this is on the internal bus not exposed outside, but
> > nevertheless bus between two subdevs or two independent hardware
> > blocks. For example Resizer supports NV12 on its pad. Is there any other
> > way to treat this?
>
> How is NV12 transferred on the bus in that case ? Are all luma samples
> transferred first, followed by all chroma samples ?
It uses parallel bus of 16 bits, where Y and C are transmitted simultaneously
on 8 bits each. NV12 uses a dummy C byte for every
valid one.
So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16?
That way we will be able to document the format in the documentation also.
Thx,
-Manju
>
> > > > - /* Bayer - next is 0x3015 */
> > > > + /* Bayer - next is 0x3019 */
> > > >
> > > > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
> > > > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
> > > > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
> > > >
> > > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
> > > >
> > > > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> > > > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> > > > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> > > >
> > > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> > > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> > > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> > > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
> > >
> > > Please keep the names sorted as described in the comment at the
> > > beginning of the file.
> > >
> > > > /* JPEG compressed formats - next is 0x4002 */
> > > > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
>
> --
> 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
RE: [PATCH v6 01/11] davinci: vpif: remove obsolete header file inclusion
Mauro, Sekhar needs your ack on this to get a series of mach patches in. Can you please have a look at this? -Manju On Thu, Dec 15, 2011 at 17:41:50, Hadli, Manjunath wrote: > remove inclusion of header files from vpif.h and vpif_dispaly.c and add > appropriate header file for building. > > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML > --- > drivers/media/video/davinci/vpif.h |2 +- > drivers/media/video/davinci/vpif_display.c |2 -- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/video/davinci/vpif.h > b/drivers/media/video/davinci/vpif.h > index 25036cb..c96268a 100644 > --- a/drivers/media/video/davinci/vpif.h > +++ b/drivers/media/video/davinci/vpif.h > @@ -19,7 +19,7 @@ > #include > #include > #include > -#include > +#include > #include > > /* Maximum channel allowed */ > diff --git a/drivers/media/video/davinci/vpif_display.c > b/drivers/media/video/davinci/vpif_display.c > index 286f029..7fa34b4 100644 > --- a/drivers/media/video/davinci/vpif_display.c > +++ b/drivers/media/video/davinci/vpif_display.c > @@ -39,8 +39,6 @@ > #include > #include > > -#include > - > #include "vpif_display.h" > #include "vpif.h" > > -- > 1.6.2.4 > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] media: add new mediabus format enums for dm365
Laurent,
Thank you for the comments.
On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> Hi Manhunath,
>
> Thanks for the patch.
>
> On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
> > mbus_pixel_code to represent A-LAW compressed Bayer format. This
> > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> > supported on dm365.
> >
> > Signed-off-by: Manjunath Hadli
> > Cc: Laurent Pinchart
> > ---
> > include/linux/v4l2-mediabus.h | 10 --
> > 1 files changed, 8 insertions(+), 2 deletions(-)
>
> Please also update the documentation in Documentation/DocBook/media/v4l.
>
> > diff --git a/include/linux/v4l2-mediabus.h
> > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > --- a/include/linux/v4l2-mediabus.h
> > +++ b/include/linux/v4l2-mediabus.h
> > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
> > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
> >
> > - /* YUV (including grey) - next is 0x2014 */
> > + /* YUV (including grey) - next is 0x2016 */
> > V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
>
> NV12, on the bus ? How does that work ? (The documentation should answer my
> question :-))
Well, this is on the internal bus not exposed outside, but nevertheless bus
between two subdevs or two independent hardware blocks. For example Resizer
supports NV12 on its pad. Is there any other way to treat this?
Thx,
-Manju
>
> > - /* Bayer - next is 0x3015 */
> > + /* Bayer - next is 0x3019 */
> > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
> > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
> > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
> > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
> > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
>
> Please keep the names sorted as described in the comment at the beginning of
> the file.
>
> >
> > /* JPEG compressed formats - next is 0x4002 */
> > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
>
> --
> 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
RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Hello Laurent,
Thank you for the comments.
On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> Hi Manjunath,
>
> Thanks for the patch.
>
> On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > frames compressed by A-LAW alogorithm.
> > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> >
> > Signed-off-by: Manjunath Hadli
> > Cc: Laurent Pinchart
> > ---
> > include/linux/videodev2.h |6 ++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
>
> Could you please also document these formats in
> Documentation/DocBook/media/v4l ?
I will. Sorry to have missed that out.
>
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 4b752d5..969112d 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV
> > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420v4l2_fourcc('M',
> > '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */
> >
> > +/* Chrominance formats */
> > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV
> > 4:4 */ +
> > /* two planes -- one Y, one Cr + Cb interleaved */
> > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
> > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /*
> > 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format {
> > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG..
> > GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ #define
> > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > +
>
> That's not very future-proof, how would you describe SGBRG10ALAW8 for
> instance ?
>
> Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4
> characters, we could start with 'B' to denote Bayer, followed by one
> character for the order, one for the compression, and one for the number of
> bits.
I agree.
May be ('B', 'G', 'A', '8') is fine for the above?
Thanks and Regards,
-Manju
>
> > /*
> > * 10bit raw bayer, expanded to 16 bits
> > * rrgg ggbb...
>
> --
> 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
RE: [PATCH] vpif_capture.c: v4l2_device_register() is called too late in vpif_probe()
Hans,
On Tue, Dec 13, 2011 at 15:14:42, Hans Verkuil wrote:
> The function v4l2_device_register() is called too late in vpif_probe().
> This meant that vpif_obj.v4l2_dev is accessed before it is initialized which
> caused a crash.
>
> This used to work in the past, but video_register_device() is now actually
> using the v4l2_dev pointer.
I also found this issue today. Good catch!
>
> Note that vpif_display.c doesn't have this bug, there v4l2_device_register()
> is called at the beginning of vpif_probe.
>
> Signed-off-by: Georgios Plakaris
> Signed-off-by: Hans Verkuil
>
> diff --git a/drivers/media/video/davinci/vpif_capture.c
> b/drivers/media/video/davinci/vpif_capture.c
> index 49e4deb..6504e40 100644
> --- a/drivers/media/video/davinci/vpif_capture.c
> +++ b/drivers/media/video/davinci/vpif_capture.c
> @@ -2177,6 +2177,12 @@ static __init int vpif_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + err = v4l2_device_register(vpif_dev, &vpif_obj.v4l2_dev);
> + if (err) {
> + v4l2_err(vpif_dev->driver, "Error registering v4l2 device\n");
> + return err;
> + }
> +
> k = 0;
> while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
> for (i = res->start; i <= res->end; i++) { @@ -2246,12 +2252,6
> @@ static __init int vpif_probe(struct platform_device *pdev)
> goto probe_out;
> }
>
> - err = v4l2_device_register(vpif_dev, &vpif_obj.v4l2_dev);
> - if (err) {
> - v4l2_err(vpif_dev->driver, "Error registering v4l2 device\n");
> - goto probe_subdev_out;
> - }
> -
> for (i = 0; i < subdev_count; i++) {
> subdevdata = &config->subdev_info[i];
> vpif_obj.sd[i] =
> @@ -2281,7 +2281,6 @@ probe_subdev_out:
>
> j = VPIF_CAPTURE_MAX_DEVICES;
> probe_out:
> - v4l2_device_unregister(&vpif_obj.v4l2_dev);
> for (k = 0; k < j; k++) {
> /* Get the pointer to the channel object */
> ch = vpif_obj.dev[k];
> @@ -2303,6 +2302,7 @@ vpif_int_err:
> if (res)
> i = res->end;
> }
> + v4l2_device_unregister(&vpif_obj.v4l2_dev);
> return err;
> }
>
>
>
>
ACKed by me.
Thx,
-Manju
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/5] ARM: davinci: re-arrange definitions to have a common davinci header
Sekhar, On Wed, Nov 30, 2011 at 17:07:21, Nori, Sekhar wrote: > Hi Manju, > > On Thu, Nov 17, 2011 at 15:48:53, Hadli, Manjunath wrote: > > Re-arrange definitions and remove unnecessary code so that we canx > > These are two different things and should be done in separate patches. Sergei > has already pointed out couple of instances. Ok, This is only subject for the cover letter and not individual patches. The individual patches have separate modularized implementations. I will change the cover letter subject to "remove private definitions from headers and move to C files". Is that OK? > > > have a common header for all davinci platforms. This will enable > > You mean all DMx platforms? DA8x and TNETVx will still have their own header > files after this patch set. Yes, DMx platforms. I will also change the common "davinci.h" to dmx.h ? > > > us to share defines and enable common routines to be used without > > polluting hardware.h. > > This patch set forms the base for a later set of patches for having a > > common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > > > Changes from previous version(As per Sergei's comments): > > 1. Renamed davinci_common.h to davinci.h. > > 2. Added extra line whereever appropriate. > > 3. removed unnecessary header inclusion. > > > > Manjunath Hadli (5): > > ARM: davinci: dm644x: remove the macros from the header to move to c > > file > > ARM: davinci: dm365: remove the macros from the header to move to c > > file > > ARM: davinci: dm646x: remove the macros from the header to move to c > > file > > These headlines should describe the changes better. You are moving _private_ > defines to C file (to reduce header file pollution). That should be clear > from the headline. > > > ARM: davinci: create new common platform header for davinci > > ARM: davinci: delete individual platform header files and use a > > common header > > > > arch/arm/mach-davinci/board-dm355-evm.c |2 +- > > arch/arm/mach-davinci/board-dm355-leopard.c |2 +- > > arch/arm/mach-davinci/board-dm365-evm.c |2 +- > > arch/arm/mach-davinci/board-dm644x-evm.c |2 +- > > arch/arm/mach-davinci/board-dm646x-evm.c |2 +- > > arch/arm/mach-davinci/board-neuros-osd2.c|2 +- > > arch/arm/mach-davinci/board-sffsdr.c |2 +- > > arch/arm/mach-davinci/dm355.c|2 +- > > arch/arm/mach-davinci/dm365.c| 18 +- > > arch/arm/mach-davinci/dm644x.c |9 +++- > > arch/arm/mach-davinci/dm646x.c |9 +++- > > arch/arm/mach-davinci/include/mach/davinci.h | 88 > > ++ > > This file should be placed in arch/arm/mach-davinci itself since the > definitions are private to arch/arm/mach-davinci. > Russell has been complaining about placing unnecessary files in include/mach. I will just check if the file is needed from the main driver files. If not, I will move it to mach-davinci. > > Thanks, > Sekhar > > Thanks and Regards, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] board-dm646x-evm.c: wrong register used in setup_vpif_input_channel_mode
Hans,
Thank you for the patch. I have verified from the data sheet.
It might be a copy mistake. It also says the vpif_vsclkdis_reg
can be used to disable and enable in case we make any clock switches
so as to avoid glitches.
In this case I would imagine we would stream off before switching, so
That might not be a necessity.
I have not been able to test this however. Trust you would have.
Acked-by: Manjunath Hadli
Thanks and Regards,
-Manju
On Mon, Nov 14, 2011 at 23:50:49, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The function setup_vpif_input_channel_mode() used the VSCLKDIS register
> instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0
> used a different clock from channel 1.
>
> Clearly a copy-and-paste error.
>
> Signed-off-by: Hans Verkuil
> ---
> arch/arm/mach-davinci/board-dm646x-evm.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
> b/arch/arm/mach-davinci/board-dm646x-evm.c
> index 337c45e..607a527 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -563,7 +563,7 @@ static int setup_vpif_input_channel_mode(int mux_mode)
> int val;
> u32 value;
>
> - if (!vpif_vsclkdis_reg || !cpld_client)
> + if (!vpif_vidclkctl_reg || !cpld_client)
> return -ENXIO;
>
> val = i2c_smbus_read_byte(cpld_client); @@ -571,7 +571,7 @@ static int
> setup_vpif_input_channel_mode(int mux_mode)
> return val;
>
> spin_lock_irqsave(&vpif_reg_lock, flags);
> - value = __raw_readl(vpif_vsclkdis_reg);
> + value = __raw_readl(vpif_vidclkctl_reg);
> if (mux_mode) {
> val &= VPIF_INPUT_TWO_CHANNEL;
> value |= VIDCH1CLK;
> @@ -579,7 +579,7 @@ static int setup_vpif_input_channel_mode(int mux_mode)
> val |= VPIF_INPUT_ONE_CHANNEL;
> value &= ~VIDCH1CLK;
> }
> - __raw_writel(value, vpif_vsclkdis_reg);
> + __raw_writel(value, vpif_vidclkctl_reg);
> spin_unlock_irqrestore(&vpif_reg_lock, flags);
>
> err = i2c_smbus_write_byte(cpld_client, val);
> --
> 1.7.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/5] ARM: davinci: create new common platform header for davinci
Sergei, Thank you for the comments. On Thu, Nov 17, 2011 at 16:18:17, Sergei Shtylyov wrote: > Hello. > > On 17-11-2011 14:18, Manjunath Hadli wrote: > > > remove the code from individual platform header files for dm365, > > dm355, dm644x and dm646x and consolidate it into a single and common > > header file davinci_common.h. > > Include the new header file in individual platform header files as a > > pre-cursor for deleting these headers in follow up patches. > > > Signed-off-by: Manjunath Hadli > [...] > > > diff --git a/arch/arm/mach-davinci/include/mach/davinci.h > > b/arch/arm/mach-davinci/include/mach/davinci.h > > new file mode 100644 > > index 000..49bf2f3 > > --- /dev/null > > +++ b/arch/arm/mach-davinci/include/mach/davinci.h > > @@ -0,0 +1,88 @@ > [...] > > +/* DM355 base addresses */ > > +#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e1 > > +#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x0200 > > > +/* DM365 base addresses */ > > +#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d1 > > +#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x0200 > > +#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x0400 > > Note that DM355/365 EMIF CE0/1 bases are similar -- perhaps it's worth to > have the single definition for them now, like > DM3X5_ASYNC_EMIF_DATA_CE_BASE. There is only DM355 and DM365. DM3X5 has not been used anywhere till now. Too much generalization in naming might lead to confusion? I guess we will keep it as-is for the sake of clarity. What do you say? > > WBR, Sergei > Thank s and Regards, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/5] davinci: dm644x: remove the macros from the header to move to c file
Sergei,
On Tue, Nov 15, 2011 at 16:10:16, Sergei Shtylyov wrote:
> Hello.
>
> On 14-11-2011 19:09, Manjunath Hadli wrote:
>
> > move the register base addresses and offsets used only by dm644x
> > platform file from platform header dm644x.h to dm644x.c as they are
> > used only in the c file.
>
> > Signed-off-by: Manjunath Hadli
> > ---
> > arch/arm/mach-davinci/dm644x.c |6 ++
> > arch/arm/mach-davinci/include/mach/dm644x.h |7 ---
> > 2 files changed, 6 insertions(+), 7 deletions(-)
>
> > diff --git a/arch/arm/mach-davinci/dm644x.c
> > b/arch/arm/mach-davinci/dm644x.c index 3470983..1b4b911 100644
> > --- a/arch/arm/mach-davinci/dm644x.c
> > +++ b/arch/arm/mach-davinci/dm644x.c
> > @@ -34,6 +34,12 @@
> >* Device specific clocks
> >*/
> > #define DM644X_REF_FREQ 2700
>
> Add an empty line here please.
Ok.
Regards,
--Manju
>
> > +#define DM644X_EMAC_BASE 0x01c8
> > +#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000)
> > +#define DM644X_EMAC_CNTRL_OFFSET 0x
> > +#define DM644X_EMAC_CNTRL_MOD_OFFSET 0x1000
> > +#define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000
> > +#define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000
> >
> > static struct pll_data pll1_data = {
> > .num = 1,
>
> WBR, Sergei
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 5/5] davinci: delete individual platform header files and use a common header
Sergei, On Tue, Nov 15, 2011 at 16:24:49, Sergei Shtylyov wrote: > Hello. > > On 14-11-2011 19:09, Manjunath Hadli wrote: > > > include davinci_common.h file in files using the platform header file > > for dm355, dm365, dm644x and dm646x and delete the individual platform > > header files. > > > Signed-off-by: Manjunath Hadli > [...] > > > diff --git a/drivers/media/video/davinci/vpif.h > > b/drivers/media/video/davinci/vpif.h > > index 25036cb..73b00bd 100644 > > --- a/drivers/media/video/davinci/vpif.h > > +++ b/drivers/media/video/davinci/vpif.h > > @@ -18,8 +18,7 @@ > > > > #include > > #include > > -#include > > Why are you removing this? It currently builds without the hardware.h. Perhaps it is not using any of the defines. > > > -#include > > +#include > > #include > > > > /* Maximum channel allowed */ > > diff --git a/drivers/media/video/davinci/vpif_capture.h > > b/drivers/media/video/davinci/vpif_capture.h > > index a693d4e..c019d26 100644 > > --- a/drivers/media/video/davinci/vpif_capture.h > > +++ b/drivers/media/video/davinci/vpif_capture.h > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include > > Not clear why are you adding this when no platform header was included > before. There was an inner inclusion of i2c.h. Will correct it for i2c.h only and remove davinci_common.h > > WBR, Sergei > > Thx, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/5] davinci: create new common platform header for davinci
Sergei, On Tue, Nov 15, 2011 at 15:33:14, Sergei Shtylyov wrote: > Hello. > > On 14-11-2011 19:09, Manjunath Hadli wrote: > > > remove the code from individual platform header files for dm365, > > dm355, dm644x and dm646x and consolidate it into a single and common > > header file davinci_common.h. > > Include the new header file in individual platform header files as a > > pre-cursor for deleting these headers in follow up patches. > > > Signed-off-by: Manjunath Hadli > > --- > > .../arm/mach-davinci/include/mach/davinci_common.h | 88 > > > > arch/arm/mach-davinci/include/mach/dm355.h | 18 + > > arch/arm/mach-davinci/include/mach/dm365.h | 20 + > > arch/arm/mach-davinci/include/mach/dm644x.h| 15 +--- > > arch/arm/mach-davinci/include/mach/dm646x.h| 20 + > > 5 files changed, 92 insertions(+), 69 deletions(-) > > create mode 100644 > > arch/arm/mach-davinci/include/mach/davinci_common.h > > > diff --git a/arch/arm/mach-davinci/include/mach/davinci_common.h > > b/arch/arm/mach-davinci/include/mach/davinci_common.h > > new file mode 100644 > > index 000..a859318 > > --- /dev/null > > +++ b/arch/arm/mach-davinci/include/mach/davinci_common.h > > Why not call it just davinci.h? Ok. Regards, --Manju > > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] davinci vpbe: enable DM365 v4l2 display driver
Mauro, A gentle reminder for the pull request. These have been acked by Hans. Cheers, -Manju On Wed, Sep 28, 2011 at 18:32:48, Hadli, Manjunath wrote: > Mauro, > Please pull : > git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_mauro > > The patchset adds incremental changes necessary to enable dm365 > v4l2 display driver, which includes vpbe display driver changes, osd specific > changes and venc changes. The changes are incremental in nature,addind a few > HD modes, and taking care of register level changes. > > The patches are tested for both SD and HD modes. > > Manjunath Hadli (3): > davinci vpbe: add dm365 VPBE display driver changes > davinci vpbe: add dm365 and dm355 specific OSD changes > davinci vpbe: add VENC block changes to enable dm365 and dm355 > > drivers/media/video/davinci/vpbe.c | 48 +++- > drivers/media/video/davinci/vpbe_osd.c | 472 > --- drivers/media/video/davinci/vpbe_venc.c | > 205 -- > include/media/davinci/vpbe.h| 16 + > include/media/davinci/vpbe_venc.h |4 + > 5 files changed, 677 insertions(+), 68 deletions(-) > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
new mbus formats
Hi, I need a few mbus formats to be defined loosely for following. Please tell me if anyone has already thought of taking care of them already. These are supported for Texas Instruments DM365 and DM355 SoCs. 1. RGB 888 parallel: 2. YUV420 color separate: 3. C plane 420: ( On the lines of Y plane: V4L2_MBUS_FMT_Y8_1X8) 4. C plane 422 5. 10 bit bayer with ALAW compression. If not, could you please suggest/discuss on the possible MBUS formats for the above? Thanks and Regards, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND 2/4] davinci vpbe: add dm365 VPBE display driver changes
On Mon, Sep 26, 2011 at 18:31:48, Hans Verkuil wrote:
> On Monday, September 19, 2011 07:35:27 Manjunath Hadli wrote:
> > This patch implements the core additions to the display driver, mainly
> > controlling the VENC and other encoders for dm365.
> > This patch also includes addition of amplifier subdevice to the vpbe
> > driver and interfacing with venc subdevice.
> >
> > Signed-off-by: Manjunath Hadli
> > ---
> > drivers/media/video/davinci/vpbe.c | 55
> > ++--
> > include/media/davinci/vpbe.h | 16 ++
> > 2 files changed, 68 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/video/davinci/vpbe.c
> > b/drivers/media/video/davinci/vpbe.c
> > index d773d30..21a8645 100644
> > --- a/drivers/media/video/davinci/vpbe.c
> > +++ b/drivers/media/video/davinci/vpbe.c
> > @@ -141,11 +141,12 @@ static int vpbe_enum_outputs(struct vpbe_device
> > *vpbe_dev,
> > return 0;
> > }
> >
> > -static int vpbe_get_mode_info(struct vpbe_device *vpbe_dev, char
> > *mode)
Hans,
> > +static int vpbe_get_mode_info(struct vpbe_device *vpbe_dev, char *mode,
> > + int output_index)
> > {
> > struct vpbe_config *cfg = vpbe_dev->cfg;
> > struct vpbe_enc_mode_info var;
> > - int curr_output = vpbe_dev->current_out_index;
> > + int curr_output = output_index;
> > int i;
> >
> > if (NULL == mode)
> > @@ -245,6 +246,8 @@ static int vpbe_set_output(struct vpbe_device
> > *vpbe_dev, int index)
> > struct encoder_config_info *curr_enc_info =
> > vpbe_current_encoder_info(vpbe_dev);
> > struct vpbe_config *cfg = vpbe_dev->cfg;
> > + struct venc_platform_data *venc_device = vpbe_dev->venc_device;
> > + enum v4l2_mbus_pixelcode if_params;
> > int enc_out_index;
> > int sd_index;
> > int ret = 0;
> > @@ -274,6 +277,8 @@ static int vpbe_set_output(struct vpbe_device
> > *vpbe_dev, int index)
> > goto out;
> > }
> >
> > + if_params = cfg->outputs[index].if_params;
> > + venc_device->setup_if_config(if_params);
> > if (ret)
> > goto out;
> > }
> > @@ -293,7 +298,7 @@ static int vpbe_set_output(struct vpbe_device
> > *vpbe_dev, int index)
> > * encoder.
> > */
> > ret = vpbe_get_mode_info(vpbe_dev,
> > -cfg->outputs[index].default_mode);
> > +cfg->outputs[index].default_mode, index);
> > if (!ret) {
> > struct osd_state *osd_device = vpbe_dev->osd_device;
> >
> > @@ -367,6 +372,11 @@ static int vpbe_s_dv_preset(struct vpbe_device
> > *vpbe_dev,
> >
> > ret = v4l2_subdev_call(vpbe_dev->encoders[sd_index], video,
> > s_dv_preset, dv_preset);
> > + if (!ret && (vpbe_dev->amp != NULL)) {
> > + /* Call amplifier subdevice */
> > + ret = v4l2_subdev_call(vpbe_dev->amp, video,
> > + s_dv_preset, dv_preset);
> > + }
> > /* set the lcd controller output for the given mode */
> > if (!ret) {
> > struct osd_state *osd_device = vpbe_dev->osd_device; @@ -566,6
> > +576,8 @@ static int platform_device_get(struct device *dev, void
> > *data)
> >
> > if (strcmp("vpbe-osd", pdev->name) == 0)
> > vpbe_dev->osd_device = platform_get_drvdata(pdev);
> > + if (strcmp("vpbe-venc", pdev->name) == 0)
> > + vpbe_dev->venc_device = dev_get_platdata(&pdev->dev);
> >
> > return 0;
> > }
> > @@ -584,6 +596,7 @@ static int platform_device_get(struct device *dev,
> > void *data) static int vpbe_initialize(struct device *dev, struct
> > vpbe_device *vpbe_dev) {
> > struct encoder_config_info *enc_info;
> > + struct amp_config_info *amp_info;
> > struct v4l2_subdev **enc_subdev;
> > struct osd_state *osd_device;
> > struct i2c_adapter *i2c_adap;
> > @@ -704,6 +717,39 @@ static int vpbe_initialize(struct device *dev, struct
> > vpbe_device *vpbe_dev)
> > v4l2_warn(&vpbe_dev->v4l2_dev, "non-i2c encoders"
> > " currently not supported");
> > }
> > + /* Add amplifier subdevice for dm365 */
> > + if ((strcmp(vpbe_dev->cfg->module_name, "dm365-vpbe-display") == 0) &&
> > + vpbe_dev->cfg->amp != NULL) {
> > + vpbe_dev->amp = kmalloc(sizeof(struct v4l2_subdev *),
> > + GFP_KERNEL);
>
> Huh? Why alloc a struct v4l2_subdev pointer here?
>
> > + if (vpbe_dev->amp == NULL) {
> > + v4l2_err(&vpbe_dev->v4l2_dev,
> > + "unable to allocate memory for sub device");
> > + ret = -ENOMEM;
> > + goto vpbe_fail_v4l2_device;
> > + }
> > + amp_info = vpbe_dev->cfg->amp;
> > + if (amp_info->is_i2c) {
> > + vpbe_dev->amp = v4l2_i2c_n
RE: [PATCH RESEND 0/4] davinci vpbe: enable DM365 v4l2 display driver
On Mon, Sep 26, 2011 at 16:46:52, Hans Verkuil wrote: > On Monday, September 19, 2011 07:49:18 Hadli, Manjunath wrote: > > Sakari, Hans, > > Can I request you to have a look at these patches too? > > It's on my TODO list for this week. Thank you Hans. I will pull request nevertheless, and Mauro can take a call if he wants to defer. Thx, -Manju > > Regards, > > Hans > > > > > Thanks and Regards, > > -Manju > > > > On Mon, Sep 19, 2011 at 11:05:25, Hadli, Manjunath wrote: > > > The patchset adds incremental changes necessary to enable dm365 > > > v4l2 display driver, which includes vpbe display driver changes, osd > > > specific changes and venc changes. The changes are incremental in > > > nature,addind a few HD modes, and taking care of register level changes. > > > > > > The patch set does not include THS7303 amplifier driver which is planned > > > to be sent seperately. > > > > > > > > > Manjunath Hadli (4): > > > davinci vpbe: remove unused macro. > > > davinci vpbe: add dm365 VPBE display driver changes > > > davinci vpbe: add dm365 and dm355 specific OSD changes > > > davinci vpbe: add VENC block changes to enable dm365 and dm355 > > > > > > drivers/media/video/davinci/vpbe.c | 55 +++- > > > drivers/media/video/davinci/vpbe_display.c |1 - > > > drivers/media/video/davinci/vpbe_osd.c | 474 > > > +--- > > > drivers/media/video/davinci/vpbe_venc.c| 205 +++-- > > > include/media/davinci/vpbe.h | 16 + > > > include/media/davinci/vpbe_venc.h |4 + > > > 6 files changed, 686 insertions(+), 69 deletions(-) > > > > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" > > in the body of a message to majord...@vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND 0/4] davinci vpbe: enable DM365 v4l2 display driver
On Sat, Sep 24, 2011 at 05:08:34, Mauro Carvalho Chehab wrote: > Em 19-09-2011 02:35, Manjunath Hadli escreveu: > > The patchset adds incremental changes necessary to enable dm365 > > v4l2 display driver, which includes vpbe display driver changes, osd > > specific changes and venc changes. The changes are incremental in > > nature,addind a few HD modes, and taking care of register level > > changes. > > > > The patch set does not include THS7303 amplifier driver which is > > planned to be sent seperately. > > > > > > Manjunath Hadli (4): > > davinci vpbe: remove unused macro. > > davinci vpbe: add dm365 VPBE display driver changes > > davinci vpbe: add dm365 and dm355 specific OSD changes > > davinci vpbe: add VENC block changes to enable dm365 and dm355 > > > > drivers/media/video/davinci/vpbe.c | 55 +++- > > drivers/media/video/davinci/vpbe_display.c |1 - > > drivers/media/video/davinci/vpbe_osd.c | 474 > > +--- > > drivers/media/video/davinci/vpbe_venc.c| 205 +++-- > > include/media/davinci/vpbe.h | 16 + > > include/media/davinci/vpbe_venc.h |4 + > > 6 files changed, 686 insertions(+), 69 deletions(-) > > > Not sure why are you re-sending this patch series. To whom are you re-sending > it? You have your git access at linuxtv.org. So, if the patches are ready for > merge, just send me a pull request. Otherwise, please mark the patches as RFC > or send to the one that will maintain the driver, c/c the mailing list. Thank you Mauro. I will send you a pull request for the rest of the three patches. -Manju > > In any case, I'll mark the patches 2-4 as RFC (patch 1 is too trivial, I'll > just apply it, to never see it again ;) ). > > Thanks, > Mauro > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" > > in the body of a message to majord...@vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND 1/4] davinci vpbe: remove unused macro.
On Sat, Sep 24, 2011 at 05:04:26, Mauro Carvalho Chehab wrote: > Em 19-09-2011 02:35, Manjunath Hadli escreveu: > > remove VPBE_DISPLAY_SD_BUF_SIZE as it is no longer used. > > > > Signed-off-by: Manjunath Hadli > > --- > > drivers/media/video/davinci/vpbe_display.c |1 - > > 1 files changed, 0 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/media/video/davinci/vpbe_display.c > > b/drivers/media/video/davinci/vpbe_display.c > > index ae7add1..09a659e 100644 > > --- a/drivers/media/video/davinci/vpbe_display.c > > +++ b/drivers/media/video/davinci/vpbe_display.c > > @@ -43,7 +43,6 @@ > > > > static int debug; > > > > -#define VPBE_DISPLAY_SD_BUF_SIZE (720*576*2) #define > > VPBE_DEFAULT_NUM_BUFS 3 > > > > module_param(debug, int, 0644); > > This is really trivial. I won't wait for your pull request to merge this one > ;) Thank you Mauro. > > Thanks, > Mauro > Thx, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND 0/4] davinci vpbe: enable DM365 v4l2 display driver
Sakari, Hans, Can I request you to have a look at these patches too? Thanks and Regards, -Manju On Mon, Sep 19, 2011 at 11:05:25, Hadli, Manjunath wrote: > The patchset adds incremental changes necessary to enable dm365 > v4l2 display driver, which includes vpbe display driver changes, osd specific > changes and venc changes. The changes are incremental in nature,addind a few > HD modes, and taking care of register level changes. > > The patch set does not include THS7303 amplifier driver which is planned to > be sent seperately. > > > Manjunath Hadli (4): > davinci vpbe: remove unused macro. > davinci vpbe: add dm365 VPBE display driver changes > davinci vpbe: add dm365 and dm355 specific OSD changes > davinci vpbe: add VENC block changes to enable dm365 and dm355 > > drivers/media/video/davinci/vpbe.c | 55 +++- > drivers/media/video/davinci/vpbe_display.c |1 - > drivers/media/video/davinci/vpbe_osd.c | 474 > +--- > drivers/media/video/davinci/vpbe_venc.c| 205 +++-- > include/media/davinci/vpbe.h | 16 + > include/media/davinci/vpbe_venc.h |4 + > 6 files changed, 686 insertions(+), 69 deletions(-) > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Mauro, Thank you for your note. The first RFC for this (VPFE MC) driver was sent only in August this year. The other driver being discussed before was VPBE (which did go through some grind but not 2 years) which you accepted. This series of patches is definitely not two years old (unless I am mistaken somewhere). Currently Sakari is taking active interest in reviewing the patches, but I would like to take the cue from your note to request others also to actively review these patches and help me get them accepted. Thanks and Regards, -Manju On Sun, Sep 18, 2011 at 20:05:46, Mauro Carvalho Chehab wrote: > Em 29-08-2011 12:07, Manjunath Hadli escreveu: > > changes from last patch set: > > 1. Made changes based on Sakari's feedback mainly: > > a. returned early to allow unindenting > > b. reformatting to shift the code to left where possible > > c. changed hex numbers to lower case > > d. corrected the defines according to module names. > > e. magic numbers removed. > > f. changed non-integer returning functions to void > > g. removed unwanted paranthses. > > h. fixed error codes. > > i. fixed some RESET_BIt code to what it was intended for. > > 2. reorganized the header files to move the kernel-only headers along > > with the c files and interface headers in the include folder. > > Manju, > > Please be sure to send me a pull request when you think this driver is ready > for merge. The first submission I'm noticing for this driver was back on > 2009, and still today, nobody sent me a git pull request for it. Two years > seems too much time to solve the pending issues and sending a pull request > for me to merge it! > > > > Manjunath Hadli (6): > > davinci: vpfe: add dm3xx IPIPEIF hardware support module > > davinci: vpfe: add support for CCDC hardware for dm365 > > davinci: vpfe: add ccdc driver with media controller interface > > davinci: vpfe: add v4l2 video driver support > > davinci: vpfe: v4l2 capture driver with media interface > > davinci: vpfe: build infrastructure for dm365 > > > > Nagabhushana Netagunte (2): > > davinci: vpfe: add IPIPE hardware layer support > > davinci: vpfe: add IPIPE support for media controller driver > > > > drivers/media/video/davinci/Kconfig | 46 +- > > drivers/media/video/davinci/Makefile | 17 +- > > drivers/media/video/davinci/ccdc_hw_device.h | 10 +- > > drivers/media/video/davinci/ccdc_types.h | 43 + > > drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ > > drivers/media/video/davinci/dm365_ccdc.h | 88 + > > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ > > drivers/media/video/davinci/dm365_def_para.c | 486 +++ > > drivers/media/video/davinci/dm365_def_para.h | 39 + > > drivers/media/video/davinci/dm365_ipipe.c | 3966 > > + > > drivers/media/video/davinci/dm365_ipipe.h | 300 ++ > > drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ > > drivers/media/video/davinci/dm365_ipipe_hw.h | 539 > > drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ > > drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ > > drivers/media/video/davinci/imp_common.h | 85 + > > drivers/media/video/davinci/imp_hw_if.h | 178 ++ > > drivers/media/video/davinci/vpfe_capture.c| 793 + > > drivers/media/video/davinci/vpfe_capture.h| 104 + > > drivers/media/video/davinci/vpfe_ccdc.c | 813 + > > drivers/media/video/davinci/vpfe_ccdc.h | 85 + > > drivers/media/video/davinci/vpfe_video.c | 1712 +++ > > drivers/media/video/davinci/vpfe_video.h | 142 + > > include/linux/davinci_vpfe.h | 1223 > > include/linux/dm365_ccdc.h| 664 + > > include/linux/dm3xx_ipipeif.h | 64 + > > include/media/davinci/vpfe.h | 91 + > > 27 files changed, 14829 insertions(+), 11 deletions(-) create mode > > 100644 drivers/media/video/davinci/ccdc_types.h > > create mode 100644 drivers/media/video/davinci/dm365_ccdc.c > > create mode 100644 drivers/media/video/davinci/dm365_ccdc.h > > create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h > > create mode 100644 drivers/media/video/davinci/dm365_def_para.c > > create mode 100644 drivers/media/video/davinci/dm365_def_para.h > > create mode 100644 drivers/media/video/davinci/dm365_ipipe.c > > create mode 100644 drivers/media/video/davinci/dm365_ipipe.h > > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c > > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h > > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c > > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h > > create mode 100644 drivers/media/video/davinci/imp_common.h > > create mode 100644 drivers/media/video/davinci/imp_hw_if.h > > create
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Thank you Sakari. -Manju On Mon, Sep 12, 2011 at 17:29:25, Sakari Ailus wrote: > On Sat, Sep 10, 2011 at 12:11:37PM +0530, Hadli, Manjunath wrote: > > Hi Sakari, > > On Fri, Sep 09, 2011 at 21:49:40, Sakari Ailus wrote: > > > On Fri, Sep 09, 2011 at 07:10:49PM +0530, Hadli, Manjunath wrote: > > > > Hi Sakari, > > > > > > > > On Thu, Sep 01, 2011 at 03:00:32, Sakari Ailus wrote: > > > > > Hi Manju, > > > > > > > > > > Do you have the media device grap that would be typical for this > > > > > hardware produced by media-ctl? That can be converted to postscript > > > > > using dotfile. > > > > > > > > > > this would make it a little easier to understan this driver. Thanks. > > > > > > > > Sure. But can you be a little more elaborate on how you need this > > > > information? If you can tell me in little more detail about this > > > > that will help me make the information in a way that everyone can > > > > understand. > > > > > > Preferrably in PostScript format so it's easy to visualise the layout of > > > the hardware that the driver supports, as the OMAP 3 ISP example was. > > Sure. > > I was more looking for an example of the same so it could help me put > > the data together in the way it has been done before. Can you send > > across if you have one? > > Ah. I think I misunderstood you first. :-) > > On the device, run > > $ media-ctl --print-dot > graph.dot > > This will produce a graph of the media device in the dot format. This is then > processed by program called dot: > > $ dot -o graph.ps -T ps < graph.dot > > dot is available at least in Debian in a package called graphviz. > > Cheers, > > -- > Sakari Ailus > e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Hi Sakari, On Fri, Sep 09, 2011 at 21:49:40, Sakari Ailus wrote: > On Fri, Sep 09, 2011 at 07:10:49PM +0530, Hadli, Manjunath wrote: > > Hi Sakari, > > > > On Thu, Sep 01, 2011 at 03:00:32, Sakari Ailus wrote: > > > Hi Manju, > > > > > > Do you have the media device grap that would be typical for this hardware > > > produced by media-ctl? That can be converted to postscript using dotfile. > > > > > > this would make it a little easier to understan this driver. Thanks. > > > > Sure. But can you be a little more elaborate on how you need this > > information? If you can tell me in little more detail about this that > > will help me make the information in a way that everyone can understand. > > Preferrably in PostScript format so it's easy to visualise the layout of the > hardware that the driver supports, as the OMAP 3 ISP example was. Sure. I was more looking for an example of the same so it could help me put the data together in the way it has been done before. Can you send across if you have one? Many Thx, -Manju > > > Thanks and Regards, > > -Manju > > > > > > > > > > On Mon, Aug 29, 2011 at 08:37:11PM +0530, Manjunath Hadli wrote: > > > > changes from last patch set: > > > > 1. Made changes based on Sakari's feedback mainly: > > > > a. returned early to allow unindenting > > > > b. reformatting to shift the code to left where possible > > > > c. changed hex numbers to lower case > > > > d. corrected the defines according to module names. > > > > e. magic numbers removed. > > > > f. changed non-integer returning functions to void > > > > g. removed unwanted paranthses. > > > > h. fixed error codes. > > > > i. fixed some RESET_BIt code to what it was intended for. > > > > 2. reorganized the header files to move the kernel-only headers > > > > along with the c files and interface headers in the include folder. > > > > > > ... > > > > > > -- > Sakari Ailus > e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Hi Sakari, On Thu, Sep 01, 2011 at 03:00:32, Sakari Ailus wrote: > Hi Manju, > > Do you have the media device grap that would be typical for this hardware > produced by media-ctl? That can be converted to postscript using dotfile. > > this would make it a little easier to understan this driver. Thanks. Sure. But can you be a little more elaborate on how you need this information? If you can tell me in little more detail about this that will help me make the information in a way that everyone can understand. Thanks and Regards, -Manju > > On Mon, Aug 29, 2011 at 08:37:11PM +0530, Manjunath Hadli wrote: > > changes from last patch set: > > 1. Made changes based on Sakari's feedback mainly: > > a. returned early to allow unindenting > > b. reformatting to shift the code to left where possible > > c. changed hex numbers to lower case > > d. corrected the defines according to module names. > > e. magic numbers removed. > > f. changed non-integer returning functions to void > > g. removed unwanted paranthses. > > h. fixed error codes. > > i. fixed some RESET_BIt code to what it was intended for. > > 2. reorganized the header files to move the kernel-only headers along > > with the c files and interface headers in the include folder. > > ... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/8] davinci: vpfe: add support for CCDC hardware for dm365
Thank you for these comments too. My responses inlined. -Manju On Fri, Sep 02, 2011 at 02:53:08, Sylwester Nawrocki wrote: > Hi Manjunath, > > few more comments below.. > > On 08/29/2011 05:07 PM, Manjunath Hadli wrote: > > add support for ccdc on dm365 SoC. ccdc is responsible for capturing > > video data- both raw bayer through sync seperate signals and through > > BT656/1120 interfaces. This driver implements the hardware > > functionality. Mainly- setting of hardware, validation of parameters, > > and isr configuration. > > > > Signed-off-by: Manjunath Hadli > > Signed-off-by: Nagabhushana Netagunte > > --- > > drivers/media/video/davinci/ccdc_types.h | 43 + > > drivers/media/video/davinci/dm365_ccdc.c | 1519 > > + > > drivers/media/video/davinci/dm365_ccdc.h | 88 ++ > > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 + > > include/linux/dm365_ccdc.h| 664 +++ > > 5 files changed, 2623 insertions(+), 0 deletions(-) > > create mode 100644 drivers/media/video/davinci/ccdc_types.h > > create mode 100644 drivers/media/video/davinci/dm365_ccdc.c > > create mode 100644 drivers/media/video/davinci/dm365_ccdc.h > > create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h > > create mode 100644 include/linux/dm365_ccdc.h > ... > > +#define CCDC_LINEAR_LUT0_ADDR 0x1c7c000 > > +#define CCDC_LINEAR_LUT1_ADDR 0x1c7c400 > > + > > +/* Masks& Shifts below */ > > +#define START_PX_HOR_MASK (0x7fff) > > +#define NUM_PX_HOR_MASK(0x7fff) > > +#define START_VER_ONE_MASK (0x7fff) > > +#define START_VER_TWO_MASK (0x7fff) > > +#define NUM_LINES_VER (0x7fff) > > + > > +/* gain - offset masks */ > > +#define GAIN_INTEGER_MASK (0x7) > > +#define GAIN_INTEGER_SHIFT (0x9) > > +#define GAIN_DECIMAL_MASK (0x1ff) > > +#define OFFSET_MASK(0xfff) > > +#define GAIN_SDRAM_EN_SHIFT(12) > > +#define GAIN_IPIPE_EN_SHIFT(13) > > +#define GAIN_H3A_EN_SHIFT (14) > > +#define OFST_SDRAM_EN_SHIFT(8) > > +#define OFST_IPIPE_EN_SHIFT(9) > > +#define OFST_H3A_EN_SHIFT (10) > > +#define GAIN_OFFSET_EN_MASK(0x7700) > > + > > +/* Culling */ > > +#define CULL_PAT_EVEN_LINE_SHIFT (8) > > + > > +/* CCDCFG register */ > > +#define CCDC_YCINSWP_RAW (0x00<< 4) > > +#define CCDC_YCINSWP_YCBCR (0x01<< 4) > > +#define CCDC_CCDCFG_FIDMD_LATCH_VSYNC (0x00<< 6) > > +#define CCDC_CCDCFG_WENLOG_AND (0x00<< 8) > > +#define CCDC_CCDCFG_TRGSEL_WEN (0x00<< 9) > > +#define CCDC_CCDCFG_EXTRG_DISABLE (0x00<< 10) > > +#define CCDC_LATCH_ON_VSYNC_DISABLE(0x01<< 15) > > +#define CCDC_LATCH_ON_VSYNC_ENABLE (0x00<< 15) > > +#define CCDC_DATA_PACK_MASK(0x03) > > +#define CCDC_DATA_PACK16 (0x0) > > +#define CCDC_DATA_PACK12 (0x1) > > +#define CCDC_DATA_PACK8(0x2) > > +#define CCDC_PIX_ORDER_SHIFT (11) > > +#define CCDC_PIX_ORDER_MASK(0x01) > > +#define CCDC_BW656_ENABLE (0x01<< 5) > > + > > +/* MODESET registers */ > > +#define CCDC_VDHDOUT_INPUT (0x00<< 0) > > +#define CCDC_INPUT_MASK(0x03) > > +#define CCDC_INPUT_SHIFT (12) > > +#define CCDC_RAW_INPUT_MODE(0x00) > > +#define CCDC_FID_POL_MASK (0x01) > > +#define CCDC_FID_POL_SHIFT (4) > > +#define CCDC_HD_POL_MASK (0x01) > > +#define CCDC_HD_POL_SHIFT (3) > > +#define CCDC_VD_POL_MASK (0x01) > > +#define CCDC_VD_POL_SHIFT (2) > > +#define CCDC_DATAPOL_NORMAL(0x00) > > +#define CCDC_DATAPOL_MASK (0x01) > > +#define CCDC_DATAPOL_SHIFT (6) > > +#define CCDC_EXWEN_DISABLE (0x00) > > +#define CCDC_EXWEN_MASK(0x01) > > +#define CCDC_EXWEN_SHIFT (5) > > +#define CCDC_FRM_FMT_MASK (0x01) > > +#define CCDC_FRM_FMT_SHIFT (7) > > +#define CCDC_DATASFT_MASK (0x07) > > +#define CCDC_DATASFT_SHIFT (8) > > +#define CCDC_LPF_SHIFT (14) > > +#define CCDC_LPF_MASK (0x1) > > + > > +/* GAMMAWD registers */ > > +#define CCDC_ALAW_GAMA_WD_MASK (0xf) > > +#define CCDC_ALAW_GAMA_WD_SHIFT(1) > > +#define CCDC
RE: [PATCH v2 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Hi Sylwester,
Thank you for your comments.
My responses inline.
Thanks and Regards,
-Manju
On Fri, Sep 02, 2011 at 02:17:49, Sylwester Nawrocki wrote:
> Hi Manjunath,
>
> A few comments below...
>
> On 08/29/2011 05:07 PM, Manjunath Hadli wrote:
> > add support for dm3xx IPIPEIF hardware setup. This is the lowest
> > software layer for the dm3x vpfe driver which directly accesses
> > hardware. Add support for features like default pixel correction, dark
> > frame substraction and hardware setup.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Nagabhushana Netagunte
> > ---
> > drivers/media/video/davinci/dm3xx_ipipeif.c | 317
> > +++
> > drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++
> > include/linux/dm3xx_ipipeif.h | 64 ++
> > 3 files changed, 639 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
> > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h
> > create mode 100644 include/linux/dm3xx_ipipeif.h
> >
> > diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
> > b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > new file mode 100644
> > index 000..ebc8895
> > --- /dev/null
> > +++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > @@ -0,0 +1,317 @@
> ...
> > +
> > +static void ipipeif_config_dpc(struct ipipeif_dpc *dpc) {
> > + u32 val;
> > +
> > + /* Intialize val*/
> > + val = 0;
>
> s/Intialize/Initialize ? But this comment doesn't seem much helpful and could
> probably be removed. Also it might be better to just do:
>
> u32 val = 0;
Done.
>
> > +
> > + if (dpc->en) {
> > + val = (dpc->en& 1)<< IPIPEIF_DPC2_EN_SHIFT;
> > + val |= dpc->thr& IPIPEIF_DPC2_THR_MASK;
> > + }
> > +
> > + regw_if(val, IPIPEIF_DPC2);
> > +}
> > +
> ...
> > +
> > +static int __devinit dm3xx_ipipeif_probe(struct platform_device
> > +*pdev) {
> > + static resource_size_t res_len;
> > + struct resource *res;
> > + int status;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res)
> > + return -ENOENT;
> > +
> > + res_len = res->end - res->start + 1;
>
> resource_size(res) macro could be used here
Done.
>
> > +
> > + res = request_mem_region(res->start, res_len, res->name);
> > + if (!res)
> > + return -EBUSY;
> > +
> > + ipipeif_base_addr = ioremap_nocache(res->start, res_len);
> > + if (!ipipeif_base_addr) {
> > + status = -EBUSY;
> > + goto fail;
> > + }
> > + return 0;
> > +
> > +fail:
> > + release_mem_region(res->start, res_len);
> > +
> > + return status;
> > +}
> > +
> > +static int dm3xx_ipipeif_remove(struct platform_device *pdev) {
> > + struct resource *res;
> > +
> > + iounmap(ipipeif_base_addr);
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (res)
> > + release_mem_region(res->start, res->end - res->start + 1);
>
> release_mem_region(res->start, resource_size(res));
Done.
>
> > + return 0;
> > +}
> > +
> > +static struct platform_driver dm3xx_ipipeif_driver = {
> > + .driver = {
> > + .name = "dm3xx_ipipeif",
> > + .owner = THIS_MODULE,
> > + },
> > + .remove = __devexit_p(dm3xx_ipipeif_remove),
> > + .probe = dm3xx_ipipeif_probe,
> > +};
> > +
> > +static int dm3xx_ipipeif_init(void)
> > +{
> > + return platform_driver_register(&dm3xx_ipipeif_driver);
> > +}
> > +
> > +static void dm3xx_ipipeif_exit(void)
> > +{
> > + platform_driver_unregister(&dm3xx_ipipeif_driver);
> > +}
> > +
> > +module_init(dm3xx_ipipeif_init);
> > +module_exit(dm3xx_ipipeif_exit);
> > +
> > +MODULE_LICENSE("GPL2");
> > diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.h
> > b/drivers/media/video/davinci/dm3xx_ipipeif.h
> > new file mode 100644
> > index 000..f3289f0
> > --- /dev/null
> > +++ b/drivers/media/video/davinci/dm3xx_ipipeif.h
> > @@ -0,0 +1,258 @@
> > +/*
> ...
> > +
> > +/* IPIPEIF Register Offsets from the base address */
> > +#define IPIPEIF_ENABLE (0x00)
> > +#define IPIPEIF_CFG1 (0x04)
> > +#define IPIPEIF_PPLN (0x08)
> > +#define IPIPEIF_LPFR (0x0c)
> > +#define IPIPEIF_HNUM (0x10)
> > +#define IPIPEIF_VNUM (0x14)
> > +#define IPIPEIF_ADDRU (0x18)
> > +#define IPIPEIF_ADDRL (0x1c)
> > +#define IPIPEIF_ADOFS (0x20)
> > +#define IPIPEIF_RSZ(0x24)
> > +#define IPIPEIF_GAIN (0x28)
> > +
> > +/* Below registers are available only on IPIPE 5.1 */
> > +#define IPIPEIF_DPCM (0x2c)
> > +#define IPIPEIF_CFG2 (0x30)
> > +#define IPIPEIF_INIRSZ (0x34)
> > +#define IPIPEIF_OCLIP (0x38)
> > +#define IPIPEIF_DTUD
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Please treat the patches as RFC. Thx, -manju On Mon, Aug 29, 2011 at 20:37:11, Hadli, Manjunath wrote: > changes from last patch set: > 1. Made changes based on Sakari's feedback mainly: > a. returned early to allow unindenting > b. reformatting to shift the code to left where possible > c. changed hex numbers to lower case > d. corrected the defines according to module names. > e. magic numbers removed. > f. changed non-integer returning functions to void > g. removed unwanted paranthses. > h. fixed error codes. > i. fixed some RESET_BIt code to what it was intended for. > 2. reorganized the header files to move the kernel-only headers along with > the c files and interface headers in the include folder. > > Manjunath Hadli (6): > davinci: vpfe: add dm3xx IPIPEIF hardware support module > davinci: vpfe: add support for CCDC hardware for dm365 > davinci: vpfe: add ccdc driver with media controller interface > davinci: vpfe: add v4l2 video driver support > davinci: vpfe: v4l2 capture driver with media interface > davinci: vpfe: build infrastructure for dm365 > > Nagabhushana Netagunte (2): > davinci: vpfe: add IPIPE hardware layer support > davinci: vpfe: add IPIPE support for media controller driver > > drivers/media/video/davinci/Kconfig | 46 +- > drivers/media/video/davinci/Makefile | 17 +- > drivers/media/video/davinci/ccdc_hw_device.h | 10 +- > drivers/media/video/davinci/ccdc_types.h | 43 + > drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ > drivers/media/video/davinci/dm365_ccdc.h | 88 + > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ > drivers/media/video/davinci/dm365_def_para.c | 486 +++ > drivers/media/video/davinci/dm365_def_para.h | 39 + > drivers/media/video/davinci/dm365_ipipe.c | 3966 > + > drivers/media/video/davinci/dm365_ipipe.h | 300 ++ > drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ > drivers/media/video/davinci/dm365_ipipe_hw.h | 539 > drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ > drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ > drivers/media/video/davinci/imp_common.h | 85 + > drivers/media/video/davinci/imp_hw_if.h | 178 ++ > drivers/media/video/davinci/vpfe_capture.c| 793 + > drivers/media/video/davinci/vpfe_capture.h| 104 + > drivers/media/video/davinci/vpfe_ccdc.c | 813 + > drivers/media/video/davinci/vpfe_ccdc.h | 85 + > drivers/media/video/davinci/vpfe_video.c | 1712 +++ > drivers/media/video/davinci/vpfe_video.h | 142 + > include/linux/davinci_vpfe.h | 1223 > include/linux/dm365_ccdc.h| 664 + > include/linux/dm3xx_ipipeif.h | 64 + > include/media/davinci/vpfe.h | 91 + > 27 files changed, 14829 insertions(+), 11 deletions(-) create mode 100644 > drivers/media/video/davinci/ccdc_types.h > create mode 100644 drivers/media/video/davinci/dm365_ccdc.c > create mode 100644 drivers/media/video/davinci/dm365_ccdc.h > create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h > create mode 100644 drivers/media/video/davinci/dm365_def_para.c > create mode 100644 drivers/media/video/davinci/dm365_def_para.h > create mode 100644 drivers/media/video/davinci/dm365_ipipe.c > create mode 100644 drivers/media/video/davinci/dm365_ipipe.h > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h > create mode 100644 drivers/media/video/davinci/imp_common.h > create mode 100644 drivers/media/video/davinci/imp_hw_if.h > create mode 100644 drivers/media/video/davinci/vpfe_capture.c > create mode 100644 drivers/media/video/davinci/vpfe_capture.h > create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c > create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h > create mode 100644 drivers/media/video/davinci/vpfe_video.c > create mode 100644 drivers/media/video/davinci/vpfe_video.h > create mode 100644 include/linux/davinci_vpfe.h create mode 100644 > include/linux/dm365_ccdc.h create mode 100644 include/linux/dm3xx_ipipeif.h > create mode 100644 include/media/davinci/vpfe.h > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Sakari,
I have sent a fresh patch-set with your comments fixed and and some
cleanup and reorg of my own- mainly the headers. Please review.
Also, I had to keep one of your comments without code change as I felt it was
Ok to keep it here as it is only a local variable which actually gets the info
from the device specific data structures. I removed the other however.
Looking forward for your comments on further patches as well.
-Manju
On Thu, Jul 14, 2011 at 00:20:50, Sakari Ailus wrote:
> Hi Manju,
>
> Thanks for the patchset!
>
> I have a few comments on this patch below. I haven't read the rest of the
> patches yet so I may have more comments on this one when I do that.
>
> On Thu, Jun 30, 2011 at 06:43:10PM +0530, Manjunath Hadli wrote:
> > add support for dm3xx IPIPEIF hardware setup. This is the lowest
> > software layer for the dm3x vpfe driver which directly accesses
> > hardware. Add support for features like default pixel correction, dark
> > frame substraction and hardware setup.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Nagabhushana Netagunte
> > ---
> > drivers/media/video/davinci/dm3xx_ipipeif.c | 368
> > +++
> > include/media/davinci/dm3xx_ipipeif.h | 292 +
> > 2 files changed, 660 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
> > create mode 100644 include/media/davinci/dm3xx_ipipeif.h
> >
> > diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
> > b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > new file mode 100644
> > index 000..36cb61b
> > --- /dev/null
> > +++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > @@ -0,0 +1,368 @@
---code
> > +#include #include #include
> > + #include #include
> > + #include
> > +
> > +#define DM355 0
> > +#define DM365 1
> > +
> > +static void *__iomem ipipeif_base_addr;
>
> This looks device specific. What about using dev_set/get_drvdata and remove
> this one?
This one is actually gotten from the platform data structure in the manner you
suggested but stored here for local usage.
>
> > +static int device_type;
>
> Ditto. Both should be in a device specific struct.
This one I have removed.
>
> > +static inline u32 regr_if(u32 offset) {
> > + return readl(ipipeif_base_addr + offset); }
> > +
> > +static inline void regw_if(u32 val, u32 offset) {
> > + writel(val, ipipeif_base_addr + offset); }
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Sakari,
Thank you for your comments. I agree with them and fix. Please comment on the
rest of the patches as well.
-Manju
On Thu, Jul 14, 2011 at 00:20:50, Sakari Ailus wrote:
> Hi Manju,
>
> Thanks for the patchset!
>
> I have a few comments on this patch below. I haven't read the rest of the
> patches yet so I may have more comments on this one when I do that.
>
> On Thu, Jun 30, 2011 at 06:43:10PM +0530, Manjunath Hadli wrote:
> > add support for dm3xx IPIPEIF hardware setup. This is the lowest
> > software layer for the dm3x vpfe driver which directly accesses
> > hardware. Add support for features like default pixel correction, dark
> > frame substraction and hardware setup.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Nagabhushana Netagunte
> > ---
> > drivers/media/video/davinci/dm3xx_ipipeif.c | 368
> > +++
> > include/media/davinci/dm3xx_ipipeif.h | 292 +
> > 2 files changed, 660 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
> > create mode 100644 include/media/davinci/dm3xx_ipipeif.h
> >
> > diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
> > b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > new file mode 100644
> > index 000..36cb61b
> > --- /dev/null
> > +++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > @@ -0,0 +1,368 @@
> > +/*
> > +* Copyright (C) 2011 Texas Instruments Inc
> > +*
> > +* This program is free software; you can redistribute it and/or
> > +* modify it under the terms of the GNU General Public License as
> > +* published by the Free Software Foundation version 2.
> > +*
> > +* 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
> > +*
> > +* ipipe module to hold common functionality across DM355 and DM365 */
> > +#include #include #include
> > + #include #include
> > + #include
> > +
> > +#define DM355 0
> > +#define DM365 1
> > +
> > +static void *__iomem ipipeif_base_addr;
>
> This looks device specific. What about using dev_set/get_drvdata and remove
> this one?
>
> > +static int device_type;
>
> Ditto. Both should be in a device specific struct.
I will move both of the above to platform file.
>
> > +static inline u32 regr_if(u32 offset) {
> > + return readl(ipipeif_base_addr + offset); }
> > +
> > +static inline void regw_if(u32 val, u32 offset) {
> > + writel(val, ipipeif_base_addr + offset); }
> > +
> > +void ipipeif_set_enable(char en, unsigned int mode) {
> > + regw_if(1, IPIPEIF_ENABLE);
> > +}
> > +
> > +u32 ipipeif_get_enable(void)
> > +{
> > + return regr_if(IPIPEIF_ENABLE);
> > +}
> > +
> > +int ipipeif_set_address(struct ipipeif *params, unsigned int address)
> > +{
>
> If address is a value for a register you should use u32.
Okay.
>
> > + unsigned int val1;
> > + unsigned int val;
> > +
> > + if (params->source != 0) {
> > + val = ((params->adofs >> 5) & IPIPEIF_ADOFS_LSB_MASK);
> > + regw_if(val, IPIPEIF_ADOFS);
>
> You may do without val as well.
>
> > + /* lower sixteen bit */
> > + val = ((address >> IPIPEIF_ADDRL_SHIFT) & IPIPEIF_ADDRL_MASK);
> > + regw_if(val, IPIPEIF_ADDRL);
> > +
> > + /* upper next seven bit */
> > + val1 =
> > + ((address >> IPIPEIF_ADDRU_SHIFT) & IPIPEIF_ADDRU_MASK);
> > + regw_if(val1, IPIPEIF_ADDRU);
> > + } else
> > + return -1;
>
> What's -1? If this is an error, Ex codes should be used.
>
> The error check should become first and the rest of the function may be
> unindented by one tab stop.
Okay.
>
> > + return 0;
> > +}
> > +
> > +static void ipipeif_config_dpc(struct ipipeif_dpc *dpc) {
> > + u32 val;
> > +
> > + if (dpc->en) {
> > + val = ((dpc->en & 1) << IPIPEIF_DPC2_EN_SHIFT);
> > + val |= (dpc->thr & IPIPEIF_DPC2_THR_MASK);
> > + } else
> > + val = 0;
> > +
> > + regw_if(val, IPIPEIF_DPC2);
> > +}
> > +
> > +/* This function sets up IPIPEIF and is called from
> > + * ipipe_hw_setup()
> > + */
> > +int ipipeif_hw_setup(struct ipipeif *params) {
> > + enum v4l2_mbus_pixelcode isif_port_if;
> > + unsigned int val1 = 0x7;
>
> 7 looks like a magic number.
Will fix.
>
> > + unsigned int val;
> > +
> > + if (NULL == params)
> > + return -1;
>
> Same here, and I can also see elsewhere.
Will fix.
>
> > + /* Enable clock to IPIPEIF and IPIPE */
> > + if (device_type == DM365)
> > + vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
> > +
> > + /* Combine all the f
RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Sakari/Laurent, Did you get some time to review the code? Will look forward for your comments. -Manju On Wed, Jul 06, 2011 at 11:10:38, Hadli, Manjunath wrote: > > Hi Sakari, > > On Mon, Jul 04, 2011 at 21:43:09, Sakari Ailus wrote: > > Hadli, Manjunath wrote: > > > Thank you Laurent. > > > > Hi Manjunath, > > > > > On Mon, Jul 04, 2011 at 18:52:37, Laurent Pinchart wrote: > > >> Hi Manjunath, > > >> > > >> On Monday 04 July 2011 07:58:06 Hadli, Manjunath wrote: > > >>> On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote: > > >> > > >> [snip] > > >> > > >>>> I understand that not all the blocks are there. Are there any > > >>>> major functional differences between those in Davinci and those > > >>>> in OMAP 3? Could the OMAP 3 ISP driver made support Davinci ISP as > > >>>> well? > > >>> > > >>> Yes, there are a lot of major differences between OMAP3 and > > >>> Dm365/Dm355, both in terms of features, there IP, and the software > > >>> interface, including all the registers which are entirely different. > > >>> The closest omap3 would come to is only to DM6446. I do not think > > >>> OMAP3 driver can be made to support Dm355 and Dm365. It is good to > > >>> keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and > > >>> keep the Davinci family separate. The names might look similar and > > >>> hence confusing for you, but the names can as well be made the > > >>> same as Dm365 blocks like ISIF and IPIPE and IPIPEIF which are > > >>> different. > > >> > > >> The DM6446 ISP is very similar to the OMAP3 ISP, and thus quite > > >> different from the DM355/365 ISPs. Should the DM6446 be supported > > >> by the OMAP3 ISP driver, and the DM355/365 by this driver ? > > > > > > DM6446 capture IP is in some respects similar to OMAP3 for some > > > features, but there are a large number of differences also (MMU, > > > VRFB, a lot of display interfaces etc). Having a single driver > > > catering to Since DM6446 and OMAP3 is going to be unwieldy. Also, > > > DM6446 belongs to the Davinci family of chips, it should be clubbed > > > with the other Davinci SoCs as it will simplify a lot of other > > > things including directory subdirectory/file naming, organization of > > > machine/platform code etc among other things. Other than Video a lot > > > of other system registers and features which are common with the > > > rest of Davinci SoCs which if treated together is a good thing, > > > whereas > > > OMAP3 can be modified and developed with those on the OMAP family > > > (OMAP4 for ex). > > > > Thanks for the clarifications. > > > > What about the DM3730? As far as I understand, the ISP on that one is > > supported by the OMAP 3 ISP driver. But it looks like that it's more > > continuation for the OMAP family of the chips than the Davinci. > Let me say that for all practical purposes, for developers, DM3730 is OMAP3. > So a distinction between OMAP3 and DM3730 need not be made at all. As to why > it is a Davinci device, has more to do with things outside the realm of > development. So Dm3730 for us, including you and me, can be OMAP3, As the TRM > says - " It is OMAP3 compatible". > > > > > I glanced at the DM6446 documentation and at the register level the > > interface looks somewhat different although some register names are the > > same. I didn't found a proper TRM which would be as detailed as the OMAP > > ones --- does TI have one available in public? > TRMs for Davinci devices are slightly in a different format - split into > multiple documents for each peripheral and system functionalities unlike a > big singe doc for OMAP. > But all the required documents are in public domain and can be found at : > http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html under the user > guides category. If you are looking for some particular information, let me > know and I can help you locate it. > > > > > > > OMAP 4 has a quite different ISS --- which the ISP is a part of, and which > > also is very different to the OMAP 3 one --- so it's unlikely that the > > same driver would support OMAP 3 and OMAP 4 ISPs. > > > > Kind regards, > > > > -- > > Sakari Ailus > > sakari.ai...@iki.fi > > > > Regards, > -Manjunath > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Hi Sakari, On Mon, Jul 04, 2011 at 21:43:09, Sakari Ailus wrote: > Hadli, Manjunath wrote: > > Thank you Laurent. > > Hi Manjunath, > > > On Mon, Jul 04, 2011 at 18:52:37, Laurent Pinchart wrote: > >> Hi Manjunath, > >> > >> On Monday 04 July 2011 07:58:06 Hadli, Manjunath wrote: > >>> On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote: > >> > >> [snip] > >> > >>>> I understand that not all the blocks are there. Are there any major > >>>> functional differences between those in Davinci and those in OMAP > >>>> 3? Could the OMAP 3 ISP driver made support Davinci ISP as well? > >>> > >>> Yes, there are a lot of major differences between OMAP3 and > >>> Dm365/Dm355, both in terms of features, there IP, and the software > >>> interface, including all the registers which are entirely different. > >>> The closest omap3 would come to is only to DM6446. I do not think > >>> OMAP3 driver can be made to support Dm355 and Dm365. It is good to > >>> keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and > >>> keep the Davinci family separate. The names might look similar and > >>> hence confusing for you, but the names can as well be made the same > >>> as Dm365 blocks like ISIF and IPIPE and IPIPEIF which are different. > >> > >> The DM6446 ISP is very similar to the OMAP3 ISP, and thus quite > >> different from the DM355/365 ISPs. Should the DM6446 be supported by > >> the OMAP3 ISP driver, and the DM355/365 by this driver ? > > > > DM6446 capture IP is in some respects similar to OMAP3 for some > > features, but there are a large number of differences also (MMU, VRFB, > > a lot of display interfaces etc). Having a single driver catering to > > Since DM6446 and OMAP3 is going to be unwieldy. Also, > > DM6446 belongs to the Davinci family of chips, it should be clubbed > > with the other Davinci SoCs as it will simplify a lot of other things > > including directory subdirectory/file naming, organization of > > machine/platform code etc among other things. Other than Video a lot > > of other system registers and features which are common with the rest > > of Davinci SoCs which if treated together is a good thing, whereas > > OMAP3 can be modified and developed with those on the OMAP family > > (OMAP4 for ex). > > Thanks for the clarifications. > > What about the DM3730? As far as I understand, the ISP on that one is > supported by the OMAP 3 ISP driver. But it looks like that it's more > continuation for the OMAP family of the chips than the Davinci. Let me say that for all practical purposes, for developers, DM3730 is OMAP3. So a distinction between OMAP3 and DM3730 need not be made at all. As to why it is a Davinci device, has more to do with things outside the realm of development. So Dm3730 for us, including you and me, can be OMAP3, As the TRM says - " It is OMAP3 compatible". > > I glanced at the DM6446 documentation and at the register level the interface > looks somewhat different although some register names are the same. I didn't > found a proper TRM which would be as detailed as the OMAP ones --- does TI > have one available in public? TRMs for Davinci devices are slightly in a different format - split into multiple documents for each peripheral and system functionalities unlike a big singe doc for OMAP. But all the required documents are in public domain and can be found at : http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html under the user guides category. If you are looking for some particular information, let me know and I can help you locate it. > > OMAP 4 has a quite different ISS --- which the ISP is a part of, and which > also is very different to the OMAP 3 one --- so it's unlikely that the same > driver would support OMAP 3 and OMAP 4 ISPs. > > Kind regards, > > -- > Sakari Ailus > sakari.ai...@iki.fi > Regards, -Manjunath -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Thank you Laurent. On Mon, Jul 04, 2011 at 18:52:37, Laurent Pinchart wrote: > Hi Manjunath, > > On Monday 04 July 2011 07:58:06 Hadli, Manjunath wrote: > > On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote: > > [snip] > > > > I understand that not all the blocks are there. Are there any major > > > functional differences between those in Davinci and those in OMAP 3? > > > Could the OMAP 3 ISP driver made support Davinci ISP as well? > > > > Yes, there are a lot of major differences between OMAP3 and > > Dm365/Dm355, both in terms of features, there IP, and the software > > interface, including all the registers which are entirely different. > > The closest omap3 would come to is only to DM6446. I do not think > > OMAP3 driver can be made to support Dm355 and Dm365. It is good to > > keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and keep > > the Davinci family separate. The names might look similar and hence > > confusing for you, but the names can as well be made the same as Dm365 > > blocks like ISIF and IPIPE and IPIPEIF which are different. > > The DM6446 ISP is very similar to the OMAP3 ISP, and thus quite different > from the DM355/365 ISPs. Should the DM6446 be supported by the OMAP3 ISP > driver, and the DM355/365 by this driver ? DM6446 capture IP is in some respects similar to OMAP3 for some features, but there are a large number of differences also (MMU, VRFB, a lot of display interfaces etc). Having a single driver catering to Since DM6446 and OMAP3 is going to be unwieldy. Also, DM6446 belongs to the Davinci family of chips, it should be clubbed with the other Davinci SoCs as it will simplify a lot of other things including directory subdirectory/file naming, organization of machine/platform code etc among other things. Other than Video a lot of other system registers and features which are common with the rest of Davinci SoCs which if treated together is a good thing, whereas OMAP3 can be modified and developed with those on the OMAP family (OMAP4 for ex). > > > > There are number of possible improvements that still should be made > > > to the OMAP 3 ISP driver so this way both of the driver would easily > > > get them. To mention some: > > > > > > - Multiple output pipeline > > > - Switch to videobuf2 > > > - Switch to GENIRQ > > > > Sure. There is definitely a design element convergence, and overtime I > > think some of these would get into the core v4l2 infrastructure. > > -- > 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
RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Sakari, Thank you for the comments. My responses inlined. -Manjunath On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote: > Hi Manjunath, > > Thanks for the patches. > > On Thu, Jun 30, 2011 at 06:43:09PM +0530, Manjunath Hadli wrote: > > Thease are the RFC patches for the DM365 video capture, of which the > > current set includes only CCDC and the VPFE framework. Once the > > present set is reviewed, I will send out the other parts like H3A, > > sensor additions etc. > > > > Introduction > > > > This is the proposal of the initial version of design and > > implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video > > Port Front End) drivers using Media Controloler , the initial version > > which supports the following: > > 1) dm365 vpfe > > 2) ccdc,previewer,resizer,h3a,af blocks > > 3) supports both continuous and single-shot modes > > 4) supports user pointer exchange and memory mapped modes for buffer > > allocation > > > > This driver bases its design on Laurent Pinchart's Media Controller > > Design whose patches for Media Controller and subdev enhancements form the > > base. > > The driver also takes copious elements taken from Laurent Pinchart and > > others' OMAP ISP driver based on Media Controller. So thank you all > > the people who are responsible for the Media Controller and the OMAP ISP > > driver. > > This may be a stupid question, but how much changes are there between this > driver and the OMAP 3 ISP driver? The elements which pertain to how to write to media controller driver for a capture device have been imbibed from the OMAP3 but as such the code is very different. For example the v4l2 video routines as an almost separate library is a good element we took as a design, but the rest of it is entirely different. > > I understand that not all the blocks are there. Are there any major > functional differences between those in Davinci and those in OMAP 3? Could > the OMAP 3 ISP driver made support Davinci ISP as well? Yes, there are a lot of major differences between OMAP3 and Dm365/Dm355, both in terms of features, there IP, and the software interface, including all the registers which are entirely different. The closest omap3 would come to is only to DM6446. I do not think OMAP3 driver can be made to support Dm355 and Dm365. It is good to keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and keep the Davinci family separate. The names might look similar and hence confusing for you, but the names can as well be made the same as Dm365 blocks like ISIF and IPIPE and IPIPEIF which are different. > > There are number of possible improvements that still should be made to the > OMAP 3 ISP driver so this way both of the driver would easily get them. To > mention some: > > - Multiple output pipeline > - Switch to videobuf2 > - Switch to GENIRQ Sure. There is definitely a design element convergence, and overtime I think some of these would get into the core v4l2 infrastructure. > > Cc Laurent. > > Regards, > > -- > Sakari Ailus > sakari.ai...@iki.fi > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Media Controller Capture driver for DM365
Laurent, Sorry for getting back late on this. I was also tied up. I am following it up with the patches. -Manju On Mon, May 02, 2011 at 03:36:23, Laurent Pinchart wrote: > Hi Manjunath, > > On Wednesday 27 April 2011 16:14:03 Hadli, Manjunath wrote: > > Introduction > > > > This is the proposal of the initial version of design and > > implementation of the DM365 VPFE (Video Port Front End) drivers using > > Media Controloler , the initial version which supports the following: > > 1) dm365 vpfe > > 2) ccdc,previewer,resizer,h3a,af blocks > > 3) supports both continuous and single-shot modes > > 4) supports user pointer exchange and memory mapped modes for buffer > > allocation > > > > This driver bases its design on Laurent Pinchart's Media Controller > > Design whose patches for Media Controller and subdev enhancements form the > > base. > > The driver also takes copious elements taken from Laurent Pinchart and > > others' OMAP ISP driver based on Media Controller. So thank you all > > the people who are responsible for the Media Controller and the OMAP > > ISP driver. > > You're welcome. > > > Also, the core functionality of the driver comes from the arago vpfe > > capture driver of which the CCDC capture was based on V4L2, with other > > drivers like Previwer, and Resizer. > > > > The specification for DM365 can be found here: > > dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c > > > > The initial version of the driver implementation can be found here: > > > > http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h > > =refs > > /heads/mc_release > > I'll try to review the code, but I got the DM644x V4L2 display driver on my > todo-list first :-) > > > Driver Design: Main entities > > > > The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. > > These hardware modules are generically exposed to the user level in > > the for of > > dm6446 style modules. Mainly - > > ccdc, previewer, resizer in addition to the other histogram and auto > > color/white balance correction and auto focus modules. > > I'm curious, why do you name the modules CCDC and previewer in the code, when > they're called ISIF, IPIPEIF and IPIPE in the documentation ? That's quite > confusing. The driver is intended to support Dm365, Dm355 and Dm6446. The three are similar and there are some internal differences. The counterparts for IPIPE in Dm6446 are known by names as CCDC , previewer etc and a good part of the world knows the driver by that name. So rather than changing the names, we decided to keep them as-is. > > > 1)MT9P031 sensor module for RAW capture > > 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD > > inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV > > conversion 6)Resizer Module for scaling > > > > Connection for on-the-fly capture > > - > > Mt9P031 > > -->CCDC--->Previewer(optional)--->Resizer(optional)--->Video > > > > TVP7002 --- > > > > TV514x --- > > > > File Organisation > > - > > > > main driver files > > > > drivers/media/video/davinci/vpfe_capture.c > > include/media/davinci/vpfe_capture.h > > > > Instantiatiation of the v4l2 device, media device and all subdevs > > from here. > > > > video Interface files > > - > > drivers/media/video/davinci/vpfe_video.c > > include/media/davinci/vpfe_video.h > > > > Implements all the v4l2 video operations with a generic implementation > > for continuous and one shot mode. > > > > subdev interface files > > -- > > These file implement the subdev interface functionality for each of > > the subdev entities - mainly the entry points and their > > implementations in a IP generic way. > > > > drivers/media/video/davinci/vpfe_ccdc.c > > drivers/media/video/davinci/vpfe_previewer.c > > drivers/media/video/davinci/vpfe_resizer.c > > drivers/media/video/davinci/vpfe_af.c > > drivers/media/video/davinci/vpfe_aew.c > > drivers/media/video/mt9p031.c > > drivers/media/video/tvp514x.c > > drivers/media/video/tvp7002.c > > drivers/media/video/ths7353.c > > > > include/media/davinci/vpfe_ccdc.h > > include/media/davinci/vpfe_previewer.h > > include/media/davinci/vpfe_resizer.h > > includ
RE: [RESEND PATCH v19 0/6] davinci vpbe: dm6446 v4l2 driver
Thanks Mauro. I will make sure I send you a pull request from a git tree. -Manju On Wed, Jun 22, 2011 at 00:54:01, Mauro Carvalho Chehab wrote: > Em 17-06-2011 04:03, Hadli, Manjunath escreveu: > > Mauro, > > > > Can you consider this patch series for a pull? > > Next time, could you please add on your tree and send me a git pull request? > > Patchwork is currently not reliable. I have a backup process, but a git pull > request works better and I won't have the risk of applying the wrong patches > or at a wrong order. > > In this specific case, as all patches were caught by patchwork, I'll apply > from your emails after reviewing them. > > Thanks, > Mauro > > > > > -Manju > > > > On Fri, Jun 17, 2011 at 12:31:30, Hadli, Manjunath wrote: > >> fixed a wrong file inclusion in one of the patches > >> > >> Manjunath Hadli (6): > >> davinci vpbe: V4L2 display driver for DM644X SoC > >> davinci vpbe: VPBE display driver > >> davinci vpbe: OSD(On Screen Display) block > >> davinci vpbe: VENC( Video Encoder) implementation > >> davinci vpbe: Build infrastructure for VPBE driver > >> davinci vpbe: Readme text for Dm6446 vpbe > >> > >> Documentation/video4linux/README.davinci-vpbe | 93 ++ > >> drivers/media/video/davinci/Kconfig | 23 + > >> drivers/media/video/davinci/Makefile |2 + > >> drivers/media/video/davinci/vpbe.c| 864 > >> drivers/media/video/davinci/vpbe_display.c| 1860 > >> + > >> drivers/media/video/davinci/vpbe_osd.c| 1231 > >> drivers/media/video/davinci/vpbe_osd_regs.h | 364 + > >> drivers/media/video/davinci/vpbe_venc.c | 566 > >> drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ > >> include/media/davinci/vpbe.h | 184 +++ > >> include/media/davinci/vpbe_display.h | 147 ++ > >> include/media/davinci/vpbe_osd.h | 394 ++ > >> include/media/davinci/vpbe_types.h| 91 ++ > >> include/media/davinci/vpbe_venc.h | 45 + > >> 14 files changed, 6041 insertions(+), 0 deletions(-) create mode > >> 100644 Documentation/video4linux/README.davinci-vpbe > >> create mode 100644 drivers/media/video/davinci/vpbe.c > >> create mode 100644 drivers/media/video/davinci/vpbe_display.c > >> create mode 100644 drivers/media/video/davinci/vpbe_osd.c > >> create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > >> create mode 100644 drivers/media/video/davinci/vpbe_venc.c > >> create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > >> create mode 100644 include/media/davinci/vpbe.h create mode 100644 > >> include/media/davinci/vpbe_display.h > >> create mode 100644 include/media/davinci/vpbe_osd.h create mode > >> 100644 include/media/davinci/vpbe_types.h > >> create mode 100644 include/media/davinci/vpbe_venc.h > >> > >> > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" > > in the body of a message to majord...@vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RESEND PATCH v19 0/6] davinci vpbe: dm6446 v4l2 driver
Mauro, Can you consider this patch series for a pull? -Manju On Fri, Jun 17, 2011 at 12:31:30, Hadli, Manjunath wrote: > fixed a wrong file inclusion in one of the patches > > Manjunath Hadli (6): > davinci vpbe: V4L2 display driver for DM644X SoC > davinci vpbe: VPBE display driver > davinci vpbe: OSD(On Screen Display) block > davinci vpbe: VENC( Video Encoder) implementation > davinci vpbe: Build infrastructure for VPBE driver > davinci vpbe: Readme text for Dm6446 vpbe > > Documentation/video4linux/README.davinci-vpbe | 93 ++ > drivers/media/video/davinci/Kconfig | 23 + > drivers/media/video/davinci/Makefile |2 + > drivers/media/video/davinci/vpbe.c| 864 > drivers/media/video/davinci/vpbe_display.c| 1860 > + > drivers/media/video/davinci/vpbe_osd.c| 1231 > drivers/media/video/davinci/vpbe_osd_regs.h | 364 + > drivers/media/video/davinci/vpbe_venc.c | 566 > drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ > include/media/davinci/vpbe.h | 184 +++ > include/media/davinci/vpbe_display.h | 147 ++ > include/media/davinci/vpbe_osd.h | 394 ++ > include/media/davinci/vpbe_types.h| 91 ++ > include/media/davinci/vpbe_venc.h | 45 + > 14 files changed, 6041 insertions(+), 0 deletions(-) create mode 100644 > Documentation/video4linux/README.davinci-vpbe > create mode 100644 drivers/media/video/davinci/vpbe.c > create mode 100644 drivers/media/video/davinci/vpbe_display.c > create mode 100644 drivers/media/video/davinci/vpbe_osd.c > create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > create mode 100644 drivers/media/video/davinci/vpbe_venc.c > create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > create mode 100644 include/media/davinci/vpbe.h create mode 100644 > include/media/davinci/vpbe_display.h > create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 > include/media/davinci/vpbe_types.h > create mode 100644 include/media/davinci/vpbe_venc.h > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v17 5/6] davinci vpbe: Build infrastructure for VPBE driver
On Mon, May 23, 2011 at 13:58:26, Nori, Sekhar wrote: > On Fri, May 20, 2011 at 20:02:08, Sergei Shtylyov wrote: > > Hello. > > > > Manjunath Hadli wrote: > > > > > This patch adds the build infra-structure for Davinci VPBE dislay > > > driver. > > > > > Signed-off-by: Manjunath Hadli > > > Acked-by: Muralidharan Karicheri > > > Acked-by: Hans Verkuil > > [...] > > > > > diff --git a/drivers/media/video/davinci/Kconfig > > > b/drivers/media/video/davinci/Kconfig > > > index 6b19540..a7f11e7 100644 > > > --- a/drivers/media/video/davinci/Kconfig > > > +++ b/drivers/media/video/davinci/Kconfig > > > @@ -91,3 +91,25 @@ config VIDEO_ISIF > > > > > > To compile this driver as a module, choose M here: the > > > module will be called vpfe. > > > + > > > +config VIDEO_DM644X_VPBE > > > + tristate "DM644X VPBE HW module" > > > > BTW, as this seems DM644x specific, shouldn't this depend on > > CONFIG_ARCH_DAVINCI_DM644x? > > Since VENC/OSD etc are also applicable to other DaVinci devices, this KConfig > entry should probably be split to refer to them individually and in a generic > way. "depends on" can then be used to make sure only the relevant ones show > up. Both venc and osd have to be used together always, so might not make a good idea to split. However, I will add a dependency on DM644x, and include others with appropriate patch sets. > > Thanks, > Sekhar > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Laurent,
Thank you for your comments. I have addressed all your suggestions.
Please find my comments inline.
Also,
Would you please review the patch again?
The branch is at:
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs/heads/forkhilman2
and the patch that you last reviewed was:
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=commit;h=690187eb05de65f1e63fc631ad4dc31358d01e55
Thanks,
-Manju
On Mon, May 02, 2011 at 15:28:23, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Tuesday 26 April 2011 16:47:45 Hadli, Manjunath wrote:
> > Laurent,
> > Can you please review the patches with your suggestions from :
> > http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h
> > =refs
> > /heads/forkhilman2 and let me know if you think all your suggestions
> > are taken care of?
> >
> > The patch you reviewed was :
> >
> > http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=commitdiff
> > ;h=69
> > f60ed7577ab9184ceabd7efbe5bb3453bf7ef1;hp=a400604f47c339831880c50eda6f
> > 6b032
> > 21579e3
>
> I've reviewed the same patch, here are my comments.
>
> > +/*
> > + * vpbe_display_isr()
> > + * ISR function. It changes status of the displayed buffer, takes
> > +next
> buffer
> > + * from the queue and sets its address in VPBE registers */ static
> > +void vpbe_display_isr(unsigned int event, struct vpbe_display
> *disp_obj)
> > +{
> > + struct osd_state *osd_device = disp_obj->osd_device;
> > + struct timespec timevalue;
> > + struct vpbe_layer *layer;
> > + unsigned long addr;
> > + int fid;
> > + int i;
> > +
> > + ktime_get_ts(&timevalue);
> > +
> > + for (i = 0; i < VPBE_DISPLAY_MAX_DEVICES; i++) {
> > + layer = disp_obj->dev[i];
> > + /* If streaming is started in this layer */
> > + if (!layer->started)
> > + continue;
>
> What about moving everything above to venc_isr(), and having this function
> handle a single layer only ? It will lower the max indentation level. I also
> wonder whether you couldn't share some code between the non-interlaced and
> the interlaced cases by reorganizing the function body (the fid == 1 code
> looks quite similar to the non-interlaced code).
To make it very clean I have broken the isr in a different way and tried to
neatly arrange it. It has now been made qute small and re-usable.Hope you like
it.
>
> [snip]
>
> > +/**
> > + * vpbe_try_format()
> > + * If user application provides width and height, and have
> > +bytesperline set
> > + * to zero, driver calculates bytesperline and sizeimage based on
> > +hardware
> > + * limits. If application likes to add pads at the end of each line
> > +and
> > + * end of the buffer , it can set bytesperline to line size and
> > +sizeimage
> to
> > + * bytesperline * height of the buffer. If driver fills zero for
> > + active
> > + * video width and height, and has requested user bytesperline and
> sizeimage,
> > + * width and height is adjusted to maximum display limit or buffer
> > + width
> > + * height which ever is lower
>
> This still sounds a bit cryptic to me.
>
> vpbe_try_format() should return a format closest to what the user requested:
>
> - If the pixel format is invalid, select a default value (done)
> - If the field is invalid or not specified, select a default value (partly
> done, you don't check for default values)
> - If width and/or height are invalid (including being set to 0), select
> default values (partly done, you compute width/height based on bytesperline
> and sizeimage when they're set to 0, and I don't understand why)
> - If bytesperline is invalid (smaller than the minimum value according to the
> selected width, or larger than the maximum allowable value), fix it
> - If sizeimage is invalid (smaller than the minimum value according the the
> selected height and bytesperline), fix it
>
> Is there a need to allow sizeimage values different than height *
> bytesperline ?
Cleaned and taken care of.
>
> > + */
>
> [snip]
>
> > +static int vpbe_display_querycap(struct file *file, void *priv,
> > + struct v4l2_capability *cap) {
> > + struct vpbe_fh *fh = file->private_data;
> > + struct vpbe_device *vpbe_dev = fh->disp_dev->vpbe_dev;
> > +
> > + cap->version = VPBE_DISPLAY_VERSION_CODE;
> > + cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
> > + strlcpy(cap->driver,
[RFC] Media Controller Capture driver for DM365
Introduction This is the proposal of the initial version of design and implementation of the DM365 VPFE (Video Port Front End) drivers using Media Controloler , the initial version which supports the following: 1) dm365 vpfe 2) ccdc,previewer,resizer,h3a,af blocks 3) supports both continuous and single-shot modes 4) supports user pointer exchange and memory mapped modes for buffer allocation This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the CCDC capture was based on V4L2, with other drivers like Previwer, and Resizer. The specification for DM365 can be found here: dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c The initial version of the driver implementation can be found here: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs/heads/mc_release Driver Design: Main entities The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. These hardware modules are generically exposed to the user level in the for of dm6446 style modules. Mainly - ccdc, previewer, resizer in addition to the other histogram and auto color/white balance correction and auto focus modules. 1)MT9P031 sensor module for RAW capture 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV conversion 6)Resizer Module for scaling Connection for on-the-fly capture - Mt9P031 -->CCDC--->Previewer(optional)--->Resizer(optional)--->Video | TVP7002 --- | TV514x --- File Organisation - main driver files drivers/media/video/davinci/vpfe_capture.c include/media/davinci/vpfe_capture.h Instantiatiation of the v4l2 device, media device and all subdevs from here. video Interface files - drivers/media/video/davinci/vpfe_video.c include/media/davinci/vpfe_video.h Implements all the v4l2 video operations with a generic implementation for continuous and one shot mode. subdev interface files -- These file implement the subdev interface functionality for each of the subdev entities - mainly the entry points and their implementations in a IP generic way. drivers/media/video/davinci/vpfe_ccdc.c drivers/media/video/davinci/vpfe_previewer.c drivers/media/video/davinci/vpfe_resizer.c drivers/media/video/davinci/vpfe_af.c drivers/media/video/davinci/vpfe_aew.c drivers/media/video/mt9p031.c drivers/media/video/tvp514x.c drivers/media/video/tvp7002.c drivers/media/video/ths7353.c include/media/davinci/vpfe_ccdc.h include/media/davinci/vpfe_previewer.h include/media/davinci/vpfe_resizer.h include/media/davinci/vpfe_af.h include/media/davinci/vpfe_aew.h include/media/tvp514x.h drivers/media/video/tvp514x_regs.h include/media/tvp7002.h drivers/media/video/tvp7002_reg.h core implementation files - These provide a core implementation routines for ccdc, ipipeif, ipipe,aew, af, resizer hardware modules. drivers/media/video/davinci/dm365_ccdc.c drivers/media/video/davinci/dm365_ipipe.c drivers/media/video/davinci/dm365_def_para.c drivers/media/video/davinci/dm365_ipipe_hw.c drivers/media/video/davinci/dm3xx_ipipe.c drivers/media/video/davinci/dm365_aew.c drivers/media/video/davinci/dm365_af.c drivers/media/video/davinci/dm365_a3_hw.c include/media/davinci/imp_common.h include/media/davinci/dm365_ccdc.h include/media/davinci/dm365_ipipe.h include/media/davinci/imp_hw_if.h include/media/davinci/dm3xx_ipipe.h include/media/davinci/dm365_aew.h include/media/davinci/dm365_af.h include/media/davinci/dm365_a3_hw.h include/media/davinci/vpfe_types.h drivers/media/video/davinci/dm365_ccdc_regs.h drivers/media/video/davinci/ccdc_hw_device.h drivers/media/video/davinci/dm365_def_para.h drivers/media/video/davinci/dm365_ipipe_hw.h TODOs: == 1. Support NV12/YUYV format 2. Support more than 1 buffer for single-shot mode 3. Enable Resizer-B 4. Remove duplicate format setting in ipipe 5. Remove function declarations in dm365_ipipe.c by removing function pointer table 6. Remove function declarations in dm365_ccdc.c by removing function pointer table 7. Make multilevel previewer module ioctl into single level 8. Move kernel only headers into drivers/media/video/davinci from include/media/davinci-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Laurent,
Can you please review the patches with your suggestions from :
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs/heads/forkhilman2
and let me know if you think all your suggestions are taken care of?
The patch you reviewed was :
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=commitdiff;h=69f60ed7577ab9184ceabd7efbe5bb3453bf7ef1;hp=a400604f47c339831880c50eda6f6b03221579e3
-Manju
-Original Message-
From: Hadli, Manjunath
Sent: Monday, April 25, 2011 2:20 PM
To: 'Laurent Pinchart'
Cc: davinci-linux-open-sou...@linux.davincidsp.com; LMML; Kevin Hilman; LAK;
Nori, Sekhar
Subject: RE: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Laurent,
Thank you for your comments.
Please find my updates below.
The updated patches will follow today.
-Manju
On Thu, Apr 21, 2011 at 15:48:05, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Wednesday 20 April 2011 17:30:08 Hadli, Manjunath wrote:
> > Hi Laurent,
> > Thank you for you very valuable and detailed comments. I have fixed a
> > lot of your suggestions and there are a few questions I need more
> > explanation for. I will send the fixed and updated patches as a
> > follow-up after your clarifications.
>
> OK. Please see below for answsers.
>
> > On Thu, Apr 07, 2011 at 17:28:20, Laurent Pinchart wrote:
> > > On Saturday 02 April 2011 11:40:49 Manjunath Hadli wrote:
>
> [snip]
>
> > > > +static u32 video2_numbuffers = 3; static u32 video3_numbuffers =
> > > > +3;
> > >
> > > Why is the number of buffers set by a module parameter ? It should
> > > be negotiated dynamically with REQBUFS.
> >
> > This is the minimum number of buffers to be allocated by the system as
> > there is no scatter-gather mechanism in Davinci. To make sure of
> > availability of a minimum numbers of buffers for the system which may
> > not be available otherwise due to fragmentation, these are used.
>
> But you don't reserve the memory when the driver is probed, so how does this
> help ?
That was how it was done earlier. A detailed look at the code revealed that it
is not applicable anymore. Fixed it.
>
> [snip]
>
> > > > + struct vpbe_display *disp_dev = (struct vpbe_display
> > > > + *)disp_obj;
> > > > +
> > > > + /* Convert time represention from jiffies to timeval */
> > > > + jiffies_to_timeval(jiffies_time, &timevalue);
> > >
> > > Please use ktime_get_ts() or ktime_get_real_ts() to get the timestamp.
> >
> > Fixed. Used do_gettimeofday().
>
> Please use ktime_get_ts() instead. It will return a monotonic clock timestamp.
> Otherwise the buffer timestamp will vary when the system clock is modified
> (as a result of an NTP time update for instance).
Fixed.
>
> > > > + for (i = 0; i < VPBE_DISPLAY_MAX_DEVICES; i++) {
> > > > + layer = disp_dev->dev[i];
> > > > + /* If streaming is started in this layer */
> > > > + if (!layer->started)
> > > > + continue;
> > > > + /* Check the field format */
> > > > + if ((V4L2_FIELD_NONE == layer->pix_fmt.field) &&
> > > > + (event & OSD_END_OF_FRAME)) {
> > > > + /* Progressive mode */
> > > > + if (layer_first_int[i]) {
> > > > + layer_first_int[i] = 0;
> > > > + continue;
> > > > + }
> > > > + /*
> > > > +* Mark status of the cur_frm to
> > > > +* done and unlock semaphore on it
> > > > +*/
> > > > +
> > > > + if (layer->cur_frm != layer->next_frm) {
> > > > + layer->cur_frm->ts = timevalue;
> > > > + layer->cur_frm->state = VIDEOBUF_DONE;
> > >
> > > Please use videobuf2.
> >
> > I would like to get to videobuf2 as a next set of changes. I want to
> > get the Dm6446 driver fisrt, add it with Dm365 and do the videobuf2
> > later. I hope it is okay.
>
> We're trying to get rid of videobuf1, so accepting new drivers that make use
> of videobuf1 is a bit problematic. Have you had a look at videobuf2 ? How
> much time do you think it would take to convert this driver to videobuf2 ?
> Let's first address all the other issues, and then tackle that one.
I have gone through the videob
RE: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Hello Vladimir, Davinci family of devices consist of mainly Dm6446, Dm6467, Dm365, Dm355 which are dissimilar to OMAP devices in features and registers, and some (for ex Dm6467) in entire architecture. the current driver which you are seeing is DM6446, but the intent is to build-up the same code with support for DM355 and dM365 which belong to the same family and have almost same features and registers. There is no plan to share code with OMAP directory. Thanks and Regards, -Manju From: Vladimir Pantelic [vlado...@gmail.com] Sent: Tuesday, April 26, 2011 12:07 PM To: Hadli, Manjunath Cc: LMML; Kevin Hilman; LAK; Nori, Sekhar; dlos Subject: Re: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC Manjunath Hadli wrote: > This is the display driver for Texas Instruments's DM644X family > SoC. This patch contains the main implementation of the driver with the > V4L2 interface. The driver implements the streaming model with > support for both kernel allocated buffers and user pointers. It also > implements all of the necessary IOCTLs necessary and supported by the > video display device. is there any hope/chance to make this share code with the omap v4l2 driver in drivers/media/video/omap? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Laurent,
Thank you for your comments.
Please find my updates below.
The updated patches will follow today.
-Manju
On Thu, Apr 21, 2011 at 15:48:05, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Wednesday 20 April 2011 17:30:08 Hadli, Manjunath wrote:
> > Hi Laurent,
> > Thank you for you very valuable and detailed comments. I have fixed a
> > lot of your suggestions and there are a few questions I need more
> > explanation for. I will send the fixed and updated patches as a
> > follow-up after your clarifications.
>
> OK. Please see below for answsers.
>
> > On Thu, Apr 07, 2011 at 17:28:20, Laurent Pinchart wrote:
> > > On Saturday 02 April 2011 11:40:49 Manjunath Hadli wrote:
>
> [snip]
>
> > > > +static u32 video2_numbuffers = 3; static u32 video3_numbuffers =
> > > > +3;
> > >
> > > Why is the number of buffers set by a module parameter ? It should
> > > be negotiated dynamically with REQBUFS.
> >
> > This is the minimum number of buffers to be allocated by the system as
> > there is no scatter-gather mechanism in Davinci. To make sure of
> > availability of a minimum numbers of buffers for the system which may
> > not be available otherwise due to fragmentation, these are used.
>
> But you don't reserve the memory when the driver is probed, so how does this
> help ?
That was how it was done earlier. A detailed look at the code revealed that it
is not applicable anymore. Fixed it.
>
> [snip]
>
> > > > + struct vpbe_display *disp_dev = (struct vpbe_display
> > > > + *)disp_obj;
> > > > +
> > > > + /* Convert time represention from jiffies to timeval */
> > > > + jiffies_to_timeval(jiffies_time, &timevalue);
> > >
> > > Please use ktime_get_ts() or ktime_get_real_ts() to get the timestamp.
> >
> > Fixed. Used do_gettimeofday().
>
> Please use ktime_get_ts() instead. It will return a monotonic clock timestamp.
> Otherwise the buffer timestamp will vary when the system clock is modified
> (as a result of an NTP time update for instance).
Fixed.
>
> > > > + for (i = 0; i < VPBE_DISPLAY_MAX_DEVICES; i++) {
> > > > + layer = disp_dev->dev[i];
> > > > + /* If streaming is started in this layer */
> > > > + if (!layer->started)
> > > > + continue;
> > > > + /* Check the field format */
> > > > + if ((V4L2_FIELD_NONE == layer->pix_fmt.field) &&
> > > > + (event & OSD_END_OF_FRAME)) {
> > > > + /* Progressive mode */
> > > > + if (layer_first_int[i]) {
> > > > + layer_first_int[i] = 0;
> > > > + continue;
> > > > + }
> > > > + /*
> > > > +* Mark status of the cur_frm to
> > > > +* done and unlock semaphore on it
> > > > +*/
> > > > +
> > > > + if (layer->cur_frm != layer->next_frm) {
> > > > + layer->cur_frm->ts = timevalue;
> > > > + layer->cur_frm->state = VIDEOBUF_DONE;
> > >
> > > Please use videobuf2.
> >
> > I would like to get to videobuf2 as a next set of changes. I want to
> > get the Dm6446 driver fisrt, add it with Dm365 and do the videobuf2
> > later. I hope it is okay.
>
> We're trying to get rid of videobuf1, so accepting new drivers that make use
> of videobuf1 is a bit problematic. Have you had a look at videobuf2 ? How
> much time do you think it would take to convert this driver to videobuf2 ?
> Let's first address all the other issues, and then tackle that one.
I have gone through the videobuf2 in a limited way. I can get the changes done
for videobuf2, but my major objective is to get this version of the driver in.
Immediately after that I can take up videobuf2.
>
> [snip]
>
> > > > +/* interrupt service routine */
> > > > +static irqreturn_t venc_isr(int irq, void *arg) {
> > > > + static unsigned last_event;
> > > > + unsigned event = 0;
> > > > +
> > > > + if (venc_is_second_field())
> > > > + event |= VENC_SECOND_FIELD;
> > > > + else
> > > > + event |= VENC_FIRST_FIELD;
> > > > +
> > > > + if (event == (last_event & ~VENC_E
RE: [PATCH v18 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod
On Tue, Apr 05, 2011 at 16:28:33, Nori, Sekhar wrote: > Hi Manju, > > On Sat, Apr 02, 2011 at 15:13:17, Hadli, Manjunath wrote: > > Current devices.c file has a number of instances where > > IO_ADDRESS() is used for system module register access. Eliminate this > > in favor of a ioremap() based access. > > > > Consequent to this, a new global pointer davinci_sysmodbase has been > > introduced which gets initialized during the initialization of each > > relevant SoC > > > > Signed-off-by: Manjunath Hadli > > Acked-by: Sekhar Nori > > --- > > > diff --git a/arch/arm/mach-davinci/include/mach/hardware.h > > b/arch/arm/mach-davinci/include/mach/hardware.h > > index 414e0b9..2a6b560 100644 > > --- a/arch/arm/mach-davinci/include/mach/hardware.h > > +++ b/arch/arm/mach-davinci/include/mach/hardware.h > > @@ -21,6 +21,12 @@ > > */ > > #define DAVINCI_SYSTEM_MODULE_BASE0x01C4 > > > > +#ifndef __ASSEMBLER__ > > +extern void __iomem *davinci_sysmodbase; > > +#define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase + (x)) > > +void davinci_map_sysmod(void); > > +#endif > > Russell has posted[1] that the hardware.h file should not be polluted with > platform private stuff like this. > > Your patch 7/13 actually helped towards that goal, but this one takes us > back. This patch cannot be used in the current form. > > Currently there are separate header files for dm644x, dm355, dm646x and > dm365. I would like to start by removing unnecessary code from these files > and trying to consolidate them into a single file. Done. I have consolidated all the headers for DM6446, Dm6467, DM365 and DM355 into a single header as per your suggestion. > > Example, the EMAC base address definitions in dm365.h should be moved into > dm365.c. Similarly, there is a lot of VPIF specific stuff in dm646x.h which > is not really specific to dm646x.h and so should probably be moved to > include/media/ or arch/arm/mach-davinci/include/mach/vpif.h Done. > > Once consolidated into a single file, davinci_sysmodbase can be moved into > that file. Done. > > Also, Russell has said[2] that at least for this merge window only > consolidation and bug fixes will go through his tree. This means that as far > as mach-davinci is concerned, the clean-up part of this series can go to > 2.6.40 - but not the stuff which adds new support. > > Thanks, > Sekhar > > [1] http://www.spinics.net/lists/arm-kernel/msg120410.html > [2] http://www.spinics.net/lists/arm-kernel/msg120606.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v17 00/13] davinci vpbe: dm6446 v4l2 driver
Sekhar, Kevin, These patches have gone through considerable reviews. Could you please ACK from your end? Thanks and Regards, -Manju On Tue, Mar 15, 2011 at 19:26:28, Hadli, Manjunath wrote: > version17: > The more important among the patch history from previous comments 1. > Replacing _raw_readl() with readl(). > 2. Removal of platform resource overlap. > 3. Removal of unused macros. > 4. Fixing the module params typo. > 5. Minor changes in the GPL licensing header. > 6. Removed the initializer for field inversion parameter. > 7. Changing the Field inversion #ifdef to platform >based implementation. > 8. Interchanged platform and board specific patches due to dependencies. > > Manjunath Hadli (13): > davinci vpbe: V4L2 display driver for DM644X SoC > davinci vpbe: VPBE display driver > davinci vpbe: OSD(On Screen Display) block > davinci vpbe: VENC( Video Encoder) implementation > davinci vpbe: Build infrastructure for VPBE driver > davinci vpbe: Readme text for Dm6446 vpbe > davinci: move DM64XX_VDD3P3V_PWDN to devices.c > davinci: eliminate use of IO_ADDRESS() on sysmod > davinci: dm644x: Replace register base value with a defined macro > davinci: dm644x: change vpfe capture structure variables for > consistency > davinci: dm644x: move vpfe init from soc to board specific files > davinci: dm644x: add support for v4l2 video display > davinci: dm644x EVM: add support for VPBE display > > Documentation/video4linux/README.davinci-vpbe | 93 ++ > arch/arm/mach-davinci/board-dm644x-evm.c | 131 ++- > arch/arm/mach-davinci/devices.c | 24 +- > arch/arm/mach-davinci/dm355.c |1 + > arch/arm/mach-davinci/dm365.c |1 + > arch/arm/mach-davinci/dm644x.c| 172 ++- > arch/arm/mach-davinci/dm646x.c|1 + > arch/arm/mach-davinci/include/mach/dm644x.h |7 +- > arch/arm/mach-davinci/include/mach/hardware.h |7 +- > drivers/media/video/davinci/Kconfig | 22 + > drivers/media/video/davinci/Makefile |2 + > drivers/media/video/davinci/vpbe.c| 826 ++ > drivers/media/video/davinci/vpbe_display.c| 2084 > + > drivers/media/video/davinci/vpbe_osd.c| 1216 ++ > drivers/media/video/davinci/vpbe_osd_regs.h | 364 + > drivers/media/video/davinci/vpbe_venc.c | 556 +++ > drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ > include/media/davinci/vpbe.h | 185 +++ > include/media/davinci/vpbe_display.h | 146 ++ > include/media/davinci/vpbe_osd.h | 397 + > include/media/davinci/vpbe_types.h| 91 ++ > include/media/davinci/vpbe_venc.h | 41 + > 22 files changed, 6500 insertions(+), 44 deletions(-) create mode 100644 > Documentation/video4linux/README.davinci-vpbe > create mode 100644 drivers/media/video/davinci/vpbe.c > create mode 100644 drivers/media/video/davinci/vpbe_display.c > create mode 100644 drivers/media/video/davinci/vpbe_osd.c > create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > create mode 100644 drivers/media/video/davinci/vpbe_venc.c > create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > create mode 100644 include/media/davinci/vpbe.h create mode 100644 > include/media/davinci/vpbe_display.h > create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 > include/media/davinci/vpbe_types.h > create mode 100644 include/media/davinci/vpbe_venc.h > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] davinci: move DM64XX_VDD3P3V_PWDN to devices.c
Please ignore this platform patch series. I will repost it with the core driver
patch series as well.
Thx,
-Manju
On Mon, Mar 14, 2011 at 19:25:18, Hadli, Manjunath wrote:
> Move the definition of DM64XX_VDD3P3V_PWDN from hardware.h to devices.c since
> it is used only there.
>
> Signed-off-by: Manjunath Hadli
> ---
> arch/arm/mach-davinci/devices.c |1 +
> arch/arm/mach-davinci/include/mach/hardware.h |3 ---
> 2 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/devices.c
> b/arch/arm/mach-davinci/devices.c index 22ebc64..d3b2040 100644
> --- a/arch/arm/mach-davinci/devices.c
> +++ b/arch/arm/mach-davinci/devices.c
> @@ -182,6 +182,7 @@ static struct platform_device davinci_mmcsd1_device = {
> .resource = mmcsd1_resources,
> };
>
> +#define DM64XX_VDD3P3V_PWDN 0x48
>
> void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config)
> { diff --git a/arch/arm/mach-davinci/include/mach/hardware.h
> b/arch/arm/mach-davinci/include/mach/hardware.h
> index c45ba1f..414e0b9 100644
> --- a/arch/arm/mach-davinci/include/mach/hardware.h
> +++ b/arch/arm/mach-davinci/include/mach/hardware.h
> @@ -21,9 +21,6 @@
> */
> #define DAVINCI_SYSTEM_MODULE_BASE0x01C4
>
> -/* System control register offsets */
> -#define DM64XX_VDD3P3V_PWDN 0x48
> -
> /*
> * I/O mapping
> */
> --
> 1.6.2.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] davinci: vpfe: mdia controller implementation for capture
On Sun, Mar 06, 2011 at 22:59:40, Laurent Pinchart wrote: > Hi Manjunath, > > On Sunday 06 March 2011 16:36:05 Manjunath Hadli wrote: > > Introduction > > > > This is the proposal of the initial version of design and > > implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video > > Port Front End) drivers using Media Controloler , the initial version > > which supports the following: > > 1) dm365 vpfe > > 2) ccdc,previewer,resizer,h3a,af blocks > > 3) supports only continuous mode and not on-the-fly > > 4) supports user pointer exchange and memory mapped modes for buffer > > allocation > > > > This driver bases its design on Laurent Pinchart's Media Controller > > Design whose patches for Media Controller and subdev enhancements form the > > base. > > The driver also takes copious elements taken from Laurent Pinchart and > > others' OMAP ISP driver based on Media Controller. So thank you all > > the people who are responsible for the Media Controller and the OMAP > > ISP driver. > > You're welcome :-) > > > Also, the core functionality of the driver comes from the arago vpfe > > capture driver of which the CCDC capture was based on V4L2, with other > > drivers like Previwer, Resizer and other being individual character > > drivers. > > The CCDC, preview and resizer modules look very similar to their OMAP3 > counterparts. I think we should aim at sharing code between the drivers. It's > hard enough to develop, review and maintain one driver, let's not duplicate > the effort. Laurent, the modules in DM365 and DM355 are based on ISIF (for image capture) IPIPEIF, IPIPE and these modules are very different from that of their OMAP3 counterparts both in terms of hardware features, implementation and registers. The naming is done as CCDC, Previewer and Resizer only because to make it simple in understanding and making it comfortable for the API users of DM644X. I am aware of the discussion you and Vaibhav had, where he mentioned your point to make these drivers similar, and after Poring through the specs in detail we concluded that the approach can be the same but code-re-use is be minimal. So, we have derived the top level approach from you while the core implementation of hardware programming comes from arago. > > > The current driver caters to dm6446,dm355 and dm365 of which the > > current implementation works for dm365. The three VPFE IPs have some > > common elements in terms of some highe level functionality but there > > are differences in terms of register definitions and some core blocks. > > > > The individual specifications for each of these can be found here: > > dm6446 vpfe: http://www.ti.com/litv/pdf/sprue38h > > dm355 vpfe: http://www.ti.com/litv/pdf/spruf71a > > dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c > > > > The initial version of the driver implementation can be found here: > > > > http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h > > =refs > > /heads/mc_release > > > > Driver Design: Main entities > > > > The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. > > These hardware modules are generically exposed to the user level in > > the for of > > dm6446 style modules. Mainly - > > ccdc, previewer, resizer in addition to the other histogram and auto > > color/white balance correction and auto focus modules. > > > > 1)MT9P031 sensor module for RAW capture > > 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD > > inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV > > conversion 6)Resizer Module for scaling > > > > > > Connection for on-the-fly capture > > - > > Mt9P031 > > -->CCDC--->Previewer(optional)--->Resizer(optional)--->Video > > > > TVP7002 --- > > > > TV514x --- > > > > File Organisation > > - > > > > main driver files > > > > drivers/media/video/davinci/vpfe_capture.c > > include/media/davinci/vpfe_capture.h > > > > Instantiatiation of the v4l2 device, media device and all subdevs > > from here. > > > > video Interface files > > - > > drivers/media/video/davinci/vpfe_video.c > > include/media/davinci/vpfe_video.h > > > > Implements all the v4l2 video operations with a generic implementation > > for continuous and one shot mode. > > > > subdev interface files > > -- > > These file implement the subdev interface functionality for each of > > the subdev entities - mainly the entry points and their > > implementations in a IP generic way. > > > > drivers/media/video/davinci/vpfe_ccdc.c > > drivers/media/video/davinci/vpfe_previewer.c > > drivers/media/video/davinci/vpfe_resizer.c > > drivers/media/video/davinci/vpfe_af.c > > drivers/media/video/davinci/vpfe_aew.c > > drivers/media/video/tvp514x.c > > drivers/media/video/tvp7002.c > > drivers/media/video/ths7353.c > > > > include/media/davin
RE: [PATCH v16 3/3] davinci vpbe: board specific additions
Hi,
On Wed, Jan 19, 2011 at 21:42:00, Robert Mellen wrote:
> Are the "davinci vpbe" patches specific only to the DM644x platform? I am
> developing on the DM365 and would like to use the OSD features implemented in
> the patches. Are there plans to port these patches to the DM365? Is it only a
> matter of changing the board-specific files, such as board-dm365-evm.c?
These patches are only for DM6446. The DM365 enabled patches will follow in a
few days. Those will include the overall DM365 features and appropriate
platform additions.
>
> Sincerely,
> Robert Mellen
>
-Manjunath Hadli
>
> -Original Message-
> From:
> davinci-linux-open-source-bounces+robert.mellen=gvimd.com@linux.davincid
> davinci-linux-open-source-bounces+sp.c
> om
> [mailto:davinci-linux-open-source-bounces+robert.mellen=gvimd@linux.davi
> ncidsp.com] On Behalf Of Manjunath Hadli
> Sent: Tuesday, January 18, 2011 8:40 AM
> To: LMML; LAK; Kevin Hilman
> Cc: dlos; Mauro Carvalho Chehab
> Subject: [PATCH v16 3/3] davinci vpbe: board specific additions
>
> This patch implements tables for display timings,outputs and other board
> related functionalities.
>
> Signed-off-by: Manjunath Hadli
> Acked-by: Muralidharan Karicheri
> Acked-by: Hans Verkuil
> ---
> arch/arm/mach-davinci/board-dm644x-evm.c | 84
> -
> 1 files changed, 69 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
> b/arch/arm/mach-davinci/board-dm644x-evm.c
> index 0ca90b8..95ea13d 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -176,18 +176,6 @@ static struct platform_device
> davinci_evm_nandflash_device = {
> .resource = davinci_evm_nandflash_resource,
> };
>
> -static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
> -
> -static struct platform_device davinci_fb_device = {
> - .name = "davincifb",
> - .id = -1,
> - .dev = {
> - .dma_mask = &davinci_fb_dma_mask,
> - .coherent_dma_mask = DMA_BIT_MASK(32),
> - },
> - .num_resources = 0,
> -};
> -
> static struct tvp514x_platform_data tvp5146_pdata = {
> .clk_polarity = 0,
> .hs_polarity = 1,
> @@ -337,7 +325,6 @@ static struct pcf857x_platform_data pcf_data_u2 = {
> .teardown = evm_led_teardown,
> };
>
> -
> /* U18 - A/V clock generator and user switch */
>
> static int sw_gpio;
> @@ -404,7 +391,6 @@ static struct pcf857x_platform_data pcf_data_u18 = {
> .teardown = evm_u18_teardown,
> };
>
> -
> /* U35 - various I/O signals used to manage USB, CF, ATA, etc */
>
> static int
> @@ -616,8 +602,73 @@ static void __init evm_init_i2c(void)
> i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info)); }
>
> +#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
> +
> +/* venc standards timings */
> +static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
> + {"ntsc", VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
> + {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
> + {"pal", VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
> + {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0}, };
> +
> +/* venc dv preset timings */
> +static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
> + {"480p59_94", VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
> + {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
> + {"576p50", VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
> + {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0}, };
> +
> +/*
> + * The outputs available from VPBE + encoders. Keep the order same
> + * as that of encoders. First that from venc followed by that from
> + * encoders. Index in the output refers to index on a particular encoder.
> + * Driver uses this index to pass it to encoder when it supports more
> +than
> + * one output. Application uses index of the array to set an output.
> + */
> +static struct vpbe_output dm644x_vpbe_outputs[] = {
> + {
> + .output = {
> + .index = 0,
> + .name = "Composite",
> + .type = V4L2_OUTPUT_TYPE_ANALOG,
> + .std = VENC_STD_ALL,
> + .capabilities = V4L2_OUT_CAP_STD,
> + },
> + .subdev_name = VPBE_VENC_SUBDEV_NAME,
> + .default_mode = "ntsc",
> + .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
> + .modes = vbpe_enc_std_timings,
> + },
> + {
> + .output = {
> + .index = 1,
> + .name = "Component",
> + .type = V4L2_OUTPUT_TYPE_ANALOG,
> + .capabilities = V4L2_OUT_CAP_PRESETS,
> + },
> + .subdev_name = VPBE_VENC_SUBDEV_NAME,
> + .default_mode = "480p59_94",
> + .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
> + .mod
RE: [PATCH v14 1/2] davinci vpbe: platform specific additions
On Sat, Jan 15, 2011 at 21:13:33, Sergei Shtylyov wrote:
> Hello.
>
> On 14-01-2011 16:31, Manjunath Hadli wrote:
>
> > This patch implements the overall device creation for the Video
> > display driver.
>
> It does not only that...
>
> > Signed-off-by: Manjunath Hadli
> > Acked-by: Muralidharan Karicheri
> > Acked-by: Hans Verkuil
> [...]
>
> > diff --git a/arch/arm/mach-davinci/devices.c
> > b/arch/arm/mach-davinci/devices.c index 22ebc64..f435c7d 100644
> > --- a/arch/arm/mach-davinci/devices.c
> > +++ b/arch/arm/mach-davinci/devices.c
> > @@ -33,6 +33,8 @@
> > #define DM365_MMCSD0_BASE 0x01D11000
> > #define DM365_MMCSD1_BASE 0x01D0
> >
> > +void __iomem *davinci_sysmodbase;
> > +
>
> I think this should be added in a sperate patch.
>
> > @@ -242,10 +242,7 @@ void __init davinci_setup_mmc(int module, struct
> > davinci_mmc_config *config)
> > SZ_4K - 1;
> > mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
> > } else if (cpu_is_davinci_dm644x()) {
> > - /* REVISIT: should this be in board-init code? */
>
> Why you removed that line?
>
> > - void __iomem *base =
> > - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> > -
> > + void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
> > /* Power-on 3.3V IO cells */
> > __raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
> > /*Set up the pull regiter for MMC */ diff --git
> > a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index
> > 2652af1..106bc1b 100644
> > --- a/arch/arm/mach-davinci/dm355.c
> > +++ b/arch/arm/mach-davinci/dm355.c
> > @@ -878,6 +878,9 @@ void __init dm355_init_asp1(u32 evt_enable, struct
> > snd_platform_data *pdata)
> >
> > void __init dm355_init(void)
> > {
> > + davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
> > + if (!davinci_sysmodbase)
> > + return;
>
> Why not do it in davinci_common_init() instead of repeating for every SoC?
>
> > davinci_common_init(&davinci_soc_info_dm355);
> > }
> [...]
> > diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h
> > b/arch/arm/mach-davinci/include/mach/dm644x.h
> > index 5a1b26d..790925f 100644
> > --- a/arch/arm/mach-davinci/include/mach/dm644x.h
> > +++ b/arch/arm/mach-davinci/include/mach/dm644x.h
> > @@ -40,8 +44,14 @@
> > #define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600
> > #define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800
> >
> > +/* VPBE register base addresses */
> > +#define DM644X_VPSS_REG_BASE 0x01c73400
> > +#define DM644X_VENC_REG_BASE 0x01C72400
> > +#define DM644X_OSD_REG_BASE0x01C72600
>
> Note that for other devices we don't have '_REG' in such macros. Would
> make sense to delete it here for consistency.
You mean other devices like Dm355/Dm365? They will get added as part of a later
patch. Anyway since Sekhar also feels these could be a part of the .c file, I
will move these there.
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v13 5/8] davinci vpbe: platform specific additions
On Mon, Jan 10, 2011 at 17:25:33, Nori, Sekhar wrote: > On Mon, Jan 10, 2011 at 16:58:41, Sergei Shtylyov wrote: > > > > + > > > +#define OSD_REG_SIZE 0x01ff > > > +#define VENC_REG_SIZE0x017f > > > > Well, actually that's not the size but "limit" -- sizes should be > > 0x200 and 0x180 respectively... > > In most resource definitions on DaVinci, these are not even #defined. Just > add the limit directly to the base to derive the .end > > Thanks, > Sekhar > Ok. I shall keep the numbers as is. Thanks, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v12 5/8] davinci vpbe: platform specific additions
On Fri, Jan 07, 2011 at 19:49:19, Sergei Shtylyov wrote: > On 07-01-2011 17:13, Hadli, Manjunath wrote: > > >>> This patch implements the overall device creation for the Video > >>> display driver. > > >>> Signed-off-by: Manjunath Hadli > >>> Acked-by: Muralidharan Karicheri > >>> Acked-by: Hans Verkuil > >> [...] > > >>> diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h > >>> b/arch/arm/mach-davinci/include/mach/dm644x.h > >>> index 5a1b26d..b59591c 100644 > >>> --- a/arch/arm/mach-davinci/include/mach/dm644x.h > >>> +++ b/arch/arm/mach-davinci/include/mach/dm644x.h > [...] > >>> @@ -40,8 +43,21 @@ > >>>#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600 > >>>#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800 > > >>> +/* VPBE register base addresses */ > >>> +#define DM644X_VENC_REG_BASE 0x01C72400 > > >> You defined the macro but don't use it... > > >>> +#define DM644X_VPBE_REG_BASE 0x01C72780 > >>> + > >>> +#define DM644X_OSD_REG_BASE 0x01C72600 > > >> Same comment... > > >>> +#define DM644X_VPBE_REG_BASE 0x01C72780 > > >> This is duplicate. > > >>> + > >>> +#define OSD_REG_SIZE 0x0100 > > >> Your OSD platform device however has its resource of size 0x200... > > >>> +/* SYS register addresses */ > >>> +#define SYS_VPSS_CLKCTL 0x01C40044 > > >> You've already #define'd and used VPSS_CLKCTL -- this is > >> duplicate/unused. > > > We are using the base addresses from platform resources. I will delete > > these. > > You could use these macros to #define the platfrom resources, if you > #define'd them already. That is a good idea as well. Will take it. > > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v12 5/8] davinci vpbe: platform specific additions
On Fri, Jan 07, 2011 at 19:27:37, Sergei Shtylyov wrote: > Hello. > > On 07-01-2011 16:40, Manjunath Hadli wrote: > > > This patch implements the overall device creation for the Video > > display driver. > > > Signed-off-by: Manjunath Hadli > > Acked-by: Muralidharan Karicheri > > Acked-by: Hans Verkuil > [...] > > > diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h > > b/arch/arm/mach-davinci/include/mach/dm644x.h > > index 5a1b26d..b59591c 100644 > > --- a/arch/arm/mach-davinci/include/mach/dm644x.h > > +++ b/arch/arm/mach-davinci/include/mach/dm644x.h > > @@ -6,8 +6,7 @@ > >* > >* 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. > > + * the Free Software Foundation; either version 2 of the License. > > Unfinished sentence. Did you intend to changed the license to GPL 2 only? > If so, it's worth mentioning in the changelog... This should read like this: 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 version 2. I will change it appropriately. > > [...] > > @@ -40,8 +43,21 @@ > > #define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600 > > #define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800 > > > > +/* VPBE register base addresses */ > > +#define DM644X_VENC_REG_BASE 0x01C72400 > > You defined the macro but don't use it... > > > +#define DM644X_VPBE_REG_BASE 0x01C72780 > > + > > +#define DM644X_OSD_REG_BASE0x01C72600 > > Same comment... > > > +#define DM644X_VPBE_REG_BASE 0x01C72780 > > This is duplicate. > > > + > > +#define OSD_REG_SIZE 0x0100 > > Your OSD platform device however has its resource of size 0x200... > > > +/* SYS register addresses */ > > +#define SYS_VPSS_CLKCTL0x01C40044 > > You've already #define'd and used VPSS_CLKCTL -- this is duplicate/unused. We are using the base addresses from platform resources. I will delete these. > > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 0/2] davinci: convert to core-assisted locking
Tested for SD loopback and other IOCTLS. Reviewed the patches. Patch series Acked by: Manjunath Hadli -Manju On Wed, Jan 05, 2011 at 22:12:38, Hans Verkuil wrote: > > These two patches convert vpif_capture and vpif_display to core-assisted > locking and now use .unlocked_ioctl instead of .ioctl. > > These patches assume that the 'DaVinci VPIF: Support for DV preset and DV > timings' patch series was applied first. See: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26594.html > > These patches are targeted for 2.6.38. > > Regards, > > Hans > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] DaVinci VPIF: Support for DV preset and DV timings.
Tested for SD modes on TI Dm6467 EVM. DV_PRESTES testing done for THS8200 based EVM by Hans. For the whole patch series: Acked-by: Manjunath Hadli Regards, -Manju -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of mats.randga...@cisco.com Sent: Thursday, December 16, 2010 8:48 PM To: linux-media@vger.kernel.org Cc: mats.randga...@cisco.com Subject: [PATCH 0/5] DaVinci VPIF: Support for DV preset and DV timings. From: Mats Randgaard Support for DV preset and timings added to vpif_capture and vpif_display drivers. Functions for debugging are added and the code is improved as well. Mats Randgaard (5): vpif_cap/disp: Add debug functionality vpif: Consolidate formats from capture and display vpif_cap/disp: Add support for DV presets vpif_cap/disp: Added support for DV timings vpif_cap/disp: Cleanup, improved comments drivers/media/video/davinci/vpif.c | 177 drivers/media/video/davinci/vpif.h | 18 +- drivers/media/video/davinci/vpif_capture.c | 361 +++-- drivers/media/video/davinci/vpif_capture.h |2 + drivers/media/video/davinci/vpif_display.c | 402 +--- drivers/media/video/davinci/vpif_display.h |2 + 6 files changed, 886 insertions(+), 76 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v10 5/8] davinci vpbe: platform specific additions
Sergei,
On Thu, Dec 23, 2010 at 23:19:30, Sergei Shtylyov wrote:
> Hello.
>
> Manjunath Hadli wrote:
>
> > This patch implements the overall device creation for the Video
> > display driver
>
> > Signed-off-by: Manjunath Hadli
> > Acked-by: Muralidharan Karicheri
> > Acked-by: Hans Verkuil
> [...]
>
> > diff --git a/arch/arm/mach-davinci/dm644x.c
> > b/arch/arm/mach-davinci/dm644x.c index 9a2376b..eb87867 100644
> > --- a/arch/arm/mach-davinci/dm644x.c
> > +++ b/arch/arm/mach-davinci/dm644x.c
> > @@ -370,6 +370,7 @@ static struct platform_device dm644x_mdio_device = {
> > * soc description mux mode mode muxdbg
> > * reg offset mask mode
> > */
> > +
>
> Stray newline?
>
> [...]
> > +static struct resource dm644x_venc_resources[] = {
> > + /* venc registers io space */
> > + {
> > + .start = 0x01C72400,
> > + .end= 0x01C72400 + 0x17f,
> > + .flags = IORESOURCE_MEM,
> > + },
> > +};
> > +
> [...]
> > +static struct resource dm644x_v4l2_disp_resources[] = {
> > + {
> > + .start = IRQ_VENCINT,
> > + .end= IRQ_VENCINT,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = 0x01C724B8,
> > + .end= 0x01C724B8 + 0x3,
> > + .flags = IORESOURCE_MEM,
> > + },
> > +};
>
> Still intersects with dm644x_venc_resources[]. Is it intended?
Yes. We need one VENC register in the display ISR to check the field status.
I have reduced the access of the full range to only one reg.
>
> > static int __init dm644x_init_devices(void) {
> > if (!cpu_is_davinci_dm644x())
> > return 0;
> >
> > - /* Add ccdc clock aliases */
> > - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL);
> > - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL);
> > platform_device_register(&dm644x_edma_device);
> > -
>
> Should've left this newline alone...
>
> WBR, Sergei
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v10 0/8] davinci vpbe: dm6446 v4l2 driver
On Thu, Dec 23, 2010 at 17:23:37, Hadli, Manjunath wrote: > version10: addressed Kevin's and Sergei's comments > on: > 1.Lines spacing. > 2.Language errors 3.Now based on Kevin Hilman's tree :) > > Manjunath Hadli (8): > davinci vpbe: V4L2 display driver for DM644X SoC > davinci vpbe: VPBE display driver > davinci vpbe: OSD(On Screen Display) block > davinci vpbe: VENC( Video Encoder) implementation > davinci vpbe: platform specific additions-khilman > davinci vpbe: board specific additions > davinci vpbe: Build infrastructure for VPBE driver > davinci vpbe: Readme text for Dm6446 vpbe > > Documentation/video4linux/README.davinci-vpbe | 93 ++ > arch/arm/mach-davinci/board-dm644x-evm.c | 81 +- > arch/arm/mach-davinci/dm644x.c| 172 ++- > arch/arm/mach-davinci/include/mach/dm644x.h |4 + > drivers/media/video/davinci/Kconfig | 22 + > drivers/media/video/davinci/Makefile |2 + > drivers/media/video/davinci/vpbe.c| 836 ++ > drivers/media/video/davinci/vpbe_display.c| 2099 > + > drivers/media/video/davinci/vpbe_osd.c| 1211 ++ > drivers/media/video/davinci/vpbe_osd_regs.h | 389 + > drivers/media/video/davinci/vpbe_venc.c | 568 +++ > drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ > include/media/davinci/vpbe.h | 186 +++ > include/media/davinci/vpbe_display.h | 146 ++ > include/media/davinci/vpbe_osd.h | 397 + > include/media/davinci/vpbe_types.h| 93 ++ > include/media/davinci/vpbe_venc.h | 38 + > 17 files changed, 6505 insertions(+), 21 deletions(-) create mode 100644 > Documentation/video4linux/README.davinci-vpbe > create mode 100644 drivers/media/video/davinci/vpbe.c > create mode 100644 drivers/media/video/davinci/vpbe_display.c > create mode 100644 drivers/media/video/davinci/vpbe_osd.c > create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > create mode 100644 drivers/media/video/davinci/vpbe_venc.c > create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > create mode 100644 include/media/davinci/vpbe.h create mode 100644 > include/media/davinci/vpbe_display.h > create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 > include/media/davinci/vpbe_types.h > create mode 100644 include/media/davinci/vpbe_venc.h > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 6/8] davinci vpbe: board specific additions
Sergei,
Only one comment. For others I have done the fixes.
Thanks and Regards,
-Manju
Others On Tue, Dec 21, 2010 at 17:13:30, Sergei Shtylyov wrote:
> Hello.
>
> On 20-12-2010 16:54, Manjunath Hadli wrote:
>
> > This patch implements tables for display timings,outputs and other
> > board related functionalities.
>
> > Signed-off-by: Manjunath Hadli
> > Acked-by: Muralidharan Karicheri
> > Acked-by: Hans Verkuil
> [...]
>
> > diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
> > b/arch/arm/mach-davinci/board-dm644x-evm.c
> > index 34c8b41..e9b1243 100644
> > --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> > +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> [...]
> > @@ -606,8 +594,71 @@ static void __init evm_init_i2c(void)
> > i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
> > }
> >
> > +#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
>
> Insert an empty line here, please.
>
> > +/* venc standards timings */
> > +static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
> > + {"ntsc", VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
> > + {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
> > + {"pal", VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
> > + {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0}, };
> > +
> > +/* venc dv preset timings */
> > +static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
> > + {"480p59_94", VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
> > + {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
> > + {"576p50", VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
> > + {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0}, };
> > +
> > +/*
> > + * The outputs available from VPBE + ecnoders. Keep the
> > + * the order same as that of encoders. First that from venc followed
> > +by that
>^^^ duplicate
These are actually 2 different structures, the second one holding high def
Standards - 480p and 576p and use DV_PRESETS whicle the first is used for
SD modes.
>
> > +static struct vpbe_display_config vpbe_display_cfg = {
> > + .module_name = "dm644x-vpbe-display",
> > + .i2c_adapter_id = 1,
> > + .osd = {
> > + .module_name = VPBE_OSD_SUBDEV_NAME,
> > + },
> > + .venc = {
> > + .module_name = VPBE_VENC_SUBDEV_NAME,
> > + },
> > + .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
> > + .outputs = dm644x_vpbe_outputs,
> > +};
>
> Insert an empty line here, please.
>
> > static struct platform_device *davinci_evm_devices[] __initdata = {
> > - &davinci_fb_device,
> > &rtc_dev,
> > };
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 5/8] davinci vpbe: board specific additions
On Fri, Dec 17, 2010 at 21:59:23, Sergei Shtylyov wrote:
> Hello.
>
> Manjunath Hadli wrote:
>
> > This patch implements tables for display timings,outputs and other
> > board related functionalities.
>
> > Signed-off-by: Manjunath Hadli
> > Acked-by: Muralidharan Karicheri
> > Acked-by: Hans Verkuil
> [...]
>
> > diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
> > b/arch/arm/mach-davinci/board-dm644x-evm.c
> > index 34c8b41..e9b1243 100644
> > --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> > +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> [...]
> > @@ -620,6 +671,8 @@ davinci_evm_map_io(void) {
> > /* setup input configuration for VPFE input devices */
> > dm644x_set_vpfe_config(&vpfe_cfg);
> > + /* setup configuration for vpbe devices */
> > + dm644x_set_vpbe_display_config(&vpbe_display_cfg);
> > dm644x_init();
> > }
>
> This patch should *follow* the platform patch (where
> dm644x_set_vpbe_display_config() is defined), not precede it.
Thanks. Will update the patch series.
-Manju
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
Hans, I can take a look at this (DM6467)conversion unless your colleague has already started working on t. -Manju On Sun, Dec 19, 2010 at 02:48:05, Hans Verkuil wrote: > On Saturday, December 18, 2010 16:38:29 Muralidharan Karicheri wrote: > > Hans, > > > > For davinci drivers, I will be able to do this for vpfe_capture driver > > (DM355/6446/365). > > That one already uses unlocked_ioctl. You might want to consider auditing it > to see if converting it to core-assisted locking is better. It is much easier > to verify lock-correctness that way. > > > For DM6467, will someone from your company be able to take care of > > this? > > I'll see if I can do it and ask a colleague to test for me next week. > Otherwise I can do it in the first week of January. > > Regards, > > Hans > > > > > Murali > > > > On Sat, Dec 18, 2010 at 6:31 AM, Hans Verkuil wrote: > > > Hi all, > > > > > > Now that the BKL patch series has been merged in 2.6.37 it is time > > > to work on replacing .ioctl by .unlocked_ioctl in all v4l drivers. > > > > > > I've made an inventory of all drivers that still use .ioctl and I am > > > looking for volunteers to tackle one or more drivers. > > > > > > I have CCed this email to the maintainers of the various drivers (if > > > I know who it is) in the hope that we can get this conversion done > > > as quickly as possible. > > > > > > If I have added your name to a driver, then please confirm if you > > > are able to work on it or not. If you can't work on it, but you know > > > someone else, then let me know as well. > > > > > > There is also a list of drivers where I do not know who can do the > > > conversion. > > > If you can tackle one or more of those, please respond. > > > Unfortunately, those are among the hardest to convert :-( > > > > > > It would be great if we can tackle most of these drivers for 2.6.38. > > > I think we should finish all drivers for 2.6.39 at the latest. > > > > > > There are two ways of doing the conversion: one is to do all the > > > locking within the driver, the other is to use core-assisted > > > locking. How to do the core-assisted locking is described in > > > Documentation/video4linux/v4l2-framework.txt, but I'll repeat the > > > relevant part here: > > > > > > v4l2_file_operations and locking > > > > > > > > > You can set a pointer to a mutex_lock in struct video_device. > > > Usually this will be either a top-level mutex or a mutex per device > > > node. If you want finer-grained locking then you have to set it to NULL > > > and do you own locking. > > > > > > If a lock is specified then all file operations will be serialized > > > on that lock. If you use videobuf then you must pass the same lock > > > to the videobuf queue initialize function: if videobuf has to wait > > > for a frame to arrive, then it will temporarily unlock the lock and > > > relock it afterwards. If your driver also waits in the code, then > > > you should do the same to allow other processes to access the device node > > > while the first process is waiting for something. > > > > > > The implementation of a hotplug disconnect should also take the lock > > > before calling v4l2_device_disconnect. > > > > > > > > > Driver list: > > > > > > saa7146 (Hans Verkuil) > > > mem2mem_testdev (Pawel Osciak or Marek Szyprowski) > > > cx23885 (Steve Toth) > > > cx18-alsa (Andy Walls) > > > omap24xxcam (Sakari Ailus or David Cohen) > > > au0828 (Janne Grunau) > > > cpia2 (Andy Walls or Hans Verkuil) > > > cx231xx (Mauro Carvalho Chehab) > > > davinci (Muralidharan Karicheri) > > > saa6588 (Hans Verkuil) > > > pvrusb2 (Mike Isely) > > > usbvision (Hans Verkuil) > > > s5p-fimc (Sylwester Nawrocki) > > > fsl-viu (Anatolij Gustschin) > > > tlg2300 (Mauro Carvalho Chehab) > > > zr364xx (Hans de Goede) > > > soc_camera (Guennadi Liakhovetski) > > > usbvideo/vicam (Hans de Goede) > > > s2255drv (Pete Eberlein) > > > bttv (Mauro Carvalho Chehab) > > > stk-webcam (Hans de Goede) > > > se401 (Hans de Goede) > > > si4713-i2c (Hans Verkuil) > > > dsbr100 (Hans Verkuil) > > > > > > Staging driver list: > > > > > > go7007 (Pete Eberlein) > > > tm6000 (Mauro Carvalho Chehab) > > > (stradis/cpia: will be removed in 2.6.38, so no need to do anything) > > > > > > Unassigned drivers: > > > > > > saa7134 > > > em28xx > > > cx88 > > > solo6x10 (staging driver) > > > > > > Regards, > > > > > >Hans > > > > > > -- > > > Hans Verkuil - video4linux developer - sponsored by Cisco > > > -- > > > 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 > > > > > > > > > > > > > -- > Hans Verkuil - video4linux developer - sponsored by Cisco > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in the > body of a message to majord...@vger.kernel.org More majordomo i
RE: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe
Murali, Will update the doc. Thank you, -Manju On Wed, Dec 15, 2010 at 20:49:00, Karicheri, Muralidharan wrote: > Manju, > > Could you review the Document? I think it is not updated to reflect the > latest status: > > >+ Current status:- > >+ > >+ A build tested version of vpbe controller is available. > > I guess you have already tested this using the v4l2 driver. > > >+ v4l2 driver > >+- A version is already developed which is to be cleaned up and > >+ unit > >tested > > Ditto. v4l2 driver is already tested, right? > > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > > >-Original Message- > >From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >ow...@vger.kernel.org] On Behalf Of Manjunath Hadli > >Sent: Wednesday, December 15, 2010 4:12 AM > >To: LMML > >Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath > >Subject: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe > > > >Please refer to this file for detailed documentation of davinci vpbe > >v4l2 driver > > > >Signed-off-by: Manjunath Hadli > >Acked-by: Muralidharan Karicheri > >Acked-by: Hans Verkuil > >--- > > Documentation/video4linux/README.davinci-vpbe | 100 > >+ > > 1 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 > > Documentation/video4linux/README.davinci-vpbe > > > >diff --git a/Documentation/video4linux/README.davinci-vpbe > >b/Documentation/video4linux/README.davinci-vpbe > >new file mode 100644 > >index 000..3ff2dc3 > >--- /dev/null > >+++ b/Documentation/video4linux/README.davinci-vpbe > >@@ -0,0 +1,100 @@ > >+ > >+VPBE V4L2 driver design > >+ = > >+ = > >+ > >+ File partitioning > >+ - > >+ V4L2 display device driver > >+ drivers/media/video/davinci/vpbe_display.c > >+ drivers/media/video/davinci/vpbe_display.h > >+ > >+ VPBE display controller > >+ drivers/media/video/davinci/vpbe.c > >+ drivers/media/video/davinci/vpbe.h > >+ > >+ VPBE venc sub device driver > >+ drivers/media/video/davinci/vpbe_venc.c > >+ drivers/media/video/davinci/vpbe_venc.h > >+ drivers/media/video/davinci/vpbe_venc_regs.h > >+ > >+ VPBE osd driver > >+ drivers/media/video/davinci/vpbe_osd.c > >+ drivers/media/video/davinci/vpbe_osd.h > >+ drivers/media/video/davinci/vpbe_osd_regs.h > >+ > >+ Functional partitioning > >+ --- > >+ > >+ Consists of the following (in the same order as the list under file > >+ partitioning):- > >+ > >+ 1. V4L2 display driver > >+Implements video2 and video3 device nodes and > >+provides v4l2 device interface to manage VID0 and VID1 layers. > >+ > >+ 2. Display controller > >+Loads up venc, osd and external encoders such as ths8200. It provides > >+a set of API calls to V4L2 drivers to set the output/standards > >+in the venc or external sub devices. It also provides > >+a device object to access the services from osd sub device > >+using sub device ops. The connection of external encoders to venc LCD > >+controller port is done at init time based on default output and > >standard > >+selection or at run time when application change the output through > >+V4L2 IOCTLs. > >+ > >+When connetected to an external encoder, vpbe controller is also > >responsible > >+for setting up the interface between venc and external encoders > >+ based > >on > >+board specific settings (specified in board-xxx-evm.c). This allows > >+interfacing external encoders such as ths8200. The setup_if_config() > >+is implemented for this as well as configure_venc() (part of the > >+ next > >patch) > >+API to set timings in venc for a specific display resolution. As > >+ of > >this > >+patch series, the interconnection and enabling ans setting of the > >external > >+encoders is not present, and would be a part of the next patch series. > >+ > >+ 3. Venc subdevice > >+Responsible for setting outputs provided through internal dacs and > >also > >+setting timings at LCD controller port when external encoders are > >connected > >+at the port or LCD panel timings required. W
RE: [PATCH v3 6/6] davinci vpbe: Build infrastructure for VPBE driver
Sergei, Thank you for your comments. Will send a corrected pacth. -Manju On Thu, Dec 09, 2010 at 17:42:00, Sergei Shtylyov wrote: > Hello. > > On 02-12-2010 15:39, Manjunath Hadli wrote: > > > This patch adds the build infra-structure for Davinci VPBE dislay > > driver > > > Signed-off-by: Manjunath Hadli > > Signed-off-by: Muralidharan Karicheri > [...] > > > diff --git a/drivers/media/video/davinci/Kconfig > > b/drivers/media/video/davinci/Kconfig > > index 6b19540..dab32d5 100644 > > --- a/drivers/media/video/davinci/Kconfig > > +++ b/drivers/media/video/davinci/Kconfig > > @@ -91,3 +91,25 @@ config VIDEO_ISIF > > > >To compile this driver as a module, choose M here: the > >module will be called vpfe. > > + > > +config VIDEO_DM644X_VPBE > > +tristate "DM644X VPBE HW module" > > +select VIDEO_VPSS_SYSTEM > > + select VIDEOBUF_DMA_CONTIG > > Please use tabs uniformly to indent. > > > diff --git a/drivers/media/video/davinci/davinci_vpbe_readme.txt > > b/drivers/media/video/davinci/davinci_vpbe_readme.txt > > new file mode 100644 > > index 000..e7aabba > > --- /dev/null > > +++ b/drivers/media/video/davinci/davinci_vpbe_readme.txt > > @@ -0,0 +1,100 @@ > > + > > +VPBE V4L2 driver design > > + > > + == > > + > > + File partitioning > > + - > > + V4L2 display device driver > > + drivers/media/video/davinci/vpbe_display.c > > + drivers/media/video/davinci/vpbe_display.h > > + > > + VPBE display controller > > + drivers/media/video/davinci/vpbe.c > > + drivers/media/video/davinci/vpbe.h > > + > > + VPBE venc sub device driver > > + drivers/media/video/davinci/vpbe_venc.c > > + drivers/media/video/davinci/vpbe_venc.h > > + drivers/media/video/davinci/vpbe_venc_regs.h > > + > > + VPBE osd driver > > + drivers/media/video/davinci/vpbe_osd.c > > + drivers/media/video/davinci/vpbe_osd.h > > + drivers/media/video/davinci/vpbe_osd_regs.h > > + > > + Functional partitioning > > + --- > > + > > + Consists of following (in the same order as the list under file > ^ "the" missing. > > > + partitioning):- > > + > > + 1. V4L2 display driver > > +Implements video2 and video3 device nodes and > > +provides v4l2 device interface to manage VID0 and VID1 layers. > > + > > + 2. Display controller > > +Loads up venc, osd and external encoders such as ths8200. It provides > > +a set of API calls to V4L2 drivers to set the output/standards > > +in the venc or external sub devices. It also provides > > +a device object to access the services from osd sub device > > +using sub device ops. The connection of external encoders to venc LCD > > +controller port is done at init time based on default output and > > standard > > +selection or at run time when application change the output through > > +V4L2 IOCTLs. > > + > > +When connetected to an external encoder, vpbe controller is also > > responsible > > +for setting up the interface between venc and external encoders based > > on > > +board specific settings (specified in board-xxx-evm.c). This > > + allowes > > Only "allows". > > > +interfacing external encoders such as ths8200. The setup_if_config() > > +is implemented for this as well as configure_venc() (part of the next > > patch) > > +API to set timings in venc for a specific display resolution.As > > + of this > > Space missing after period. > > > +patch series, the interconnection and enabling ans setting of the > > external > > +encoders is not present, and would be a part of the next patch series. > > + > > + 3. Venc sub device > > +Responsible for setting outputs provides > > Provided? > > > through internal dacs and also > > DACs. > > > +setting timings at LCD controller port when external encoders are > > connected > > +at the port or LCD panel timings required. When external encoder/LCD > > panel > > +is connected, the timings for a specific standard/preset is retrieved > > from > > +the board specific table and the values are used to set the timings in > > +venc using non-standard timing mode. > > + > > +Support LCD Panel displays using the venc. For example to support a > > Logic > > +PD display, it requires setting up the LCD controller port with a set > > of > > +timings for the resolution supported and setting the dot clock. So we > > could > > +add the available outputs as a board specific entry ( i.e add the > > "LogicPD" > > Space not needed after (. > > > +output name to board-xxx-evm.c). A table of timings for various LCDs > > +supported cab > > Can? > > > be maintained in the board specific setup file to support > > +various LCD displays. > > + > > + 4. osd sub device > >
RE: [PATCH v3 2/6] davinci vpbe: VPBE display driver
Hans,
Thanks for the comments. Only one comment from me. Rest everything I have
taken care.
Thanks and Regards,
-Manju
On Tue, Dec 07, 2010 at 02:13:45, Hans Verkuil wrote:
> Comments below...
>
> On Thursday, December 02, 2010 13:38:36 Manjunath Hadli wrote:
> > This patch implements the coe functionality of the dislay driver,
> > mainly controlling the VENC and other encoders, and acting as the one
> > point interface for the man V4L2 driver.This implements the cre of
> > each of the V4L2 IOCTLs.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Muralidharan Karicheri
> > ---
> > drivers/media/video/davinci/vpbe.c | 847
> >
> > include/media/davinci/vpbe.h | 186
> > 2 files changed, 1033 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/media/video/davinci/vpbe.c
> > create mode 100644 include/media/davinci/vpbe.h
> >
> > diff --git a/drivers/media/video/davinci/vpbe.c
> > b/drivers/media/video/davinci/vpbe.c
> > new file mode 100644
> > index 000..96c0eea
> > --- /dev/null
> > +++ b/drivers/media/video/davinci/vpbe.c
> > @@ -0,0 +1,847 @@
> > +/*
> > + * Copyright (C) 2010 Texas Instruments Inc
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License as published
> > +by
> > + * the Free Software Foundation; either version 2 of the License.
> > + *
> > + * 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 #include
> > +#include #include #include
> > + #include #include
> > +#include #include #include
> > + #include #include #include
> > +
> > +
> > +#include
> > +#include #include
> > +#include
> > +
> > +
> > +#define VPBE_DEFAULT_OUTPUT"Composite"
> > +#define VPBE_DEFAULT_MODE "ntsc"
> > +
> > +static char *def_output = VPBE_DEFAULT_OUTPUT; static char *def_mode
> > += VPBE_DEFAULT_MODE; static struct osd_state *osd_device; static
> > +struct venc_platform_data *venc_device; static int debug;
> > +
> > +module_param(def_output, charp, S_IRUGO); module_param(def_mode,
> > +charp, S_IRUGO); module_param(debug, int, 0644);
> > +
> > +MODULE_PARM_DESC(def_output, "vpbe output name (default:Composite)");
> > +MODULE_PARM_DESC(ef_mode, "vpbe output mode name (default:ntsc");
> > +MODULE_PARM_DESC(debug, "Debug level 0-1");
> > +
> > +MODULE_DESCRIPTION("TI DMXXX VPBE Display controller");
> > +MODULE_LICENSE("GPL"); MODULE_AUTHOR("Texas Instruments");
> > +
> > +/**
> > + * vpbe_current_encoder_info - Get config info for current encoder
> > + * @vpbe_dev - vpbe device ptr
> > + *
> > + * Return ptr to current encoder config info */ static struct
> > +encoder_config_info* vpbe_current_encoder_info(struct vpbe_device
> > +*vpbe_dev) {
> > + struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
> > + int index = vpbe_dev->current_sd_index;
> > + return ((index == 0) ? &vpbe_config->venc :
> > + &vpbe_config->ext_encoders[index-1]);
> > +}
> > +
> > +/**
> > + * vpbe_find_encoder_sd_index - Given a name find encoder sd index
> > + *
> > + * @vpbe_config - ptr to vpbe cfg
> > + * @output_index - index used by application
> > + *
> > + * Return sd index of the encoder
> > + */
> > +static int vpbe_find_encoder_sd_index(struct vpbe_display_config
> > *vpbe_config,
> > +int index)
> > +{
> > + char *encoder_name = vpbe_config->outputs[index].subdev_name;
> > + int i;
> > +
> > + /* Venc is always first */
> > + if (!strcmp(encoder_name, vpbe_config->venc.module_name))
> > + return 0;
> > +
> > + for (i = 0; i < vpbe_config->num_ext_encoders; i++) {
> > + if (!strcmp(encoder_name,
> > +vpbe_config->ext_encoders[i].module_name))
> > + return i+1;
> > + }
> > + return -EINVAL;
> > +}
> > +
> > +/**
> > + * vpbe_g_cropcap - Get crop capabilities of the display
> > + * @vpbe_dev - vpbe device ptr
> > + * @cropcap - cropcap is a ptr to struct v4l2_cropcap
> > + *
> > + * Update the crop capabilities in crop cap for current
> > + * mode
> > + */
> > +static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
> > + struct v4l2_cropcap *cropcap)
> > +{
> > + if (NULL == cropcap)
> > + return -EINVAL;
> > + cropcap->bounds.left = 0;
> > + cropcap->bounds.top = 0;
> > + cropcap->bounds.width = vpbe_dev->current_timings.xres;
> > + cropcap->bounds.height = vpbe_dev->current_timings.yres;
> > + cropcap->defrect =
RE: [PATCH v2 5/6] davinci vpbe: platform specific additions
Resending the reply with proper indentation..
On Mon, Nov 29, 2010 at 21:27:39, Hadli, Manjunath wrote:
> On Sat, Nov 27, 2010 at 20:52:14, Muralidharan Karicheri wrote:
> > > +static int dm644x_set_if_config(enum v4l2_mbus_pixelcode pixcode) {
> > > + unsigned int val = 0;
> > > + int ret = 0;
> > > +
> > > + switch (pixcode) {
> > > + case V4L2_MBUS_FMT_FIXED:
> > > + /* Analog out.do nothing */
> > > + break;
> > > + case V4L2_MBUS_FMT_YUYV8_2X8:
> > > + /* BT656 */
> > > + val = (1<<12);
> > > + /*set VDMD in VMOD */
> > > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > > + /* Set YCCTL */
> > > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > > + break;
> > > + case V4L2_MBUS_FMT_YUYV10_1X20:
> > > + /* This was VPBE_DIGITAL_IF_YCC16.BT656.Replace the enum
> > > +accordingly
> > > + * when the right one gets into open source */
> > > + val = 0 << 12;
> > > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > > + break;
> > > + case V4L2_MBUS_FMT_SGRBG8_1X8:
> > > + /* This was VPBE_DIGITAL_IF_PRGB/SRGB.Replace the enum
> > > +accordingly
> > > + * when the right one gets into open source */
> > > + val = 2 << 12;
> > > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > > + break;
> > > + default:
> > > + ret = -EINVAL;
> > > + break;
> > > + }
> > > + return ret;
> > > +}
> >
> > The media bus format was added to sub device interface sometime back to
> > >configure the media data format (8 bit, 16 bit etc) and there is also a
> > set >of APIs to set the pad configuration (done by Laurent) which is being
> > >reviewed. In the context of that, I believe the venc VMOD configuration
> > can >be handled by implementing s_mbus_fmt() sub device API at venc.
> > Currently >OSD sub device has set_layer_config() which consists of setting
> > the pixel >format, frame format and sub-frame(crop). I think this can be
> > replaced by >s_mbus_fmt(). So on a board file, we could define the pad
> > configuration >which will include the mbus code such as
> > V4L2_MBUS_FMT_YUYV8_2X8 + addition >pad configurations such as embedded
> > sync enabled etc. So once sub device is >selected, vpbe controller will set
> > the pad configuration (obtained from >board file for each of the ?). The
> > pad in this case is the link between >venc lcd port to external encoder.
> > When S_FMT/S_CROP is called on the video >node, the controller calls
> > s_mbus_fmt() on the osd and venc sub device to >set the mbus formats.
>
[Manju] I changed the implementation currently only with the view
of reducing the privately defined enumerations which was one of the
comments by Hans. I am following Laurent's patch series, and it
is a good idea to get to s_mbus_fmt when it gets in. Till then we
can keep this. In the same regard, I asked Laurent to suggest
the correct enums for the RGB666 interfaces. I have no problem in
removing this call now and re-introducing it as part of next
patch series. I hope by that time Laurent's patch would get in too.
>
> >
> > Since the external encoder support is a TBD, I am okay if you implement
> > this after this patch series is merged to the tree.
> >
> > Murali
> > > +
> > > +static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
> > > +
> > > +static struct resource dm644x_v4l2_disp_resources[] = {
> > > + {
> > > + .start = IRQ_VENCINT,
> > > + .end = IRQ_VENCINT,
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + {
> > > + .start = 0x01C72400,
> > > + .end = 0x01C72400 + 0x180,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > +
> > > +};
> > > +static struct platform_device vpbe_v4l2_display = {
> > > + .name = "vpbe-v4l2",
> > > + .id = -1,
> > > + .num_resources = ARRAY_SIZE(dm644x_v4l2_di
RE: [PATCH v2 5/6] davinci vpbe: platform specific additions
On Sat, Nov 27, 2010 at 20:52:14, Muralidharan Karicheri wrote:
> > +static int dm644x_set_if_config(enum v4l2_mbus_pixelcode pixcode) {
> > + unsigned int val = 0;
> > + int ret = 0;
> > +
> > + switch (pixcode) {
> > + case V4L2_MBUS_FMT_FIXED:
> > + /* Analog out.do nothing */
> > + break;
> > + case V4L2_MBUS_FMT_YUYV8_2X8:
> > + /* BT656 */
> > + val = (1<<12);
> > + /*set VDMD in VMOD */
> > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > + /* Set YCCTL */
> > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > + break;
> > + case V4L2_MBUS_FMT_YUYV10_1X20:
> > + /* This was VPBE_DIGITAL_IF_YCC16.BT656.Replace the enum
> > +accordingly
> > + * when the right one gets into open source */
> > + val = 0 << 12;
> > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > + break;
> > + case V4L2_MBUS_FMT_SGRBG8_1X8:
> > + /* This was VPBE_DIGITAL_IF_PRGB/SRGB.Replace the enum
> > +accordingly
> > + * when the right one gets into open source */
> > + val = 2 << 12;
> > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + break;
> > + }
> > + return ret;
> > +}
>
> The media bus format was added to sub device interface sometime back to
> >configure the media data format (8 bit, 16 bit etc) and there is also a set
> >of APIs to set the pad configuration (done by Laurent) which is being
> >reviewed. In the context of that, I believe the venc VMOD configuration can
> >be handled by implementing s_mbus_fmt() sub device API at venc. Currently
> >OSD sub device has set_layer_config() which consists of setting the pixel
> >format, frame format and sub-frame(crop). I think this can be replaced by
> >s_mbus_fmt(). So on a board file, we could define the pad configuration
> >which will include the mbus code such as V4L2_MBUS_FMT_YUYV8_2X8 + addition
> >pad configurations such as embedded sync enabled etc. So once sub device is
> >selected, vpbe controller will set the pad configuration (obtained from
> >board file for each of the ?). The pad in this case is the link between
> >venc lcd port to external encoder. When S_FMT/S_CROP is called on the video
> >node, the controller calls s_mbus_fmt() on the osd and venc sub device to
> >set the mbus formats.
[Manju] I changed the implementation currently only with the view of reducing
the privately defined enumerations which was one of the comments by Hans. I am
following Laurent's patch series, and it is a good idea to get to s_mbus_fmt
when it gets in. Till then we can keep this. In the same regard, I asked
Laurent to suggest the correct enums for the RGB666 interfaces. I have no
problem in removing this call now and re-introducing it as part of next patch
series. I hope by that time Laurent's patch would get in too.
>
> Since the external encoder support is a TBD, I am okay if you implement this
> after this patch series is merged to the tree.
>
> Murali
> > +
> > +static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
> > +
> > +static struct resource dm644x_v4l2_disp_resources[] = {
> > + {
> > + .start = IRQ_VENCINT,
> > + .end = IRQ_VENCINT,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = 0x01C72400,
> > + .end = 0x01C72400 + 0x180,
> > + .flags = IORESOURCE_MEM,
> > + },
> > +
> > +};
> > +static struct platform_device vpbe_v4l2_display = {
> > + .name = "vpbe-v4l2",
> > + .id = -1,
> > + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
> > + .resource = dm644x_v4l2_disp_resources,
> > + .dev = {
> > + .dma_mask = &vpbe_display_dma_mask,
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + },
> > +};
> > +struct venc_platform_data dm644x_venc_pdata = {
> > + .venc_type = DM644X_VPBE,
> > + .setup_pinmux = dm644x_vpbe_setup_pinmux,
> > + .setup_clock = dm644x_venc_setup_clock,
> > + .setup_if_config = dm644x_set_if_config, };
> > +
> > +static struct platform_device dm644x_venc_dev = {
> > + .name = VPBE_VENC_SUBDEV_NAME,
> > + .id = -1,
> > + .num_resources = ARRAY_SIZE(dm644x_venc_resources),
> > + .resource = dm644x_venc_resources,
> > + .dev = {
> > + .dma_mask = &dm644x_venc_dma_mask,
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + .platform_data = (void *)&dm644x_venc_pdata,
> > + },
> > +};
> > +
> >
RE: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Hans, Thank you for the review comments. I will include a section on customizing for additions and changes to different boards. Thanks again, -Manju On Sat, Nov 13, 2010 at 18:22:19, Hans Verkuil wrote: > Hi Manju, > > I've reviewed the other patches as well. The only one for which I had > comments was patch 2/6. > > However, what I think would be useful here is to have an overview document, > either as part of a source or header, or as a separate text document. It is > not easy to get a good overview of how everything fits together, and a > document that describes the various parts and how they fit together would be > very benificial. > > I am thinking in particular of vendors building a new board based on this > device: how and where do you define new i2c display devices, how are they > initialized, etc. > > Regards, > > Hans > > On Monday, November 08, 2010 15:54:05 Manjunath Hadli wrote: > > This driver is written for Texas Instruments's DM644X VPBE IP. > > This SoC supports 2 video planes and 2 OSD planes as part of its OSD > > (On Screen Display) block. The OSD lanes predminantly support RGB > > space and the Video planes support YUV data. Out of these 4, the 2 > > video planes are supported as part of the V4L2 driver. These would be > > enumerated as video2 and video3 dev nodes. > > The blending and video timing generator unit (VENC- for Video Encoder) > > is the unit which combines/blends the output of these 4 planes into a > > single stream and this output is given to Video input devices like TV > > and other digital LCDs. The software for VENC is designed as a > > subdevice with support for SD(NTSC and PAL) modes and 2 outputs. > > This SoC forms the iniial implementation of its later additions like > > DM355 and DM365. > > > > Muralidharan Karicheri (6): > > davinci vpbe: V4L2 display driver for DM644X SoC > > davinci vpbe: VPBE display driver > > davinci vpbe: OSD(On Screen Display ) block > > davinci vpbe: VENC( Video Encoder) implementation > > davinci vpbe: platform specific additions > > davinci vpbe: Build infrastructure for VPBE driver > > > > arch/arm/mach-davinci/board-dm644x-evm.c | 85 +- > > arch/arm/mach-davinci/dm644x.c | 181 ++- > > arch/arm/mach-davinci/include/mach/dm644x.h |4 + > > drivers/media/video/davinci/Kconfig | 22 + > > drivers/media/video/davinci/Makefile |2 + > > drivers/media/video/davinci/vpbe.c | 861 ++ > > drivers/media/video/davinci/vpbe_display.c | 2283 > > ++ > > drivers/media/video/davinci/vpbe_osd.c | 1208 ++ > > drivers/media/video/davinci/vpbe_osd_regs.h | 389 + > > drivers/media/video/davinci/vpbe_venc.c | 617 +++ > > drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ > > include/media/davinci/vpbe.h | 187 +++ > > include/media/davinci/vpbe_display.h | 144 ++ > > include/media/davinci/vpbe_osd.h | 397 + > > include/media/davinci/vpbe_types.h | 170 ++ > > include/media/davinci/vpbe_venc.h| 70 + > > 16 files changed, 6790 insertions(+), 19 deletions(-) create mode > > 100644 drivers/media/video/davinci/vpbe.c > > create mode 100644 drivers/media/video/davinci/vpbe_display.c > > create mode 100644 drivers/media/video/davinci/vpbe_osd.c > > create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > > create mode 100644 drivers/media/video/davinci/vpbe_venc.c > > create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > > create mode 100644 include/media/davinci/vpbe.h create mode 100644 > > include/media/davinci/vpbe_display.h > > create mode 100644 include/media/davinci/vpbe_osd.h create mode > > 100644 include/media/davinci/vpbe_types.h > > create mode 100644 include/media/davinci/vpbe_venc.h > > > > -- > > 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 > > > > > > -- > Hans Verkuil - video4linux developer - sponsored by Cisco > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mediabus enums
On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote: > Hi Guennadi, > > On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote: > > On Wed, 10 Nov 2010, Hadli, Manjunath wrote: > > > Hello Guennadi, > > > > > >Your media-bus enumerations capture the formats quite well. I > > > needed > > > > > > the following for support on Davinci SOCs and liked to check with > > > you if these are covered in some format in the list. > > > 1. Parallel RGB 666 (18 data lines+ 5 sync lines) 2. YUYV16 (16 > > > lines) (16 data lines + 4 or 5 sync lines) > > > > According to the subdev-formats.xml > > > > http://git.linuxtv.org/pinchartl/media.git?a=blob;f=Documentation/DocB > > ook/v > > 4l/subdev-formats.xml;h=3688f27185f72ab109e3094c268e04f67cb8643e;hb=re > > fs/he > > ads/media-0003-subdev-pad > > > > they should be called V4L2_MBUS_FMT_RGB666_1X18 (or BGR666...) > > Agreed. > > > and V4L2_MBUS_FMT_YUYV16_1X16. > > Depending on what Manjunath meant, this should be either YUYV16_2X16 or > > > YUYV8_1X16. 16 bits per sample seems quite high to me, I suppose it should > > then be YUYV8_1X16. Actually, the interface transfers 16 bits per sample (Y=8bits and C=8bits) For the YC16 and 18 data lines (parallel) for RGB666. probably V4L2_MBUS_FMT_RGB666_1X18 and V4L2_MBUS_FMT_YUYV16_1X16 fit the bill. > > > Notice, that these codes do not define the complete bus topology, > > e.g., they say nothing about sync signals. This is a separate topic. > > -- > 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
RE: [PATCH 1/6] davinci vpbe: V4L2 display driver for DM644X SoC
Will do. Thanks! -manju On Wed, Nov 10, 2010 at 18:54:12, Hans Verkuil wrote: > > > Hans, > > Thank you for the review. I have taken care of the points you mentioned. > > The name comparison is unnecessary. I have also replaced the native > > struct definitions with those of v4l2. Request you to go through the > > rest of the patches so I can send the set once again. > > I won't have time for that until Friday at the earliest. More likely it will > be the weekend. I hope that's OK. > > Regards, > >Hans > > > > > Thanks and Regards, > > -Manju > > > -- > Hans Verkuil - video4linux developer - sponsored by Cisco > > -- 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
mediabus enums
Hello Guennadi, Your media-bus enumerations capture the formats quite well. I needed the following for support on Davinci SOCs and liked to check with you if these are covered in some format in the list. 1. Parallel RGB 666 (18 data lines+ 5 sync lines) 2. YUYV16 (16 lines) (16 data lines + 4 or 5 sync lines) Thanks and Regards, -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Murali, I will change the name order. Thanks and Regards, -manju On Wed, Nov 10, 2010 at 18:35:16, Muralidharan Karicheri wrote: > Manjunath, > > Thank you for putting up this patch together. I didn't see the 1/6 of this > series in the mailing list. Also it appears as if the patch came from me. > Please add my sign-off as second, you being the first. > > Murali > On Mon, Nov 8, 2010 at 9:54 AM, Manjunath Hadli > wrote: > > This driver is written for Texas Instruments's DM644X VPBE IP. > > This SoC supports 2 video planes and 2 OSD planes as part of its OSD > > (On Screen Display) block. The OSD lanes predminantly support RGB > > space and the Video planes support YUV data. Out of these 4, the 2 > > video planes are supported as part of the V4L2 driver. These would be > > enumerated as video2 and video3 dev nodes. > > The blending and video timing generator unit (VENC- for Video Encoder) > > is the unit which combines/blends the output of these 4 planes into a > > single stream and this output is given to Video input devices like TV > > and other digital LCDs. The software for VENC is designed as a > > subdevice with support for SD(NTSC and PAL) modes and 2 outputs. > > This SoC forms the iniial implementation of its later additions like > > DM355 and DM365. > > > > Muralidharan Karicheri (6): > > davinci vpbe: V4L2 display driver for DM644X SoC > > davinci vpbe: VPBE display driver > > davinci vpbe: OSD(On Screen Display ) block > > davinci vpbe: VENC( Video Encoder) implementation > > davinci vpbe: platform specific additions > > davinci vpbe: Build infrastructure for VPBE driver > > > > arch/arm/mach-davinci/board-dm644x-evm.c | 85 +- > > arch/arm/mach-davinci/dm644x.c | 181 ++- > > arch/arm/mach-davinci/include/mach/dm644x.h | 4 + > > drivers/media/video/davinci/Kconfig | 22 + > > drivers/media/video/davinci/Makefile | 2 + > > drivers/media/video/davinci/vpbe.c | 861 ++ > > drivers/media/video/davinci/vpbe_display.c | 2283 > > ++ > > drivers/media/video/davinci/vpbe_osd.c | 1208 ++ > > drivers/media/video/davinci/vpbe_osd_regs.h | 389 + > > drivers/media/video/davinci/vpbe_venc.c | 617 +++ > > drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ > > include/media/davinci/vpbe.h | 187 +++ > > include/media/davinci/vpbe_display.h | 144 ++ > > include/media/davinci/vpbe_osd.h | 397 + > > include/media/davinci/vpbe_types.h | 170 ++ > > include/media/davinci/vpbe_venc.h | 70 + > > 16 files changed, 6790 insertions(+), 19 deletions(-) > > create mode 100644 drivers/media/video/davinci/vpbe.c > > create mode 100644 drivers/media/video/davinci/vpbe_display.c > > create mode 100644 drivers/media/video/davinci/vpbe_osd.c > > create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > > create mode 100644 drivers/media/video/davinci/vpbe_venc.c > > create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > > create mode 100644 include/media/davinci/vpbe.h > > create mode 100644 include/media/davinci/vpbe_display.h > > create mode 100644 include/media/davinci/vpbe_osd.h > > create mode 100644 include/media/davinci/vpbe_types.h > > create mode 100644 include/media/davinci/vpbe_venc.h > > > > -- > > 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 > > > > > > -- > Murali Karicheri > mkarich...@gmail.com > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] davinci vpbe: Build infrastructure for VPBE driver
On Tue, Nov 09, 2010 at 20:21:50, Sergei Shtylyov wrote: > Hello. > > Manjunath Hadli wrote: > > > From: Muralidharan Karicheri > > > This patch adds the build infra-structure for Davinci VPBE dislay > > driver. > > > Signed-off-by: Muralidharan Karicheri > > Signed-off-by: Manjunath Hadli > [...] > > > diff --git a/drivers/media/video/davinci/Kconfig > > b/drivers/media/video/davinci/Kconfig > > index 6b19540..dab32d5 100644 > > --- a/drivers/media/video/davinci/Kconfig > > +++ b/drivers/media/video/davinci/Kconfig > > @@ -91,3 +91,25 @@ config VIDEO_ISIF > > > >To compile this driver as a module, choose M here: the > >module will be called vpfe. > > + > > +config VIDEO_DM644X_VPBE > > +tristate "DM644X VPBE HW module" > > +select VIDEO_VPSS_SYSTEM > > + select VIDEOBUF_DMA_CONTIG > > +help > > Please use tabs for indentation uniformly. > > WBR, Sergei > > Sure. Thank you for the review. -Manju -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Embedded Linux Conference
That is great! I will let you know our plans soon. -Manju -Original Message- From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com] Sent: Friday, March 06, 2009 9:33 AM To: Hans Verkuil Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Hadli, Manjunath; Aguirre Rodriguez, Sergio Alberto; Hiremath, Vaibhav Subject: Re: Embedded Linux Conference Hello, I'm attending as a speaker for one session which title is "Digital camera framework in Linux" I'm also looking forward to see many v4l2 engineers and discuss about latest issues. BTW, see you there Hans :) Nate On Fri, Mar 6, 2009 at 1:49 AM, Hans Verkuil wrote: > Just FYI: > > I'll be attending the Embedded Linux Conference in San Francisco, > April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). > > This might be a good opportunity to discuss omap and davinci V4L2 > issues face-to-face. Let me know if you are interested. > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- 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
