Re: [PATCH v4 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

2020-05-12 Thread Linus Walleij
On Thu, May 7, 2020 at 4:39 PM Doug Anderson  wrote:

> One suggestion that came off-list is to change the code to make the
> numbering match up better with the datasheet.  Right now if you want
> GPIO 2 you have to refer to it like:
>
> hpd-gpios = <_bridge 1 GPIO_ACTIVE_HIGH>;
>
> That's because the code right now numbers things starting at 0 even if
> the datasheet numbers things starting at 1.

This is the hallmark of mixed-mode IC engineers at work.
They are at heart analog IC designers so of course they
enumerate everything starting at 1.

Digital IC designers are like programmers and start on 0.

Never the twain shall meet...

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


Re: [PATCH v4 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

2020-05-07 Thread Doug Anderson
Hi,

On Thu, Apr 30, 2020 at 12:46 PM Douglas Anderson  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

One suggestion that came off-list is to change the code to make the
numbering match up better with the datasheet.  Right now if you want
GPIO 2 you have to refer to it like:

hpd-gpios = <_bridge 1 GPIO_ACTIVE_HIGH>;

That's because the code right now numbers things starting at 0 even if
the datasheet numbers things starting at 1.

I'm planning to spin the series later today for this.  While at it,
I'll squash my yaml bindings fixup into the bindings patch in this
series.  If someone would rather I wait and not spin yet, please yell.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

2020-04-30 Thread Douglas Anderson
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 
Cc: Linus Walleij 
Cc: Bartosz Golaszewski 
Reviewed-by: Stephen Boyd 
---

Changes in v4:
- Don't include gpio.h
- Use gpiochip_get_data() instead of container_of() to get data.
- GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
- Use Linus W's favorite syntax to read a bit from a bitfield.
- Define and use SN_GPIO_MUX_MASK.
- Add a comment about why we use a bitmap for gchip_output.

Changes in v3:
- Becaue => Because
- Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
- More comments about how powering off affects us (get_dir, dir_input).
- Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
- Use a bitmap rather than rolling my own.

Changes in v2:
- ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")

 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 195 ++
 1 file changed, 195 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6ad688b320ae..1a125423eb07 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -4,9 +4,11 @@
  * datasheet: http://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -54,6 +56,14 @@
 #define  BPP_18_RGBBIT(0)
 #define SN_HPD_DISABLE_REG 0x5C
 #define  HPD_DISABLE   BIT(0)
+#define SN_GPIO_IO_REG 0x5E
+#define  SN_GPIO_INPUT_SHIFT   4
+#define  SN_GPIO_OUTPUT_SHIFT  0
+#define SN_GPIO_CTRL_REG   0x5F
+#define  SN_GPIO_MUX_INPUT 0
+#define  SN_GPIO_MUX_OUTPUT1
+#define  SN_GPIO_MUX_SPECIAL   2
+#define  SN_GPIO_MUX_MASK  0x3
 #define SN_AUX_WDATA_REG(x)(0x64 + (x))
 #define SN_AUX_ADDR_19_16_REG  0x74
 #define SN_AUX_ADDR_15_8_REG   0x75
@@ -88,6 +98,34 @@
 
 #define SN_REGULATOR_SUPPLY_NUM4
 
+#define SN_NUM_GPIOS   4
+
+/**
+ * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
+ * @dev:  Pointer to our device.
+ * @regmap:   Regmap for accessing i2c.
+ * @aux:  Our aux channel.
+ * @bridge:   Our bridge.
+ * @connector:Our connector.
+ * @debugfs:  Used for managing our debugfs.
+ * @host_node:Remote DSI node.
+ * @dsi:  Our MIPI DSI source.
+ * @refclk:   Our reference clock.
+ * @panel:Our panel.
+ * @enable_gpio:  The GPIO we toggle to enable the bridge.
+ * @supplies: Data for bulk enabling/disabling our regulators.
+ * @dp_lanes: Count of dp_lanes we're using.
+ *
+ * @gchip:If we expose our GPIOs, this is used.
+ * @gchip_output: A cache of whether we've set GPIOs to output.  This
+ *serves double-duty of keeping track of the direction and
+ *also keeping track of whether we've incremented the
+ *pm_runtime reference count for this pin, which we do
+ *whenever a pin is configured as an output.  This is a
+ *bitmap so we can do atomic ops on it without an extra
+ *lock so concurrent users of our 4 GPIOs don't stomp on
+ *each other's read-modify-write.
+ */
 struct ti_sn_bridge {
struct device   *dev;
struct regmap   *regmap;
@@ -102,6 +140,9 @@ struct