Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [171001 13:49]:
> Hi,
> 
> On Sun, Oct 01, 2017 at 10:14:07AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel <sre-GFxCN5SEZAc@public.gmane.org> [171001 06:12]:
> > > On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> > > > Note that additional properties for sysc capabilities will be added
> > > > later on. For now, we can already use this binding for interconnect
> > > > target modules that do not have any child device drivers available.
> > > > This allows us to idle the unused interconnect target modules during
> > > > init without the need for legacy hwmod platform data for doing it.
> > > 
> > > DT backwards compatibility is about booting an old DT file with a
> > > newer kernel. Since old DT file does not contain a "ti,sysc-omap*"
> > > node you don't need to add "ti,hwmod = *" support to it. Instead a
> > > DT file, that uses ti,hwmod in the device node and does not have a
> > > "ti,sysc-omap*" at all should still work.
> > 
> > Not sure if I parse that right, but I'm assuming you suggest leaving
> > out ti,hwmod to start with. Well I considered that, but it causes
> > the "waiting for a magical flip issue". So initially we need to use
> > both ti,sysc and ti,hwmod until ti,sysc alone has the equal
> > functionality. That's because then we can do the following steps:
> > 
> > 1. We want to add compatible = ti,sysc so we can define the
> >    nodes and get the parent-children hierarhcy right. We can
> >    already use the parent-child features even with ti,hwmods
> >    before we have complete dts based data. We are currently
> >    missing that capability without doing device specific parent
> >    drivers like we do with drivers/usb/musb/musb_am335x.c. Note
> >    that in this step we are moving the ti,hwmod to the parent
> >    node
> > 
> > 2. When ti,sysc can configure things based on dts data alone the
> >    same way as the legacy platform data, we can just drop the
> >    ti,hwmod property. We also want to be able to test one driver
> >    at a time between ti,sysc + ti,hwmod vs ti,sysc only
> > 
> > 3. Once ti,hwmod properties have been removed from the mainline
> >    kernel, we can add a warning about ti,hwmod properties being
> >    deprecated
> > 
> > 4. Then later on, we can also drop the hwmod platform data and
> >    continue produce warnings if ti,hwmod is seen
> 
> Ok, I misunderstood the reason for keeping/adding "ti,hwmod".
> I thought it was only about keeping backwards compatibility, but
> it's still required since hwmod is only partially converted to DT
> by this patchset.

OK

> That basically means, that this patchset breaks DT ABI *now*, since
> old DT has no ti,sysc node?

Nope, things still keep working as they are with and without
ti,sysc :)

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html