Message ID | 20190604122150.29D6468B05@newverein.lst.de |
---|---|
Headers | show |
Series | Add anx6345 DP/eDP bridge for Olimex Teres-I | expand |
On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote: > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and > the I2C controlling signals are connected to I2C0 bus. eDP output goes > to an Innolux N116BGE panel. > > Enable it in the device tree. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Torsten Duwe <duwe@suse.de> > --- > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++-- > 1 file changed, 61 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > index 0ec46b969a75..a0ad438b037f 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > @@ -65,6 +65,21 @@ > }; > }; > > + panel: panel { > + compatible ="innolux,n116bge", "simple-panel"; It's still "simple-panel". I believe I already mentioned that Rob asked it to be edp-connector. > + status = "okay"; > + power-supply = <®_dcdc1>; > + backlight = <&backlight>; > + > + ports { > + panel_in: port { > + panel_in_edp: endpoint { > + remote-endpoint = <&anx6345_out>; > + }; > + }; > + }; > + }; > + > reg_usb1_vbus: usb1-vbus { > compatible = "regulator-fixed"; > regulator-name = "usb1-vbus"; > @@ -81,20 +96,48 @@ > }; > }; > > +&de { > + status = "okay"; > +}; > + > &ehci1 { > status = "okay"; > }; > > > -/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline) > - * driver for this chip at the moment, the bootloader initializes it. > - * However it can be accessed with the i2c-dev driver from user space. > - */ > &i2c0 { > clock-frequency = <100000>; > pinctrl-names = "default"; > pinctrl-0 = <&i2c0_pins>; > status = "okay"; > + > + anx6345: anx6345@38 { > + compatible = "analogix,anx6345"; > + reg = <0x38>; > + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */ > + dvdd25-supply = <®_dldo2>; > + dvdd12-supply = <®_dldo3>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + anx6345_in: endpoint { > + remote-endpoint = <&tcon0_out_anx6345>; > + }; > + }; > + port@1 { > + anx6345_out: endpoint { > + remote-endpoint = <&panel_in_edp>; > + }; > + }; > + }; > + }; > +}; > + > +&mixer0 { > + status = "okay"; > }; > > &mmc0 { > @@ -279,6 +322,20 @@ > vcc-hdmi-supply = <®_dldo1>; > }; > > +&tcon0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&lcd_rgb666_pins>; > + > + status = "okay"; > +}; > + > +&tcon0_out { > + tcon0_out_anx6345: endpoint@0 { > + reg = <0>; > + remote-endpoint = <&anx6345_in>; > + }; > +}; > + > &uart0 { > pinctrl-names = "default"; > pinctrl-0 = <&uart0_pb_pins>; > -- > 2.16.4 >
On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote: > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote: > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and > > the I2C controlling signals are connected to I2C0 bus. eDP output goes > > to an Innolux N116BGE panel. > > > > Enable it in the device tree. > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > > Signed-off-by: Torsten Duwe <duwe@suse.de> > > --- > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++-- > > 1 file changed, 61 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > index 0ec46b969a75..a0ad438b037f 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > @@ -65,6 +65,21 @@ > > }; > > }; > > > > + panel: panel { > > + compatible ="innolux,n116bge", "simple-panel"; > > It's still "simple-panel". I believe I already mentioned that Rob > asked it to be edp-connector. > For which there are neither bindings nor drivers. Is anybody seriously proposing to hold back support for existing (open source!) hardware in favour of an *imaginable* *possibly* better solution? Especially when this exact line is already used in some other places? (there's a space missing btw...) I'm more than glad to follow any constructive improvements towards better modularity. However there were none so far, and on top of that, it's a laptop. I see little advantage in mentioning an internal connector when the panel connected is always the same. FWIW, Rob should also have received these patches. Torsten
On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote: > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote: > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote: > > > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes > > > to an Innolux N116BGE panel. > > > > > > Enable it in the device tree. > > > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > > > Signed-off-by: Torsten Duwe <duwe@suse.de> > > > --- > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++-- > > > 1 file changed, 61 insertions(+), 4 deletions(-) > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > index 0ec46b969a75..a0ad438b037f 100644 > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > @@ -65,6 +65,21 @@ > > > }; > > > }; > > > > > > + panel: panel { > > > + compatible ="innolux,n116bge", "simple-panel"; > > > > It's still "simple-panel". I believe I already mentioned that Rob > > asked it to be edp-connector. > > For which there are neither bindings nor drivers. > > Is anybody seriously proposing to hold back support for existing > (open source!) hardware in favour of an *imaginable* *possibly* > better solution? Especially when this exact line is already used in > some other places? (there's a space missing btw...) It's non-existent and imaginable only because you've been ignoring everyone that said that you should do it. So it's self-inflicted, really. And the DT is considered an ABI, so yeah, we will witheld everything that doesn't fit what we would like. Your point of view is that it's more work and for no particular benefit, ours is that it's a short-term pain for a long-term gain, and the benefits will be in the maintainance cost. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Guys, this discussion is getting heated for no reason. Let's put personal frustrations aside and discuss the issue on its merits: Maxime Ripard writes: > On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote: > > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote: > > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote: > > > > > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and > > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes > > > > to an Innolux N116BGE panel. > > > > > > > > Enable it in the device tree. > > > > > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > > > > Signed-off-by: Torsten Duwe <duwe@suse.de> > > > > --- > > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++-- > > > > 1 file changed, 61 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > > index 0ec46b969a75..a0ad438b037f 100644 > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > > @@ -65,6 +65,21 @@ > > > > }; > > > > }; > > > > > > > > + panel: panel { > > > > + compatible ="innolux,n116bge", "simple-panel"; > > > > > > It's still "simple-panel". I believe I already mentioned that Rob > > > asked it to be edp-connector. Actually just dropping the "simple-panel" compatible would be a poor choice. Even if "edp-connector" is specified as binding and implemented in a driver, there are older kernel versions and other operating systems to keep in mind. If the HW works with "simple-panel" driver satisfactorily, we should definitely keep the compatible as a fall back for cases where the edp-connector driver is unavailable. If think valid compatible properties would be: compatible = "innolux,n116bge", "simple-panel"; compatible = "edp-connector", "simple-panel"; compatible = "innolux,n116bge", "edp-connector", "simple-panel"; compatible = "edp-connector", "innolux,n116bge", "simple-panel"; I can't make up my mind which one I prefere. However neither of these variants requires actually implmenting an edp-connector driver. And each of these variants is clearly preferable to shipping DTs without description of the panel at all and complies with bindings after adding a stub for "edp-connector". > And the DT is considered an ABI, so yeah, we will witheld everything > that doesn't fit what we would like. I fail to see how the patch in discussion adds new ABI. While I understand the need to pester contributors for more work, outright blocking DTs, that properly describe the HW and comply with existing bindings, seems a bit unreasonable. (Assuming there are no other issues of course.) Also note that the innolux,n116bge binding suggestes using simple-panel as fallback. HTH, Harald
On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote: > Guys, this discussion is getting heated for no reason. Let's put > personal frustrations aside and discuss the issue on its merits: > > Maxime Ripard writes: > > On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote: > > > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote: > > > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote: > > > > > > > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and > > > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes > > > > > to an Innolux N116BGE panel. > > > > > > > > > > Enable it in the device tree. > > > > > > > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > > > > > Signed-off-by: Torsten Duwe <duwe@suse.de> > > > > > --- > > > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++-- > > > > > 1 file changed, 61 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > > > index 0ec46b969a75..a0ad438b037f 100644 > > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts > > > > > @@ -65,6 +65,21 @@ > > > > > }; > > > > > }; > > > > > > > > > > + panel: panel { > > > > > + compatible ="innolux,n116bge", "simple-panel"; > > > > > > > > It's still "simple-panel". I believe I already mentioned that Rob > > > > asked it to be edp-connector. > > Actually just dropping the "simple-panel" compatible would be a poor > choice. Even if "edp-connector" is specified as binding and implemented in a > driver, there are older kernel versions and other operating systems to > keep in mind. Which older kernels? This is a new binding, adding a new driver, so if an older kernel uses a separate driver with its own binding, good for them, but we don't have to support it. > If the HW works with "simple-panel" driver satisfactorily, > we should definitely keep the compatible as a fall back for cases where > the edp-connector driver is unavailable. > > If think valid compatible properties would be: > compatible = "innolux,n116bge", "simple-panel"; > compatible = "edp-connector", "simple-panel"; A connector isn't a panel. > compatible = "innolux,n116bge", "edp-connector", "simple-panel"; And the innolux,n116bge is certainly not a connector either. > compatible = "edp-connector", "innolux,n116bge", "simple-panel"; > > I can't make up my mind which one I prefere. However neither of these > variants requires actually implmenting an edp-connector driver. No-one asked to do an edp-connector driver. You should use it in your DT, but if you want to have some code in your driver that parses the DT directly, I'm totally fine with that. > And each of these variants is clearly preferable to shipping DTs > without description of the panel at all and complies with bindings > after adding a stub for "edp-connector". I guess you should describe why do you think it's "clear", because I'm not sure this is obvious for everyone here. eDP allows to discover which device is on the other side and its supported timings, just like HDMI for example (or regular DP, for that matter). Would you think it's clearly preferable to ship a DT with the DP/HDMI monitor connected on the other side exposed as a panel as well? > > And the DT is considered an ABI, so yeah, we will witheld everything > > that doesn't fit what we would like. > > I fail to see how the patch in discussion adds new ABI. The binding itself is the ABI, and we will have to support that binding for pretty much forever. > While I understand the need to pester contributors for more work, > outright blocking DTs, that properly describe the HW Properly is arguable. > and comply with existing bindings And that's bindings meant for another use-case. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote: > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote: > > > > If think valid compatible properties would be: > > compatible = "innolux,n116bge", "simple-panel"; > > compatible = "edp-connector", "simple-panel"; > > A connector isn't a panel. > > > compatible = "innolux,n116bge", "edp-connector", "simple-panel"; > > And the innolux,n116bge is certainly not a connector either. > > > compatible = "edp-connector", "innolux,n116bge", "simple-panel"; > > > > I can't make up my mind which one I prefere. However neither of these > > variants requires actually implmenting an edp-connector driver. > > No-one asked to do an edp-connector driver. You should use it in your > DT, but if you want to have some code in your driver that parses the > DT directly, I'm totally fine with that. I must admit I fail to understand what that extra node would be good for. Logically, the eDP far side is connected to the well-known n116bge. Inside the laptop case it might as well be a flat ribbon cable or soldered directly. In good intention, that's all I wanted to express in the DT. I don't know whether the relevant mechanical dimensions of the panel and the connector are standardised, so whether one could in theory assemble it with a different panel than the one it came with. OTOH, as I checked during the discussion with anarsoul, the panel's supply voltage is permanently connected to the main 3.3V rail. We already agreed that the eDP output port must not neccessarily be specified, this setup is a good example why: because the panel is always powered, the anx6345 can always pull valid EDID data from it so at this stage there's no need for any OS driver to reach beyond the bridge. IIRC even the backlight got switched off for the blank screen without. All I wanted to say is that "there's usually an n116bge behind it"; but this is mostly redundant. So, shall we just drop the output port specification (along with the panel node) in order to get one step further? > I guess you should describe why do you think it's "clear", because I'm > not sure this is obvious for everyone here. eDP allows to discover > which device is on the other side and its supported timings, just like > HDMI for example (or regular DP, for that matter). Would you think > it's clearly preferable to ship a DT with the DP/HDMI monitor > connected on the other side exposed as a panel as well? Well, as I wrote: "in good intention". That's the panel that comes with the kit but it is very well detected automatically, just like you describe. So, just leave it out? Torsten
On 04.06.2019 14:22, Torsten Duwe wrote: > From: Icenowy Zheng <icenowy@aosc.io> > > Some definitions currently in analogix-anx78xx.h are not restricted to > the ANX78xx series, but also applicable to other DisplayPort > transmitters by Analogix. > > Split out them to dedicated headers, and make analogix-anx78xx.h include > them. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > Signed-off-by: Torsten Duwe <duwe@suse.de> > --- > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 465 +-------------------- > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 256 ++++++++++++ > .../drm/bridge/analogix/analogix-i2c-txcommon.h | 242 +++++++++++ > 3 files changed, 503 insertions(+), 460 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h > index 38753c870137..3fbe2c3244fd 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h > @@ -11,13 +11,15 @@ > * GNU General Public License for more details. > * > */ > - > #ifndef __ANX78xx_H > #define __ANX78xx_H > > -#define TX_P0 0x70 > +#include "analogix-i2c-dptx.h" > +#include "analogix-i2c-txcommon.h" > + > +#define TX_P0 ANALOGIX_I2C_DPTX > #define TX_P1 0x7a > -#define TX_P2 0x72 > +#define TX_P2 ANALOGIX_I2C_TXCOMMON > > #define RX_P0 0x7e > #define RX_P1 0x80 > @@ -225,463 +227,6 @@ > #define SP_CLEAR_AVMUTE BIT(4) > #define SP_SET_AVMUTE BIT(0) > > -/***************************************************************/ > -/* Register definition of device address 0x70 */ > -/***************************************************************/ > - > -/* HDCP Status Register */ > -#define SP_TX_HDCP_STATUS_REG 0x00 > -#define SP_AUTH_FAIL BIT(5) > -#define SP_AUTHEN_PASS BIT(1) > - > -/* HDCP Control Register 0 */ > -#define SP_HDCP_CTRL0_REG 0x01 > -#define SP_RX_REPEATER BIT(6) > -#define SP_RE_AUTH BIT(5) > -#define SP_SW_AUTH_OK BIT(4) > -#define SP_HARD_AUTH_EN BIT(3) > -#define SP_HDCP_ENC_EN BIT(2) > -#define SP_BKSV_SRM_PASS BIT(1) > -#define SP_KSVLIST_VLD BIT(0) > -/* HDCP Function Enabled */ > -#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3)) > - > -/* HDCP Receiver BSTATUS Register 0 */ > -#define SP_HDCP_RX_BSTATUS0_REG 0x1b > -/* HDCP Receiver BSTATUS Register 1 */ > -#define SP_HDCP_RX_BSTATUS1_REG 0x1c > - > -/* HDCP Embedded "Blue Screen" Content Registers */ > -#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c > -#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d > -#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e > - > -/* HDCP Wait R0 Timing Register */ > -#define SP_HDCP_WAIT_R0_TIME_REG 0x40 > - > -/* HDCP Link Integrity Check Timer Register */ > -#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41 > - > -/* HDCP Repeater Ready Wait Timer Register */ > -#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42 > - > -/* HDCP Auto Timer Register */ > -#define SP_HDCP_AUTO_TIMER_REG 0x51 > - > -/* HDCP Key Status Register */ > -#define SP_HDCP_KEY_STATUS_REG 0x5e > - > -/* HDCP Key Command Register */ > -#define SP_HDCP_KEY_COMMAND_REG 0x5f > -#define SP_DISABLE_SYNC_HDCP BIT(2) > - > -/* OTP Memory Key Protection Registers */ > -#define SP_OTP_KEY_PROTECT1_REG 0x60 > -#define SP_OTP_KEY_PROTECT2_REG 0x61 > -#define SP_OTP_KEY_PROTECT3_REG 0x62 > -#define SP_OTP_PSW1 0xa2 > -#define SP_OTP_PSW2 0x7e > -#define SP_OTP_PSW3 0xc6 > - > -/* DP System Control Registers */ > -#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1) > -/* Bits for DP System Control Register 2 */ > -#define SP_CHA_STA BIT(2) > -/* Bits for DP System Control Register 3 */ > -#define SP_HPD_STATUS BIT(6) > -#define SP_STRM_VALID BIT(2) > -/* Bits for DP System Control Register 4 */ > -#define SP_ENHANCED_MODE BIT(3) > - > -/* DP Video Control Register */ > -#define SP_DP_VIDEO_CTRL_REG 0x84 > -#define SP_COLOR_F_MASK 0x06 > -#define SP_COLOR_F_SHIFT 1 > -#define SP_BPC_MASK 0xe0 > -#define SP_BPC_SHIFT 5 > -# define SP_BPC_6BITS 0x00 > -# define SP_BPC_8BITS 0x01 > -# define SP_BPC_10BITS 0x02 > -# define SP_BPC_12BITS 0x03 > - > -/* DP Audio Control Register */ > -#define SP_DP_AUDIO_CTRL_REG 0x87 > -#define SP_AUD_EN BIT(0) > - > -/* 10us Pulse Generate Timer Registers */ > -#define SP_I2C_GEN_10US_TIMER0_REG 0x88 > -#define SP_I2C_GEN_10US_TIMER1_REG 0x89 > - > -/* Packet Send Control Register */ > -#define SP_PACKET_SEND_CTRL_REG 0x90 > -#define SP_AUD_IF_UP BIT(7) > -#define SP_AVI_IF_UD BIT(6) > -#define SP_MPEG_IF_UD BIT(5) > -#define SP_SPD_IF_UD BIT(4) > -#define SP_AUD_IF_EN BIT(3) > -#define SP_AVI_IF_EN BIT(2) > -#define SP_MPEG_IF_EN BIT(1) > -#define SP_SPD_IF_EN BIT(0) > - > -/* DP HDCP Control Register */ > -#define SP_DP_HDCP_CTRL_REG 0x92 > -#define SP_AUTO_EN BIT(7) > -#define SP_AUTO_START BIT(5) > -#define SP_LINK_POLLING BIT(1) > - > -/* DP Main Link Bandwidth Setting Register */ > -#define SP_DP_MAIN_LINK_BW_SET_REG 0xa0 > -#define SP_LINK_BW_SET_MASK 0x1f > -#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5) > - > -/* DP Training Pattern Set Register */ > -#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2 > - > -/* DP Lane 0 Link Training Control Register */ > -#define SP_DP_LANE0_LT_CTRL_REG 0xa3 > -#define SP_TX_SW_SET_MASK 0x1b > -#define SP_MAX_PRE_REACH BIT(5) > -#define SP_MAX_DRIVE_REACH BIT(4) > -#define SP_PRE_EMP_LEVEL1 BIT(3) > -#define SP_DRVIE_CURRENT_LEVEL1 BIT(0) > - > -/* DP Link Training Control Register */ > -#define SP_DP_LT_CTRL_REG 0xa8 > -#define SP_LT_ERROR_TYPE_MASK 0x70 > -# define SP_LT_NO_ERROR 0x00 > -# define SP_LT_AUX_WRITE_ERROR 0x01 > -# define SP_LT_MAX_DRIVE_REACHED 0x02 > -# define SP_LT_WRONG_LANE_COUNT_SET 0x03 > -# define SP_LT_LOOP_SAME_5_TIME 0x04 > -# define SP_LT_CR_FAIL_IN_EQ 0x05 > -# define SP_LT_EQ_LOOP_5_TIME 0x06 > -#define SP_LT_EN BIT(0) > - > -/* DP CEP Training Control Registers */ > -#define SP_DP_CEP_TRAINING_CTRL0_REG 0xa9 > -#define SP_DP_CEP_TRAINING_CTRL1_REG 0xaa > - > -/* DP Debug Register 1 */ > -#define SP_DP_DEBUG1_REG 0xb0 > -#define SP_DEBUG_PLL_LOCK BIT(4) > -#define SP_POLLING_EN BIT(1) > - > -/* DP Polling Control Register */ > -#define SP_DP_POLLING_CTRL_REG 0xb4 > -#define SP_AUTO_POLLING_DISABLE BIT(0) > - > -/* DP Link Debug Control Register */ > -#define SP_DP_LINK_DEBUG_CTRL_REG 0xb8 > -#define SP_M_VID_DEBUG BIT(5) > -#define SP_NEW_PRBS7 BIT(4) > -#define SP_INSERT_ER BIT(1) > -#define SP_PRBS31_EN BIT(0) > - > -/* AUX Misc control Register */ > -#define SP_AUX_MISC_CTRL_REG 0xbf > - > -/* DP PLL control Register */ > -#define SP_DP_PLL_CTRL_REG 0xc7 > -#define SP_PLL_RST BIT(6) > - > -/* DP Analog Power Down Register */ > -#define SP_DP_ANALOG_POWER_DOWN_REG 0xc8 > -#define SP_CH0_PD BIT(0) > - > -/* DP Misc Control Register */ > -#define SP_DP_MISC_CTRL_REG 0xcd > -#define SP_EQ_TRAINING_LOOP BIT(6) > - > -/* DP Extra I2C Device Address Register */ > -#define SP_DP_EXTRA_I2C_DEV_ADDR_REG 0xce > -#define SP_I2C_STRETCH_DISABLE BIT(7) > - > -#define SP_I2C_EXTRA_ADDR 0x50 > - > -/* DP Downspread Control Register 1 */ > -#define SP_DP_DOWNSPREAD_CTRL1_REG 0xd0 > - > -/* DP M Value Calculation Control Register */ > -#define SP_DP_M_CALCULATION_CTRL_REG 0xd9 > -#define SP_M_GEN_CLK_SEL BIT(0) > - > -/* AUX Channel Access Status Register */ > -#define SP_AUX_CH_STATUS_REG 0xe0 > -#define SP_AUX_STATUS 0x0f > - > -/* AUX Channel DEFER Control Register */ > -#define SP_AUX_DEFER_CTRL_REG 0xe2 > -#define SP_DEFER_CTRL_EN BIT(7) > - > -/* DP Buffer Data Count Register */ > -#define SP_BUF_DATA_COUNT_REG 0xe4 > -#define SP_BUF_DATA_COUNT_MASK 0x1f > -#define SP_BUF_CLR BIT(7) > - > -/* DP AUX Channel Control Register 1 */ > -#define SP_DP_AUX_CH_CTRL1_REG 0xe5 > -#define SP_AUX_TX_COMM_MASK 0x0f > -#define SP_AUX_LENGTH_MASK 0xf0 > -#define SP_AUX_LENGTH_SHIFT 4 > - > -/* DP AUX CH Address Register 0 */ > -#define SP_AUX_ADDR_7_0_REG 0xe6 > - > -/* DP AUX CH Address Register 1 */ > -#define SP_AUX_ADDR_15_8_REG 0xe7 > - > -/* DP AUX CH Address Register 2 */ > -#define SP_AUX_ADDR_19_16_REG 0xe8 > -#define SP_AUX_ADDR_19_16_MASK 0x0f > - > -/* DP AUX Channel Control Register 2 */ > -#define SP_DP_AUX_CH_CTRL2_REG 0xe9 > -#define SP_AUX_SEL_RXCM BIT(6) > -#define SP_AUX_CHSEL BIT(3) > -#define SP_AUX_PN_INV BIT(2) > -#define SP_ADDR_ONLY BIT(1) > -#define SP_AUX_EN BIT(0) > - > -/* DP Video Stream Control InfoFrame Register */ > -#define SP_DP_3D_VSC_CTRL_REG 0xea > -#define SP_INFO_FRAME_VSC_EN BIT(0) > - > -/* DP Video Stream Data Byte 1 Register */ > -#define SP_DP_VSC_DB1_REG 0xeb > - > -/* DP AUX Channel Control Register 3 */ > -#define SP_DP_AUX_CH_CTRL3_REG 0xec > -#define SP_WAIT_COUNTER_7_0_MASK 0xff > - > -/* DP AUX Channel Control Register 4 */ > -#define SP_DP_AUX_CH_CTRL4_REG 0xed > - > -/* DP AUX Buffer Data Registers */ > -#define SP_DP_BUF_DATA0_REG 0xf0 > - > -/***************************************************************/ > -/* Register definition of device address 0x72 */ > -/***************************************************************/ > - > -/* > - * Core Register Definitions > - */ > - > -/* Device ID Low Byte Register */ > -#define SP_DEVICE_IDL_REG 0x02 > - > -/* Device ID High Byte Register */ > -#define SP_DEVICE_IDH_REG 0x03 > - > -/* Device version register */ > -#define SP_DEVICE_VERSION_REG 0x04 > - > -/* Power Down Control Register */ > -#define SP_POWERDOWN_CTRL_REG 0x05 > -#define SP_REGISTER_PD BIT(7) > -#define SP_HDCP_PD BIT(5) > -#define SP_AUDIO_PD BIT(4) > -#define SP_VIDEO_PD BIT(3) > -#define SP_LINK_PD BIT(2) > -#define SP_TOTAL_PD BIT(1) > - > -/* Reset Control Register 1 */ > -#define SP_RESET_CTRL1_REG 0x06 > -#define SP_MISC_RST BIT(7) > -#define SP_VIDCAP_RST BIT(6) > -#define SP_VIDFIF_RST BIT(5) > -#define SP_AUDFIF_RST BIT(4) > -#define SP_AUDCAP_RST BIT(3) > -#define SP_HDCP_RST BIT(2) > -#define SP_SW_RST BIT(1) > -#define SP_HW_RST BIT(0) > - > -/* Reset Control Register 2 */ > -#define SP_RESET_CTRL2_REG 0x07 > -#define SP_AUX_RST BIT(2) > -#define SP_SERDES_FIFO_RST BIT(1) > -#define SP_I2C_REG_RST BIT(0) > - > -/* Video Control Register 1 */ > -#define SP_VID_CTRL1_REG 0x08 > -#define SP_VIDEO_EN BIT(7) > -#define SP_VIDEO_MUTE BIT(2) > -#define SP_DE_GEN BIT(1) > -#define SP_DEMUX BIT(0) > - > -/* Video Control Register 2 */ > -#define SP_VID_CTRL2_REG 0x09 > -#define SP_IN_COLOR_F_MASK 0x03 > -#define SP_IN_YC_BIT_SEL BIT(2) > -#define SP_IN_BPC_MASK 0x70 > -#define SP_IN_BPC_SHIFT 4 > -# define SP_IN_BPC_12BIT 0x03 > -# define SP_IN_BPC_10BIT 0x02 > -# define SP_IN_BPC_8BIT 0x01 > -# define SP_IN_BPC_6BIT 0x00 > -#define SP_IN_D_RANGE BIT(7) > - > -/* Video Control Register 3 */ > -#define SP_VID_CTRL3_REG 0x0a > -#define SP_HPD_OUT BIT(6) > - > -/* Video Control Register 5 */ > -#define SP_VID_CTRL5_REG 0x0c > -#define SP_CSC_STD_SEL BIT(7) > -#define SP_XVYCC_RNG_LMT BIT(6) > -#define SP_RANGE_Y2R BIT(5) > -#define SP_CSPACE_Y2R BIT(4) > -#define SP_RGB_RNG_LMT BIT(3) > -#define SP_Y_RNG_LMT BIT(2) > -#define SP_RANGE_R2Y BIT(1) > -#define SP_CSPACE_R2Y BIT(0) > - > -/* Video Control Register 6 */ > -#define SP_VID_CTRL6_REG 0x0d > -#define SP_TEST_PATTERN_EN BIT(7) > -#define SP_VIDEO_PROCESS_EN BIT(6) > -#define SP_VID_US_MODE BIT(3) > -#define SP_VID_DS_MODE BIT(2) > -#define SP_UP_SAMPLE BIT(1) > -#define SP_DOWN_SAMPLE BIT(0) > - > -/* Video Control Register 8 */ > -#define SP_VID_CTRL8_REG 0x0f > -#define SP_VID_VRES_TH BIT(0) > - > -/* Total Line Status Low Byte Register */ > -#define SP_TOTAL_LINE_STAL_REG 0x24 > - > -/* Total Line Status High Byte Register */ > -#define SP_TOTAL_LINE_STAH_REG 0x25 > - > -/* Active Line Status Low Byte Register */ > -#define SP_ACT_LINE_STAL_REG 0x26 > - > -/* Active Line Status High Byte Register */ > -#define SP_ACT_LINE_STAH_REG 0x27 > - > -/* Vertical Front Porch Status Register */ > -#define SP_V_F_PORCH_STA_REG 0x28 > - > -/* Vertical SYNC Width Status Register */ > -#define SP_V_SYNC_STA_REG 0x29 > - > -/* Vertical Back Porch Status Register */ > -#define SP_V_B_PORCH_STA_REG 0x2a > - > -/* Total Pixel Status Low Byte Register */ > -#define SP_TOTAL_PIXEL_STAL_REG 0x2b > - > -/* Total Pixel Status High Byte Register */ > -#define SP_TOTAL_PIXEL_STAH_REG 0x2c > - > -/* Active Pixel Status Low Byte Register */ > -#define SP_ACT_PIXEL_STAL_REG 0x2d > - > -/* Active Pixel Status High Byte Register */ > -#define SP_ACT_PIXEL_STAH_REG 0x2e > - > -/* Horizontal Front Porch Status Low Byte Register */ > -#define SP_H_F_PORCH_STAL_REG 0x2f > - > -/* Horizontal Front Porch Statys High Byte Register */ > -#define SP_H_F_PORCH_STAH_REG 0x30 > - > -/* Horizontal SYNC Width Status Low Byte Register */ > -#define SP_H_SYNC_STAL_REG 0x31 > - > -/* Horizontal SYNC Width Status High Byte Register */ > -#define SP_H_SYNC_STAH_REG 0x32 > - > -/* Horizontal Back Porch Status Low Byte Register */ > -#define SP_H_B_PORCH_STAL_REG 0x33 > - > -/* Horizontal Back Porch Status High Byte Register */ > -#define SP_H_B_PORCH_STAH_REG 0x34 > - > -/* InfoFrame AVI Packet DB1 Register */ > -#define SP_INFOFRAME_AVI_DB1_REG 0x70 > - > -/* Bit Control Specific Register */ > -#define SP_BIT_CTRL_SPECIFIC_REG 0x80 > -#define SP_BIT_CTRL_SELECT_SHIFT 1 > -#define SP_ENABLE_BIT_CTRL BIT(0) > - > -/* InfoFrame Audio Packet DB1 Register */ > -#define SP_INFOFRAME_AUD_DB1_REG 0x83 > - > -/* InfoFrame MPEG Packet DB1 Register */ > -#define SP_INFOFRAME_MPEG_DB1_REG 0xb0 > - > -/* Audio Channel Status Registers */ > -#define SP_AUD_CH_STATUS_BASE 0xd0 > - > -/* Audio Channel Num Register 5 */ > -#define SP_I2S_CHANNEL_NUM_MASK 0xe0 > -# define SP_I2S_CH_NUM_1 (0x00 << 5) > -# define SP_I2S_CH_NUM_2 (0x01 << 5) > -# define SP_I2S_CH_NUM_3 (0x02 << 5) > -# define SP_I2S_CH_NUM_4 (0x03 << 5) > -# define SP_I2S_CH_NUM_5 (0x04 << 5) > -# define SP_I2S_CH_NUM_6 (0x05 << 5) > -# define SP_I2S_CH_NUM_7 (0x06 << 5) > -# define SP_I2S_CH_NUM_8 (0x07 << 5) > -#define SP_EXT_VUCP BIT(2) > -#define SP_VBIT BIT(1) > -#define SP_AUDIO_LAYOUT BIT(0) > - > -/* Analog Debug Register 2 */ > -#define SP_ANALOG_DEBUG2_REG 0xdd > -#define SP_FORCE_SW_OFF_BYPASS 0x20 > -#define SP_XTAL_FRQ 0x1c > -# define SP_XTAL_FRQ_19M2 (0x00 << 2) > -# define SP_XTAL_FRQ_24M (0x01 << 2) > -# define SP_XTAL_FRQ_25M (0x02 << 2) > -# define SP_XTAL_FRQ_26M (0x03 << 2) > -# define SP_XTAL_FRQ_27M (0x04 << 2) > -# define SP_XTAL_FRQ_38M4 (0x05 << 2) > -# define SP_XTAL_FRQ_52M (0x06 << 2) > -#define SP_POWERON_TIME_1P5MS 0x03 > - > -/* Analog Control 0 Register */ > -#define SP_ANALOG_CTRL0_REG 0xe1 > - > -/* Common Interrupt Status Register 1 */ > -#define SP_COMMON_INT_STATUS_BASE (0xf1 - 1) > -#define SP_PLL_LOCK_CHG 0x40 > - > -/* Common Interrupt Status Register 2 */ > -#define SP_COMMON_INT_STATUS2 0xf2 > -#define SP_HDCP_AUTH_CHG BIT(1) > -#define SP_HDCP_AUTH_DONE BIT(0) > - > -#define SP_HDCP_LINK_CHECK_FAIL BIT(0) > - > -/* Common Interrupt Status Register 4 */ > -#define SP_COMMON_INT_STATUS4_REG 0xf4 > -#define SP_HPD_IRQ BIT(6) > -#define SP_HPD_ESYNC_ERR BIT(4) > -#define SP_HPD_CHG BIT(2) > -#define SP_HPD_LOST BIT(1) > -#define SP_HPD_PLUG BIT(0) > - > -/* DP Interrupt Status Register */ > -#define SP_DP_INT_STATUS1_REG 0xf7 > -#define SP_TRAINING_FINISH BIT(5) > -#define SP_POLLING_ERR BIT(4) > - > -/* Common Interrupt Mask Register */ > -#define SP_COMMON_INT_MASK_BASE (0xf8 - 1) > - > -#define SP_COMMON_INT_MASK4_REG 0xfb > - > -/* DP Interrupts Mask Register */ > -#define SP_DP_INT_MASK1_REG 0xfe > - > -/* Interrupt Control Register */ > -#define SP_INT_CTRL_REG 0xff > - > /***************************************************************/ > /* Register definition of device address 0x7a */ > /***************************************************************/ > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > new file mode 100644 > index 000000000000..5a54c6d86428 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > @@ -0,0 +1,256 @@ > +/* > + * Copyright(c) 2016, Analogix Semiconductor. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. Please use SPDX identifiers in all new files. > + * > + * Based on anx7808 driver obtained from chromeos with copyright: > + * Copyright(c) 2013, Google Inc. > + * > + */ > +#ifndef _ANALOGIX_I2C_DPTX_H_ > +#define _ANALOGIX_I2C_DPTX_H_ > + > +#define ANALOGIX_I2C_DPTX 0x70 > + > +/***************************************************************/ > +/* Register definition of device address 0x70 */ > +/***************************************************************/ > + > +/* HDCP Status Register */ > +#define SP_TX_HDCP_STATUS_REG 0x00 > +#define SP_AUTH_FAIL BIT(5) > +#define SP_AUTHEN_PASS BIT(1) > + > +/* HDCP Control Register 0 */ > +#define SP_HDCP_CTRL0_REG 0x01 > +#define SP_RX_REPEATER BIT(6) > +#define SP_RE_AUTH BIT(5) > +#define SP_SW_AUTH_OK BIT(4) > +#define SP_HARD_AUTH_EN BIT(3) > +#define SP_HDCP_ENC_EN BIT(2) > +#define SP_BKSV_SRM_PASS BIT(1) > +#define SP_KSVLIST_VLD BIT(0) > +/* HDCP Function Enabled */ > +#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3)) > + > +/* HDCP Receiver BSTATUS Register 0 */ > +#define SP_HDCP_RX_BSTATUS0_REG 0x1b > +/* HDCP Receiver BSTATUS Register 1 */ > +#define SP_HDCP_RX_BSTATUS1_REG 0x1c > + > +/* HDCP Embedded "Blue Screen" Content Registers */ > +#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c > +#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d > +#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e > + > +/* HDCP Wait R0 Timing Register */ > +#define SP_HDCP_WAIT_R0_TIME_REG 0x40 > + > +/* HDCP Link Integrity Check Timer Register */ > +#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41 > + > +/* HDCP Repeater Ready Wait Timer Register */ > +#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42 > + > +/* HDCP Auto Timer Register */ > +#define SP_HDCP_AUTO_TIMER_REG 0x51 > + > +/* HDCP Key Status Register */ > +#define SP_HDCP_KEY_STATUS_REG 0x5e > + > +/* HDCP Key Command Register */ > +#define SP_HDCP_KEY_COMMAND_REG 0x5f > +#define SP_DISABLE_SYNC_HDCP BIT(2) > + > +/* OTP Memory Key Protection Registers */ > +#define SP_OTP_KEY_PROTECT1_REG 0x60 > +#define SP_OTP_KEY_PROTECT2_REG 0x61 > +#define SP_OTP_KEY_PROTECT3_REG 0x62 > +#define SP_OTP_PSW1 0xa2 > +#define SP_OTP_PSW2 0x7e > +#define SP_OTP_PSW3 0xc6 > + > +/* DP System Control Registers */ > +#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1) > +/* Bits for DP System Control Register 2 */ > +#define SP_CHA_STA BIT(2) > +/* Bits for DP System Control Register 3 */ > +#define SP_HPD_STATUS BIT(6) > +#define SP_STRM_VALID BIT(2) > +/* Bits for DP System Control Register 4 */ > +#define SP_ENHANCED_MODE BIT(3) > + > +/* DP Video Control Register */ > +#define SP_DP_VIDEO_CTRL_REG 0x84 > +#define SP_COLOR_F_MASK 0x06 > +#define SP_COLOR_F_SHIFT 1 > +#define SP_BPC_MASK 0xe0 > +#define SP_BPC_SHIFT 5 > +# define SP_BPC_6BITS 0x00 > +# define SP_BPC_8BITS 0x01 > +# define SP_BPC_10BITS 0x02 > +# define SP_BPC_12BITS 0x03 > + > +/* DP Audio Control Register */ > +#define SP_DP_AUDIO_CTRL_REG 0x87 > +#define SP_AUD_EN BIT(0) > + > +/* 10us Pulse Generate Timer Registers */ > +#define SP_I2C_GEN_10US_TIMER0_REG 0x88 > +#define SP_I2C_GEN_10US_TIMER1_REG 0x89 > + > +/* Packet Send Control Register */ > +#define SP_PACKET_SEND_CTRL_REG 0x90 > +#define SP_AUD_IF_UP BIT(7) > +#define SP_AVI_IF_UD BIT(6) > +#define SP_MPEG_IF_UD BIT(5) > +#define SP_SPD_IF_UD BIT(4) > +#define SP_AUD_IF_EN BIT(3) > +#define SP_AVI_IF_EN BIT(2) > +#define SP_MPEG_IF_EN BIT(1) > +#define SP_SPD_IF_EN BIT(0) > + > +/* DP HDCP Control Register */ > +#define SP_DP_HDCP_CTRL_REG 0x92 > +#define SP_AUTO_EN BIT(7) > +#define SP_AUTO_START BIT(5) > +#define SP_LINK_POLLING BIT(1) > + > +/* DP Main Link Bandwidth Setting Register */ > +#define SP_DP_MAIN_LINK_BW_SET_REG 0xa0 > +#define SP_LINK_BW_SET_MASK 0x1f > +#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5) > + > +/* DP Training Pattern Set Register */ > +#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2 > + > +/* DP Lane 0 Link Training Control Register */ > +#define SP_DP_LANE0_LT_CTRL_REG 0xa3 > +#define SP_TX_SW_SET_MASK 0x1b > +#define SP_MAX_PRE_REACH BIT(5) > +#define SP_MAX_DRIVE_REACH BIT(4) > +#define SP_PRE_EMP_LEVEL1 BIT(3) > +#define SP_DRVIE_CURRENT_LEVEL1 BIT(0) > + > +/* DP Link Training Control Register */ > +#define SP_DP_LT_CTRL_REG 0xa8 > +#define SP_LT_ERROR_TYPE_MASK 0x70 > +# define SP_LT_NO_ERROR 0x00 > +# define SP_LT_AUX_WRITE_ERROR 0x01 > +# define SP_LT_MAX_DRIVE_REACHED 0x02 > +# define SP_LT_WRONG_LANE_COUNT_SET 0x03 > +# define SP_LT_LOOP_SAME_5_TIME 0x04 > +# define SP_LT_CR_FAIL_IN_EQ 0x05 > +# define SP_LT_EQ_LOOP_5_TIME 0x06 > +#define SP_LT_EN BIT(0) > + > +/* DP CEP Training Control Registers */ > +#define SP_DP_CEP_TRAINING_CTRL0_REG 0xa9 > +#define SP_DP_CEP_TRAINING_CTRL1_REG 0xaa > + > +/* DP Debug Register 1 */ > +#define SP_DP_DEBUG1_REG 0xb0 > +#define SP_DEBUG_PLL_LOCK BIT(4) > +#define SP_POLLING_EN BIT(1) > + > +/* DP Polling Control Register */ > +#define SP_DP_POLLING_CTRL_REG 0xb4 > +#define SP_AUTO_POLLING_DISABLE BIT(0) > + > +/* DP Link Debug Control Register */ > +#define SP_DP_LINK_DEBUG_CTRL_REG 0xb8 > +#define SP_M_VID_DEBUG BIT(5) > +#define SP_NEW_PRBS7 BIT(4) > +#define SP_INSERT_ER BIT(1) > +#define SP_PRBS31_EN BIT(0) > + > +/* AUX Misc control Register */ > +#define SP_AUX_MISC_CTRL_REG 0xbf > + > +/* DP PLL control Register */ > +#define SP_DP_PLL_CTRL_REG 0xc7 > +#define SP_PLL_RST BIT(6) > + > +/* DP Analog Power Down Register */ > +#define SP_DP_ANALOG_POWER_DOWN_REG 0xc8 > +#define SP_CH0_PD BIT(0) > + > +/* DP Misc Control Register */ > +#define SP_DP_MISC_CTRL_REG 0xcd > +#define SP_EQ_TRAINING_LOOP BIT(6) > + > +/* DP Extra I2C Device Address Register */ > +#define SP_DP_EXTRA_I2C_DEV_ADDR_REG 0xce > +#define SP_I2C_STRETCH_DISABLE BIT(7) > + > +#define SP_I2C_EXTRA_ADDR 0x50 > + > +/* DP Downspread Control Register 1 */ > +#define SP_DP_DOWNSPREAD_CTRL1_REG 0xd0 > + > +/* DP M Value Calculation Control Register */ > +#define SP_DP_M_CALCULATION_CTRL_REG 0xd9 > +#define SP_M_GEN_CLK_SEL BIT(0) > + > +/* AUX Channel Access Status Register */ > +#define SP_AUX_CH_STATUS_REG 0xe0 > +#define SP_AUX_STATUS 0x0f > + > +/* AUX Channel DEFER Control Register */ > +#define SP_AUX_DEFER_CTRL_REG 0xe2 > +#define SP_DEFER_CTRL_EN BIT(7) > + > +/* DP Buffer Data Count Register */ > +#define SP_BUF_DATA_COUNT_REG 0xe4 > +#define SP_BUF_DATA_COUNT_MASK 0x1f > +#define SP_BUF_CLR BIT(7) > + > +/* DP AUX Channel Control Register 1 */ > +#define SP_DP_AUX_CH_CTRL1_REG 0xe5 > +#define SP_AUX_TX_COMM_MASK 0x0f > +#define SP_AUX_LENGTH_MASK 0xf0 > +#define SP_AUX_LENGTH_SHIFT 4 > + > +/* DP AUX CH Address Register 0 */ > +#define SP_AUX_ADDR_7_0_REG 0xe6 > + > +/* DP AUX CH Address Register 1 */ > +#define SP_AUX_ADDR_15_8_REG 0xe7 > + > +/* DP AUX CH Address Register 2 */ > +#define SP_AUX_ADDR_19_16_REG 0xe8 > +#define SP_AUX_ADDR_19_16_MASK 0x0f > + > +/* DP AUX Channel Control Register 2 */ > +#define SP_DP_AUX_CH_CTRL2_REG 0xe9 > +#define SP_AUX_SEL_RXCM BIT(6) > +#define SP_AUX_CHSEL BIT(3) > +#define SP_AUX_PN_INV BIT(2) > +#define SP_ADDR_ONLY BIT(1) > +#define SP_AUX_EN BIT(0) > + > +/* DP Video Stream Control InfoFrame Register */ > +#define SP_DP_3D_VSC_CTRL_REG 0xea > +#define SP_INFO_FRAME_VSC_EN BIT(0) > + > +/* DP Video Stream Data Byte 1 Register */ > +#define SP_DP_VSC_DB1_REG 0xeb > + > +/* DP AUX Channel Control Register 3 */ > +#define SP_DP_AUX_CH_CTRL3_REG 0xec > +#define SP_WAIT_COUNTER_7_0_MASK 0xff > + > +/* DP AUX Channel Control Register 4 */ > +#define SP_DP_AUX_CH_CTRL4_REG 0xed > + > +/* DP AUX Buffer Data Registers */ > +#define SP_DP_BUF_DATA0_REG 0xf0 > + > +#endif > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > new file mode 100644 > index 000000000000..f48293f86f9d > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > @@ -0,0 +1,242 @@ > +/* > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. ditto With above fixed: Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> -- Regards Andrzej > + * > + */ > +#ifndef _ANALOGIX_I2C_TXCOMMON_H_ > +#define _ANALOGIX_I2C_TXCOMMON_H_ > + > +#define ANALOGIX_I2C_TXCOMMON 0x72 > + > +/***************************************************************/ > +/* Register definition of device address 0x72 */ > +/***************************************************************/ > + > +/* > + * Core Register Definitions > + */ > + > +/* Device ID Low Byte Register */ > +#define SP_DEVICE_IDL_REG 0x02 > + > +/* Device ID High Byte Register */ > +#define SP_DEVICE_IDH_REG 0x03 > + > +/* Device version register */ > +#define SP_DEVICE_VERSION_REG 0x04 > + > +/* Power Down Control Register */ > +#define SP_POWERDOWN_CTRL_REG 0x05 > +#define SP_REGISTER_PD BIT(7) > +#define SP_HDCP_PD BIT(5) > +#define SP_AUDIO_PD BIT(4) > +#define SP_VIDEO_PD BIT(3) > +#define SP_LINK_PD BIT(2) > +#define SP_TOTAL_PD BIT(1) > + > +/* Reset Control Register 1 */ > +#define SP_RESET_CTRL1_REG 0x06 > +#define SP_MISC_RST BIT(7) > +#define SP_VIDCAP_RST BIT(6) > +#define SP_VIDFIF_RST BIT(5) > +#define SP_AUDFIF_RST BIT(4) > +#define SP_AUDCAP_RST BIT(3) > +#define SP_HDCP_RST BIT(2) > +#define SP_SW_RST BIT(1) > +#define SP_HW_RST BIT(0) > + > +/* Reset Control Register 2 */ > +#define SP_RESET_CTRL2_REG 0x07 > +#define SP_AUX_RST BIT(2) > +#define SP_SERDES_FIFO_RST BIT(1) > +#define SP_I2C_REG_RST BIT(0) > + > +/* Video Control Register 1 */ > +#define SP_VID_CTRL1_REG 0x08 > +#define SP_VIDEO_EN BIT(7) > +#define SP_VIDEO_MUTE BIT(2) > +#define SP_DE_GEN BIT(1) > +#define SP_DEMUX BIT(0) > + > +/* Video Control Register 2 */ > +#define SP_VID_CTRL2_REG 0x09 > +#define SP_IN_COLOR_F_MASK 0x03 > +#define SP_IN_YC_BIT_SEL BIT(2) > +#define SP_IN_BPC_MASK 0x70 > +#define SP_IN_BPC_SHIFT 4 > +# define SP_IN_BPC_12BIT 0x03 > +# define SP_IN_BPC_10BIT 0x02 > +# define SP_IN_BPC_8BIT 0x01 > +# define SP_IN_BPC_6BIT 0x00 > +#define SP_IN_D_RANGE BIT(7) > + > +/* Video Control Register 3 */ > +#define SP_VID_CTRL3_REG 0x0a > +#define SP_HPD_OUT BIT(6) > + > +/* Video Control Register 5 */ > +#define SP_VID_CTRL5_REG 0x0c > +#define SP_CSC_STD_SEL BIT(7) > +#define SP_XVYCC_RNG_LMT BIT(6) > +#define SP_RANGE_Y2R BIT(5) > +#define SP_CSPACE_Y2R BIT(4) > +#define SP_RGB_RNG_LMT BIT(3) > +#define SP_Y_RNG_LMT BIT(2) > +#define SP_RANGE_R2Y BIT(1) > +#define SP_CSPACE_R2Y BIT(0) > + > +/* Video Control Register 6 */ > +#define SP_VID_CTRL6_REG 0x0d > +#define SP_TEST_PATTERN_EN BIT(7) > +#define SP_VIDEO_PROCESS_EN BIT(6) > +#define SP_VID_US_MODE BIT(3) > +#define SP_VID_DS_MODE BIT(2) > +#define SP_UP_SAMPLE BIT(1) > +#define SP_DOWN_SAMPLE BIT(0) > + > +/* Video Control Register 8 */ > +#define SP_VID_CTRL8_REG 0x0f > +#define SP_VID_VRES_TH BIT(0) > + > +/* Total Line Status Low Byte Register */ > +#define SP_TOTAL_LINE_STAL_REG 0x24 > + > +/* Total Line Status High Byte Register */ > +#define SP_TOTAL_LINE_STAH_REG 0x25 > + > +/* Active Line Status Low Byte Register */ > +#define SP_ACT_LINE_STAL_REG 0x26 > + > +/* Active Line Status High Byte Register */ > +#define SP_ACT_LINE_STAH_REG 0x27 > + > +/* Vertical Front Porch Status Register */ > +#define SP_V_F_PORCH_STA_REG 0x28 > + > +/* Vertical SYNC Width Status Register */ > +#define SP_V_SYNC_STA_REG 0x29 > + > +/* Vertical Back Porch Status Register */ > +#define SP_V_B_PORCH_STA_REG 0x2a > + > +/* Total Pixel Status Low Byte Register */ > +#define SP_TOTAL_PIXEL_STAL_REG 0x2b > + > +/* Total Pixel Status High Byte Register */ > +#define SP_TOTAL_PIXEL_STAH_REG 0x2c > + > +/* Active Pixel Status Low Byte Register */ > +#define SP_ACT_PIXEL_STAL_REG 0x2d > + > +/* Active Pixel Status High Byte Register */ > +#define SP_ACT_PIXEL_STAH_REG 0x2e > + > +/* Horizontal Front Porch Status Low Byte Register */ > +#define SP_H_F_PORCH_STAL_REG 0x2f > + > +/* Horizontal Front Porch Statys High Byte Register */ > +#define SP_H_F_PORCH_STAH_REG 0x30 > + > +/* Horizontal SYNC Width Status Low Byte Register */ > +#define SP_H_SYNC_STAL_REG 0x31 > + > +/* Horizontal SYNC Width Status High Byte Register */ > +#define SP_H_SYNC_STAH_REG 0x32 > + > +/* Horizontal Back Porch Status Low Byte Register */ > +#define SP_H_B_PORCH_STAL_REG 0x33 > + > +/* Horizontal Back Porch Status High Byte Register */ > +#define SP_H_B_PORCH_STAH_REG 0x34 > + > +/* InfoFrame AVI Packet DB1 Register */ > +#define SP_INFOFRAME_AVI_DB1_REG 0x70 > + > +/* Bit Control Specific Register */ > +#define SP_BIT_CTRL_SPECIFIC_REG 0x80 > +#define SP_BIT_CTRL_SELECT_SHIFT 1 > +#define SP_ENABLE_BIT_CTRL BIT(0) > + > +/* InfoFrame Audio Packet DB1 Register */ > +#define SP_INFOFRAME_AUD_DB1_REG 0x83 > + > +/* InfoFrame MPEG Packet DB1 Register */ > +#define SP_INFOFRAME_MPEG_DB1_REG 0xb0 > + > +/* Audio Channel Status Registers */ > +#define SP_AUD_CH_STATUS_BASE 0xd0 > + > +/* Audio Channel Num Register 5 */ > +#define SP_I2S_CHANNEL_NUM_MASK 0xe0 > +# define SP_I2S_CH_NUM_1 (0x00 << 5) > +# define SP_I2S_CH_NUM_2 (0x01 << 5) > +# define SP_I2S_CH_NUM_3 (0x02 << 5) > +# define SP_I2S_CH_NUM_4 (0x03 << 5) > +# define SP_I2S_CH_NUM_5 (0x04 << 5) > +# define SP_I2S_CH_NUM_6 (0x05 << 5) > +# define SP_I2S_CH_NUM_7 (0x06 << 5) > +# define SP_I2S_CH_NUM_8 (0x07 << 5) > +#define SP_EXT_VUCP BIT(2) > +#define SP_VBIT BIT(1) > +#define SP_AUDIO_LAYOUT BIT(0) > + > +/* Analog Debug Register 2 */ > +#define SP_ANALOG_DEBUG2_REG 0xdd > +#define SP_FORCE_SW_OFF_BYPASS 0x20 > +#define SP_XTAL_FRQ 0x1c > +# define SP_XTAL_FRQ_19M2 (0x00 << 2) > +# define SP_XTAL_FRQ_24M (0x01 << 2) > +# define SP_XTAL_FRQ_25M (0x02 << 2) > +# define SP_XTAL_FRQ_26M (0x03 << 2) > +# define SP_XTAL_FRQ_27M (0x04 << 2) > +# define SP_XTAL_FRQ_38M4 (0x05 << 2) > +# define SP_XTAL_FRQ_52M (0x06 << 2) > +#define SP_POWERON_TIME_1P5MS 0x03 > + > +/* Analog Control 0 Register */ > +#define SP_ANALOG_CTRL0_REG 0xe1 > + > +/* Common Interrupt Status Register 1 */ > +#define SP_COMMON_INT_STATUS_BASE (0xf1 - 1) > +#define SP_PLL_LOCK_CHG 0x40 > + > +/* Common Interrupt Status Register 2 */ > +#define SP_COMMON_INT_STATUS2 0xf2 > +#define SP_HDCP_AUTH_CHG BIT(1) > +#define SP_HDCP_AUTH_DONE BIT(0) > + > +#define SP_HDCP_LINK_CHECK_FAIL BIT(0) > + > +/* Common Interrupt Status Register 4 */ > +#define SP_COMMON_INT_STATUS4_REG 0xf4 > +#define SP_HPD_IRQ BIT(6) > +#define SP_HPD_ESYNC_ERR BIT(4) > +#define SP_HPD_CHG BIT(2) > +#define SP_HPD_LOST BIT(1) > +#define SP_HPD_PLUG BIT(0) > + > +/* DP Interrupt Status Register */ > +#define SP_DP_INT_STATUS1_REG 0xf7 > +#define SP_TRAINING_FINISH BIT(5) > +#define SP_POLLING_ERR BIT(4) > + > +/* Common Interrupt Mask Register */ > +#define SP_COMMON_INT_MASK_BASE (0xf8 - 1) > + > +#define SP_COMMON_INT_MASK4_REG 0xfb > + > +/* DP Interrupts Mask Register */ > +#define SP_DP_INT_MASK1_REG 0xfe > + > +/* Interrupt Control Register */ > +#define SP_INT_CTRL_REG 0xff > + > +#endif /* _ANALOGIX_I2C_TXCOMMON_H_ */
On 04.06.2019 14:22, Torsten Duwe wrote: > From: Icenowy Zheng <icenowy@aosc.io> > > Some code can be shared within different DP bridges by Analogix. > Extract them to analogix_dp. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > Signed-off-by: Torsten Duwe <duwe@suse.de> > --- > drivers/gpu/drm/bridge/analogix/Makefile | 2 +- > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +---------------- > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 173 +++++++++++++++++++++ > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 3 + > 4 files changed, 178 insertions(+), 146 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile > index 6fcbfd3ee560..7623b9b80167 100644 > --- a/drivers/gpu/drm/bridge/analogix/Makefile > +++ b/drivers/gpu/drm/bridge/analogix/Makefile > @@ -1,4 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0-only > -analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o > +analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > index c09aaf93ae1b..f36ae51c641d 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > @@ -45,8 +45,6 @@ > #define I2C_IDX_RX_P1 4 > > #define XTAL_CLK 270 /* 27M */ > -#define AUX_CH_BUFFER_SIZE 16 > -#define AUX_WAIT_TIMEOUT_MS 15 > > static const u8 anx78xx_i2c_addresses[] = { > [I2C_IDX_TX_P0] = TX_P0, > @@ -109,153 +107,11 @@ static int anx78xx_clear_bits(struct regmap *map, u8 reg, u8 mask) > return regmap_update_bits(map, reg, mask, 0); > } > > -static bool anx78xx_aux_op_finished(struct anx78xx *anx78xx) > -{ > - unsigned int value; > - int err; > - > - err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL2_REG, > - &value); > - if (err < 0) > - return false; > - > - return (value & SP_AUX_EN) == 0; > -} > - > -static int anx78xx_aux_wait(struct anx78xx *anx78xx) > -{ > - unsigned long timeout; > - unsigned int status; > - int err; > - > - timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1; > - > - while (!anx78xx_aux_op_finished(anx78xx)) { > - if (time_after(jiffies, timeout)) { > - if (!anx78xx_aux_op_finished(anx78xx)) { > - DRM_ERROR("Timed out waiting AUX to finish\n"); > - return -ETIMEDOUT; > - } > - > - break; > - } > - > - usleep_range(1000, 2000); > - } > - > - /* Read the AUX channel access status */ > - err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_CH_STATUS_REG, > - &status); > - if (err < 0) { > - DRM_ERROR("Failed to read from AUX channel: %d\n", err); > - return err; > - } > - > - if (status & SP_AUX_STATUS) { > - DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n", > - status); > - return -ETIMEDOUT; > - } > - > - return 0; > -} > - > -static int anx78xx_aux_address(struct anx78xx *anx78xx, unsigned int addr) > -{ > - int err; > - > - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_7_0_REG, > - addr & 0xff); > - if (err) > - return err; > - > - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_15_8_REG, > - (addr & 0xff00) >> 8); > - if (err) > - return err; > - > - /* > - * DP AUX CH Address Register #2, only update bits[3:0] > - * [7:4] RESERVED > - * [3:0] AUX_ADDR[19:16], Register control AUX CH address. > - */ > - err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0], > - SP_AUX_ADDR_19_16_REG, > - SP_AUX_ADDR_19_16_MASK, > - (addr & 0xf0000) >> 16); > - > - if (err) > - return err; > - > - return 0; > -} > - > static ssize_t anx78xx_aux_transfer(struct drm_dp_aux *aux, > struct drm_dp_aux_msg *msg) > { > struct anx78xx *anx78xx = container_of(aux, struct anx78xx, aux); > - u8 ctrl1 = msg->request; > - u8 ctrl2 = SP_AUX_EN; > - u8 *buffer = msg->buffer; > - int err; > - > - /* The DP AUX transmit and receive buffer has 16 bytes. */ > - if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE)) > - return -E2BIG; > - > - /* Zero-sized messages specify address-only transactions. */ > - if (msg->size < 1) > - ctrl2 |= SP_ADDR_ONLY; > - else /* For non-zero-sized set the length field. */ > - ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT; > - > - if ((msg->request & DP_AUX_I2C_READ) == 0) { > - /* When WRITE | MOT write values to data buffer */ > - err = regmap_bulk_write(anx78xx->map[I2C_IDX_TX_P0], > - SP_DP_BUF_DATA0_REG, buffer, > - msg->size); > - if (err) > - return err; > - } > - > - /* Write address and request */ > - err = anx78xx_aux_address(anx78xx, msg->address); > - if (err) > - return err; > - > - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL1_REG, > - ctrl1); > - if (err) > - return err; > - > - /* Start transaction */ > - err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0], > - SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY | > - SP_AUX_EN, ctrl2); > - if (err) > - return err; > - > - err = anx78xx_aux_wait(anx78xx); > - if (err) > - return err; > - > - msg->reply = DP_AUX_I2C_REPLY_ACK; > - > - if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) { > - /* Read values from data buffer */ > - err = regmap_bulk_read(anx78xx->map[I2C_IDX_TX_P0], > - SP_DP_BUF_DATA0_REG, buffer, > - msg->size); > - if (err) > - return err; > - } > - > - err = anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P0], > - SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY); > - if (err) > - return err; > - > - return msg->size; > + return anx_dp_aux_transfer(anx78xx->map[I2C_IDX_TX_P0], msg); > } > > static int anx78xx_set_hpd(struct anx78xx *anx78xx) > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > new file mode 100644 > index 000000000000..d6016f789d80 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > @@ -0,0 +1,174 @@ > +/* > + * Copyright(c) 2016, Analogix Semiconductor. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. Again spdx. With that fixed: Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> -- Regards Andrzej > + * > + * Based on anx7808 driver obtained from chromeos with copyright: > + * Copyright(c) 2013, Google Inc. > + * > + */ > +#include <linux/regmap.h> > + > +#include <drm/drm.h> > +#include <drm/drm_dp_helper.h> > +#include <drm/drm_print.h> > + > +#include "analogix-i2c-dptx.h" > + > +#define AUX_WAIT_TIMEOUT_MS 15 > +#define AUX_CH_BUFFER_SIZE 16 > + > +static int anx_i2c_dp_clear_bits(struct regmap *map, u8 reg, u8 mask) > +{ > + return regmap_update_bits(map, reg, mask, 0); > +} > + > +static bool anx_dp_aux_op_finished(struct regmap *map_dptx) > +{ > + unsigned int value; > + int err; > + > + err = regmap_read(map_dptx, SP_DP_AUX_CH_CTRL2_REG, &value); > + if (err < 0) > + return false; > + > + return (value & SP_AUX_EN) == 0; > +} > + > +static int anx_dp_aux_wait(struct regmap *map_dptx) > +{ > + unsigned long timeout; > + unsigned int status; > + int err; > + > + timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1; > + > + while (!anx_dp_aux_op_finished(map_dptx)) { > + if (time_after(jiffies, timeout)) { > + if (!anx_dp_aux_op_finished(map_dptx)) { > + DRM_ERROR("Timed out waiting AUX to finish\n"); > + return -ETIMEDOUT; > + } > + > + break; > + } > + > + usleep_range(1000, 2000); > + } > + > + /* Read the AUX channel access status */ > + err = regmap_read(map_dptx, SP_AUX_CH_STATUS_REG, &status); > + if (err < 0) { > + DRM_ERROR("Failed to read from AUX channel: %d\n", err); > + return err; > + } > + > + if (status & SP_AUX_STATUS) { > + DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n", > + status); > + return -ETIMEDOUT; > + } > + > + return 0; > +} > + > +static int anx_dp_aux_address(struct regmap *map_dptx, unsigned int addr) > +{ > + int err; > + > + err = regmap_write(map_dptx, SP_AUX_ADDR_7_0_REG, addr & 0xff); > + if (err) > + return err; > + > + err = regmap_write(map_dptx, SP_AUX_ADDR_15_8_REG, > + (addr & 0xff00) >> 8); > + if (err) > + return err; > + > + /* > + * DP AUX CH Address Register #2, only update bits[3:0] > + * [7:4] RESERVED > + * [3:0] AUX_ADDR[19:16], Register control AUX CH address. > + */ > + err = regmap_update_bits(map_dptx, SP_AUX_ADDR_19_16_REG, > + SP_AUX_ADDR_19_16_MASK, > + (addr & 0xf0000) >> 16); > + > + if (err) > + return err; > + > + return 0; > +} > + > +ssize_t anx_dp_aux_transfer(struct regmap *map_dptx, > + struct drm_dp_aux_msg *msg) > +{ > + u8 ctrl1 = msg->request; > + u8 ctrl2 = SP_AUX_EN; > + u8 *buffer = msg->buffer; > + int err; > + > + /* The DP AUX transmit and receive buffer has 16 bytes. */ > + if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE)) > + return -E2BIG; > + > + /* Zero-sized messages specify address-only transactions. */ > + if (msg->size < 1) > + ctrl2 |= SP_ADDR_ONLY; > + else /* For non-zero-sized set the length field. */ > + ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT; > + > + if ((msg->request & DP_AUX_I2C_READ) == 0) { > + /* When WRITE | MOT write values to data buffer */ > + err = regmap_bulk_write(map_dptx, > + SP_DP_BUF_DATA0_REG, buffer, > + msg->size); > + if (err) > + return err; > + } > + > + /* Write address and request */ > + err = anx_dp_aux_address(map_dptx, msg->address); > + if (err) > + return err; > + > + err = regmap_write(map_dptx, SP_DP_AUX_CH_CTRL1_REG, ctrl1); > + if (err) > + return err; > + > + /* Start transaction */ > + err = regmap_update_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG, > + SP_ADDR_ONLY | SP_AUX_EN, ctrl2); > + if (err) > + return err; > + > + err = anx_dp_aux_wait(map_dptx); > + if (err) > + return err; > + > + msg->reply = DP_AUX_I2C_REPLY_ACK; > + > + if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) { > + /* Read values from data buffer */ > + err = regmap_bulk_read(map_dptx, > + SP_DP_BUF_DATA0_REG, buffer, > + msg->size); > + if (err) > + return err; > + } > + > + err = anx_i2c_dp_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG, > + SP_ADDR_ONLY); > + if (err) > + return err; > + > + return msg->size; > +} > +EXPORT_SYMBOL_GPL(anx_dp_aux_transfer); > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > index 5a54c6d86428..30436c88f181 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > @@ -253,4 +253,7 @@ > /* DP AUX Buffer Data Registers */ > #define SP_DP_BUF_DATA0_REG 0xf0 > > +ssize_t anx_dp_aux_transfer(struct regmap *map_dptx, > + struct drm_dp_aux_msg *msg); > + > #endif
On 04.06.2019 14:22, Torsten Duwe wrote: > Add bit definitions required for the anx6345 and add a > sanity check in anx_dp_aux_transfer. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > Signed-off-by: Torsten Duwe <duwe@suse.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> -- Regards Andrzej > --- > drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 2 +- > drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 8 ++++++++ > drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h | 3 +++ > 3 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > index d6016f789d80..e9d2ed4d410d 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > @@ -124,7 +124,7 @@ ssize_t anx_dp_aux_transfer(struct regmap *map_dptx, > else /* For non-zero-sized set the length field. */ > ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT; > > - if ((msg->request & DP_AUX_I2C_READ) == 0) { > + if ((msg->size > 0) && ((msg->request & DP_AUX_I2C_READ) == 0)) { > /* When WRITE | MOT write values to data buffer */ > err = regmap_bulk_write(map_dptx, > SP_DP_BUF_DATA0_REG, buffer, > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > index 30436c88f181..95ab89eecc60 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h > @@ -83,7 +83,11 @@ > #define SP_CHA_STA BIT(2) > /* Bits for DP System Control Register 3 */ > #define SP_HPD_STATUS BIT(6) > +#define SP_HPD_FORCE BIT(5) > +#define SP_HPD_CTRL BIT(4) > #define SP_STRM_VALID BIT(2) > +#define SP_STRM_FORCE BIT(1) > +#define SP_STRM_CTRL BIT(0) > /* Bits for DP System Control Register 4 */ > #define SP_ENHANCED_MODE BIT(3) > > @@ -128,6 +132,9 @@ > #define SP_LINK_BW_SET_MASK 0x1f > #define SP_INITIAL_SLIM_M_AUD_SEL BIT(5) > > +/* DP Lane Count Setting Register */ > +#define SP_DP_LANE_COUNT_SET_REG 0xa1 > + > /* DP Training Pattern Set Register */ > #define SP_DP_TRAINING_PATTERN_SET_REG 0xa2 > > @@ -141,6 +148,7 @@ > > /* DP Link Training Control Register */ > #define SP_DP_LT_CTRL_REG 0xa8 > +#define SP_DP_LT_INPROGRESS 0x80 > #define SP_LT_ERROR_TYPE_MASK 0x70 > # define SP_LT_NO_ERROR 0x00 > # define SP_LT_AUX_WRITE_ERROR 0x01 > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > index f48293f86f9d..e3391a50b5d1 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h > @@ -188,6 +188,9 @@ > #define SP_VBIT BIT(1) > #define SP_AUDIO_LAYOUT BIT(0) > > +/* Analog Debug Register 1 */ > +#define SP_ANALOG_DEBUG1_REG 0xdc > + > /* Analog Debug Register 2 */ > #define SP_ANALOG_DEBUG2_REG 0xdd > #define SP_FORCE_SW_OFF_BYPASS 0x20
On 04.06.2019 14:23, Torsten Duwe wrote: > From: Icenowy Zheng <icenowy@aosc.io> > > The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed > for portable devices. This driver adds initial support for RGB to eDP > mode, without HPD and interrupts. > > This is a configuration usually seen in eDP applications. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > Signed-off-by: Torsten Duwe <duwe@suse.de> > --- > drivers/gpu/drm/bridge/analogix/Kconfig | 12 + > drivers/gpu/drm/bridge/analogix/Makefile | 1 + > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 814 +++++++++++++++++++++ > 3 files changed, 827 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c > > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig > index 704fb0f41dc3..cd89e238b93e 100644 > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > @@ -1,6 +1,18 @@ > # SPDX-License-Identifier: GPL-2.0-only > +config DRM_ANALOGIX_ANX6345 > + tristate "Analogix ANX6345 bridge" > + select DRM_ANALOGIX_DP > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + ANX6345 is an ultra-low Full-HD DisplayPort/eDP > + transmitter designed for portable devices. The > + ANX6345 transforms the LVTTL RGB output of an > + application processor to eDP or DisplayPort. > + > config DRM_ANALOGIX_ANX78XX > tristate "Analogix ANX78XX bridge" > + select DRM_ANALOGIX_DP > select DRM_KMS_HELPER > select REGMAP_I2C > help > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile > index 7623b9b80167..97669b374098 100644 > --- a/drivers/gpu/drm/bridge/analogix/Makefile > +++ b/drivers/gpu/drm/bridge/analogix/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0-only > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o > +obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c > new file mode 100644 > index 000000000000..ae222f9f6586 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c > @@ -0,0 +1,814 @@ > +/* > + * Copyright(c) 2016, Analogix Semiconductor. > + * Copyright(c) 2017, Icenowy Zheng <icenowy@aosc.io> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. SPDX > + * > + * Based on anx7808 driver obtained from chromeos with copyright: > + * Copyright(c) 2013, Google Inc. > + * > + */ > +#include <linux/delay.h> > +#include <linux/err.h> > +#include <linux/gpio/consumer.h> > +#include <linux/i2c.h> > +#include <linux/interrupt.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/of_platform.h> > +#include <linux/regmap.h> > +#include <linux/regulator/consumer.h> > +#include <linux/types.h> > + > +#include <drm/drm_atomic_helper.h> > +#include <drm/drm_crtc.h> > +#include <drm/drm_crtc_helper.h> > +#include <drm/drm_dp_helper.h> > +#include <drm/drm_edid.h> > +#include <drm/drm_of.h> > +#include <drm/drm_panel.h> > +#include <drm/drm_print.h> > +#include <drm/drm_probe_helper.h> > + > +#include "analogix-i2c-dptx.h" > +#include "analogix-i2c-txcommon.h" > + > +#define I2C_NUM_ADDRESSES 2 You can define it as ARRAY_SIZE(anx6345_i2c_addresses) - more generic. > +#define I2C_IDX_DPTX 0 > +#define I2C_IDX_TXCOM 1 > + > +#define POLL_DELAY 50000 /* us */ > +#define POLL_TIMEOUT 5000000 /* us */ > + > +static const u8 anx6345_i2c_addresses[] = { > + [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX, > + [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON, > +}; > + > +struct anx6345 { > + struct drm_dp_aux aux; > + struct drm_bridge bridge; > + struct i2c_client *client; > + struct edid *edid; > + struct drm_connector connector; > + struct drm_dp_link link; > + struct drm_panel *panel; > + struct regulator *dvdd12; > + struct regulator *dvdd25; > + struct gpio_desc *gpiod_reset; > + struct mutex lock; /* protect EDID access */ > + > + /* I2C Slave addresses of ANX6345 are mapped as DPTX and SYS */ > + struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES]; > + struct regmap *map[I2C_NUM_ADDRESSES]; > + > + u16 chipid; > + u8 dpcd[DP_RECEIVER_CAP_SIZE]; > + > + bool powered; > +}; > + > +static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c) > +{ > + return container_of(c, struct anx6345, connector); > +} > + > +static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct anx6345, bridge); > +} > + > +static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask) > +{ > + return regmap_update_bits(map, reg, mask, mask); > +} > + > +static int anx6345_clear_bits(struct regmap *map, u8 reg, u8 mask) > +{ > + return regmap_update_bits(map, reg, mask, 0); > +} > + > +static ssize_t anx6345_aux_transfer(struct drm_dp_aux *aux, > + struct drm_dp_aux_msg *msg) > +{ > + struct anx6345 *anx6345 = container_of(aux, struct anx6345, aux); > + > + return anx_dp_aux_transfer(anx6345->map[I2C_IDX_DPTX], msg); > +} > + > +static int anx6345_dp_link_training(struct anx6345 *anx6345) > +{ > + unsigned int value; > + u8 dp_bw; > + int err; > + > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], > + SP_POWERDOWN_CTRL_REG, > + SP_TOTAL_PD); > + if (err) > + return err; > + > + err = drm_dp_dpcd_readb(&anx6345->aux, DP_MAX_LINK_RATE, &dp_bw); > + if (err < 0) > + return err; > + > + switch (dp_bw) { > + case DP_LINK_BW_1_62: > + case DP_LINK_BW_2_7: > + break; > + > + default: > + DRM_DEBUG_KMS("DP bandwidth (%#02x) not supported\n", dp_bw); > + return -EINVAL; > + } > + > + err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG, > + SP_VIDEO_MUTE); > + if (err) > + return err; > + > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], > + SP_VID_CTRL1_REG, SP_VIDEO_EN); > + if (err) > + return err; > + > + /* Get DPCD info */ > + err = drm_dp_dpcd_read(&anx6345->aux, DP_DPCD_REV, > + &anx6345->dpcd, DP_RECEIVER_CAP_SIZE); > + if (err < 0) { > + DRM_ERROR("Failed to read DPCD: %d\n", err); > + return err; > + } > + > + /* Clear channel x SERDES power down */ > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX], > + SP_DP_ANALOG_POWER_DOWN_REG, SP_CH0_PD); > + if (err) > + return err; > + > + /* Check link capabilities */ > + err = drm_dp_link_probe(&anx6345->aux, &anx6345->link); > + if (err < 0) { > + DRM_ERROR("Failed to probe link capabilities: %d\n", err); > + return err; > + } > + > + /* Power up the sink */ > + err = drm_dp_link_power_up(&anx6345->aux, &anx6345->link); > + if (err < 0) { > + DRM_ERROR("Failed to power up DisplayPort link: %d\n", err); > + return err; > + } > + > + /* Possibly enable downspread on the sink */ > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_DOWNSPREAD_CTRL1_REG, 0); > + if (err) > + return err; > + > + if (anx6345->dpcd[DP_MAX_DOWNSPREAD] & DP_MAX_DOWNSPREAD_0_5) { > + DRM_DEBUG("Enable downspread on the sink\n"); > + /* 4000PPM */ > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_DOWNSPREAD_CTRL1_REG, 8); > + if (err) > + return err; > + > + err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL, > + DP_SPREAD_AMP_0_5); > + if (err < 0) > + return err; > + } else { > + err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL, 0); > + if (err < 0) > + return err; > + } > + > + /* Set the lane count and the link rate on the sink */ > + if (drm_dp_enhanced_frame_cap(anx6345->dpcd)) > + err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX], > + SP_DP_SYSTEM_CTRL_BASE + 4, > + SP_ENHANCED_MODE); > + else > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX], > + SP_DP_SYSTEM_CTRL_BASE + 4, > + SP_ENHANCED_MODE); > + if (err) > + return err; > + > + value = drm_dp_link_rate_to_bw_code(anx6345->link.rate); > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_MAIN_LINK_BW_SET_REG, value); > + if (err) > + return err; > + > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_LANE_COUNT_SET_REG, anx6345->link.num_lanes); > + if (err) > + return err; > + > + err = drm_dp_link_configure(&anx6345->aux, &anx6345->link); > + if (err < 0) { > + DRM_ERROR("Failed to configure DisplayPort link: %d\n", err); > + return err; > + } > + > + /* Start training on the source */ > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_LT_CTRL_REG, > + SP_LT_EN); > + if (err) > + return err; > + > + err = regmap_read_poll_timeout(anx6345->map[I2C_IDX_DPTX], > + SP_DP_LT_CTRL_REG, > + value, !(value & SP_DP_LT_INPROGRESS), > + POLL_DELAY, POLL_TIMEOUT); > + if (err) > + return err; > + > + return 0; You can use: return regmap_read_poll_timeout(....); > +} > + > +static int anx6345_tx_initialization(struct anx6345 *anx6345) > +{ > + int err, i; > + > + /* FIXME: colordepth is hardcoded for now */ > + err = regmap_write(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL2_REG, > + SP_IN_BPC_6BIT << SP_IN_BPC_SHIFT); > + if (err) > + return err; > + > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_PLL_CTRL_REG, 0); > + if (err) > + return err; > + > + err = regmap_write(anx6345->map[I2C_IDX_TXCOM], > + SP_ANALOG_DEBUG1_REG, 0); > + if (err) > + return err; > + > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_LINK_DEBUG_CTRL_REG, > + SP_NEW_PRBS7 | SP_M_VID_DEBUG); > + if (err) > + return err; > + > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_ANALOG_POWER_DOWN_REG, 0); > + if (err) > + return err; > + > + /* Force HPD */ > + err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX], > + SP_DP_SYSTEM_CTRL_BASE + 3, > + SP_HPD_FORCE | SP_HPD_CTRL); > + if (err) > + return err; > + > + for (i = 0; i < 4; i++) { > + /* 4 lanes */ > + err = regmap_write(anx6345->map[I2C_IDX_DPTX], > + SP_DP_LANE0_LT_CTRL_REG + i, 0); > + if (err) > + return err; > + } > + > + /* Reset AUX */ > + err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], > + SP_RESET_CTRL2_REG, SP_AUX_RST); > + if (err) > + return err; > + > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], > + SP_RESET_CTRL2_REG, SP_AUX_RST); > + if (err) > + return err; > + > + return 0; ditto > +} > + > +static void anx6345_poweron(struct anx6345 *anx6345) > +{ > + int err; > + > + /* Ensure reset is asserted before starting power on sequence */ > + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1); With fixed devm_gpiod_get below this line can be removed. > + usleep_range(1000, 2000); > + > + err = regulator_enable(anx6345->dvdd12); > + if (err) { > + DRM_ERROR("Failed to enable dvdd12 regulator: %d\n", > + err); > + return; > + } > + > + /* T1 - delay between VDD12 and VDD25 should be 0-2ms */ > + usleep_range(1000, 2000); > + > + err = regulator_enable(anx6345->dvdd25); > + if (err) { > + DRM_ERROR("Failed to enable dvdd25 regulator: %d\n", > + err); > + return; > + } > + > + /* T2 - delay between RESETN and all power rail stable, > + * should be 2-5ms > + */ > + usleep_range(2000, 5000); > + > + gpiod_set_value_cansleep(anx6345->gpiod_reset, 0); > + > + /* Power on registers module */ > + anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG, > + SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD); > + anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG, > + SP_REGISTER_PD | SP_TOTAL_PD); > + > + if (anx6345->panel) > + drm_panel_prepare(anx6345->panel); > + > + anx6345->powered = true; > +} > + > +static void anx6345_poweroff(struct anx6345 *anx6345) > +{ > + int err; > + > + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1); > + usleep_range(1000, 2000); > + > + if (anx6345->panel) > + drm_panel_unprepare(anx6345->panel); > + > + err = regulator_disable(anx6345->dvdd25); > + if (err) { > + DRM_ERROR("Failed to disable dvdd25 regulator: %d\n", > + err); > + return; > + } > + > + usleep_range(5000, 10000); > + > + err = regulator_disable(anx6345->dvdd12); > + if (err) { > + DRM_ERROR("Failed to disable dvdd12 regulator: %d\n", > + err); > + return; > + } > + > + usleep_range(1000, 2000); > + > + anx6345->powered = false; > +} > + > +static int anx6345_start(struct anx6345 *anx6345) > +{ > + int err; > + > + if (!anx6345->powered) > + anx6345_poweron(anx6345); > + > + /* Power on needed modules */ > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], > + SP_POWERDOWN_CTRL_REG, > + SP_VIDEO_PD | SP_LINK_PD); > + > + err = anx6345_tx_initialization(anx6345); > + if (err) { > + DRM_ERROR("Failed eDP transmitter initialization: %d\n", err); > + anx6345_poweroff(anx6345); > + return err; > + } > + > + err = anx6345_dp_link_training(anx6345); > + if (err) { > + DRM_ERROR("Failed link training: %d\n", err); > + anx6345_poweroff(anx6345); > + return err; > + } > + > + /* > + * This delay seems to help keep the hardware in a good state. Without > + * it, there are times where it fails silently. > + */ > + usleep_range(10000, 15000); > + > + return 0; > +} > + > +static int anx6345_config_dp_output(struct anx6345 *anx6345) > +{ > + int err; > + > + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG, > + SP_VIDEO_MUTE); > + if (err) > + return err; > + > + /* Enable DP output */ > + err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG, > + SP_VIDEO_EN); > + if (err) > + return err; > + > + /* Force stream valid */ > + err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX], > + SP_DP_SYSTEM_CTRL_BASE + 3, > + SP_STRM_FORCE | SP_STRM_CTRL); > + if (err) > + return err; > + > + return 0; > +} > + > +static int anx6345_get_downstream_info(struct anx6345 *anx6345) > +{ > + u8 value; > + int err; > + > + err = drm_dp_dpcd_readb(&anx6345->aux, DP_SINK_COUNT, &value); > + if (err < 0) { > + DRM_ERROR("Get sink count failed %d\n", err); > + return err; > + } > + > + if (!DP_GET_SINK_COUNT(value)) { > + DRM_ERROR("Downstream disconnected\n"); > + return -EIO; > + } > + > + return 0; > +} > + > +static int anx6345_get_modes(struct drm_connector *connector) > +{ > + struct anx6345 *anx6345 = connector_to_anx6345(connector); > + int err, num_modes = 0; > + bool power_off = false; > + > + mutex_lock(&anx6345->lock); > + > + if (!anx6345->edid) { > + if (!anx6345->powered) { > + anx6345_poweron(anx6345); > + power_off = true; > + } > + > + err = anx6345_get_downstream_info(anx6345); > + if (err) { > + DRM_ERROR("Failed to get downstream info: %d\n", err); > + goto unlock; > + } > + > + anx6345->edid = drm_get_edid(connector, &anx6345->aux.ddc); > + if (!anx6345->edid) > + DRM_ERROR("Failed to read EDID from panel\n"); > + > + err = drm_connector_update_edid_property(connector, > + anx6345->edid); > + if (err) { > + DRM_ERROR("Failed to update EDID property: %d\n", err); > + goto unlock; > + } > + } > + > + num_modes += drm_add_edid_modes(connector, anx6345->edid); > + > +unlock: > + if (power_off) > + anx6345_poweroff(anx6345); > + > + mutex_unlock(&anx6345->lock); > + > + if (!num_modes && anx6345->panel) > + num_modes += drm_panel_get_modes(anx6345->panel); > + > + return num_modes; > +} > + > +static const struct drm_connector_helper_funcs anx6345_connector_helper_funcs = { > + .get_modes = anx6345_get_modes, > +}; > + > +static void > +anx6345_connector_destroy(struct drm_connector *connector) > +{ > + struct anx6345 *anx6345 = connector_to_anx6345(connector); > + > + if (anx6345->panel) > + drm_panel_detach(anx6345->panel); > + drm_connector_cleanup(connector); > +} > + > +static const struct drm_connector_funcs anx6345_connector_funcs = { > + .fill_modes = drm_helper_probe_single_connector_modes, > + .destroy = anx6345_connector_destroy, > + .reset = drm_atomic_helper_connector_reset, > + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, > + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, > +}; > + > +static int anx6345_bridge_attach(struct drm_bridge *bridge) > +{ > + struct anx6345 *anx6345 = bridge_to_anx6345(bridge); > + int err; > + > + if (!bridge->encoder) { > + DRM_ERROR("Parent encoder object not found"); > + return -ENODEV; > + } > + > + /* Register aux channel */ > + anx6345->aux.name = "DP-AUX"; > + anx6345->aux.dev = &anx6345->client->dev; > + anx6345->aux.transfer = anx6345_aux_transfer; > + > + err = drm_dp_aux_register(&anx6345->aux); > + if (err < 0) { > + DRM_ERROR("Failed to register aux channel: %d\n", err); > + return err; > + } > + > + err = drm_connector_init(bridge->dev, &anx6345->connector, > + &anx6345_connector_funcs, > + DRM_MODE_CONNECTOR_eDP); > + if (err) { > + DRM_ERROR("Failed to initialize connector: %d\n", err); > + return err; > + } > + > + drm_connector_helper_add(&anx6345->connector, > + &anx6345_connector_helper_funcs); > + > + err = drm_connector_register(&anx6345->connector); > + if (err) { > + DRM_ERROR("Failed to register connector: %d\n", err); > + return err; > + } > + > + anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD; > + > + err = drm_connector_attach_encoder(&anx6345->connector, > + bridge->encoder); > + if (err) { > + DRM_ERROR("Failed to link up connector to encoder: %d\n", err); > + return err; > + } > + > + if (anx6345->panel) { > + err = drm_panel_attach(anx6345->panel, &anx6345->connector); > + if (err) { > + DRM_ERROR("Failed to attach panel: %d\n", err); > + return err; > + } > + } > + > + return 0; > +} > + > +static enum drm_mode_status > +anx6345_bridge_mode_valid(struct drm_bridge *bridge, > + const struct drm_display_mode *mode) > +{ > + if (mode->flags & DRM_MODE_FLAG_INTERLACE) > + return MODE_NO_INTERLACE; > + > + /* Max 1200p at 5.4 Ghz, one lane */ > + if (mode->clock > 154000) > + return MODE_CLOCK_HIGH; I wonder if you shouldn't take into account training results here, ie. training perfrormed before validation. > + > + return MODE_OK; > +} > + > +static void anx6345_bridge_disable(struct drm_bridge *bridge) > +{ > + struct anx6345 *anx6345 = bridge_to_anx6345(bridge); > + > + /* Power off all modules except configuration registers access */ > + anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG, > + SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD); > + if (anx6345->panel) > + drm_panel_disable(anx6345->panel); > + > + if (anx6345->powered) > + anx6345_poweroff(anx6345); > +} > + > +static void anx6345_bridge_enable(struct drm_bridge *bridge) > +{ > + struct anx6345 *anx6345 = bridge_to_anx6345(bridge); > + int err; > + > + if (anx6345->panel) > + drm_panel_enable(anx6345->panel); > + > + err = anx6345_start(anx6345); > + if (err) { > + DRM_ERROR("Failed to initialize: %d\n", err); > + return; > + } > + > + err = anx6345_config_dp_output(anx6345); > + if (err) > + DRM_ERROR("Failed to enable DP output: %d\n", err); > +} > + > +static const struct drm_bridge_funcs anx6345_bridge_funcs = { > + .attach = anx6345_bridge_attach, > + .mode_valid = anx6345_bridge_mode_valid, > + .disable = anx6345_bridge_disable, > + .enable = anx6345_bridge_enable, > +}; > + > +static void unregister_i2c_dummy_clients(struct anx6345 *anx6345) > +{ > + unsigned int i; > + > + for (i = 1; i < ARRAY_SIZE(anx6345->i2c_clients); i++) > + if (anx6345->i2c_clients[i] && > + anx6345->i2c_clients[i]->addr != anx6345->client->addr) > + i2c_unregister_device(anx6345->i2c_clients[i]); > +} > + > +static const struct regmap_config anx6345_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > + .max_register = 0xff, > + .cache_type = REGCACHE_NONE, > +}; > + > +static const u16 anx6345_chipid_list[] = { > + 0x6345, > +}; > + > +static bool anx6345_get_chip_id(struct anx6345 *anx6345) > +{ > + unsigned int i, idl, idh, version; > + > + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG, &idl)) > + return false; > + > + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG, &idh)) > + return false; > + > + anx6345->chipid = (u8)idl | ((u8)idh << 8); > + > + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG, > + &version)) > + return false; > + > + for (i = 0; i < ARRAY_SIZE(anx6345_chipid_list); i++) { > + if (anx6345->chipid == anx6345_chipid_list[i]) { > + DRM_INFO("Found ANX%x (ver. %d) eDP Transmitter\n", > + anx6345->chipid, version); > + return true; > + } > + } > + > + DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n", > + anx6345->chipid, version); > + > + return false; > +} > + > +static int anx6345_i2c_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct anx6345 *anx6345; > + struct device *dev; > + int i, err; > + > + anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL); > + if (!anx6345) > + return -ENOMEM; > + > + mutex_init(&anx6345->lock); > + > + anx6345->bridge.of_node = client->dev.of_node; > + > + anx6345->client = client; > + i2c_set_clientdata(client, anx6345); > + > + dev = &anx6345->client->dev; > + > + err = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0, > + &anx6345->panel, NULL); > + if (err == -EPROBE_DEFER) > + return err; > + > + if (err) > + DRM_DEBUG("No panel found\n"); > + > + /* 1.2V digital core power regulator */ > + anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply"); > + if (IS_ERR(anx6345->dvdd12)) { > + DRM_ERROR("dvdd12-supply not found\n"); > + return PTR_ERR(anx6345->dvdd12); > + } > + > + /* 2.5V digital core power regulator */ > + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply"); > + if (IS_ERR(anx6345->dvdd25)) { > + DRM_ERROR("dvdd25-supply not found\n"); > + return PTR_ERR(anx6345->dvdd25); > + } > + > + /* GPIO for chip reset */ > + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); Shouldn't be set to GPIOD_OUT_HIGH? > + if (IS_ERR(anx6345->gpiod_reset)) { > + DRM_ERROR("Reset gpio not found\n"); > + return PTR_ERR(anx6345->gpiod_reset); > + } > + > + /* Map slave addresses of ANX6345 */ > + for (i = 0; i < I2C_NUM_ADDRESSES; i++) { > + if (anx6345_i2c_addresses[i] >> 1 != client->addr) > + anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter, > + anx6345_i2c_addresses[i] >> 1); > + else > + anx6345->i2c_clients[i] = client; > + > + if (!anx6345->i2c_clients[i]) { > + err = -ENOMEM; > + DRM_ERROR("Failed to reserve I2C bus %02x\n", > + anx6345_i2c_addresses[i]); > + goto err_unregister_i2c; > + } > + > + anx6345->map[i] = devm_regmap_init_i2c(anx6345->i2c_clients[i], > + &anx6345_regmap_config); > + if (IS_ERR(anx6345->map[i])) { > + err = PTR_ERR(anx6345->map[i]); > + DRM_ERROR("Failed regmap initialization %02x\n", > + anx6345_i2c_addresses[i]); > + goto err_unregister_i2c; > + } > + } > + > + /* Look for supported chip ID */ > + anx6345_poweron(anx6345); > + if (anx6345_get_chip_id(anx6345)) { > + anx6345->bridge.funcs = &anx6345_bridge_funcs; > + drm_bridge_add(&anx6345->bridge); > + > + return 0; > + } else { > + anx6345_poweroff(anx6345); > + err = -ENODEV; > + } > + > +err_unregister_i2c: > + unregister_i2c_dummy_clients(anx6345); > + return err; > +} > + > +static int anx6345_i2c_remove(struct i2c_client *client) > +{ > + struct anx6345 *anx6345 = i2c_get_clientdata(client); > + > + drm_bridge_remove(&anx6345->bridge); > + > + unregister_i2c_dummy_clients(anx6345); > + > + kfree(anx6345->edid); > + > + mutex_destroy(&anx6345->lock); > + > + return 0; > +} > + > +static const struct i2c_device_id anx6345_id[] = { > + { "anx6345", 0 }, > + { /* sentinel */ } > +}; > +MODULE_DEVICE_TABLE(i2c, anx6345_id); > + > +static const struct of_device_id anx6345_match_table[] = { > + { .compatible = "analogix,anx6345", }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, anx6345_match_table); > + > +static struct i2c_driver anx6345_driver = { > + .driver = { > + .name = "anx6345", > + .of_match_table = of_match_ptr(anx6345_match_table), > + }, > + .probe = anx6345_i2c_probe, > + .remove = anx6345_i2c_remove, > + .id_table = anx6345_id, > +}; > +module_i2c_driver(anx6345_driver); > + > +MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver"); > +MODULE_AUTHOR("Enric Balletbo i Serra <enric.balletbo@collabora.com>"); Submitter, patch author, and module author are different, this can be correct, but maybe somebody forgot to update some of these fields. Regards Andrzej > +MODULE_LICENSE("GPL v2");
On 07.06.2019 11:40, Torsten Duwe wrote: > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote: >> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote: >>> If think valid compatible properties would be: >>> compatible = "innolux,n116bge", "simple-panel"; >>> compatible = "edp-connector", "simple-panel"; >> A connector isn't a panel. >> >>> compatible = "innolux,n116bge", "edp-connector", "simple-panel"; >> And the innolux,n116bge is certainly not a connector either. >> >>> compatible = "edp-connector", "innolux,n116bge", "simple-panel"; >>> >>> I can't make up my mind which one I prefere. However neither of these >>> variants requires actually implmenting an edp-connector driver. >> No-one asked to do an edp-connector driver. You should use it in your >> DT, but if you want to have some code in your driver that parses the >> DT directly, I'm totally fine with that. > I must admit I fail to understand what that extra node would be good for. > Logically, the eDP far side is connected to the well-known n116bge. > Inside the laptop case it might as well be a flat ribbon cable or > soldered directly. > In good intention, that's all I wanted to express in the DT. I don't > know whether the relevant mechanical dimensions of the panel and the > connector are standardised, so whether one could in theory assemble it > with a different panel than the one it came with. > > OTOH, as I checked during the discussion with anarsoul, the panel's > supply voltage is permanently connected to the main 3.3V rail. > We already agreed that the eDP output port must not neccessarily be > specified, this setup is a good example why: because the panel is > always powered, the anx6345 can always pull valid EDID data from it > so at this stage there's no need for any OS driver to reach beyond > the bridge. IIRC even the backlight got switched off for the blank > screen without. > > All I wanted to say is that "there's usually an n116bge behind it"; > but this is mostly redundant. > > So, shall we just drop the output port specification (along with the > panel node) in order to get one step further? I am not sure if I understand whole discussion here, but I also do not understand whole edp-connector thing. According to VESA[1] eDP is "Internal display interface" - there is no external connector for eDP, the way it is connected is integrator's decision, but it is fixed - ie end user do not plug/unplug it. If I remember correctly in some boards eDP is connected to some DP connector (odroid xu3 if I remember correctly), but this is non-standard hack, and for this case in bindings there should be rather dp-connector not edp-connector. [1]: https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf Regards Andrzej > >> I guess you should describe why do you think it's "clear", because I'm >> not sure this is obvious for everyone here. eDP allows to discover >> which device is on the other side and its supported timings, just like >> HDMI for example (or regular DP, for that matter). Would you think >> it's clearly preferable to ship a DT with the DP/HDMI monitor >> connected on the other side exposed as a panel as well? > Well, as I wrote: "in good intention". That's the panel that comes with > the kit but it is very well detected automatically, just like you describe. > > So, just leave it out? > > Torsten > > >
On 04.06.2019 14:22, Torsten Duwe wrote: > From: Icenowy Zheng <icenowy@aosc.io> > > As ANA78xx chips are designed and produced by Analogix Semiconductor, > Inc, move their driver codes into analogix subdirectory. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Signed-off-by: Torsten Duwe <duwe@suse.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> -- Regards Andrzej > --- > drivers/gpu/drm/bridge/Kconfig | 10 ---------- > drivers/gpu/drm/bridge/Makefile | 4 ++-- > drivers/gpu/drm/bridge/analogix/Kconfig | 10 ++++++++++ > drivers/gpu/drm/bridge/analogix/Makefile | 1 + > drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0 > drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h | 0 > 6 files changed, 13 insertions(+), 12 deletions(-) > rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%) > rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index ee777469293a..862789bf64a0 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -16,16 +16,6 @@ config DRM_PANEL_BRIDGE > menu "Display Interface Bridges" > depends on DRM && DRM_BRIDGE > > -config DRM_ANALOGIX_ANX78XX > - tristate "Analogix ANX78XX bridge" > - select DRM_KMS_HELPER > - select REGMAP_I2C > - ---help--- > - ANX78XX is an ultra-low Full-HD SlimPort transmitter > - designed for portable devices. The ANX78XX transforms > - the HDMI output of an application processor to MyDP > - or DisplayPort. > - > config DRM_CDNS_DSI > tristate "Cadence DPI/DSI bridge" > select DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 4934fcf5a6f8..a6c7dd7727ea 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,5 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > -obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > @@ -12,8 +11,9 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o > obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > -obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > + > +obj-y += analogix/ > obj-y += synopsys/ > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig > index e930ff9b5cd4..704fb0f41dc3 100644 > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > @@ -1,4 +1,14 @@ > # SPDX-License-Identifier: GPL-2.0-only > +config DRM_ANALOGIX_ANX78XX > + tristate "Analogix ANX78XX bridge" > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + ANX78XX is an ultra-low Full-HD SlimPort transmitter > + designed for portable devices. The ANX78XX transforms > + the HDMI output of an application processor to MyDP > + or DisplayPort. > + > config DRM_ANALOGIX_DP > tristate > depends on DRM > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile > index fdbf3fd2f087..6fcbfd3ee560 100644 > --- a/drivers/gpu/drm/bridge/analogix/Makefile > +++ b/drivers/gpu/drm/bridge/analogix/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0-only > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o > +obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > similarity index 100% > rename from drivers/gpu/drm/bridge/analogix-anx78xx.c > rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h > similarity index 100% > rename from drivers/gpu/drm/bridge/analogix-anx78xx.h > rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
Hi, On Wed, Jun 12, 2019 at 12:00:21PM +0200, Andrzej Hajda wrote: > On 07.06.2019 11:40, Torsten Duwe wrote: > > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote: > >> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote: > >>> If think valid compatible properties would be: > >>> compatible = "innolux,n116bge", "simple-panel"; > >>> compatible = "edp-connector", "simple-panel"; > >> A connector isn't a panel. > >> > >>> compatible = "innolux,n116bge", "edp-connector", "simple-panel"; > >> And the innolux,n116bge is certainly not a connector either. > >> > >>> compatible = "edp-connector", "innolux,n116bge", "simple-panel"; > >>> > >>> I can't make up my mind which one I prefere. However neither of these > >>> variants requires actually implmenting an edp-connector driver. > >> No-one asked to do an edp-connector driver. You should use it in your > >> DT, but if you want to have some code in your driver that parses the > >> DT directly, I'm totally fine with that. > > I must admit I fail to understand what that extra node would be good for. > > Logically, the eDP far side is connected to the well-known n116bge. > > Inside the laptop case it might as well be a flat ribbon cable or > > soldered directly. > > In good intention, that's all I wanted to express in the DT. I don't > > know whether the relevant mechanical dimensions of the panel and the > > connector are standardised, so whether one could in theory assemble it > > with a different panel than the one it came with. > > > > OTOH, as I checked during the discussion with anarsoul, the panel's > > supply voltage is permanently connected to the main 3.3V rail. > > We already agreed that the eDP output port must not neccessarily be > > specified, this setup is a good example why: because the panel is > > always powered, the anx6345 can always pull valid EDID data from it > > so at this stage there's no need for any OS driver to reach beyond > > the bridge. IIRC even the backlight got switched off for the blank > > screen without. > > > > All I wanted to say is that "there's usually an n116bge behind it"; > > but this is mostly redundant. > > > > So, shall we just drop the output port specification (along with the > > panel node) in order to get one step further? > > I am not sure if I understand whole discussion here, but I also do not > understand whole edp-connector thing. The context is this one: https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1 https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1 https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2 TL;DR: This bridge is being used on ARM laptops that can come with different eDP panels. Some of these panels require a regulator to be enabled for the panel to work, and this is obviously something that should be in the DT. However, we can't really describe the panel itself, since the vendor uses several of them and just relies on the eDP bus to do its job at retrieving the EDIDs. A generic panel isn't really working either since that would mean having a generic behaviour for all the panels connected to that bus, which isn't there either. The connector allows to expose this nicely. > According to VESA[1] eDP is "Internal display interface" - there is no > external connector for eDP, the way it is connected is integrator's > decision, but it is fixed - ie end user do not plug/unplug it. I'm not sure if you mean DRM or DT connector here though. In DRM, we're doing this all the time for panels. I'm literaly typing this from a laptop that has a screen with an eDP connector. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, Jun 07, 2019 at 11:40:30AM +0200, Torsten Duwe wrote: > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote: > > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote: > > > > > > If think valid compatible properties would be: > > > compatible = "innolux,n116bge", "simple-panel"; > > > compatible = "edp-connector", "simple-panel"; > > > > A connector isn't a panel. > > > > > compatible = "innolux,n116bge", "edp-connector", "simple-panel"; > > > > And the innolux,n116bge is certainly not a connector either. > > > > > compatible = "edp-connector", "innolux,n116bge", "simple-panel"; > > > > > > I can't make up my mind which one I prefere. However neither of these > > > variants requires actually implmenting an edp-connector driver. > > > > No-one asked to do an edp-connector driver. You should use it in your > > DT, but if you want to have some code in your driver that parses the > > DT directly, I'm totally fine with that. > > I must admit I fail to understand what that extra node would be good for. > Logically, the eDP far side is connected to the well-known n116bge. > Inside the laptop case it might as well be a flat ribbon cable or > soldered directly. > In good intention, that's all I wanted to express in the DT. I don't > know whether the relevant mechanical dimensions of the panel and the > connector are standardised, so whether one could in theory assemble it > with a different panel than the one it came with. Because the panel that comes with the Teres-I is always the same. However, that's not true for all the devices out there using the bridge, starting with the pinebook. > OTOH, as I checked during the discussion with anarsoul, the panel's > supply voltage is permanently connected to the main 3.3V rail. Again, that may be the case on the Teres-I, but not necessarily on other boards. > We already agreed that the eDP output port must not neccessarily be > specified, this setup is a good example why: because the panel is > always powered, the anx6345 can always pull valid EDID data from it > so at this stage there's no need for any OS driver to reach beyond > the bridge. IIRC even the backlight got switched off for the blank > screen without. That's not really the outcome of the discussion we had here though: https://patchwork.freedesktop.org/patch/305035/ > All I wanted to say is that "there's usually an n116bge behind it"; > but this is mostly redundant. > > So, shall we just drop the output port specification (along with the > panel node) in order to get one step further? Depending on the outcome of the discussion above, yes or no :) Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Hi Maxime, It seems I have missed your response. On 12.06.2019 17:20, Maxime Ripard wrote: >> I am not sure if I understand whole discussion here, but I also do not >> understand whole edp-connector thing. > The context is this one: > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1 > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1 > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2 > > TL;DR: This bridge is being used on ARM laptops that can come with > different eDP panels. Some of these panels require a regulator to be > enabled for the panel to work, and this is obviously something that > should be in the DT. > > However, we can't really describe the panel itself, since the vendor > uses several of them and just relies on the eDP bus to do its job at > retrieving the EDIDs. A generic panel isn't really working either > since that would mean having a generic behaviour for all the panels > connected to that bus, which isn't there either. > > The connector allows to expose this nicely. As VESA presentation says[1] eDP is based on DP but is much more flexible, it is up to integrator (!!!) how the connection, power up/down, initialization sequence should be performed. Trying to cover every such case in edp-connector seems to me similar to panel-simple attempt failure. Moreover there is no such thing as physical standard eDP connector. Till now I though DT connector should describe physical connector on the device, now I am lost, are there some DT bindings guidelines about definition of a connector? Maybe instead of edp-connector one would introduce integrator's specific connector, for example with compatible "olimex,teres-edp-connector" which should follow edp abstract connector rules? This will be at least consistent with below presentation[1] - eDP requirements depends on integrator. Then if olimex has standard way of dealing with panels present in olimex/teres platforms the driver would then create drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. Anyway it still looks fishy for me :), maybe because I am not familiarized with details of these platforms. [1]: https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf > >> According to VESA[1] eDP is "Internal display interface" - there is no >> external connector for eDP, the way it is connected is integrator's >> decision, but it is fixed - ie end user do not plug/unplug it. > I'm not sure if you mean DRM or DT connector here though. In DRM, > we're doing this all the time for panels. I'm literaly typing this > from a laptop that has a screen with an eDP connector. VESA describes only hardware, but since DT also describes hardware I guess it should be similar. Regards Andrzej > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Hi! On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote: > On 12.06.2019 17:20, Maxime Ripard wrote: > >> I am not sure if I understand whole discussion here, but I also do not > >> understand whole edp-connector thing. > > The context is this one: > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1 > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1 > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2 > > > > TL;DR: This bridge is being used on ARM laptops that can come with > > different eDP panels. Some of these panels require a regulator to be > > enabled for the panel to work, and this is obviously something that > > should be in the DT. > > > > However, we can't really describe the panel itself, since the vendor > > uses several of them and just relies on the eDP bus to do its job at > > retrieving the EDIDs. A generic panel isn't really working either > > since that would mean having a generic behaviour for all the panels > > connected to that bus, which isn't there either. > > > > The connector allows to expose this nicely. > > As VESA presentation says[1] eDP is based on DP but is much more > flexible, it is up to integrator (!!!) how the connection, power > up/down, initialization sequence should be performed. Trying to cover > every such case in edp-connector seems to me similar to panel-simple > attempt failure. Moreover there is no such thing as physical standard > eDP connector. Till now I though DT connector should describe physical > connector on the device, now I am lost, are there some DT bindings > guidelines about definition of a connector? This might be semantics but I guess we're in some kind of grey area? Like, for eDP, if it's soldered I guess we could say that there's no connector. But what happens if for some other board, that signal is routed through a ribbon? You could argue that there's no physical connector in both cases, or that there's one in both, or one for the ribbon and no connector for the one soldered in. > Maybe instead of edp-connector one would introduce integrator's specific > connector, for example with compatible "olimex,teres-edp-connector" > which should follow edp abstract connector rules? This will be at least > consistent with below presentation[1] - eDP requirements depends on > integrator. Then if olimex has standard way of dealing with panels > present in olimex/teres platforms the driver would then create > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > Anyway it still looks fishy for me :), maybe because I am not > familiarized with details of these platforms. That makes sense yes Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On 01.07.2019 11:58, Maxime Ripard wrote: > Hi! > > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote: >> On 12.06.2019 17:20, Maxime Ripard wrote: >>>> I am not sure if I understand whole discussion here, but I also do not >>>> understand whole edp-connector thing. >>> The context is this one: >>> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1 >>> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1 >>> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2 >>> >>> TL;DR: This bridge is being used on ARM laptops that can come with >>> different eDP panels. Some of these panels require a regulator to be >>> enabled for the panel to work, and this is obviously something that >>> should be in the DT. >>> >>> However, we can't really describe the panel itself, since the vendor >>> uses several of them and just relies on the eDP bus to do its job at >>> retrieving the EDIDs. A generic panel isn't really working either >>> since that would mean having a generic behaviour for all the panels >>> connected to that bus, which isn't there either. >>> >>> The connector allows to expose this nicely. >> As VESA presentation says[1] eDP is based on DP but is much more >> flexible, it is up to integrator (!!!) how the connection, power >> up/down, initialization sequence should be performed. Trying to cover >> every such case in edp-connector seems to me similar to panel-simple >> attempt failure. Moreover there is no such thing as physical standard >> eDP connector. Till now I though DT connector should describe physical >> connector on the device, now I am lost, are there some DT bindings >> guidelines about definition of a connector? > This might be semantics but I guess we're in some kind of grey area? > > Like, for eDP, if it's soldered I guess we could say that there's no > connector. But what happens if for some other board, that signal is > routed through a ribbon? > > You could argue that there's no physical connector in both cases, or > that there's one in both, or one for the ribbon and no connector for > the one soldered in. This is not about ribbon vs soldering. It is about usage: this connection is static across the whole life of the device (except exceptional things: repair, non-standard usage, etc). And "the real connector" is (at least for me) something where end-user can connect/disconnect different things: USB, HDMI, ethernet, etc. And obviously to be functional it should be somehow standardized. So even if there could be some grey area, I do not see it here. > >> Maybe instead of edp-connector one would introduce integrator's specific >> connector, for example with compatible "olimex,teres-edp-connector" >> which should follow edp abstract connector rules? This will be at least >> consistent with below presentation[1] - eDP requirements depends on >> integrator. Then if olimex has standard way of dealing with panels >> present in olimex/teres platforms the driver would then create >> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. >> Anyway it still looks fishy for me :), maybe because I am not >> familiarized with details of these platforms. > That makes sense yes And what if some panel can be used with this pseudo-connecter and in some different hw directly? Code duplication? DT overlays? Regards Andrzej > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Mon, Jul 01, 2019 at 02:27:51PM +0200, Andrzej Hajda wrote: > On 01.07.2019 11:58, Maxime Ripard wrote: > > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote: > >> On 12.06.2019 17:20, Maxime Ripard wrote: > >>>> I am not sure if I understand whole discussion here, but I also do not > >>>> understand whole edp-connector thing. > >>> The context is this one: > >>> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1 > >>> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1 > >>> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2 > >>> > >>> TL;DR: This bridge is being used on ARM laptops that can come with > >>> different eDP panels. Some of these panels require a regulator to be > >>> enabled for the panel to work, and this is obviously something that > >>> should be in the DT. > >>> > >>> However, we can't really describe the panel itself, since the vendor > >>> uses several of them and just relies on the eDP bus to do its job at > >>> retrieving the EDIDs. A generic panel isn't really working either > >>> since that would mean having a generic behaviour for all the panels > >>> connected to that bus, which isn't there either. > >>> > >>> The connector allows to expose this nicely. > >> As VESA presentation says[1] eDP is based on DP but is much more > >> flexible, it is up to integrator (!!!) how the connection, power > >> up/down, initialization sequence should be performed. Trying to cover > >> every such case in edp-connector seems to me similar to panel-simple > >> attempt failure. Moreover there is no such thing as physical standard > >> eDP connector. Till now I though DT connector should describe physical > >> connector on the device, now I am lost, are there some DT bindings > >> guidelines about definition of a connector? > > This might be semantics but I guess we're in some kind of grey area? > > > > Like, for eDP, if it's soldered I guess we could say that there's no > > connector. But what happens if for some other board, that signal is > > routed through a ribbon? > > > > You could argue that there's no physical connector in both cases, or > > that there's one in both, or one for the ribbon and no connector for > > the one soldered in. > > This is not about ribbon vs soldering. It is about usage: this > connection is static across the whole life of the device (except > exceptional things: repair, non-standard usage, etc). It doesn't have to be. > And "the real connector" is (at least for me) something where > end-user can connect/disconnect different things: USB, HDMI, > ethernet, etc. And obviously to be functional it should be somehow > standardized. So even if there could be some grey area, I do not see > it here. Well, if there's a ribbon connector, then you have a physical connector, with the end user being able to connect / disconnect various displays. It might not be the case with actual products, but it's pretty common with SBCs to have that signal routed through a connector, and the user has several options to connect a display to it. The line really is blurred. > >> Maybe instead of edp-connector one would introduce integrator's specific > >> connector, for example with compatible "olimex,teres-edp-connector" > >> which should follow edp abstract connector rules? This will be at least > >> consistent with below presentation[1] - eDP requirements depends on > >> integrator. Then if olimex has standard way of dealing with panels > >> present in olimex/teres platforms the driver would then create > >> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > >> Anyway it still looks fishy for me :), maybe because I am not > >> familiarized with details of these platforms. > > > That makes sense yes > > And what if some panel can be used with this pseudo-connecter and in > some different hw directly? Code duplication? DT overlays? Overlays are a solution, but I would advocate to always have the connector. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > Hi! > > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote: > > On 12.06.2019 17:20, Maxime Ripard wrote: > > >> I am not sure if I understand whole discussion here, but I also do not > > >> understand whole edp-connector thing. > > > The context is this one: > > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1 > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1 > > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2 > > > > > > TL;DR: This bridge is being used on ARM laptops that can come with > > > different eDP panels. Some of these panels require a regulator to be > > > enabled for the panel to work, and this is obviously something that > > > should be in the DT. > > > > > > However, we can't really describe the panel itself, since the vendor > > > uses several of them and just relies on the eDP bus to do its job at > > > retrieving the EDIDs. A generic panel isn't really working either > > > since that would mean having a generic behaviour for all the panels > > > connected to that bus, which isn't there either. > > > > > > The connector allows to expose this nicely. > > > > As VESA presentation says[1] eDP is based on DP but is much more > > flexible, it is up to integrator (!!!) how the connection, power > > up/down, initialization sequence should be performed. Trying to cover > > every such case in edp-connector seems to me similar to panel-simple > > attempt failure. Moreover there is no such thing as physical standard > > eDP connector. Till now I though DT connector should describe physical > > connector on the device, now I am lost, are there some DT bindings > > guidelines about definition of a connector? > > This might be semantics but I guess we're in some kind of grey area? > > Like, for eDP, if it's soldered I guess we could say that there's no > connector. But what happens if for some other board, that signal is > routed through a ribbon? > > You could argue that there's no physical connector in both cases, or > that there's one in both, or one for the ribbon and no connector for > the one soldered in. > > > Maybe instead of edp-connector one would introduce integrator's specific > > connector, for example with compatible "olimex,teres-edp-connector" > > which should follow edp abstract connector rules? This will be at least > > consistent with below presentation[1] - eDP requirements depends on > > integrator. Then if olimex has standard way of dealing with panels > > present in olimex/teres platforms the driver would then create > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > Anyway it still looks fishy for me :), maybe because I am not > > familiarized with details of these platforms. > > That makes sense yes Actually, it makes no sense at all. Current implementation for anx6345 driver works fine as is with any panel specified assuming panel delays are long enough for connected panel. It just doesn't use panel timings from the driver. Creating a platform driver for connector itself looks redundant since it can't be reused, it doesn't describe actual hardware and it's just defeats purpose of DT by introducing board-specific code. There's another issue: if we introduce edp-connector we'll have to specify power up delays somewhere (in dts? or in platform driver?), so edp-connector doesn't really solve the issue of multiple panels with same motherboard. I'd say DT overlays should be preferred solution here, not another connector binding. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > Maybe instead of edp-connector one would introduce integrator's specific > > > connector, for example with compatible "olimex,teres-edp-connector" > > > which should follow edp abstract connector rules? This will be at least > > > consistent with below presentation[1] - eDP requirements depends on > > > integrator. Then if olimex has standard way of dealing with panels > > > present in olimex/teres platforms the driver would then create > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > Anyway it still looks fishy for me :), maybe because I am not > > > familiarized with details of these platforms. > > > > That makes sense yes > > Actually, it makes no sense at all. Current implementation for anx6345 > driver works fine as is with any panel specified assuming panel delays > are long enough for connected panel. It just doesn't use panel timings > from the driver. Creating a platform driver for connector itself looks > redundant since it can't be reused, it doesn't describe actual > hardware and it's just defeats purpose of DT by introducing > board-specific code. I'm not sure where you got the idea that the purpose of DT is to not have any board-specific code. It's perfectly fine to have some, that's even why there's a compatible assigned to each and every board. What the DT is about is allowing us to have a generic behaviour that we can detect: we can have a given behaviour for a given board, and a separate one for another one, and this will be evaluated at runtime. This is *exactly* what this is about: we can have a compatible that sets a given, more specific, behaviour (olimex,teres-edp-connector) while saying that this is compatible with the generic behaviour (edp-connector). That way, any OS will know what quirk to apply if needed, and if not that it can use the generic behaviour. And we could create a generic driver, for the generic behaviour if needed. > There's another issue: if we introduce edp-connector we'll have to > specify power up delays somewhere (in dts? or in platform driver?), so > edp-connector doesn't really solve the issue of multiple panels with > same motherboard. And that's what that compatible is about :) > I'd say DT overlays should be preferred solution here, not another > connector binding. Overlays are a way to apply a device tree dynamically. It's orthogonal to the binding. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到: >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: >> > > Maybe instead of edp-connector one would introduce integrator's >specific >> > > connector, for example with compatible >"olimex,teres-edp-connector" >> > > which should follow edp abstract connector rules? This will be at >least >> > > consistent with below presentation[1] - eDP requirements depends >on >> > > integrator. Then if olimex has standard way of dealing with >panels >> > > present in olimex/teres platforms the driver would then create >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I >guess. >> > > Anyway it still looks fishy for me :), maybe because I am not >> > > familiarized with details of these platforms. >> > >> > That makes sense yes >> >> Actually, it makes no sense at all. Current implementation for >anx6345 >> driver works fine as is with any panel specified assuming panel >delays >> are long enough for connected panel. It just doesn't use panel >timings >> from the driver. Creating a platform driver for connector itself >looks >> redundant since it can't be reused, it doesn't describe actual >> hardware and it's just defeats purpose of DT by introducing >> board-specific code. > >I'm not sure where you got the idea that the purpose of DT is to not >have any board-specific code. > >It's perfectly fine to have some, that's even why there's a compatible >assigned to each and every board. > >What the DT is about is allowing us to have a generic behaviour that >we can detect: we can have a given behaviour for a given board, and a >separate one for another one, and this will be evaluated at runtime. > >This is *exactly* what this is about: we can have a compatible that >sets a given, more specific, behaviour (olimex,teres-edp-connector) >while saying that this is compatible with the generic behaviour >(edp-connector). That way, any OS will know what quirk to apply if >needed, and if not that it can use the generic behaviour. > >And we could create a generic driver, for the generic behaviour if >needed. > >> There's another issue: if we introduce edp-connector we'll have to >> specify power up delays somewhere (in dts? or in platform driver?), >so >> edp-connector doesn't really solve the issue of multiple panels with >> same motherboard. > >And that's what that compatible is about :) Maybe we can introduce a connector w/o any driver just like hdmi-connector? > >> I'd say DT overlays should be preferred solution here, not another >> connector binding. > >Overlays are a way to apply a device tree dynamically. It's orthogonal >to the binding. > >Maxime > >-- >Maxime Ripard, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com
On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote: > > > 于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到: > >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > >> > > Maybe instead of edp-connector one would introduce integrator's > >specific > >> > > connector, for example with compatible > >"olimex,teres-edp-connector" > >> > > which should follow edp abstract connector rules? This will be at > >least > >> > > consistent with below presentation[1] - eDP requirements depends > >on > >> > > integrator. Then if olimex has standard way of dealing with > >panels > >> > > present in olimex/teres platforms the driver would then create > >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I > >guess. > >> > > Anyway it still looks fishy for me :), maybe because I am not > >> > > familiarized with details of these platforms. > >> > > >> > That makes sense yes > >> > >> Actually, it makes no sense at all. Current implementation for > >anx6345 > >> driver works fine as is with any panel specified assuming panel > >delays > >> are long enough for connected panel. It just doesn't use panel > >timings > >> from the driver. Creating a platform driver for connector itself > >looks > >> redundant since it can't be reused, it doesn't describe actual > >> hardware and it's just defeats purpose of DT by introducing > >> board-specific code. > > > >I'm not sure where you got the idea that the purpose of DT is to not > >have any board-specific code. > > > >It's perfectly fine to have some, that's even why there's a compatible > >assigned to each and every board. > > > >What the DT is about is allowing us to have a generic behaviour that > >we can detect: we can have a given behaviour for a given board, and a > >separate one for another one, and this will be evaluated at runtime. > > > >This is *exactly* what this is about: we can have a compatible that > >sets a given, more specific, behaviour (olimex,teres-edp-connector) > >while saying that this is compatible with the generic behaviour > >(edp-connector). That way, any OS will know what quirk to apply if > >needed, and if not that it can use the generic behaviour. > > > >And we could create a generic driver, for the generic behaviour if > >needed. > > > >> There's another issue: if we introduce edp-connector we'll have to > >> specify power up delays somewhere (in dts? or in platform driver?), > >so > >> edp-connector doesn't really solve the issue of multiple panels with > >> same motherboard. > > > >And that's what that compatible is about :) > > Maybe we can introduce a connector w/o any driver just like hdmi-connector? Ironically, a driver for it has been sent yesterday :) But yeah, we can definitely do that too. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > which should follow edp abstract connector rules? This will be at least > > > > consistent with below presentation[1] - eDP requirements depends on > > > > integrator. Then if olimex has standard way of dealing with panels > > > > present in olimex/teres platforms the driver would then create > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > familiarized with details of these platforms. > > > > > > That makes sense yes > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > driver works fine as is with any panel specified assuming panel delays > > are long enough for connected panel. It just doesn't use panel timings > > from the driver. Creating a platform driver for connector itself looks > > redundant since it can't be reused, it doesn't describe actual > > hardware and it's just defeats purpose of DT by introducing > > board-specific code. > > I'm not sure where you got the idea that the purpose of DT is to not > have any board-specific code. I believe DT was an attempt to move to declarative approach for describing hardware. Yes, we have different compatibles for different devices but they're specific to particular device rather than particular board. Device interconnection is described in DT along with some properties rather than in board-specific C-file. Introducing board-specific compatible for a connector isn't looking right to me. > It's perfectly fine to have some, that's even why there's a compatible > assigned to each and every board. > > What the DT is about is allowing us to have a generic behaviour that > we can detect: we can have a given behaviour for a given board, and a > separate one for another one, and this will be evaluated at runtime. > > This is *exactly* what this is about: we can have a compatible that > sets a given, more specific, behaviour (olimex,teres-edp-connector) > while saying that this is compatible with the generic behaviour > (edp-connector). That way, any OS will know what quirk to apply if > needed, and if not that it can use the generic behaviour. > > And we could create a generic driver, for the generic behaviour if > needed. > > > There's another issue: if we introduce edp-connector we'll have to > > specify power up delays somewhere (in dts? or in platform driver?), so > > edp-connector doesn't really solve the issue of multiple panels with > > same motherboard. > > And that's what that compatible is about :) Sorry, I fail to see how it would be different from using existing panels infrastructure and different panels compatibles. I think Rob's idea was to introduce generic edp-connector. If we can't make it generic then let's use panel infrastructure. > > I'd say DT overlays should be preferred solution here, not another > > connector binding. > > Overlays are a way to apply a device tree dynamically. It's orthogonal > to the binding. It isn't orthogonal to original problem though. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote: > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > > which should follow edp abstract connector rules? This will be at least > > > > > consistent with below presentation[1] - eDP requirements depends on > > > > > integrator. Then if olimex has standard way of dealing with panels > > > > > present in olimex/teres platforms the driver would then create > > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > > familiarized with details of these platforms. > > > > > > > > That makes sense yes > > > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > > driver works fine as is with any panel specified assuming panel delays > > > are long enough for connected panel. It just doesn't use panel timings > > > from the driver. Creating a platform driver for connector itself looks > > > redundant since it can't be reused, it doesn't describe actual > > > hardware and it's just defeats purpose of DT by introducing > > > board-specific code. > > > > I'm not sure where you got the idea that the purpose of DT is to not > > have any board-specific code. > > I believe DT was an attempt to move to declarative approach for > describing hardware. Yes, we have different compatibles for different > devices but they're specific to particular device rather than > particular board. Device interconnection is described in DT along with > some properties rather than in board-specific C-file. You're right, but it's not incompatible with having some code to deal with some board quirk. > Introducing board-specific compatible for a connector isn't looking > right to me. If that board has a board-specific behaviour for it's connector, then what's the issue? You can't describe all the quirks in the all boards using purely properties. > > It's perfectly fine to have some, that's even why there's a compatible > > assigned to each and every board. > > > > What the DT is about is allowing us to have a generic behaviour that > > we can detect: we can have a given behaviour for a given board, and a > > separate one for another one, and this will be evaluated at runtime. > > > > This is *exactly* what this is about: we can have a compatible that > > sets a given, more specific, behaviour (olimex,teres-edp-connector) > > while saying that this is compatible with the generic behaviour > > (edp-connector). That way, any OS will know what quirk to apply if > > needed, and if not that it can use the generic behaviour. > > > > And we could create a generic driver, for the generic behaviour if > > needed. > > > > > There's another issue: if we introduce edp-connector we'll have to > > > specify power up delays somewhere (in dts? or in platform driver?), so > > > edp-connector doesn't really solve the issue of multiple panels with > > > same motherboard. > > > > And that's what that compatible is about :) > > Sorry, I fail to see how it would be different from using existing > panels infrastructure and different panels compatibles. I think Rob's > idea was to introduce generic edp-connector. Again, there's no such thing as a generic edp-connector. The spec doesn't define anything related to the power sequence for example. > If we can't make it generic then let's use panel infrastructure. Which uses a device specific compatible. Really, I'm not sure what your objection and / or argument is here. In addition, when that was brought up in the discussion, you rejected it because it was inconvenient: https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 And I agree with you on that one. > > > I'd say DT overlays should be preferred solution here, not another > > > connector binding. > > > > Overlays are a way to apply a device tree dynamically. It's orthogonal > > to the binding. > > It isn't orthogonal to original problem though. It is. The original problem is that you want to power up whatever is on the other side of a eDP link using an arbitrary regulator. This is a "how do I describe that in my DT" problem, and it really has nothing to do with how the DT is being passed to the kernel. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote: > > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > > > which should follow edp abstract connector rules? This will be at least > > > > > > consistent with below presentation[1] - eDP requirements depends on > > > > > > integrator. Then if olimex has standard way of dealing with panels > > > > > > present in olimex/teres platforms the driver would then create > > > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > > > familiarized with details of these platforms. > > > > > > > > > > That makes sense yes > > > > > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > > > driver works fine as is with any panel specified assuming panel delays > > > > are long enough for connected panel. It just doesn't use panel timings > > > > from the driver. Creating a platform driver for connector itself looks > > > > redundant since it can't be reused, it doesn't describe actual > > > > hardware and it's just defeats purpose of DT by introducing > > > > board-specific code. > > > > > > I'm not sure where you got the idea that the purpose of DT is to not > > > have any board-specific code. > > > > I believe DT was an attempt to move to declarative approach for > > describing hardware. Yes, we have different compatibles for different > > devices but they're specific to particular device rather than > > particular board. Device interconnection is described in DT along with > > some properties rather than in board-specific C-file. > > You're right, but it's not incompatible with having some code to deal > with some board quirk. > > > Introducing board-specific compatible for a connector isn't looking > > right to me. > > If that board has a board-specific behaviour for it's connector, then > what's the issue? > > You can't describe all the quirks in the all boards using purely > properties. > > > > It's perfectly fine to have some, that's even why there's a compatible > > > assigned to each and every board. > > > > > > What the DT is about is allowing us to have a generic behaviour that > > > we can detect: we can have a given behaviour for a given board, and a > > > separate one for another one, and this will be evaluated at runtime. > > > > > > This is *exactly* what this is about: we can have a compatible that > > > sets a given, more specific, behaviour (olimex,teres-edp-connector) > > > while saying that this is compatible with the generic behaviour > > > (edp-connector). That way, any OS will know what quirk to apply if > > > needed, and if not that it can use the generic behaviour. > > > > > > And we could create a generic driver, for the generic behaviour if > > > needed. > > > > > > > There's another issue: if we introduce edp-connector we'll have to > > > > specify power up delays somewhere (in dts? or in platform driver?), so > > > > edp-connector doesn't really solve the issue of multiple panels with > > > > same motherboard. > > > > > > And that's what that compatible is about :) > > > > Sorry, I fail to see how it would be different from using existing > > panels infrastructure and different panels compatibles. I think Rob's > > idea was to introduce generic edp-connector. > > Again, there's no such thing as a generic edp-connector. The spec > doesn't define anything related to the power sequence for example. > > > If we can't make it generic then let's use panel infrastructure. > > Which uses a device specific compatible. Really, I'm not sure what > your objection and / or argument is here. > > In addition, when that was brought up in the discussion, you rejected > it because it was inconvenient: > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 It is inconvenient, but I don't understand how having board-specific connectors fixes it. > And I agree with you on that one. > > > > > I'd say DT overlays should be preferred solution here, not another > > > > connector binding. > > > > > > Overlays are a way to apply a device tree dynamically. It's orthogonal > > > to the binding. > > > > It isn't orthogonal to original problem though. > > It is. The original problem is that you want to power up whatever is > on the other side of a eDP link using an arbitrary regulator. > > This is a "how do I describe that in my DT" problem, and it really has > nothing to do with how the DT is being passed to the kernel. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote: > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > > There's another issue: if we introduce edp-connector we'll have to > > > > > specify power up delays somewhere (in dts? or in platform driver?), so > > > > > edp-connector doesn't really solve the issue of multiple panels with > > > > > same motherboard. > > > > > > > > And that's what that compatible is about :) > > > > > > Sorry, I fail to see how it would be different from using existing > > > panels infrastructure and different panels compatibles. I think Rob's > > > idea was to introduce generic edp-connector. > > > > Again, there's no such thing as a generic edp-connector. The spec > > doesn't define anything related to the power sequence for example. > > > > > If we can't make it generic then let's use panel infrastructure. > > > > Which uses a device specific compatible. Really, I'm not sure what > > your objection and / or argument is here. > > > > In addition, when that was brought up in the discussion, you rejected > > it because it was inconvenient: > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 > > It is inconvenient, but I don't understand how having board-specific > connectors fixes it. How it would not fix it? You'll have one connector, without the need to describe each and every panel in the device tree and rely on the EDID instead, and you'll have the option to power up the regulator you need. I really don't understand what's the issue here, so let's take a step back. What are is the issue , what are your requirements, and how would you like that to be described ? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote: > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > > > There's another issue: if we introduce edp-connector we'll have to > > > > > > specify power up delays somewhere (in dts? or in platform driver?), so > > > > > > edp-connector doesn't really solve the issue of multiple panels with > > > > > > same motherboard. > > > > > > > > > > And that's what that compatible is about :) > > > > > > > > Sorry, I fail to see how it would be different from using existing > > > > panels infrastructure and different panels compatibles. I think Rob's > > > > idea was to introduce generic edp-connector. > > > > > > Again, there's no such thing as a generic edp-connector. The spec > > > doesn't define anything related to the power sequence for example. > > > > > > > If we can't make it generic then let's use panel infrastructure. > > > > > > Which uses a device specific compatible. Really, I'm not sure what > > > your objection and / or argument is here. > > > > > > In addition, when that was brought up in the discussion, you rejected > > > it because it was inconvenient: > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 > > > > It is inconvenient, but I don't understand how having board-specific > > connectors fixes it. > > How it would not fix it? I think I got your idea, but yet I think it's not the best solution. Do I understand correctly that you're proposing to introduce board-specific edp-connector driver that will be aware of worst case power up delays and will control backlight and power? Then why not to add another board-specific panel (e.g. "pine64,pinebook-panel") to simple-panel.c that does the same? > You'll have one connector, without the need to describe each and every > panel in the device tree and rely on the EDID instead, and you'll have > the option to power up the regulator you need. > > I really don't understand what's the issue here, so let's take a step > back. What are is the issue , what are your requirements, and how > would you like that to be described ? We have a device (Pinebook) that uses the same board with multiple edp panels. So far there're pinebooks with 3 different panels: 11" with 768p panel, 11" with 1080p panel, 14" with 768p panel. Currently there's no way to describe all pinebooks with a single dts. There's a simple workaround though -- we can just specify a panel with worst power up delays in dts and it'll work since anx6345 driver ignores panel modes anyway and uses EDID. Originally I proposed to extend simple-panel driver to support generic edp-panel but it was rejected. I still believe that it's the best solution assuming we can specify delays in dts, since panels list is specific to particular device and it probably can't be reused, i.e. there's no good reason to move it into C code. Rob Herring proposed to introduce edp-connector. While I still believe that it's not accurate description of hardware since it'll have to have backlight node (backlight is actually panel property) I was OK with this approach assuming we can store delays in dts. Later it evolved into board-specific edp-connector. So far I don't understand why everyone is trying to avoid introducing edp-panel driver that can read delays from dts. Basically, I don't understand what's the magic behind simple-panel.c and why new panels should be added there rather than described in dts. [1] Doesn't explain that. [1] http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html Regards, Vasily > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Wed, Jun 12, 2019 at 11:13:10AM +0200, Andrzej Hajda wrote: > On 04.06.2019 14:23, Torsten Duwe wrote: > > + > > +static void anx6345_poweron(struct anx6345 *anx6345) > > +{ > > + int err; > > + > > + /* Ensure reset is asserted before starting power on sequence */ > > + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1); > > With fixed devm_gpiod_get below this line can be removed. In any case, reset must be asserted for this procedure to succeed... > > +static enum drm_mode_status > > +anx6345_bridge_mode_valid(struct drm_bridge *bridge, > > + const struct drm_display_mode *mode) > > +{ > > + if (mode->flags & DRM_MODE_FLAG_INTERLACE) > > + return MODE_NO_INTERLACE; > > + > > + /* Max 1200p at 5.4 Ghz, one lane */ > > + if (mode->clock > 154000) > > + return MODE_CLOCK_HIGH; > > I wonder if you shouldn't take into account training results here, ie. > training perfrormed before validation. Sure, but this is verbatim from the anx78xx.c sibling, code provided by analogix. Lacking in-depth datasheets, this is probably the best effort. > > + > > + /* 2.5V digital core power regulator */ > > + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply"); > > + if (IS_ERR(anx6345->dvdd25)) { > > + DRM_ERROR("dvdd25-supply not found\n"); > > + return PTR_ERR(anx6345->dvdd25); > > + } > > + > > + /* GPIO for chip reset */ > > + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); > > Shouldn't be set to GPIOD_OUT_HIGH? It used to be in the original submission, and confused even more people ;-) Fact is, the reset for this chip _is_ low active; I'm following Documentation/devicetree/bindings/gpio/gpio.txt, "1.1) GPIO specifier best practices", which I find rather comprehensive. Any suggestions on how to phrase this even better are appreciated. > > +}; > > +module_i2c_driver(anx6345_driver); > > + > > +MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver"); > > +MODULE_AUTHOR("Enric Balletbo i Serra <enric.balletbo@collabora.com>"); > > Submitter, patch author, and module author are different, this can be > correct, but maybe somebody forgot to update some of these fields. As mentioned in the v2 cover letter, I had a closer look on which code got actually introduced and which lines were simply copied around, and made the copyright and authorship stick to where they belong. *I* believe this is correct now; specific improvements welcome. Torsten
On Mon, Jul 15, 2019 at 05:28:53PM -0700, Vasily Khoruzhick wrote: > On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote: > > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > > > > There's another issue: if we introduce edp-connector we'll have to > > > > > > > specify power up delays somewhere (in dts? or in platform driver?), so > > > > > > > edp-connector doesn't really solve the issue of multiple panels with > > > > > > > same motherboard. > > > > > > > > > > > > And that's what that compatible is about :) > > > > > > > > > > Sorry, I fail to see how it would be different from using existing > > > > > panels infrastructure and different panels compatibles. I think Rob's > > > > > idea was to introduce generic edp-connector. > > > > > > > > Again, there's no such thing as a generic edp-connector. The spec > > > > doesn't define anything related to the power sequence for example. > > > > > > > > > If we can't make it generic then let's use panel infrastructure. > > > > > > > > Which uses a device specific compatible. Really, I'm not sure what > > > > your objection and / or argument is here. > > > > > > > > In addition, when that was brought up in the discussion, you rejected > > > > it because it was inconvenient: > > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 > > > > > > It is inconvenient, but I don't understand how having board-specific > > > connectors fixes it. > > > > How it would not fix it? > > I think I got your idea, but yet I think it's not the best solution. > > Do I understand correctly that you're proposing to introduce > board-specific edp-connector driver that will be aware of worst case > power up delays and will control backlight and power? > > Then why not to add another board-specific panel (e.g. > "pine64,pinebook-panel") to simple-panel.c that does the same? That would be fine for me too. Thierry was against it though IIRC, and I don't recall why exactly. > > You'll have one connector, without the need to describe each and every > > panel in the device tree and rely on the EDID instead, and you'll have > > the option to power up the regulator you need. > > > > I really don't understand what's the issue here, so let's take a step > > back. What are is the issue , what are your requirements, and how > > would you like that to be described ? > > We have a device (Pinebook) that uses the same board with multiple edp > panels. So far there're pinebooks with 3 different panels: 11" with > 768p panel, 11" with 1080p panel, 14" with 768p panel. > > Currently there's no way to describe all pinebooks with a single dts. > There's a simple workaround though -- we can just specify a panel with > worst power up delays in dts and it'll work since anx6345 driver > ignores panel modes anyway and uses EDID. > > Originally I proposed to extend simple-panel driver to support generic > edp-panel but it was rejected. I still believe that it's the best > solution assuming we can specify delays in dts, since panels list is > specific to particular device and it probably can't be reused, i.e. > there's no good reason to move it into C code. > > Rob Herring proposed to introduce edp-connector. While I still believe > that it's not accurate description of hardware since it'll have to > have backlight node (backlight is actually panel property) I was OK > with this approach assuming we can store delays in dts. > > Later it evolved into board-specific edp-connector. I think you got that wrong. As far as I'm concerned, the plan was to have two compatibles: the board-specific one, and the generic one. Something like compatible = "pine64,pinebook-edp-connector", "edp-connector"; or whatever. > So far I don't understand why everyone is trying to avoid introducing > edp-panel driver that can read delays from dts. Basically, I don't > understand what's the magic behind simple-panel.c and why new panels > should be added there rather than described in dts. [1] Doesn't > explain that. So others might have different viewpoints here as well, but the major downside I see in putting those kind of values in the device tree is that at some point, someone will get it wrong, and chances are that even for the same panel, everyone will use a slightly different set of timings. And once it's wrong, then it's a mess to fix. You have to track down every DT using it, make sure it's corrected, and then every user will have to change their DT in their system. Whereas if you have just a compatible and those timings in the kernel, then the only thing required is a kernel update, which should be a pretty standard operation. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com