| Message ID | 20181018073327.64942-1-icenowy@aosc.io (mailing list archive) |
|---|---|
| Headers | show |
| Series | Analogix ANX6345 RGB-(e)DP bridge support | expand |
在 2018-10-18四的 14:18 +0200，Maxime Ripard写道： > On Thu, Oct 18, 2018 at 02:31:01PM +0300, Laurent Pinchart wrote: > > Hello, > > > > On Thursday, 18 October 2018 12:42:58 EEST Maxime Ripard wrote: > > > On Thu, Oct 18, 2018 at 11:18:06AM +0200, Daniel Vetter wrote: > > > > On Thu, Oct 18, 2018 at 10:55 AM Laurent Pinchart wrote: > > > > > On Thursday, 18 October 2018 10:33:27 EEST Icenowy Zheng > > > > > wrote: > > > > > > From: Chen-Yu Tsai <wens@csie.org> > > > > > > > > > > > > The panels shipped with Allwinner devices are very > > > > > > "generic", i.e. > > > > > > they do not have model numbers or reliable sources of > > > > > > information > > > > > > for the timings (that we know of) other than the fex files > > > > > > shipped > > > > > > on them. The dot clock frequency provided in the fex files > > > > > > have all > > > > > > been rounded to the nearest MHz, as that is the unit used > > > > > > in them. > > > > > > > > > > > > We were using the simple panel "urt,umsh-8596md-t" as a > > > > > > substitute > > > > > > for the A13 Q8 tablets in the absence of a specific model > > > > > > for what > > > > > > may be many different but otherwise timing compatible > > > > > > panels. This > > > > > > was usable without any visual artifacts or side effects, > > > > > > until the > > > > > > dot clock rate check was added in commit bb43d40d7c83 > > > > > > ("drm/sun4i: > > > > > > rgb: Validate the clock rate"). > > > > > > > > > > > > The reason this check fails is because the dotclock > > > > > > frequency for > > > > > > this model is 33.26 MHz, which is not achievable with our > > > > > > dot clock > > > > > > hardware, and the rate returned by clk_round_rate deviates > > > > > > slightly, > > > > > > causing the driver to reject the display mode. > > > > > > > > > > > > The LCD panels have some tolerance on the dot clock > > > > > > frequency, even > > > > > > if it's not specified in their datasheets. > > > > > > > > > > > > This patch adds a 5% tolerence to the dot clock check. > > > > > > > > > > Why do you think this shouldn't be merged ? > > > > > > > > It pisses of a lot of people who really insist upon accurate > > > > timing. > > > > > > It's not just about accurate timings. That 5% is a made-up limit, > > > that > > > never have really been confirmed by looking at the typical > > > tolerancies > > > of panels. > > > > > > And while being to relaxed might make some panels work that are > > > not > > > working currently, it might also break some panels that currently > > > work > > > and won't now, and ideally, we should really be able to let those > > > panels work if they can, and filter out resolutions if they > > > can't. > > > > > > > I think a better fix would be to have a dotclock range in > > > > drm_panel, > > > > and some magic to figure out which one of these we can actually > > > > do. Then tell userspace that this is the mode is should > > > > request. That way userspace knows what the actual > > > > dotclock/refresh > > > > rate is, and the panel still works. > > > > > > It's not just about panels, but also bridges with EDID where the > > > tolerancy is not exposed. > > > > Given that the tolerance is a property of the panel or bridge, I > > agree with > > Daniel that it should be implemented there, or at least in > > cooperation with > > drm_panel and drm_bridge. > > How are we supposed to deal with panels without any documentation > then? > > > Semi-related information, I think the CEA and VESA standards allow > > a 0.5% > > clock tolerance. What is the maximum clock frequency deviation > > required for > > this platform ? > > Looks like it does indeed. That's definetely good to know. Then maybe we can choose to allow 0.5% error when a bridge is attached? > > Thanks! > Maxime >
Hi Maxime, On Thursday, 18 October 2018 15:18:19 EEST Maxime Ripard wrote: > On Thu, Oct 18, 2018 at 02:31:01PM +0300, Laurent Pinchart wrote: > > On Thursday, 18 October 2018 12:42:58 EEST Maxime Ripard wrote: > >> On Thu, Oct 18, 2018 at 11:18:06AM +0200, Daniel Vetter wrote: > >>> On Thu, Oct 18, 2018 at 10:55 AM Laurent Pinchart wrote: > >>>> On Thursday, 18 October 2018 10:33:27 EEST Icenowy Zheng wrote: > >>>>> From: Chen-Yu Tsai <wens@csie.org> > >>>>> > >>>>> The panels shipped with Allwinner devices are very "generic", i.e. > >>>>> they do not have model numbers or reliable sources of information > >>>>> for the timings (that we know of) other than the fex files shipped > >>>>> on them. The dot clock frequency provided in the fex files have all > >>>>> been rounded to the nearest MHz, as that is the unit used in them. > >>>>> > >>>>> We were using the simple panel "urt,umsh-8596md-t" as a substitute > >>>>> for the A13 Q8 tablets in the absence of a specific model for what > >>>>> may be many different but otherwise timing compatible panels. This > >>>>> was usable without any visual artifacts or side effects, until the > >>>>> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i: > >>>>> rgb: Validate the clock rate"). > >>>>> > >>>>> The reason this check fails is because the dotclock frequency for > >>>>> this model is 33.26 MHz, which is not achievable with our dot clock > >>>>> hardware, and the rate returned by clk_round_rate deviates slightly, > >>>>> causing the driver to reject the display mode. > >>>>> > >>>>> The LCD panels have some tolerance on the dot clock frequency, even > >>>>> if it's not specified in their datasheets. > >>>>> > >>>>> This patch adds a 5% tolerence to the dot clock check. > >>>> > >>>> Why do you think this shouldn't be merged ? > >>> > >>> It pisses of a lot of people who really insist upon accurate timing. > >> > >> It's not just about accurate timings. That 5% is a made-up limit, that > >> never have really been confirmed by looking at the typical tolerancies > >> of panels. > >> > >> And while being to relaxed might make some panels work that are not > >> working currently, it might also break some panels that currently work > >> and won't now, and ideally, we should really be able to let those > >> panels work if they can, and filter out resolutions if they can't. > >> > >>> I think a better fix would be to have a dotclock range in drm_panel, > >>> and some magic to figure out which one of these we can actually > >>> do. Then tell userspace that this is the mode is should > >>> request. That way userspace knows what the actual dotclock/refresh > >>> rate is, and the panel still works. > >> > >> It's not just about panels, but also bridges with EDID where the > >> tolerancy is not exposed. > > > > Given that the tolerance is a property of the panel or bridge, I agree > > with Daniel that it should be implemented there, or at least in > > cooperation with drm_panel and drm_bridge. > > How are we supposed to deal with panels without any documentation then? We can only guess, but if the guess comes from the panel driver, it will at least not affect all panels and bridges, like this patch does. > > Semi-related information, I think the CEA and VESA standards allow a 0.5% > > clock tolerance. What is the maximum clock frequency deviation required > > for this platform ? > > Looks like it does indeed. That's definetely good to know.
On Thu, Oct 18, 2018 at 12:35 AM Icenowy Zheng <icenowy@aosc.io> wrote: > > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex > TERES-I. > > It reuses some definitions from the ANX78xx driver that already exists > in the kernel tree, but the driver code itself is rewritten, because the > big difference between ANX6345 and ANX78xx. > > This patchset also enables the bridge on Pinebook and TERES-I, and a > temporary workaround patch (do not merge) for the dot clock accuracy > problem of sun4i-drm. > > This patchset assumes some fixes ([1], [2] and [3]) are already > applied, without them the patchset cannot be tested on the A64 devices > mentioned above. For whole series: Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> > > [1] https://patchwork.kernel.org/patch/10628827/ > [2] https://patchwork.kernel.org/patch/10628825/ > [3] https://patchwork.kernel.org/patch/10646791/ > > Chen-Yu Tsai (1): > [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency > check > > Icenowy Zheng (8): > drm/bridge: move ANA78xx driver to analogix subdirectory > drm/bridge: split some definitions of ANX78xx to dedicated headers > drm/bridge: extract some Analogix I2C DP common code > dt-bindings: Add ANX6345 DP/eDP transmitter binding > drm/bridge: Add Analogix anx6345 support > arm64: allwinner: a64: add pinmux for RGB666 LCD > arm64: allwinner: a64: enable ANX6345 bridge on Pinebook > arm64: allwinner: a64: enable ANX6345 bridge on TERES-I > > .../bindings/display/bridge/anx6345.txt | 39 + > .../dts/allwinner/sun50i-a64-pinebook.dts | 43 + > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 + > drivers/gpu/drm/bridge/Kconfig | 10 - > drivers/gpu/drm/bridge/Makefile | 4 +- > drivers/gpu/drm/bridge/analogix-anx78xx.h | 719 --------------- > drivers/gpu/drm/bridge/analogix/Kconfig | 25 + > drivers/gpu/drm/bridge/analogix/Makefile | 4 + > .../drm/bridge/analogix/analogix-anx6345.c | 862 ++++++++++++++++++ > .../bridge/{ => analogix}/analogix-anx78xx.c | 146 +-- > .../drm/bridge/analogix/analogix-anx78xx.h | 265 ++++++ > .../drm/bridge/analogix/analogix-i2c-dptx.c | 169 ++++ > .../drm/bridge/analogix/analogix-i2c-dptx.h | 258 ++++++ > .../bridge/analogix/analogix-i2c-txcommon.h | 240 +++++ > drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +- > 16 files changed, 1956 insertions(+), 882 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt > delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c > rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (90%) > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > > -- > 2.18.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Oct 18, 2018 at 4:31 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Given that the tolerance is a property of the panel or bridge, I agree with > Daniel that it should be implemented there, or at least in cooperation with > drm_panel and drm_bridge. Clock tolerance is not specified in ANX6345 datasheet. > Semi-related information, I think the CEA and VESA standards allow a 0.5% > clock tolerance. What is the maximum clock frequency deviation required for > this platform ? This particular platform requires ~1% deviation. E.g. on Pinebook with 768p panel: requested clock: 73.0 MHz, real clock: 72.296296 MHz (0.96%) on Pinebook with 1080p panel: requested clock: 138.5 MHz, real clock: 138.461538 MHz (0.03%) So unfortunately 0.5% is not enough. Regards, Vasily
On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote: > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex > TERES-I. > So what's the status here? I'm working on the Teres-I and I find myself recreating the chunks in this patchset almost verbatim (only DT so far), one by one, so there must be something right about them ;-) Whose turn is it? Torsten
On Mon, Feb 4, 2019 at 4:22 AM Torsten Duwe <duwe@lst.de> wrote: > > On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote: > > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, > > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex > > TERES-I. > > > > So what's the status here? I'm working on the Teres-I and I find myself > recreating the chunks in this patchset almost verbatim (only DT so far), > one by one, so there must be something right about them ;-) > > Whose turn is it? I've sent v2 yesterday, however I tested it only on Pinebook. > > Torsten > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, which is used by some Allwinner A64 laptops, such as Pinebook and Olimex TERES-I. It reuses some definitions from the ANX78xx driver that already exists in the kernel tree, but the driver code itself is rewritten, because the big difference between ANX6345 and ANX78xx. This patchset also enables the bridge on Pinebook and TERES-I, and a temporary workaround patch (do not merge) for the dot clock accuracy problem of sun4i-drm. This patchset assumes some fixes ([1], [2] and [3]) are already applied, without them the patchset cannot be tested on the A64 devices mentioned above. [1] https://patchwork.kernel.org/patch/10628827/ [2] https://patchwork.kernel.org/patch/10628825/ [3] https://patchwork.kernel.org/patch/10646791/ Chen-Yu Tsai (1): [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Icenowy Zheng (8): drm/bridge: move ANA78xx driver to analogix subdirectory drm/bridge: split some definitions of ANX78xx to dedicated headers drm/bridge: extract some Analogix I2C DP common code dt-bindings: Add ANX6345 DP/eDP transmitter binding drm/bridge: Add Analogix anx6345 support arm64: allwinner: a64: add pinmux for RGB666 LCD arm64: allwinner: a64: enable ANX6345 bridge on Pinebook arm64: allwinner: a64: enable ANX6345 bridge on TERES-I .../bindings/display/bridge/anx6345.txt | 39 + .../dts/allwinner/sun50i-a64-pinebook.dts | 43 + .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 + drivers/gpu/drm/bridge/Kconfig | 10 - drivers/gpu/drm/bridge/Makefile | 4 +- drivers/gpu/drm/bridge/analogix-anx78xx.h | 719 --------------- drivers/gpu/drm/bridge/analogix/Kconfig | 25 + drivers/gpu/drm/bridge/analogix/Makefile | 4 + .../drm/bridge/analogix/analogix-anx6345.c | 862 ++++++++++++++++++ .../bridge/{ => analogix}/analogix-anx78xx.c | 146 +-- .../drm/bridge/analogix/analogix-anx78xx.h | 265 ++++++ .../drm/bridge/analogix/analogix-i2c-dptx.c | 169 ++++ .../drm/bridge/analogix/analogix-i2c-dptx.h | 258 ++++++ .../bridge/analogix/analogix-i2c-txcommon.h | 240 +++++ drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +- 16 files changed, 1956 insertions(+), 882 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (90%) create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h