On 2 July 2015 at 12:33, Jagan Teki jteki@openedev.com wrote:
On 1 July 2015 at 02:38, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On 30 June 2015 at 14:31, Tom Rini trini@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@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)
- 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!