Hi GPIO maintainer,
Need your help.
I want to add interrupt function to gpio/pch_gpio.c
According to other upstreamed GPIO driver, (e.g. pl061, langwell, etc...)
2 IRQs(irq, irq_base) are used.
I can get "irq" from (struct pci_dev *)pdev->irq.
However I can't understand where can I get the "irq_base".
Let me know how to get.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
On 04/21/2011 09:32 AM, Tomoya MORINAGA wrote:
> Hi GPIO maintainer,
>
> Need your help.
> I want to add interrupt function to gpio/pch_gpio.c
>
> According to other upstreamed GPIO driver, (e.g. pl061, langwell, etc...)
> 2 IRQs(irq, irq_base) are used.
>
> I can get "irq" from (struct pci_dev *)pdev->irq.
> However I can't understand where can I get the "irq_base".
> Let me know how to get.
>
> Thanks,
> -----------------------------------------
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.
In my opinion the best option for expander chips is to allocate a new irq_desc
range by calling irq_alloc_descs. It will return the first irq number in the
newly allocated range, which will be your irq_base.
But be aware that this will require SPARSE_IRQ to work.
- Lars
On Thu, Apr 21, 2011 at 10:09:14AM +0200, Lars-Peter Clausen wrote:
> On 04/21/2011 09:32 AM, Tomoya MORINAGA wrote:
> > Hi GPIO maintainer,
> >
> > Need your help.
> > I want to add interrupt function to gpio/pch_gpio.c
> >
> > According to other upstreamed GPIO driver, (e.g. pl061, langwell, etc...)
> > 2 IRQs(irq, irq_base) are used.
irq and irq_base are two different things. irq is the irq number that
the gpio expander is wired up to. irq_base is the starting range for
any irqs generated by the gpio expender. Essentially, turning the
gpio controller into an irq controller.
> >
> > I can get "irq" from (struct pci_dev *)pdev->irq.
> > However I can't understand where can I get the "irq_base".
> > Let me know how to get.
> >
> > Thanks,
> > -----------------------------------------
> > Tomoya MORINAGA
> > OKI SEMICONDUCTOR CO., LTD.
>
> In my opinion the best option for expander chips is to allocate a new irq_desc
> range by calling irq_alloc_descs. It will return the first irq number in the
> newly allocated range, which will be your irq_base.
Yes, irq_alloc_descs() will give you a range of irqs that the gpio
expander can use. In many drivers, the irq_base is hard coded in the
board file and passed in via pdata, but as much as possible I
recommend avoiding that and letting Linux dynamically allocate the
irq_base for you. Setting gpio_base to -1 will do this.
The ->to_irq() hook in your driver can translate
from a gpio number to an irq number for a specific gpio.
> But be aware that this will require SPARSE_IRQ to work.
Why?
g.
On 04/21/2011 03:45 PM, Grant Likely wrote:
> On Thu, Apr 21, 2011 at 10:09:14AM +0200, Lars-Peter Clausen wrote:
>> [...]
>>
>> In my opinion the best option for expander chips is to allocate a new irq_desc
>> range by calling irq_alloc_descs. It will return the first irq number in the
>> newly allocated range, which will be your irq_base.
>
> Yes, irq_alloc_descs() will give you a range of irqs that the gpio
> expander can use. In many drivers, the irq_base is hard coded in the
> board file and passed in via pdata, but as much as possible I
> recommend avoiding that and letting Linux dynamically allocate the
> irq_base for you. Setting gpio_base to -1 will do this.
>
> The ->to_irq() hook in your driver can translate
> from a gpio number to an irq number for a specific gpio.
>
>> But be aware that this will require SPARSE_IRQ to work.
>
> Why?
>
Because in a non-SPARSE_IRQ setup all irq_descs will be allocated by default.
See early_irq_init for the non-SPARSE_IRQ case in kernel/irq/irq_desc.c.
Though platform code could make irq_descs explicitly available byfirst setting
NR_IRQS to a larger number then it actually requires and then call
irq_free_descs for those irqs which are not used by platform code, but using
SPARSE_IRQ is in my opinion the better alternative in this case.
- Lars
On Thu, Apr 21, 2011 at 04:08:11PM +0200, Lars-Peter Clausen wrote:
> On 04/21/2011 03:45 PM, Grant Likely wrote:
> > On Thu, Apr 21, 2011 at 10:09:14AM +0200, Lars-Peter Clausen wrote:
> >> [...]
> >>
> >> In my opinion the best option for expander chips is to allocate a new irq_desc
> >> range by calling irq_alloc_descs. It will return the first irq number in the
> >> newly allocated range, which will be your irq_base.
> >
> > Yes, irq_alloc_descs() will give you a range of irqs that the gpio
> > expander can use. In many drivers, the irq_base is hard coded in the
> > board file and passed in via pdata, but as much as possible I
> > recommend avoiding that and letting Linux dynamically allocate the
> > irq_base for you. Setting gpio_base to -1 will do this.
> >
> > The ->to_irq() hook in your driver can translate
> > from a gpio number to an irq number for a specific gpio.
> >
> >> But be aware that this will require SPARSE_IRQ to work.
> >
> > Why?
> >
>
> Because in a non-SPARSE_IRQ setup all irq_descs will be allocated by default.
> See early_irq_init for the non-SPARSE_IRQ case in kernel/irq/irq_desc.c.
They'll be allocated, but not all need to be assigned.
>
> Though platform code could make irq_descs explicitly available byfirst setting
> NR_IRQS to a larger number then it actually requires and then call
> irq_free_descs for those irqs which are not used by platform code, but using
> SPARSE_IRQ is in my opinion the better alternative in this case.
On the powerpc platforms, pretty much all irqs are dynamically
allocated and SPARSE_IRQ can be either on or off. So, yes, you need
to make sure NR_IRQs is large enough if you don't want to use SPARSE,
but SPARSE is not a hard requirement.
g.
Hi Grant, Lars-Peter Clausen
Thank you for your information.
It seems nothing driver uses irq_alloc_descs.
Thus, let me clarify my using.
int irq_base = irq_alloc_descs(-1, 0, 12, GFP_KERNEL)
(Intel-ET20T-PCH has GPIO~GPIO11)
Using the above, I can see "irq_base = 18d".
Is the above TRUE ?
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
Hi Grant, Lars-Peter Clausen,
- Executing the following command,
cd /sys/class/gpio/gpio244
echo "falling" > edge
- I can see the following error message.
IRQ handler type mismatch for IRQ 18
current handler: spi_topcliff_pch
Pid: 3269, comm: bash Not tainted 2.6.38.3.upstream_check+ #23
Call Trace:
[<c0470682>] ? __setup_irq+0x257/0x2a9
[<c054a45f>] ? gpio_sysfs_irq+0x0/0x11
[<c047077c>] ? request_threaded_irq+0xa8/0xce
[<c04707fb>] ? request_any_context_irq+0x59/0x64
[<c054a45f>] ? gpio_sysfs_irq+0x0/0x11
[<c054a8f5>] ? gpio_setup_irq.clone.4+0x1fa/0x292
[<c054ae2c>] ? gpio_edge_store+0xa3/0xd2
[<c054ad89>] ? gpio_edge_store+0x0/0xd2
[<c05bf270>] ? dev_attr_store+0x1b/0x23
[<c04e90a5>] ? sysfs_write_file+0xae/0xe7
[<c04e8ff7>] ? sysfs_write_file+0x0/0xe7
[<c04a71a1>] ? vfs_write+0x82/0xd9
[<c04a7366>] ? sys_write+0x3b/0x5d
[<c0403018>] ? sysenter_do_call+0x12/0x28
> Using the above, I can see "irq_base = 18d".
- According to the following "/proc/interrupts" information,
I suspect pch_gpio can't use IRQ18.
[morinaga@localhost ~]$ cat /proc/interrupts
CPU0 CPU1
0: 30881 0 IO-APIC-edge timer
1: 2 0 IO-APIC-edge i8042
4: 2 0 IO-APIC-edge
8: 128 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 4 0 IO-APIC-edge i8042
16: 385 0 IO-APIC-fasteoi intel-eg20t-pch, ehci_hcd:usb2, ohci_hcd:usb6, ohci_hcd:usb7, ohci_hcd:usb8,
hda_intel
17: 0 0 IO-APIC-fasteoi eth1
18: 0 0 IO-APIC-fasteoi spi_topcliff_pch, i2c_eg20t, pch-dma, mmc0, mmc1
19: 3599 0 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, pch-dma,
mga@pci:0000:07:00.0
40: 10298 0 PCI-MSI-edge ahci
42: 98 0 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 76268 72502 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES: 1383 1842 Rescheduling interrupts
CAL: 67 108 Function call interrupts
TLB: 224 292 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 0
MIS: 0
Let me know your opinion.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: Tomoya MORINAGA [mailto:[email protected]]
> Sent: Friday, April 22, 2011 9:33 AM
> To: 'Grant Likely'; 'Lars-Peter Clausen'
> Cc: '[email protected]'; '[email protected]'
> Subject: RE: Question: GPIO driver how to get irq_base
>
> Hi Grant, Lars-Peter Clausen
>
> Thank you for your information.
>
> It seems nothing driver uses irq_alloc_descs.
> Thus, let me clarify my using.
>
> int irq_base = irq_alloc_descs(-1, 0, 12, GFP_KERNEL)
> (Intel-ET20T-PCH has GPIO~GPIO11)
>
> Using the above, I can see "irq_base = 18d".
> Is the above TRUE ?
>
> Thanks,
> -----------------------------------------
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.
>
On 04/22/2011 03:12 AM, Tomoya MORINAGA wrote:
> Hi Grant, Lars-Peter Clausen,
>
> - Executing the following command,
> cd /sys/class/gpio/gpio244
> echo "falling" > edge
>
> - I can see the following error message.
> IRQ handler type mismatch for IRQ 18
> current handler: spi_topcliff_pch
> Pid: 3269, comm: bash Not tainted 2.6.38.3.upstream_check+ #23
> Call Trace:
> [<c0470682>] ? __setup_irq+0x257/0x2a9
> [<c054a45f>] ? gpio_sysfs_irq+0x0/0x11
> [<c047077c>] ? request_threaded_irq+0xa8/0xce
> [<c04707fb>] ? request_any_context_irq+0x59/0x64
> [<c054a45f>] ? gpio_sysfs_irq+0x0/0x11
> [<c054a8f5>] ? gpio_setup_irq.clone.4+0x1fa/0x292
> [<c054ae2c>] ? gpio_edge_store+0xa3/0xd2
> [<c054ad89>] ? gpio_edge_store+0x0/0xd2
> [<c05bf270>] ? dev_attr_store+0x1b/0x23
> [<c04e90a5>] ? sysfs_write_file+0xae/0xe7
> [<c04e8ff7>] ? sysfs_write_file+0x0/0xe7
> [<c04a71a1>] ? vfs_write+0x82/0xd9
> [<c04a7366>] ? sys_write+0x3b/0x5d
> [<c0403018>] ? sysenter_do_call+0x12/0x28
>
>> Using the above, I can see "irq_base = 18d".
> - According to the following "/proc/interrupts" information,
> I suspect pch_gpio can't use IRQ18.
>
> [morinaga@localhost ~]$ cat /proc/interrupts
> CPU0 CPU1
> 0: 30881 0 IO-APIC-edge timer
> 1: 2 0 IO-APIC-edge i8042
> 4: 2 0 IO-APIC-edge
> 8: 128 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 4 0 IO-APIC-edge i8042
> 16: 385 0 IO-APIC-fasteoi intel-eg20t-pch, ehci_hcd:usb2, ohci_hcd:usb6, ohci_hcd:usb7, ohci_hcd:usb8,
> hda_intel
> 17: 0 0 IO-APIC-fasteoi eth1
> 18: 0 0 IO-APIC-fasteoi spi_topcliff_pch, i2c_eg20t, pch-dma, mmc0, mmc1
> 19: 3599 0 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, pch-dma,
> mga@pci:0000:07:00.0
> 40: 10298 0 PCI-MSI-edge ahci
> 42: 98 0 PCI-MSI-edge eth0
> NMI: 0 0 Non-maskable interrupts
> LOC: 76268 72502 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> IWI: 0 0 IRQ work interrupts
> RES: 1383 1842 Rescheduling interrupts
> CAL: 67 108 Function call interrupts
> TLB: 224 292 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 1 1 Machine check polls
> ERR: 0
> MIS: 0
>
> Let me know your opinion.
>
> Thanks,
> -----------------------------------------
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.
>
Hi
It looks as both your driver and IO-APIC have allocated the same IRQ. You could
try to add some debug code to alloc_irq_and_cfg_at to figure out what is going
wrong.
- Lars
Hi Lars,
On Saturday, April 23, 2011 7:15 PM, Lars-Peter Clausen wrote:
> It looks as both your driver and IO-APIC have allocated the
> same IRQ. You could try to add some debug code to
> alloc_irq_and_cfg_at to figure out what is going wrong.
>
> - Lars
Adding debug code like below.
/////////////////////////////////////////////////////////////////////////////////////////////////
static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at, int node)
{
int res = irq_alloc_desc_at(at, node);
struct irq_cfg *cfg;
printk("%s:1 at=%d node=%d res=%d\n", __func__, at, node, res);
if (res < 0) {
printk("%s:2\n", __func__);
if (res != -EEXIST)
return NULL;
printk("%s:3\n", __func__);
cfg = get_irq_chip_data(at);
printk("%s:4\n", __func__);
if (cfg)
return cfg;
}
cfg = alloc_irq_cfg(at, node);
printk("%s:5cfg=%p\n", __func__, cfg);
if (cfg)
set_irq_chip_data(at, cfg);
else
irq_free_desc(at);
printk("%s:6cfg=%p\n", __func__, cfg);
return cfg;
}
/////////////////////////////////////////////////////////////////////////////////////////////////
The following is kernel boot log.
alloc_irq_and_cfg_at:1 at=1 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=0 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=3 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=4 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=5 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=6 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=7 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=8 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=9 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=10 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=11 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=12 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=13 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=14 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=15 node=0 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=4 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=8 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=13 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=1 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=12 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:1 at=16 node=-1 res=16
alloc_irq_and_cfg_at:5cfg=f599c1b0
alloc_irq_and_cfg_at:6cfg=f599c1b0
alloc_irq_and_cfg_at:1 at=17 node=-1 res=17
alloc_irq_and_cfg_at:5cfg=f599c1a0
alloc_irq_and_cfg_at:6cfg=f599c1a0
alloc_irq_and_cfg_at:1 at=19 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
alloc_irq_and_cfg_at:5cfg=f5957dc0
alloc_irq_and_cfg_at:6cfg=f5957dc0
alloc_irq_and_cfg_at:1 at=18 node=-1 res=-17
alloc_irq_and_cfg_at:2
alloc_irq_and_cfg_at:3
alloc_irq_and_cfg_at:4
With Best Regards,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
Hi Lars,
Did you see this email ?
I'm waiting for your response.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Tomoya MORINAGA
> Sent: Monday, April 25, 2011 1:04 PM
> To: 'Lars-Peter Clausen'
> Cc: 'Grant Likely'; [email protected];
> [email protected]
> Subject: RE: Question: GPIO driver how to get irq_base
>
> Hi Lars,
>
> On Saturday, April 23, 2011 7:15 PM, Lars-Peter Clausen wrote:
> > It looks as both your driver and IO-APIC have allocated the
> same IRQ.
> > You could try to add some debug code to
> alloc_irq_and_cfg_at to figure
> > out what is going wrong.
> >
> > - Lars
>
> Adding debug code like below.
>
> //////////////////////////////////////////////////////////////
> ///////////////////////////////////
> static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at,
> int node) {
> int res = irq_alloc_desc_at(at, node);
> struct irq_cfg *cfg;
> printk("%s:1 at=%d node=%d res=%d\n", __func__, at, node, res);
> if (res < 0) {
> printk("%s:2\n", __func__);
> if (res != -EEXIST)
> return NULL;
> printk("%s:3\n", __func__);
> cfg = get_irq_chip_data(at);
> printk("%s:4\n", __func__);
> if (cfg)
> return cfg;
> }
>
> cfg = alloc_irq_cfg(at, node);
> printk("%s:5cfg=%p\n", __func__, cfg);
> if (cfg)
> set_irq_chip_data(at, cfg);
> else
> irq_free_desc(at);
> printk("%s:6cfg=%p\n", __func__, cfg);
> return cfg;
> }
> //////////////////////////////////////////////////////////////
> ///////////////////////////////////
>
> The following is kernel boot log.
>
> alloc_irq_and_cfg_at:1 at=1 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=0 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=3 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=4 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=5 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=6 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=7 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=8 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=9 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=10 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=11 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=12 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=13 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=14 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:1 at=15 node=0 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
> alloc_irq_and_cfg_at:1 at=4 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
> alloc_irq_and_cfg_at:1 at=8 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
> alloc_irq_and_cfg_at:1 at=13 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
> alloc_irq_and_cfg_at:1 at=1 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
> alloc_irq_and_cfg_at:1 at=12 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
> alloc_irq_and_cfg_at:1 at=16 node=-1 res=16
> alloc_irq_and_cfg_at:5cfg=f599c1b0
> alloc_irq_and_cfg_at:6cfg=f599c1b0
>
> alloc_irq_and_cfg_at:1 at=17 node=-1 res=17
> alloc_irq_and_cfg_at:5cfg=f599c1a0
> alloc_irq_and_cfg_at:6cfg=f599c1a0
>
> alloc_irq_and_cfg_at:1 at=19 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
> alloc_irq_and_cfg_at:5cfg=f5957dc0
> alloc_irq_and_cfg_at:6cfg=f5957dc0
>
> alloc_irq_and_cfg_at:1 at=18 node=-1 res=-17
> alloc_irq_and_cfg_at:2
> alloc_irq_and_cfg_at:3
> alloc_irq_and_cfg_at:4
>
>
> With Best Regards,
> -----------------------------------------
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 05/09/2011 10:54 PM, Tomoya MORINAGA wrote:
> Hi Lars,
>
> Did you see this email ?
> I'm waiting for your response.
>
Hi
Well, it looks as if io-apic assumes that IRQ18 is reserved for itself, while
it actually is requested by your driver. But that's all I can say. I'm not
familiar with the x86 irq code, so I've no idea what the proper fix would be.
- Lars
> Thanks,
> -----------------------------------------
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of
>> Tomoya MORINAGA
>> Sent: Monday, April 25, 2011 1:04 PM
>> To: 'Lars-Peter Clausen'
>> Cc: 'Grant Likely'; [email protected];
>> [email protected]
>> Subject: RE: Question: GPIO driver how to get irq_base
>>
>> Hi Lars,
>>
>> On Saturday, April 23, 2011 7:15 PM, Lars-Peter Clausen wrote:
>>> It looks as both your driver and IO-APIC have allocated the
>> same IRQ.
>>> You could try to add some debug code to
>> alloc_irq_and_cfg_at to figure
>>> out what is going wrong.
>>>
>>> - Lars
>>
>> Adding debug code like below.
>>
>> //////////////////////////////////////////////////////////////
>> ///////////////////////////////////
>> static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at,
>> int node) {
>> int res = irq_alloc_desc_at(at, node);
>> struct irq_cfg *cfg;
>> printk("%s:1 at=%d node=%d res=%d\n", __func__, at, node, res);
>> if (res < 0) {
>> printk("%s:2\n", __func__);
>> if (res != -EEXIST)
>> return NULL;
>> printk("%s:3\n", __func__);
>> cfg = get_irq_chip_data(at);
>> printk("%s:4\n", __func__);
>> if (cfg)
>> return cfg;
>> }
>>
>> cfg = alloc_irq_cfg(at, node);
>> printk("%s:5cfg=%p\n", __func__, cfg);
>> if (cfg)
>> set_irq_chip_data(at, cfg);
>> else
>> irq_free_desc(at);
>> printk("%s:6cfg=%p\n", __func__, cfg);
>> return cfg;
>> }
>> //////////////////////////////////////////////////////////////
>> ///////////////////////////////////
>>
>> The following is kernel boot log.
>>
>> alloc_irq_and_cfg_at:1 at=1 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=0 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=3 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=4 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=5 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=6 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=7 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=8 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=9 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=10 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=11 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=12 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=13 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=14 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:1 at=15 node=0 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>> alloc_irq_and_cfg_at:1 at=4 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>> alloc_irq_and_cfg_at:1 at=8 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>> alloc_irq_and_cfg_at:1 at=13 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>> alloc_irq_and_cfg_at:1 at=1 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>> alloc_irq_and_cfg_at:1 at=12 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>> alloc_irq_and_cfg_at:1 at=16 node=-1 res=16
>> alloc_irq_and_cfg_at:5cfg=f599c1b0
>> alloc_irq_and_cfg_at:6cfg=f599c1b0
>>
>> alloc_irq_and_cfg_at:1 at=17 node=-1 res=17
>> alloc_irq_and_cfg_at:5cfg=f599c1a0
>> alloc_irq_and_cfg_at:6cfg=f599c1a0
>>
>> alloc_irq_and_cfg_at:1 at=19 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>> alloc_irq_and_cfg_at:5cfg=f5957dc0
>> alloc_irq_and_cfg_at:6cfg=f5957dc0
>>
>> alloc_irq_and_cfg_at:1 at=18 node=-1 res=-17
>> alloc_irq_and_cfg_at:2
>> alloc_irq_and_cfg_at:3
>> alloc_irq_and_cfg_at:4
>>
>>
>> With Best Regards,
>> -----------------------------------------
>> Tomoya MORINAGA
>> OKI SEMICONDUCTOR CO., LTD.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in the body of a message to
>> [email protected] More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
Hi Lars, Grant
According to "/proc/interrupts", IRQ18 is not empty.
However, irq_alloc_descs returns "18".
I suspect irq_alloc_descs returns should not return "18".
> Grant,
Let me know your opinion.
With Best Regards,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: Lars-Peter Clausen [mailto:[email protected]]
> Sent: Thursday, May 12, 2011 4:20 AM
> To: Tomoya MORINAGA
> Cc: 'Grant Likely'; [email protected];
> [email protected]
> Subject: Re: Question: GPIO driver how to get irq_base
>
> On 05/09/2011 10:54 PM, Tomoya MORINAGA wrote:
> > Hi Lars,
> >
> > Did you see this email ?
> > I'm waiting for your response.
> >
>
> Hi
>
> Well, it looks as if io-apic assumes that IRQ18 is reserved
> for itself, while it actually is requested by your driver.
> But that's all I can say. I'm not familiar with the x86 irq
> code, so I've no idea what the proper fix would be.
>
> - Lars
>
On 05/12/2011 05:01 AM, Tomoya MORINAGA wrote:
> Hi Lars, Grant
>
> According to "/proc/interrupts", IRQ18 is not empty.
> However, irq_alloc_descs returns "18".
> I suspect irq_alloc_descs returns should not return "18".
>
>> Grant,
> Let me know your opinion.
>
> With Best Regards,
Is it already used at the time when you call irq_alloc_descs?
- Lars
Hi Lars,
On Friday, May 13, 2011 4:43 AM, Lars-Peter Clausen wrote:
> Is it already used at the time when you call irq_alloc_descs?
Since gpio driver with interrupt function must be integrated as built-in,
I don't know whether "18" is already used or NOT at that time.
If you have any information, let me know.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
On 05/12/2011 07:40 PM, Tomoya MORINAGA wrote:
> Hi Lars,
>
> On Friday, May 13, 2011 4:43 AM, Lars-Peter Clausen wrote:
>> Is it already used at the time when you call irq_alloc_descs?
>
> Since gpio driver with interrupt function must be integrated as built-in,
> I don't know whether "18" is already used or NOT at that time.
> If you have any information, let me know.
>
Well, you should be able to figure that out with some debug printks, shouldn't you?
- Lars
Friday, May 13, 2011 12:19 PM, Lars-Peter Clausen wrote:
> Well, you should be able to figure that out with some debug
> printks, shouldn't you?
I can confirm "18" is not assigned at that time.
After loading gpio driver, other modules are assigned to "IRQ18".
(IRQ numbers shared system)
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: Lars-Peter Clausen [mailto:[email protected]]
> Sent: Friday, May 13, 2011 12:19 PM
> To: Tomoya MORINAGA
> Cc: 'Grant Likely'; [email protected];
> [email protected]
> Subject: Re: Question: GPIO driver how to get irq_base
>
> On 05/12/2011 07:40 PM, Tomoya MORINAGA wrote:
> > Hi Lars,
> >
> > On Friday, May 13, 2011 4:43 AM, Lars-Peter Clausen wrote:
> >> Is it already used at the time when you call irq_alloc_descs?
> >
> > Since gpio driver with interrupt function must be integrated as
> > built-in, I don't know whether "18" is already used or NOT
> at that time.
> > If you have any information, let me know.
> >
>
> Well, you should be able to figure that out with some debug
> printks, shouldn't you?
>
> - Lars
>
Hi,
Pch_gpio driver can become detecting falling/rising edge.
I attached the latest GPIO driver, usermode TP and the result.
However, "poll( )" of gpio_tp behavior is different than I anticipated.
The "poll" is not blocked. (The returned value looks good)
My anticipated behavior is
Execute gpio_tp (blocked at poll( ))
(Detect edge)
Interrupt handler of pch_gpio is called
Blocked poll( ) becomes released.
Let me know your opinion.
With Best Regards,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
Hi,
Modifying parameter of poll ( ) like below, poll ( ) becomes blocked correctly.
pfd.events = POLLPRI | POLLERR
And I can confirm when GPIO driver detects edge changing,
the blocked poll ( ) is released correctly.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Tomoya MORINAGA
> Sent: Monday, May 16, 2011 7:39 PM
> To: 'Lars-Peter Clausen'; 'Grant Likely'
> Cc: [email protected]; [email protected]
> Subject: RE: Question: GPIO driver how to get irq_base
>
> Hi,
>
> Pch_gpio driver can become detecting falling/rising edge.
> I attached the latest GPIO driver, usermode TP and the result.
>
> However, "poll( )" of gpio_tp behavior is different than I
> anticipated.
> The "poll" is not blocked. (The returned value looks good)
>
> My anticipated behavior is
> Execute gpio_tp (blocked at poll( ))
> (Detect edge)
> Interrupt handler of pch_gpio is called
> Blocked poll( ) becomes released.
>
> Let me know your opinion.
>
> With Best Regards,
> -----------------------------------------
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.
>