porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...

porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...

[Mike Timmons]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

I have a framebuffer driver for the Fujitsu CoralP that registers fine
with the PCI bus and operates for my new arch=powerpc 2.6.24 build. The
only thing that failed when jumping from arch=ppc on my 2.6.16 kernel to
my new 2.6.24 kernel is the interrupt request. While testing other
functionality I simply compiled-out the interrupt request because it is
not always critical for basic frame buffer operation. I'm back to
wanting the interrupt.

 

Specifically, I have a lite5200b-based board in both cases (2.6.14 and
2.6.24 kernels). Under the old ppc scheme I obtained irq=1 via a call to


 

pci_read_config_byte(pci_dev, PCI_INTERRUPT_LINE, &irqnum).

 

Under my new powerpc kernel 2.6.24 I obtain irq=0 and the subsequent
interrupt request fails. Also, a hard-coded irq=1 fails too. I know this
is an issue with NOT querying the device tree, but I'm not sure what to
specify in lite5200b.dts, or what property I need to query to get the
correct pci interrupt.

 

If anyone is familiar with lite5200b.dts, is all the info I need already
in there, or do I need to add my pci device? I've done some mucking
around in the dts file but I'm not a pci expert so I am a bit confused.


[-- Attachment #2: Type: text/html, Size: 3615 bytes --]

Re: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...

[Scott Wood]

Mike Timmons wrote:
> pci_read_config_byte(pci_dev, PCI_INTERRUPT_LINE, &irqnum).

Don't do this; use pci_dev->irq instead.

If that value doesn't work, check your interrupt-map in the pci node of 
the device tree.

-Scott

RE: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...

[Mike Timmons]

Scott,
Thanks for the quick answer. I did try this. I successfully get the
interrupt (virq=3D16) but it then fires continuously, immedetely =
following
the request_irq call.

My old ppc driver calls request_irq with flags SA_SHIRQ | SA_INTERRUPT
(0x20000000 | 0x04000000 ). I can't find equivalencies in the new
powerpc 2.6.24 kernel.

The only flag I'm passing to request_irq under the new 2.6.24 is
IRQF_SHARED.

I'm wondering if some interrupt type setting is mucked up, hence the
continuous interrupts. I only expect to receive this interrupt in
response to an error on my coralP, so I shouldn't see the interrupt at
all immediately following the interrupt request.

Any ideas? Thanks again,

Mike


-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]=20
Sent: Tuesday, May 06, 2008 1:12 PM
To: Mike Timmons
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: porting pci driverfrom arch=3Dppc on kernel 2.6.16 to
arch=3Dpowerpc on 2.6.24...

Mike Timmons wrote:
> pci_read_config_byte(pci_dev, PCI_INTERRUPT_LINE, &irqnum).

Don't do this; use pci_dev->irq instead.

If that value doesn't work, check your interrupt-map in the pci node of=20
the device tree.

-Scott

RE: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...

[Mike Timmons]

If I'm not supposed to read the interrupt using config_read, should I
also not be writing to the host register on the coral P to clear the
interrupt?

Should I instead be using some PCI helper functions?=20

I think I now have a valid interrupt, but seeing it fire continuously
when I know when-and-how it is supposed to fire is the problem now.
Obviously some of the code in the legacy driver for 2.6.16 ppc is not
correct now.

I suspect is it within the MB86290FB_WRITE_HOST_REGISTER() macros that
are used to manipulate the interrupts mask register within the CoralP
PCI graphics controller.=20

Please advise if there is some pci API I should be using to manipulate
this and other registers under the 2.6.24 powerpc kernel.

I do have a few books here with PCI examples but the interrupt
information is sparse.

Thanks again.
-Mike

Re: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...

[Scott Wood]

Mike Timmons wrote:
> If I'm not supposed to read the interrupt using config_read, should I
> also not be writing to the host register on the coral P to clear the
> interrupt?
> 
> Should I instead be using some PCI helper functions? 

No, clearing interrupts is device-specific.

Have you verified that the device does not think it's generating an 
interrupt during the interrupt storm?  Do other PCI cards work?

-Scott