Hi,
On Thu, May 10, 2012 at 3:15 AM, Thomas Abraham
<thomas.abraham@xxxxxxxxxx> wrote:
> Hi Olof,
>
> On 2 May 2012 23:37, Olof Johansson <olof@xxxxxxxxx> wrote:
>> Hi,
>
> [...]
>
>>> +# Slots: The slot specific information are contained within child-nodes with
>>> + each child-node representing a supported slot. There should be atleast one
>>> + child node representing a card slot. The name of the slot child node should
>>> + be 'slot{n}' where n is the unique number of the slot connnected to the
>>> + controller. The following are optional properties which can be included in
>>> + the slot child node.
>>
>> Since we're talking slots / cards on a bus, I think the addressing
>> model would be useful here. So in the main controller node:
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> And then each slot would need a reg property and possibly unit address:
>>
>> slot {
>> reg = <0>;
>> ...
>> };
>>
>> (unit addresses on the slots are only needed if they can't be
>> disambiguated by name, so not needed if you only have one slot).
>>
>
> Is the addressing model as described above needed in this case? The
> address for a slot is not used by the controller driver code and is
> just a virtual number. It would be sufficient to represent the nodes
> representing the slots with a unique name.
The driver has the concept of slot IDs (slot->id struct member), and
the hardware definitely enumerates them.
So, I think it makes sense to give a chance to enumerate the slots in
the device tree. Otherwise, how do you know which one is which on
hardware? It also opens up the flexibility to have the same name for
both slots if it makes sense to describe a board that way.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
