| Message ID | 20200420220458.v2.1.Ia50267a5549392af8b37e67092ca653a59c95886@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect | expand |
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) > {
Hi, On Wed, Apr 22, 2020 at 3:23 AM Stephen Boyd <swboyd@chromium.org> wrote: > > 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? Don't bitmaps need an external lock to protect against concurrent access? When I looked I wasn't convinced that the GPIO subsystem prevented two callers from changing two GPIOs at the same time. See below for a bigger discussion. > > + 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? A few reasons: 1. If nobody else had the bridge powered on this would be a slow operation involving powering the bridge on, querying via i2c, and then powering the bridge off. Not only would it be slow but you'd be powering the chip up for no really good reason. You didn't need to know anything that only the chip could tell you. 2. If nobody else had the bridge powered on then the bridge loses state and resets to defaults (everything resets to "input"). Yes, we could still power the bridge up and confirm this, but... 3. This bitmap does double-duty of not only knowing whether a pin is input or output but also whether we've incremented the "pm_runtime" refcount in order to keep the output driven. Knowing whether we've already incremented the "pm_runtime" refcount can simplify a bit of the code because we know whether it's powered without having to power it on and query. If we didn't have a cache, then when we changed a pin to input we'd do: pm_runtime_get() // Make sure we can access if dir_was_output: pm_runtime_put() // Not driving anymore set_to_input(); pm_runtime_put() // Done with access ...basically in some cases we'd do pm_runtime_put() twice in the same function. It'd work, but feels like a worse solution than the one in my patch. 4. When I bootup I see that this call gets made once per GPIO in gpiochip_add_data_with_key(). There's no reason to go through all the slowness when we know these pins are inputs. In the next version of the patch I'll plan to add a kerneldoc comment to "struct ti_sn_bridge" and add a summary of the above for "gchip_output". > > +} > > + > [...] > > +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? Right. I've assumed that we're not running two of these functions at the same time for the same GPIO. I'm not convinced that the GPIO core enforces this but it seems like it'd be undefined behavior for a client to be, for instance, setting and changing direction for the same GPIO in two threads at the same time. Where simple I've tried to make it so it wouldn't horribly break if someone did some amount of concurrent access of the same pin but not every corner case is handled. Mostly I focused on making sure that I could never mess up keeping track of whether I incremented the "pm_runtime" refcount for a pin. One thing specifically I didn't handle: if we were midway through ti_sn_bridge_gpio_set(), we context switched out and someone changed us to an input, then we'd possibly do an unpowered regmap_update_bits() and timeout. What I do think is a sensible case to handle, though, is someone working with two different GPIOs exported by this controller at the same time. IIUC atomic_t allows me to only spend 1 bit per pin, have no lock, and still make sure these different consumers don't stomp on each other. NOTE: I did a quick trace for the call chain when using the "gpioget" command-line tool. I saw: - ti_sn_bridge_gpio_get() - gpio_chip_get_multiple() - gpiod_get_array_value_complex() - linehandle_ioctl() None of these appear to do any locking. There's sorta an implicit lock in that only one client can "request" a given GPIO at the same time so the assumption that we're somewhat protected against two concurrent accesses of the exact same GPIO is a bit justified. ...but nothing appears to protect us from concurrent accesses of different GPIOs. I also notice that other GPIO drivers seem to grab their own locks. If it makes the patch more palatable, I can get rid of all the atomic stuff and put in a big mutex? -Doug
Quoting Doug Anderson (2020-04-22 09:09:17) > Hi, > > On Wed, Apr 22, 2020 at 3:23 AM Stephen Boyd <swboyd@chromium.org> wrote: > > > > Quoting Douglas Anderson (2020-04-20 22:06:17) > > > > > 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? > > Don't bitmaps need an external lock to protect against concurrent > access? Bitmaps are sometimes atomic. See Documentation/atomic_bitops.txt for more info. From what I see here it looks like we can have a bitmap for this and then use set_bit(), test_and_set_bit(), etc. and it will be the same and easier to read. > When I looked I wasn't convinced that the GPIO subsystem > prevented two callers from changing two GPIOs at the same time. See > below for a bigger discussion. > > > > > + 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? > [...] > > In the next version of the patch I'll plan to add a kerneldoc comment > to "struct ti_sn_bridge" and add a summary of the above for > "gchip_output". Yeah it deserves a comment in the code indicating why it doesn't read the hardware. > > > > > +} > > > + > > [...] > > > +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? [...] > None of these appear to do any locking. There's sorta an implicit > lock in that only one client can "request" a given GPIO at the same > time so the assumption that we're somewhat protected against two > concurrent accesses of the exact same GPIO is a bit justified. ...but > nothing appears to protect us from concurrent accesses of different > GPIOs. > > I also notice that other GPIO drivers seem to grab their own locks. > If it makes the patch more palatable, I can get rid of all the atomic > stuff and put in a big mutex? No. I'd rather see the bitmap APIs used instead of a custom bitmap overlaid on an atomic_t. Otherwise it seems fine to assume a GPIO can't be touched by two entities at once and thus nothing to worry about for locking at the driver level for that.
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 @@ -7,6 +7,8 @@ #include <linux/clk.h> #include <linux/debugfs.h> #include <linux/gpio/consumer.h> +#include <linux/gpio/driver.h> +#include <linux/gpio.h> #include <linux/i2c.h> #include <linux/iopoll.h> #include <linux/module.h> @@ -54,6 +56,13 @@ #define BPP_18_RGB BIT(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_OUTPUT 1 +#define SN_GPIO_MUX_SPECIAL 2 #define SN_AUX_WDATA_REG(x) (0x64 + (x)) #define SN_AUX_ADDR_19_16_REG 0x74 #define SN_AUX_ADDR_15_8_REG 0x75 @@ -102,6 +111,9 @@ struct ti_sn_bridge { struct gpio_desc *enable_gpio; struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM]; int dp_lanes; + + struct gpio_chip gchip; + atomic_t gchip_output; }; static const struct regmap_range ti_sn_bridge_volatile_ranges[] = { @@ -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)) ? + GPIOF_DIR_OUT : GPIOF_DIR_IN; +} + +static int ti_sn_bridge_gpio_get(struct gpio_chip *chip, unsigned int offset) +{ + struct ti_sn_bridge *pdata = gchip_to_pdata(chip); + unsigned int val; + int ret; + + /* + * When the pin is an input we don't forcibly keep the bridge + * powered--we just power it on to read the pin. NOTE: part of + * the reason this works is that the bridge defaults to all 4 + * GPIOs being configured as GPIO input. Also note that if + * something else is keeping the chip powered the pm_runtime + * functions are lightweight increments of a refcount. + */ + pm_runtime_get_sync(pdata->dev); + ret = regmap_read(pdata->regmap, SN_GPIO_IO_REG, &val); + pm_runtime_put(pdata->dev); + + if (ret) + return ret; + + return (val >> (SN_GPIO_INPUT_SHIFT + offset)) & 1; +} + +static void ti_sn_bridge_gpio_set(struct gpio_chip *chip, unsigned int offset, + int val) +{ + struct ti_sn_bridge *pdata = gchip_to_pdata(chip); + int ret; + + if (!(atomic_read(&pdata->gchip_output) & BIT(offset))) { + dev_err(pdata->dev, "Ignoring GPIO set while input\n"); + return; + } + + val &= 1; + ret = regmap_update_bits(pdata->regmap, SN_GPIO_IO_REG, + BIT(SN_GPIO_OUTPUT_SHIFT + offset), + val << (SN_GPIO_OUTPUT_SHIFT + offset)); +} + +static int ti_sn_bridge_gpio_direction_input(struct gpio_chip *chip, + unsigned int offset) +{ + struct ti_sn_bridge *pdata = gchip_to_pdata(chip); + int shift = offset * 2; + int old_gchip_output; + int ret; + + old_gchip_output = atomic_fetch_andnot(BIT(offset), + &pdata->gchip_output); + if (!(old_gchip_output & BIT(offset))) + return 0; + + ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG, + 0x3 << shift, SN_GPIO_MUX_INPUT << shift); + if (ret) { + atomic_or(BIT(offset), &pdata->gchip_output); + return ret; + } + + pm_runtime_put(pdata->dev); + + return 0; +} + +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); + 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) +{ + int ret; + + /* Only init if someone is going to use us as a GPIO controller */ + if (!of_property_read_bool(pdata->dev->of_node, "gpio-controller")) + return 0; + + pdata->gchip.label = dev_name(pdata->dev); + pdata->gchip.parent = pdata->dev; + pdata->gchip.owner = THIS_MODULE; + 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 = 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; +} + static int ti_sn_bridge_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -937,6 +1096,12 @@ static int ti_sn_bridge_probe(struct i2c_client *client, pm_runtime_enable(pdata->dev); + ret = ti_sn_setup_gpio_controller(pdata); + if (ret) { + pm_runtime_disable(pdata->dev); + return ret; + } + i2c_set_clientdata(client, pdata); pdata->aux.name = "ti-sn65dsi86-aux";
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 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> --- 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(+)