On 8/9/2011 11:49 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =<0x20000 0x200 0x24000 0x200>;
foo-reg =<0>;
bar-reg =<1>;
};
That's a little nasty. A reg-names = "foo", "bar"; would probably be
better.
Yep, I agree.
And what about something like that?
reg =<0x20000 0x200>, "foo",
<0x20000 0x200>, "bar" ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = "foo_wrapper";
start =<0x10000>;
end =<0x200>;
}
reg {
name = "foo";
start =<0x20000>;
end =<0x200>;
}
}
A little bit more verbose, but at least we can add any attribute we want.
That won't work either because that also breaks the existing 'reg'
binding. Anything you do will need to supplement the existing
binding without changing it in an incompatible way.
OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
reg_named...?
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
