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

[Jagan Teki]

On 11 February 2016 at 20:31, Jagan Teki <jteki at openedev.com> wrote:
> On 11 February 2016 at 02:30, Christophe Ricard
> <christophe.ricard at 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 at openedev.com> wrote:
>>>>
>>>> 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.
>>>
>>> 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 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.
>>
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
> --
> Jagan.



-- 
Jagan.