Re: [PATCH 1/3] pinctrl: Intel: add RX invertion config

[Linus Walleij <linus.walleij@linaro.org>]

On Tue, Mar 15, 2016 at 3:17 AM, Zheng, Qi <qi.zheng@intel.com> wrote:
>> On Mon, Mar 14, 2016 at 9:56 AM, Zheng, Qi <qi.zheng@intel.com> wrote:
>
>> The "pi330532" device on Broxton requires this function to manually
>> trigger an GPIO input interrupt.
> (...)
>> We have gone through this requirement from CHT to BXT, there was no
>> other better way to simulate the GPIO interrupt for the use of those devices.
>
>> I what you want is to trigger IRQs on GPIO lines using software we
>> need to add that to the GPIOlib subsystem, so this register gets accessed
>> from the GPIO side of things, not through pin control I think?
>
> We have pinctrl control map locally.
> The RX inversion is implemented by pinctrl control calls, pinctrl_pm_select_default_state
> and pinctrl_pm_select_sleep_state.
>
>> We have so many diverse function pointers in the gpiochip, so ability to
>> trigger/test IRQs from software is certainly not a burden.
>
>> I don't understand the real-world usecase though, please explain what kind of problem
>> this is trying to overcome? Why does this pi330532 driver need to do that, why can
>> it not just inform the driver that needs this interrupt that it should wake up, e.g by
>> using a notification or just an open-coded function call or whatever?
>
> According to the pi330532 driver owner,
> "
> we needed this support to simulate the HPD interrupt behavior as we don’t have
> dedicated interrupt line for Type-C DP HPD.

- What is a HPD interrupt?
- What is a Type-C DP HPD?
- Again why can't you just use a notifier or function call?

> We don’t have any notifications mechasism b/w USB and display/Gfx stack and
> also not the ideal way to handle.  HPD toggling is the preferred approach suggested
> by VPG and HW teams to meet timing requirements also.

What is VPG? Now it seems Intel's internal organization is being used as
part of the argument to get this change in and that makes me a bit
annoyed.

If there is no good notification mechanism then implement one instead
of starting to software-generate hardware interrupts.

I also start to get the feeling that these USB and display stacks
you are referring to are not the upstream versions.

> static void hpd_trigger(struct pi3usb30532_mux *chip, int state)
> {
>         dev_info(&chip->client->dev, "[HPD trigger] state : %d\n", state);
>
>         if (state)
>                 pinctrl_pm_select_default_state(chip->dev);
>         else
>                 pinctrl_pm_select_sleep_state(chip->dev);
> }

Can we get the *TECHNICAL* explanation of why this thing needs
to be done instead of using a notifier or function call?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html