| Message ID | 1453028210-10139-4-git-send-email-christophe-h.ricard@st.com |
|---|---|
| State | Rejected |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
+Mugunthan, Tom On 17 January 2016 at 03:56, Christophe Ricard <christophe.ricard@gmail.com> wrote: > Convert omap3_spi driver to DM and keep compatibility with previous > mode. > > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> > --- > > drivers/spi/Kconfig | 6 + > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ > drivers/spi/omap3_spi.h | 14 +- > 3 files changed, 402 insertions(+), 57 deletions(-) This is a pretty painful conversion, with lots of #ifdefs. I think it would be possible to use a common pointer type and reduce this. But perhaps it does not matter - how long must we be in the state of supporting legacy SPI? Can we convert all TI boards to driver model? Regards, Simon
On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: > +Mugunthan, Tom > > On 17 January 2016 at 03:56, Christophe Ricard > <christophe.ricard@gmail.com> wrote: > > Convert omap3_spi driver to DM and keep compatibility with previous > > mode. > > > > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> > > --- > > > > drivers/spi/Kconfig | 6 + > > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ > > drivers/spi/omap3_spi.h | 14 +- > > 3 files changed, 402 insertions(+), 57 deletions(-) > > This is a pretty painful conversion, with lots of #ifdefs. I think it > would be possible to use a common pointer type and reduce this. > > But perhaps it does not matter - how long must we be in the state of > supporting legacy SPI? Can we convert all TI boards to driver model? We _really_ need some way to support more than one board per binary before we can move everything to DM only. I think we can kind of do this today if we stick to using platform data for everything that's board-specific rather than SoC-defined. What we talked about at ELCE was auto-generating the pdata from the device tree, I think.
+Hans Hi Tom, On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: > On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >> +Mugunthan, Tom >> >> On 17 January 2016 at 03:56, Christophe Ricard >> <christophe.ricard@gmail.com> wrote: >> > Convert omap3_spi driver to DM and keep compatibility with previous >> > mode. >> > >> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >> > --- >> > >> > drivers/spi/Kconfig | 6 + >> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >> > drivers/spi/omap3_spi.h | 14 +- >> > 3 files changed, 402 insertions(+), 57 deletions(-) >> >> This is a pretty painful conversion, with lots of #ifdefs. I think it >> would be possible to use a common pointer type and reduce this. >> >> But perhaps it does not matter - how long must we be in the state of >> supporting legacy SPI? Can we convert all TI boards to driver model? > > We _really_ need some way to support more than one board per binary > before we can move everything to DM only. > > I think we can kind of do this today if we stick to using platform data > for everything that's board-specific rather than SoC-defined. What we > talked about at ELCE was auto-generating the pdata from the device tree, > I think. We discussed this on IRC but since that doesn't exist as far as the mailing list is concerned... The current plan is: - Adjust build system to optionally build a u-boot.img in FIT format that includes the U-Boot binary and >1 device tree files - Adjust SPL to load this - Add a way for SPL to determine which device tree to select (by calling a board-specific function) - Have SPL pass this selected device tree to U-Boot when it starts Thus we should be able to support more than one board with a single U-Boot image. Of course this is not a perfect solution (e.g. it is inefficient since the DTs are likely to be largely the same) but it should be a good first step. I'm going to try this out with sunxi initially and plan to get some patches out by the end of the week. Regards, Simon
Hi Simon, On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >+Hans > >Hi Tom, > >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>> +Mugunthan, Tom >>> >>> On 17 January 2016 at 03:56, Christophe Ricard >>> <christophe.ricard@gmail.com> wrote: >>> > Convert omap3_spi driver to DM and keep compatibility with previous >>> > mode. >>> > >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>> > --- >>> > >>> > drivers/spi/Kconfig | 6 + >>> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >>> > drivers/spi/omap3_spi.h | 14 +- >>> > 3 files changed, 402 insertions(+), 57 deletions(-) >>> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it >>> would be possible to use a common pointer type and reduce this. >>> >>> But perhaps it does not matter - how long must we be in the state of >>> supporting legacy SPI? Can we convert all TI boards to driver model? >> >> We _really_ need some way to support more than one board per binary >> before we can move everything to DM only. >> >> I think we can kind of do this today if we stick to using platform data >> for everything that's board-specific rather than SoC-defined. What we >> talked about at ELCE was auto-generating the pdata from the device tree, >> I think. > >We discussed this on IRC but since that doesn't exist as far as the >mailing list is concerned... > >The current plan is: > >- Adjust build system to optionally build a u-boot.img in FIT format >that includes the U-Boot binary and >1 device tree files >- Adjust SPL to load this >- Add a way for SPL to determine which device tree to select (by >calling a board-specific function) >- Have SPL pass this selected device tree to U-Boot when it starts Can dtb be sperated from the final u-boot.img, if using SPL? I mean let SPL load the u-boot.img and the dtb to correct DRAM address. And the dtb is shared with linux kernel. Regards, Peng. > >Thus we should be able to support more than one board with a single >U-Boot image. Of course this is not a perfect solution (e.g. it is >inefficient since the DTs are likely to be largely the same) but it >should be a good first step. > >I'm going to try this out with sunxi initially and plan to get some >patches out by the end of the week. > >Regards, >Simon >_______________________________________________ >U-Boot mailing list >U-Boot@lists.denx.de >http://lists.denx.de/mailman/listinfo/u-boot
Hi Peng, On 25 January 2016 at 18:55, Peng Fan <van.freenix@gmail.com> wrote: > Hi Simon, > > On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >>+Hans >> >>Hi Tom, >> >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>>> +Mugunthan, Tom >>>> >>>> On 17 January 2016 at 03:56, Christophe Ricard >>>> <christophe.ricard@gmail.com> wrote: >>>> > Convert omap3_spi driver to DM and keep compatibility with previous >>>> > mode. >>>> > >>>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>>> > --- >>>> > >>>> > drivers/spi/Kconfig | 6 + >>>> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >>>> > drivers/spi/omap3_spi.h | 14 +- >>>> > 3 files changed, 402 insertions(+), 57 deletions(-) >>>> >>>> This is a pretty painful conversion, with lots of #ifdefs. I think it >>>> would be possible to use a common pointer type and reduce this. >>>> >>>> But perhaps it does not matter - how long must we be in the state of >>>> supporting legacy SPI? Can we convert all TI boards to driver model? >>> >>> We _really_ need some way to support more than one board per binary >>> before we can move everything to DM only. >>> >>> I think we can kind of do this today if we stick to using platform data >>> for everything that's board-specific rather than SoC-defined. What we >>> talked about at ELCE was auto-generating the pdata from the device tree, >>> I think. >> >>We discussed this on IRC but since that doesn't exist as far as the >>mailing list is concerned... >> >>The current plan is: >> >>- Adjust build system to optionally build a u-boot.img in FIT format >>that includes the U-Boot binary and >1 device tree files >>- Adjust SPL to load this >>- Add a way for SPL to determine which device tree to select (by >>calling a board-specific function) >>- Have SPL pass this selected device tree to U-Boot when it starts > > Can dtb be sperated from the final u-boot.img, if using SPL? > I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > And the dtb is shared with linux kernel. The way I have it is that u-boot.img include U-Boot and multiple .dtb files. Then SPL selects the correct one and passes it to U-Boot. It could be passed to the kernel also, but then you would need to upgrade your firmware to upgrade your kernel. If that's what you want, it would not be hard to implement. But I am not planning that for this work - it seems like a separate feature to me. > > Regards, > Peng. >> >>Thus we should be able to support more than one board with a single >>U-Boot image. Of course this is not a perfect solution (e.g. it is >>inefficient since the DTs are likely to be largely the same) but it >>should be a good first step. >> >>I'm going to try this out with sunxi initially and plan to get some >>patches out by the end of the week. >> >>Regards, >>Simon Regards Simon
On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote: > Hi Simon, > > On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: > >+Hans > > > >Hi Tom, > > > >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: > >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: > >>> +Mugunthan, Tom > >>> > >>> On 17 January 2016 at 03:56, Christophe Ricard > >>> <christophe.ricard@gmail.com> wrote: > >>> > Convert omap3_spi driver to DM and keep compatibility with previous > >>> > mode. > >>> > > >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> > >>> > --- > >>> > > >>> > drivers/spi/Kconfig | 6 + > >>> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ > >>> > drivers/spi/omap3_spi.h | 14 +- > >>> > 3 files changed, 402 insertions(+), 57 deletions(-) > >>> > >>> This is a pretty painful conversion, with lots of #ifdefs. I think it > >>> would be possible to use a common pointer type and reduce this. > >>> > >>> But perhaps it does not matter - how long must we be in the state of > >>> supporting legacy SPI? Can we convert all TI boards to driver model? > >> > >> We _really_ need some way to support more than one board per binary > >> before we can move everything to DM only. > >> > >> I think we can kind of do this today if we stick to using platform data > >> for everything that's board-specific rather than SoC-defined. What we > >> talked about at ELCE was auto-generating the pdata from the device tree, > >> I think. > > > >We discussed this on IRC but since that doesn't exist as far as the > >mailing list is concerned... > > > >The current plan is: > > > >- Adjust build system to optionally build a u-boot.img in FIT format > >that includes the U-Boot binary and >1 device tree files > >- Adjust SPL to load this > >- Add a way for SPL to determine which device tree to select (by > >calling a board-specific function) > >- Have SPL pass this selected device tree to U-Boot when it starts > > Can dtb be sperated from the final u-boot.img, if using SPL? > I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > And the dtb is shared with linux kernel. This sounds similar, but different. The problem I'm asking to be solved is that at the starting point, there are no DTBs on the hardware. But we can in software easily and reliable tell which of say 3 boards we are on. At that point, we need to make sure that both SPL and then U-Boot know which board they are on. And if in U-Boot we use the DT to pass in all data, it has to be correct. It sounds to me like you're describing the case where the HW has the dtb stored at a known location and you just don't need it embedded within SPL/U-Boot.
On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote: >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote: >> Hi Simon, >> >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >> >+Hans >> > >> >Hi Tom, >> > >> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >> >>> +Mugunthan, Tom >> >>> >> >>> On 17 January 2016 at 03:56, Christophe Ricard >> >>> <christophe.ricard@gmail.com> wrote: >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous >> >>> > mode. >> >>> > >> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >> >>> > --- >> >>> > >> >>> > drivers/spi/Kconfig | 6 + >> >>> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >> >>> > drivers/spi/omap3_spi.h | 14 +- >> >>> > 3 files changed, 402 insertions(+), 57 deletions(-) >> >>> >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it >> >>> would be possible to use a common pointer type and reduce this. >> >>> >> >>> But perhaps it does not matter - how long must we be in the state of >> >>> supporting legacy SPI? Can we convert all TI boards to driver model? >> >> >> >> We _really_ need some way to support more than one board per binary >> >> before we can move everything to DM only. >> >> >> >> I think we can kind of do this today if we stick to using platform data >> >> for everything that's board-specific rather than SoC-defined. What we >> >> talked about at ELCE was auto-generating the pdata from the device tree, >> >> I think. >> > >> >We discussed this on IRC but since that doesn't exist as far as the >> >mailing list is concerned... >> > >> >The current plan is: >> > >> >- Adjust build system to optionally build a u-boot.img in FIT format >> >that includes the U-Boot binary and >1 device tree files >> >- Adjust SPL to load this >> >- Add a way for SPL to determine which device tree to select (by >> >calling a board-specific function) >> >- Have SPL pass this selected device tree to U-Boot when it starts >> >> Can dtb be sperated from the final u-boot.img, if using SPL? >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address. >> And the dtb is shared with linux kernel. > >This sounds similar, but different. The problem I'm asking to be solved >is that at the starting point, there are no DTBs on the hardware. But Oh. Thanks for explanation. >we can in software easily and reliable tell which of say 3 boards we are >on. At that point, we need to make sure that both SPL and then U-Boot >know which board they are on. And if in U-Boot we use the DT to pass in >all data, it has to be correct. It sounds to me like you're describing >the case where the HW has the dtb stored at a known location and you >just don't need it embedded within SPL/U-Boot. Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file. Thanks, Peng. > >-- >Tom
On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote: > On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote: > >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote: > >> Hi Simon, > >> > >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: > >> >+Hans > >> > > >> >Hi Tom, > >> > > >> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: > >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: > >> >>> +Mugunthan, Tom > >> >>> > >> >>> On 17 January 2016 at 03:56, Christophe Ricard > >> >>> <christophe.ricard@gmail.com> wrote: > >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous > >> >>> > mode. > >> >>> > > >> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> > >> >>> > --- > >> >>> > > >> >>> > drivers/spi/Kconfig | 6 + > >> >>> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ > >> >>> > drivers/spi/omap3_spi.h | 14 +- > >> >>> > 3 files changed, 402 insertions(+), 57 deletions(-) > >> >>> > >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it > >> >>> would be possible to use a common pointer type and reduce this. > >> >>> > >> >>> But perhaps it does not matter - how long must we be in the state of > >> >>> supporting legacy SPI? Can we convert all TI boards to driver model? > >> >> > >> >> We _really_ need some way to support more than one board per binary > >> >> before we can move everything to DM only. > >> >> > >> >> I think we can kind of do this today if we stick to using platform data > >> >> for everything that's board-specific rather than SoC-defined. What we > >> >> talked about at ELCE was auto-generating the pdata from the device tree, > >> >> I think. > >> > > >> >We discussed this on IRC but since that doesn't exist as far as the > >> >mailing list is concerned... > >> > > >> >The current plan is: > >> > > >> >- Adjust build system to optionally build a u-boot.img in FIT format > >> >that includes the U-Boot binary and >1 device tree files > >> >- Adjust SPL to load this > >> >- Add a way for SPL to determine which device tree to select (by > >> >calling a board-specific function) > >> >- Have SPL pass this selected device tree to U-Boot when it starts > >> > >> Can dtb be sperated from the final u-boot.img, if using SPL? > >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > >> And the dtb is shared with linux kernel. > > > >This sounds similar, but different. The problem I'm asking to be solved > >is that at the starting point, there are no DTBs on the hardware. But > > Oh. Thanks for explanation. > > >we can in software easily and reliable tell which of say 3 boards we are > >on. At that point, we need to make sure that both SPL and then U-Boot > >know which board they are on. And if in U-Boot we use the DT to pass in > >all data, it has to be correct. It sounds to me like you're describing > >the case where the HW has the dtb stored at a known location and you > >just don't need it embedded within SPL/U-Boot. > > Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file. Can you explain how this would work, or the use case for it? We can't always assume we're reading u-boot.img off FAT for example.
On Tue, Jan 26, 2016 at 10:12:10AM -0500, Tom Rini wrote: >On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote: >> On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote: >> >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote: >> >> Hi Simon, >> >> >> >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >> >> >+Hans >> >> > >> >> >Hi Tom, >> >> > >> >> >On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >> >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >> >> >>> +Mugunthan, Tom >> >> >>> >> >> >>> On 17 January 2016 at 03:56, Christophe Ricard >> >> >>> <christophe.ricard@gmail.com> wrote: >> >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous >> >> >>> > mode. >> >> >>> > >> >> >>> > Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >> >> >>> > --- >> >> >>> > >> >> >>> > drivers/spi/Kconfig | 6 + >> >> >>> > drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >> >> >>> > drivers/spi/omap3_spi.h | 14 +- >> >> >>> > 3 files changed, 402 insertions(+), 57 deletions(-) >> >> >>> >> >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it >> >> >>> would be possible to use a common pointer type and reduce this. >> >> >>> >> >> >>> But perhaps it does not matter - how long must we be in the state of >> >> >>> supporting legacy SPI? Can we convert all TI boards to driver model? >> >> >> >> >> >> We _really_ need some way to support more than one board per binary >> >> >> before we can move everything to DM only. >> >> >> >> >> >> I think we can kind of do this today if we stick to using platform data >> >> >> for everything that's board-specific rather than SoC-defined. What we >> >> >> talked about at ELCE was auto-generating the pdata from the device tree, >> >> >> I think. >> >> > >> >> >We discussed this on IRC but since that doesn't exist as far as the >> >> >mailing list is concerned... >> >> > >> >> >The current plan is: >> >> > >> >> >- Adjust build system to optionally build a u-boot.img in FIT format >> >> >that includes the U-Boot binary and >1 device tree files >> >> >- Adjust SPL to load this >> >> >- Add a way for SPL to determine which device tree to select (by >> >> >calling a board-specific function) >> >> >- Have SPL pass this selected device tree to U-Boot when it starts >> >> >> >> Can dtb be sperated from the final u-boot.img, if using SPL? >> >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address. >> >> And the dtb is shared with linux kernel. >> > >> >This sounds similar, but different. The problem I'm asking to be solved >> >is that at the starting point, there are no DTBs on the hardware. But >> >> Oh. Thanks for explanation. >> >> >we can in software easily and reliable tell which of say 3 boards we are >> >on. At that point, we need to make sure that both SPL and then U-Boot >> >know which board they are on. And if in U-Boot we use the DT to pass in >> >all data, it has to be correct. It sounds to me like you're describing >> >the case where the HW has the dtb stored at a known location and you >> >just don't need it embedded within SPL/U-Boot. >> >> Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file. > >Can you explain how this would work, or the use case for it? We can't >always assume we're reading u-boot.img off FAT for example. I have no idea on this for now (:. Regards, Peng. > >-- >Tom
Hi Simon, Tom, I assume the approach you are taking is also valuable for the i2c: omap24xx patch serie: http://lists.denx.de/pipermail/u-boot/2016-January/241676.html What are your recommendation about the pending patches ? Should i send back only the one not taking care of the DM conversion and send another serie later ? I have seen some work ongoing on this topic on the u-boot-fdt tree on the spl-working branch. Is there a more accurate place to follow this work ? Best Regards Christophe On 26/01/2016 02:55, Peng Fan wrote: > Hi Simon, > > On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >> +Hans >> >> Hi Tom, >> >> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>>> +Mugunthan, Tom >>>> >>>> On 17 January 2016 at 03:56, Christophe Ricard >>>> <christophe.ricard@gmail.com> wrote: >>>>> Convert omap3_spi driver to DM and keep compatibility with previous >>>>> mode. >>>>> >>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>>>> --- >>>>> >>>>> drivers/spi/Kconfig | 6 + >>>>> drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >>>>> drivers/spi/omap3_spi.h | 14 +- >>>>> 3 files changed, 402 insertions(+), 57 deletions(-) >>>> This is a pretty painful conversion, with lots of #ifdefs. I think it >>>> would be possible to use a common pointer type and reduce this. >>>> >>>> But perhaps it does not matter - how long must we be in the state of >>>> supporting legacy SPI? Can we convert all TI boards to driver model? >>> We _really_ need some way to support more than one board per binary >>> before we can move everything to DM only. >>> >>> I think we can kind of do this today if we stick to using platform data >>> for everything that's board-specific rather than SoC-defined. What we >>> talked about at ELCE was auto-generating the pdata from the device tree, >>> I think. >> We discussed this on IRC but since that doesn't exist as far as the >> mailing list is concerned... >> >> The current plan is: >> >> - Adjust build system to optionally build a u-boot.img in FIT format >> that includes the U-Boot binary and >1 device tree files >> - Adjust SPL to load this >> - Add a way for SPL to determine which device tree to select (by >> calling a board-specific function) >> - Have SPL pass this selected device tree to U-Boot when it starts > Can dtb be sperated from the final u-boot.img, if using SPL? > I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > And the dtb is shared with linux kernel. > > Regards, > Peng. >> Thus we should be able to support more than one board with a single >> U-Boot image. Of course this is not a perfect solution (e.g. it is >> inefficient since the DTs are likely to be largely the same) but it >> should be a good first step. >> >> I'm going to try this out with sunxi initially and plan to get some >> patches out by the end of the week. >> >> Regards, >> Simon >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot
On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: > Hi Simon, Tom, > > I assume the approach you are taking is also valuable for the i2c: > omap24xx patch serie: > http://lists.denx.de/pipermail/u-boot/2016-January/241676.html > > What are your recommendation about the pending patches ? > Should i send back only the one not taking care of the DM conversion > and send another serie later ? > > I have seen some work ongoing on this topic on the u-boot-fdt tree > on the spl-working branch. > Is there a more accurate place to follow this work ? For i2c, aside from needing to defer removing the non-DM code for a while yet, there were some review comments to address in a v2 or answer as intentional. For SPI, it's all looking good and I'm assuming Jagan will have a SPI PR soon. Thanks! > > Best Regards > Christophe > > On 26/01/2016 02:55, Peng Fan wrote: > >Hi Simon, > > > >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: > >>+Hans > >> > >>Hi Tom, > >> > >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: > >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: > >>>>+Mugunthan, Tom > >>>> > >>>>On 17 January 2016 at 03:56, Christophe Ricard > >>>><christophe.ricard@gmail.com> wrote: > >>>>>Convert omap3_spi driver to DM and keep compatibility with previous > >>>>>mode. > >>>>> > >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> > >>>>>--- > >>>>> > >>>>> drivers/spi/Kconfig | 6 + > >>>>> drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ > >>>>> drivers/spi/omap3_spi.h | 14 +- > >>>>> 3 files changed, 402 insertions(+), 57 deletions(-) > >>>>This is a pretty painful conversion, with lots of #ifdefs. I think it > >>>>would be possible to use a common pointer type and reduce this. > >>>> > >>>>But perhaps it does not matter - how long must we be in the state of > >>>>supporting legacy SPI? Can we convert all TI boards to driver model? > >>>We _really_ need some way to support more than one board per binary > >>>before we can move everything to DM only. > >>> > >>>I think we can kind of do this today if we stick to using platform data > >>>for everything that's board-specific rather than SoC-defined. What we > >>>talked about at ELCE was auto-generating the pdata from the device tree, > >>>I think. > >>We discussed this on IRC but since that doesn't exist as far as the > >>mailing list is concerned... > >> > >>The current plan is: > >> > >>- Adjust build system to optionally build a u-boot.img in FIT format > >>that includes the U-Boot binary and >1 device tree files > >>- Adjust SPL to load this > >>- Add a way for SPL to determine which device tree to select (by > >>calling a board-specific function) > >>- Have SPL pass this selected device tree to U-Boot when it starts > >Can dtb be sperated from the final u-boot.img, if using SPL? > >I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > >And the dtb is shared with linux kernel. > > > >Regards, > >Peng. > >>Thus we should be able to support more than one board with a single > >>U-Boot image. Of course this is not a perfect solution (e.g. it is > >>inefficient since the DTs are likely to be largely the same) but it > >>should be a good first step. > >> > >>I'm going to try this out with sunxi initially and plan to get some > >>patches out by the end of the week. > >> > >>Regards, > >>Simon > >>_______________________________________________ > >>U-Boot mailing list > >>U-Boot@lists.denx.de > >>http://lists.denx.de/mailman/listinfo/u-boot >
On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote: > On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: >> Hi Simon, Tom, >> >> I assume the approach you are taking is also valuable for the i2c: >> omap24xx patch serie: >> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html >> >> What are your recommendation about the pending patches ? >> Should i send back only the one not taking care of the DM conversion >> and send another serie later ? >> >> I have seen some work ongoing on this topic on the u-boot-fdt tree >> on the spl-working branch. >> Is there a more accurate place to follow this work ? > > For i2c, aside from needing to defer removing the non-DM code for a > while yet, there were some review comments to address in a v2 or answer > as intentional. For SPI, it's all looking good and I'm assuming Jagan > will have a SPI PR soon. Thanks! Yes, by this week-end. >> >> On 26/01/2016 02:55, Peng Fan wrote: >> >Hi Simon, >> > >> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >> >>+Hans >> >> >> >>Hi Tom, >> >> >> >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >> >>>>+Mugunthan, Tom >> >>>> >> >>>>On 17 January 2016 at 03:56, Christophe Ricard >> >>>><christophe.ricard@gmail.com> wrote: >> >>>>>Convert omap3_spi driver to DM and keep compatibility with previous >> >>>>>mode. >> >>>>> >> >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >> >>>>>--- >> >>>>> >> >>>>> drivers/spi/Kconfig | 6 + >> >>>>> drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >> >>>>> drivers/spi/omap3_spi.h | 14 +- >> >>>>> 3 files changed, 402 insertions(+), 57 deletions(-) >> >>>>This is a pretty painful conversion, with lots of #ifdefs. I think it >> >>>>would be possible to use a common pointer type and reduce this. >> >>>> >> >>>>But perhaps it does not matter - how long must we be in the state of >> >>>>supporting legacy SPI? Can we convert all TI boards to driver model? >> >>>We _really_ need some way to support more than one board per binary >> >>>before we can move everything to DM only. >> >>> >> >>>I think we can kind of do this today if we stick to using platform data >> >>>for everything that's board-specific rather than SoC-defined. What we >> >>>talked about at ELCE was auto-generating the pdata from the device tree, >> >>>I think. >> >>We discussed this on IRC but since that doesn't exist as far as the >> >>mailing list is concerned... >> >> >> >>The current plan is: >> >> >> >>- Adjust build system to optionally build a u-boot.img in FIT format >> >>that includes the U-Boot binary and >1 device tree files >> >>- Adjust SPL to load this >> >>- Add a way for SPL to determine which device tree to select (by >> >>calling a board-specific function) >> >>- Have SPL pass this selected device tree to U-Boot when it starts >> >Can dtb be sperated from the final u-boot.img, if using SPL? >> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address. >> >And the dtb is shared with linux kernel. >> > >> >Regards, >> >Peng. >> >>Thus we should be able to support more than one board with a single >> >>U-Boot image. Of course this is not a perfect solution (e.g. it is >> >>inefficient since the DTs are likely to be largely the same) but it >> >>should be a good first step. >> >> >> >>I'm going to try this out with sunxi initially and plan to get some >> >>patches out by the end of the week.
On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote: > On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote: >> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: >>> Hi Simon, Tom, >>> >>> I assume the approach you are taking is also valuable for the i2c: >>> omap24xx patch serie: >>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html >>> >>> What are your recommendation about the pending patches ? >>> Should i send back only the one not taking care of the DM conversion >>> and send another serie later ? >>> >>> I have seen some work ongoing on this topic on the u-boot-fdt tree >>> on the spl-working branch. >>> Is there a more accurate place to follow this work ? >> >> For i2c, aside from needing to defer removing the non-DM code for a >> while yet, there were some review comments to address in a v2 or answer >> as intentional. For SPI, it's all looking good and I'm assuming Jagan >> will have a SPI PR soon. Thanks! > > Yes, by this week-end. Any idea 4/4 got differed in patchwork [1], do we have next version patches for these? [1] https://patchwork.ozlabs.org/patch/569241/ > >>> >>> On 26/01/2016 02:55, Peng Fan wrote: >>> >Hi Simon, >>> > >>> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >>> >>+Hans >>> >> >>> >>Hi Tom, >>> >> >>> >>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >>> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>> >>>>+Mugunthan, Tom >>> >>>> >>> >>>>On 17 January 2016 at 03:56, Christophe Ricard >>> >>>><christophe.ricard@gmail.com> wrote: >>> >>>>>Convert omap3_spi driver to DM and keep compatibility with previous >>> >>>>>mode. >>> >>>>> >>> >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>> >>>>>--- >>> >>>>> >>> >>>>> drivers/spi/Kconfig | 6 + >>> >>>>> drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >>> >>>>> drivers/spi/omap3_spi.h | 14 +- >>> >>>>> 3 files changed, 402 insertions(+), 57 deletions(-) >>> >>>>This is a pretty painful conversion, with lots of #ifdefs. I think it >>> >>>>would be possible to use a common pointer type and reduce this. >>> >>>> >>> >>>>But perhaps it does not matter - how long must we be in the state of >>> >>>>supporting legacy SPI? Can we convert all TI boards to driver model? >>> >>>We _really_ need some way to support more than one board per binary >>> >>>before we can move everything to DM only. >>> >>> >>> >>>I think we can kind of do this today if we stick to using platform data >>> >>>for everything that's board-specific rather than SoC-defined. What we >>> >>>talked about at ELCE was auto-generating the pdata from the device tree, >>> >>>I think. >>> >>We discussed this on IRC but since that doesn't exist as far as the >>> >>mailing list is concerned... >>> >> >>> >>The current plan is: >>> >> >>> >>- Adjust build system to optionally build a u-boot.img in FIT format >>> >>that includes the U-Boot binary and >1 device tree files >>> >>- Adjust SPL to load this >>> >>- Add a way for SPL to determine which device tree to select (by >>> >>calling a board-specific function) >>> >>- Have SPL pass this selected device tree to U-Boot when it starts >>> >Can dtb be sperated from the final u-boot.img, if using SPL? >>> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address. >>> >And the dtb is shared with linux kernel. >>> > >>> >Regards, >>> >Peng. >>> >>Thus we should be able to support more than one board with a single >>> >>U-Boot image. Of course this is not a perfect solution (e.g. it is >>> >>inefficient since the DTs are likely to be largely the same) but it >>> >>should be a good first step. >>> >> >>> >>I'm going to try this out with sunxi initially and plan to get some >>> >>patches out by the end of the week.
Hi Jagan, My understanding is that some work are ongoing around spl in order to support correctly DM for all spi/i2c bus drivers. As a consequence patch 4 got differed. Hopefully Simon or Tom can comment. Are you ok in applying patch 1 and 2 only ? or should i send a new serie with only patch 1 and 2 ? Best Regards Christophe On 10/02/2016 20:16, Jagan Teki wrote: > On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote: >> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote: >>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: >>>> Hi Simon, Tom, >>>> >>>> I assume the approach you are taking is also valuable for the i2c: >>>> omap24xx patch serie: >>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html >>>> >>>> What are your recommendation about the pending patches ? >>>> Should i send back only the one not taking care of the DM conversion >>>> and send another serie later ? >>>> >>>> I have seen some work ongoing on this topic on the u-boot-fdt tree >>>> on the spl-working branch. >>>> Is there a more accurate place to follow this work ? >>> For i2c, aside from needing to defer removing the non-DM code for a >>> while yet, there were some review comments to address in a v2 or answer >>> as intentional. For SPI, it's all looking good and I'm assuming Jagan >>> will have a SPI PR soon. Thanks! >> Yes, by this week-end. > Any idea 4/4 got differed in patchwork [1], do we have next version > patches for these? > > [1] https://patchwork.ozlabs.org/patch/569241/ > >>>> On 26/01/2016 02:55, Peng Fan wrote: >>>>> Hi Simon, >>>>> >>>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >>>>>> +Hans >>>>>> >>>>>> Hi Tom, >>>>>> >>>>>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >>>>>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>>>>>>> +Mugunthan, Tom >>>>>>>> >>>>>>>> On 17 January 2016 at 03:56, Christophe Ricard >>>>>>>> <christophe.ricard@gmail.com> wrote: >>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with previous >>>>>>>>> mode. >>>>>>>>> >>>>>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> drivers/spi/Kconfig | 6 + >>>>>>>>> drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ >>>>>>>>> drivers/spi/omap3_spi.h | 14 +- >>>>>>>>> 3 files changed, 402 insertions(+), 57 deletions(-) >>>>>>>> This is a pretty painful conversion, with lots of #ifdefs. I think it >>>>>>>> would be possible to use a common pointer type and reduce this. >>>>>>>> >>>>>>>> But perhaps it does not matter - how long must we be in the state of >>>>>>>> supporting legacy SPI? Can we convert all TI boards to driver model? >>>>>>> We _really_ need some way to support more than one board per binary >>>>>>> before we can move everything to DM only. >>>>>>> >>>>>>> I think we can kind of do this today if we stick to using platform data >>>>>>> for everything that's board-specific rather than SoC-defined. What we >>>>>>> talked about at ELCE was auto-generating the pdata from the device tree, >>>>>>> I think. >>>>>> We discussed this on IRC but since that doesn't exist as far as the >>>>>> mailing list is concerned... >>>>>> >>>>>> The current plan is: >>>>>> >>>>>> - Adjust build system to optionally build a u-boot.img in FIT format >>>>>> that includes the U-Boot binary and >1 device tree files >>>>>> - Adjust SPL to load this >>>>>> - Add a way for SPL to determine which device tree to select (by >>>>>> calling a board-specific function) >>>>>> - Have SPL pass this selected device tree to U-Boot when it starts >>>>> Can dtb be sperated from the final u-boot.img, if using SPL? >>>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM address. >>>>> And the dtb is shared with linux kernel. >>>>> >>>>> Regards, >>>>> Peng. >>>>>> Thus we should be able to support more than one board with a single >>>>>> U-Boot image. Of course this is not a perfect solution (e.g. it is >>>>>> inefficient since the DTs are likely to be largely the same) but it >>>>>> should be a good first step. >>>>>> >>>>>> I'm going to try this out with sunxi initially and plan to get some >>>>>> patches out by the end of the week.
On Wed, Feb 10, 2016 at 10:00:55PM +0100, Christophe Ricard wrote: > Hi Jagan, > > My understanding is that some work are ongoing around spl in order > to support correctly DM for all spi/i2c bus drivers. > As a consequence patch 4 got differed. > > Hopefully Simon or Tom can comment. Yes, I deferred 4/4 because until we convert all of the platforms to DM (and Simon is making progress on what's required there). > Are you ok in applying patch 1 and 2 only ? or should i send a new > serie with only patch 1 and 2 ? 1, 2 and 3? should be fine to go now and you shouldn't need to re-send them. > > Best Regards > Christophe > > On 10/02/2016 20:16, Jagan Teki wrote: > >On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote: > >>On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote: > >>>On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: > >>>>Hi Simon, Tom, > >>>> > >>>>I assume the approach you are taking is also valuable for the i2c: > >>>>omap24xx patch serie: > >>>>http://lists.denx.de/pipermail/u-boot/2016-January/241676.html > >>>> > >>>>What are your recommendation about the pending patches ? > >>>>Should i send back only the one not taking care of the DM conversion > >>>>and send another serie later ? > >>>> > >>>>I have seen some work ongoing on this topic on the u-boot-fdt tree > >>>>on the spl-working branch. > >>>>Is there a more accurate place to follow this work ? > >>>For i2c, aside from needing to defer removing the non-DM code for a > >>>while yet, there were some review comments to address in a v2 or answer > >>>as intentional. For SPI, it's all looking good and I'm assuming Jagan > >>>will have a SPI PR soon. Thanks! > >>Yes, by this week-end. > >Any idea 4/4 got differed in patchwork [1], do we have next version > >patches for these? > > > >[1] https://patchwork.ozlabs.org/patch/569241/ > > > >>>>On 26/01/2016 02:55, Peng Fan wrote: > >>>>>Hi Simon, > >>>>> > >>>>>On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: > >>>>>>+Hans > >>>>>> > >>>>>>Hi Tom, > >>>>>> > >>>>>>On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: > >>>>>>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: > >>>>>>>>+Mugunthan, Tom > >>>>>>>> > >>>>>>>>On 17 January 2016 at 03:56, Christophe Ricard > >>>>>>>><christophe.ricard@gmail.com> wrote: > >>>>>>>>>Convert omap3_spi driver to DM and keep compatibility with previous > >>>>>>>>>mode. > >>>>>>>>> > >>>>>>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> > >>>>>>>>>--- > >>>>>>>>> > >>>>>>>>> drivers/spi/Kconfig | 6 + > >>>>>>>>> drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ > >>>>>>>>> drivers/spi/omap3_spi.h | 14 +- > >>>>>>>>> 3 files changed, 402 insertions(+), 57 deletions(-) > >>>>>>>>This is a pretty painful conversion, with lots of #ifdefs. I think it > >>>>>>>>would be possible to use a common pointer type and reduce this. > >>>>>>>> > >>>>>>>>But perhaps it does not matter - how long must we be in the state of > >>>>>>>>supporting legacy SPI? Can we convert all TI boards to driver model? > >>>>>>>We _really_ need some way to support more than one board per binary > >>>>>>>before we can move everything to DM only. > >>>>>>> > >>>>>>>I think we can kind of do this today if we stick to using platform data > >>>>>>>for everything that's board-specific rather than SoC-defined. What we > >>>>>>>talked about at ELCE was auto-generating the pdata from the device tree, > >>>>>>>I think. > >>>>>>We discussed this on IRC but since that doesn't exist as far as the > >>>>>>mailing list is concerned... > >>>>>> > >>>>>>The current plan is: > >>>>>> > >>>>>>- Adjust build system to optionally build a u-boot.img in FIT format > >>>>>>that includes the U-Boot binary and >1 device tree files > >>>>>>- Adjust SPL to load this > >>>>>>- Add a way for SPL to determine which device tree to select (by > >>>>>>calling a board-specific function) > >>>>>>- Have SPL pass this selected device tree to U-Boot when it starts > >>>>>Can dtb be sperated from the final u-boot.img, if using SPL? > >>>>>I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > >>>>>And the dtb is shared with linux kernel. > >>>>> > >>>>>Regards, > >>>>>Peng. > >>>>>>Thus we should be able to support more than one board with a single > >>>>>>U-Boot image. Of course this is not a perfect solution (e.g. it is > >>>>>>inefficient since the DTs are likely to be largely the same) but it > >>>>>>should be a good first step. > >>>>>> > >>>>>>I'm going to try this out with sunxi initially and plan to get some > >>>>>>patches out by the end of the week. >
On 11 February 2016 at 02:30, Christophe Ricard <christophe.ricard@gmail.com> wrote: > Hi Jagan, > > My understanding is that some work are ongoing around spl in order to > support correctly DM for all spi/i2c bus drivers. > As a consequence patch 4 got differed. > > Hopefully Simon or Tom can comment. > > Are you ok in applying patch 1 and 2 only ? or should i send a new serie > with only patch 1 and 2 ? 3/4 looks not good to me with so many ifdef, may we can do something clear similar to kirkwood_spi does. > > On 10/02/2016 20:16, Jagan Teki wrote: >> >> On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote: >>> >>> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote: >>>> >>>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: >>>>> >>>>> Hi Simon, Tom, >>>>> >>>>> I assume the approach you are taking is also valuable for the i2c: >>>>> omap24xx patch serie: >>>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html >>>>> >>>>> What are your recommendation about the pending patches ? >>>>> Should i send back only the one not taking care of the DM conversion >>>>> and send another serie later ? >>>>> >>>>> I have seen some work ongoing on this topic on the u-boot-fdt tree >>>>> on the spl-working branch. >>>>> Is there a more accurate place to follow this work ? >>>> >>>> For i2c, aside from needing to defer removing the non-DM code for a >>>> while yet, there were some review comments to address in a v2 or answer >>>> as intentional. For SPI, it's all looking good and I'm assuming Jagan >>>> will have a SPI PR soon. Thanks! >>> >>> Yes, by this week-end. >> >> Any idea 4/4 got differed in patchwork [1], do we have next version >> patches for these? >> >> [1] https://patchwork.ozlabs.org/patch/569241/ >> >>>>> On 26/01/2016 02:55, Peng Fan wrote: >>>>>> >>>>>> Hi Simon, >>>>>> >>>>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >>>>>>> >>>>>>> +Hans >>>>>>> >>>>>>> Hi Tom, >>>>>>> >>>>>>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >>>>>>>> >>>>>>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>>>>>>>> >>>>>>>>> +Mugunthan, Tom >>>>>>>>> >>>>>>>>> On 17 January 2016 at 03:56, Christophe Ricard >>>>>>>>> <christophe.ricard@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with >>>>>>>>>> previous >>>>>>>>>> mode. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> drivers/spi/Kconfig | 6 + >>>>>>>>>> drivers/spi/omap3_spi.c | 439 >>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++------ >>>>>>>>>> drivers/spi/omap3_spi.h | 14 +- >>>>>>>>>> 3 files changed, 402 insertions(+), 57 deletions(-) >>>>>>>>> >>>>>>>>> This is a pretty painful conversion, with lots of #ifdefs. I think >>>>>>>>> it >>>>>>>>> would be possible to use a common pointer type and reduce this. >>>>>>>>> >>>>>>>>> But perhaps it does not matter - how long must we be in the state >>>>>>>>> of >>>>>>>>> supporting legacy SPI? Can we convert all TI boards to driver >>>>>>>>> model? >>>>>>>> >>>>>>>> We _really_ need some way to support more than one board per binary >>>>>>>> before we can move everything to DM only. >>>>>>>> >>>>>>>> I think we can kind of do this today if we stick to using platform >>>>>>>> data >>>>>>>> for everything that's board-specific rather than SoC-defined. What >>>>>>>> we >>>>>>>> talked about at ELCE was auto-generating the pdata from the device >>>>>>>> tree, >>>>>>>> I think. >>>>>>> >>>>>>> We discussed this on IRC but since that doesn't exist as far as the >>>>>>> mailing list is concerned... >>>>>>> >>>>>>> The current plan is: >>>>>>> >>>>>>> - Adjust build system to optionally build a u-boot.img in FIT format >>>>>>> that includes the U-Boot binary and >1 device tree files >>>>>>> - Adjust SPL to load this >>>>>>> - Add a way for SPL to determine which device tree to select (by >>>>>>> calling a board-specific function) >>>>>>> - Have SPL pass this selected device tree to U-Boot when it starts >>>>>> >>>>>> Can dtb be sperated from the final u-boot.img, if using SPL? >>>>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM >>>>>> address. >>>>>> And the dtb is shared with linux kernel. >>>>>> >>>>>> Regards, >>>>>> Peng. >>>>>>> >>>>>>> Thus we should be able to support more than one board with a single >>>>>>> U-Boot image. Of course this is not a perfect solution (e.g. it is >>>>>>> inefficient since the DTs are likely to be largely the same) but it >>>>>>> should be a good first step. >>>>>>> >>>>>>> I'm going to try this out with sunxi initially and plan to get some >>>>>>> patches out by the end of the week. > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
On 11 February 2016 at 20:31, Jagan Teki <jteki@openedev.com> wrote: > On 11 February 2016 at 02:30, Christophe Ricard > <christophe.ricard@gmail.com> wrote: >> Hi Jagan, >> >> My understanding is that some work are ongoing around spl in order to >> support correctly DM for all spi/i2c bus drivers. >> As a consequence patch 4 got differed. >> >> Hopefully Simon or Tom can comment. >> >> Are you ok in applying patch 1 and 2 only ? or should i send a new serie >> with only patch 1 and 2 ? > > 3/4 looks not good to me with so many ifdef, may we can do something > clear similar to kirkwood_spi does. I did some dm conversion on these long back which looks similar like kirkwood_spi, will post them as well so-that we can discuss. > >> >> On 10/02/2016 20:16, Jagan Teki wrote: >>> >>> On 8 February 2016 at 23:26, Jagan Teki <jteki@openedev.com> wrote: >>>> >>>> On 8 February 2016 at 23:10, Tom Rini <trini@konsulko.com> wrote: >>>>> >>>>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote: >>>>>> >>>>>> Hi Simon, Tom, >>>>>> >>>>>> I assume the approach you are taking is also valuable for the i2c: >>>>>> omap24xx patch serie: >>>>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html >>>>>> >>>>>> What are your recommendation about the pending patches ? >>>>>> Should i send back only the one not taking care of the DM conversion >>>>>> and send another serie later ? >>>>>> >>>>>> I have seen some work ongoing on this topic on the u-boot-fdt tree >>>>>> on the spl-working branch. >>>>>> Is there a more accurate place to follow this work ? >>>>> >>>>> For i2c, aside from needing to defer removing the non-DM code for a >>>>> while yet, there were some review comments to address in a v2 or answer >>>>> as intentional. For SPI, it's all looking good and I'm assuming Jagan >>>>> will have a SPI PR soon. Thanks! >>>> >>>> Yes, by this week-end. >>> >>> Any idea 4/4 got differed in patchwork [1], do we have next version >>> patches for these? >>> >>> [1] https://patchwork.ozlabs.org/patch/569241/ >>> >>>>>> On 26/01/2016 02:55, Peng Fan wrote: >>>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: >>>>>>>> >>>>>>>> +Hans >>>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> On 21 January 2016 at 05:24, Tom Rini <trini@konsulko.com> wrote: >>>>>>>>> >>>>>>>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: >>>>>>>>>> >>>>>>>>>> +Mugunthan, Tom >>>>>>>>>> >>>>>>>>>> On 17 January 2016 at 03:56, Christophe Ricard >>>>>>>>>> <christophe.ricard@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Convert omap3_spi driver to DM and keep compatibility with >>>>>>>>>>> previous >>>>>>>>>>> mode. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> drivers/spi/Kconfig | 6 + >>>>>>>>>>> drivers/spi/omap3_spi.c | 439 >>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++------ >>>>>>>>>>> drivers/spi/omap3_spi.h | 14 +- >>>>>>>>>>> 3 files changed, 402 insertions(+), 57 deletions(-) >>>>>>>>>> >>>>>>>>>> This is a pretty painful conversion, with lots of #ifdefs. I think >>>>>>>>>> it >>>>>>>>>> would be possible to use a common pointer type and reduce this. >>>>>>>>>> >>>>>>>>>> But perhaps it does not matter - how long must we be in the state >>>>>>>>>> of >>>>>>>>>> supporting legacy SPI? Can we convert all TI boards to driver >>>>>>>>>> model? >>>>>>>>> >>>>>>>>> We _really_ need some way to support more than one board per binary >>>>>>>>> before we can move everything to DM only. >>>>>>>>> >>>>>>>>> I think we can kind of do this today if we stick to using platform >>>>>>>>> data >>>>>>>>> for everything that's board-specific rather than SoC-defined. What >>>>>>>>> we >>>>>>>>> talked about at ELCE was auto-generating the pdata from the device >>>>>>>>> tree, >>>>>>>>> I think. >>>>>>>> >>>>>>>> We discussed this on IRC but since that doesn't exist as far as the >>>>>>>> mailing list is concerned... >>>>>>>> >>>>>>>> The current plan is: >>>>>>>> >>>>>>>> - Adjust build system to optionally build a u-boot.img in FIT format >>>>>>>> that includes the U-Boot binary and >1 device tree files >>>>>>>> - Adjust SPL to load this >>>>>>>> - Add a way for SPL to determine which device tree to select (by >>>>>>>> calling a board-specific function) >>>>>>>> - Have SPL pass this selected device tree to U-Boot when it starts >>>>>>> >>>>>>> Can dtb be sperated from the final u-boot.img, if using SPL? >>>>>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM >>>>>>> address. >>>>>>> And the dtb is shared with linux kernel. >>>>>>> >>>>>>> Regards, >>>>>>> Peng. >>>>>>>> >>>>>>>> Thus we should be able to support more than one board with a single >>>>>>>> U-Boot image. Of course this is not a perfect solution (e.g. it is >>>>>>>> inefficient since the DTs are likely to be largely the same) but it >>>>>>>> should be a good first step. >>>>>>>> >>>>>>>> I'm going to try this out with sunxi initially and plan to get some >>>>>>>> patches out by the end of the week. >> >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > > > -- > Jagan.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 2cdb110..b8c2498 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -155,6 +155,12 @@ config ZYNQ_QSPI Zynq QSPI IP core. This IP is used to connect the flash in 4-bit qspi, 8-bit dual stacked and shared 4-bit dual parallel. +config OMAP3_SPI + bool "McSPI driver for OMAP" + help + SPI master controller for OMAP24XX and later Multichannel SPI + (McSPI) modules. + endif # if DM_SPI config FSL_ESPI diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c index 95cdfa3..09fb1ef 100644 --- a/drivers/spi/omap3_spi.c +++ b/drivers/spi/omap3_spi.c @@ -11,10 +11,14 @@ * * Modified by Ruslan Araslanov <ruslan.araslanov@vitecmm.com> * + * Copyright (c) 2016 Christophe Ricard <christophe.ricard@gmail.com> + * - Added support for DM_SPI + * * SPDX-License-Identifier: GPL-2.0+ */ #include <common.h> +#include <dm.h> #include <spi.h> #include <malloc.h> #include <asm/io.h> @@ -22,9 +26,17 @@ #define SPI_WAIT_TIMEOUT 10 +#ifdef CONFIG_DM_SPI +static void spi_reset(struct udevice *dev) +#else static void spi_reset(struct omap3_spi_slave *ds) +#endif { unsigned int tmp; +#ifdef CONFIG_DM_SPI + struct omap3_spi_slave *ds = dev_get_priv(dev->parent); + +#endif writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, &ds->regs->sysconfig); do { @@ -39,20 +51,50 @@ static void spi_reset(struct omap3_spi_slave *ds) writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, &ds->regs->wakeupenable); } +#ifdef CONFIG_DM_SPI +static void omap3_spi_write_chconf(struct udevice *dev, int val) +#else static void omap3_spi_write_chconf(struct omap3_spi_slave *ds, int val) +#endif { - writel(val, &ds->regs->channel[ds->slave.cs].chconf); + unsigned int cs; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct omap3_spi_slave *ds = dev_get_priv(dev->parent); + + + cs = platdata->cs; +#else + cs = ds->slave.cs; +#endif + + writel(val, &ds->regs->channel[cs].chconf); /* Flash post writes to make immediate effect */ - readl(&ds->regs->channel[ds->slave.cs].chconf); + readl(&ds->regs->channel[cs].chconf); } +#ifdef CONFIG_DM_SPI +static void omap3_spi_set_enable(struct udevice *dev, int enable) +#else static void omap3_spi_set_enable(struct omap3_spi_slave *ds, int enable) +#endif { - writel(enable, &ds->regs->channel[ds->slave.cs].chctrl); + unsigned int cs; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct omap3_spi_slave *ds = dev_get_priv(dev->parent); + + cs = platdata->cs; +#else + cs = ds->slave.cs; +#endif + + writel(enable, &ds->regs->channel[cs].chctrl); /* Flash post writes to make immediate effect */ - readl(&ds->regs->channel[ds->slave.cs].chctrl); + readl(&ds->regs->channel[cs].chctrl); } +#ifndef CONFIG_DM_SPI void spi_init() { /* do nothing */ @@ -138,10 +180,32 @@ void spi_free_slave(struct spi_slave *slave) free(ds); } +int spi_cs_is_valid(unsigned int bus, unsigned int cs) +{ + return 1; +} +#endif + +#ifdef CONFIG_DM_SPI +static int omap3_spi_claim_bus(struct udevice *dev) +#else int spi_claim_bus(struct spi_slave *slave) +#endif { - struct omap3_spi_slave *ds = to_omap3_spi(slave); + unsigned int cs; + struct omap3_spi_slave *ds; unsigned int conf, div = 0; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct spi_slave *slave = dev_get_parent_priv(dev); + + ds = dev_get_priv(dev->parent); + cs = platdata->cs; + ds->freq = slave->max_hz; +#else + ds = to_omap3_spi(slave); + cs = ds->slave.cs; +#endif /* McSPI global module configuration */ @@ -149,7 +213,11 @@ int spi_claim_bus(struct spi_slave *slave) * setup when switching from (reset default) slave mode * to single-channel master mode */ +#ifdef CONFIG_DM_SPI + spi_reset(dev); +#else spi_reset(ds); +#endif conf = readl(&ds->regs->modulctrl); conf &= ~(OMAP3_MCSPI_MODULCTRL_STEST | OMAP3_MCSPI_MODULCTRL_MS); conf |= OMAP3_MCSPI_MODULCTRL_SINGLE; @@ -165,8 +233,7 @@ int spi_claim_bus(struct spi_slave *slave) } else div = 0xC; - conf = readl(&ds->regs->channel[ds->slave.cs].chconf); - + conf = readl(&ds->regs->channel[cs].chconf); /* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS * REVISIT: this controller could support SPI_3WIRE mode. */ @@ -184,7 +251,7 @@ int spi_claim_bus(struct spi_slave *slave) /* wordlength */ conf &= ~OMAP3_MCSPI_CHCONF_WL_MASK; - conf |= (ds->slave.wordlen - 1) << 7; + conf |= (slave->wordlen - 1) << 7; /* set chipselect polarity; manage with FORCE */ if (!(ds->mode & SPI_CS_HIGH)) @@ -209,113 +276,222 @@ int spi_claim_bus(struct spi_slave *slave) /* Transmit & receive mode */ conf &= ~OMAP3_MCSPI_CHCONF_TRM_MASK; +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, conf); +#else omap3_spi_write_chconf(ds,conf); +#endif return 0; } +#ifdef CONFIG_DM_SPI +int omap3_spi_release_bus(struct udevice *dev) +#else void spi_release_bus(struct spi_slave *slave) +#endif { +#ifndef CONFIG_DM_SPI struct omap3_spi_slave *ds = to_omap3_spi(slave); - +#endif /* Reset the SPI hardware */ +#ifdef CONFIG_DM_SPI + spi_reset(dev); +#else spi_reset(ds); +#endif + +#ifdef CONFIG_DM_SPI + return 0; +#endif } +#ifdef CONFIG_DM_SPI +int omap3_spi_write(struct udevice *dev, unsigned int len, const void *txp, + unsigned long flags) +#else int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp, unsigned long flags) +#endif { - struct omap3_spi_slave *ds = to_omap3_spi(slave); - int i; + struct omap3_spi_slave *ds; + int i, chconf; ulong start; - int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf); + unsigned int cs; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct spi_slave *slave = dev_get_parent_priv(dev); + + ds = dev_get_priv(dev->parent); + cs = platdata->cs; +#else + ds = to_omap3_spi(slave); + cs = ds->slave.cs; +#endif + + chconf = readl(&ds->regs->channel[cs].chconf); + +#ifdef CONFIG_DM_SPI /* Enable the channel */ - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN); + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN); +#else + /* Enable the channel */ + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN); +#endif chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK); +#ifdef CONFIG_DM_SPI + chconf |= (slave->wordlen - 1) << 7; +#else chconf |= (ds->slave.wordlen - 1) << 7; +#endif chconf |= OMAP3_MCSPI_CHCONF_TRM_TX_ONLY; chconf |= OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif for (i = 0; i < len; i++) { /* wait till TX register is empty (TXS == 1) */ start = get_timer(0); - while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) & + while (!(readl(&ds->regs->channel[cs].chstat) & OMAP3_MCSPI_CHSTAT_TXS)) { if (get_timer(start) > SPI_WAIT_TIMEOUT) { printf("SPI TXS timed out, status=0x%08x\n", - readl(&ds->regs->channel[ds->slave.cs].chstat)); + readl(&ds->regs->channel[cs].chstat)); return -1; } } + /* Write the data */ - unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx; + unsigned int *tx = &ds->regs->channel[cs].tx; +#ifdef CONFIG_DM_SPI + if (slave->wordlen > 16) +#else if (ds->slave.wordlen > 16) +#endif writel(((u32 *)txp)[i], tx); +#ifdef CONFIG_DM_SPI + else if (slave->wordlen > 8) +#else else if (ds->slave.wordlen > 8) +#endif writel(((u16 *)txp)[i], tx); else writel(((u8 *)txp)[i], tx); } /* wait to finish of transfer */ - while ((readl(&ds->regs->channel[ds->slave.cs].chstat) & + while ((readl(&ds->regs->channel[cs].chstat) & (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS)) != - (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS)); + (OMAP3_MCSPI_CHSTAT_EOT | OMAP3_MCSPI_CHSTAT_TXS)) + ; +#ifdef CONFIG_DM_SPI + /* Disable the channel otherwise the next immediate RX will get affected */ + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS); +#else /* Disable the channel otherwise the next immediate RX will get affected */ - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS); + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS); +#endif if (flags & SPI_XFER_END) { chconf &= ~OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif } + return 0; } +#ifdef CONFIG_DM_SPI +int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp, + unsigned long flags) +#else int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp, unsigned long flags) +#endif { - struct omap3_spi_slave *ds = to_omap3_spi(slave); - int i; + struct omap3_spi_slave *ds; + int i, chconf; ulong start; - int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf); + unsigned int cs; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct spi_slave *slave = dev_get_parent_priv(dev); + + ds = dev_get_priv(dev->parent); + cs = platdata->cs; +#else + ds = to_omap3_spi(slave); + cs = ds->slave.cs; +#endif + chconf = readl(&ds->regs->channel[cs].chconf); + +#ifdef CONFIG_DM_SPI + /* Enable the channel */ + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN); +#else /* Enable the channel */ - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN); + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN); +#endif chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK); +#ifdef CONFIG_DM_SPI + chconf |= (slave->wordlen - 1) << 7; +#else chconf |= (ds->slave.wordlen - 1) << 7; +#endif chconf |= OMAP3_MCSPI_CHCONF_TRM_RX_ONLY; chconf |= OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif - writel(0, &ds->regs->channel[ds->slave.cs].tx); + writel(0, &ds->regs->channel[cs].tx); for (i = 0; i < len; i++) { start = get_timer(0); /* Wait till RX register contains data (RXS == 1) */ - while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) & + while (!(readl(&ds->regs->channel[cs].chstat) & OMAP3_MCSPI_CHSTAT_RXS)) { if (get_timer(start) > SPI_WAIT_TIMEOUT) { printf("SPI RXS timed out, status=0x%08x\n", - readl(&ds->regs->channel[ds->slave.cs].chstat)); + readl(&ds->regs->channel[cs].chstat)); return -1; } } - /* Disable the channel to prevent furher receiving */ if(i == (len - 1)) - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS); +#ifdef CONFIG_DM_SPI + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS); +#else + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS); +#endif /* Read the data */ - unsigned int *rx = &ds->regs->channel[ds->slave.cs].rx; + unsigned int *rx = &ds->regs->channel[cs].rx; +#ifdef CONFIG_DM_SPI + if (slave->wordlen > 16) +#else if (ds->slave.wordlen > 16) +#endif ((u32 *)rxp)[i] = readl(rx); +#ifdef CONFIG_DM_SPI + else if (slave->wordlen > 8) +#else else if (ds->slave.wordlen > 8) +#endif ((u16 *)rxp)[i] = (u16)readl(rx); else ((u8 *)rxp)[i] = (u8)readl(rx); @@ -323,89 +499,177 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp, if (flags & SPI_XFER_END) { chconf &= ~OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif } return 0; } +#ifdef CONFIG_DM_SPI +/*McSPI Transmit Receive Mode*/ +int omap3_spi_txrx(struct udevice *dev, unsigned int len, + const void *txp, void *rxp, unsigned long flags) +#else /*McSPI Transmit Receive Mode*/ int omap3_spi_txrx(struct spi_slave *slave, unsigned int len, const void *txp, void *rxp, unsigned long flags) +#endif { - struct omap3_spi_slave *ds = to_omap3_spi(slave); + struct omap3_spi_slave *ds; ulong start; - int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf); + int chconf; int i=0; + unsigned int cs; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct spi_slave *slave = dev_get_parent_priv(dev); + + ds = dev_get_priv(dev->parent); + cs = platdata->cs; +#else + ds = to_omap3_spi(slave); + cs = ds->slave.cs; +#endif + chconf = readl(&ds->regs->channel[cs].chconf); + +#ifdef CONFIG_DM_SPI + /*Enable SPI channel*/ + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN); +#else /*Enable SPI channel*/ - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN); + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN); +#endif /*set TRANSMIT-RECEIVE Mode*/ chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK); +#ifdef CONFIG_DM_SPI + chconf |= (slave->wordlen - 1) << 7; +#else chconf |= (ds->slave.wordlen - 1) << 7; +#endif chconf |= OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif /*Shift in and out 1 byte at time*/ for (i=0; i < len; i++){ /* Write: wait for TX empty (TXS == 1)*/ start = get_timer(0); - while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) & + while (!(readl(&ds->regs->channel[cs].chstat) & OMAP3_MCSPI_CHSTAT_TXS)) { if (get_timer(start) > SPI_WAIT_TIMEOUT) { printf("SPI TXS timed out, status=0x%08x\n", - readl(&ds->regs->channel[ds->slave.cs].chstat)); + readl(&ds->regs->channel[cs].chstat)); return -1; } } /* Write the data */ - unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx; + unsigned int *tx = &ds->regs->channel[cs].tx; +#ifdef CONFIG_DM_SPI + if (slave->wordlen > 16) +#else if (ds->slave.wordlen > 16) +#endif writel(((u32 *)txp)[i], tx); +#ifdef CONFIG_DM_SPI + else if (slave->wordlen > 8) +#else else if (ds->slave.wordlen > 8) +#endif writel(((u16 *)txp)[i], tx); else writel(((u8 *)txp)[i], tx); /*Read: wait for RX containing data (RXS == 1)*/ start = get_timer(0); - while (!(readl(&ds->regs->channel[ds->slave.cs].chstat) & + while (!(readl(&ds->regs->channel[cs].chstat) & OMAP3_MCSPI_CHSTAT_RXS)) { if (get_timer(start) > SPI_WAIT_TIMEOUT) { printf("SPI RXS timed out, status=0x%08x\n", - readl(&ds->regs->channel[ds->slave.cs].chstat)); + readl(&ds->regs->channel[cs].chstat)); return -1; } } /* Read the data */ - unsigned int *rx = &ds->regs->channel[ds->slave.cs].rx; + unsigned int *rx = &ds->regs->channel[cs].rx; +#ifdef CONFIG_DM_SPI + if (slave->wordlen > 16) +#else if (ds->slave.wordlen > 16) +#endif ((u32 *)rxp)[i] = readl(rx); +#ifdef CONFIG_DM_SPI + else if (slave->wordlen > 8) +#else else if (ds->slave.wordlen > 8) +#endif ((u16 *)rxp)[i] = (u16)readl(rx); else ((u8 *)rxp)[i] = (u8)readl(rx); } + +#ifdef CONFIG_DM_SPI + /* Disable the channel */ + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS); +#else /* Disable the channel */ - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS); + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS); +#endif /*if transfer must be terminated disable the channel*/ if (flags & SPI_XFER_END) { chconf &= ~OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif } return 0; } +#ifdef CONFIG_DM_SPI +int omap3_spi_xfer(struct udevice *dev, unsigned int bitlen, + const void *dout, void *din, unsigned long flags) +#else int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout, void *din, unsigned long flags) +#endif { - struct omap3_spi_slave *ds = to_omap3_spi(slave); - unsigned int len; + struct omap3_spi_slave *ds; + unsigned int len, cs; int ret = -1; +#ifdef CONFIG_DM_SPI + struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev); + struct spi_slave *slave = dev_get_parent_priv(dev); + + ds = dev_get_priv(dev->parent); + cs = platdata->cs; +#else + ds = to_omap3_spi(slave); + cs = ds->slave.cs; +#endif +#ifdef CONFIG_DM_SPI + if (slave->wordlen < 4 || slave->wordlen > 32) { + printf("omap3_spi: invalid wordlen %d\n", slave->wordlen); + return -1; + } + + if (bitlen % slave->wordlen) + return -1; + + len = bitlen / slave->wordlen; +#else if (ds->slave.wordlen < 4 || ds->slave.wordlen > 32) { printf("omap3_spi: invalid wordlen %d\n", ds->slave.wordlen); return -1; @@ -415,41 +679,104 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, return -1; len = bitlen / ds->slave.wordlen; +#endif if (bitlen == 0) { /* only change CS */ - int chconf = readl(&ds->regs->channel[ds->slave.cs].chconf); + int chconf = readl(&ds->regs->channel[cs].chconf); if (flags & SPI_XFER_BEGIN) { - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN); +#ifdef CONFIG_DM_SPI + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_EN); +#else + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_EN); +#endif chconf |= OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); +#else + omap3_spi_write_chconf(ds, chconf); +#endif } if (flags & SPI_XFER_END) { chconf &= ~OMAP3_MCSPI_CHCONF_FORCE; - omap3_spi_write_chconf(ds,chconf); - omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS); +#ifdef CONFIG_DM_SPI + omap3_spi_write_chconf(dev, chconf); + omap3_spi_set_enable(dev, OMAP3_MCSPI_CHCTRL_DIS); +#else + omap3_spi_write_chconf(ds, chconf); + omap3_spi_set_enable(ds, OMAP3_MCSPI_CHCTRL_DIS); +#endif } ret = 0; } else { +#ifdef CONFIG_DM_SPI + if (dout != NULL && din != NULL) + ret = omap3_spi_txrx(dev, len, dout, din, flags); + else if (dout != NULL) + ret = omap3_spi_write(dev, len, dout, flags); + else if (din != NULL) + ret = omap3_spi_read(dev, len, din, flags); +#else if (dout != NULL && din != NULL) ret = omap3_spi_txrx(slave, len, dout, din, flags); else if (dout != NULL) ret = omap3_spi_write(slave, len, dout, flags); else if (din != NULL) ret = omap3_spi_read(slave, len, din, flags); +#endif } return ret; } -int spi_cs_is_valid(unsigned int bus, unsigned int cs) +void spi_cs_activate(struct spi_slave *slave) { - return 1; } -void spi_cs_activate(struct spi_slave *slave) +void spi_cs_deactivate(struct spi_slave *slave) { } -void spi_cs_deactivate(struct spi_slave *slave) +#ifdef CONFIG_DM_SPI +static int omap3_spi_probe(struct udevice *dev) { + struct omap3_spi_slave *ds = dev_get_priv(dev); + + ds->regs = (struct mcspi *)dev_get_addr(dev); + + return 0; } + +static int omap3_spi_set_speed(struct udevice *dev, unsigned int speed) +{ + return 0; +} + +static int omap3_spi_set_mode(struct udevice *bus, uint mode) +{ + return 0; +} + + +static const struct dm_spi_ops omap3_spi_ops = { + .claim_bus = omap3_spi_claim_bus, + .release_bus = omap3_spi_release_bus, + .xfer = omap3_spi_xfer, + .set_speed = omap3_spi_set_speed, + .set_mode = omap3_spi_set_mode, +}; + +static const struct udevice_id omap3_spi_ids[] = { + { .compatible = "ti,omap2-mcspi" }, + { .compatible = "ti,omap4-mcspi" }, + { } +}; + +U_BOOT_DRIVER(omap3_spi) = { + .name = "omap3_spi", + .id = UCLASS_SPI, + .of_match = omap3_spi_ids, + .probe = omap3_spi_probe, + .ops = &omap3_spi_ops, + .priv_auto_alloc_size = sizeof(struct omap3_spi_slave), +}; +#endif diff --git a/drivers/spi/omap3_spi.h b/drivers/spi/omap3_spi.h index 6a07c6d..a974ca3 100644 --- a/drivers/spi/omap3_spi.h +++ b/drivers/spi/omap3_spi.h @@ -88,22 +88,34 @@ struct mcspi { #define OMAP3_MCSPI_WAKEUPENABLE_WKEN BIT(0) struct omap3_spi_slave { +#ifndef CONFIG_DM_SPI struct spi_slave slave; +#endif struct mcspi *regs; unsigned int freq; unsigned int mode; }; +#ifndef CONFIG_DM_SPI static inline struct omap3_spi_slave *to_omap3_spi(struct spi_slave *slave) { return container_of(slave, struct omap3_spi_slave, slave); } +#endif +#ifdef CONFIG_DM_SPI +int omap3_spi_txrx(struct udevice *dev, unsigned int len, const void *txp, + void *rxp, unsigned long flags); +int omap3_spi_write(struct udevice *dev, unsigned int len, const void *txp, + unsigned long flags); +int omap3_spi_read(struct udevice *dev, unsigned int len, void *rxp, + unsigned long flags); +#else int omap3_spi_txrx(struct spi_slave *slave, unsigned int len, const void *txp, void *rxp, unsigned long flags); int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp, unsigned long flags); int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp, unsigned long flags); - +#endif #endif /* _OMAP3_SPI_H_ */
Convert omap3_spi driver to DM and keep compatibility with previous mode. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> --- drivers/spi/Kconfig | 6 + drivers/spi/omap3_spi.c | 439 ++++++++++++++++++++++++++++++++++++++++++------ drivers/spi/omap3_spi.h | 14 +- 3 files changed, 402 insertions(+), 57 deletions(-)