of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
What about adding a third param to of_iomap for the driver name? If it
is non-null also do the request region. If it is null check to make
sure the region has already be requested.
--
Jon Smirl
jonsmirl@gmail.com
On Sunday 10 February 2008, Jon Smirl wrote:
of_iomap doesn't implicitly do a request_mem_region(). =A0How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
=20
What about adding a third param to of_iomap for the driver name? If it
is non-null also do the request region. If it is null check to make
sure the region has already be requested.
I'd prefer changing of_iomap so that it gets the of_device instead of
the device_node. That would help us do two changes at once:
1. call request_mem_region using dev->driver->name, as you mentioned.
2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
so that we can kill all the calls to iounmap in the cleanup path
of OF drivers.
maybe we can do a new ofm_iomap interface first, and then move
drivers over to use that one.
Arnd <><
On 2/9/08, Arnd Bergmann [off-list ref] wrote:
On Sunday 10 February 2008, Jon Smirl wrote:
quoted
of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
What about adding a third param to of_iomap for the driver name? If it
is non-null also do the request region. If it is null check to make
sure the region has already be requested.
I'd prefer changing of_iomap so that it gets the of_device instead of
the device_node. That would help us do two changes at once:
1. call request_mem_region using dev->driver->name, as you mentioned.
2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
so that we can kill all the calls to iounmap in the cleanup path
of OF drivers.
maybe we can do a new ofm_iomap interface first, and then move
drivers over to use that one.
There are only four drivers using of_iomap. It is not much work to
change them. Looking at them I don't see any that request the
resource. That's probably because they don't have the length needed to
make the call.
There are a lot of drivers using of_address_to_resource. They could
probably be converted to of_iomap if it gets changed. All of the ones
I checked follow the of_address_to_resource with a request_resource
call.
Arnd <><
--
Jon Smirl
jonsmirl@gmail.com
On Sunday 10 February 2008, Jon Smirl wrote:
On 2/9/08, Arnd Bergmann [off-list ref] wrote:
quoted
On Sunday 10 February 2008, Jon Smirl wrote:
quoted
of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
What about adding a third param to of_iomap for the driver name? If it
is non-null also do the request region. If it is null check to make
sure the region has already be requested.
I'd prefer changing of_iomap so that it gets the of_device instead of
the device_node. That would help us do two changes at once:
1. call request_mem_region using dev->driver->name, as you mentioned.
2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
so that we can kill all the calls to iounmap in the cleanup path
of OF drivers.
maybe we can do a new ofm_iomap interface first, and then move
drivers over to use that one.
There are only four drivers using of_iomap.
$ git-ls-files | xargs grep of_iomap | cut -f 1 -d: | uniq | wc -l
19
Unfortunately, many of them don't even use an of_device, so the
conversion is not trivial.
There are a lot of drivers using of_address_to_resource. They could
probably be converted to of_iomap if it gets changed. All of the ones
I checked follow the of_address_to_resource with a request_resource
call.
Right, but again, we are still in the progress of converting drivers
from using of_find_node_by_type() and similar to of_platform_driver.
If we don't have an of_device, the interface as I would prefer
it doesn't work.
Arnd <><