All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andy@kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: baytrail: Clear direct_irq_en flag on broken configs
Date: Sat, 8 Jan 2022 10:59:47 +0100	[thread overview]
Message-ID: <ba1e407a-76e4-5a81-1cf2-45766be35b2a@redhat.com> (raw)
In-Reply-To: <CAHp75Vfgpm7sROw_Ay8+tK0bhu-kCbS=O_kwax+i_vaH7H4wXA@mail.gmail.com>

Hi,

On 1/8/22 01:04, Andy Shevchenko wrote:
> 
> 
> On Saturday, January 8, 2022, Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> wrote:
> 
>     Some boards set the direct_irq_en flag in the conf0 register without
>     setting any of the trigger bits. The direct_irq_en flag just means that
>     the GPIO will send IRQs directly to the APIC instead of going through
>     the shared interrupt for the GPIO controller, in order for the pin to
>     be able to actually generate IRQs the trigger flags must still be set.
> 
>     So having the direct_irq_en flag set without any trigger flags is
>     non-sense, log a FW_BUG warning when encountering this and clear the flag
>     so that a driver can actually use the pin as IRQ through gpiod_to_irq().
> 
>     Specifically this allows the edt-ft5x06 touchscreen driver to use
>     INT33FC:02 pin 3 as touchscreen IRQ on the Nextbook Ares 8 tablet,
>     accompanied by the following new log message:
> 
>     byt_gpio INT33FC:02: [Firmware Bug]: pin 3: direct_irq_en set without trigger, clearing
> 
>     The new byt_direct_irq_sanity_check() function also checks that the
>     pin is actually appointed to one of the 16 direct-IRQs which the GPIO
>     controller supports and on success prints debug messages like these:
> 
>     byt_gpio INT33FC:02: Pin 0: uses direct IRQ 0 (APIC 67)
>     byt_gpio INT33FC:02: Pin 15: uses direct IRQ 2 (APIC 69)
> 
> 
> Should be these updated?

Yes the " (APIC 6x)" part is gone now. I will fix this for v4.

>     This is useful to figure out the GPIO pin belonging to ACPI
>     resources like this one: "Interrupt () { 0x00000043 }" or
>     the other way around.
> 
>     Suggested-by: Andy Shevchenko <andy@kernel.org <mailto:andy@kernel.org>>
>     Signed-off-by: Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>>
>     ---
>     Changes in v3:
>     - Rework code to check if the pin is assigned one of the 16 direct IRQs
>       (new code suggested-by Andy)
>     - Drop dev_dbg of the (likely?) APIC IRQ, only log the direct IRQ index
> 
> 
> Thinking about direct IRQ mappings I will look into the Datasheet next week.

Ok, I will wait for you to get back to me then before posting a v4.

>  
> 
>     Changes in v2:
>     - Add "FW_BUG pin %i: direct_irq_en set but no IRQ assigned, clearing" warning
>     ---
>      drivers/pinctrl/intel/pinctrl-baytrail.c | 31 ++++++++++++++++++++++--
>      1 file changed, 29 insertions(+), 2 deletions(-)
> 
>     diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c
>     index 4c01333e1406..508b8a1cad1f 100644
>     --- a/drivers/pinctrl/intel/pinctrl-baytrail.c
>     +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
>     @@ -32,6 +32,7 @@
>      #define BYT_VAL_REG            0x008
>      #define BYT_DFT_REG            0x00c
>      #define BYT_INT_STAT_REG       0x800
>     +#define BYT_DIRECT_IRQ_REG     0x980
>      #define BYT_DEBOUNCE_REG       0x9d0
> 
>      /* BYT_CONF0_REG register bits */
>     @@ -1465,6 +1466,27 @@ static void byt_gpio_irq_handler(struct irq_desc *desc)
>             chip->irq_eoi(data);
>      }
> 
>     +static bool byt_direct_irq_sanity_check(struct intel_pinctrl *vg, int pin, u32 value)
>     +{
>     +       u8 *match, direct_irq[16];
> 
> 
> Oops, I thought it’ 16 u32 you need to read and in u8 it’s 64, which one is correct?

There are 4 32 bit registers, the original code before your suggested
refactoring did 4 readl()s . And each register holds 4 pin-numbers, for
a total of maximum 16 direct IRQs.

This is in the public datasheets, except that the public datasheet does
not explain the meaning the byte (7 bits really, the 8th bit is reserved /
always 0). The datasheet simply calls the 7 bits per direct IRQ "Direct0" /
"Direct1", etc.

That these 7 bits are actually the pin number of the pin triggering the
direct IRQ is something which I figured out by looking at a number of
cases where both the APIC IRQ number as well as the used pin were known,
allowing me to figure out the mapping.

Regards,

Hans







>  
> 
>     +
>     +       if (!(value & (BYT_TRIG_POS | BYT_TRIG_NEG))) {
>     +               dev_warn(vg->dev,
>     +                        FW_BUG "pin %i: direct_irq_en set without trigger, clearing\n", pin);
>     +               return false;
>     +       }
>     +
>     +       memcpy_fromio(direct_irq, vg->communities->pad_regs + BYT_DIRECT_IRQ_REG,
>     +                     sizeof(direct_irq));
>     +       match = memchr(direct_irq, pin, sizeof(direct_irq));
>     +       if (match)
>     +               dev_dbg(vg->dev, "Pin %i: uses direct IRQ %ld\n", pin, match - direct_irq);
>     +       else
>     +               dev_warn(vg->dev, FW_BUG "pin %i: direct_irq_en set but no IRQ assigned, clearing\n", pin);
>     +
>     +       return match;
>     +}
>     +
>      static void byt_init_irq_valid_mask(struct gpio_chip *chip,
>                                         unsigned long *valid_mask,
>                                         unsigned int ngpios)
>     @@ -1492,8 +1514,13 @@ static void byt_init_irq_valid_mask(struct gpio_chip *chip,
>      
>                     value = readl(reg);
>                     if (value & BYT_DIRECT_IRQ_EN) {
>     -                       clear_bit(i, valid_mask);
>     -                       dev_dbg(vg->dev, "excluding GPIO %d from IRQ domain\n", i);
>     +                       if (byt_direct_irq_sanity_check(vg, i, value)) {
>     +                               clear_bit(i, valid_mask);
>     +                       } else {
>     +                               value &= ~(BYT_DIRECT_IRQ_EN | BYT_TRIG_POS |
>     +                                          BYT_TRIG_NEG | BYT_TRIG_LVL);
>     +                               writel(value, reg);
>     +                       }
>                     } else if ((value & BYT_PIN_MUX) == byt_get_gpio_mux(vg, i)) {
>                             byt_gpio_clear_triggering(vg, i);
>                             dev_dbg(vg->dev, "disabling GPIO %d\n", i);
>     -- 
>     2.33.1
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 


  parent reply	other threads:[~2022-01-08  9:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07 23:44 [PATCH v3] pinctrl: baytrail: Clear direct_irq_en flag on broken configs Hans de Goede
     [not found] ` <CAHp75Vfgpm7sROw_Ay8+tK0bhu-kCbS=O_kwax+i_vaH7H4wXA@mail.gmail.com>
2022-01-08  9:59   ` Hans de Goede [this message]
2022-01-12 20:20     ` [PATCH] " Hans de Goede
2022-01-12 20:42       ` Andy Shevchenko
2022-01-12 20:45         ` Hans de Goede
2022-01-08 18:54 ` [PATCH v3] " kernel test robot
2022-01-08 18:54   ` kernel test robot
2022-01-12 19:58   ` Hans de Goede
2022-01-12 19:58     ` Hans de Goede
2022-01-12 20:44     ` Andy Shevchenko
2022-01-12 20:44       ` Andy Shevchenko
2022-01-12 20:50       ` Hans de Goede
2022-01-12 20:50         ` Hans de Goede
2022-01-12 21:01         ` Andy Shevchenko
2022-01-12 21:01           ` Andy Shevchenko
2022-01-08 18:54 ` kernel test robot
2022-01-08 18:54   ` kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2022-01-07 14:18 [PATCH] " Hans de Goede
2022-01-07 14:20 ` Hans de Goede

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=ba1e407a-76e4-5a81-1cf2-45766be35b2a@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.