Hi Steve and Philipp, 2017-01-11 0:52 GMT+01:00 Steve Longerbeam <steve_longerbeam@xxxxxxxxxx>: > > > On 01/09/2017 04:15 PM, Steve Longerbeam wrote: >> >> Hi Philipp, >> >> >> On 01/09/2017 11:43 AM, Philipp Zabel wrote: >> >> >> <snip> >>> >>> One is the amount and organization of subdevices/media entities visible >>> to userspace. The SMFCs should not be user controllable subdevices, but >>> can be implicitly enabled when a CSI is directly linked to a camif. >> >> >> I agree the SMFC could be folded into the CSI, but I see at least one >> issue. >> >> From the dot graph you'll see that the PRPVF entity can receive directly >> from the CSI, or indirectly via the SMFC. If the SMFC entity were folded >> into the CSI entity, there would have to be a "direct to PRPVF" output pad >> and a "indirect via SMFC" output pad and I'm not sure how that info would >> be conveyed to the user. With a SMFC entity those pipelines are explicit. > > > In summary here, unless you have strong objection I'd prefer to keep a > distinct SMFC entity. It makes the pipelines more clear to the user, and it > better models the IPU internals. > >> >>> Also I'm not convinced the 1:1 mapping of IC task to subdevices is the >>> best choice. It is true that the three tasks can be enabled separately, >>> but to my understanding, the PRP ENC and PRP VF tasks share a single >>> input channel. Shouldn't this be a single PRP subdevice with one input >>> and two (VF, ENC) outputs? >> >> >> Since the VDIC sends its motion compensated frames to the PRP VF task, >> I've created the PRPVF entity solely for motion compensated de-interlace >> support. I don't really see any other use for the PRPVF task except for >> motion compensated de-interlace. >> >> So really, the PRPVF entity is a combination of the VDIC and PRPVF >> subunits. >> >> So looking at link_setup() in imx-csi.c, you'll see that when the CSI is >> linked >> to PRPVF entity, it is actually sending to IPU_CSI_DEST_VDIC. >> >> But if we were to create a VDIC entity, I can see how we could then >> have a single PRP entity. Then if the PRP entity is receiving from the >> VDIC, >> the PRP VF task would be activated. >> >> Another advantage of creating a distinct VDIC entity is that frames could >> potentially be routed directly from the VDIC to camif, for >> motion-compensated >> frame capture only with no scaling/CSC. I think that would be IDMAC >> channel >> 5, we've tried to get that pipeline to work in the past without success. >> That's >> mainly why I decided not to attempt it and instead fold VDIC into PRPVF >> entity. >> >> > > Here also, I'd prefer to keep distinct PRPENC and PRPVF entities. You are > correct > that PRPENC and PRPVF do share an input channel (the CSIs). But the PRPVF > has an additional input channel from the VDIC, and since my PRPVF entity > roles > up the VDIC internally, it is actually receiving from the VDIC channel. > > So unless you think we should have a distinct VDIC entity, I would like to > keep this > the way it is. > > Steve > That is exactly my thought. I was wondering if VDIC could be an independent entity, as it could also be used as a combiner if one adds the channels... What do you think about that ? JM PS: My phone sent the mail in HTML, again, sorry for the double mail, again... -- 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
