From: Stephen Boyd <swboyd@chromium.org>
To: Douglas Anderson <dianders@chromium.org>,
Laurent.pinchart@ideasonboard.com, a.hajda@samsung.com,
airlied@linux.ie, bgolaszewski@baylibre.com, daniel@ffwll.ch,
linus.walleij@linaro.org, narmstrong@baylibre.com,
robh+dt@kernel.org, spanda@codeaurora.org
Cc: jonas@kwiboo.se, jeffrey.l.hugo@gmail.com,
linux-gpio@vger.kernel.org, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
jernej.skrabec@siol.net, bjorn.andersson@linaro.org,
robdclark@chromium.org, Douglas Anderson <dianders@chromium.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
Date: Wed, 22 Apr 2020 03:23:26 -0700 [thread overview]
Message-ID: <158755100643.159702.17904334834962681759@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20200420220458.v2.1.Ia50267a5549392af8b37e67092ca653a59c95886@changeid>
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)
> {
next prev parent reply other threads:[~2020-04-22 10:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 5:06 [PATCH v2 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Douglas Anderson
2020-04-21 5:06 ` [PATCH v2 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux Douglas Anderson
2020-04-22 10:23 ` Stephen Boyd [this message]
2020-04-22 16:09 ` Doug Anderson
2020-04-21 5:06 ` [PATCH v2 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings Douglas Anderson
2020-04-22 10:24 ` Stephen Boyd
2020-04-21 5:06 ` [PATCH v2 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare() Douglas Anderson
2020-04-22 21:12 ` Stephen Boyd
2020-04-21 5:06 ` [PATCH v2 4/6] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml Douglas Anderson
2020-04-21 5:06 ` [PATCH v2 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd Douglas Anderson
2020-04-22 10:26 ` Stephen Boyd
2020-04-21 5:06 ` [PATCH v2 6/6] arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza Douglas Anderson
2020-04-22 10:26 ` Stephen Boyd
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=158755100643.159702.17904334834962681759@swboyd.mtv.corp.google.com \
--to=swboyd@chromium.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=bgolaszewski@baylibre.com \
--cc=bjorn.andersson@linaro.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jeffrey.l.hugo@gmail.com \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=narmstrong@baylibre.com \
--cc=robdclark@chromium.org \
--cc=robh+dt@kernel.org \
--cc=spanda@codeaurora.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).