| Message ID | 20200507213500.241695-1-dianders@chromium.org |
|---|---|
| Headers | show |
| Series | drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect | expand |
Hi Douglas. On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote: > > As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86: > Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is > kinda useless, at least for embedded DisplayPort (eDP). However, > despite the fact that the actual HPD pin on the bridge is mostly > useless for eDP, the concept of HPD for eDP still makes sense. It > allows us to optimize out a hardcoded delay that many panels need if > HPD isn't hooked up. Panel timing diagrams show HPD as one of the > events to measure timing from and we have to assume the worst case if > we can't actually read HPD. > > One way to use HPD for eDP without using the mostly useless HPD pin on > ti-sn65dsi86 is to route the panel's HPD somewhere else in the system, > like to a GPIO. This works great because eDP panels aren't physically > hotplugged. That means the debouncing logic that caused us problems > wasn't really needed and a raw GPIO works great. > > As per the above, a smart board designer would realize the value of > HPD and choose to route it to a GPIO somewhere on the board to avoid > the silly sn65dsi86 debouncing. While said "smart designer" could > theoretically route HPD anywhere on the board, a really smart designer > would realize that there are several GPIOs on the bridge itself that > are nearly useless for anything but this purpose and route HPD to one > of those. > > This series of patches is intended to allow the scenario described > above. > > This patch has been tested on a board that is not yet mainline. On > the hardware I have: > - Panel spec says HPD could take up to 200 ms to come up, so without > HPD hooked up we need to delay 200 ms. > - On my board the panel is powered by the same rail as the > touchscreen. By chance of probe order the touchscreen comes up > first. This means by the time we check HPD in ti_sn_bridge_enable() > it's already up. Thus we can use the panel on 200 ms earlier. > - If I measure HPD on this pane it comes up ~56 ms after the panel is > powered. This means I can save 144 ms of delay. > > Side effects (though not main goals) of this series are: > - ti-sn65dsi86 GPIOs are now exported in Linux. > - ti-sn65dsi86 bindings are converted to yaml. > - Common panel bindings now have "hpd-gpios" listed. > - The simple-panel driver in Linux can delay in prepare based on > "hpd-gpios" > - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd" > if HPD isn't hooked up. > > Changes in v5: > - Use of_xlate so that numbers in dts start at 1, not 0. > - Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ > > 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. > - Tacked on "or is otherwise unusable." to description. > > 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. > - Remind how gpio_get_optional() works in the commit message. > - useful implement => useful to implement > > Changes in v2: > - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs") > - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2 > - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs") > - specification => specifier. > - power up => power. > - Added back missing suspend-gpios. > - data-lanes and lane-polarities are are the right place now. > - endpoints don't need to be patternProperties. > - Specified more details for data-lanes and lane-polarities. > - Added old example back in, fixing bugs in it. > - Example i2c bus is just called "i2c", not "i2c1" now. > - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2. > - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2. > > Douglas Anderson (6): > drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux > dt-bindings: display: Add hpd-gpios to panel-common bindings > drm/panel-simple: Support hpd-gpios for delaying prepare() > dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml > dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd > arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza Applied: > dt-bindings: display: Add hpd-gpios to panel-common bindings > drm/panel-simple: Support hpd-gpios for delaying prepare() to drm-misc-next. The others was missing reviews so we need to wait for feedback. Sam
Quoting Douglas Anderson (2020-05-07 14:34:55) > 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> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
On Thu 07 May 14:34 PDT 2020, 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 > > 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. > I'm working on a patch for supporting the PWM controller in the bridge and as you say the muxing for that is better left internal to the bridge driver. > Signed-off-by: Douglas Anderson <dianders@chromium.org> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Regards, Bjorn > --- > Removed Stephen's review tag in v5 to confirm he's good with the way I > implemented of_xlate. > > Changes in v5: > - Use of_xlate so that numbers in dts start at 1, not 0. > > 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 | 214 ++++++++++++++++++++++++++ > 1 file changed, 214 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 6ad688b320ae..4e8df948b3b8 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 <linux/bits.h> > #include <linux/clk.h> > #include <linux/debugfs.h> > #include <linux/gpio/consumer.h> > +#include <linux/gpio/driver.h> > #include <linux/i2c.h> > #include <linux/iopoll.h> > #include <linux/module.h> > @@ -54,6 +56,14 @@ > #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_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,35 @@ > > #define SN_REGULATOR_SUPPLY_NUM 4 > > +#define SN_NUM_GPIOS 4 > +#define SN_GPIO_PHYSICAL_OFFSET 1 > + > +/** > + * 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 +141,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; > + DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS); > }; > > static const struct regmap_range ti_sn_bridge_volatile_ranges[] = { > @@ -874,6 +916,172 @@ static int ti_sn_bridge_parse_dsi_host(struct ti_sn_bridge *pdata) > return 0; > } > > +static int tn_sn_bridge_of_xlate(struct gpio_chip *chip, > + const struct of_phandle_args *gpiospec, > + u32 *flags) > +{ > + if (WARN_ON(gpiospec->args_count < chip->of_gpio_n_cells)) > + return -EINVAL; > + > + if (gpiospec->args[0] > chip->ngpio || gpiospec->args[0] < 1) > + return -EINVAL; > + > + if (flags) > + *flags = gpiospec->args[1]; > + > + return gpiospec->args[0] - SN_GPIO_PHYSICAL_OFFSET; > +} > + > +static int ti_sn_bridge_gpio_get_direction(struct gpio_chip *chip, > + unsigned int offset) > +{ > + struct ti_sn_bridge *pdata = gpiochip_get_data(chip); > + > + /* > + * We already have to keep track of the direction because we use > + * that to figure out whether we've powered the device. We can > + * just return that rather than (maybe) powering up the device > + * to ask its direction. > + */ > + return test_bit(offset, pdata->gchip_output) ? > + GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > +} > + > +static int ti_sn_bridge_gpio_get(struct gpio_chip *chip, unsigned int offset) > +{ > + struct ti_sn_bridge *pdata = gpiochip_get_data(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 (when > + * powered back on) 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 & BIT(SN_GPIO_INPUT_SHIFT + offset)); > +} > + > +static void ti_sn_bridge_gpio_set(struct gpio_chip *chip, unsigned int offset, > + int val) > +{ > + struct ti_sn_bridge *pdata = gpiochip_get_data(chip); > + int ret; > + > + if (!test_bit(offset, pdata->gchip_output)) { > + 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 = gpiochip_get_data(chip); > + int shift = offset * 2; > + int ret; > + > + if (!test_and_clear_bit(offset, pdata->gchip_output)) > + return 0; > + > + ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG, > + SN_GPIO_MUX_MASK << shift, > + SN_GPIO_MUX_INPUT << shift); > + if (ret) { > + set_bit(offset, pdata->gchip_output); > + return ret; > + } > + > + /* > + * NOTE: if nobody else is powering the device this may fully power > + * it off and when it comes back it will have lost all state, but > + * that's OK because the default is input and we're now an input. > + */ > + 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 = gpiochip_get_data(chip); > + int shift = offset * 2; > + int ret; > + > + if (test_and_set_bit(offset, pdata->gchip_output)) > + 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, > + SN_GPIO_MUX_MASK << shift, > + SN_GPIO_MUX_OUTPUT << shift); > + if (ret) { > + clear_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[SN_NUM_GPIOS] = { > + "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.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; > + ret = devm_gpiochip_add_data(pdata->dev, &pdata->gchip, pdata); > + if (ret) > + dev_err(pdata->dev, "can't add gpio chip\n"); > + > + return ret; > +} > + > static int ti_sn_bridge_probe(struct i2c_client *client, > const struct i2c_device_id *id) > { > @@ -937,6 +1145,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"; > -- > 2.26.2.645.ge9eca65c58-goog >
Sam, On Sat, May 9, 2020 at 3:48 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg <sam@ravnborg.org> wrote: > > > > Hi Douglas. > > > > On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote: > > > > > > As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86: > > > Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is > > > kinda useless, at least for embedded DisplayPort (eDP). However, > > > despite the fact that the actual HPD pin on the bridge is mostly > > > useless for eDP, the concept of HPD for eDP still makes sense. It > > > allows us to optimize out a hardcoded delay that many panels need if > > > HPD isn't hooked up. Panel timing diagrams show HPD as one of the > > > events to measure timing from and we have to assume the worst case if > > > we can't actually read HPD. > > > > > > One way to use HPD for eDP without using the mostly useless HPD pin on > > > ti-sn65dsi86 is to route the panel's HPD somewhere else in the system, > > > like to a GPIO. This works great because eDP panels aren't physically > > > hotplugged. That means the debouncing logic that caused us problems > > > wasn't really needed and a raw GPIO works great. > > > > > > As per the above, a smart board designer would realize the value of > > > HPD and choose to route it to a GPIO somewhere on the board to avoid > > > the silly sn65dsi86 debouncing. While said "smart designer" could > > > theoretically route HPD anywhere on the board, a really smart designer > > > would realize that there are several GPIOs on the bridge itself that > > > are nearly useless for anything but this purpose and route HPD to one > > > of those. > > > > > > This series of patches is intended to allow the scenario described > > > above. > > > > > > This patch has been tested on a board that is not yet mainline. On > > > the hardware I have: > > > - Panel spec says HPD could take up to 200 ms to come up, so without > > > HPD hooked up we need to delay 200 ms. > > > - On my board the panel is powered by the same rail as the > > > touchscreen. By chance of probe order the touchscreen comes up > > > first. This means by the time we check HPD in ti_sn_bridge_enable() > > > it's already up. Thus we can use the panel on 200 ms earlier. > > > - If I measure HPD on this pane it comes up ~56 ms after the panel is > > > powered. This means I can save 144 ms of delay. > > > > > > Side effects (though not main goals) of this series are: > > > - ti-sn65dsi86 GPIOs are now exported in Linux. > > > - ti-sn65dsi86 bindings are converted to yaml. > > > - Common panel bindings now have "hpd-gpios" listed. > > > - The simple-panel driver in Linux can delay in prepare based on > > > "hpd-gpios" > > > - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd" > > > if HPD isn't hooked up. > > > > > > Changes in v5: > > > - Use of_xlate so that numbers in dts start at 1, not 0. > > > - Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ > > > > > > 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. > > > - Tacked on "or is otherwise unusable." to description. > > > > > > 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. > > > - Remind how gpio_get_optional() works in the commit message. > > > - useful implement => useful to implement > > > > > > Changes in v2: > > > - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs") > > > - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2 > > > - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs") > > > - specification => specifier. > > > - power up => power. > > > - Added back missing suspend-gpios. > > > - data-lanes and lane-polarities are are the right place now. > > > - endpoints don't need to be patternProperties. > > > - Specified more details for data-lanes and lane-polarities. > > > - Added old example back in, fixing bugs in it. > > > - Example i2c bus is just called "i2c", not "i2c1" now. > > > - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2. > > > - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2. > > > > > > Douglas Anderson (6): > > > drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux > > > dt-bindings: display: Add hpd-gpios to panel-common bindings > > > drm/panel-simple: Support hpd-gpios for delaying prepare() > > > dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml > > > dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd > > > arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza > > > > Applied: > > > dt-bindings: display: Add hpd-gpios to panel-common bindings > > > drm/panel-simple: Support hpd-gpios for delaying prepare() > > to drm-misc-next. > > > > The others was missing reviews so we need to wait for feedback. > > Thanks! > > Given the previous feedback from Linus W, Stephen, and Laurent I > expect things are good enough to land now, but it'd be good to get > confirmation (I removed some of the previous tags just to get > confirmation). If we can get review tags early next week maybe it'll > still be in time to land for 5.8? I think all the others have reviews now. Is there anything blocking them from getting applied? Thanks! -Doug
Hi Douglas. > > Given the previous feedback from Linus W, Stephen, and Laurent I > > expect things are good enough to land now, but it'd be good to get > > confirmation (I removed some of the previous tags just to get > > confirmation). If we can get review tags early next week maybe it'll > > still be in time to land for 5.8? > > I think all the others have reviews now. Is there anything blocking > them from getting applied? Applied, including the small fix pointed out by Linus. Sam
Sam, On Mon, May 18, 2020 at 10:59 AM Sam Ravnborg <sam@ravnborg.org> wrote: > > Hi Douglas. > > > > Given the previous feedback from Linus W, Stephen, and Laurent I > > > expect things are good enough to land now, but it'd be good to get > > > confirmation (I removed some of the previous tags just to get > > > confirmation). If we can get review tags early next week maybe it'll > > > still be in time to land for 5.8? > > > > I think all the others have reviews now. Is there anything blocking > > them from getting applied? > Applied, including the small fix pointed out by Linus. Thanks! Ugh, I just realized what the problem was. I posted a v6 with this fix but insanely somehow didn't CC you (!!!). It was here: https://lore.kernel.org/r/20200513215902.261547-1-dianders@chromium.org I'm super sorry about that and thanks for fixing the nit. That was the only difference between v5 and v6. I just checked what you pushed and it looks great, thank you. -Doug
Hi Douglas, On Mon, May 18, 2020 at 11:05:58AM -0700, Doug Anderson wrote: > Sam, > > On Mon, May 18, 2020 at 10:59 AM Sam Ravnborg <sam@ravnborg.org> wrote: > > > > Hi Douglas. > > > > > > Given the previous feedback from Linus W, Stephen, and Laurent I > > > > expect things are good enough to land now, but it'd be good to get > > > > confirmation (I removed some of the previous tags just to get > > > > confirmation). If we can get review tags early next week maybe it'll > > > > still be in time to land for 5.8? > > > > > > I think all the others have reviews now. Is there anything blocking > > > them from getting applied? > > Applied, including the small fix pointed out by Linus. > > Thanks! Ugh, I just realized what the problem was. I posted a v6 > with this fix but insanely somehow didn't CC you (!!!). It was here: > > https://lore.kernel.org/r/20200513215902.261547-1-dianders@chromium.org > > I'm super sorry about that and thanks for fixing the nit. That was > the only difference between v5 and v6. I just checked what you pushed > and it looks great, thank you. No worries as long as what hits drm-misc-next is OK, which it was in this case. Sam
As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86: Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is kinda useless, at least for embedded DisplayPort (eDP). However, despite the fact that the actual HPD pin on the bridge is mostly useless for eDP, the concept of HPD for eDP still makes sense. It allows us to optimize out a hardcoded delay that many panels need if HPD isn't hooked up. Panel timing diagrams show HPD as one of the events to measure timing from and we have to assume the worst case if we can't actually read HPD. One way to use HPD for eDP without using the mostly useless HPD pin on ti-sn65dsi86 is to route the panel's HPD somewhere else in the system, like to a GPIO. This works great because eDP panels aren't physically hotplugged. That means the debouncing logic that caused us problems wasn't really needed and a raw GPIO works great. As per the above, a smart board designer would realize the value of HPD and choose to route it to a GPIO somewhere on the board to avoid the silly sn65dsi86 debouncing. While said "smart designer" could theoretically route HPD anywhere on the board, a really smart designer would realize that there are several GPIOs on the bridge itself that are nearly useless for anything but this purpose and route HPD to one of those. This series of patches is intended to allow the scenario described above. This patch has been tested on a board that is not yet mainline. On the hardware I have: - Panel spec says HPD could take up to 200 ms to come up, so without HPD hooked up we need to delay 200 ms. - On my board the panel is powered by the same rail as the touchscreen. By chance of probe order the touchscreen comes up first. This means by the time we check HPD in ti_sn_bridge_enable() it's already up. Thus we can use the panel on 200 ms earlier. - If I measure HPD on this pane it comes up ~56 ms after the panel is powered. This means I can save 144 ms of delay. Side effects (though not main goals) of this series are: - ti-sn65dsi86 GPIOs are now exported in Linux. - ti-sn65dsi86 bindings are converted to yaml. - Common panel bindings now have "hpd-gpios" listed. - The simple-panel driver in Linux can delay in prepare based on "hpd-gpios" - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd" if HPD isn't hooked up. Changes in v5: - Use of_xlate so that numbers in dts start at 1, not 0. - Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ 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. - Tacked on "or is otherwise unusable." to description. 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. - Remind how gpio_get_optional() works in the commit message. - useful implement => useful to implement Changes in v2: - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs") - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2 - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs") - specification => specifier. - power up => power. - Added back missing suspend-gpios. - data-lanes and lane-polarities are are the right place now. - endpoints don't need to be patternProperties. - Specified more details for data-lanes and lane-polarities. - Added old example back in, fixing bugs in it. - Example i2c bus is just called "i2c", not "i2c1" now. - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2. - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2. Douglas Anderson (6): drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux dt-bindings: display: Add hpd-gpios to panel-common bindings drm/panel-simple: Support hpd-gpios for delaying prepare() dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza .../bindings/display/bridge/ti,sn65dsi86.txt | 87 ------ .../bindings/display/bridge/ti,sn65dsi86.yaml | 293 ++++++++++++++++++ .../bindings/display/panel/panel-common.yaml | 6 + arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 214 +++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 53 ++++ 6 files changed, 568 insertions(+), 87 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml