[PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Geert Uytterhoeven
geert at linux-m68k.org
Wed May 31 13:39:31 UTC 2023
Hi Laurent,
On Wed, May 31, 2023 at 3:37 PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Wed, May 31, 2023 at 02:51:48PM +0200, Geert Uytterhoeven wrote:
> > On Wed, May 31, 2023 at 10:59 AM Laurent Pinchart wrote:
> > > On Mon, May 29, 2023 at 09:00:43AM +0000, Biju Das wrote:
> > > > > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> > > > > And why do you need this ?
> > > >
> > > > As per Krzysztof [2],
> > > >
> > > > The DT schema allows multiple addresses for children. But we lack
> > > > implementation of parent child relationship, As parent owns the resources.
> > > > Child device needs to parse parent node to get some resource
> > > > like clocks.
> > > >
> > > > [2] https://lore.kernel.org/linux-renesas-soc/TYCPR01MB5933BFFD4EB556F5FB4EA82186729@TYCPR01MB5933.jpnprd01.prod.outlook.com/
> > >
> > > The I2C ancillary clients are not meant to be handled by separate
> > > drivers. You're supposed to have one device node in DT, which causes the
> > > I2C core to instantiate a main i2c_client, and bind it to one driver.
> > > That driver then uses i2c_new_ancillary_device() to create other
> > > i2c_client instances for the secondary I2C addresses. Those i2c_client
> > > instances are not bound to a separate driver, so there should be no code
> > > that needs to look at the parent for resources.
> >
> > In Biju's particular use case, the i2c device responds to two addresses,
> > which is the standard i2c ancillary use case. However, what's special
> > is that the second instance is a derivative of an existing i2c device
> > with an existing Linux driver. Hence the desire to make the existing
> > driver match against the second instance, which requires these changes
> > to i2c_new_ancillary_device().
> >
> > As some resources are shared (knowledge about the clocks), splitting
> > this in two distinct devices in DT (which is what Biju's initial patch
> > series did) would need phandles to link both nodes together.
> >
> > Do you have a better idea how to represent this?
>
> MFD ? Otherwise, I'll delegate that to Wolfram, I've spent enough time
> on this patch series I'm afraid :-)
That was v2... (do I need to repeat I don't like mfds? ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
More information about the dri-devel
mailing list