[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <158784350116.117437.9524374865698963301@swboyd.mtv.corp.google.com>
Date: Sat, 25 Apr 2020 12:38:21 -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: devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
jeffrey.l.hugo@...il.com, dri-devel@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, robdclark@...omium.org,
jernej.skrabec@...l.net, jonas@...boo.se,
bjorn.andersson@...aro.org,
Douglas Anderson <dianders@...omium.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
Quoting Douglas Anderson (2020-04-23 09:25:43)
> 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.
>
> Because of all of the above limitations we just need to implement a
> 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>
> ---
Reviewed-by: Stephen Boyd <swboyd@...omium.org>
Powered by blists - more mailing lists