| Message ID | 20200429163743.67854-1-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/12] ARM: dts: stm32: Add alternate pinmux for I2C2 pins | expand |
Hi Marek On 4/29/20 6:37 PM, Marek Vasut wrote: > Add another mux option for I2C2 pins, this is used on AV96 board. > > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Alexandre Torgue <alexandre.torgue@st.com> > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> > Cc: Patrice Chotard <patrice.chotard@st.com> > Cc: Patrick Delaunay <patrick.delaunay@st.com> > Cc: linux-stm32@st-md-mailman.stormreply.com > To: linux-arm-kernel@lists.infradead.org > --- > arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi > index aeddcaadb829..ca4edcf369d0 100644 > --- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi > +++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi > @@ -408,6 +408,23 @@ pins { > }; > }; > > + i2c2_pins_c: i2c2-4 { > + pins { > + pinmux = <STM32_PINMUX('F', 1, AF4)>, /* I2C2_SCL */ > + <STM32_PINMUX('H', 5, AF4)>; /* I2C2_SDA */ > + bias-disable; > + drive-open-drain; > + slew-rate = <0>; > + }; > + }; > + > + i2c2_pins_sleep_c: i2c2-5 { should be i2c2-sleep-4. I'll fix it directly when I'll merge. > + pins { > + pinmux = <STM32_PINMUX('F', 1, ANALOG)>, /* I2C2_SCL */ > + <STM32_PINMUX('H', 5, ANALOG)>; /* I2C2_SDA */ > + }; > + }; > + > i2c5_pins_a: i2c5-0 { > pins { > pinmux = <STM32_PINMUX('A', 11, AF4)>, /* I2C5_SCL */ >
On 5/6/20 9:46 AM, Alexandre Torgue wrote: > Hi Marek Hi, > On 4/29/20 6:37 PM, Marek Vasut wrote: >> Add another mux option for I2C2 pins, this is used on AV96 board. >> >> Signed-off-by: Marek Vasut <marex@denx.de> >> Cc: Alexandre Torgue <alexandre.torgue@st.com> >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> >> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> >> Cc: Patrice Chotard <patrice.chotard@st.com> >> Cc: Patrick Delaunay <patrick.delaunay@st.com> >> Cc: linux-stm32@st-md-mailman.stormreply.com >> To: linux-arm-kernel@lists.infradead.org >> --- >> arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi >> b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi >> index aeddcaadb829..ca4edcf369d0 100644 >> --- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi >> +++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi >> @@ -408,6 +408,23 @@ pins { >> }; >> }; >> + i2c2_pins_c: i2c2-4 { >> + pins { >> + pinmux = <STM32_PINMUX('F', 1, AF4)>, /* I2C2_SCL */ >> + <STM32_PINMUX('H', 5, AF4)>; /* I2C2_SDA */ >> + bias-disable; >> + drive-open-drain; >> + slew-rate = <0>; >> + }; >> + }; >> + >> + i2c2_pins_sleep_c: i2c2-5 { > > should be i2c2-sleep-4. I'll fix it directly when I'll merge. All right, thanks. btw I had this internal discussion now about handling the combinatorial explosion of board DTs here. If we support them all, by the end of the lifespan of these devices, we end up with: STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00. There won't be every SoM and baseboard revision combination all right. But even the amount of SoM options gives me 12 DTs. That is not a low number. Does ST have some plan to handle such situation ? I can imagine that U-Boot can patch the DT and enable/disable functionality , which could handle the {a,c,d,f} options and reduce the amount of DTs. It could possibly also handle the {1,3,7} options. Any other ideas ?
> All right, thanks. > > btw I had this internal discussion now about handling the combinatorial > explosion of board DTs here. If we support them all, by the end of the > lifespan of these devices, we end up with: > > STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00. > > There won't be every SoM and baseboard revision combination all right. > But even the amount of SoM options gives me 12 DTs. That is not a low > number. Does ST have some plan to handle such situation ? Yes I have the same point in mind. How to maintain all boards ? Should we refuse some boards and only keep one as example ? > I can imagine that U-Boot can patch the DT and enable/disable > functionality , which could handle the {a,c,d,f} options and reduce the > amount of DTs. It could possibly also handle the {1,3,7} options. > It is something I discussed with Kevin Hilman at ELCE and sometime with Rob on IIRc. We could use u-boot to handle differences between SoC, and boards. Technically it's possible but the main issue doing that is, you will hide some updates in your bootloader and then your dtb used by kernel will not reflect your dts file. It could be confused for customers and users. > Any other ideas ? What is for you the main issue ? the number of files to add or how to maintain all those files ? If it is the number of files to add, we can think about several ways: 1-As mentioned above, to only keep kind of reference platforms 2-Have vendor directories in arch/arm/boot/dts (but it's another story to make it accepted) 3-Or maybe use DTBO to overwrite some configuration. If the concern is about how to maintain, maybe I'm wrong but I think that with a good split and factorization we could minimize support. Currently I only those things in mind but nothing really mature. regards alex
On 5/6/20 4:26 PM, Alexandre Torgue wrote: > > > >> All right, thanks. >> >> btw I had this internal discussion now about handling the combinatorial >> explosion of board DTs here. If we support them all, by the end of the >> lifespan of these devices, we end up with: >> >> STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00. >> >> There won't be every SoM and baseboard revision combination all right. >> But even the amount of SoM options gives me 12 DTs. That is not a low >> number. Does ST have some plan to handle such situation ? > > Yes I have the same point in mind. How to maintain all boards ? Should > we refuse some boards and only keep one as example ? But which ones do you want to drop? The pdk2 is a devkit , so you can put in any SoM option, that's the problem. >> I can imagine that U-Boot can patch the DT and enable/disable >> functionality , which could handle the {a,c,d,f} options and reduce the >> amount of DTs. It could possibly also handle the {1,3,7} options. >> > > It is something I discussed with Kevin Hilman at ELCE and sometime with > Rob on IIRc. We could use u-boot to handle differences between SoC, and > boards. Technically it's possible but the main issue doing that is, you > will hide some updates in your bootloader and then your dtb used by > kernel will not reflect your dts file. It could be confused for > customers and users. Yes. >> Any other ideas ? > > What is for you the main issue ? the number of files to add or how to > maintain all those files ? The number. Maintaining them is not that much of a problem. > If it is the number of files to add, we can think about several ways: > > 1-As mentioned above, to only keep kind of reference platforms > > 2-Have vendor directories in arch/arm/boot/dts (but it's another story > to make it accepted) Maybe that's something we should consider for arm32, but that's a different discussion altogether. > 3-Or maybe use DTBO to overwrite some configuration. > > If the concern is about how to maintain, maybe I'm wrong but I think > that with a good split and factorization we could minimize support. > > Currently I only those things in mind but nothing really mature. I hope this patchset does the split right, it's the number.
On 5/6/20 4:39 PM, Marek Vasut wrote: > On 5/6/20 4:26 PM, Alexandre Torgue wrote: >> >> >> >>> All right, thanks. >>> >>> btw I had this internal discussion now about handling the combinatorial >>> explosion of board DTs here. If we support them all, by the end of the >>> lifespan of these devices, we end up with: >>> >>> STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00. >>> >>> There won't be every SoM and baseboard revision combination all right. >>> But even the amount of SoM options gives me 12 DTs. That is not a low >>> number. Does ST have some plan to handle such situation ? >> >> Yes I have the same point in mind. How to maintain all boards ? Should >> we refuse some boards and only keep one as example ? > > But which ones do you want to drop? The pdk2 is a devkit , so you can > put in any SoM option, that's the problem. Ok but we could choice to build only one (or few) possibilities. I mean maybe only mp157 ? >>> I can imagine that U-Boot can patch the DT and enable/disable >>> functionality , which could handle the {a,c,d,f} options and reduce the >>> amount of DTs. It could possibly also handle the {1,3,7} options. >>> >> >> It is something I discussed with Kevin Hilman at ELCE and sometime with >> Rob on IIRc. We could use u-boot to handle differences between SoC, and >> boards. Technically it's possible but the main issue doing that is, you >> will hide some updates in your bootloader and then your dtb used by >> kernel will not reflect your dts file. It could be confused for >> customers and users. > > Yes. > >>> Any other ideas ? >> >> What is for you the main issue ? the number of files to add or how to >> maintain all those files ? > > The number. Maintaining them is not that much of a problem. I agree > >> If it is the number of files to add, we can think about several ways: >> >> 1-As mentioned above, to only keep kind of reference platforms >> >> 2-Have vendor directories in arch/arm/boot/dts (but it's another story >> to make it accepted) > > Maybe that's something we should consider for arm32, but that's a > different discussion altogether. I gonna see how to start discussion on that (maybe thanks to Linaro and device tree evolution) >> 3-Or maybe use DTBO to overwrite some configuration. >> >> If the concern is about how to maintain, maybe I'm wrong but I think >> that with a good split and factorization we could minimize support. >> >> Currently I only those things in mind but nothing really mature. > > I hope this patchset does the split right, it's the number. >
On 5/6/20 4:55 PM, Alexandre Torgue wrote: > > > On 5/6/20 4:39 PM, Marek Vasut wrote: >> On 5/6/20 4:26 PM, Alexandre Torgue wrote: >>> >>> >>> >>>> All right, thanks. >>>> >>>> btw I had this internal discussion now about handling the combinatorial >>>> explosion of board DTs here. If we support them all, by the end of the >>>> lifespan of these devices, we end up with: >>>> >>>> STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00. >>>> >>>> There won't be every SoM and baseboard revision combination all right. >>>> But even the amount of SoM options gives me 12 DTs. That is not a low >>>> number. Does ST have some plan to handle such situation ? >>> >>> Yes I have the same point in mind. How to maintain all boards ? Should >>> we refuse some boards and only keep one as example ? >> >> But which ones do you want to drop? The pdk2 is a devkit , so you can >> put in any SoM option, that's the problem. > > Ok but we could choice to build only one (or few) possibilities. I mean > maybe only mp157 ? But that one isn't gonna work for e.g. 153 then, would it? >>>> I can imagine that U-Boot can patch the DT and enable/disable >>>> functionality , which could handle the {a,c,d,f} options and reduce the >>>> amount of DTs. It could possibly also handle the {1,3,7} options. >>>> >>> >>> It is something I discussed with Kevin Hilman at ELCE and sometime with >>> Rob on IIRc. We could use u-boot to handle differences between SoC, and >>> boards. Technically it's possible but the main issue doing that is, you >>> will hide some updates in your bootloader and then your dtb used by >>> kernel will not reflect your dts file. It could be confused for >>> customers and users. >> >> Yes. >> >>>> Any other ideas ? >>> >>> What is for you the main issue ? the number of files to add or how to >>> maintain all those files ? >> >> The number. Maintaining them is not that much of a problem. > > I agree > >> >>> If it is the number of files to add, we can think about several ways: >>> >>> 1-As mentioned above, to only keep kind of reference platforms >>> >>> 2-Have vendor directories in arch/arm/boot/dts (but it's another story >>> to make it accepted) >> >> Maybe that's something we should consider for arm32, but that's a >> different discussion altogether. > > I gonna see how to start discussion on that (maybe thanks to Linaro and > device tree evolution) All right.
On 5/6/20 4:58 PM, Marek Vasut wrote: > On 5/6/20 4:55 PM, Alexandre Torgue wrote: >> >> >> On 5/6/20 4:39 PM, Marek Vasut wrote: >>> On 5/6/20 4:26 PM, Alexandre Torgue wrote: >>>> >>>> >>>> >>>>> All right, thanks. >>>>> >>>>> btw I had this internal discussion now about handling the combinatorial >>>>> explosion of board DTs here. If we support them all, by the end of the >>>>> lifespan of these devices, we end up with: >>>>> >>>>> STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00. >>>>> >>>>> There won't be every SoM and baseboard revision combination all right. >>>>> But even the amount of SoM options gives me 12 DTs. That is not a low >>>>> number. Does ST have some plan to handle such situation ? >>>> >>>> Yes I have the same point in mind. How to maintain all boards ? Should >>>> we refuse some boards and only keep one as example ? >>> >>> But which ones do you want to drop? The pdk2 is a devkit , so you can >>> put in any SoM option, that's the problem. >> >> Ok but we could choice to build only one (or few) possibilities. I mean >> maybe only mp157 ? > > But that one isn't gonna work for e.g. 153 then, would it? No but we could let user of 153 do his own dts by hand. With a good split is not difficult to do. For e.g I don't plan to upstream stm32mp153c-dk2 (I don't know if it really exist), but user could easily create his own stm32mp153c-dk2.dts by assembling well dtsi files and taking stm32mp157c-dk2 (or dk1) as example. >>>>> I can imagine that U-Boot can patch the DT and enable/disable >>>>> functionality , which could handle the {a,c,d,f} options and reduce the >>>>> amount of DTs. It could possibly also handle the {1,3,7} options. >>>>> >>>> >>>> It is something I discussed with Kevin Hilman at ELCE and sometime with >>>> Rob on IIRc. We could use u-boot to handle differences between SoC, and >>>> boards. Technically it's possible but the main issue doing that is, you >>>> will hide some updates in your bootloader and then your dtb used by >>>> kernel will not reflect your dts file. It could be confused for >>>> customers and users. >>> >>> Yes. >>> >>>>> Any other ideas ? >>>> >>>> What is for you the main issue ? the number of files to add or how to >>>> maintain all those files ? >>> >>> The number. Maintaining them is not that much of a problem. >> >> I agree >> >>> >>>> If it is the number of files to add, we can think about several ways: >>>> >>>> 1-As mentioned above, to only keep kind of reference platforms >>>> >>>> 2-Have vendor directories in arch/arm/boot/dts (but it's another story >>>> to make it accepted) >>> >>> Maybe that's something we should consider for arm32, but that's a >>> different discussion altogether. >> >> I gonna see how to start discussion on that (maybe thanks to Linaro and >> device tree evolution) > > All right. >
On 5/6/20 5:15 PM, Alexandre Torgue wrote: > > > On 5/6/20 4:58 PM, Marek Vasut wrote: >> On 5/6/20 4:55 PM, Alexandre Torgue wrote: >>> >>> >>> On 5/6/20 4:39 PM, Marek Vasut wrote: >>>> On 5/6/20 4:26 PM, Alexandre Torgue wrote: >>>>> >>>>> >>>>> >>>>>> All right, thanks. >>>>>> >>>>>> btw I had this internal discussion now about handling the >>>>>> combinatorial >>>>>> explosion of board DTs here. If we support them all, by the end of >>>>>> the >>>>>> lifespan of these devices, we end up with: >>>>>> >>>>>> STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. >>>>>> {0..7}00. >>>>>> >>>>>> There won't be every SoM and baseboard revision combination all >>>>>> right. >>>>>> But even the amount of SoM options gives me 12 DTs. That is not a low >>>>>> number. Does ST have some plan to handle such situation ? >>>>> >>>>> Yes I have the same point in mind. How to maintain all boards ? Should >>>>> we refuse some boards and only keep one as example ? >>>> >>>> But which ones do you want to drop? The pdk2 is a devkit , so you can >>>> put in any SoM option, that's the problem. >>> >>> Ok but we could choice to build only one (or few) possibilities. I mean >>> maybe only mp157 ? >> >> But that one isn't gonna work for e.g. 153 then, would it? > > No but we could let user of 153 do his own dts by hand. With a good > split is not difficult to do. > > For e.g I don't plan to upstream stm32mp153c-dk2 (I don't know if it > really exist), but user could easily create his own stm32mp153c-dk2.dts > by assembling well dtsi files and taking stm32mp157c-dk2 (or dk1) as > example. I would still want to make it easy for the users of this SoM to just use it though. And I am quite sure there will be all combinations of it eventually. [...]
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi index aeddcaadb829..ca4edcf369d0 100644 --- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi +++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi @@ -408,6 +408,23 @@ pins { }; }; + i2c2_pins_c: i2c2-4 { + pins { + pinmux = <STM32_PINMUX('F', 1, AF4)>, /* I2C2_SCL */ + <STM32_PINMUX('H', 5, AF4)>; /* I2C2_SDA */ + bias-disable; + drive-open-drain; + slew-rate = <0>; + }; + }; + + i2c2_pins_sleep_c: i2c2-5 { + pins { + pinmux = <STM32_PINMUX('F', 1, ANALOG)>, /* I2C2_SCL */ + <STM32_PINMUX('H', 5, ANALOG)>; /* I2C2_SDA */ + }; + }; + i2c5_pins_a: i2c5-0 { pins { pinmux = <STM32_PINMUX('A', 11, AF4)>, /* I2C5_SCL */
Add another mux option for I2C2 pins, this is used on AV96 board. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org --- arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)