Re: [PATCH 1/9] dt-bindings: ti-sysc: Update binding for timers and capabilities

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

* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [171216 18:33]:
> >  Optional properties:
> >  
> > +- ti,sysc-mask	shall contain mask of supported register bits for the
> > +		SYSCONFIG register as documented in the Technical Reference
> > +		Manual (TRM) for the interconnect target module
> > +
> > +- ti,sysc-midle	list of master idle modes supported by the interconnect
> > +		target module as documented in the TRM for SYSCONFIG
> > +		register MIDLEMODE bits
> > +
> > +- ti,sysc-sidle	list of slave idle modes supported by the interconnect
> > +		target module as documented in the TRM for SYSCONFIG
> > +		register SIDLEMODE bits
> > +
> > +- ti,sysc-delay-us	delay needed after OCP softreset before accssing
> > +			SYSCONFIG register again
> > +
> > +- ti,syss-mask	optional mask of reset done status bits as described in the
> > +		TRM for SYSSTATUS registers, typically 1 with some devices
> > +		having separate reset done bits for children like OHCI and
> > +		EHCI
> > +
> 
> Seems like a lot of this should be implied by specific compatible 
> strings.

Unfortunately that would still explode the permutations to almost
one compatible per module especially for types "ti,sysc-omap2" and
"ti,sysc-omap4". And the features and idle modes supported by the
module are all over the place for "ti,sysc-mask", "ti,sysc-midle",
"ti,sysc-sidle" and "ti,syss-mask"..

I was planning to have "ti,sysc-delay-us" only in the driver, but
the same IP needs it set on dm814x while not on omap4 for OTG
for example. I could add SoC specific quirks to the driver
for that one if you prefer that instead?

I do have a patch also I'm testing to use the revision register
value for handling further quirks, but unfortunately that
register is not populated or updated for many modules. And it's
only usable after the module is already configured to accessible :)

> Are the bits you've defined all of them or there's more?

That's it, with this binding I've allocated the data from dts
for the tests I've done. So that should allow us to replace the
static data to start with as seen with the following command:

$ git grep -A10 "struct omap_hwmod_class_sysconfig" \
	arch/arm/*hwmod*data*.c
...

So that's to configure a big pile of different module
configurations we currently have as can be seen with:

$ git grep "struct omap_hwmod_class_sysconfig" \
	arch/arm/*hwmod*data*.c | wc -l
194

I'm sure there's still few duplicates there though..

The only pending binding change I'm aware of is the optional
extra clocks, but that still pending and just uses the
standard clock binding.

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