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

From: Christophe Ricard <christophe.ricard@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM
Date: Sat, 6 Feb 2016 23:27:21 +0100	[thread overview]
Message-ID: <56B67349.8010502@gmail.com> (raw)
In-Reply-To: <20160126015541.GB13773@linux-7smt.suse>

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 at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot