Hi, On Tue, Jun 13, 2017 at 06:05:57PM +0800, Chen-Yu Tsai wrote: > > That's not true. DE1's can output to several TCONs (or rather, TCONs > > can select multiple engines as their input). The A31 for example is in > > this case. > > Actually that's not true. The TCON is bound to the backend. I don't see > any controls for muxing that. So the TCON-backend search routine is very > simple for DE1. The frontends are free to feed either backend though. I think it does, look at the lower bits of TCON0_CTL_REG and TCON1_CTL_REG in the A31 datasheet. It clearly seems used to control from which DE you fetch your data from, and you have both options. > >> For example, if we enabled mixer0, tcon0 and tcon1, tcon1 shouldn't > >> be bound at all. However in BFS situation tcon1 will also be bound > >> and then fail to be bound if the backward engine searching is fixed. > > > > Short term view: we shouldn't be in that case in the first place. > > Long term view: there's no reason it shouldn't work. > > Maybe I missed something? TCONs and everything before them should always > be enabled. There's no reason not to. This is especially true for TCON0 > which holds the mux register on some SoCs. If we're not able to use anything connected to TCON1, disabling it still seems like a good stop-gap measure. > About Maxime's long term view: there's no reason we can't just silently > ignore a component if its supposed companion is missing, like a TCON > missing its backend, or the other way around. It's a bit more complicated than that. TCON0 is probably mandatory, and even if TCON1 is missing, we can entirely route around it in hardware, and I think it's the case for all the stages in our pipelines. There's no reason we could not operate that way. But this is clearly something that we should aim for, not something that needs to be done today. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
