LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* of_iomap and request_mem_region
@ 2008-02-10  2:38 Jon Smirl
  2008-02-10  2:45 ` Arnd Bergmann
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Smirl @ 2008-02-10  2:38 UTC (permalink / raw)
  To: Linux/PPC Development

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: of_iomap and request_mem_region
  2008-02-10  2:38 of_iomap and request_mem_region Jon Smirl
@ 2008-02-10  2:45 ` Arnd Bergmann
  2008-02-10  2:59   ` Jon Smirl
  0 siblings, 1 reply; 4+ messages in thread
From: Arnd Bergmann @ 2008-02-10  2:45 UTC (permalink / raw)
  To: linuxppc-dev

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 <><

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: of_iomap and request_mem_region
  2008-02-10  2:45 ` Arnd Bergmann
@ 2008-02-10  2:59   ` Jon Smirl
  2008-02-10  3:14     ` Arnd Bergmann
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Smirl @ 2008-02-10  2:59 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev

On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 10 February 2008, Jon Smirl wrote:
> > 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: of_iomap and request_mem_region
  2008-02-10  2:59   ` Jon Smirl
@ 2008-02-10  3:14     ` Arnd Bergmann
  0 siblings, 0 replies; 4+ messages in thread
From: Arnd Bergmann @ 2008-02-10  3:14 UTC (permalink / raw)
  To: linuxppc-dev

On Sunday 10 February 2008, Jon Smirl wrote:
> On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 10 February 2008, Jon Smirl wrote:
> > > 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 <><

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-02-10  3:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-10  2:38 of_iomap and request_mem_region Jon Smirl
2008-02-10  2:45 ` Arnd Bergmann
2008-02-10  2:59   ` Jon Smirl
2008-02-10  3:14     ` Arnd Bergmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox