On 03/10/2016 01:12 AM, Steve Longerbeam wrote: > On 03/09/2016 02:44 PM, Tim Harvey wrote: >> On Tue, Mar 8, 2016 at 6:06 PM, Steve Longerbeam >> <steve_longerbeam@xxxxxxxxxx> wrote: >>> On 03/07/2016 08:19 AM, Tim Harvey wrote: >> <snip> >>> >>> Hi Tim, good to hear it works for you on the Ventana boards. >>> >>> I've just pushed some more commits to the mx6-media-staging branch that >>> get the drivers/media/i2c/adv7180.c subdev working with the imx6 capture >>> backend. Images look perfect when switching to UYVY8_2X8 mbus code instead >>> of YUYV8_2X8. But I'm holding off on that change because this subdev is used >>> by Renesas targets and would likely corrupt captured images for those >>> targets. But I believe UYVY is the correct transmit order according to the >>> BT.656 standard. >>> >>> Another thing that should also be changed in drivers/media/i2c/adv7180.c >>> is the field type. It should be V4L2_FIELD_SEQ_TB for NTSC and V4L2_FIELD_SEQ_BT >>> for PAL. >>> >>> Steve >>> >>> >> Steve, >> >> with your latest patches, I'm crashing with an null-pointer-deref in >> adv7180_set_pad_format. What is your kernel config for >> CONFIG_MEDIA_CONTROLLER and CONFIG_VIDEO_V4L2_SUBDEV_API? > > Right, I thought I fixed that, I was passing a NULL pad_cfg for > TRY_FORMAT, but that was fixed. Maybe you fetched a version > of mx6-media-staging while I was in the middle of debugging? > Try fetching again. > > I tried with both CONFIG_MEDIA_CONTROLLER and > CONFIG_VIDEO_V4L2_SUBDEV_API enabled and both disabled, and > I don't get the null deref in adv7180_set_pad_format. > > >> >> Your tree contains about 16 or so patches on top of linux-media for >> imx6 capture. Are you close to the point where you will be posting a >> patch series? If so, please CC me for testing with the adv7180 sensor. > > I guess I can try posting a series again, but there will likely be push-back from > Pengutronix. They have their own video capture driver for imx6. Last I heard (a while ago!) > their version did not implement scaling, colorspace conversion, or image rotation via > the IC. Instead their driver sends raw camera frames directly to memory, and image > conversion is carried out by separate mem2mem device. Our capture driver does > image conversion (scaling, CSC, and rotation) natively using the IC pre-processing channel. > We also have a mem2mem device that does conversion using IC post-processing, > which I have included in mx6-media-staging. > > Also IIRC they did some pretty slick stuff with a video bus multiplexer subdev, which > can multiplex video from different sensors either using the internal mux in the SoC, > or can control an external mux via gpio. Our driver only supports the internal mux, > and does it with a platform data function. > > But like I said, I don't what the latest status is of the Pengutronix video capture support. > > Btw, I just pushed an update of mx6-media-staging that implements vidioc_[gs]_selection. Steve & Pengutronix, I would be happy to add drivers to staging, either Steve's, Pengutronix or both. The i.mx6 is quite popular and the lack of video capture support in the kernel is a big stumbling block, especially given the pile of crap that freescale provides. Having decent code in the kernel will help progress a lot I hope. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
