Hi Steve, Am Dienstag, den 09.09.2014, 09:12 -0700 schrieb Steve Longerbeam: > Hi Jean-Michel, > > > On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: > > 2014-08-27 16:23 GMT+02:00 Steve Longerbeam <steve_longerbeam@xxxxxxxxxx>: > > > >> Hi Jean-Michel, Phillip, > > Hi Steve, > > > >> I've done some work on Philipp's June 12 patchset, converting > >> the CSI driver to a CSI subdev entity, and fixing some issues here > >> and there. This June 12 patchset doesn't appear to be a fully working > >> driver, Phillip correct me if I am wrong. I can post this work as it > >> exists, it is incomplete but compiles. > > Dos it compile against a 3.17-rc3 kernel :) ? > > No, not anymore, the original posted driver was against 3.16 IIRC. > > > > >> I've also worked out what I think is a workable video pipeline graph for i.MX, > >> suitable for defining the entities, pads, and links. Unfortunately I haven't > >> been able to spend as much time as I'd like on it. > > This is very interesting, do you have written this somewhere ? > > Yes, I'll try to find some time to create a pdf image. I'd be very interested in this, too. I have in the meantime started to implement everything that has a source or destination selector in the Frame Synchronization Unit (FSU) as media entity. I wonder which of these parts should reasonably be unified into a single entity: CSI0 CSI1 SMFC0 SMFC1 SMFC2 SMFC3 IC preprocessor (input to VF and ENC, if I understood correctly) IC viewfinder task (scaling, csc) IC encoding task IC post processing task IRT viewfinder task (rotation) IRT encoding task IRT post processing task VDIC (deinterlacing, combining) (and probably some entry for DP/DC/DMFC for the direct viewfinder path) I suppose the SMFC channels need to be separate because they can belong to different pipelines (and each entity can only belong to one). The three IC task entities could probably be combined with their corresponding IRT task entity somehow, but that would be at the cost of not being able to tell the kernel whether to rotate before or after scaling, which might be useful when handling chroma subsampled formats. I have put my current state up here: git://git.pengutronix.de/git/pza/linux.git test/nitrogen6x-ipu-media So far I've captured video through the SMFC on a Nitrogen6X board with OV5652 parallel camera with this. > >> The complete driver I posted to the list does have some minor issues > >> mostly suggested by Hans Verkuil (switch to new selection API instead > >> of cropping API for example). It is a full featured driver but it does not > >> implement the media device framework, i.e. user does not have direct > >> control of the video pipeline, rather the driver chooses the pipeline based > >> on the traditional inputs from user (video format and controls). > >> > >> If there is interest I can submit another version of the traditional driver > >> to resolve the issues. But media device is a major rework, so I don't > >> know whether it would make sense to start from the traditional driver > >> and then implement media device on top later, since media device > >> is almost a complete rewrite. > > I, at least, am interested by this driver, even in its "traditionnal" > > form :). If you don't want to submit it directly because this is not > > using media controller, this is ok, you can provide me a git repo in > > order to get it, or send a patchset. > > I think I'll follow Hans' proposal and submit it again to media-tree as > a staging driver. I'm not too fond of adding a staging driver that we know will have to be replaced. Maybe we could work together to get a media entity based version up to speed? regards Philipp -- 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
