On Sat, Dec 16, 2017 at 11:22:22AM -0800, Tony Lindgren wrote: > * Rob Herring <robh@xxxxxxxxxx> [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".. Okay. > 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? No, I don't have a preference. > 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.. Okay, then I guess I'm okay with this. Reviewed-by: Rob Herring <robh@xxxxxxxxxx> -- 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
