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

[Christophe Ricard <christophe.ricard@gmail.com>]

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.