Hi Javier, On 18-07-31 14:52, Javier Martinez Canillas wrote: > Hi Marco, > > On 07/31/2018 02:36 PM, Marco Felsch wrote: > > [snip] > > >> > >> Yes, another thing that patch 19/22 should take into account is DTs that > >> don't have input connectors defined. So probably TVP5150_PORT_YOUT should > >> be 0 instead of TVP5150_PORT_NUM - 1 as is the case in the current patch. > >> > >> In other words, it should work both when input connectors are defined in > >> the DT and when these are not defined and only an output port is defined. > > > > Yes, it would be a approach to map the output port dynamicaly to the > > highest port number. I tried to keep things easy by a static mapping. > > Maybe a follow up patch can change this behaviour. > > > > Anyway, input connectors aren't required. There must be at least one > > port child node with a correct port-number in the DT. > > > > Yes, that was my point. But your patch uses the port child reg property as > the index for the struct device_node *endpoints[TVP5150_PORT_NUM] array. > > If there's only one port child (for the output) then the DT binding says > that the reg property isn't required, so this will be 0 and your patch will > wrongly map it to TVP5150_PORT_AIP1A. That's why I said that the output port > should be the first one in your enum tvp5150_ports and not the last one. Yes, now I got you. I implemted this in such a way in my first apporach. But at the moment I don't know why I changed this. Maybe to keep the decoder->input number in sync with the em28xx devices, which will set the port by the s_routing() callback. Let me check this. Best Regards, Marco > > Regards, > > Marco > > > > Best regards, -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
