On Wed, Oct 15, 2025 at 05:14:02PM +0800, Liu Ying wrote: > On 10/14/2025, Marek Vasut wrote: > > On 10/14/25 5:11 PM, Frank Li wrote: > >> On Tue, Oct 14, 2025 at 04:03:37PM +0200, Marek Vasut wrote: > >>> On 10/13/25 6:56 PM, Frank Li wrote: > >>>> On Sat, Oct 11, 2025 at 06:51:20PM +0200, Marek Vasut wrote: > >>>>> Rework dc_subdev_get_id() to drop ARRAY_SIZE() use and use empty > >>>>> trailing > >>>>> entry in each ID look up array instead. This allows passing of those > >>>>> arrays > >>>>> around as OF match data, which will be useful when using this pipeline > >>>>> on > >>>>> i.MX95, which has different address-to-ID mapping. > >>>>> > >>>>> Signed-off-by: Marek Vasut <[email protected]> > >>>> > >>>> This change is okay. but my questions is why need map register to id. > >>> > >>> This seems to be a recurring pattern in the driver, where some components > >>> need to find other components to link with them. The mapping is fixed, and > >>> since the DT does not encode link IDs, the resolution of the mapping has > >>> to > >>> happen by mapping the component base addresses to the IDs first. > >> > >> In graphic link, port@<n>, n should be id? why not use it? > > I suspect you could model the relationships between the DC blocks using OF > > graph, yes. I also suspect that description would be very complex in > > DT, considering the amount of blocks and links this device contains. I > > suspect this is why there is no such DT description using OF graph. > > Yes. The design decision was made to avoid using OF graph to describe > links between DC blocks due to the complexity.
Any previous discuission? Using registers base address to determiate ID is not solution. Frank > > > > > I think it might also be good to talk to Liu directly about the original > > design > > decision and why this id mapping was done the way it was done, > > they should know better than me. > > > -- > Regards, > Liu Ying
