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

[Jagan Teki]

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?

>
>>>> >
>>>>
>>>> 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.