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

["Zheng, Qi" <qi.zheng@xxxxxxxxx>]

> On Mon, Mar 14, 2016 at 9:56 AM, Zheng, Qi <qi.zheng@xxxxxxxxx> 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.

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.

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);
}

"

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at  http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n�����{��
b���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f