Re: [PATCH 05/15] mm: compaction: export some of the functions
On Fri, Feb 3, 2012 at 8:18 PM, Marek Szyprowski wrote: > From: Michal Nazarewicz > > This commit exports some of the functions from compaction.c file > outside of it adding their declaration into internal.h header > file so that other mm related code can use them. > > This forced compaction.c to always be compiled (as opposed to being > compiled only if CONFIG_COMPACTION is defined) but as to avoid > introducing code that user did not ask for, part of the compaction.c > is now wrapped in on #ifdef. > What if both compaction and CMA are not enabled? Good weekend Hillf -- 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 12/15] drivers: add Contiguous Memory Allocator
On Fri, Feb 3, 2012 at 8:18 PM, Marek Szyprowski wrote: > The Contiguous Memory Allocator is a set of helper functions for DMA > mapping framework that improves allocations of contiguous memory chunks. > > CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and > gives back to the system. Kernel is allowed to allocate movable pages > within CMA's managed memory so that it can be used for example for page > cache when DMA mapping do not use it. On dma_alloc_from_contiguous() > request such pages are migrated out of CMA area to free required > contiguous block and fulfill the request. This allows to allocate large > contiguous chunks of memory at any time assuming that there is enough > free memory available in the system. > > This code is heavily based on earlier works by Michal Nazarewicz. > > Signed-off-by: Marek Szyprowski > Signed-off-by: Kyungmin Park > CC: Michal Nazarewicz > Acked-by: Arnd Bergmann > Tested-by: Rob Clark > Tested-by: Ohad Ben-Cohen > Tested-by: Benjamin Gaignard > --- [...] > +/* > + * Contiguous Memory Allocator > + * > + * The Contiguous Memory Allocator (CMA) makes it possible to > + * allocate big contiguous chunks of memory after the system has > + * booted. > + * > + * Why is it needed? > + * > + * Various devices on embedded systems have no scatter-getter and/or > + * IO map support and require contiguous blocks of memory to > + * operate. They include devices such as cameras, hardware video > + * coders, etc. > + * > + * Such devices often require big memory buffers (a full HD frame > + * is, for instance, more then 2 mega pixels large, i.e. more than 6 > + * MB of memory), which makes mechanisms such as kmalloc() or > + * alloc_page() ineffective. > + * > + * At the same time, a solution where a big memory region is > + * reserved for a device is suboptimal since often more memory is > + * reserved then strictly required and, moreover, the memory is > + * inaccessible to page system even if device drivers don't use it. > + * > + * CMA tries to solve this issue by operating on memory regions > + * where only movable pages can be allocated from. This way, kernel > + * can use the memory for pagecache and when device driver requests > + * it, allocated pages can be migrated. > + * Without boot mem reservation, what is the successful rate of CMA to serve requests of 1MiB, 2MiB, 4MiB and 8MiB chunks? -- 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
dvb-apps: add scan files for Ireland (ie-*)
# HG changeset patch # User Jonathan McCrohan # Date 1328407970 0 # Node ID 068772e2c579c9e8c32c81d2e7b5b6978e6afe7f # Parent 69fc03702a6489ae46c50a3a5514df714d3832e8 add scan files for Ireland (ie-*) Signed-off-by: Jonathan McCrohan diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-CairnHill --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-CairnHill Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Cairn Hill +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 68200 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH47: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-ClermontCarn --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-ClermontCarn Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Clermont Carn +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 73000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH53: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-Dungarvan --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-Dungarvan Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Dungarvan +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 74600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH55: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-HolywellHill --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-HolywellHill Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Holywell Hill +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 54600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH30: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-Kippure --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-KippureSun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Kippure +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 73800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH54: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-Maghera --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-MagheraSun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Maghera +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 69000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH48: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-MountLeinster --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-MountLeinster Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Mount Leinster +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 66600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH45: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-Mullaghanish --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-Mullaghanish Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Mullaghanish +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 47400 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH21: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-SpurHill --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-SpurHill Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Spur Hill +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 66600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH45: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-ThreeRock --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-ThreeRock Sun Feb 05 02:12:50 2012 + @@ -0,0 +1,4 @@ +# Ireland, Three Rock +# Generated from http://www.rtenl.ie/wp-content/uploads/2011/12/SAORVIEW-Frequencies-Rev-1.0.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 73800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH54: Saorview diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-Truskmore --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/ie-Truskmore S
Re: [Q] Interleaved formats on the media bus
On 02/05/2012 12:44 AM, Guennadi Liakhovetski wrote: >> Yes, this is what I started with. What do you think about creating media Actually now I have something like V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 (I1 indicating interleaving method), so it is not so tightly tied to a particular sensor. >> bus codes directly corresponding the the user defined MIPI-CSI data types ? > > We've discussed this before with Laurent, IIRC, and the decision was, that > since a "typical" CSI-2 configuration includes a CSI-2 phy, interfacing to > a "standard" bridge, that can also receive parallel data directly, and the > phy normally has a 1-to-1 mapping from CSI-2 formats to mediabus codes, > so, we can just as well directly use respective mediabus codes to > configure CSI-2 phys. OK. The 1-to-1 mapping is true only for MIPI-CSI defined image formats AFAICS. Let's take JPEG as an example, AFAIU there is nothing in the standard indicating which User Defined Data Type should be used for JPEG. If some bridge/sensor pair uses User1 for V4L2_MBUS_FMT_JPEG_1X8 and other uses User2 then there is no way to make any of these sensors work with any bridge without code modifications. Looks like we would need MIPI-CSI DT field in format description data structure ((like) struct soc_mbus_lookup). -- Thanks, Sylwester -- 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: [Q] Interleaved formats on the media bus
On Sat, 4 Feb 2012, Sakari Ailus wrote: > Hi Sylwester, > > Sylwester Nawrocki wrote: > > On 02/04/2012 12:22 PM, Sakari Ailus wrote: [snip] > >> I'd be much in favour or using a separate channel ID as Guennadi asked; > >> that way you could quite probably save one memory copy as well. But if > >> the hardware already exists and behaves badly there's usually not much > >> you can do about it. > > > > As I explained above I suspect that the sensor sends each image data type > > on separate channels (I'm not 100% sure) but the bridge is unable to DMA > > it into separate memory regions. > > > > Currently we have no support in V4L2 for specifying separate image data > > format per MIPI-CSI2 channel. Maybe the solution is just about that - > > adding support for virtual channels and a possibility to specify an image > > format separately per each channel ? > > Still, there would be nothing telling how the channels are interleaved :-/ > > _If_ the sensor sends YUV and compressed JPEG data in separate CSI-2 > channels then definitely the correct way to implement this is to take > this kind of setup into account in the frame format description --- we > do need that quite badly. > > However, this doesn't really help you with your current problem, and > perhaps just creating a custom format for your sensor driver is the best > way to go for the time being. As fas as I understand, the problem is not the sensor but the bridge. So, following your logic you would have to create a new format for each sensor with similar capabilities, if you want to connect it to this bridge. This doesn't seem like a good idea to me. May I again do some shameless self-advertising: soc-camera had to deal with this kind of problem since some time and we have a solution for it. The problem is actually not _quite_ identical, it has nothing to do with interleaved formats, but I think, essentially the problem is: how to configure bridges to process some generic (video) data when no specialised support for this data format is available or implemented yet. This is what we call a pass-through mode. All bridges I've met so far have a capability to receive and store in memory some generic video data, for which you basically just configure the number of bytes per line and the number of lines per frame. The solution, that we use in soc-camera is to define format descriptors, that can be used to calculate those generic parameters for each supported format. I am talking about the mbus_fmt[] array and the soc_mbus_bytes_per_line() function in soc_mediabus.c. So, my suggestion would be to use something similar for this case too: use some high-level description for this format, including any channel information, that advanced bridges can use to properly separate the date, and a function, that interprets that high-level description and provides the low-level details like bytes-per-line, necessary to configure bridges, unable to handle the data natively. Ideally, of course, I would suggest to convert that file to a generic API, usable for all V4L2 drivers (basically, just rename a couple of structs and functions) and extend it to handle interleaved formats. > But. When someone attaches this kind of > sensor to another CSI-2 receiver that can separate the data from > different channels, I think we should start working towards for a > correct solution which this driver also should support. Exactly. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [Q] Interleaved formats on the media bus
On Sat, 4 Feb 2012, Sylwester Nawrocki wrote: > Hi Sakari, [snip] > Yes, this is what I started with. What do you think about creating media > bus codes directly corresponding the the user defined MIPI-CSI data types ? We've discussed this before with Laurent, IIRC, and the decision was, that since a "typical" CSI-2 configuration includes a CSI-2 phy, interfacing to a "standard" bridge, that can also receive parallel data directly, and the phy normally has a 1-to-1 mapping from CSI-2 formats to mediabus codes, so, we can just as well directly use respective mediabus codes to configure CSI-2 phys. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 04/31] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
Hi Sakari, On 02/04/2012 09:30 PM, Sakari Ailus wrote: >>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1<< 0) >>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1<< 1) >>> +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1<< 2) >>> + >>> +/* active cropping area */ >>> +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE0 >>> +/* cropping bounds */ >>> +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS2 >> >> You've dropped the DEFAULT targets but the target numbers stayed >> unchanged. How about using hex numbers ? e.g. >> >> #define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 0x0100 >> #define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 0x0101 > > Fine for me. Changed for the next revision. > > I wanted to keep the target numbers the same since we're still using > exactly the same as the V4L2. You're right, keeping the numbers same for subdevs and regular video nodes may be important. I'm wondering whether we should use same definitions for subdevs, rather than inventing new ones ? In case we associate the selection targets with controls some target identifiers must not actually be different. Whether the control belongs directly to a video node control handler or is inherited from a sub-device the selection target would have to be same. I'm referring here to an auto focus rectangle selection target base for instance. I guess including videodev2.h from v4l2-subdev.h is not an option, if at all necessary ? -- Thanks, Sylwester -- 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 04/31] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
Hi Sylwester,
Thanks for the comments!!
Sylwester Nawrocki wrote:
> On 02/03/2012 12:54 AM, Sakari Ailus wrote:
>> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
>> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
>> VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
>>
>> VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
>>
>> Signed-off-by: Sakari Ailus
>> ---
>> drivers/media/video/v4l2-subdev.c | 34 +-
>> include/linux/v4l2-subdev.h | 41
>> +
>> include/media/v4l2-subdev.h | 21 +++---
>> 3 files changed, 82 insertions(+), 14 deletions(-)
>>
> ...
>> diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
>> index ed29cbb..192993a 100644
>> --- a/include/linux/v4l2-subdev.h
>> +++ b/include/linux/v4l2-subdev.h
>> @@ -123,6 +123,43 @@ struct v4l2_subdev_frame_interval_enum {
>> __u32 reserved[9];
>> };
>>
>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE(1<< 0)
>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE(1<< 1)
>> +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG(1<< 2)
>> +
>> +/* active cropping area */
>> +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE 0
>> +/* cropping bounds */
>> +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS 2
>
> You've dropped the DEFAULT targets but the target numbers stayed
> unchanged. How about using hex numbers ? e.g.
>
> #define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE0x0100
> #define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS0x0101
Fine for me. Changed for the next revision.
I wanted to keep the target numbers the same since we're still using
exactly the same as the V4L2.
> ?
>> +/* current composing area */
>> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 256
>> +/* composing bounds */
>> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 258
>> +
>> +
>> +/**
>> + * struct v4l2_subdev_selection - selection info
>> + *
>> + * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
>> + * @pad: pad number, as reported by the media API
>> + * @target: selection target, used to choose one of possible rectangles
>> + * @flags: constraints flags
>
> s/constraints/constraint ?
Fixed.
>> + * @r: coordinates of selection window
>
> s/selection/ the selection ?
>
>> + * @reserved: for future use, rounds structure size to 64 bytes, set to zero
>> + *
>> + * Hardware may use multiple helper window to process a video stream.
>
> s/window/windows ?
Same for these two.
>> + * The structure is used to exchange this selection areas between
>> + * an application and a driver.
>> + */
>> +struct v4l2_subdev_selection {
>> +__u32 which;
>> +__u32 pad;
>> +__u32 target;
>> +__u32 flags;
>> +struct v4l2_rect r;
>> +__u32 reserved[8];
>> +};
>> +
Cheers,
--
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: [PATCH v2 09/31] v4l: Image source control class
Hi Sylwester, Thanks for the review! Sylwester Nawrocki wrote: > On 02/03/2012 12:54 AM, Sakari Ailus wrote: >> Add image source control class. This control class is intended to contain >> low level controls which deal with control of the image capture process --- >> the A/D converter in image sensors, for example. >> >> Signed-off-by: Sakari Ailus >> --- >> Documentation/DocBook/media/v4l/controls.xml | 86 >> >> .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |6 ++ >> drivers/media/video/v4l2-ctrls.c |7 ++ >> include/linux/videodev2.h |9 ++ >> 4 files changed, 108 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml >> index a1be378..6842e80 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -3379,4 +3379,90 @@ interface and may change in the future. >> >> >> >> + >> + >> +Image Source Control Reference >> + >> + >> +Experimental >> + >> +This is an> +linkend="experimental">experimental interface and may >> +change in the future. >> + >> + >> + >> +The Image Source control class is intended for low-level >> +control of image source devices such as image sensors. The >> +devices feature an analogue to digital converter and a bus >> +transmitter to transmit the image data out of the device. >> + >> + >> + >> +Image Source Control IDs >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> +ID >> +Type >> +> align="left">Description >> + >> + >> + >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS >> +class >> + >> + >> +The IMAGE_SOURCE class descriptor. >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK >> +integer >> + >> + >> +Vertical blanking. The idle >> +preriod after every frame during which no image data is >> +produced. The unit of vertical blanking is a line. Every >> +line has length of the image width plus horizontal >> +blanking at the pixel clock specified by struct >> +v4l2_mbus_framefmt > The pixel clock is no longer specified by struct v4l2_mbus_framefmt, it's > now determined by V4L2_CID_IMAGE_PROC_LINK_FREQ controls, right ? I've had so many references to the pixel rate in the media bus frame format that it was inevitable some must have been left. :-o The V4L2_CID_IMAGE_PROC_PIXEL_RATE control will replace this. > When you drop the class name from the control names, it is perhaps better > to just use V4L2_CID_LINK_FREQUENCY name. I'll do that to the next patch.set. >> +/>. >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK >> +integer >> + >> + >> +Horizontal blanking. The idle >> +preriod after every line of image data during which no > > s/preriod/period Fixed. >> +image data is produced. The unit of horizontal blanking is >> +pixels. >> + >> + >> +> spanname="id">V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN >> +integer >> + >> + >> +Analogue gain is gain affecting >> +all colour components in the pixel matrix. The gain >> +operation is performed in the analogue domain before A/D >> +conversion. >> + >> + >> + >> + >> + >> + >> + >> + >> + >> >> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml >> b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml >> index b17a7aa..f420034 100644 >> --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml >> +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml >> @@ -265,6 +265,12 @@ These controls are described in> These controls are described in> linkend="flash-controls" />. >> >> + >> +V4L2_CTRL_CLASS_IMAGE_SOURCE >> +0x9d The class containing image >> +source controls. These controls are described in> +linkend="image-source-controls" />. >> + >> >> >> >> diff --git a/drivers/media/video/v4l2-ctrls.c >> b/drivers/media/video/v4l2-ctrls.c >> index 139ba42..37249b7 100644 >> --- a/drivers/media/video/v4l2-ctrls.c >> +++ b/drivers/media/video/v4l2-ctrls.c >> @@ -607,6 +607,12 @@ const char *v4l2_ctrl_get_name(u32 id) >> case V4L2_CID_FLASH_CHARGE: return "Charge"; >> case V4L2_CID_FLASH_READY: return "Ready to Strobe"; >> >> +/* Image source controls */ >> +case V4L2_CID_IMAGE_SOURCE_CLASS: return "Image source controls"; >> +case V4L2_CID_IMAGE_SOURCE_VBLANK: return "Vertical blanking"; >> +case V4L2_CID_IMAGE_SOURCE_HBLANK: return "Horizontal blanking"; >> +case V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN: return "Analogue gain"; > > All words in control descriptions ne
Re: [PATCH v2 04/31] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
On 02/03/2012 12:54 AM, Sakari Ailus wrote:
> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
> VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
>
> VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/video/v4l2-subdev.c | 34 +-
> include/linux/v4l2-subdev.h | 41
> +
> include/media/v4l2-subdev.h | 21 +++---
> 3 files changed, 82 insertions(+), 14 deletions(-)
>
...
> diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
> index ed29cbb..192993a 100644
> --- a/include/linux/v4l2-subdev.h
> +++ b/include/linux/v4l2-subdev.h
> @@ -123,6 +123,43 @@ struct v4l2_subdev_frame_interval_enum {
> __u32 reserved[9];
> };
>
> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1<< 0)
> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1<< 1)
> +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1<< 2)
> +
> +/* active cropping area */
> +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE 0
> +/* cropping bounds */
> +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS 2
You've dropped the DEFAULT targets but the target numbers stayed
unchanged. How about using hex numbers ? e.g.
#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 0x0100
#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 0x0101
?
> +/* current composing area */
> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 256
> +/* composing bounds */
> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 258
> +
> +
> +/**
> + * struct v4l2_subdev_selection - selection info
> + *
> + * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
> + * @pad: pad number, as reported by the media API
> + * @target: selection target, used to choose one of possible rectangles
> + * @flags: constraints flags
s/constraints/constraint ?
> + * @r: coordinates of selection window
s/selection/ the selection ?
> + * @reserved: for future use, rounds structure size to 64 bytes, set to zero
> + *
> + * Hardware may use multiple helper window to process a video stream.
s/window/windows ?
> + * The structure is used to exchange this selection areas between
> + * an application and a driver.
> + */
> +struct v4l2_subdev_selection {
> + __u32 which;
> + __u32 pad;
> + __u32 target;
> + __u32 flags;
> + struct v4l2_rect r;
> + __u32 reserved[8];
> +};
> +
--
Regards,
Sylwester
--
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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Feb 4 19:00:17 CET 2012 git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/31] v4l: Image source control class
Hi Sakari, On 02/03/2012 12:54 AM, Sakari Ailus wrote: > Add image source control class. This control class is intended to contain > low level controls which deal with control of the image capture process --- > the A/D converter in image sensors, for example. > > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media/v4l/controls.xml | 86 > > .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |6 ++ > drivers/media/video/v4l2-ctrls.c |7 ++ > include/linux/videodev2.h |9 ++ > 4 files changed, 108 insertions(+), 0 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index a1be378..6842e80 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -3379,4 +3379,90 @@ interface and may change in the future. > > > > + > + > +Image Source Control Reference > + > + > + Experimental > + > + This is an + linkend="experimental">experimental interface and may > + change in the future. > + > + > + > + The Image Source control class is intended for low-level > + control of image source devices such as image sensors. The > + devices feature an analogue to digital converter and a bus > + transmitter to transmit the image data out of the device. > + > + > + > +Image Source Control IDs > + > + > + > + > + > + > + > + > + > + > + ID > + Type > + align="left">Description > + > + > + > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS > + class > + > + > + The IMAGE_SOURCE class descriptor. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK > + integer > + > + > + Vertical blanking. The idle > + preriod after every frame during which no image data is > + produced. The unit of vertical blanking is a line. Every > + line has length of the image width plus horizontal > + blanking at the pixel clock specified by struct > + v4l2_mbus_framefmt + />. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK > + integer > + > + > + Horizontal blanking. The idle > + preriod after every line of image data during which no s/preriod/period > + image data is produced. The unit of horizontal blanking is > + pixels. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN > + integer > + > + > + Analogue gain is gain affecting > + all colour components in the pixel matrix. The gain > + operation is performed in the analogue domain before A/D > + conversion. > + > + > + > + > + > + > + > + > + > > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml > b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml > index b17a7aa..f420034 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml > @@ -265,6 +265,12 @@ These controls are described in These controls are described in linkend="flash-controls" />. > > + > + V4L2_CTRL_CLASS_IMAGE_SOURCE > + 0x9d The class containing image > + source controls. These controls are described in + linkend="image-source-controls" />. > + > > > > diff --git a/drivers/media/video/v4l2-ctrls.c > b/drivers/media/video/v4l2-ctrls.c > index 139ba42..37249b7 100644 > --- a/drivers/media/video/v4l2-ctrls.c > +++ b/drivers/media/video/v4l2-ctrls.c > @@ -607,6 +607,12 @@ const char *v4l2_ctrl_get_name(u32 id) > case V4L2_CID_FLASH_CHARGE: return "Charge"; > case V4L2_CID_FLASH_READY: return "Ready to Strobe"; > > + /* Image source controls */ > + case V4L2_CID_IMAGE_SOURCE_CLASS: return "Image source controls"; > + case V4L2_CID_IMAGE_SOURCE_VBLANK: return "Vertical blanking"; > + case V4L2_CID_IMAGE_SOURCE_HBLANK: return "Horizontal blanking"; > + case V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN: return "Analogue gain"; All words in control descriptions need to be capitalized. :-) -- Regards, Sylwester -- 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: [Q] Interleaved formats on the media bus
Hi Sakari, On 02/04/2012 04:43 PM, Sakari Ailus wrote: >> As I explained above I suspect that the sensor sends each image data type >> on separate channels (I'm not 100% sure) but the bridge is unable to DMA >> it into separate memory regions. >> >> Currently we have no support in V4L2 for specifying separate image data >> format per MIPI-CSI2 channel. Maybe the solution is just about that - >> adding support for virtual channels and a possibility to specify an image >> format separately per each channel ? >> Still, there would be nothing telling how the channels are interleaved :-/ > > _If_ the sensor sends YUV and compressed JPEG data in separate CSI-2 As I learned MIPI-CSI2 specifies 3 data interleaving methods, at: packet, frame and virtual channel level. I'm almost certain I'm dealing now with packet level interleaving, but VC interleaving might need to be supported very soon. > channels then definitely the correct way to implement this is to take > this kind of setup into account in the frame format description --- we > do need that quite badly. Yeah, I will probably want to focus more on that after completing the camera control works. > However, this doesn't really help you with your current problem, and > perhaps just creating a custom format for your sensor driver is the best > way to go for the time being. But. When someone attaches this kind of Yes, this is what I started with. What do you think about creating media bus codes directly corresponding the the user defined MIPI-CSI data types ? > sensor to another CSI-2 receiver that can separate the data from > different channels, I think we should start working towards for a > correct solution which this driver also should support. Sure. We would also include description of bus receiver/transmitter capabilities, e.g. telling explicitly which interleaving methods are supported. > With information on the frame format, the CSI-2 hardware could properly > write the data into two separate buffers. Possibly it should provide two > video nodes, but I'm not sure about that. A multi-plane buffer is > another option. Indeed. I think both solutions are equally correct and there should be no need to restrict us to one or the other. I would leave decision up to the driver authors, as one option will be more appropriate in some cases than the other. -- Thanks, Sylwester -- 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: [Q] Interleaved formats on the media bus
Hi Laurent, On 02/04/2012 12:34 PM, Laurent Pinchart wrote: > On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote: >> On 02/02/2012 10:55 AM, Laurent Pinchart wrote: >>> Do all those sensors interleave the data in the same way ? This sounds >>> quite >> No, each one uses it's own interleaving method. >> >>> hackish and vendor-specific to me, I'm not sure if we should try to >>> generalize that. Maybe vendor-specific media bus format codes would be >>> the way to go. I don't expect ISPs to understand the format, they will >>> likely be configured in pass-through mode. Instead of adding explicit >>> support for all those weird formats to all ISP drivers, it might make >>> sense to add a "binary blob" media bus code to be used by the ISP. >> >> This could work, except that there is no way to match a fourcc with media >> bus code. Different fourcc would map to same media bus code, making it >> impossible for the brigde to handle multiple sensors or one sensor >> supporting multiple interleaved formats. Moreover there is a need to map >> media bus code to the MIPI-CSI data ID. What if one sensor sends "binary" >> blob with MIPI-CSI "User Define Data 1" and the other with "User Define >> Data 2" ? > > My gut feeling is that the information should be retrieved from the sensor > driver. This is all pretty vendor-specific, and adding explicit support for > such sensors to each bridge driver wouldn't be very clean. Could the bridge We have many standard pixel codes in include/linux/v4l2-mediabus.h, yet each bridge driver supports only a subset of them. I wouldn't expect a sudden need for all existing bridge drivers to support some strange interleaved image formats. > query the sensor using a subdev operation ? There is also a MIPI-CSI2 receiver in between that needs to be configured. I.e. it must know that it processes the User Defined Data 1, which implies certain pixel alignment, etc. So far a media bus pixel codes have been a base information to handle such things. >> Maybe we could create e.g. V4L2_MBUS_FMT_USER?, for each MIPI-CSI User >> Defined data identifier, but as I remember it was decided not to map >> MIPI-CSI data codes directly onto media bus pixel codes. > > Would setting the format directly on the sensor subdev be an option ? Do you mean setting a MIPI-CSI2 format ? It should work as long as the bridge driver can identify media bus code given a fourcc. I can't recall situation where a reverse lookup is necessary, i.e. struct v4l2_mbus_framefmt::code -> fourcc. This would fail since e.g. JPEG and YUV/JPEG would both correspond to User 1 format. -- Regards, Sylwester -- 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: [Q] Interleaved formats on the media bus
Hi Sylwester, Sylwester Nawrocki wrote: > On 02/04/2012 12:22 PM, Sakari Ailus wrote: >> Sylwester Nawrocki wrote: >>> On 02/01/2012 11:00 AM, Sakari Ailus wrote: I'd guess that all the ISP would do to such formats is to write them to memory since I don't see much use for either in ISPs --- both typically are output of the ISP. >>> >>> Yep, correct. In fact in those cases the sensor has complicated ISP built >>> in, >>> so everything a bridge have to do is to pass data over to user space. >>> >>> Also non-image data might need to be passed to user space as well. >> >> How does one know in the user space which part of the video buffer >> contains jpeg data and which part is yuv? Does the data contain some >> kind of header, or how is this done currently? > > There is an additional data appended to the image data. Part of it must > be retrieved out of the main DMA channel. I someway missed to mention in > the previous e-mails that the bridge is somehow retarded, probably because > of the way is has been evolving over time. That is, it originally > supported only the parallel video bus and then a MIPI-CSI2 frontend was > added. So it cannot split MIPI-CSI data channels into separate memory > buffers, AFAIK - at this stage. I think it just ignores the VC field of > the Data Identifier (DI), but it's just a guess for now. > > If you look at the S5PV210 datasheet and the MIPI-CSIS device registers, > at the end of the IO region it has 4 x ~4kiB internal buffers for > "non-image" data. These buffers must be emptied in the interrupt handler > and I'm going to need this data in user space in order to decode data > from sensors. > > Sounds like a 2-plane buffers is a way to go, one plane for interleaved > YUV/JPEG and the second one for the "metadata". > > I originally thought about a separate buffer queue at the MIPI-CSIS driver, > but it likely would have added unnecessary complication in the applications. > >> I'd be much in favour or using a separate channel ID as Guennadi asked; >> that way you could quite probably save one memory copy as well. But if >> the hardware already exists and behaves badly there's usually not much >> you can do about it. > > As I explained above I suspect that the sensor sends each image data type > on separate channels (I'm not 100% sure) but the bridge is unable to DMA > it into separate memory regions. > > Currently we have no support in V4L2 for specifying separate image data > format per MIPI-CSI2 channel. Maybe the solution is just about that - > adding support for virtual channels and a possibility to specify an image > format separately per each channel ? > Still, there would be nothing telling how the channels are interleaved :-/ _If_ the sensor sends YUV and compressed JPEG data in separate CSI-2 channels then definitely the correct way to implement this is to take this kind of setup into account in the frame format description --- we do need that quite badly. However, this doesn't really help you with your current problem, and perhaps just creating a custom format for your sensor driver is the best way to go for the time being. But. When someone attaches this kind of sensor to another CSI-2 receiver that can separate the data from different channels, I think we should start working towards for a correct solution which this driver also should support. With information on the frame format, the CSI-2 hardware could properly write the data into two separate buffers. Possibly it should provide two video nodes, but I'm not sure about that. A multi-plane buffer is another option. Cheers, -- 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: [Q] Interleaved formats on the media bus
Hi Laurent, On 02/04/2012 12:30 PM, Laurent Pinchart wrote: >> I'd be much in favour or using a separate channel ID as Guennadi asked; >> that way you could quite probably save one memory copy as well. But if >> the hardware already exists and behaves badly there's usually not much >> you can do about it. > > If I'm not mistaken, the sensor doesn't send data in separate channels but I suspect it might be sending data on separate virtual channels, but the bridge won't understand that and will just return one data plane in memory. The sensor might well send the data in one channel, I don't know myself yet. In either case we end up with a mixed data in memory, that must be parsed, which is likely best done in the user space. Also please see my previous answer to Sakari, there is some more details there. > interleaves them in a single channel (possibly with headers or fixed-size > packets - Sylwester, could you comment on that ?). That makes it pretty > difficult to do anything else than pass-through capture. I'm not entirely sure the sensor doesn't send the data in separate virtual channels. Certainly the bridge cannot DMA each channel into separate memory buffers. -- Regards, Sylwester -- 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: [Q] Interleaved formats on the media bus
Hi Sakari, On 02/04/2012 12:22 PM, Sakari Ailus wrote: > Sylwester Nawrocki wrote: >> On 02/01/2012 11:00 AM, Sakari Ailus wrote: >>> I'd guess that all the ISP would do to such formats is to write them to >>> memory since I don't see much use for either in ISPs --- both typically are >>> output of the ISP. >> >> Yep, correct. In fact in those cases the sensor has complicated ISP built in, >> so everything a bridge have to do is to pass data over to user space. >> >> Also non-image data might need to be passed to user space as well. > > How does one know in the user space which part of the video buffer > contains jpeg data and which part is yuv? Does the data contain some > kind of header, or how is this done currently? There is an additional data appended to the image data. Part of it must be retrieved out of the main DMA channel. I someway missed to mention in the previous e-mails that the bridge is somehow retarded, probably because of the way is has been evolving over time. That is, it originally supported only the parallel video bus and then a MIPI-CSI2 frontend was added. So it cannot split MIPI-CSI data channels into separate memory buffers, AFAIK - at this stage. I think it just ignores the VC field of the Data Identifier (DI), but it's just a guess for now. If you look at the S5PV210 datasheet and the MIPI-CSIS device registers, at the end of the IO region it has 4 x ~4kiB internal buffers for "non-image" data. These buffers must be emptied in the interrupt handler and I'm going to need this data in user space in order to decode data from sensors. Sounds like a 2-plane buffers is a way to go, one plane for interleaved YUV/JPEG and the second one for the "metadata". I originally thought about a separate buffer queue at the MIPI-CSIS driver, but it likely would have added unnecessary complication in the applications. > I'd be much in favour or using a separate channel ID as Guennadi asked; > that way you could quite probably save one memory copy as well. But if > the hardware already exists and behaves badly there's usually not much > you can do about it. As I explained above I suspect that the sensor sends each image data type on separate channels (I'm not 100% sure) but the bridge is unable to DMA it into separate memory regions. Currently we have no support in V4L2 for specifying separate image data format per MIPI-CSI2 channel. Maybe the solution is just about that - adding support for virtual channels and a possibility to specify an image format separately per each channel ? Still, there would be nothing telling how the channels are interleaved :-/ -- Regards, Sylwester -- 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] Adding YUV input support for OMAP3ISP driver
On Sat, Feb 4, 2012 at 12:48 PM, Gary Thomas wrote: > On 2012-01-30 10:30, Gary Thomas wrote: >> >> On 2012-01-20 05:19, Laurent Pinchart wrote: >>> >>> Hi Enrico, >>> >>> On Thursday 19 January 2012 15:17:57 Enrico wrote: On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomas wrote: > > On 2012-01-19 06:35, Gary Thomas wrote: >> >> My camera init code is attached. In the previous kernel, the I2C bus >> was >> probed implicitly when I initialized the OMAP3ISP. I thought I >> remembered some discussion about how that worked (maybe changing), so >> this is probably >> where the problem starts. >> >> If you have an example, I can check my setup against it. > > > Note: I reworked how the sensor+I2C was initialized to be > omap3_init_camera(&cobra3530p73_isp_platform_data); > > > omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs->subdevs[0] > .i2c_adapter_id, 400, > > cobra3530p73_isp_platform_data.subdevs->subdevs[0].board_info, 1); > > The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). >>> >>> >>> I totally understand your feeling. >>> >>> I'd like to get YUV support integrated in the OMAP3 ISP driver. However, >>> I >>> have no YUV image source hardware, so I can only review the patches but >>> not >>> test them. >>> >>> If someone can rebase the existing patches on top of >>> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- >>> omap3isp-yuv and test them, then I'll review the result. >>> >> >> The attached patches produce a working setup against Laurent's tree above. >> That said, I don't recall exactly where which changes came from (I'm old >> school and not very git savvy, sorry). I've CC'd all the folks I think >> provided at least part of these changes. Perhaps we can all work together >> to come up with a proper set of patches which can be pushed upstream >> for this, once and for all? >> >> Thanks >> > > Ping! Is no one but me interested in getting these changes into > the mainline? I am interested, i didn't have time to test it but i will for sure. And i think it's important to test non bt656/yuv sensors too, but i have no hardware for that. Enrico -- 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] media, adp1653: Remove unneeded include of version.h from drivers/media/video/adp1653.c
Hi Jesper, On Thu, Feb 02, 2012 at 10:15:06PM +0100, Jesper Juhl wrote: > Signed-off-by: Jesper Juhl > --- > drivers/media/video/adp1653.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > compile tested only. > > diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c > index 12eedf4..badbdb6 100644 > --- a/drivers/media/video/adp1653.c > +++ b/drivers/media/video/adp1653.c > @@ -35,7 +35,6 @@ > #include > #include > #include > -#include > #include > #include Thanks for the patch! I've applied it to my tree --- plus removing extra module.h at the same time. -- 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] Adding YUV input support for OMAP3ISP driver
On 2012-01-30 10:30, Gary Thomas wrote: On 2012-01-20 05:19, Laurent Pinchart wrote: Hi Enrico, On Thursday 19 January 2012 15:17:57 Enrico wrote: On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomas wrote: On 2012-01-19 06:35, Gary Thomas wrote: My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(&cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs->subdevs[0] .i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs->subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). I totally understand your feeling. I'd like to get YUV support integrated in the OMAP3 ISP driver. However, I have no YUV image source hardware, so I can only review the patches but not test them. If someone can rebase the existing patches on top of http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-yuv and test them, then I'll review the result. The attached patches produce a working setup against Laurent's tree above. That said, I don't recall exactly where which changes came from (I'm old school and not very git savvy, sorry). I've CC'd all the folks I think provided at least part of these changes. Perhaps we can all work together to come up with a proper set of patches which can be pushed upstream for this, once and for all? Thanks Ping! Is no one but me interested in getting these changes into the mainline? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Rob, Clark, Rob wrote: > On Mon, Jan 30, 2012 at 4:01 PM, Sakari Ailus wrote: >> >>> So to summarize I understand your constraints - gpu drivers have worked >>> like v4l a few years ago. The thing I'm trying to achieve with this >>> constant yelling is just to raise awereness for these issues so that >>> people aren't suprised when drm starts pulling tricks on dma_bufs. >> >> I think we should be able to mark dma_bufs non-relocatable so also DRM can >> work with these buffers. Or alternatively, as Laurent proposed, V4L2 be >> prepared for moving the buffers around. Are there other reasons to do so >> than paging them out of system memory to make room for something else? > > fwiw, from GPU perspective, the DRM device wouldn't be actively > relocating buffers just for the fun of it. I think it is more that we > want to give the GPU driver the flexibility to relocate when it really > needs to. For example, maybe user has camera app running, then puts > it in the background and opens firefox which tries to allocate a big > set of pixmaps putting pressure on GPU memory.. > > I guess the root issue is who is doing the IOMMU programming for the > camera driver. I guess if this is something built in to the camera > driver then when it calls dma_buf_map() it probably wants some hint > that the backing pages haven't moved so in the common case (ie. buffer > hasn't moved) it doesn't have to do anything expensive. > > On omap4 v4l2+drm example I have running, it is actually the DRM > driver doing the "IOMMU" programming.. so v4l2 camera really doesn't > need to care about it. (And the IOMMU programming here is pretty This part sounds odd to me. Well, I guess it _could_ be done that way, but the ISP IOMMU could be as well different as the one in DRM. That's the case on OMAP 3, for example. > fast.) But I suppose this maybe doesn't represent all cases. I > suppose if a camera didn't really sit behind an IOMMU but uses > something more like a DMA descriptor list would want to know if it > needed to regenerate it's descriptor list. Or likewise if camera has > an IOMMU that isn't really using the IOMMU framework (although maybe > that is easier to solve). But I think a hint returned from > dma_buf_map() would do the job? An alternative to IOMMU I think in practice would mean CMA-allocated buffers. I need to think about this a bit and understand how this would really work to properly comment this. For example, how does one mlock() something that isn't mapped to process memory --- think of a dma buffer not mapped to the user space process address space? Cheers, -- 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: [Q] Interleaved formats on the media bus
Hi Guennadi, On Thursday 02 February 2012 12:00:57 Guennadi Liakhovetski wrote: > On Thu, 2 Feb 2012, Laurent Pinchart wrote: > > Do all those sensors interleave the data in the same way ? This sounds > > quite hackish and vendor-specific to me, I'm not sure if we should try to > > generalize that. Maybe vendor-specific media bus format codes would be > > the way to go. I don't expect ISPs to understand the format, they will > > likely be configured in pass-through mode. Instead of adding explicit > > support for all those weird formats to all ISP drivers, it might make > > sense to add a "binary blob" media bus code to be used by the ISP. > > Yes, I agree, that those formats will be just forwarded as is by ISPs, but > the user-space wants to know the contents, so, it might be more useful to > provide information about specific components, even if their packing > layout cannot be defined in a generic way with offsets and sizes. Even > saying "you're getting formats YUYV and JPEG in vendor-specific packing > #N" might be more useful, than just "vendor-specific format #N". That's right. A single media bus code might not be the best option indeed. Vendor-specific blob codes (and 4CCs) then ? -- 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: [Q] Interleaved formats on the media bus
Hi Sylwester, On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote: > On 02/02/2012 10:55 AM, Laurent Pinchart wrote: > > Do all those sensors interleave the data in the same way ? This sounds > > quite > No, each one uses it's own interleaving method. > > > hackish and vendor-specific to me, I'm not sure if we should try to > > generalize that. Maybe vendor-specific media bus format codes would be > > the way to go. I don't expect ISPs to understand the format, they will > > likely be configured in pass-through mode. Instead of adding explicit > > support for all those weird formats to all ISP drivers, it might make > > sense to add a "binary blob" media bus code to be used by the ISP. > > This could work, except that there is no way to match a fourcc with media > bus code. Different fourcc would map to same media bus code, making it > impossible for the brigde to handle multiple sensors or one sensor > supporting multiple interleaved formats. Moreover there is a need to map > media bus code to the MIPI-CSI data ID. What if one sensor sends "binary" > blob with MIPI-CSI "User Define Data 1" and the other with "User Define > Data 2" ? My gut feeling is that the information should be retrieved from the sensor driver. This is all pretty vendor-specific, and adding explicit support for such sensors to each bridge driver wouldn't be very clean. Could the bridge query the sensor using a subdev operation ? > Maybe we could create e.g. V4L2_MBUS_FMT_USER?, for each MIPI-CSI User > Defined data identifier, but as I remember it was decided not to map > MIPI-CSI data codes directly onto media bus pixel codes. Would setting the format directly on the sensor subdev be an option ? -- 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: [Q] Interleaved formats on the media bus
Hi Sakari, On Saturday 04 February 2012 13:22:21 Sakari Ailus wrote: > Sylwester Nawrocki wrote: > > On 02/01/2012 11:00 AM, Sakari Ailus wrote: > >> I'd guess that all the ISP would do to such formats is to write them to > >> memory since I don't see much use for either in ISPs --- both typically > >> are > >> output of the ISP. > > > > Yep, correct. In fact in those cases the sensor has complicated ISP built > > in, so everything a bridge have to do is to pass data over to user space. > > > > Also non-image data might need to be passed to user space as well. > > How does one know in the user space which part of the video buffer > contains jpeg data and which part is yuv? Does the data contain some > kind of header, or how is this done currently? > > I'd be much in favour or using a separate channel ID as Guennadi asked; > that way you could quite probably save one memory copy as well. But if > the hardware already exists and behaves badly there's usually not much > you can do about it. If I'm not mistaken, the sensor doesn't send data in separate channels but interleaves them in a single channel (possibly with headers or fixed-size packets - Sylwester, could you comment on that ?). That makes it pretty difficult to do anything else than pass-through capture. -- 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: [Q] Interleaved formats on the media bus
Hi Sylwester, Sylwester Nawrocki wrote: > On 02/01/2012 11:00 AM, Sakari Ailus wrote: >> I'd guess that all the ISP would do to such formats is to write them to >> memory since I don't see much use for either in ISPs --- both typically are >> output of the ISP. > > Yep, correct. In fact in those cases the sensor has complicated ISP built in, > so everything a bridge have to do is to pass data over to user space. > > Also non-image data might need to be passed to user space as well. How does one know in the user space which part of the video buffer contains jpeg data and which part is yuv? Does the data contain some kind of header, or how is this done currently? I'd be much in favour or using a separate channel ID as Guennadi asked; that way you could quite probably save one memory copy as well. But if the hardware already exists and behaves badly there's usually not much you can do about it. Cheers, -- 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: Current drivers for Hauppauge NOVA-S Plus broken (?)
Am Dienstag, den 31.01.2012, 12:39 +0100 schrieb Jürgen Hein: > Hallo, > > with the current drivers from media_build_experimental for hauppauge > NOVA-S Plus (Conexant 2388x (bt878 successor) support (VIDEO_CX88) > cx8800...)does this here not more. Picture and sound with significant > dropouts. > > With the drivers of 11.2011 is working properly. > > I have something wrong? Or why do I get no answer? > Regards -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/15] mm: mmzone: MIGRATE_CMA migration type added
2012/2/3 Michal Nazarewicz : >>> +static inline bool migrate_async_suitable(int migratetype) > > On Fri, 03 Feb 2012 15:19:54 +0100, Hillf Danton wrote: >> >> Just nitpick, since the helper is not directly related to what async >> means, >> how about migrate_suitable(int migrate_type) ? > > > I feel current name is better suited since it says that it's OK to scan this > block if it's an asynchronous compaction run. > The input is the migrate type of page considered, and the async is only one of the modes that compaction should be carried out. Plus the helper is also used in other cases where async is entirely not concerned. That said, the naming is not clear, if not misleading. -- 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
