Date:   Wed, 22 Apr 2020 03:23:26 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Douglas Anderson <dianders@...omium.org>,
        Laurent.pinchart@...asonboard.com, a.hajda@...sung.com,
        airlied@...ux.ie, bgolaszewski@...libre.com, daniel@...ll.ch,
        linus.walleij@...aro.org, narmstrong@...libre.com,
        robh+dt@...nel.org, spanda@...eaurora.org
Cc:     jonas@...boo.se, jeffrey.l.hugo@...il.com,
        linux-gpio@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        jernej.skrabec@...l.net, bjorn.andersson@...aro.org,
        robdclark@...omium.org, Douglas Anderson <dianders@...omium.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

Quoting Douglas Anderson (2020-04-20 22:06:17)
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> be used as GPIOs in a system.  Each pin can be configured as input,
> output, or a special function for the bridge chip.  These are:
> - GPIO1: SUSPEND Input
> - GPIO2: DSIA VSYNC
> - GPIO3: DSIA HSYNC or VSYNC
> - GPIO4: PWM
> 
> Let's expose these pins as GPIOs.  A few notes:
> - Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
> - These pins can't be configured for IRQ.
> - There are no programmable pulls or other fancy features.
> - Keeping the bridge chip powered might be expensive.  The driver is
>   setup such that if all used GPIOs are only inputs we'll power the
>   bridge chip on just long enough to read the GPIO and then power it
>   off again.  Setting a GPIO as output will keep the bridge powered.
> - If someone releases a GPIO we'll implicitly switch it to an input so
>   we no longer need to keep the bridge powered for it.
> 
> Becaue of all of the above limitations we just need to implement a

Because

> bare-bones GPIO driver.  The device tree bindings already account for
> this device being a GPIO controller so we only need the driver changes
> for it.
> 
> NOTE: Despite the fact that these pins are nominally muxable I don't
> believe it makes sense to expose them through the pinctrl interface as
> well as the GPIO interface.  The special functions are things that the
> bridge chip driver itself would care about and it can just configure
> the pins as needed.
> 
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> Cc: Linus Walleij <linus.walleij@...aro.org>
> Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>
> ---
> 

Cool patch.

> Changes in v2:
> - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
> 
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 165 ++++++++++++++++++++++++++
>  1 file changed, 165 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 6ad688b320ae..d04c2b83d699 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -874,6 +886,153 @@ static int ti_sn_bridge_parse_dsi_host(struct ti_sn_bridge *pdata)
>         return 0;
>  }
>  
> +static struct ti_sn_bridge *gchip_to_pdata(struct gpio_chip *chip)
> +{
> +       return container_of(chip, struct ti_sn_bridge, gchip);
> +}
> +
> +static int ti_sn_bridge_gpio_get_direction(struct gpio_chip *chip,
> +                                          unsigned int offset)
> +{
> +       struct ti_sn_bridge *pdata = gchip_to_pdata(chip);
> +
> +       return (atomic_read(&pdata->gchip_output) & BIT(offset)) ?

Any reason this isn't a bitmap?

> +               GPIOF_DIR_OUT : GPIOF_DIR_IN;

And why can't we read the hardware to figure out if it's in output or
input mode?

> +}
> +
[...]
> +static int ti_sn_bridge_gpio_direction_output(struct gpio_chip *chip,
> +                                             unsigned int offset, int val)
> +{
> +       struct ti_sn_bridge *pdata = gchip_to_pdata(chip);
> +       int shift = offset * 2;
> +       int old_gchip_output;
> +       int ret;
> +
> +       old_gchip_output = atomic_fetch_or(BIT(offset), &pdata->gchip_output);

I presume gpiolib is already preventing a gpio from being modified twice
at the same time. So is this atomic stuff really necessary?

> +       if (old_gchip_output & BIT(offset))
> +               return 0;
> +
> +       pm_runtime_get_sync(pdata->dev);
> +
> +       /* Set value first to avoid glitching */
> +       ti_sn_bridge_gpio_set(chip, offset, val);
> +
> +       /* Set direction */
> +       ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,
> +                                0x3 << shift, SN_GPIO_MUX_OUTPUT << shift);
> +       if (ret) {
> +               atomic_andnot(BIT(offset), &pdata->gchip_output);
> +               pm_runtime_put(pdata->dev);
> +       }
> +
> +       return ret;
> +}
> +
> +static void ti_sn_bridge_gpio_free(struct gpio_chip *chip, unsigned int offset)
> +{
> +       /* We won't keep pm_runtime if we're input, so switch there on free */
> +       ti_sn_bridge_gpio_direction_input(chip, offset);
> +}
> +
> +static const char * const ti_sn_bridge_gpio_names[] = {
> +       "GPIO1", "GPIO2", "GPIO3", "GPIO4"
> +};
> +
> +static int ti_sn_setup_gpio_controller(struct ti_sn_bridge *pdata)
> +{
[...]
> +       pdata->gchip.names = ti_sn_bridge_gpio_names;
> +       pdata->gchip.ngpio = ARRAY_SIZE(ti_sn_bridge_gpio_names);
> +       ret = devm_gpiochip_add_data(pdata->dev, &pdata->gchip, pdata);
> +       if (ret) {
> +               dev_err(pdata->dev, "can't add gpio chip\n");
> +               return ret;
> +       }
> +
> +       return 0;

return ret?

> +}
> +
>  static int ti_sn_bridge_probe(struct i2c_client *client,
>                               const struct i2c_device_id *id)
>  {

Powered by blists - more mailing lists