lkml.org 
[lkml]   [2020]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
From
Date
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@chromium.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.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)
> {

\
 
 \ /
  Last update: 2020-04-22 12:36    [W:0.119 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site