All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Dave Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Sandeep Panda <spanda@codeaurora.org>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	MSM <linux-arm-msm@vger.kernel.org>,
	Rob Clark <robdclark@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
Date: Tue, 12 May 2020 14:28:25 +0200	[thread overview]
Message-ID: <CACRpkdYedMY1Byrg4uyw-DkjLX0NVh5uFngUT+1F2tdfNMx29A@mail.gmail.com> (raw)
In-Reply-To: <20200507143354.v5.1.Ia50267a5549392af8b37e67092ca653a59c95886@changeid>

On Thu, May 7, 2020 at 11:35 PM Douglas Anderson <dianders@chromium.org> wrote:

> 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@chromium.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Looks good mostly!

> +       pdata->gchip.label = dev_name(pdata->dev);
> +       pdata->gchip.parent = pdata->dev;
> +       pdata->gchip.owner = THIS_MODULE;
> +       pdata->gchip.of_xlate = tn_sn_bridge_of_xlate;
> +       pdata->gchip.of_gpio_n_cells = 2;
> +       pdata->gchip.free = ti_sn_bridge_gpio_free;
> +       pdata->gchip.get_direction = ti_sn_bridge_gpio_get_direction;
> +       pdata->gchip.direction_input = ti_sn_bridge_gpio_direction_input;
> +       pdata->gchip.direction_output = ti_sn_bridge_gpio_direction_output;
> +       pdata->gchip.get = ti_sn_bridge_gpio_get;
> +       pdata->gchip.set = ti_sn_bridge_gpio_set;
> +       pdata->gchip.can_sleep = true;
> +       pdata->gchip.names = ti_sn_bridge_gpio_names;
> +       pdata->gchip.ngpio = SN_NUM_GPIOS;

Please add:
pdata->gchip.base = -1;

So it is clear that you use dynamically assigned GPIO numbers,
with that:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: Rob Clark <robdclark@chromium.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Dave Airlie <airlied@linux.ie>,
	MSM <linux-arm-msm@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	Sandeep Panda <spanda@codeaurora.org>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Jonas Karlman <jonas@kwiboo.se>, Rob Herring <robh+dt@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Stephen Boyd <swboyd@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
Date: Tue, 12 May 2020 14:28:25 +0200	[thread overview]
Message-ID: <CACRpkdYedMY1Byrg4uyw-DkjLX0NVh5uFngUT+1F2tdfNMx29A@mail.gmail.com> (raw)
In-Reply-To: <20200507143354.v5.1.Ia50267a5549392af8b37e67092ca653a59c95886@changeid>

On Thu, May 7, 2020 at 11:35 PM Douglas Anderson <dianders@chromium.org> wrote:

> 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@chromium.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Looks good mostly!

> +       pdata->gchip.label = dev_name(pdata->dev);
> +       pdata->gchip.parent = pdata->dev;
> +       pdata->gchip.owner = THIS_MODULE;
> +       pdata->gchip.of_xlate = tn_sn_bridge_of_xlate;
> +       pdata->gchip.of_gpio_n_cells = 2;
> +       pdata->gchip.free = ti_sn_bridge_gpio_free;
> +       pdata->gchip.get_direction = ti_sn_bridge_gpio_get_direction;
> +       pdata->gchip.direction_input = ti_sn_bridge_gpio_direction_input;
> +       pdata->gchip.direction_output = ti_sn_bridge_gpio_direction_output;
> +       pdata->gchip.get = ti_sn_bridge_gpio_get;
> +       pdata->gchip.set = ti_sn_bridge_gpio_set;
> +       pdata->gchip.can_sleep = true;
> +       pdata->gchip.names = ti_sn_bridge_gpio_names;
> +       pdata->gchip.ngpio = SN_NUM_GPIOS;

Please add:
pdata->gchip.base = -1;

So it is clear that you use dynamically assigned GPIO numbers,
with that:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-05-12 12:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 21:34 [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Douglas Anderson
2020-05-07 21:34 ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-11 16:24   ` Stephen Boyd
2020-05-11 16:24     ` Stephen Boyd
2020-05-12  1:36   ` Bjorn Andersson
2020-05-12  1:36     ` Bjorn Andersson
2020-05-12 12:28   ` Linus Walleij [this message]
2020-05-12 12:28     ` Linus Walleij
2020-05-07 21:34 ` [PATCH v5 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare() Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 4/6] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-11 16:25   ` Stephen Boyd
2020-05-11 16:25     ` Stephen Boyd
2020-05-07 21:34 ` [PATCH v5 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:35 ` [PATCH v5 6/6] arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza Douglas Anderson
2020-05-07 21:35   ` Douglas Anderson
2020-05-12  1:21   ` Bjorn Andersson
2020-05-12  1:21     ` Bjorn Andersson
2020-05-09 20:15 ` [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Sam Ravnborg
2020-05-09 20:15   ` Sam Ravnborg
2020-05-09 22:48   ` Doug Anderson
2020-05-09 22:48     ` Doug Anderson
2020-05-18 14:50     ` Doug Anderson
2020-05-18 14:50       ` Doug Anderson
2020-05-18 17:59       ` Sam Ravnborg
2020-05-18 17:59         ` Sam Ravnborg
2020-05-18 18:05         ` Doug Anderson
2020-05-18 18:05           ` Doug Anderson
2020-05-18 18:28           ` Sam Ravnborg
2020-05-18 18:28             ` Sam Ravnborg

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=CACRpkdYedMY1Byrg4uyw-DkjLX0NVh5uFngUT+1F2tdfNMx29A@mail.gmail.com \
    --to=linus.walleij@linaro.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=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 \
    --cc=swboyd@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.