| Message ID | 1313440100-17131-7-git-send-email-swarren@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Aug 15, 2011 at 02:28:13PM -0600, Stephen Warren wrote: > Signed-off-by: Stephen Warren <swarren@nvidia.com> > --- > .../devicetree/bindings/pinmux/pinmux_nvidia.txt | 294 ++++++++++++++++++++ > 1 files changed, 294 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > [...] > + > +Example of a gpio-controller node: > + You meant pinmux node instead of gpio. Regards, Shawn > + pinmux: pinmux@70000000 { > + compatible = "nvidia,tegra20-pinmux"; > + reg = < 0x70000000 0xc00 >; > + nvidia,mux-groups { > + cdev1 { > + nvidia,function = "plla_out"; > + }; > + cdev2 { > + nvidia,function = "pllp_out4"; > + nvidia,pull-down; > + nvidia,tristate; > + }; > + }; > + nvidia,drive-groups { > + sdio1 { > + nvidia,schmitt; > + nvidia,drive-power = <1>; > + nvidia,pull-down-strength = <31>; > + nvidia,pull-up-strength = <31>; > + nvidia,slew-rate-rising = <3>; > + nvidia,slew-rate-falling = <3>; > + }; > + }; > + }; > + > -- > 1.7.0.4 > >
On Monday 15 August 2011, Stephen Warren wrote: > Signed-off-by: Stephen Warren <swarren@nvidia.com> > --- > .../devicetree/bindings/pinmux/pinmux_nvidia.txt | 294 ++++++++++++++++++++ > 1 files changed, 294 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > new file mode 100644 > index 0000000..744e1b7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > @@ -0,0 +1,294 @@ > +NVIDIA Tegra 2 pinmux controller > + > +Required properties: > +- compatible : "nvidia,tegra20-pinmux" Hmm, I think it would be much better in general if we could define pinmux bindings in a way that is less specific to just one soc. The contents of this file seem to be specific to even just one version of the tegra chip, and might be completely different for tegra30 and later, right? Maybe Linus W can comment on this and say whether he thinks it can be generalized enough to apply to other pinmux drivers. > +Optional sub-nodes: > +- nvidia,mux-groups : Mux group settings; see below. > +- nvidia,drive-groups : Drive group settings; see below. > + > +nvidia,mux-groups sub-node: These concepts seem general enough to me that they can apply to other chips, and I would consequently drop the nvidia, prefix. > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. > +The name of the sub-node should be the name of the mux pingroup. The following > +names are valid: > + > + ata > + atb > + atc > + atd > + ate > + cdev1 > + cdev2 > ... I noticed that each board you define has a complete list of these. Would it be possible to move a generic list into a tegra20-pinmux.dtsi file and just override the pins in the per-board .dts file that require some special setup? > + > +optional subnode-properties: > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin. > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin. > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it. > + > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up > +takes precedence. These again seem generic enough to go into a general pinmux binding, without the nvidia, prefix. Arnd
Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM: > On Monday 15 August 2011, Stephen Warren wrote: > > Signed-off-by: Stephen Warren <swarren@nvidia.com> > > --- > > .../devicetree/bindings/pinmux/pinmux_nvidia.txt | 294 ++++++++++++++++++++ > > 1 files changed, 294 insertions(+), 0 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > new file mode 100644 > > index 0000000..744e1b7 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > @@ -0,0 +1,294 @@ > > +NVIDIA Tegra 2 pinmux controller > > + > > +Required properties: > > +- compatible : "nvidia,tegra20-pinmux" > > Hmm, I think it would be much better in general if we could define > pinmux bindings in a way that is less specific to just one soc. > The contents of this file seem to be specific to even just one > version of the tegra chip, and might be completely different for > tegra30 and later, right? The general concepts are the same between tegra20 and tegra30. Tegra30 has a different set of mux and drive pingroups. Tegra30 has more functions that can be assigned to pins. Tegra30 has three more options per mux pingroup, although I haven't Investigated whether any of those would need to be represented in DT; I suspect at least one will, possibly all. > Maybe Linus W can comment on this and say whether he thinks it can > be generalized enough to apply to other pinmux drivers. > > > +Optional sub-nodes: > > +- nvidia,mux-groups : Mux group settings; see below. > > +- nvidia,drive-groups : Drive group settings; see below. > > + > > +nvidia,mux-groups sub-node: > > These concepts seem general enough to me that they can apply to > other chips, and I would consequently drop the nvidia, prefix. Two things to note about Tegra that might not apply to all SoCs: * There are separate groups of pins for Muxing (plus some config) vs. drive-strength (and related config). Some SoCs might use the same set of groups for both. Perhaps some SoC might even have three or more types of groups! I expect this to have some impact on the binding; I created explicit mux-groups and drive-groups sub-nodes to represent this. * Tegra's pinmux apply settings to groups of pins instead of individual pins. Some SoCs might allow each setting to be configurable per-pin. I don't expect this to have any impact as far as the bindings go though; it'll simply impact the names of the available pin "groups"; some SoCs will name groups, others pins. > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. > > +The name of the sub-node should be the name of the mux pingroup. The following > > +names are valid: > > + > > + ata > > + atb > > + atc > > + atd > > + ate > > + cdev1 > > + cdev2 > > ... > > I noticed that each board you define has a complete list of these. Would > it be possible to move a generic list into a tegra20-pinmux.dtsi file and > just override the pins in the per-board .dts file that require some special > setup? I'm not sure how much commonality there will really be. Certainly, many boards are based off our reference designs and so will have many similarities that could be shared. That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows a lot of differences. It seems a lot less error-prone to just completely describe the entire pinmux state in each board's .dts file, rather than trying to represent half the information as default in the SoC .dtsi file, and just the diff in the board .dts file. I suppose perhaps if we put the hardware's own default settings in tegra20.dtsi, that'd make sense, since people are presumably reasonably aware of the delta relative to that. We'd need to add new properties to override defaults, like: nvidia,tristate --> nvidia,drive nvidia,pull-* --> nvidia,no-pull > > + > > +optional subnode-properties: > > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin. > > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin. > > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it. > > + > > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up > > +takes precedence. > > These again seem generic enough to go into a general pinmux binding, without > the nvidia, prefix. Yes, I believe Jamie Iles was going to try cooking up a generic core binding that could be shared across different SoCs, and extended with custom stuff.
On Tue, Aug 16, 2011 at 10:32:05AM -0700, Stephen Warren wrote: > Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM: > > On Monday 15 August 2011, Stephen Warren wrote: > > > Signed-off-by: Stephen Warren <swarren@nvidia.com> > > > --- > > > .../devicetree/bindings/pinmux/pinmux_nvidia.txt | 294 ++++++++++++++++++++ > > > 1 files changed, 294 insertions(+), 0 deletions(-) > > > create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > > > > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > new file mode 100644 > > > index 0000000..744e1b7 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > @@ -0,0 +1,294 @@ > > > +NVIDIA Tegra 2 pinmux controller > > > + > > > +Required properties: > > > +- compatible : "nvidia,tegra20-pinmux" > > > > Hmm, I think it would be much better in general if we could define > > pinmux bindings in a way that is less specific to just one soc. > > > The contents of this file seem to be specific to even just one > > version of the tegra chip, and might be completely different for > > tegra30 and later, right? > > The general concepts are the same between tegra20 and tegra30. > > Tegra30 has a different set of mux and drive pingroups. > > Tegra30 has more functions that can be assigned to pins. > > Tegra30 has three more options per mux pingroup, although I haven't > Investigated whether any of those would need to be represented in DT; > I suspect at least one will, possibly all. > > > Maybe Linus W can comment on this and say whether he thinks it can > > be generalized enough to apply to other pinmux drivers. > > > > > +Optional sub-nodes: > > > +- nvidia,mux-groups : Mux group settings; see below. > > > +- nvidia,drive-groups : Drive group settings; see below. > > > + > > > +nvidia,mux-groups sub-node: > > > > These concepts seem general enough to me that they can apply to > > other chips, and I would consequently drop the nvidia, prefix. > > Two things to note about Tegra that might not apply to all SoCs: > > * There are separate groups of pins for Muxing (plus some config) vs. > drive-strength (and related config). Some SoCs might use the same set > of groups for both. Perhaps some SoC might even have three or more types > of groups! I expect this to have some impact on the binding; I created > explicit mux-groups and drive-groups sub-nodes to represent this. > > * Tegra's pinmux apply settings to groups of pins instead of individual > pins. Some SoCs might allow each setting to be configurable per-pin. > I don't expect this to have any impact as far as the bindings go though; > it'll simply impact the names of the available pin "groups"; some SoCs > will name groups, others pins. > +1 imx's pinmux applies settings to individual pins. > > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. > > > +The name of the sub-node should be the name of the mux pingroup. The following > > > +names are valid: > > > + > > > + ata > > > + atb > > > + atc > > > + atd > > > + ate > > > + cdev1 > > > + cdev2 > > > ... > > > > I noticed that each board you define has a complete list of these. Would > > it be possible to move a generic list into a tegra20-pinmux.dtsi file and > > just override the pins in the per-board .dts file that require some special > > setup? > It sounds sane for imx though. I'm going to take this suggestion to have imx53-pinmux.dtsi holding register offset for each pin, which is common across all i.mx53 boards. > I'm not sure how much commonality there will really be. > > Certainly, many boards are based off our reference designs and so will > have many similarities that could be shared. > > That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows > a lot of differences. It seems a lot less error-prone to just completely > describe the entire pinmux state in each board's .dts file, rather than > trying to represent half the information as default in the SoC .dtsi file, > and just the diff in the board .dts file. I suppose perhaps if we put the > hardware's own default settings in tegra20.dtsi, that'd make sense, since > people are presumably reasonably aware of the delta relative to that. > > We'd need to add new properties to override defaults, like: > > nvidia,tristate --> nvidia,drive > nvidia,pull-* --> nvidia,no-pull > > > > + > > > +optional subnode-properties: > > > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin. > > > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin. > > > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it. > > > + > > > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up > > > +takes precedence. > > > > These again seem generic enough to go into a general pinmux binding, without > > the nvidia, prefix. > > Yes, I believe Jamie Iles was going to try cooking up a generic core binding > that could be shared across different SoCs, and extended with custom stuff. > I would image that whatever common binding for pin/pad configuration comes can hardly work for imx out of box. For each pin/pad, imx have 4 configurations for pull: 00: 100KOhm Pull Down 01: 47KOhm Pull Up 10: 100KOhm Pull Up 11: 22KOhm Pull Up 4 configurations for drive: 00: 100KOhm Pull Down 01: 47KOhm Pull Up 10: 100KOhm Pull Up 11: 22KOhm Pull Up some other 1 bit configuration fields: low/high output voltage Field Hyst. Enable Field Pull / Keep Enable Field Pull / Keep Select Field Slew Rate Field All these are all in one register <pad_name>_PAD_CTL (mux configuration is in another register <pad_name>_PAD_MUX). The best binding for PAD_CTL I can think of so far is to encode the register value in DT directly.
On Wed, Aug 17, 2011 at 02:02:43PM +0800, Shawn Guo wrote: > On Tue, Aug 16, 2011 at 10:32:05AM -0700, Stephen Warren wrote: > > Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM: > > > On Monday 15 August 2011, Stephen Warren wrote: > > > > Signed-off-by: Stephen Warren <swarren@nvidia.com> > > > > --- > > > > .../devicetree/bindings/pinmux/pinmux_nvidia.txt | 294 ++++++++++++++++++++ > > > > 1 files changed, 294 insertions(+), 0 deletions(-) > > > > create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > > new file mode 100644 > > > > index 0000000..744e1b7 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt > > > > @@ -0,0 +1,294 @@ > > > > +NVIDIA Tegra 2 pinmux controller > > > > + > > > > +Required properties: > > > > +- compatible : "nvidia,tegra20-pinmux" > > > > > > Hmm, I think it would be much better in general if we could define > > > pinmux bindings in a way that is less specific to just one soc. > > > > > The contents of this file seem to be specific to even just one > > > version of the tegra chip, and might be completely different for > > > tegra30 and later, right? > > > > The general concepts are the same between tegra20 and tegra30. > > > > Tegra30 has a different set of mux and drive pingroups. > > > > Tegra30 has more functions that can be assigned to pins. > > > > Tegra30 has three more options per mux pingroup, although I haven't > > Investigated whether any of those would need to be represented in DT; > > I suspect at least one will, possibly all. > > > > > Maybe Linus W can comment on this and say whether he thinks it can > > > be generalized enough to apply to other pinmux drivers. > > > > > > > +Optional sub-nodes: > > > > +- nvidia,mux-groups : Mux group settings; see below. > > > > +- nvidia,drive-groups : Drive group settings; see below. > > > > + > > > > +nvidia,mux-groups sub-node: > > > > > > These concepts seem general enough to me that they can apply to > > > other chips, and I would consequently drop the nvidia, prefix. > > > > Two things to note about Tegra that might not apply to all SoCs: > > > > * There are separate groups of pins for Muxing (plus some config) vs. > > drive-strength (and related config). Some SoCs might use the same set > > of groups for both. Perhaps some SoC might even have three or more types > > of groups! I expect this to have some impact on the binding; I created > > explicit mux-groups and drive-groups sub-nodes to represent this. > > > > * Tegra's pinmux apply settings to groups of pins instead of individual > > pins. Some SoCs might allow each setting to be configurable per-pin. > > I don't expect this to have any impact as far as the bindings go though; > > it'll simply impact the names of the available pin "groups"; some SoCs > > will name groups, others pins. > > > +1 > > imx's pinmux applies settings to individual pins. > > > > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. > > > > +The name of the sub-node should be the name of the mux pingroup. The following > > > > +names are valid: > > > > + > > > > + ata > > > > + atb > > > > + atc > > > > + atd > > > > + ate > > > > + cdev1 > > > > + cdev2 > > > > ... > > > > > > I noticed that each board you define has a complete list of these. Would > > > it be possible to move a generic list into a tegra20-pinmux.dtsi file and > > > just override the pins in the per-board .dts file that require some special > > > setup? > > > > It sounds sane for imx though. I'm going to take this suggestion to > have imx53-pinmux.dtsi holding register offset for each pin, which is > common across all i.mx53 boards. > > > I'm not sure how much commonality there will really be. > > > > Certainly, many boards are based off our reference designs and so will > > have many similarities that could be shared. > > > > That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows > > a lot of differences. It seems a lot less error-prone to just completely > > describe the entire pinmux state in each board's .dts file, rather than > > trying to represent half the information as default in the SoC .dtsi file, > > and just the diff in the board .dts file. I suppose perhaps if we put the > > hardware's own default settings in tegra20.dtsi, that'd make sense, since > > people are presumably reasonably aware of the delta relative to that. > > > > We'd need to add new properties to override defaults, like: > > > > nvidia,tristate --> nvidia,drive > > nvidia,pull-* --> nvidia,no-pull > > > > > > + > > > > +optional subnode-properties: > > > > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin. > > > > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin. > > > > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it. > > > > + > > > > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up > > > > +takes precedence. > > > > > > These again seem generic enough to go into a general pinmux binding, without > > > the nvidia, prefix. > > > > Yes, I believe Jamie Iles was going to try cooking up a generic core binding > > that could be shared across different SoCs, and extended with custom stuff. > > > I would image that whatever common binding for pin/pad configuration > comes can hardly work for imx out of box. For each pin/pad, imx have > 4 configurations for pull: > > 00: 100KOhm Pull Down > 01: 47KOhm Pull Up > 10: 100KOhm Pull Up > 11: 22KOhm Pull Up > > 4 configurations for drive: > > 00: 100KOhm Pull Down > 01: 47KOhm Pull Up > 10: 100KOhm Pull Up > 11: 22KOhm Pull Up > Correction: 00 Low Drive Strength 01 Medium Drive Strength 10 High Drive Strength 11 Max Drive Strength > some other 1 bit configuration fields: > > low/high output voltage Field > Hyst. Enable Field > Pull / Keep Enable Field > Pull / Keep Select Field > Slew Rate Field > > All these are all in one register <pad_name>_PAD_CTL (mux configuration > is in another register <pad_name>_PAD_MUX). The best binding for > PAD_CTL I can think of so far is to encode the register value in DT > directly. >
On Tuesday 16 August 2011, Stephen Warren wrote: > Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM: > > On Monday 15 August 2011, Stephen Warren wrote: > > > The contents of this file seem to be specific to even just one > > version of the tegra chip, and might be completely different for > > tegra30 and later, right? > > The general concepts are the same between tegra20 and tegra30. > > Tegra30 has a different set of mux and drive pingroups. > > Tegra30 has more functions that can be assigned to pins. > > Tegra30 has three more options per mux pingroup, although I haven't > Investigated whether any of those would need to be represented in DT; > I suspect at least one will, possibly all. Thanks for the info! > Two things to note about Tegra that might not apply to all SoCs: > > * There are separate groups of pins for Muxing (plus some config) vs. > drive-strength (and related config). Some SoCs might use the same set > of groups for both. Perhaps some SoC might even have three or more types > of groups! I expect this to have some impact on the binding; I created > explicit mux-groups and drive-groups sub-nodes to represent this. > > * Tegra's pinmux apply settings to groups of pins instead of individual > pins. Some SoCs might allow each setting to be configurable per-pin. > I don't expect this to have any impact as far as the bindings go though; > it'll simply impact the names of the available pin "groups"; some SoCs > will name groups, others pins. ok, makes sense. So if we want to have a general binding that applies to all, we really need to cover a lot of different ways to set these up. > > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. > > > +The name of the sub-node should be the name of the mux pingroup. The following > > > +names are valid: > > > + > > > + ata > > > + atb > > > + atc > > > + atd > > > + ate > > > + cdev1 > > > + cdev2 > > > ... > > > > I noticed that each board you define has a complete list of these. Would > > it be possible to move a generic list into a tegra20-pinmux.dtsi file and > > just override the pins in the per-board .dts file that require some special > > setup? > > I'm not sure how much commonality there will really be. > > Certainly, many boards are based off our reference designs and so will > have many similarities that could be shared. > > That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows > a lot of differences. It seems a lot less error-prone to just completely > describe the entire pinmux state in each board's .dts file, rather than > trying to represent half the information as default in the SoC .dtsi file, > and just the diff in the board .dts file. I suppose perhaps if we put the > hardware's own default settings in tegra20.dtsi, that'd make sense, since > people are presumably reasonably aware of the delta relative to that. > > We'd need to add new properties to override defaults, like: > > nvidia,tristate --> nvidia,drive > nvidia,pull-* --> nvidia,no-pull The split I had in mind is more to the effect that the .dtsi file describes the set of pins that is there with their names and addresses, while the board specific file describes how they are set up. Does that make sense? I think I'm still missing some essential aspect of what the pinmux code actually does ;-) I now saw that you have the full description in the arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c files, with all the names again, and apparently your patch set leaves these around. Do you think it's possible to actually move the static tables from there into the device tree and do the entire setup based on that? Arnd
Hi Arnd, On Wed, Aug 17, 2011 at 01:37:25PM +0200, Arnd Bergmann wrote: > The split I had in mind is more to the effect that the .dtsi file > describes the set of pins that is there with their names and addresses, > while the board specific file describes how they are set up. Does that > make sense? I think I'm still missing some essential aspect of what the > pinmux code actually does ;-) > > I now saw that you have the full description in the > arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c > files, with all the names again, and apparently your patch set leaves > these around. Do you think it's possible to actually move the static > tables from there into the device tree and do the entire setup based > on that? The platform I'm working on has a different method of muxing for almost every pin (some aren't even memory mapped registers) so defining the SoC pin definitions in the DTS could result in some pretty horrible bindings. Stephens bindings for configuring the muxing of the pins works quite nicely for our platform though, and I'm just about to post patches that abstract the tegra specific bits out. Jamie
Arnd Bergmann wrote at Wednesday, August 17, 2011 5:37 AM: ... > > > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. > > > > +The name of the sub-node should be the name of the mux pingroup. The following > > > > +names are valid: > > > > + > > > > + ata > > > > + atb > > > > + atc > > > > + atd > > > > + ate > > > > + cdev1 > > > > + cdev2 > > > > ... > > > > > > I noticed that each board you define has a complete list of these. Would > > > it be possible to move a generic list into a tegra20-pinmux.dtsi file and > > > just override the pins in the per-board .dts file that require some special > > > setup? > > > > I'm not sure how much commonality there will really be. > > > > Certainly, many boards are based off our reference designs and so will > > have many similarities that could be shared. > > > > That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows > > a lot of differences. It seems a lot less error-prone to just completely > > describe the entire pinmux state in each board's .dts file, rather than > > trying to represent half the information as default in the SoC .dtsi file, > > and just the diff in the board .dts file. I suppose perhaps if we put the > > hardware's own default settings in tegra20.dtsi, that'd make sense, since > > people are presumably reasonably aware of the delta relative to that. > > > > We'd need to add new properties to override defaults, like: > > > > nvidia,tristate --> nvidia,drive > > nvidia,pull-* --> nvidia,no-pull > > The split I had in mind is more to the effect that the .dtsi file > describes the set of pins that is there with their names and addresses, > while the board specific file describes how they are set up. Does that > make sense? I think I'm still missing some essential aspect of what the > pinmux code actually does ;-) > > I now saw that you have the full description in the > arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c > files, with all the names again, and apparently your patch set leaves > these around. Do you think it's possible to actually move the static > tables from there into the device tree and do the entire setup based > on that? Ah, so you're looking for tegra20.dtsi to define the set pin groups that can be configured, and tegra-harmony.dts to provide the configuration for each of those pingroups. As you see from my patches, I had assumed that the Tegra pinmux driver would be what ended up defining the available pin groups, the register addresses and fields for those groups, just like it does today. The DT would only provide the configuration for each group. That's the reason I didn't understand your questions the first time around. So yes, I think we could represent the set of available pin groups in tegra20.dtsi; it's just some data tables. I don't think this provides as much benefit as moving the per-board configuration data into DT though, because it changes only per SoC generation, not per board. Still, putting the list of pingroups in tegra20.dtsi does move that data out of the kernel, although it bloats each DTB with almost static data that'll take a bunch of time to parse. It's worth considering though. I'm unclear how to resolve where the best location for the data is though; should we just go ahead and move it from the pinmux driver to DT right now, or discuss more or ...?
diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt new file mode 100644 index 0000000..744e1b7 --- /dev/null +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt @@ -0,0 +1,294 @@ +NVIDIA Tegra 2 pinmux controller + +Required properties: +- compatible : "nvidia,tegra20-pinmux" + +Optional sub-nodes: +- nvidia,mux-groups : Mux group settings; see below. +- nvidia,drive-groups : Drive group settings; see below. + +nvidia,mux-groups sub-node: + +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node. +The name of the sub-node should be the name of the mux pingroup. The following +names are valid: + + ata + atb + atc + atd + ate + cdev1 + cdev2 + crtp + csus + dap1 + dap2 + dap3 + dap4 + ddc + dta + dtb + dtc + dtd + dte + dtf + gma + gmb + gmc + gmd + gme + gpu + gpu7 + gpv + hdint + i2cp + irrx + irtx + kbca + kbcb + kbcc + kbcd + kbce + kbcf + lcsn + ld0 + ld1 + ld10 + ld11 + ld12 + ld13 + ld14 + ld15 + ld16 + ld17 + ld2 + ld3 + ld4 + ld5 + ld6 + ld7 + ld8 + ld9 + ldc + ldi + lhp0 + lhp1 + lhp2 + lhs + lm0 + lm1 + lpp + lpw0 + lpw1 + lpw2 + lsc0 + lsc1 + lsck + lsda + lsdi + lspi + lvp0 + lvp1 + lvs + owc + pmc + pta + rm + sdb + sdc + sdd + sdio1 + slxa + slxc + slxd + slxk + spdi + spdo + spia + spib + spic + spid + spie + spif + spig + spih + uaa + uab + uac + uad + uca + ucb + uda + ck32 + ddrc + pmca + pmcb + pmcc + pmcd + pmce + xm2c + xm2d + +Required subnode-properties: +- nvidia,function : A string containing the name of the pinmux function to + mux to the pingroup. The following names are valid; see the Tegra TRM to + determine which are valid for each pingroup: + + none (used for pingroups without muxing functionality) + ahb_clk + apb_clk + audio_sync + crt + dap1 + dap2 + dap3 + dap4 + dap5 + displaya + displayb + emc_test0_dll + emc_test1_dll + gmi + gmi_int + hdmi + i2c + i2c2 + i2c3 + ide + irda + kbc + mio + mipi_hs + nand + osc + owr + pcie + plla_out + pllc_out1 + pllm_out1 + pllp_out2 + pllp_out3 + pllp_out4 + pwm + pwr_intr + pwr_on + rtck + sdio1 + sdio2 + sdio3 + sdio4 + sflash + spdif + spi1 + spi2 + spi2_alt + spi3 + spi4 + trace + twc + uarta + uartb + uartc + uartd + uarte + ulpi + vi + vi_sensor_clk + xio + +optional subnode-properties: +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin. +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin. +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it. + +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up +takes precedence. + +nvidia,drive-groups sub-node: + +Each drive pin group is represented as a sub-node of the nvidia,drive-groups +node. The name of the sub-node should be the name of the drive pingroup. The +following names are valid: + + ao1 + ao2 + at1 + at2 + cdev1 + cdev2 + csus + dap1 + dap2 + dap3 + dap4 + dbg + lcd1 + lcd2 + sdmmc2 + sdmmc3 + spi + uaa + uab + uart2 + uart3 + vi1 + vi2 + xm2a + xm2c + xm2d + xm2clk + memcomp + sdio1 + crt + ddc + gma + gmb + gmc + gmd + gme + owr + uad + +Required subnode-properties: +- nvidia,high-speed-mode : Boolean, enable high speed mode the pins. +- nvidia,schmitt : Boolean, enables Schmitt Trigger on the input. +- nvidia,drive-power : Integer, valid values 0-3. 0 is least power, 3 is + most power. Controls the drive power or current. See "Low Power Mode" + or "LPMD1" and "LPMD0" in the Tegra TRM. +- nvidia,pull-down-strength : Integer, valid values 0-31. Controls drive + strength. See "CAL_DRVDN" in the Tegra TRM. +- nvidia,pull-up-strength : Integer, valid values 0-31. Controls drive + strength. See "CAL_DRVUP" in the Tegra TRM. +- nvidia,slew_rate-rising : Integer, valid values 0-3. 0 is fastest, 3 is + slowest. See "DRVUP_SLWR" in the Tegra TRM. +- nvidia,slew_rate-falling : Integer, valid values 0-3. 0 is fastest, 3 is + slowest. See "DRVDN_SLWR" in the Tegra TRM. + +Example of a gpio-controller node: + + pinmux: pinmux@70000000 { + compatible = "nvidia,tegra20-pinmux"; + reg = < 0x70000000 0xc00 >; + nvidia,mux-groups { + cdev1 { + nvidia,function = "plla_out"; + }; + cdev2 { + nvidia,function = "pllp_out4"; + nvidia,pull-down; + nvidia,tristate; + }; + }; + nvidia,drive-groups { + sdio1 { + nvidia,schmitt; + nvidia,drive-power = <1>; + nvidia,pull-down-strength = <31>; + nvidia,pull-up-strength = <31>; + nvidia,slew-rate-rising = <3>; + nvidia,slew-rate-falling = <3>; + }; + }; + }; +
Signed-off-by: Stephen Warren <swarren@nvidia.com> --- .../devicetree/bindings/pinmux/pinmux_nvidia.txt | 294 ++++++++++++++++++++ 1 files changed, 294 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt