linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Bill Gatliff <bgat@billgatliff.com>
To: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Linux/PPC Development <linuxppc-dev@ozlabs.org>
Subject: Re: Does gpio_to_irq() work for MPC52xx gpios?
Date: Wed, 23 Dec 2009 14:39:08 -0600	[thread overview]
Message-ID: <4B327FEC.9030801@billgatliff.com> (raw)
In-Reply-To: <4B3249AA.50405@billgatliff.com>

Bill Gatliff wrote:
> Peter Korsgaard wrote:
>   
>> No (not yet). In Ben's latest pull request there's a patch from me to
>> add basic infrastructure for gpio_to_irq(). I've recently added irq
>> support to the mpc8xxx driver, but so far nothing has been written for
>> 52xx.
>>
>> http://patchwork.ozlabs.org/patch/41550/
>>   
>>     
>
> Ok.  I'm taking a look at that code now, planning to adapt it for the
> MPC52xx unless someone raises any objections.
>   

Ok, working on this now.  I'm pretty far along, but I'm stopped at what
I think is a device tree source file problem.

I have an external device that generates two interrupt outputs.  One of
them is connected to IRQ2, the other to GPIO_WKUP_7.  I'm describing the
device like this:

    ...
    soc5200@f0000000 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "fsl,mpc5200b-immr","simple-bus";
        ranges = <0 0xf0000000 0x0000c000>;
        reg = <0xf0000000 0x00000100>;
        bus-frequency = <0>;        // from bootloader
        system-frequency = <0>;        // from bootloader
    ...
        mpc5200_pic: interrupt-controller@500 {
            // 5200 interrupts are encoded into two levels;
            interrupt-controller;
            gpio-controller;
            #interrupt-cells = <3>;
            #address-cells = <0>;
            #size-cells = <0>;
            compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
            reg = <0x500 0x80>;
            interrupts = < 0 0 3  1 1 3  2 2 2  3 3 2 >;
        };
        gpio_wkup: gpio@c00 {
            compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
            #gpio-cells = <2>;
            #interrupt-cells = <2>;
            #address-cells = <0>;
            #size-cells = <0>;
            reg = <0xc00 0x40>;
            interrupts = <1 8 0  0 3 0>;
            interrupt-parent = <&mpc5200_pic>;
            gpio-controller;
            interrupt-controller;
        };
    ...
    };
    ...
    system {
        compatible = "simple-bus";

        rotary-encoder {
            compatible = "linux,rotary-encoder","rotary-encoder";
            interrupts = <&mpc5200_pic 2 3  &gpio_wkup 0 0>;
            //interrupts = <&mpc5200_pic 2 3>;
            //gpios = <&gpio_wkup 0 0>;
            type = <1>;
            val-ccw = <0x4a>;
            val-cw = <78>;
        };
    };

When I use the "gpios" property instead of the above, I get a useful
gpio number and I can see the signal using sys/class/gpio.  And I also
know the hardware is working because an ancient, pre-device-tree kernel
is working fine.  :)

The problem is that I'm not getting a valid number out for the second
interrupt specification, presumably because the dts compiler doesn't
have any idea how to generate the data--- and I have no idea how to fix
that.

I captured some dmesg information which shows the problem.  The first
line is for IRQ2, which is correct.  The second is for GPIO_WKUP_7,
which the kernel chokes on:

...
irq: irq_create_mapping(0xcf814000,
0x42)                                         
irq: -> using host
@cf814000                                                      
  alloc irq_desc for 66 on node
0                                                 
  alloc kstat_irqs on node
0                                                      
mpc52xx_irqhost_map: External IRQ2 virq=42, hw=42.
type=8                         
irq: irq 66 on host /soc5200@f0000000/interrupt-controller@500 mapped to
virtual irq
66                                                                              

mpc52xx_extirq_set_type: irq=42. l2=2
flow_type=8                                 
linux,rotary-encoder rotary-encoder.3: irq[0] 66 gpio[0] -2  <- my
driver's output, the "magic number" was 66
return 0, l1=4,
l2=0                                                              
irq: irq_create_mapping(0xcf814000,
0x0)                                          
irq: -> using host
@cf814000                                                      
  alloc irq_desc for 16 on node
0                                                 
  alloc kstat_irqs on node
0                                                      
mpc52xx_irqhost_map: External IRQ0 virq=10, hw=0.
type=8                          
irq: irq 0 on host /soc5200@f0000000/interrupt-controller@500 mapped to
virtual irq
16                                                                               

mpc52xx_extirq_set_type: irq=0. l2=0
flow_type=8                                  
linux,rotary-encoder rotary-encoder.3: irq[1] 16 gpio[1] -2         <-
my driver's "magic number" was 16
...


The device tree has the magic number "66" for IRQ2, which
mpc52xx_irqhost_map gets right.  But it doesn't know what to do with the
magic number "16" that's fed to it from the other interrupt
specification.  And I don't yet, either...  :)

Any ideas?  Basically, what I think this boils down to is somewhere I
need to translate that 16 to yet another virtual number for the
demultiplexed interrupt descriptor.  But I'm getting a little lost in
the virtual-ness of everything!


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

  reply	other threads:[~2009-12-23 20:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-22 20:40 Does gpio_to_irq() work for MPC52xx gpios? Bill Gatliff
2009-12-22 21:00 ` Peter Korsgaard
2009-12-23 16:47   ` Bill Gatliff
2009-12-23 20:39     ` Bill Gatliff [this message]
2009-12-24  5:38       ` Bill Gatliff
2009-12-24  6:52         ` Bill Gatliff
2009-12-30  6:27   ` Bill Gatliff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B327FEC.9030801@billgatliff.com \
    --to=bgat@billgatliff.com \
    --cc=jacmet@sunsite.dk \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).