ANX6345 LVTTL->eDP video bridge, driver with device tree bindings.
Changes from v2:
* use SPDX-IDs throughout
* removed the panel output again, as it was not what Maxime had in mind.
At least the Teres-I does very well without. No connector spec, no "quirks"[1],
just plain EDID at work.
* binding clarifications and cosmetic changes as suggested by Andrzej
Changes from v1:
* fixed up copyright information. Most code changes are only moves and thus
retain copyright and module ownership. Even the new analogix-anx6345.c originates
from the old 1495-line analogix-anx78xx.c, with 306 insertions and 987 deletions
(ignoring the trivial anx78xx -> anx6345 replacements) 306 new vs. 508 old...
* fixed all minor formatting issues brought up
* merged previously separate new analogix_dp_i2c module into existing analogix_dp
* split additional defines into a preparatory patch
* renamed the factored-out common functions anx_aux_* -> anx_dp_aux_*, because
anx_...aux_transfer was exported globally. Besides, it is now GPL-only exported.
* moved chip ID read into a separate function.
* keep the chip powered after a successful probe.
(There's a good chance that this is the only display during boot!)
* updated the binding document: LVTTL input is now required, only the output side
description is optional.
Laurent: I have also looked into the drm_panel_bridge infrastructure,
but it's not that trivial to convert these drivers to it.
Changes from the respective previous versions:
* the reset polarity is corrected in DT and the driver;
things should be clearer now.
* as requested, add a panel (the known innolux,n116bge) and connect
the ports.
* renamed dvdd?? to *-supply to match the established scheme
* trivial update to the #include list, to make it compile in 5.2
--------------
[1] I hesitate to associate information about a connected panel with that term.
But should it be neccessary for maximum power saving (e.g. pinebooks),
it would be good to have something here, regardless of nomenclature.
Torsten
On Mon, Jul 22, 2019 at 8:04 AM Torsten Duwe <[email protected]> wrote:
>
> ANX6345 LVTTL->eDP video bridge, driver with device tree bindings.
>
> Changes from v2:
>
> * use SPDX-IDs throughout
>
> * removed the panel output again, as it was not what Maxime had in mind.
> At least the Teres-I does very well without. No connector spec, no "quirks"[1],
> just plain EDID at work.
You still need a panel to put backlight in there. Otherwise backlight
will stay on when display is turned off.
>
> * binding clarifications and cosmetic changes as suggested by Andrzej
>
> Changes from v1:
>
> * fixed up copyright information. Most code changes are only moves and thus
> retain copyright and module ownership. Even the new analogix-anx6345.c originates
> from the old 1495-line analogix-anx78xx.c, with 306 insertions and 987 deletions
> (ignoring the trivial anx78xx -> anx6345 replacements) 306 new vs. 508 old...
>
> * fixed all minor formatting issues brought up
>
> * merged previously separate new analogix_dp_i2c module into existing analogix_dp
>
> * split additional defines into a preparatory patch
>
> * renamed the factored-out common functions anx_aux_* -> anx_dp_aux_*, because
> anx_...aux_transfer was exported globally. Besides, it is now GPL-only exported.
>
> * moved chip ID read into a separate function.
>
> * keep the chip powered after a successful probe.
> (There's a good chance that this is the only display during boot!)
>
> * updated the binding document: LVTTL input is now required, only the output side
> description is optional.
>
> Laurent: I have also looked into the drm_panel_bridge infrastructure,
> but it's not that trivial to convert these drivers to it.
>
> Changes from the respective previous versions:
>
> * the reset polarity is corrected in DT and the driver;
> things should be clearer now.
>
> * as requested, add a panel (the known innolux,n116bge) and connect
> the ports.
>
> * renamed dvdd?? to *-supply to match the established scheme
>
> * trivial update to the #include list, to make it compile in 5.2
>
> --------------
> [1] I hesitate to associate information about a connected panel with that term.
> But should it be neccessary for maximum power saving (e.g. pinebooks),
> it would be good to have something here, regardless of nomenclature.
>
> Torsten