mbox series

[RESEND,v2,00/12] Analogix ANX6345 RGB-(e)DP bridge support

Message ID 20190203185501.8958-1-anarsoul@gmail.com
Headers show
Series Analogix ANX6345 RGB-(e)DP bridge support | expand

Message

Vasily Khoruzhick Feb. 3, 2019, 6:54 p.m. UTC
This patchset brings 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 ANX78xx driver that already exists in the
kernel tree, but the driver code itself is rewritten due to significant
difference between ANX6345 and ANX78xx.

This patchset also enables the bridge on Pinebook and TERES-I and adds 1%
tolerance into dotclock check in sun4i driver in case if bridge is
connected

v2: - sort Kconfig and Makefile entries alphabetically
    - remove panel supply from anx6345
    - add support for panels into anx6345 driver
    - add compatible and binding for generic eDP panel
    - replace patch that adds 5% tolerance for dotclock check in sun4i
      driver for panel and bridges with patch that adds 1% tolerance
      in case if bridge is connected.

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 LCD-related hardware for Pinebook
  arm64: allwinner: a64: enable LCD-related hardware for TERES-I

Vasily Khoruzhick (4):
  drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge
    is connected
  drm/panel: simple: don't fail if we don't have panel desc
  dt-bindings: add binding for generic eDP panel
  drm/panel: simple: add generic eDP panel

 .../bindings/display/bridge/anx6345.txt       |  56 ++
 .../bindings/display/panel/panel-edp.txt      |   7 +
 .../dts/allwinner/sun50i-a64-pinebook.dts     |  74 ++
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts |  71 +-
 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    | 845 ++++++++++++++++++
 .../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/panel/panel-simple.c          |  24 +-
 drivers/gpu/drm/sun4i/sun4i_rgb.c             |  16 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h            |   1 +
 19 files changed, 2049 insertions(+), 894 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.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

Comments

Maxime Ripard Feb. 4, 2019, 2:20 p.m. UTC | #1
Hi,

On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> Validate the clock rate") prevents some panel and bridges from working with
> sun4i driver.
> 
> Unfortunately, dotclock frequency for some modes are not achievable on
> sunxi hardware, and there's a slight deviation in rate returned by
> clk_round_rate(), so they fail this check.
> 
> Experiments show that panels and bridges work fine with this slight
> deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> fine.
> 
> This patch adds a 1% tolerence to the dot clock check when bridge is
> connected.
> 
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>

I'm not sure we want to make exceptions for all the hardware
combination we face, but we should go for something more generic (and
easier to maintain instead).

IIRC, from the previous discussion, HDMI had a tolerancy requirement
in the standard. Do you know if there's such a thing for eDP? That
would solve the issue for all the eDP displays at once.

Maxime
Vasily Khoruzhick Feb. 4, 2019, 4:26 p.m. UTC | #2
On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > Validate the clock rate") prevents some panel and bridges from working with
> > sun4i driver.
> >
> > Unfortunately, dotclock frequency for some modes are not achievable on
> > sunxi hardware, and there's a slight deviation in rate returned by
> > clk_round_rate(), so they fail this check.
> >
> > Experiments show that panels and bridges work fine with this slight
> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > fine.
> >
> > This patch adds a 1% tolerence to the dot clock check when bridge is
> > connected.
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>
> I'm not sure we want to make exceptions for all the hardware
> combination we face, but we should go for something more generic (and
> easier to maintain instead).
>
> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> in the standard. Do you know if there's such a thing for eDP? That
> would solve the issue for all the eDP displays at once.

I don't have access to eDP standard - vesa.org says it's available to
members only.

> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Icenowy Zheng Feb. 4, 2019, 4:28 p.m. UTC | #3
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick <anarsoul@gmail.com> 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
><maxime.ripard@bootlin.com> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the clock rate") prevents some panel and bridges from
>working with
>> > sun4i driver.
>> >
>> > Unfortunately, dotclock frequency for some modes are not achievable
>on
>> > sunxi hardware, and there's a slight deviation in rate returned by
>> > clk_round_rate(), so they fail this check.
>> >
>> > Experiments show that panels and bridges work fine with this slight
>> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP
>panel
>> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and
>works just
>> > fine.
>> >
>> > This patch adds a 1% tolerence to the dot clock check when bridge
>is
>> > connected.
>> >
>> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>
>> I'm not sure we want to make exceptions for all the hardware
>> combination we face, but we should go for something more generic (and
>> easier to maintain instead).
>>
>> IIRC, from the previous discussion, HDMI had a tolerancy requirement
>> in the standard. Do you know if there's such a thing for eDP? That
>> would solve the issue for all the eDP displays at once.
>
>I don't have access to eDP standard - vesa.org says it's available to
>members only.

Try out to grab an old version?

I remember 1.0 is open.

>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Vasily Khoruzhick Feb. 4, 2019, 6:50 p.m. UTC | #4
On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> >> in the standard. Do you know if there's such a thing for eDP? That
> >> would solve the issue for all the eDP displays at once.
> >
> >I don't have access to eDP standard - vesa.org says it's available to
> >members only.
>
> Try out to grab an old version?
>
> I remember 1.0 is open.

I can't find anything regarding dot clock tolerance in DisplayPort
specification.
Maxime Ripard Feb. 5, 2019, 3:41 p.m. UTC | #5
On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > >> in the standard. Do you know if there's such a thing for eDP? That
> > >> would solve the issue for all the eDP displays at once.
> > >
> > >I don't have access to eDP standard - vesa.org says it's available to
> > >members only.
> >
> > Try out to grab an old version?
> >
> > I remember 1.0 is open.
> 
> I can't find anything regarding dot clock tolerance in DisplayPort
> specification.

I guess since the DP is a VESA spec, it's probably .5%, just like on
the EDID (well, CVT).

Maxime
Vasily Khoruzhick Feb. 5, 2019, 5:49 p.m. UTC | #6
On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > >> would solve the issue for all the eDP displays at once.
> > > >
> > > >I don't have access to eDP standard - vesa.org says it's available to
> > > >members only.
> > >
> > > Try out to grab an old version?
> > >
> > > I remember 1.0 is open.
> >
> > I can't find anything regarding dot clock tolerance in DisplayPort
> > specification.
>
> I guess since the DP is a VESA spec, it's probably .5%, just like on
> the EDID (well, CVT).

Unfortunately that's not enough for Pinebook. It needs 1% for 768p panel.

>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Maxime Ripard Feb. 6, 2019, 9:16 a.m. UTC | #7
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > > >> would solve the issue for all the eDP displays at once.
> > > > >
> > > > >I don't have access to eDP standard - vesa.org says it's available to
> > > > >members only.
> > > >
> > > > Try out to grab an old version?
> > > >
> > > > I remember 1.0 is open.
> > >
> > > I can't find anything regarding dot clock tolerance in DisplayPort
> > > specification.
> >
> > I guess since the DP is a VESA spec, it's probably .5%, just like on
> > the EDID (well, CVT).
> 
> Unfortunately that's not enough for Pinebook. It needs 1% for 768p
> panel.

And that mode is stored in the EDID as a standard (or established)
timing, or a detailed timing?

If the latter, then it should also provide the tolerancies as part of
the panel timing description.

If the former, then what would be the advertised pixel clock and the
one we can compute? Maybe we have a bug somewhere.

Maxime
Thierry Reding Feb. 6, 2019, 11:42 a.m. UTC | #8
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote:
> On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > > > >> would solve the issue for all the eDP displays at once.
> > > > > >
> > > > > >I don't have access to eDP standard - vesa.org says it's available to
> > > > > >members only.
> > > > >
> > > > > Try out to grab an old version?
> > > > >
> > > > > I remember 1.0 is open.
> > > >
> > > > I can't find anything regarding dot clock tolerance in DisplayPort
> > > > specification.
> > >
> > > I guess since the DP is a VESA spec, it's probably .5%, just like on
> > > the EDID (well, CVT).
> > 
> > Unfortunately that's not enough for Pinebook. It needs 1% for 768p
> > panel.
> 
> And that mode is stored in the EDID as a standard (or established)
> timing, or a detailed timing?
> 
> If the latter, then it should also provide the tolerancies as part of
> the panel timing description.

The simple-panel driver can, in addition to a struct drm_display_mode
take a struct display_timings to specify the modes. These allow to
define <minimum, typical, maximum> triplets for each parameter, which
are usually found in panel datasheets.

Of course that's not going to help you much if all you have is EDID and
if that doesn't provide tolerances.

Thierry

> If the former, then what would be the advertised pixel clock and the
> one we can compute? Maybe we have a bug somewhere.
> 
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com