Hi Jagan, On 9 July 2015 at 14:31, Jagan Teki <jt...@openedev.com> wrote: > On 2 July 2015 at 12:33, Jagan Teki <jt...@openedev.com> wrote: >> On 1 July 2015 at 02:38, Simon Glass <s...@chromium.org> wrote: >>> Hi Tom, >>> >>> On 30 June 2015 at 14:31, Tom Rini <tr...@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 <york...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
