Linus Walleij wrote at Tuesday, November 29, 2011 12:42 AM: > can we have some initial idea about DT support for pin control > devices and how these will look? Since pin control seems to be > a cruicial piece for people to get board data out of their kernels > we'd better have a common understanding. > > The way I've understood it, we will need three pieces of > DT data: > > 1) Per-driver info, includes the pin controller base, its pins, their > (optional) names and their specific presets like bias etc.
I'm still planning on putting this all into the driver source code; I don't really see any advantage of putting this almost static data into DT just to parse it back out into the same tables that could be written straight into the driver anyway. (only almost static rather than static since we'll need new tables for each SoC) > 2) Board pin group definitions, saying "these three pins > belong to the group "i2c0-pins" I think this is part of (1), if present in the DT at all. This is HW description data, rather than higher level data being added for the purpose of more abstract pinctrl reasons. As such, it belongs in the pinmux HW's node. I don't think we should force this data to be in DT at all if the driver includes the tables itself. There's more to a pin group than just the list of pins it includes; on Tegra20 at least, all muxing/configuration/... is at the pin group level rather than the pin level, so each pin group needs register address, some representation of which configuration options are valid for it, etc. As such, any core DT binding specified would cover a limited subset of the data that needs to be parsed. That said, we could standardize on the way to list the set of pins in each group, and even provide helper functions to enumerate the list of groups and parse the pin list, so that drivers that wish to include this information in their bindings can use it. But I still think the driver should be responsible for obtaining the data however it sees fit, and passing that to the pinctrl core using the existing APIs. > 3) Board function mapping definitions saying "the pin group > 'i2c0-pins' is to be used with device i2c0" which can map > several groups to a single device. Yes, I see this as the domain of the core pinctrl DT bindings. > (1) should be read out by each pin controller driver and > (2)+(3) by the pin controller, specifically pinmux core. ... -- nvpublic _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
