[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Jagan Teki]

On 8 February 2016 at 23:10, Tom Rini <trini at 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 at 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 at gmail.com> wrote:
>> >>>>>Convert omap3_spi driver to DM and keep compatibility with previous
>> >>>>>mode.
>> >>>>>
>> >>>>>Signed-off-by: Christophe Ricard <christophe-h.ricard at 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.

-- 
Jagan.