devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: David Daney <david.daney@cavium.com>
Cc: David Daney <ddaney.cavm@gmail.com>,
	linux-mips@linux-mips.org, ralf@linux-mips.org,
	devicetree-discuss@lists.ozlabs.org,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/4] MIPS: Octeon: Setup irq_domains for interrupts.
Date: Tue, 27 Mar 2012 17:05:24 -0500	[thread overview]
Message-ID: <4F7239A4.7070905@gmail.com> (raw)
In-Reply-To: <4F7205F3.3000108@cavium.com>

On 03/27/2012 01:24 PM, David Daney wrote:
> On 03/26/2012 06:56 PM, Rob Herring wrote:
>> On 03/26/2012 02:31 PM, David Daney wrote:
>>> From: David Daney<david.daney@cavium.com>
> [...]
>>> +static bool octeon_irq_ciu_is_edge(unsigned int line, unsigned int bit)
>>> +{
>>> +    bool edge = false;
>>> +
>>> +    if (line == 0)
>>> +        switch (bit) {
>>> +        case 48 ... 49: /* GMX DRP */
>>> +        case 50: /* IPD_DRP */
>>> +        case 52 ... 55: /* Timers */
>>> +        case 58: /* MPI */
>>> +            edge = true;
>>> +            break;
>>> +        default:
>>> +            break;
>>> +        }
>>> +    else /* line == 1 */
>>> +        switch (bit) {
>>> +        case 47: /* PTP */
>>> +            edge = true;
>>> +            break;
>>> +        default:
>>> +            break;
>>> +        }
>>> +    return edge;
>>
>> Moving in the right direction, but I still don't get why this is not in
>> the CIU binding as a 3rd cell?
> 
> There are a several reasons, in no particular order they are:
> 
> o There is no 3rd cell.  The bindings were discussed with Grant here:
>   http://www.linux-mips.org/archives/linux-mips/2011-05/msg00355.html
> 

Then add one.

> o The edge/level thing cannot be changed, and the irq lines don't leave
> the SOC, so hard coding it is possible.

Right, but DT describes h/w connections and this is an aspect of the
connection. This may be fixed for the SOC, but it's not fixed for the
CIU (i.e. could change in future chips), right?

There's 2 reasons why you would not put this into DTS:

- All irq lines' trigger type are the same, fixed and known.
- You can read a register to tell you the trigger type.

Even if it's not going to change ever, it's still worth putting into the
DTS as it is well suited for holding that data and it is just data.

> 
>>
>>> +}
>>> +
>>> +struct octeon_irq_gpio_domain_data {
>>> +    unsigned int base_hwirq;
>>> +};
>>> +
>>> +static int octeon_irq_gpio_xlat(struct irq_domain *d,
>>> +                struct device_node *node,
>>> +                const u32 *intspec,
>>> +                unsigned int intsize,
>>> +                unsigned long *out_hwirq,
>>> +                unsigned int *out_type)
>>> +{
>>> +    unsigned int type;
>>> +    unsigned int pin;
>>> +    unsigned int trigger;
>>> +    bool set_edge_handler = false;
>>> +    struct octeon_irq_gpio_domain_data *gpiod;
>>> +
>>> +    if (d->of_node != node)
>>> +        return -EINVAL;
>>> +
>>> +    if (intsize<  2)
>>> +        return -EINVAL;
>>> +
>>> +    pin = intspec[0];
>>> +    if (pin>= 16)
>>> +        return -EINVAL;
>>> +
>>> +    trigger = intspec[1];
>>> +
>>> +    switch (trigger) {
>>> +    case 1:
>>> +        type = IRQ_TYPE_EDGE_RISING;
>>> +        set_edge_handler = true;
>>
>> This is never used.
> 
> Right, it was leftover from the previous version.
> 
>>
>>> +        break;
>>> +    case 2:
>>> +        type = IRQ_TYPE_EDGE_FALLING;
>>> +        set_edge_handler = true;
>>> +        break;
>>> +    case 4:
>>> +        type = IRQ_TYPE_LEVEL_HIGH;
>>> +        break;
>>> +    case 8:
>>> +        type = IRQ_TYPE_LEVEL_LOW;
>>> +        break;
>>> +    default:
>>> +        pr_err("Error: (%s) Invalid irq trigger specification: %x\n",
>>> +               node->name,
>>> +               trigger);
>>> +        type = IRQ_TYPE_LEVEL_LOW;
>>> +        break;
>>> +    }
>>> +    *out_type = type;
>>
>> Can't you get rid of the whole switch statement and just do:
>>
>> *out_type = intspec[1];
> 
> That wouldn't catch erroneous values like 6.
> 

if (!x || fls(x) != ffs(x))
	// ERROR


>>
> [...]
>>> +static int octeon_irq_ciu_map(struct irq_domain *d,
>>> +                  unsigned int virq, irq_hw_number_t hw)
>>> +{
>>> +    unsigned int line = hw>>  6;
>>> +    unsigned int bit = hw&  63;
>>> +
>>> +    if (virq>= 256)
>>> +        return -EINVAL;
>>
>> Drop this. You should not care what the virq numbers are.
> 
> 
> I care that they don't overflow the width of octeon_irq_ciu_to_irq (a u8).
> 
> So really I want to say:
> 
>    if (virq >= (1 << sizeof (octeon_irq_ciu_to_irq[0][0]))) {
>        WARN(...);
>        return -EINVAL;
>    }
> 
> 
> I need a map external to any one irq_domain.  The irq handling code
> handles sources that come from two separate irq_domains, as well as irqs
> that are not part of any domain.
> 

Okay, but ultimately this needs to go. The irqdomain provides no
guarantee of irq numbers assigned.

Rob

  reply	other threads:[~2012-03-27 22:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26 19:31 [PATCH v7 0/4] MIPS: OCTEON: Use Device Tree David Daney
2012-03-26 19:31 ` [PATCH v7 1/4] MIPS: Don't define early_init_devtree() and device_tree_init() in prom.c for CPU_CAVIUM_OCTEON David Daney
2012-03-26 19:31 ` [PATCH v7 2/4] MIPS: Octeon: Setup irq_domains for interrupts David Daney
     [not found]   ` <1332790281-9648-3-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-03-27  1:56     ` Rob Herring
2012-03-27 18:24       ` David Daney
2012-03-27 22:05         ` Rob Herring [this message]
2012-03-27 22:31           ` David Daney
2012-03-28 14:21             ` Rob Herring
2012-03-28 16:16               ` David Daney
2012-03-28 22:08                 ` Grant Likely
2012-03-29  1:46                   ` David Daney
2012-03-28 22:22         ` Grant Likely
2012-03-29  1:41           ` David Daney
     [not found]             ` <4F73BDAF.7020206-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
2012-03-30 21:54               ` Grant Likely
2012-03-28 22:31   ` Grant Likely
2012-03-29  1:33     ` David Daney
2012-03-26 19:31 ` [PATCH v7 3/4] MIPS: Octeon: Add device tree source files David Daney
2012-03-27  2:38   ` Rob Herring
2012-03-27 18:45     ` David Daney
2012-03-26 19:31 ` [PATCH v7 4/4] MIPS: Octeon: Initialize and fixup device tree David Daney

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=4F7239A4.7070905@gmail.com \
    --to=robherring2@gmail.com \
    --cc=david.daney@cavium.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rob.herring@calxeda.com \
    /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).