| Message ID | 20200423162548.129661-1-dianders@chromium.org |
|---|---|
| Headers | show |
| Series | drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect | expand |
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@chromium.org> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson <dianders@chromium.org> wrote: > People use panel-simple when they have panels that are builtin to > their device. In these cases the HPD (Hot Plug Detect) signal isn't > really used for hotplugging devices but instead is used for power > sequencing. Panel timing diagrams (especially for eDP panels) usually > have the HPD signal in them and it acts as an indicator that the panel > is ready for us to talk to it. > > Sometimes the HPD signal is hooked up to a normal GPIO on a system. > In this case we need to poll it in the correct place to know that the > panel is ready for us. In some system designs the right place for > this is panel-simple. > > When adding this support, we'll account for the case that there might > be a circular dependency between panel-simple and the provider of the > GPIO. The case this was designed for was for the "ti-sn65dsi86" > bridge chip. If HPD is hooked up to one of the GPIOs provided by the > bridge chip then in our probe function we'll always get back > -EPROBE_DEFER. Let's handle this by allowing this GPIO to show up > late if we saw -EPROBE_DEFER during probe. NOTE: since the > gpio_get_optional() is used, if the "hpd-gpios" isn't there our > variable will just be NULL and we won't do anything in prepare(). > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > Reviewed-by: Stephen Boyd <swboyd@chromium.org> > --- > > Changes in v3: > - Remind how gpio_get_optional() works in the commit message. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> I have a small inkling to protest against calling this driver "panel-simple" as we tend to stockpile things like this. I suppose panel-panacea.c is a better name at this point :/ Yours, Linus Walleij
On Thu, Apr 23, 2020 at 6:26 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> Pretty cool. I wonder if this chip could use the generic regmap GPIO helpers that we are working on when they come around? https://lore.kernel.org/linux-gpio/20200423174543.17161-11-michael@walle.cc/ > +#include <linux/gpio/driver.h> > +#include <linux/gpio.h> Only <linux/gpio/driver.h> should be needed else you are doing something wrong. > + * @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. That sounds a bit hairy but I guess it's fine. > + */ > struct ti_sn_bridge { > struct device *dev; > struct regmap *regmap; > @@ -102,6 +136,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); Do you really need a bitmap for 4 bits? Can't you just have something like an u8 and check bit 0,1,2,3 ... well I suppose it has some elegance to it as well but... hm. > +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); Is there some specific reason why you don't just use gpiochip_get_data()? > + /* > + * 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) ? > + GPIOF_DIR_OUT : GPIOF_DIR_IN; > +} Don't use these legacy defines, they are for consumers. Use GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT. from <linux/gpio/driver.h> > + 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; My preferred way to do this is: #include <linux/bits.h> 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 = gchip_to_pdata(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)); Looks like a job for the generic helper library. > +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 ret; > + > + if (!test_and_clear_bit(offset, pdata->gchip_output)) > + return 0; > + > + ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG, > + 0x3 << shift, SN_GPIO_MUX_INPUT << shift); But this 0x03 does not look very generic, it's not just 1 bit but 2. Overall it looks good, just the minor things above need fixing or looking into. Yours, Linus Walleij
Hi, On Tue, Apr 28, 2020 at 5:44 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Thu, Apr 23, 2020 at 6:26 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> > > Pretty cool. > > I wonder if this chip could use the generic regmap GPIO helpers > that we are working on when they come around? > https://lore.kernel.org/linux-gpio/20200423174543.17161-11-michael@walle.cc/ An important part of my patch is the handling of power management. Specifically: * If the GPIO is an input we don't need to keep the device powered, just power it temporarily to read the pin. * If the GPIO is an output we do need to keep the device powered. I suppose that could be common for other similar devices so as long as the generic interfaces can handle this concept we can try to use it. > > +#include <linux/gpio/driver.h> > > +#include <linux/gpio.h> > > Only <linux/gpio/driver.h> should be needed else you are doing > something wrong. It's because I needed GPIOF_DIR_OUT / GPIOF_DIR_IN which was apparently wrong. See below. > > + * @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. > > That sounds a bit hairy but I guess it's fine. > > > + */ > > struct ti_sn_bridge { > > struct device *dev; > > struct regmap *regmap; > > @@ -102,6 +136,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); > > Do you really need a bitmap for 4 bits? Can't you just have something > like an u8 and check bit 0,1,2,3 ... well I suppose it has some elegance to > it as well but... hm. Doing so requires adding a lock to this driver to handle concurrent users of the different GPIOs. I can go back and do that but I'd rather not. Some prior discussion: https://lore.kernel.org/r/CAD=FV=WJONhm4ukwZa2vGtozrz_SmLuTCLxVimnGba7wRPPzgQ@mail.gmail.com ...if you want me to change this to a u8 + a mutex then please let me know, otherwise I'll assume keeping it a bitmap is fine. > > +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); > > Is there some specific reason why you don't just use > gpiochip_get_data()? I guess I'm used to interfaces that don't have a data pointer. I'll change it to gpiochip_get_data() at your suggestion, though (I think) it might be slightly less efficient (a function call and a pointer dereference compared to a subtract operation). > > + /* > > + * 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) ? > > + GPIOF_DIR_OUT : GPIOF_DIR_IN; > > +} > > Don't use these legacy defines, they are for consumers. > Use GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT. > from <linux/gpio/driver.h> That's what I get for reading the comments. I'll change this in the next version. I've also sent the following patch to help keep other people from falling into my trap: https://lore.kernel.org/r/20200428172322.1.I396f351e364f3c09df7c7606e79abefb8682c092@changeid/ > > + 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; > > My preferred way to do this is: > > #include <linux/bits.h> > > return !!(val & BIT(SN_GPIO_INPUT_SHIFT + offset)); Somehow I think of "!!" as being a bool and this function as returning something that's logically an int. It really doesn't matter a whole lot and I'm happy to change it, so I'll change it in the next version. > > +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 (!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)); > > Looks like a job for the generic helper library. I think that (for now) this comment is a no-op since the generic helper library isn't landed yet, right? ...and it wouldn't handle the power management I need? If I'm confused and I need to act on this comment, please let me know. > > +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 ret; > > + > > + if (!test_and_clear_bit(offset, pdata->gchip_output)) > > + return 0; > > + > > + ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG, > > + 0x3 << shift, SN_GPIO_MUX_INPUT << shift); > > But this 0x03 does not look very generic, it's not just 1 bit but 2. Sure, I can add #define SN_GPIO_MUX_MASK 0x3. Basically the mux is: * 0: input * 1: output * 2: special function As talked about in the patch comments, I don't define this as an official pinmux driver because that seems overkill. I'll assume it's OK to just do the #define and use it. If you want something more, let me know. > Overall it looks good, just the minor things above need fixing or > looking into. Thank you very much for the review! I'll plan to send a new patch out in the next day or two with minor comments addressed and making the assumptions I've documented above. If I got something wrong then please yell. ...or yell after I send the next version and I'll send yet another version after that! :-) -Doug
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 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 | 285 ++++++++++++++++++ .../bindings/display/panel/panel-common.yaml | 6 + arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 194 ++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 53 ++++ 6 files changed, 540 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