2.6 4xx GPIO OCP driver?

2.6 4xx GPIO OCP driver?

[Travis B. Sawyer]

Greetings:


I'm working on porting our 'package' of software from a 2.4.x kernel to 2.6.


We use the GPIO on the 440GX for some indications to our user space 
applications (board slot number, other board is present, etc).

In 2.4 we used the drivers/char/ibm_ocp_gpio.c module.  I see no such 
support in 2.6.10.  I perused the archives, found nothing (OBTW: can 
someone point me to the search engine for the list?)

Granted there are many changes in the OCP handling, but I was wondering 
if someone is already working on it, or if I'm going to have to RMO 
(roll my own)/up-port the module.


TIA,

Travis Sawyer

RE: 2.6 4xx GPIO OCP driver?

[Steven Blakeslee]

> In 2.4 we used the drivers/char/ibm_ocp_gpio.c module.  I see=20
> no such support in 2.6.10.  I perused the archives, found=20
> nothing (OBTW: can someone point me to the search engine for=20
> the list?)

I see it.  Drivers/char/ibm_gpio.c in Linux 2.6.10-rc3.

Re: 2.6 4xx GPIO OCP driver?

[Travis B. Sawyer]

Steven Blakeslee wrote:
>>In 2.4 we used the drivers/char/ibm_ocp_gpio.c module.  I see 
>>no such support in 2.6.10.  I perused the archives, found 
>>nothing (OBTW: can someone point me to the search engine for 
>>the list?)
> 
> 
> I see it.  Drivers/char/ibm_gpio.c in Linux 2.6.10-rc3.

I guess I should be using the linuxppc-2.5 tree instead of straight from
kernel.org.

Oopsie.

-travis

Re: 2.6 4xx GPIO OCP driver?

[Matt Porter]

On Fri, Feb 25, 2005 at 03:25:04PM -0500, Travis B. Sawyer wrote:
> Steven Blakeslee wrote:
> >>In 2.4 we used the drivers/char/ibm_ocp_gpio.c module.  I see 
> >>no such support in 2.6.10.  I perused the archives, found 
> >>nothing (OBTW: can someone point me to the search engine for 
> >>the list?)
> > 
> > 
> > I see it.  Drivers/char/ibm_gpio.c in Linux 2.6.10-rc3.
> 
> I guess I should be using the linuxppc-2.5 tree instead of straight from
> kernel.org.

I didn't bother merging it upstream at one time. It wasn't clear
if the driver had any value over just mmaping /dev/mem to bang
on the couple gpio registers directly. We can get it in real
2.6 if people really find it more convenient. My only argument
against it is that it's not much of a layer over the trivial
registers and each SoC requires completely different support
since the pin routings are SoC specific.

Anyway, just speak up. ;)

-Matt

Re: 2.6 4xx GPIO OCP driver?

[Travis B. Sawyer]

Matt Porter wrote:
> On Fri, Feb 25, 2005 at 03:25:04PM -0500, Travis B. Sawyer wrote:
> 
>>Steven Blakeslee wrote:
>>>>In 2.4 we used the drivers/char/ibm_ocp_gpio.c module.  I see 
>>>>no such support in 2.6.10.  I perused the archives, found 
>>>>nothing
>>>I see it.  Drivers/char/ibm_gpio.c in Linux 2.6.10-rc3.
>>
<SNIPPAGE above>
> I didn't bother merging it upstream at one time. It wasn't clear
> if the driver had any value over just mmaping /dev/mem to bang
> on the couple gpio registers directly.

Matt:

Good point, and that'll work for 2.4 also, which means I don't have to 
support different usercode btw the two versions of the kernel.

Thanx,

Travis

Re: 2.6 4xx GPIO OCP driver?

[Ralph Siemsen]

Matt Porter wrote:

> I didn't bother merging it upstream at one time. It wasn't clear
> if the driver had any value over just mmaping /dev/mem to bang
> on the couple gpio registers directly. [...]

Will that work on the 440 where the devices sit above 4GB mark?  Or must 
one rely on there being an existing TLB mapping to bring them into 
32-bit space?

-Ralph

Re: 2.6 4xx GPIO OCP driver?

[Matt Porter]

On Fri, Feb 25, 2005 at 04:19:41PM -0500, Ralph Siemsen wrote:
> Matt Porter wrote:
> 
> > I didn't bother merging it upstream at one time. It wasn't clear
> > if the driver had any value over just mmaping /dev/mem to bang
> > on the couple gpio registers directly. [...]
> 
> Will that work on the 440 where the devices sit above 4GB mark?  Or must 
> one rely on there being an existing TLB mapping to bring them into 
> 32-bit space?

Ack...that's the one thing we are missing. :-/ I had forgotten
that driver/char/mem.c  calls remap_pfn_range() directly rather
than io_remap_page_range(). Had it called the latter, we'd be OK
since the "bigphys" fixup could take place.  We can fix /dev/mem to
call io_remap_page_range() when on ppc32 && 36-bit phys...other arches
do similar tricks in that driver.

If everybody is happy with mmaping /dev/mem then we can go try that
route.

-Matt

Re: 2.6 4xx GPIO OCP driver?

[Travis Sawyer]

Matt Porter wrote:
> On Fri, Feb 25, 2005 at 04:19:41PM -0500, Ralph Siemsen wrote:
>>Will that work on the 440 where the devices sit above 4GB mark?  Or must 
>>one rely on there being an existing TLB mapping to bring them into 
>>32-bit space?

EINVAL.

mmap certainly didn't like the phys address of gpio.  Tried that.
> 
> 
> Ack...that's the one thing we are missing. :-/ I had forgotten
> that driver/char/mem.c  calls remap_pfn_range() directly rather
> than io_remap_page_range(). Had it called the latter, we'd be OK
> since the "bigphys" fixup could take place.  We can fix /dev/mem to
> call io_remap_page_range() when on ppc32 && 36-bit phys...other arches
> do similar tricks in that driver.
> 

Sounds like a plan, I'd be happy to test it out.

> If everybody is happy with mmaping /dev/mem then we can go try that
> route.
> 

Thanx,

Travis

Re: 2.6 4xx GPIO OCP driver?

[Travis B. Sawyer]

Matt Porter wrote:
> On Fri, Feb 25, 2005 at 04:19:41PM -0500, Ralph Siemsen wrote:
>>Will that work on the 440 where the devices sit above 4GB mark?  Or must 
>>one rely on there being an existing TLB mapping to bring them into 
>>32-bit space?

EINVAL.

mmap certainly didn't like the phys address of gpio.  Tried that.
> 
> 
> Ack...that's the one thing we are missing. :-/ I had forgotten
> that driver/char/mem.c  calls remap_pfn_range() directly rather
> than io_remap_page_range(). Had it called the latter, we'd be OK
> since the "bigphys" fixup could take place.  We can fix /dev/mem to
> call io_remap_page_range() when on ppc32 && 36-bit phys...other arches
> do similar tricks in that driver.
> 

Sounds like a plan, I'd be happy to test it out.

> If everybody is happy with mmaping /dev/mem then we can go try that
> route.
> 

Thanx,

Travis