[U-Boot] [PATCH v3 0/29] Introduce driver model support for SPI, SPI flash, cros_ec

[Simon Glass]

Hi,

On 10 October 2014 07:51, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> On 10 October 2014 19:05, Simon Glass <sjg at chromium.org> wrote:
>> Hi Jagan,
>>
>> On 10 October 2014 07:30, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On 10 October 2014 07:36, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On 9 October 2014 04:33, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>> On 9 October 2014 02:03, Simon Glass <sjg at chromium.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 29 September 2014 13:34, Simon Glass <sjg at chromium.org> wrote:
>>>>>>> Up until now driver model has not been used for any type of bus. Buses
>>>>>>> have some unique properties and needs, so we cannot claim that driver
>>>>>>> model can cover all the common cases unless we have converted a bus over
>>>>>>> to driver model.
>>>>>>>
>>>>>>> SPI is a reasonable choice for this next step. It has a fairly simple
>>>>>>> API and not too many dependencies. The main one is SPI flash so we may
>>>>>>> as well convert that also. Since the boards I test with have cros_ec I
>>>>>>> have also included that, for SPI only.
>>>>>>>
>>>>>>> The technique used is make use of driver model's supported data structures
>>>>>>> to hold information currently kept by each subsystem in a private data
>>>>>>> structure. Since 'struct spi_slave' relates to the slave device on the bus
>>>>>>> it is stored in the 'parent' data with each child device of the bus.
>>>>>>> Since 'struct spi_flash' is a standard interface used for each SPI flash
>>>>>>> driver, it is stored in the SPI FLash uclass's private data for each
>>>>>>> device.
>>>>>>>
>>>>>>> New defines are created to enable driver model for each subsystem. These
>>>>>>> are:
>>>>>>>
>>>>>>>    CONFIG_DM_SPI
>>>>>>>    CONFIG_DM_SPI_FLASH
>>>>>>>    CONFIG_DM_CROS_EC
>>>>>>>
>>>>>>> This allows us to move some boards and drivers to driver model, while
>>>>>>> leaving others behind. A 'big bang' conversion of everything to driver
>>>>>>> model, even at a subsystem level, is never going to work.
>>>>>>>
>>>>>>> There is some cost in changing the uclass interface after it is created,
>>>>>>> so if you have limited time, please spend it reviewing the uclass
>>>>>>> interfaces in spi.h and spi_flash.h. These need to be supported by each
>>>>>>> driver, so changing them later may involve changing multiple drivers.
>>>>>>>
>>>>>>> To assist with the conversion of other SPI drivers, a README file is
>>>>>>> added to walk through the process.
>>>>>>>
>>>>>>> So far, sandbox, exynos and tegra drivers are converted over.
>>>>>>>
>>>>>>> As always, driver model patches are available at u-boot-dm.git branch
>>>>>>> 'working'. There is a branch for just this series called 'spi-working'.
>>>>>>
>>>>>> I think this has had enough time out there. So I will push this to
>>>>>> dm/next later this week.
>>>>>
>>>>> Sorry - I need to review a lot wrt v3.
>>>>> I do understand that it has been in enough time, but this causes a
>>>>> significant changes on
>>>>> entire framework, please hold on for a while I need to think with
>>>>> respect on qspi stuff with in
>>>>> the spi framework.
>>>>
>>>> Well I'm not sure it supports setting of the flags that are needed for
>>>> that. I don't have a platform to test with anyway.
>>>>
>>>> On the other hand adding that support to driver model could easily be
>>>> a separate effort. I don't see a good reason to hold up the core SPI /
>>>> SPI flash support.
>>>
>>> Partially agreed at this moment, let me think and review the whole stuff.
>>> I would place all these stuff on to my master-next, once I'm OK.
>>>
>>> Any changes based on my strategy wrt qspi stuff - I may change these.
>>> But I will push all these later on the 13/10 release.
>>>
>>> Comments?
>>
>> Actually I'd like to bring this through the dm tree as I have a lot of
>> dependent series that need to go that way. What is your timeline for
>> further review of v3? I'm planning to push this to dm/next soon.
>
> OK, I will give my first level comments by tomorrow (IST)
> May be this will prolong least by next week end, if something need to change.
>

OK I'll take a look at your comments when I get them.

>>
>> I suggest adding the qspi stuff to sandbox. Then it will be easier to
>> test with driver model. What do you think?
>
> Will comment again on this.

OK.

Regards,
Simon