esdhc binding compatiable

esdhc binding compatiable

[Kumar Gala]

There has been some discussion on various lists about what the binding  
doc says w/regards to compat binding for eSHDC on 83xx, 85xx, pxxxx.

My thinking is that we wanted to avoid "fsl,eshdc" as possibly being  
to generic (some theory that esdhc might be same or similar controller  
on iMX devices from FSL).  If that's the case I'm thinking something  
like:

fsl,pq-eshdc	(covers 83xx, 85xx family)
fsl,qoirq-esdhc (covers any new p2xxx, p4xxx, etc..)

and if imx needs it

fsl,imx-esdhc

this would be the base compatible.  In addition to that we've  
discussed having a fsl,pq-eshdc-vX.Y compat to match the IP version in  
the specific SoC.

thoughts?

- k

Re: esdhc binding compatiable

[Scott Wood]

On Mon, May 04, 2009 at 08:54:28AM -0500, Kumar Gala wrote:
> There has been some discussion on various lists about what the binding  
> doc says w/regards to compat binding for eSHDC on 83xx, 85xx, pxxxx.
> 
> My thinking is that we wanted to avoid "fsl,eshdc" as possibly being  
> to generic (some theory that esdhc might be same or similar controller  
> on iMX devices from FSL).  If that's the case I'm thinking something  
> like:

If it's the *same* controller, then it should have the same compatible
(and the same driver).

> fsl,pq-eshdc	(covers 83xx, 85xx family)
> fsl,qoirq-esdhc (covers any new p2xxx, p4xxx, etc..)

And then a new one when marketing changes the name again?  It was first
introduced on a "pq" chip (among those chips which are currently using a
device tree at all), so use "pq" if we need a prefix.

Newer versions could have "qoriq" as a prefix if those versions never
appeared on a "pq" chip.

I'm inclined to leave the prefix off, though, if the block is truly
shared (naming and version numbering intact) across Freescale.

> and if imx needs it
> 
> fsl,imx-esdhc
> 
> this would be the base compatible.  In addition to that we've  
> discussed having a fsl,pq-eshdc-vX.Y compat to match the IP version in  
> the specific SoC.

I think we should only have the versioned compatible (with significant
older but compatible versions listed additionally).  Otherwise it's
not obvious that "fsl,esdhc" is really "fsl,esdhc-v1.0".

-Scott

Re: esdhc binding compatiable

[Kim Phillips]

On Mon, 4 May 2009 16:11:10 -0500
Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> I'm inclined to leave the prefix off, though, if the block is truly
> shared (naming and version numbering intact) across Freescale.

agreed.

> > this would be the base compatible.  In addition to that we've  
> > discussed having a fsl,pq-eshdc-vX.Y compat to match the IP version in  
> > the specific SoC.
> 
> I think we should only have the versioned compatible (with significant
> older but compatible versions listed additionally).  Otherwise it's

I'd say 'all' instead of 'significant', because one never knows what
the driver might think significant as it gets developed further down
the road.

> not obvious that "fsl,esdhc" is really "fsl,esdhc-v1.0".

minor nit:  I'd remove the "-v" to make it "fsl,esdhc1.0".  It's really
no loss of clarity, and it saves space.

Kim

Re: esdhc binding compatiable

[Scott Wood]

Kim Phillips wrote:
>> I think we should only have the versioned compatible (with significant
>> older but compatible versions listed additionally).  Otherwise it's
> 
> I'd say 'all' instead of 'significant', because one never knows what
> the driver might think significant as it gets developed further down
> the road.

I wanted to leave some room for trimming of what could be an excessively 
long list (which is costly not just in terms of the bits, but in the 
verification of compatibility with each version).

>> not obvious that "fsl,esdhc" is really "fsl,esdhc-v1.0".
> 
> minor nit:  I'd remove the "-v" to make it "fsl,esdhc1.0".  It's really
> no loss of clarity, and it saves space.

I don't really care one way or another about the "v", but I like the 
dash.  It looks a little too smooshed together without it.

-Scott

Re: esdhc binding compatiable

[Kumar Gala]

>>> not obvious that "fsl,esdhc" is really "fsl,esdhc-v1.0".
>> minor nit:  I'd remove the "-v" to make it "fsl,esdhc1.0".  It's  
>> really
>> no loss of clarity, and it saves space.
>
> I don't really care one way or another about the "v", but I like the  
> dash.  It looks a little too smooshed together without it.

Agreed, and it resolves things like ddr2-1.0 or ddr2-v1.0.

- k

Re: esdhc binding compatiable

[Kumar Gala]

On May 4, 2009, at 4:11 PM, Scott Wood wrote:

> On Mon, May 04, 2009 at 08:54:28AM -0500, Kumar Gala wrote:
>> There has been some discussion on various lists about what the  
>> binding
>> doc says w/regards to compat binding for eSHDC on 83xx, 85xx, pxxxx.
>>
>> My thinking is that we wanted to avoid "fsl,eshdc" as possibly being
>> to generic (some theory that esdhc might be same or similar  
>> controller
>> on iMX devices from FSL).  If that's the case I'm thinking something
>> like:
>
> If it's the *same* controller, then it should have the same compatible
> (and the same driver).

Define the *same*.  I believe things might be 90/95% the same but  
there is probably some 5/10% SoC unique integration changes between an  
eSDHC on a PPC vs ARM SoC from FSL.  For example in the imx version  
they have a few registers called ADMA Error Status & ADMA Address  
which we don't have on PQ devices.

- k

Re: esdhc binding compatiable

[Mitch Bradley]

>
> On May 4, 2009, at 4:11 PM, Scott Wood wrote:
>
>> On Mon, May 04, 2009 at 08:54:28AM -0500, Kumar Gala wrote:
>>> There has been some discussion on various lists about what the binding
>>> doc says w/regards to compat binding for eSHDC on 83xx, 85xx, pxxxx.
>>>
>>> My thinking is that we wanted to avoid "fsl,eshdc" as possibly being
>>> to generic (some theory that esdhc might be same or similar controller
>>> on iMX devices from FSL).  If that's the case I'm thinking something
>>> like:
>>
>> If it's the *same* controller, then it should have the same compatible
>> (and the same driver).
>
> Define the *same*.  I believe things might be 90/95% the same but 
> there is probably some 5/10% SoC unique integration changes between an 
> eSDHC on a PPC vs ARM SoC from FSL.  For example in the imx version 
> they have a few registers called ADMA Error Status & ADMA Address 
> which we don't have on PQ devices.


If the devices have the same basic programming model - which is pretty 
clearly the case if they are 90% identical - then you would want to 
maintain one driver instead of two.  The compatible property would be 
the same to bind the one driver.  Invent additional properties as 
necessary to describe variations.  Try to describe the differences 
directly, e.g. "has-adma-address", instead of having an ever-growing 
table in the driver that effectively says "if this is variant XYX from 
manufacturer PDQ, then we happen to know that has an ADMA address 
register".  That prevents having to rev the driver for every new model - 
you only have to rev the driver when a new kind of variation is invented.