[U-Boot] [PATCH v3 00/54] dm: Introduce new driver model uclasses

[Simon Glass]

Hi Jagan,

On 9 July 2015 at 14:31, Jagan Teki <jteki at openedev.com> wrote:
> On 2 July 2015 at 12:33, Jagan Teki <jteki at openedev.com> wrote:
>> On 1 July 2015 at 02:38, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Tom,
>>>
>>> On 30 June 2015 at 14:31, Tom Rini <trini at konsulko.com> wrote:
>>>> On Tue, Jun 30, 2015 at 01:10:45PM -0700, York Sun wrote:
>>>>>
>>>>>
>>>>> On 06/30/2015 12:01 PM, Tom Rini wrote:
>>>>> > On Tue, Jun 30, 2015 at 11:42:41AM -0700, York Sun wrote:
>>>>> >>
>>>>> >>
>>>>> >> On 06/30/2015 11:33 AM, Simon Glass wrote:
>>>>> >>> Hi York,
>>>>> >>>
>>>>> >>> On 30 June 2015 at 10:08, York Sun <yorksun at freescale.com> wrote:
>>>>> >>>> Simon,
>>>>> >>>>
>>>>> >>>> Does the dm force using device tree? I was reviewing a patch set regarding SPI
>>>>> >>>> and found OF_CONTROL has to be selected in order to get the driver model happy.
>>>>> >>>>
>>>>> >>>> My understanding of the driver model is both device tree and platform data are
>>>>> >>>> allowed, like Linux. Is that still true?
>>>>> >>>
>>>>> >>> For buses you need device tree. I was rather hoping that we could
>>>>> >>> avoid platform data on platforms that have device tree. What is the
>>>>> >>> point?
>>>>> >>>
>>>>> >>
>>>>> >> Simon,
>>>>> >>
>>>>> >> It happens on a platform not using device tree, but DM will be used.
>>>>> >>
>>>>> >> I prefer DM to have both, rather than being forced to use device tree, unless we
>>>>> >> are going to enforce using device tree on all new platforms. Since device tree
>>>>> >> is still an option, I feel it is best to support platform data, like Linux
>>>>> >> drivers do.
>>>>> >
>>>>> > Well, to what end?  My recollection is that in short, the kernel has
>>>>> > both since platform data predates device tree (and converting platform
>>>>> > data to device tree is still a thing that happens).  But we're trying to
>>>>> > skip that intermediate step.  Are there platforms where you do not plan
>>>>> > to use a device tree, ever?
>>
>> My observations with this approach (dm-spi)
>>
>> 1. We're planning to move spi driver with dm support but many of the
>> boards which
>>     used spi drivers don't have dts support yet.
>> 2. I think dm will progress only when dts support progresses.
>>
>> The only solution for this - if we need to move any driver to dm then check for
>> dts on particular board this driver uses and move that board to have
>> dts support.
>>
>> Any comments?
>
> Any suggestions?
>

Yes, or maybe enable DTS for the board? It's not that hard. E.g. see
this for Raspberry Pi:

http://patchwork.ozlabs.org/patch/492694/
http://patchwork.ozlabs.org/patch/492698/
http://patchwork.ozlabs.org/patch/492700/

>>
>>>>> >
>>>>>
>>>>> Tom,
>>>>>
>>>>> I am not against using device tree at all. It is more dynamic and flexible. But
>>>>> I don't see any indication that we favor device tree over pdata (except in the
>>>>> code). If we are skipping pdata for new drivers, a clear message will be
>>>>> helpful. That's what I am trying to get clarification.
>>>>
>>>> OK.  I think we'd agreed to that at ELC-E last year and it might have
>>>> been in a few here-and-there emails but it's worth spelling out
>>>> somewhere.
>>>>
>>>> Hey Simon?  doc/driver-model/README.txt has a pdata example, so maybe
>>>> the answer here is it's time to update README.txt in a few ways :)
>>>
>>> I'll prepare a patch.
>
> thanks!
> --
> Jagan | openedev.

Regards,
Simon