linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
@ 2016-06-20  7:14 Nicolas Boichat
  2016-06-20  7:14 ` [RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding Nicolas Boichat
  2016-06-21 15:39 ` [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Archit Taneja
  0 siblings, 2 replies; 9+ messages in thread
From: Nicolas Boichat @ 2016-06-20  7:14 UTC (permalink / raw)
  To: dri-devel
  Cc: David Airlie, Thierry Reding, Nicolas Boichat, Russell King,
	Inki Dae, Yakir Yang, Enric Balletbo i Serra, Heiko Stuebner,
	linux-kernel, djkurtz, p.zabel, marcheu

ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.

The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the bridge
via 2 registers on I2C.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---

Hi,

I tested this driver using the Mediatek HDMI controller (MT8173) upstream
of the ANX bridge chip (Phillip sent a PULL request on June 13:
git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
).

I have 2 concerns, that I'm not sure how to address within the kernel DRM
framework:
 1. All other bridge drivers also have a connector attached to it. However, in
    this case, we cannot read the monitor EDID directly, so I'm not sure what
    I could put in a "get_modes" function. Instead, ANX7688 provides a I2C
    passthru/repeater, so the EDID is read on the Mediatek HDMI controller side.
    
    That leads to a somewhat strange layout, where we have:
    - MTK HDMI bridge/encoder
      - MTK connector (HDMI)
      - ANX7688 bridge
        - No connector

    Resolution filtering works fine though, thanks to mode_fixup callback on the
    bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from its
    connector mode_valid callback, so that invalid modes are not even presented
    to userspace.

 2. In the bandwidth computation, I hard-code 8-bit per channel (bpc). bpc does
    not seem to be included in the mode setting itself. We could possibly iterate
    over connectors on the DRM device, but then, IIUC, connector->display_info.bpc
    indicates the _maximum_ bpc supported by the monitor.

Any pointers? Thanks!

Best,

Nicolas

 drivers/gpu/drm/bridge/Kconfig            |   9 ++
 drivers/gpu/drm/bridge/Makefile           |   1 +
 drivers/gpu/drm/bridge/analogix-anx7688.c | 227 ++++++++++++++++++++++++++++++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8f7423f..0c1eb41 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -7,6 +7,15 @@ config DRM_BRIDGE
 menu "Display Interface Bridges"
 	depends on DRM && DRM_BRIDGE
 
+config DRM_ANALOGIX_ANX7688
+	tristate "Analogix ANX7688 bridge"
+	depends on DRM
+	select DRM_KMS_HELPER
+	---help---
+	  ANX7688 is a transmitter to support DisplayPort over USB-C for
+	  smartphone and tablets.
+	  This driver only supports the HDMI to DP component of the chip.
+
 config DRM_ANALOGIX_ANX78XX
 	tristate "Analogix ANX78XX bridge"
 	select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 96b13b3..d744c6c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
 ccflags-y := -Iinclude/drm
 
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c
new file mode 100644
index 0000000..2c34029
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
@@ -0,0 +1,227 @@
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <drm/drmP.h>
+#include <drm/drm_crtc.h>
+
+/* Register addresses */
+#define VENDOR_ID_REG 0x00
+#define DEVICE_ID_REG 0x02
+
+#define FW_VERSION_REG 0x80
+
+#define DP_BANDWIDTH_REG 0x85
+#define DP_LANE_COUNT_REG 0x86
+
+#define VENDOR_ID 0x1f29
+#define DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define MINIMUM_FW_VERSION 0x0085
+
+struct anx7688 {
+	struct drm_bridge bridge;
+	struct i2c_client *client;
+
+	bool filter;
+};
+
+static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
+			u16 data_len)
+{
+	int ret;
+	struct i2c_msg msgs[] = {
+		{
+		 .addr = client->addr,
+		 .flags = 0,
+		 .len = 1,
+		 .buf = &reg,
+		 },
+		{
+		 .addr = client->addr,
+		 .flags = I2C_M_RD,
+		 .len = data_len,
+		 .buf = data,
+		 }
+	};
+
+	ret = i2c_transfer(client->adapter, msgs, 2);
+
+	if (ret == 2)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
+{
+	return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+				      const struct drm_display_mode *mode,
+				      struct drm_display_mode *adjusted_mode)
+{
+	struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
+	u8 regs[2];
+	int totalbw, requiredbw;
+	int ret;
+
+	if (!anx7688->filter)
+		return true;
+
+	/* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+	ret = anx7688_read(anx7688->client, DP_BANDWIDTH_REG, regs, 2);
+	if (ret < 0) {
+		dev_err(&anx7688->client->dev,
+			"Failed to read bandwidth/lane count\n");
+		return false;
+	}
+
+	/* Compute available rate (kHz) */
+	totalbw = regs[0] * regs[1] * 270000 * 8 / 10;
+
+	/* Required bandwidth (8 bpc) */
+	requiredbw = mode->clock * 8 * 3;
+
+	dev_dbg(&anx7688->client->dev,
+		"DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
+		totalbw, regs[0], regs[1], requiredbw);
+
+	if (totalbw == 0) {
+		dev_warn(&anx7688->client->dev,
+			 "Bandwidth/lane count are 0, not rejecting modes\n");
+		return true;
+	}
+
+	return totalbw >= requiredbw;
+}
+
+static const struct drm_bridge_funcs anx7688_bridge_funcs = {
+	.mode_fixup	= anx7688_bridge_mode_fixup,
+};
+
+static int anx7688_i2c_probe(struct i2c_client *client,
+			     const struct i2c_device_id *id)
+{
+	struct anx7688 *anx7688;
+	int ret;
+	u8 buffer[4];
+	u16 vendor, device, fwversion;
+
+	anx7688 = devm_kzalloc(&client->dev, sizeof(*anx7688), GFP_KERNEL);
+	if (!anx7688)
+		return -ENOMEM;
+
+#if IS_ENABLED(CONFIG_OF)
+	anx7688->bridge.of_node = client->dev.of_node;
+#endif
+
+	anx7688->client = client;
+	i2c_set_clientdata(client, anx7688);
+
+	/* Read both vendor and device id (4 bytes). */
+	ret = anx7688_read(client, VENDOR_ID_REG, buffer, 4);
+	if (ret) {
+		dev_err(&client->dev, "Failed to read chip vendor/device id\n");
+		return ret;
+	}
+
+	vendor = (u16)buffer[1] << 8 | buffer[0];
+	device = (u16)buffer[3] << 8 | buffer[2];
+	if (vendor != VENDOR_ID || device != DEVICE_ID) {
+		dev_err(&client->dev,
+			"Invalid vendor/device id %04x/%04x\n",
+			vendor, device);
+		return -ENODEV;
+	}
+
+	ret = anx7688_read(client, FW_VERSION_REG, buffer, 2);
+	if (ret) {
+		dev_err(&client->dev, "Failed to read firmware version\n");
+		return ret;
+	}
+
+	fwversion = (u16)buffer[0] << 8 | buffer[1];
+	dev_info(&client->dev, "ANX7688 firwmare version %02x.%02x\n",
+		 buffer[0], buffer[1]);
+
+	/* FW version >= 0.85 supports bandwidth/lane count registers */
+	if (fwversion >= MINIMUM_FW_VERSION) {
+		anx7688->filter = true;
+	} else {
+		/* Warn, but not fail, for backwards compatiblity. */
+		dev_warn(&client->dev,
+			 "Old ANX7688 FW version (%04x), not filtering\n",
+			 fwversion);
+	}
+
+	anx7688->bridge.funcs = &anx7688_bridge_funcs;
+	ret = drm_bridge_add(&anx7688->bridge);
+	if (ret < 0) {
+		dev_err(&client->dev, "Failed to add drm bridge\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int anx7688_i2c_remove(struct i2c_client *client)
+{
+	struct anx7688 *anx7688 = i2c_get_clientdata(client);
+
+	drm_bridge_remove(&anx7688->bridge);
+
+	return 0;
+}
+
+static const struct i2c_device_id anx7688_id[] = {
+	{ "anx7688", 0 },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(i2c, anx7688_id);
+
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id anx7688_match_table[] = {
+	{ .compatible = "analogix,anx7688", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, anx7688_match_table);
+#endif
+
+static struct i2c_driver anx7688_driver = {
+	.driver = {
+		   .name = "anx7688",
+		   .of_match_table = of_match_ptr(anx7688_match_table),
+		  },
+	.probe = anx7688_i2c_probe,
+	.remove = anx7688_i2c_remove,
+	.id_table = anx7688_id,
+};
+
+module_i2c_driver(anx7688_driver);
+
+MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver");
+MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.8.0.rc3.226.g39d4020

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding
  2016-06-20  7:14 [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Nicolas Boichat
@ 2016-06-20  7:14 ` Nicolas Boichat
  2016-06-21 15:39 ` [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Archit Taneja
  1 sibling, 0 replies; 9+ messages in thread
From: Nicolas Boichat @ 2016-06-20  7:14 UTC (permalink / raw)
  To: dri-devel
  Cc: David Airlie, Thierry Reding, Nicolas Boichat, Russell King,
	Inki Dae, Yakir Yang, Enric Balletbo i Serra, Heiko Stuebner,
	linux-kernel, djkurtz, p.zabel, marcheu

ANX7688 is a transmitter to support DisplayPort over USB-C for
smartphone and tablets.

This binding only describes the HDMI to DP component of the chip.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---
 .../devicetree/bindings/video/bridge/anx7688.txt   | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7688.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7688.txt b/Documentation/devicetree/bindings/video/bridge/anx7688.txt
new file mode 100644
index 0000000..78b55bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7688.txt
@@ -0,0 +1,32 @@
+Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C)
+---------------------------------------------------------------------
+
+The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per
+second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video
+resolution from a smartphone or tablet with full function USB-C.
+
+This binding only describes the HDMI to DP display bridge.
+
+Required properties:
+
+ - compatible          : "analogix,anx7688"
+ - reg                 : I2C address of the device (fixed at 0x2c)
+
+Optional properties:
+
+ - Video port for HDMI input, using the DT bindings defined in [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+	anx7688: anx7688@2c {
+		compatible = "analogix,anx7688";
+		reg = <0x2c>;
+
+		port {
+			anx7688_in: endpoint {
+				remote-endpoint = <&hdmi0_out>;
+			};
+		};
+	};
-- 
2.8.0.rc3.226.g39d4020

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-20  7:14 [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Nicolas Boichat
  2016-06-20  7:14 ` [RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding Nicolas Boichat
@ 2016-06-21 15:39 ` Archit Taneja
  2016-06-22  2:44   ` Nicolas Boichat
  1 sibling, 1 reply; 9+ messages in thread
From: Archit Taneja @ 2016-06-21 15:39 UTC (permalink / raw)
  To: Nicolas Boichat, dri-devel
  Cc: marcheu, linux-kernel, Enric Balletbo i Serra, Russell King,
	Thierry Reding

Hi,

On 6/20/2016 12:44 PM, Nicolas Boichat wrote:
> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> that has an internal microcontroller.
>
> The only reason a Linux kernel driver is necessary is to reject
> resolutions that require more bandwidth than what is available on
> the DP side. DP bandwidth and lane count are reported by the bridge
> via 2 registers on I2C.

How does the chip know when to enable/disable itself? Does it shutoff
itself if there isn't anything on the HDMI link?

>
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
>
> Hi,
>
> I tested this driver using the Mediatek HDMI controller (MT8173) upstream
> of the ANX bridge chip (Phillip sent a PULL request on June 13:
> git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
> ).
>
> I have 2 concerns, that I'm not sure how to address within the kernel DRM
> framework:
>   1. All other bridge drivers also have a connector attached to it. However, in
>      this case, we cannot read the monitor EDID directly, so I'm not sure what
>      I could put in a "get_modes" function. Instead, ANX7688 provides a I2C
>      passthru/repeater, so the EDID is read on the Mediatek HDMI controller side.
>
>      That leads to a somewhat strange layout, where we have:
>      - MTK HDMI bridge/encoder
>        - MTK connector (HDMI)
>        - ANX7688 bridge
>          - No connector


You should ideally have one DP connector at the end of the chain:

	- MTK HDMI bridge/encoder
             - ANX7688 bridge
                - Connector (DP)

In the dt-bindings for this board, hdmi's output port shouldn't be
connected to a hdmi connector, but the input port of the ANX7688
DP bridge. The output port of the bridge should be the one that
connects to the DP connector.

One way I can think of fixing this is to make make the MTK hdmi
encoder driver a bit smarter by observing the DT connections. If
it's output port is connected to just a hdmi-connector, then
things should be as before. If the output is connected to the DP
bridge, then it should create a DP connector. The connector ops
for the DP connector can still be the same as that of the HDMI
connector before, but the phandle to the DDC bus would be in the
DP device node in this case.

This way, you can get around having the correct layout.

Ideally, a bridge driver shouldn't be the one that creates a
connector. It may contain some of the connector functionality, but
the connector creation should be managed by the kms driver.
Almost all bridge drivers creating a connector in their .attach
callbacks since they own some of the connector functionality (like
reading EDID). That's something we're trying to fix by providing
some more bridge api that kms drivers can use.

Since this bridge driver doesn't have any connector functionality
anyway, you should be okay.

>
>      Resolution filtering works fine though, thanks to mode_fixup callback on the
>      bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from its
>      connector mode_valid callback, so that invalid modes are not even presented
>      to userspace.
>
>   2. In the bandwidth computation, I hard-code 8-bit per channel (bpc). bpc does
>      not seem to be included in the mode setting itself. We could possibly iterate
>      over connectors on the DRM device, but then, IIUC, connector->display_info.bpc
>      indicates the _maximum_ bpc supported by the monitor.

I'm not clear about this either. Some drivers set a bus format
on the connector via drm_display_info_set_bus_formats in their
get_modes connector op, and then retrieve it later.

>
> Any pointers? Thanks!
>
> Best,
>
> Nicolas
>
>   drivers/gpu/drm/bridge/Kconfig            |   9 ++
>   drivers/gpu/drm/bridge/Makefile           |   1 +
>   drivers/gpu/drm/bridge/analogix-anx7688.c | 227 ++++++++++++++++++++++++++++++
>   3 files changed, 237 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..0c1eb41 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -7,6 +7,15 @@ config DRM_BRIDGE
>   menu "Display Interface Bridges"
>   	depends on DRM && DRM_BRIDGE
>
> +config DRM_ANALOGIX_ANX7688
> +	tristate "Analogix ANX7688 bridge"
> +	depends on DRM
> +	select DRM_KMS_HELPER
> +	---help---
> +	  ANX7688 is a transmitter to support DisplayPort over USB-C for
> +	  smartphone and tablets.
> +	  This driver only supports the HDMI to DP component of the chip.
> +
>   config DRM_ANALOGIX_ANX78XX
>   	tristate "Analogix ANX78XX bridge"
>   	select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..d744c6c 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,6 @@
>   ccflags-y := -Iinclude/drm
>
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
>   obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c
> new file mode 100644
> index 0000000..2c34029
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
> @@ -0,0 +1,227 @@
> +/*
> + * ANX7688 HDMI->DP bridge driver
> + *
> + * Copyright (C) 2016 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <drm/drmP.h>

The 3 headers above aren't needed.

> +#include <drm/drm_crtc.h>
> +
> +/* Register addresses */
> +#define VENDOR_ID_REG 0x00
> +#define DEVICE_ID_REG 0x02
> +
> +#define FW_VERSION_REG 0x80
> +
> +#define DP_BANDWIDTH_REG 0x85
> +#define DP_LANE_COUNT_REG 0x86
> +
> +#define VENDOR_ID 0x1f29
> +#define DEVICE_ID 0x7688
> +
> +/* First supported firmware version (0.85) */
> +#define MINIMUM_FW_VERSION 0x0085
> +
> +struct anx7688 {
> +	struct drm_bridge bridge;
> +	struct i2c_client *client;
> +
> +	bool filter;
> +};
> +
> +static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
> +			u16 data_len)
> +{
> +	int ret;
> +	struct i2c_msg msgs[] = {
> +		{
> +		 .addr = client->addr,
> +		 .flags = 0,
> +		 .len = 1,
> +		 .buf = &reg,
> +		 },
> +		{
> +		 .addr = client->addr,
> +		 .flags = I2C_M_RD,
> +		 .len = data_len,
> +		 .buf = data,
> +		 }
> +	};
> +
> +	ret = i2c_transfer(client->adapter, msgs, 2);
> +
> +	if (ret == 2)
> +		return 0;
> +	if (ret < 0)
> +		return ret;
> +	else
> +		return -EIO;
> +}
> +
> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> +{
> +	return container_of(bridge, struct anx7688, bridge);
> +}
> +
> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> +				      const struct drm_display_mode *mode,
> +				      struct drm_display_mode *adjusted_mode)
> +{
> +	struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> +	u8 regs[2];
> +	int totalbw, requiredbw;

It might make sense to use a u32 or long or something here to prevent
risk of overflow.

> +	int ret;
> +
> +	if (!anx7688->filter)
> +		return true;
> +
> +	/* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
> +	ret = anx7688_read(anx7688->client, DP_BANDWIDTH_REG, regs, 2);

Who programmed these registers in the first place? Is the lane count
some sort of reset value? Or is it something that changes dynamically?

> +	if (ret < 0) {
> +		dev_err(&anx7688->client->dev,
> +			"Failed to read bandwidth/lane count\n");
> +		return false;
> +	}
> +
> +	/* Compute available rate (kHz) */
> +	totalbw = regs[0] * regs[1] * 270000 * 8 / 10;
> +
> +	/* Required bandwidth (8 bpc) */
> +	requiredbw = mode->clock * 8 * 3;
> +
> +	dev_dbg(&anx7688->client->dev,
> +		"DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
> +		totalbw, regs[0], regs[1], requiredbw);
> +
> +	if (totalbw == 0) {
> +		dev_warn(&anx7688->client->dev,
> +			 "Bandwidth/lane count are 0, not rejecting modes\n");
> +		return true;
> +	}
> +
> +	return totalbw >= requiredbw;
> +}
> +
> +static const struct drm_bridge_funcs anx7688_bridge_funcs = {
> +	.mode_fixup	= anx7688_bridge_mode_fixup,
> +};
> +
> +static int anx7688_i2c_probe(struct i2c_client *client,
> +			     const struct i2c_device_id *id)
> +{
> +	struct anx7688 *anx7688;
> +	int ret;
> +	u8 buffer[4];
> +	u16 vendor, device, fwversion;
> +
> +	anx7688 = devm_kzalloc(&client->dev, sizeof(*anx7688), GFP_KERNEL);
> +	if (!anx7688)
> +		return -ENOMEM;
> +
> +#if IS_ENABLED(CONFIG_OF)
> +	anx7688->bridge.of_node = client->dev.of_node;
> +#endif
> +
> +	anx7688->client = client;
> +	i2c_set_clientdata(client, anx7688);
> +
> +	/* Read both vendor and device id (4 bytes). */
> +	ret = anx7688_read(client, VENDOR_ID_REG, buffer, 4);
> +	if (ret) {
> +		dev_err(&client->dev, "Failed to read chip vendor/device id\n");
> +		return ret;
> +	}
> +
> +	vendor = (u16)buffer[1] << 8 | buffer[0];
> +	device = (u16)buffer[3] << 8 | buffer[2];
> +	if (vendor != VENDOR_ID || device != DEVICE_ID) {
> +		dev_err(&client->dev,
> +			"Invalid vendor/device id %04x/%04x\n",
> +			vendor, device);
> +		return -ENODEV;
> +	}
> +
> +	ret = anx7688_read(client, FW_VERSION_REG, buffer, 2);
> +	if (ret) {
> +		dev_err(&client->dev, "Failed to read firmware version\n");
> +		return ret;
> +	}
> +
> +	fwversion = (u16)buffer[0] << 8 | buffer[1];
> +	dev_info(&client->dev, "ANX7688 firwmare version %02x.%02x\n",
> +		 buffer[0], buffer[1]);
> +
> +	/* FW version >= 0.85 supports bandwidth/lane count registers */
> +	if (fwversion >= MINIMUM_FW_VERSION) {
> +		anx7688->filter = true;
> +	} else {
> +		/* Warn, but not fail, for backwards compatiblity. */

s/compatiblity/compatibility

> +		dev_warn(&client->dev,
> +			 "Old ANX7688 FW version (%04x), not filtering\n",
> +			 fwversion);
> +	}
> +
> +	anx7688->bridge.funcs = &anx7688_bridge_funcs;
> +	ret = drm_bridge_add(&anx7688->bridge);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "Failed to add drm bridge\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int anx7688_i2c_remove(struct i2c_client *client)
> +{
> +	struct anx7688 *anx7688 = i2c_get_clientdata(client);
> +
> +	drm_bridge_remove(&anx7688->bridge);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id anx7688_id[] = {
> +	{ "anx7688", 0 },
> +	{ /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, anx7688_id);
> +
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id anx7688_match_table[] = {
> +	{ .compatible = "analogix,anx7688", },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, anx7688_match_table);
> +#endif
> +
> +static struct i2c_driver anx7688_driver = {
> +	.driver = {
> +		   .name = "anx7688",
> +		   .of_match_table = of_match_ptr(anx7688_match_table),
> +		  },
> +	.probe = anx7688_i2c_probe,
> +	.remove = anx7688_i2c_remove,
> +	.id_table = anx7688_id,
> +};
> +
> +module_i2c_driver(anx7688_driver);
> +
> +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver");
> +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>");
> +MODULE_LICENSE("GPL v2");
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-21 15:39 ` [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Archit Taneja
@ 2016-06-22  2:44   ` Nicolas Boichat
  2016-06-22  3:54     ` Archit Taneja
  0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Boichat @ 2016-06-22  2:44 UTC (permalink / raw)
  To: Archit Taneja
  Cc: dri-devel, Stéphane Marchesin, linux-kernel,
	Enric Balletbo i Serra, Russell King, Thierry Reding

Hi Archit,

Thanks for your reply.

On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja <architt@codeaurora.org> wrote:
> Hi,
>
> On 6/20/2016 12:44 PM, Nicolas Boichat wrote:
>>
>> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
>> that has an internal microcontroller.
>>
>> The only reason a Linux kernel driver is necessary is to reject
>> resolutions that require more bandwidth than what is available on
>> the DP side. DP bandwidth and lane count are reported by the bridge
>> via 2 registers on I2C.
>
>
> How does the chip know when to enable/disable itself? Does it shutoff
> itself if there isn't anything on the HDMI link?

Not 100% sure of the internals (there is a closed source firmware in
the chip), but I believe the HDMI/DP part of the chip is switched on
whenever there is a DP over USB-C connector plugged in.

>>
>> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>> ---
>>
>> Hi,
>>
>> I tested this driver using the Mediatek HDMI controller (MT8173) upstream
>> of the ANX bridge chip (Phillip sent a PULL request on June 13:
>> git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
>> ).
>>
>> I have 2 concerns, that I'm not sure how to address within the kernel DRM
>> framework:
>>   1. All other bridge drivers also have a connector attached to it.
>> However, in
>>      this case, we cannot read the monitor EDID directly, so I'm not sure
>> what
>>      I could put in a "get_modes" function. Instead, ANX7688 provides a
>> I2C
>>      passthru/repeater, so the EDID is read on the Mediatek HDMI
>> controller side.
>>
>>      That leads to a somewhat strange layout, where we have:
>>      - MTK HDMI bridge/encoder
>>        - MTK connector (HDMI)
>>        - ANX7688 bridge
>>          - No connector
>
>
>
> You should ideally have one DP connector at the end of the chain:
>
>         - MTK HDMI bridge/encoder
>             - ANX7688 bridge
>                - Connector (DP)
>
> In the dt-bindings for this board, hdmi's output port shouldn't be
> connected to a hdmi connector, but the input port of the ANX7688
> DP bridge. The output port of the bridge should be the one that
> connects to the DP connector.

Yes that's what I do (in the device tree).

Actually, experimenting a bit more with the code, I realized that the
connector is always attached to the encoder, not the bridge, so the 2
layouts above are actually identical (from the userspace point of
view). Except that the connector name should be HDMI in one case, and
DP in the other. But I think that's mostly a cosmetic difference?

> One way I can think of fixing this is to make make the MTK hdmi
> encoder driver a bit smarter by observing the DT connections. If
> it's output port is connected to just a hdmi-connector, then
> things should be as before. If the output is connected to the DP
> bridge, then it should create a DP connector. The connector ops
> for the DP connector can still be the same as that of the HDMI
> connector before, but the phandle to the DDC bus would be in the
> DP device node in this case.

I think it'd be a bit weird to have the DDC bus phandle on the DP
connector, as we're not reading the EDID on the DP side of the bridge,
but on the HDMI side (and the bridge can do all sort of things to the
EDID: At the very least, I think it caches it).

> This way, you can get around having the correct layout.
>
> Ideally, a bridge driver shouldn't be the one that creates a
> connector. It may contain some of the connector functionality, but
> the connector creation should be managed by the kms driver.
> Almost all bridge drivers creating a connector in their .attach
> callbacks since they own some of the connector functionality (like
> reading EDID). That's something we're trying to fix by providing
> some more bridge api that kms drivers can use.
>
> Since this bridge driver doesn't have any connector functionality
> anyway, you should be okay.

Great, thanks for clarifying.

>>
>>      Resolution filtering works fine though, thanks to mode_fixup callback
>> on the
>>      bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from
>> its
>>      connector mode_valid callback, so that invalid modes are not even
>> presented
>>      to userspace.
>>
>>   2. In the bandwidth computation, I hard-code 8-bit per channel (bpc).
>> bpc does
>>      not seem to be included in the mode setting itself. We could possibly
>> iterate
>>      over connectors on the DRM device, but then, IIUC,
>> connector->display_info.bpc
>>      indicates the _maximum_ bpc supported by the monitor.
>
>
> I'm not clear about this either. Some drivers set a bus format
> on the connector via drm_display_info_set_bus_formats in their
> get_modes connector op, and then retrieve it later.

Ah, interesting... Seems like we'd need a big switch/case to convert
from bus_format to bpp, though.

>>
>> Any pointers? Thanks!
>>
>> Best,
>>
>> Nicolas
>>
>>   drivers/gpu/drm/bridge/Kconfig            |   9 ++
>>   drivers/gpu/drm/bridge/Makefile           |   1 +
>>   drivers/gpu/drm/bridge/analogix-anx7688.c | 227
>> ++++++++++++++++++++++++++++++
>>   3 files changed, 237 insertions(+)
>>   create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig
>> b/drivers/gpu/drm/bridge/Kconfig
>> index 8f7423f..0c1eb41 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -7,6 +7,15 @@ config DRM_BRIDGE
>>   menu "Display Interface Bridges"
>>         depends on DRM && DRM_BRIDGE
>>
>> +config DRM_ANALOGIX_ANX7688
>> +       tristate "Analogix ANX7688 bridge"
>> +       depends on DRM
>> +       select DRM_KMS_HELPER
>> +       ---help---
>> +         ANX7688 is a transmitter to support DisplayPort over USB-C for
>> +         smartphone and tablets.
>> +         This driver only supports the HDMI to DP component of the chip.
>> +
>>   config DRM_ANALOGIX_ANX78XX
>>         tristate "Analogix ANX78XX bridge"
>>         select DRM_KMS_HELPER
>> diff --git a/drivers/gpu/drm/bridge/Makefile
>> b/drivers/gpu/drm/bridge/Makefile
>> index 96b13b3..d744c6c 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -1,5 +1,6 @@
>>   ccflags-y := -Iinclude/drm
>>
>> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
>>   obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>>   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>> diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c
>> b/drivers/gpu/drm/bridge/analogix-anx7688.c
>> new file mode 100644
>> index 0000000..2c34029
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
>> @@ -0,0 +1,227 @@
>> +/*
>> + * ANX7688 HDMI->DP bridge driver
>> + *
>> + * Copyright (C) 2016 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * 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.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/gpio.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_gpio.h>
>> +#include <drm/drmP.h>
>
>
> The 3 headers above aren't needed.

Nor gpio.h. Removed.

>
>> +#include <drm/drm_crtc.h>
>> +
>> +/* Register addresses */
>> +#define VENDOR_ID_REG 0x00
>> +#define DEVICE_ID_REG 0x02
>> +
>> +#define FW_VERSION_REG 0x80
>> +
>> +#define DP_BANDWIDTH_REG 0x85
>> +#define DP_LANE_COUNT_REG 0x86
>> +
>> +#define VENDOR_ID 0x1f29
>> +#define DEVICE_ID 0x7688
>> +
>> +/* First supported firmware version (0.85) */
>> +#define MINIMUM_FW_VERSION 0x0085
>> +
>> +struct anx7688 {
>> +       struct drm_bridge bridge;
>> +       struct i2c_client *client;
>> +
>> +       bool filter;
>> +};
>> +
>> +static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
>> +                       u16 data_len)
>> +{
>> +       int ret;
>> +       struct i2c_msg msgs[] = {
>> +               {
>> +                .addr = client->addr,
>> +                .flags = 0,
>> +                .len = 1,
>> +                .buf = &reg,
>> +                },
>> +               {
>> +                .addr = client->addr,
>> +                .flags = I2C_M_RD,
>> +                .len = data_len,
>> +                .buf = data,
>> +                }
>> +       };
>> +
>> +       ret = i2c_transfer(client->adapter, msgs, 2);
>> +
>> +       if (ret == 2)
>> +               return 0;
>> +       if (ret < 0)
>> +               return ret;
>> +       else
>> +               return -EIO;
>> +}
>> +
>> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge
>> *bridge)
>> +{
>> +       return container_of(bridge, struct anx7688, bridge);
>> +}
>> +
>> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
>> +                                     const struct drm_display_mode *mode,
>> +                                     struct drm_display_mode
>> *adjusted_mode)
>> +{
>> +       struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
>> +       u8 regs[2];
>> +       int totalbw, requiredbw;
>
>
> It might make sense to use a u32 or long or something here to prevent
> risk of overflow.

Well, mode->clock is already an int (and there won't be any overflow
in requiredbw unless we go for THz clocks ,-))

totalbw could do with a bit more of sanity checking (e.g. check that
regs[0] * regs[1] is not absurd). Like, we know regs[1] <= 2 on this
chip. Will fix.

>> +       int ret;
>> +
>> +       if (!anx7688->filter)
>> +               return true;
>> +
>> +       /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
>> +       ret = anx7688_read(anx7688->client, DP_BANDWIDTH_REG, regs, 2);
>
>
> Who programmed these registers in the first place? Is the lane count
> some sort of reset value? Or is it something that changes dynamically?

The ANX7688 OCM (on-chip microcontroller) sets it. It changes
depending on the downstream (DP) bandwidth/lane count, so it changes
on each plug event (after DP link training presumably).

>> +       if (ret < 0) {
>> +               dev_err(&anx7688->client->dev,
>> +                       "Failed to read bandwidth/lane count\n");
>> +               return false;
>> +       }
>> +
>> +       /* Compute available rate (kHz) */
>> +       totalbw = regs[0] * regs[1] * 270000 * 8 / 10;
>> +
>> +       /* Required bandwidth (8 bpc) */
>> +       requiredbw = mode->clock * 8 * 3;
>> +
>> +       dev_dbg(&anx7688->client->dev,
>> +               "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
>> +               totalbw, regs[0], regs[1], requiredbw);
>> +
>> +       if (totalbw == 0) {
>> +               dev_warn(&anx7688->client->dev,
>> +                        "Bandwidth/lane count are 0, not rejecting
>> modes\n");
>> +               return true;
>> +       }
>> +
>> +       return totalbw >= requiredbw;
>> +}
>> +
>> +static const struct drm_bridge_funcs anx7688_bridge_funcs = {
>> +       .mode_fixup     = anx7688_bridge_mode_fixup,
>> +};
>> +
>> +static int anx7688_i2c_probe(struct i2c_client *client,
>> +                            const struct i2c_device_id *id)
>> +{
>> +       struct anx7688 *anx7688;
>> +       int ret;
>> +       u8 buffer[4];
>> +       u16 vendor, device, fwversion;
>> +
>> +       anx7688 = devm_kzalloc(&client->dev, sizeof(*anx7688),
>> GFP_KERNEL);
>> +       if (!anx7688)
>> +               return -ENOMEM;
>> +
>> +#if IS_ENABLED(CONFIG_OF)
>> +       anx7688->bridge.of_node = client->dev.of_node;
>> +#endif
>> +
>> +       anx7688->client = client;
>> +       i2c_set_clientdata(client, anx7688);
>> +
>> +       /* Read both vendor and device id (4 bytes). */
>> +       ret = anx7688_read(client, VENDOR_ID_REG, buffer, 4);
>> +       if (ret) {
>> +               dev_err(&client->dev, "Failed to read chip vendor/device
>> id\n");
>> +               return ret;
>> +       }
>> +
>> +       vendor = (u16)buffer[1] << 8 | buffer[0];
>> +       device = (u16)buffer[3] << 8 | buffer[2];
>> +       if (vendor != VENDOR_ID || device != DEVICE_ID) {
>> +               dev_err(&client->dev,
>> +                       "Invalid vendor/device id %04x/%04x\n",
>> +                       vendor, device);
>> +               return -ENODEV;
>> +       }
>> +
>> +       ret = anx7688_read(client, FW_VERSION_REG, buffer, 2);
>> +       if (ret) {
>> +               dev_err(&client->dev, "Failed to read firmware
>> version\n");
>> +               return ret;
>> +       }
>> +
>> +       fwversion = (u16)buffer[0] << 8 | buffer[1];
>> +       dev_info(&client->dev, "ANX7688 firwmare version %02x.%02x\n",
>> +                buffer[0], buffer[1]);
>> +
>> +       /* FW version >= 0.85 supports bandwidth/lane count registers */
>> +       if (fwversion >= MINIMUM_FW_VERSION) {
>> +               anx7688->filter = true;
>> +       } else {
>> +               /* Warn, but not fail, for backwards compatiblity. */
>
>
> s/compatiblity/compatibility

Will fix.

>
>> +               dev_warn(&client->dev,
>> +                        "Old ANX7688 FW version (%04x), not filtering\n",
>> +                        fwversion);
>> +       }
>> +
>> +       anx7688->bridge.funcs = &anx7688_bridge_funcs;
>> +       ret = drm_bridge_add(&anx7688->bridge);
>> +       if (ret < 0) {
>> +               dev_err(&client->dev, "Failed to add drm bridge\n");
>> +               return ret;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int anx7688_i2c_remove(struct i2c_client *client)
>> +{
>> +       struct anx7688 *anx7688 = i2c_get_clientdata(client);
>> +
>> +       drm_bridge_remove(&anx7688->bridge);
>> +
>> +       return 0;
>> +}
>> +
>> +static const struct i2c_device_id anx7688_id[] = {
>> +       { "anx7688", 0 },
>> +       { /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(i2c, anx7688_id);
>> +
>> +#if IS_ENABLED(CONFIG_OF)
>> +static const struct of_device_id anx7688_match_table[] = {
>> +       { .compatible = "analogix,anx7688", },
>> +       { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, anx7688_match_table);
>> +#endif
>> +
>> +static struct i2c_driver anx7688_driver = {
>> +       .driver = {
>> +                  .name = "anx7688",
>> +                  .of_match_table = of_match_ptr(anx7688_match_table),
>> +                 },
>> +       .probe = anx7688_i2c_probe,
>> +       .remove = anx7688_i2c_remove,
>> +       .id_table = anx7688_id,
>> +};
>> +
>> +module_i2c_driver(anx7688_driver);
>> +
>> +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver");
>> +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>");
>> +MODULE_LICENSE("GPL v2");
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-22  2:44   ` Nicolas Boichat
@ 2016-06-22  3:54     ` Archit Taneja
  2016-06-22  6:32       ` Nicolas Boichat
  0 siblings, 1 reply; 9+ messages in thread
From: Archit Taneja @ 2016-06-22  3:54 UTC (permalink / raw)
  To: Nicolas Boichat
  Cc: dri-devel, Stéphane Marchesin, linux-kernel,
	Enric Balletbo i Serra, Russell King, Thierry Reding



On 6/22/2016 8:14 AM, Nicolas Boichat wrote:
> Hi Archit,
>
> Thanks for your reply.
>
> On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja <architt@codeaurora.org> wrote:
>> Hi,
>>
>> On 6/20/2016 12:44 PM, Nicolas Boichat wrote:
>>>
>>> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
>>> that has an internal microcontroller.
>>>
>>> The only reason a Linux kernel driver is necessary is to reject
>>> resolutions that require more bandwidth than what is available on
>>> the DP side. DP bandwidth and lane count are reported by the bridge
>>> via 2 registers on I2C.
>>
>>
>> How does the chip know when to enable/disable itself? Does it shutoff
>> itself if there isn't anything on the HDMI link?
>
> Not 100% sure of the internals (there is a closed source firmware in
> the chip), but I believe the HDMI/DP part of the chip is switched on
> whenever there is a DP over USB-C connector plugged in.
>
>>>
>>> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>>> ---
>>>
>>> Hi,
>>>
>>> I tested this driver using the Mediatek HDMI controller (MT8173) upstream
>>> of the ANX bridge chip (Phillip sent a PULL request on June 13:
>>> git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
>>> ).
>>>
>>> I have 2 concerns, that I'm not sure how to address within the kernel DRM
>>> framework:
>>>    1. All other bridge drivers also have a connector attached to it.
>>> However, in
>>>       this case, we cannot read the monitor EDID directly, so I'm not sure
>>> what
>>>       I could put in a "get_modes" function. Instead, ANX7688 provides a
>>> I2C
>>>       passthru/repeater, so the EDID is read on the Mediatek HDMI
>>> controller side.
>>>
>>>       That leads to a somewhat strange layout, where we have:
>>>       - MTK HDMI bridge/encoder
>>>         - MTK connector (HDMI)
>>>         - ANX7688 bridge
>>>           - No connector
>>
>>
>>
>> You should ideally have one DP connector at the end of the chain:
>>
>>          - MTK HDMI bridge/encoder
>>              - ANX7688 bridge
>>                 - Connector (DP)
>>
>> In the dt-bindings for this board, hdmi's output port shouldn't be
>> connected to a hdmi connector, but the input port of the ANX7688
>> DP bridge. The output port of the bridge should be the one that
>> connects to the DP connector.
>
> Yes that's what I do (in the device tree).
>
> Actually, experimenting a bit more with the code, I realized that the
> connector is always attached to the encoder, not the bridge, so the 2
> layouts above are actually identical (from the userspace point of
> view). Except that the connector name should be HDMI in one case, and
> DP in the other. But I think that's mostly a cosmetic difference?

Yeah, probably. I don't know what exactly the userspace does with
the connector type, but it would be nice to represent it as a DP
connector in case it makes any decisions based on it.

>
>> One way I can think of fixing this is to make make the MTK hdmi
>> encoder driver a bit smarter by observing the DT connections. If
>> it's output port is connected to just a hdmi-connector, then
>> things should be as before. If the output is connected to the DP
>> bridge, then it should create a DP connector. The connector ops
>> for the DP connector can still be the same as that of the HDMI
>> connector before, but the phandle to the DDC bus would be in the
>> DP device node in this case.
>
> I think it'd be a bit weird to have the DDC bus phandle on the DP
> connector, as we're not reading the EDID on the DP side of the bridge,
> but on the HDMI side (and the bridge can do all sort of things to the
> EDID: At the very least, I think it caches it).

On the board, do the DDC lines join directly from the SoC pins to the
DP connector, or does it go via the ANX7688 chip?

Even with the current bindings (referred from the link below), the
hdmi connector has the DDC node. Shouldn't it be the same in the DP
case too? The DP connector, like before, is still manged by the HDMI
driver, the only difference being the name and that it's two hops away
in the DT bindings.

https://patchwork.kernel.org/patch/9137089/

>
>> This way, you can get around having the correct layout.
>>
>> Ideally, a bridge driver shouldn't be the one that creates a
>> connector. It may contain some of the connector functionality, but
>> the connector creation should be managed by the kms driver.
>> Almost all bridge drivers creating a connector in their .attach
>> callbacks since they own some of the connector functionality (like
>> reading EDID). That's something we're trying to fix by providing
>> some more bridge api that kms drivers can use.
>>
>> Since this bridge driver doesn't have any connector functionality
>> anyway, you should be okay.
>
> Great, thanks for clarifying.
>
>>>
>>>       Resolution filtering works fine though, thanks to mode_fixup callback
>>> on the
>>>       bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from
>>> its
>>>       connector mode_valid callback, so that invalid modes are not even
>>> presented
>>>       to userspace.
>>>
>>>    2. In the bandwidth computation, I hard-code 8-bit per channel (bpc).
>>> bpc does
>>>       not seem to be included in the mode setting itself. We could possibly
>>> iterate
>>>       over connectors on the DRM device, but then, IIUC,
>>> connector->display_info.bpc
>>>       indicates the _maximum_ bpc supported by the monitor.
>>
>>
>> I'm not clear about this either. Some drivers set a bus format
>> on the connector via drm_display_info_set_bus_formats in their
>> get_modes connector op, and then retrieve it later.
>
> Ah, interesting... Seems like we'd need a big switch/case to convert
> from bus_format to bpp, though.
>
>>>
>>> Any pointers? Thanks!
>>>
>>> Best,
>>>
>>> Nicolas
>>>
>>>    drivers/gpu/drm/bridge/Kconfig            |   9 ++
>>>    drivers/gpu/drm/bridge/Makefile           |   1 +
>>>    drivers/gpu/drm/bridge/analogix-anx7688.c | 227
>>> ++++++++++++++++++++++++++++++
>>>    3 files changed, 237 insertions(+)
>>>    create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig
>>> b/drivers/gpu/drm/bridge/Kconfig
>>> index 8f7423f..0c1eb41 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -7,6 +7,15 @@ config DRM_BRIDGE
>>>    menu "Display Interface Bridges"
>>>          depends on DRM && DRM_BRIDGE
>>>
>>> +config DRM_ANALOGIX_ANX7688
>>> +       tristate "Analogix ANX7688 bridge"
>>> +       depends on DRM
>>> +       select DRM_KMS_HELPER
>>> +       ---help---
>>> +         ANX7688 is a transmitter to support DisplayPort over USB-C for
>>> +         smartphone and tablets.
>>> +         This driver only supports the HDMI to DP component of the chip.
>>> +
>>>    config DRM_ANALOGIX_ANX78XX
>>>          tristate "Analogix ANX78XX bridge"
>>>          select DRM_KMS_HELPER
>>> diff --git a/drivers/gpu/drm/bridge/Makefile
>>> b/drivers/gpu/drm/bridge/Makefile
>>> index 96b13b3..d744c6c 100644
>>> --- a/drivers/gpu/drm/bridge/Makefile
>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>> @@ -1,5 +1,6 @@
>>>    ccflags-y := -Iinclude/drm
>>>
>>> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
>>>    obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>>>    obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>>>    obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>>> diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c
>>> b/drivers/gpu/drm/bridge/analogix-anx7688.c
>>> new file mode 100644
>>> index 0000000..2c34029
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
>>> @@ -0,0 +1,227 @@
>>> +/*
>>> + * ANX7688 HDMI->DP bridge driver
>>> + *
>>> + * Copyright (C) 2016 Google, Inc.
>>> + *
>>> + * This software is licensed under the terms of the GNU General Public
>>> + * License version 2, as published by the Free Software Foundation, and
>>> + * may be copied, distributed, and modified under those terms.
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +#include <linux/delay.h>
>>> +#include <linux/gpio.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_gpio.h>
>>> +#include <drm/drmP.h>
>>
>>
>> The 3 headers above aren't needed.
>
> Nor gpio.h. Removed.
>
>>
>>> +#include <drm/drm_crtc.h>
>>> +
>>> +/* Register addresses */
>>> +#define VENDOR_ID_REG 0x00
>>> +#define DEVICE_ID_REG 0x02
>>> +
>>> +#define FW_VERSION_REG 0x80
>>> +
>>> +#define DP_BANDWIDTH_REG 0x85
>>> +#define DP_LANE_COUNT_REG 0x86
>>> +
>>> +#define VENDOR_ID 0x1f29
>>> +#define DEVICE_ID 0x7688
>>> +
>>> +/* First supported firmware version (0.85) */
>>> +#define MINIMUM_FW_VERSION 0x0085
>>> +
>>> +struct anx7688 {
>>> +       struct drm_bridge bridge;
>>> +       struct i2c_client *client;
>>> +
>>> +       bool filter;
>>> +};
>>> +
>>> +static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
>>> +                       u16 data_len)
>>> +{
>>> +       int ret;
>>> +       struct i2c_msg msgs[] = {
>>> +               {
>>> +                .addr = client->addr,
>>> +                .flags = 0,
>>> +                .len = 1,
>>> +                .buf = &reg,
>>> +                },
>>> +               {
>>> +                .addr = client->addr,
>>> +                .flags = I2C_M_RD,
>>> +                .len = data_len,
>>> +                .buf = data,
>>> +                }
>>> +       };
>>> +
>>> +       ret = i2c_transfer(client->adapter, msgs, 2);
>>> +
>>> +       if (ret == 2)
>>> +               return 0;
>>> +       if (ret < 0)
>>> +               return ret;
>>> +       else
>>> +               return -EIO;
>>> +}
>>> +
>>> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge
>>> *bridge)
>>> +{
>>> +       return container_of(bridge, struct anx7688, bridge);
>>> +}
>>> +
>>> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
>>> +                                     const struct drm_display_mode *mode,
>>> +                                     struct drm_display_mode
>>> *adjusted_mode)
>>> +{
>>> +       struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
>>> +       u8 regs[2];
>>> +       int totalbw, requiredbw;
>>
>>
>> It might make sense to use a u32 or long or something here to prevent
>> risk of overflow.
>
> Well, mode->clock is already an int (and there won't be any overflow
> in requiredbw unless we go for THz clocks ,-))

Ah okay, missed that.

>
> totalbw could do with a bit more of sanity checking (e.g. check that
> regs[0] * regs[1] is not absurd). Like, we know regs[1] <= 2 on this
> chip. Will fix.
>
>>> +       int ret;
>>> +
>>> +       if (!anx7688->filter)
>>> +               return true;
>>> +
>>> +       /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
>>> +       ret = anx7688_read(anx7688->client, DP_BANDWIDTH_REG, regs, 2);
>>
>>
>> Who programmed these registers in the first place? Is the lane count
>> some sort of reset value? Or is it something that changes dynamically?
>
> The ANX7688 OCM (on-chip microcontroller) sets it. It changes
> depending on the downstream (DP) bandwidth/lane count, so it changes
> on each plug event (after DP link training presumably).

Okay. Makes sense, then.

Thanks,
Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-22  3:54     ` Archit Taneja
@ 2016-06-22  6:32       ` Nicolas Boichat
  2016-06-22  8:51         ` Philipp Zabel
  0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Boichat @ 2016-06-22  6:32 UTC (permalink / raw)
  To: Archit Taneja
  Cc: dri-devel, Stéphane Marchesin, linux-kernel,
	Enric Balletbo i Serra, Russell King, Thierry Reding, p.zabel

+Philipp

On Wed, Jun 22, 2016 at 11:54 AM, Archit Taneja <architt@codeaurora.org> wrote:
>
>
> On 6/22/2016 8:14 AM, Nicolas Boichat wrote:
>>
>> Hi Archit,
>>
>> Thanks for your reply.
>>
>> On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja <architt@codeaurora.org>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 6/20/2016 12:44 PM, Nicolas Boichat wrote:
>>>>
>>>>
>>>> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
>>>> that has an internal microcontroller.
>>>>
>>>> The only reason a Linux kernel driver is necessary is to reject
>>>> resolutions that require more bandwidth than what is available on
>>>> the DP side. DP bandwidth and lane count are reported by the bridge
>>>> via 2 registers on I2C.
>>>
>>>
>>>
>>> How does the chip know when to enable/disable itself? Does it shutoff
>>> itself if there isn't anything on the HDMI link?
>>
>>
>> Not 100% sure of the internals (there is a closed source firmware in
>> the chip), but I believe the HDMI/DP part of the chip is switched on
>> whenever there is a DP over USB-C connector plugged in.
>>
>>>>
>>>> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> I tested this driver using the Mediatek HDMI controller (MT8173)
>>>> upstream
>>>> of the ANX bridge chip (Phillip sent a PULL request on June 13:
>>>> git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
>>>> ).
>>>>
>>>> I have 2 concerns, that I'm not sure how to address within the kernel
>>>> DRM
>>>> framework:
>>>>    1. All other bridge drivers also have a connector attached to it.
>>>> However, in
>>>>       this case, we cannot read the monitor EDID directly, so I'm not
>>>> sure
>>>> what
>>>>       I could put in a "get_modes" function. Instead, ANX7688 provides a
>>>> I2C
>>>>       passthru/repeater, so the EDID is read on the Mediatek HDMI
>>>> controller side.
>>>>
>>>>       That leads to a somewhat strange layout, where we have:
>>>>       - MTK HDMI bridge/encoder
>>>>         - MTK connector (HDMI)
>>>>         - ANX7688 bridge
>>>>           - No connector
>>>
>>>
>>>
>>>
>>> You should ideally have one DP connector at the end of the chain:
>>>
>>>          - MTK HDMI bridge/encoder
>>>              - ANX7688 bridge
>>>                 - Connector (DP)
>>>
>>> In the dt-bindings for this board, hdmi's output port shouldn't be
>>> connected to a hdmi connector, but the input port of the ANX7688
>>> DP bridge. The output port of the bridge should be the one that
>>> connects to the DP connector.
>>
>>
>> Yes that's what I do (in the device tree).
>>
>> Actually, experimenting a bit more with the code, I realized that the
>> connector is always attached to the encoder, not the bridge, so the 2
>> layouts above are actually identical (from the userspace point of
>> view). Except that the connector name should be HDMI in one case, and
>> DP in the other. But I think that's mostly a cosmetic difference?
>
>
> Yeah, probably. I don't know what exactly the userspace does with
> the connector type, but it would be nice to represent it as a DP
> connector in case it makes any decisions based on it.

AFAICT does not matter... And, in any case, USB-C to HDMI adapters are
far more common (so we'd do HDMI->(DP over USB-C)->HDMI....), so there
is a high change that advertising as DP would be wrong (and
advertising as HDMI would be correct by chance...).

>>
>>> One way I can think of fixing this is to make make the MTK hdmi
>>> encoder driver a bit smarter by observing the DT connections. If
>>> it's output port is connected to just a hdmi-connector, then
>>> things should be as before. If the output is connected to the DP
>>> bridge, then it should create a DP connector. The connector ops
>>> for the DP connector can still be the same as that of the HDMI
>>> connector before, but the phandle to the DDC bus would be in the
>>> DP device node in this case.
>>
>>
>> I think it'd be a bit weird to have the DDC bus phandle on the DP
>> connector, as we're not reading the EDID on the DP side of the bridge,
>> but on the HDMI side (and the bridge can do all sort of things to the
>> EDID: At the very least, I think it caches it).
>
>
> On the board, do the DDC lines join directly from the SoC pins to the
> DP connector, or does it go via the ANX7688 chip?

The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)

> Even with the current bindings (referred from the link below), the
> hdmi connector has the DDC node. Shouldn't it be the same in the DP
> case too? The DP connector, like before, is still manged by the HDMI
> driver, the only difference being the name and that it's two hops away
> in the DT bindings.
>
> https://patchwork.kernel.org/patch/9137089/

True, the bindings say so, but the current code actually looks for
ddc-i2c-bus property in whatever is connected on the endpoint (be it a
bridge or a connector).

And again, a bit odd as DP connector does not have true I2C lines...

Phillip? Any opinion?

>>
>>> This way, you can get around having the correct layout.
>>>
>>> Ideally, a bridge driver shouldn't be the one that creates a
>>> connector. It may contain some of the connector functionality, but
>>> the connector creation should be managed by the kms driver.
>>> Almost all bridge drivers creating a connector in their .attach
>>> callbacks since they own some of the connector functionality (like
>>> reading EDID). That's something we're trying to fix by providing
>>> some more bridge api that kms drivers can use.
>>>
>>> Since this bridge driver doesn't have any connector functionality
>>> anyway, you should be okay.
>>
>>
>> Great, thanks for clarifying.
>>
>>>>
>>>>       Resolution filtering works fine though, thanks to mode_fixup
>>>> callback
>>>> on the
>>>>       bridge. It also helps that Mediatek HDMI bridge calls mode_fixup
>>>> from
>>>> its
>>>>       connector mode_valid callback, so that invalid modes are not even
>>>> presented
>>>>       to userspace.
>>>>
>>>>    2. In the bandwidth computation, I hard-code 8-bit per channel (bpc).
>>>> bpc does
>>>>       not seem to be included in the mode setting itself. We could
>>>> possibly
>>>> iterate
>>>>       over connectors on the DRM device, but then, IIUC,
>>>> connector->display_info.bpc
>>>>       indicates the _maximum_ bpc supported by the monitor.
>>>
>>>
>>>
>>> I'm not clear about this either. Some drivers set a bus format
>>> on the connector via drm_display_info_set_bus_formats in their
>>> get_modes connector op, and then retrieve it later.
>>
>>
>> Ah, interesting... Seems like we'd need a big switch/case to convert
>> from bus_format to bpp, though.
>>
>>>>
>>>> Any pointers? Thanks!
>>>>
>>>> Best,
>>>>
>>>> Nicolas
>>>>
>>>>    drivers/gpu/drm/bridge/Kconfig            |   9 ++
>>>>    drivers/gpu/drm/bridge/Makefile           |   1 +
>>>>    drivers/gpu/drm/bridge/analogix-anx7688.c | 227
>>>> ++++++++++++++++++++++++++++++
>>>>    3 files changed, 237 insertions(+)
>>>>    create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/Kconfig
>>>> b/drivers/gpu/drm/bridge/Kconfig
>>>> index 8f7423f..0c1eb41 100644
>>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>>> @@ -7,6 +7,15 @@ config DRM_BRIDGE
>>>>    menu "Display Interface Bridges"
>>>>          depends on DRM && DRM_BRIDGE
>>>>
>>>> +config DRM_ANALOGIX_ANX7688
>>>> +       tristate "Analogix ANX7688 bridge"
>>>> +       depends on DRM
>>>> +       select DRM_KMS_HELPER
>>>> +       ---help---
>>>> +         ANX7688 is a transmitter to support DisplayPort over USB-C for
>>>> +         smartphone and tablets.
>>>> +         This driver only supports the HDMI to DP component of the
>>>> chip.
>>>> +
>>>>    config DRM_ANALOGIX_ANX78XX
>>>>          tristate "Analogix ANX78XX bridge"
>>>>          select DRM_KMS_HELPER
>>>> diff --git a/drivers/gpu/drm/bridge/Makefile
>>>> b/drivers/gpu/drm/bridge/Makefile
>>>> index 96b13b3..d744c6c 100644
>>>> --- a/drivers/gpu/drm/bridge/Makefile
>>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>>> @@ -1,5 +1,6 @@
>>>>    ccflags-y := -Iinclude/drm
>>>>
>>>> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
>>>>    obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>>>>    obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>>>>    obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>>>> diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c
>>>> b/drivers/gpu/drm/bridge/analogix-anx7688.c
>>>> new file mode 100644
>>>> index 0000000..2c34029
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
>>>> @@ -0,0 +1,227 @@
>>>> +/*
>>>> + * ANX7688 HDMI->DP bridge driver
>>>> + *
>>>> + * Copyright (C) 2016 Google, Inc.
>>>> + *
>>>> + * This software is licensed under the terms of the GNU General Public
>>>> + * License version 2, as published by the Free Software Foundation, and
>>>> + * may be copied, distributed, and modified under those terms.
>>>> + *
>>>> + * 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.
>>>> + */
>>>> +
>>>> +#include <linux/delay.h>
>>>> +#include <linux/gpio.h>
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_gpio.h>
>>>> +#include <drm/drmP.h>
>>>
>>>
>>>
>>> The 3 headers above aren't needed.
>>
>>
>> Nor gpio.h. Removed.
>>
>>>
>>>> +#include <drm/drm_crtc.h>
>>>> +
>>>> +/* Register addresses */
>>>> +#define VENDOR_ID_REG 0x00
>>>> +#define DEVICE_ID_REG 0x02
>>>> +
>>>> +#define FW_VERSION_REG 0x80
>>>> +
>>>> +#define DP_BANDWIDTH_REG 0x85
>>>> +#define DP_LANE_COUNT_REG 0x86
>>>> +
>>>> +#define VENDOR_ID 0x1f29
>>>> +#define DEVICE_ID 0x7688
>>>> +
>>>> +/* First supported firmware version (0.85) */
>>>> +#define MINIMUM_FW_VERSION 0x0085
>>>> +
>>>> +struct anx7688 {
>>>> +       struct drm_bridge bridge;
>>>> +       struct i2c_client *client;
>>>> +
>>>> +       bool filter;
>>>> +};
>>>> +
>>>> +static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
>>>> +                       u16 data_len)
>>>> +{
>>>> +       int ret;
>>>> +       struct i2c_msg msgs[] = {
>>>> +               {
>>>> +                .addr = client->addr,
>>>> +                .flags = 0,
>>>> +                .len = 1,
>>>> +                .buf = &reg,
>>>> +                },
>>>> +               {
>>>> +                .addr = client->addr,
>>>> +                .flags = I2C_M_RD,
>>>> +                .len = data_len,
>>>> +                .buf = data,
>>>> +                }
>>>> +       };
>>>> +
>>>> +       ret = i2c_transfer(client->adapter, msgs, 2);
>>>> +
>>>> +       if (ret == 2)
>>>> +               return 0;
>>>> +       if (ret < 0)
>>>> +               return ret;
>>>> +       else
>>>> +               return -EIO;
>>>> +}
>>>> +
>>>> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge
>>>> *bridge)
>>>> +{
>>>> +       return container_of(bridge, struct anx7688, bridge);
>>>> +}
>>>> +
>>>> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
>>>> +                                     const struct drm_display_mode
>>>> *mode,
>>>> +                                     struct drm_display_mode
>>>> *adjusted_mode)
>>>> +{
>>>> +       struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
>>>> +       u8 regs[2];
>>>> +       int totalbw, requiredbw;
>>>
>>>
>>>
>>> It might make sense to use a u32 or long or something here to prevent
>>> risk of overflow.
>>
>>
>> Well, mode->clock is already an int (and there won't be any overflow
>> in requiredbw unless we go for THz clocks ,-))
>
>
> Ah okay, missed that.
>
>>
>> totalbw could do with a bit more of sanity checking (e.g. check that
>> regs[0] * regs[1] is not absurd). Like, we know regs[1] <= 2 on this
>> chip. Will fix.
>>
>>>> +       int ret;
>>>> +
>>>> +       if (!anx7688->filter)
>>>> +               return true;
>>>> +
>>>> +       /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
>>>> +       ret = anx7688_read(anx7688->client, DP_BANDWIDTH_REG, regs, 2);
>>>
>>>
>>>
>>> Who programmed these registers in the first place? Is the lane count
>>> some sort of reset value? Or is it something that changes dynamically?
>>
>>
>> The ANX7688 OCM (on-chip microcontroller) sets it. It changes
>> depending on the downstream (DP) bandwidth/lane count, so it changes
>> on each plug event (after DP link training presumably).
>
>
> Okay. Makes sense, then.
>
> Thanks,
> Archit
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-22  6:32       ` Nicolas Boichat
@ 2016-06-22  8:51         ` Philipp Zabel
  2016-06-23  4:08           ` Nicolas Boichat
  0 siblings, 1 reply; 9+ messages in thread
From: Philipp Zabel @ 2016-06-22  8:51 UTC (permalink / raw)
  To: Nicolas Boichat
  Cc: Archit Taneja, dri-devel, Stéphane Marchesin, linux-kernel,
	Enric Balletbo i Serra, Russell King, Thierry Reding

Hi Nicolas,

Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat:
> >> Actually, experimenting a bit more with the code, I realized that the
> >> connector is always attached to the encoder, not the bridge, so the 2
> >> layouts above are actually identical (from the userspace point of
> >> view). Except that the connector name should be HDMI in one case, and
> >> DP in the other. But I think that's mostly a cosmetic difference?
> >
> >
> > Yeah, probably. I don't know what exactly the userspace does with
> > the connector type, but it would be nice to represent it as a DP
> > connector in case it makes any decisions based on it.
> 
> AFAICT does not matter... And, in any case, USB-C to HDMI adapters are
> far more common (so we'd do HDMI->(DP over USB-C)->HDMI....), so there
> is a high change that advertising as DP would be wrong (and
> advertising as HDMI would be correct by chance...).

If anything it should be represented as an USB-C connector, whatever
USB-C(DP)->HDMI->VGA adapter chain is connected externally shouldn't
matter.

> >>> One way I can think of fixing this is to make make the MTK hdmi
> >>> encoder driver a bit smarter by observing the DT connections. If
> >>> it's output port is connected to just a hdmi-connector, then
> >>> things should be as before. If the output is connected to the DP
> >>> bridge, then it should create a DP connector. The connector ops
> >>> for the DP connector can still be the same as that of the HDMI
> >>> connector before, but the phandle to the DDC bus would be in the
> >>> DP device node in this case.
> >>
> >>
> >> I think it'd be a bit weird to have the DDC bus phandle on the DP
> >> connector, as we're not reading the EDID on the DP side of the bridge,
> >> but on the HDMI side (and the bridge can do all sort of things to the
> >> EDID: At the very least, I think it caches it).
>>
> > On the board, do the DDC lines join directly from the SoC pins to the
> > DP connector, or does it go via the ANX7688 chip?
> 
> The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)

The anx7688 should get the i2c-ddc-bus property then, and the driver
should use it to implement get_modes (or its bridge API equivalent, once
it exists).

> > Even with the current bindings (referred from the link below), the
> > hdmi connector has the DDC node. Shouldn't it be the same in the DP
> > case too? The DP connector, like before, is still manged by the HDMI
> > driver, the only difference being the name and that it's two hops away
> > in the DT bindings.
> >
> > https://patchwork.kernel.org/patch/9137089/
> 
> True, the bindings say so, but the current code actually looks for
> ddc-i2c-bus property in whatever is connected on the endpoint (be it a
> bridge or a connector).

The HDMI driver only handles this itself because there are no separate
connector drivers (or helpers) to do this. Ideally the HDMI driver
shouldn't have to parse the connector DT node.

> And again, a bit odd as DP connector does not have true I2C lines...
> 
> Phillip? Any opinion?

Make the HDMI driver leave the bridges' DT node alone and let the bridge
handle DDC, if that's where it is connected physically.

regards
Philipp

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-22  8:51         ` Philipp Zabel
@ 2016-06-23  4:08           ` Nicolas Boichat
  2016-06-23  9:18             ` Philipp Zabel
  0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Boichat @ 2016-06-23  4:08 UTC (permalink / raw)
  To: Philipp Zabel
  Cc: Archit Taneja, dri-devel, Stéphane Marchesin, linux-kernel,
	Enric Balletbo i Serra, Russell King, Thierry Reding

Hi Philipp,

On Wed, Jun 22, 2016 at 4:51 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Nicolas,
>
> Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat:
>> >> Actually, experimenting a bit more with the code, I realized that the
>> >> connector is always attached to the encoder, not the bridge, so the 2
>> >> layouts above are actually identical (from the userspace point of
>> >> view). Except that the connector name should be HDMI in one case, and
>> >> DP in the other. But I think that's mostly a cosmetic difference?
>> >
>> >
>> > Yeah, probably. I don't know what exactly the userspace does with
>> > the connector type, but it would be nice to represent it as a DP
>> > connector in case it makes any decisions based on it.
>>
>> AFAICT does not matter... And, in any case, USB-C to HDMI adapters are
>> far more common (so we'd do HDMI->(DP over USB-C)->HDMI....), so there
>> is a high change that advertising as DP would be wrong (and
>> advertising as HDMI would be correct by chance...).
>
> If anything it should be represented as an USB-C connector, whatever
> USB-C(DP)->HDMI->VGA adapter chain is connected externally shouldn't
> matter.

Indeed, looks like we could just create a new connector type.

>> >>> One way I can think of fixing this is to make make the MTK hdmi
>> >>> encoder driver a bit smarter by observing the DT connections. If
>> >>> it's output port is connected to just a hdmi-connector, then
>> >>> things should be as before. If the output is connected to the DP
>> >>> bridge, then it should create a DP connector. The connector ops
>> >>> for the DP connector can still be the same as that of the HDMI
>> >>> connector before, but the phandle to the DDC bus would be in the
>> >>> DP device node in this case.
>> >>
>> >>
>> >> I think it'd be a bit weird to have the DDC bus phandle on the DP
>> >> connector, as we're not reading the EDID on the DP side of the bridge,
>> >> but on the HDMI side (and the bridge can do all sort of things to the
>> >> EDID: At the very least, I think it caches it).
>>>
>> > On the board, do the DDC lines join directly from the SoC pins to the
>> > DP connector, or does it go via the ANX7688 chip?
>>
>> The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)
>
> The anx7688 should get the i2c-ddc-bus property then, and the driver
> should use it to implement get_modes (or its bridge API equivalent, once
> it exists).

Ok, I can do that (I tried it). It's a lot a duplication from the
existing connector in mtk-hdmi, but I understand there may not be a
better way currently.

However, the problem I'm facing is how to implement "detect" in the
connector function. I'm still getting the interrupts from the MTK cec
module (so the detect function gets called), but then I don't see a
good way to read the HPD status (ANX7688 does not have a register for
that: it passes the HPD signal downstream).

mtk_hdmi implements detect this way:
        return mtk_cec_hpd_high(hdmi->cec_dev) ?
               connector_status_connected : connector_status_disconnected;

But of course I can't call this function from the ANX7688 bridge driver...

>> > Even with the current bindings (referred from the link below), the
>> > hdmi connector has the DDC node. Shouldn't it be the same in the DP
>> > case too? The DP connector, like before, is still manged by the HDMI
>> > driver, the only difference being the name and that it's two hops away
>> > in the DT bindings.
>> >
>> > https://patchwork.kernel.org/patch/9137089/
>>
>> True, the bindings say so, but the current code actually looks for
>> ddc-i2c-bus property in whatever is connected on the endpoint (be it a
>> bridge or a connector).
>
> The HDMI driver only handles this itself because there are no separate
> connector drivers (or helpers) to do this. Ideally the HDMI driver
> shouldn't have to parse the connector DT node.
>
>> And again, a bit odd as DP connector does not have true I2C lines...
>>
>> Phillip? Any opinion?
>
> Make the HDMI driver leave the bridges' DT node alone and let the bridge
> handle DDC, if that's where it is connected physically.

Again, a bit odd... AFAICT, all other bridge drivers, and encoders,
read EDID from a bus that is downstream of it. If we handle DDC in the
ANX driver, it'll have to read the EDID upstream (on the HDMI side),
as there is no way to read the EDID on the DP side on this chip.

> regards
> Philipp
>

Thanks!

Best,

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.
  2016-06-23  4:08           ` Nicolas Boichat
@ 2016-06-23  9:18             ` Philipp Zabel
  0 siblings, 0 replies; 9+ messages in thread
From: Philipp Zabel @ 2016-06-23  9:18 UTC (permalink / raw)
  To: Nicolas Boichat
  Cc: Archit Taneja, dri-devel, Stéphane Marchesin, linux-kernel,
	Enric Balletbo i Serra, Russell King, Thierry Reding

Am Donnerstag, den 23.06.2016, 12:08 +0800 schrieb Nicolas Boichat:
[...]
> >> >> I think it'd be a bit weird to have the DDC bus phandle on the DP
> >> >> connector, as we're not reading the EDID on the DP side of the bridge,
> >> >> but on the HDMI side (and the bridge can do all sort of things to the
> >> >> EDID: At the very least, I think it caches it).
> >>>
> >> > On the board, do the DDC lines join directly from the SoC pins to the
> >> > DP connector, or does it go via the ANX7688 chip?
> >>
> >> The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)
> >
> > The anx7688 should get the i2c-ddc-bus property then, and the driver
> > should use it to implement get_modes (or its bridge API equivalent, once
> > it exists).
> 
> Ok, I can do that (I tried it). It's a lot a duplication from the
> existing connector in mtk-hdmi, but I understand there may not be a
> better way currently.

Is there a thread where moving connectors back out of the bridge drivers
was discussed?

> However, the problem I'm facing is how to implement "detect" in the
> connector function. I'm still getting the interrupts from the MTK cec
> module (so the detect function gets called), but then I don't see a
> good way to read the HPD status (ANX7688 does not have a register for
> that: it passes the HPD signal downstream).
> 
> mtk_hdmi implements detect this way:
>         return mtk_cec_hpd_high(hdmi->cec_dev) ?
>                connector_status_connected : connector_status_disconnected;
> 
> But of course I can't call this function from the ANX7688 bridge driver...

If the bridge API is extended to get a .detect equivalent, the ANX7688
could just not implement it or return -ENOTSUPP to indicate HPD
passthrough and the mtk_hdmi connector could fall back to current
behaviour.

> >> > Even with the current bindings (referred from the link below), the
> >> > hdmi connector has the DDC node. Shouldn't it be the same in the DP
> >> > case too? The DP connector, like before, is still manged by the HDMI
> >> > driver, the only difference being the name and that it's two hops away
> >> > in the DT bindings.
> >> >
> >> > https://patchwork.kernel.org/patch/9137089/
> >>
> >> True, the bindings say so, but the current code actually looks for
> >> ddc-i2c-bus property in whatever is connected on the endpoint (be it a
> >> bridge or a connector).
> >
> > The HDMI driver only handles this itself because there are no separate
> > connector drivers (or helpers) to do this. Ideally the HDMI driver
> > shouldn't have to parse the connector DT node.
> >
> >> And again, a bit odd as DP connector does not have true I2C lines...
> >>
> >> Phillip? Any opinion?
> >
> > Make the HDMI driver leave the bridges' DT node alone and let the bridge
> > handle DDC, if that's where it is connected physically.
> 
> Again, a bit odd... AFAICT, all other bridge drivers, and encoders,
> read EDID from a bus that is downstream of it. If we handle DDC in the
> ANX driver, it'll have to read the EDID upstream (on the HDMI side),
> as there is no way to read the EDID on the DP side on this chip.

Well, the chip is a bit odd in that it seems to be intended to be
transparent to the software with the EDID and HPD passthrough, but then
still needs to have a driver.

regards
Philipp

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2016-06-23  9:19 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-20  7:14 [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Nicolas Boichat
2016-06-20  7:14 ` [RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding Nicolas Boichat
2016-06-21 15:39 ` [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support Archit Taneja
2016-06-22  2:44   ` Nicolas Boichat
2016-06-22  3:54     ` Archit Taneja
2016-06-22  6:32       ` Nicolas Boichat
2016-06-22  8:51         ` Philipp Zabel
2016-06-23  4:08           ` Nicolas Boichat
2016-06-23  9:18             ` Philipp Zabel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).