Hi,
On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote:
So, I actually agree that in the long term getting resource names in
the DT would be a generally good thing.
But doing so is a *huge* change in one of the very core semantics of
all the DT bindings. It's not something that
On Tue, Aug 30, 2011 at 12:27:24PM +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote:
So, I actually agree that in the long term getting resource names in
the DT would be a generally good thing.
But doing so is a *huge* change in one of the
On Saturday 27 August 2011, Paul Walmsley wrote:
On Sat, 27 Aug 2011, Arnd Bergmann wrote:
Right, and I guess we can simply ignore DMA and ioport resources because
they are extremely rare, right?
DMA resources are quite widely used.
For example, looking at the SoCs with some
On Sunday 28 August 2011, David Gibson wrote:
Right, and I guess we can simply ignore DMA and ioport resources because
they
are extremely rare, right?
Well, remember it's where resources can appear in the DT node that
matters, not what the types are in the platform device. ioports will
On Sat, Aug 27, 2011 at 03:47:55PM -0600, Paul Walmsley wrote:
Certainly, from a kernel development perspective, one can decide to just
dump this kind of DT generation problem back on the hardware vendors.
But it seems more efficient and less error-prone to simply remove both
mapping
On Fri, Aug 26, 2011 at 04:13:15PM +0200, Cousson, Benoit wrote:
On 8/26/2011 12:58 PM, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
Seriously, how many times do I have to say it?
[...]
Insisting that the names come from the DT is to mistakenly think of
the DT as an
On Sat, Aug 27, 2011 at 08:13:59PM +0200, Arnd Bergmann wrote:
On Sunday 28 August 2011 00:37:36 David Gibson wrote:
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you
On Sun, 28 Aug 2011, David Gibson wrote:
I've never been very clear on what exactly DMA resources cover,
DMA resource data are usually DMA request line ID numbers.
DMA request lines are dedicated, unidirectional hardware signals from I/O
devices to one or more independent DMA
On Sun, Aug 28, 2011 at 05:06:43PM -0600, Paul Walmsley wrote:
DMA resource data are usually DMA request line ID numbers.
Not always. On ARMs development platforms, we ended up using strings -
because we've ended up with a DMA controller with N request signals,
where the first three request
Hi,
one case that I forgot to mention:
On Sun, 28 Aug 2011, Paul Walmsley wrote:
Several upstream device drivers get their DMA request line IDs from the
device data format[14][15][16]. But more drivers should be doing this
than currently are[17]:
- the device driver author may have
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you open code it this way then yes, it's silly. But what about
something like this:
static struct of_device_id
On Sunday 28 August 2011 00:37:36 David Gibson wrote:
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you open code it this way then yes, it's silly. But what about
On Sat, 27 Aug 2011, Arnd Bergmann wrote:
Right, and I guess we can simply ignore DMA and ioport resources because
they are extremely rare, right?
DMA resources are quite widely used.
For example, looking at the SoCs with some publicly-available
documentation, the Motorola i.MX51 reference
On Fri, 26 Aug 2011, Arnd Bergmann wrote:
I don't think anyone was talking about converting driver /to/ the
_byname method
For drivers that use multiple resources of the same type, converting those
to use platform_get_resource_byname() does indeed seem appropriate.
By the way, the same IP
On Fri, 26 Aug 2011, David Gibson wrote:
static struct of_device_id foodevice_of_match[] __devinitdata = {
{ .compatible = foocorp,foodevice1234,
.resource_names = {base_regs, extra_regs, }, },
{ .compatible = foocorp,foodevice1239,
.resource_names = {base_regs,
On Friday 26 August 2011, David Gibson wrote:
Seriously, how many times do I have to say it?
Using _byname in drivers DOES NOT require adding names to the DT.
All it needs is some glue logic to attach names as the device tree is
read. This is properly thought of as part of the code
On Thu, 25 Aug 2011, Arnd Bergmann wrote:
It's not at all about whether the Linux codein drivers/of supports this
or not, adding it would be trivial. The point is that it would be
*wrong* to add it because there already exists a way to identify every
resource in the device tree and we should
On 8/26/2011 12:58 PM, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
Seriously, how many times do I have to say it?
[...]
Insisting that the names come from the DT is to mistakenly think of
the DT as an extension of the kernel's internal interfaces, instead of
as the
On Fri, Aug 26, 2011 at 12:58:32PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
Seriously, how many times do I have to say it?
Using _byname in drivers DOES NOT require adding names to the DT.
All it needs is some glue logic to attach names as the
On Friday 26 August 2011, David Gibson wrote:
If you open code it this way then yes, it's silly. But what about
something like this:
static struct of_device_id foodevice_of_match[] __devinitdata = {
{ .compatible = foocorp,foodevice1234,
.resource_names = {base_regs,
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you open code it this way then yes, it's silly. But what about
something like this:
static struct of_device_id foodevice_of_match[] __devinitdata = {
{ .compatible =
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in a certain
order. It sounds to me that this will be prone to error in many ways
until everything is
On Thursday 25 August 2011, Russell King - ARM Linux wrote:
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in a certain
order. It sounds to me
On 8/25/2011 12:28 PM, Russell King - ARM Linux wrote:
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in a certain
order. It sounds to me that this will
Arnd Bergmann a...@arndb.de writes:
On Thursday 25 August 2011, Russell King - ARM Linux wrote:
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in
On Thursday 25 August 2011 11:16:25 Kevin Hilman wrote:
Please clarify.
What I hear Russell saying is a problem with the implementation of the
_byname API.
What I hear you sating is that since DT doesn't support this, we need to
remove it's usage completely from platform_devices also.
On Thu, Aug 25, 2011 at 11:16:25AM -0700, Kevin Hilman wrote:
Arnd Bergmann a...@arndb.de writes:
On Thursday 25 August 2011, Russell King - ARM Linux wrote:
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
on top of all that, for IPs which are used on many SoCs (such as MUSB)
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
[...]
I think it's much easier to change the existing users of _byname over
to fixed indexes than to come up with a new scheme
Hi,
On Wed, Aug 24, 2011 at 12:15:03PM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
[...]
I think it's much easier to change the
On 8/12/2011 5:02 AM, David Gibson wrote:
On Thu, Aug 11, 2011 at 02:28:55PM +0200, Cousson, Benoit wrote:
On 8/10/2011 9:22 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit
Hi,
On Fri, Aug 12, 2011 at 01:02:18PM +1000, David Gibson wrote:
That seems to be pretty straightforward to implement, and as soon as
it is useful even for a couple of drivers, it worth adding it.
It is anyway better than having to add a custom property to get the
information we will
On 8/12/2011 6:10 AM, Shawn Guo wrote:
On Tue, Aug 09, 2011 at 11:37:10PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:16 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:55 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 07:47:20PM
On Fri, Aug 12, 2011 at 10:56:13AM +0200, Cousson, Benoit wrote:
[...]
The devil is in the details, but the way the DMA lines are connected
in OMAP is similar to IRQ lines, and maybe a little bit simpler.
So starting with a copy/paste of the of_irq file should be a good start.
And then the
On Friday 12 August 2011, Felipe Balbi wrote:
On Fri, Aug 12, 2011 at 01:02:18PM +1000, David Gibson wrote:
the whole point of using *byname() is for the driver to not care about
the order of the resources. So if driver has to provided an ordered list
of names, what's the benefit ? Sounds
On Friday 12 August 2011, Cousson, Benoit wrote:
Arnd Bergmann:
But I really don't think there is value in using IORESOURCE_DMA for this.
We don't have the code to manage DMA resources for more than one DMA
controller AFAICT, and I think we should not add it. Globally
unique interrupt
On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
On Friday 12 August 2011, Felipe Balbi wrote:
On Fri, Aug 12, 2011 at 01:02:18PM +1000, David Gibson wrote:
the whole point of using *byname() is for the driver to not care about
the order of the resources. So if driver has to provided an ordered list
On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
It only make sense for drivers that support both device tree probing
and legacy probing of static platform devices.
Note how almost all drivers use only platform_get_resource
On 8/10/2011 9:22 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely wrote:
That won't work either because that also breaks the existing
On Thu, Aug 11, 2011 at 02:28:55PM +0200, Cousson, Benoit wrote:
On 8/10/2011 9:22 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely
On Tue, Aug 09, 2011 at 11:37:10PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:16 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:55 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote:
On 8/9/2011
On Wed, 10 Aug 2011, David Gibson wrote:
The difficulty with adding th enames to the DT itself is that it
exposes the essentially Linux-specific names in what's supposed to be
an OS neutral data structure.
The names are supposed to pertain to the hardware IP block, not the OS.
See for
On Wed, 10 Aug 2011, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order.
Most ARM SoC Linux ports aren't using DT now, so there isn't really an
older OS case here. Might as well try to get
On 8/10/2011 3:52 AM, David Gibson wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
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
On 08/09/2011 08:52 PM, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
name mapping in the Linux driver.
I
On 8/10/2011 5:18 PM, Scott Wood wrote:
On 08/09/2011 08:52 PM, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties. If there is a specific use case
where this doesn't work, then bring it up, but I haven't seen any yet.
The current users of
On Wed, Aug 10, 2011 at 1:57 PM, David Brown dav...@codeaurora.org wrote:
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties. If there is a specific use case
where this doesn't
Hi Grant,
Trying to bind hwmod informations with DT, I'm facing a little limitation.
A bunch of drivers are using the platform_get_resource_byname, so the
name for the resource is needed.
The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and
IORESOURCE_DMA types of resources.
Do
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi Grant,
Trying to bind hwmod informations with DT, I'm facing a little limitation.
A bunch of drivers are using the platform_get_resource_byname, so
the name for the resource is needed.
The name is used so far
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi Grant,
Trying to bind hwmod informations with DT, I'm facing a little limitation.
A bunch of drivers are using the platform_get_resource_byname, so
the
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi Grant,
Trying to bind hwmod informations with DT, I'm facing a little
On 8/9/2011 7:23 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi Grant,
Trying to bind hwmod
On Aug 9, 2011, at 1:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM +0200,
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
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi Grant,
Trying to bind hwmod informations with DT, I'm facing a little limitation.
A bunch of drivers are using the platform_get_resource_byname, so the
name for the resource is needed.
The name is used so far for
On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM
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
On 8/9/2011 9:51 PM, Russell King - ARM Linux wrote:
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi Grant,
Trying to bind hwmod informations with DT, I'm facing a little limitation.
A bunch of drivers are using the platform_get_resource_byname, so the
name for the resource
On 8/9/2011 10:55 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi
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
On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:55 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi
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
On 8/9/2011 11:16 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:55 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM,
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
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
On 08/09/2011 04:44 PM, Cousson, Benoit wrote:
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = foo_wrapper;
start = 0x1;
end = 0x200;
}
reg {
name = foo;
start = 0x2;
end = 0x200;
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
On Tue, Aug 09, 2011 at 11:23:45AM -0600, Grant Likely wrote:
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Manju,
On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
Hi Benoit,
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
Hi
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
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
69 matches
Mail list logo
