[Query] About NV12 pixel format support in a subdevice
Hi everyone, I'll like to request for your advice on adding NV12 support for my omap4iss camera driver, which is done after the resizer block in the OMAP4 ISS ISP (Imaging SubSystem Image Signal Processor). So, the problem with that, is that I don't see a match for V4L2_PIX_FMT_NV12 pixel format in "enum v4l2_mbus_pixelcode". Now, I wonder what's the best way to describe the format... Is this correct? V4L2_MBUS_FMT_NV12_1X12 Because every pixel is comprised of a 8-bit Y element, and it's UV components are grouped in pairs with the next horizontal pixel, whcih in combination are represented in 8 bits... So it's like that UV component per-pixel is 4-bits. Not exactly, but it's the best representation I could think of to simplify things. I mean, the HW itself writes in memory to 2 contiguous buffers, so there's 2 separate DMA writes. I have to program 2 starting addresses, which, in an internal non-v4l2-subdev implementation, I have been programming like this: paddr = start of 32-byte aligned physical address to store buffer x = width y = height Ysize = (x * y) UVsize = (x / 2) * y Total size = Ysize + UVsize Ystart = paddr UVstart = (paddr + Ysize) But, in the media controller framework, i have a single DMA output pad, that creates a v4l2 capture device node, and i'll be queueing a single buffer. Any advice on how to address this properly? Does anyone has/had a similar need? Regards, Sergio -- 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: [Query] About NV12 pixel format support in a subdevice
Hi Sergio On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > Hi everyone, > > I'll like to request for your advice on adding NV12 support for my omap4iss > camera driver, which is done after the resizer block in the OMAP4 ISS ISP > (Imaging SubSystem Image Signal Processor). > > So, the problem with that, is that I don't see a match for V4L2_PIX_FMT_NV12 > pixel format in "enum v4l2_mbus_pixelcode". > > Now, I wonder what's the best way to describe the format... Is this correct? > > V4L2_MBUS_FMT_NV12_1X12 > > Because every pixel is comprised of a 8-bit Y element, and it's UV components > are grouped in pairs with the next horizontal pixel, whcih in combination > are represented in 8 bits... So it's like that UV component per-pixel is > 4-bits. > Not exactly, but it's the best representation I could think of to > simplify things. Do I understand it right, that your resizer is sending the data to the DMA engine interleaved, not Y and UV planes separately, and it's only the DMA engine, that is separating the planes, when writing to buffers? In such a case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera does. Thanks Guennadi > I mean, the HW itself writes in memory to 2 contiguous buffers, so there's 2 > separate DMA writes. I have to program 2 starting addresses, which, in an > internal non-v4l2-subdev implementation, I have been programming like this: > > paddr = start of 32-byte aligned physical address to store buffer > x = width > y = height > > Ysize = (x * y) > UVsize = (x / 2) * y > Total size = Ysize + UVsize > > Ystart = paddr > UVstart = (paddr + Ysize) > > But, in the media controller framework, i have a single DMA output pad, that > creates a v4l2 capture device node, and i'll be queueing a single buffer. > > Any advice on how to address this properly? Does anyone has/had a similar > need? > > Regards, > Sergio > -- > 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 > --- 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: [Query] About NV12 pixel format support in a subdevice
Hi Guennadi, Thanks for your reply. On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski wrote: > Hi Sergio > > On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > >> Hi everyone, >> >> I'll like to request for your advice on adding NV12 support for my omap4iss >> camera driver, which is done after the resizer block in the OMAP4 ISS ISP >> (Imaging SubSystem Image Signal Processor). >> >> So, the problem with that, is that I don't see a match for V4L2_PIX_FMT_NV12 >> pixel format in "enum v4l2_mbus_pixelcode". >> >> Now, I wonder what's the best way to describe the format... Is this correct? >> >> V4L2_MBUS_FMT_NV12_1X12 >> >> Because every pixel is comprised of a 8-bit Y element, and it's UV components >> are grouped in pairs with the next horizontal pixel, whcih in combination >> are represented in 8 bits... So it's like that UV component per-pixel is >> 4-bits. >> Not exactly, but it's the best representation I could think of to >> simplify things. > > Do I understand it right, that your resizer is sending the data to the DMA > engine interleaved, not Y and UV planes separately, and it's only the DMA > engine, that is separating the planes, when writing to buffers? In such a > case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have > the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera > does. No, it actually has 2 register sets for specifying the start address for each plane. So, I have one register that I program with "Y-start" address, and another register that I program with "UV-start" address. For both cases, you control the byte offset between every begin of each line. So, in theory, you could save it interleaved in memory if you want, or in 2 separate buffers depending on how you program the address/offset pair. Regards, Sergio > > Thanks > Guennadi > >> I mean, the HW itself writes in memory to 2 contiguous buffers, so there's 2 >> separate DMA writes. I have to program 2 starting addresses, which, in an >> internal non-v4l2-subdev implementation, I have been programming like this: >> >> paddr = start of 32-byte aligned physical address to store buffer >> x = width >> y = height >> >> Ysize = (x * y) >> UVsize = (x / 2) * y >> Total size = Ysize + UVsize >> >> Ystart = paddr >> UVstart = (paddr + Ysize) >> >> But, in the media controller framework, i have a single DMA output pad, that >> creates a v4l2 capture device node, and i'll be queueing a single buffer. >> >> Any advice on how to address this properly? Does anyone has/had a similar >> need? >> >> Regards, >> Sergio >> -- >> 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 >> > > --- > 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: [Query] About NV12 pixel format support in a subdevice
On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > Hi Guennadi, > > Thanks for your reply. > > On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski > wrote: > > Hi Sergio > > > > On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > > > >> Hi everyone, > >> > >> I'll like to request for your advice on adding NV12 support for my omap4iss > >> camera driver, which is done after the resizer block in the OMAP4 ISS ISP > >> (Imaging SubSystem Image Signal Processor). > >> > >> So, the problem with that, is that I don't see a match for > >> V4L2_PIX_FMT_NV12 > >> pixel format in "enum v4l2_mbus_pixelcode". > >> > >> Now, I wonder what's the best way to describe the format... Is this > >> correct? > >> > >> V4L2_MBUS_FMT_NV12_1X12 > >> > >> Because every pixel is comprised of a 8-bit Y element, and it's UV > >> components > >> are grouped in pairs with the next horizontal pixel, whcih in combination > >> are represented in 8 bits... So it's like that UV component per-pixel is > >> 4-bits. > >> Not exactly, but it's the best representation I could think of to > >> simplify things. > > > > Do I understand it right, that your resizer is sending the data to the DMA > > engine interleaved, not Y and UV planes separately, and it's only the DMA > > engine, that is separating the planes, when writing to buffers? In such a > > case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have > > the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera > > does. > > No, it actually has 2 register sets for specifying the start address > for each plane. Sorry, what "it?" The DMA engine, right? Then it still looks pretty similar to the CEU case to me: it also can either write the data interleaved into RAM and produce a YUV420 format, or convert to NV12. Which one to do is decided by the format, configured on the video device node by the driver. Thanks Guennadi > So, I have one register that I program with "Y-start" address, and > another register > that I program with "UV-start" address. > > For both cases, you control the byte offset between every begin of each line. > > So, in theory, you could save it interleaved in memory if you want, or > in 2 separate > buffers depending on how you program the address/offset pair. > > Regards, > Sergio > > > > > Thanks > > Guennadi > > > >> I mean, the HW itself writes in memory to 2 contiguous buffers, so there's > >> 2 > >> separate DMA writes. I have to program 2 starting addresses, which, in an > >> internal non-v4l2-subdev implementation, I have been programming like this: > >> > >> paddr = start of 32-byte aligned physical address to store buffer > >> x = width > >> y = height > >> > >> Ysize = (x * y) > >> UVsize = (x / 2) * y > >> Total size = Ysize + UVsize > >> > >> Ystart = paddr > >> UVstart = (paddr + Ysize) > >> > >> But, in the media controller framework, i have a single DMA output pad, > >> that > >> creates a v4l2 capture device node, and i'll be queueing a single buffer. > >> > >> Any advice on how to address this properly? Does anyone has/had a similar > >> need? > >> > >> Regards, > >> Sergio > >> -- > >> 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 > >> > > > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > --- 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: [Query] About NV12 pixel format support in a subdevice
Hi Guennadi, On Sat, Apr 7, 2012 at 4:51 PM, Guennadi Liakhovetski wrote: > On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > >> Hi Guennadi, >> >> Thanks for your reply. >> >> On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski >> wrote: >> > Hi Sergio >> > >> > On Sat, 7 Apr 2012, Aguirre, Sergio wrote: >> > >> >> Hi everyone, >> >> >> >> I'll like to request for your advice on adding NV12 support for my >> >> omap4iss >> >> camera driver, which is done after the resizer block in the OMAP4 ISS ISP >> >> (Imaging SubSystem Image Signal Processor). >> >> >> >> So, the problem with that, is that I don't see a match for >> >> V4L2_PIX_FMT_NV12 >> >> pixel format in "enum v4l2_mbus_pixelcode". >> >> >> >> Now, I wonder what's the best way to describe the format... Is this >> >> correct? >> >> >> >> V4L2_MBUS_FMT_NV12_1X12 >> >> >> >> Because every pixel is comprised of a 8-bit Y element, and it's UV >> >> components >> >> are grouped in pairs with the next horizontal pixel, whcih in combination >> >> are represented in 8 bits... So it's like that UV component per-pixel is >> >> 4-bits. >> >> Not exactly, but it's the best representation I could think of to >> >> simplify things. >> > >> > Do I understand it right, that your resizer is sending the data to the DMA >> > engine interleaved, not Y and UV planes separately, and it's only the DMA >> > engine, that is separating the planes, when writing to buffers? In such a >> > case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have >> > the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera >> > does. >> >> No, it actually has 2 register sets for specifying the start address >> for each plane. > > Sorry, what "it?" The DMA engine, right? Then it still looks pretty > similar to the CEU case to me: it also can either write the data > interleaved into RAM and produce a YUV420 format, or convert to NV12. > Which one to do is decided by the format, configured on the video device > node by the driver. Hmm, ok. I think I know what you mean now, sorry. So you're saying I should really use, say: V4L2_MBUS_FMT_YUYV8_1_5X8 as subdevice format, and let the v4l2 device output node either use: - V4L2_PIX_FMT_NV12 or - V4L2_PIX_FMT_YUV420 depending on how I want the DMA engine to organize the data. Did I got your point correctly? Thanks for your patience. Regards, Sergio > > Thanks > Guennadi > >> So, I have one register that I program with "Y-start" address, and >> another register >> that I program with "UV-start" address. >> >> For both cases, you control the byte offset between every begin of each line. >> >> So, in theory, you could save it interleaved in memory if you want, or >> in 2 separate >> buffers depending on how you program the address/offset pair. >> >> Regards, >> Sergio >> >> > >> > Thanks >> > Guennadi >> > >> >> I mean, the HW itself writes in memory to 2 contiguous buffers, so >> >> there's 2 >> >> separate DMA writes. I have to program 2 starting addresses, which, in an >> >> internal non-v4l2-subdev implementation, I have been programming like >> >> this: >> >> >> >> paddr = start of 32-byte aligned physical address to store buffer >> >> x = width >> >> y = height >> >> >> >> Ysize = (x * y) >> >> UVsize = (x / 2) * y >> >> Total size = Ysize + UVsize >> >> >> >> Ystart = paddr >> >> UVstart = (paddr + Ysize) >> >> >> >> But, in the media controller framework, i have a single DMA output pad, >> >> that >> >> creates a v4l2 capture device node, and i'll be queueing a single buffer. >> >> >> >> Any advice on how to address this properly? Does anyone has/had a similar >> >> need? >> >> >> >> Regards, >> >> Sergio >> >> -- >> >> 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 >> >> >> > >> > --- >> > Guennadi Liakhovetski, Ph.D. >> > Freelance Open-Source Software Developer >> > http://www.open-technology.de/ >> > > --- > 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: [Query] About NV12 pixel format support in a subdevice
On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > Hi Guennadi, > > On Sat, Apr 7, 2012 at 4:51 PM, Guennadi Liakhovetski > wrote: > > On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > > > >> Hi Guennadi, > >> > >> Thanks for your reply. > >> > >> On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski > >> wrote: > >> > Hi Sergio > >> > > >> > On Sat, 7 Apr 2012, Aguirre, Sergio wrote: > >> > > >> >> Hi everyone, > >> >> > >> >> I'll like to request for your advice on adding NV12 support for my > >> >> omap4iss > >> >> camera driver, which is done after the resizer block in the OMAP4 ISS > >> >> ISP > >> >> (Imaging SubSystem Image Signal Processor). > >> >> > >> >> So, the problem with that, is that I don't see a match for > >> >> V4L2_PIX_FMT_NV12 > >> >> pixel format in "enum v4l2_mbus_pixelcode". > >> >> > >> >> Now, I wonder what's the best way to describe the format... Is this > >> >> correct? > >> >> > >> >> V4L2_MBUS_FMT_NV12_1X12 > >> >> > >> >> Because every pixel is comprised of a 8-bit Y element, and it's UV > >> >> components > >> >> are grouped in pairs with the next horizontal pixel, whcih in > >> >> combination > >> >> are represented in 8 bits... So it's like that UV component per-pixel > >> >> is 4-bits. > >> >> Not exactly, but it's the best representation I could think of to > >> >> simplify things. > >> > > >> > Do I understand it right, that your resizer is sending the data to the > >> > DMA > >> > engine interleaved, not Y and UV planes separately, and it's only the DMA > >> > engine, that is separating the planes, when writing to buffers? In such a > >> > case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have > >> > the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera > >> > does. > >> > >> No, it actually has 2 register sets for specifying the start address > >> for each plane. > > > > Sorry, what "it?" The DMA engine, right? Then it still looks pretty > > similar to the CEU case to me: it also can either write the data > > interleaved into RAM and produce a YUV420 format, or convert to NV12. > > Which one to do is decided by the format, configured on the video device > > node by the driver. > > Hmm, ok. I think I know what you mean now, sorry. > > So you're saying I should really use, say: V4L2_MBUS_FMT_YUYV8_1_5X8 as > subdevice format, and let the v4l2 device output node either use: > > - V4L2_PIX_FMT_NV12 > or > - V4L2_PIX_FMT_YUV420 > > depending on how I want the DMA engine to organize the data. > > Did I got your point correctly? Yes, that's what I meant. Sorry for not explaining properly:-) 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
