Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers
On 07/06/2016 07:28 AM, Nicolas Boichat wrote: Hi Archit, Sorry got swamped by other things and forgot to reply. On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja wrote: On 06/27/2016 01:18 PM, Nicolas Boichat wrote: Hi all, This is a follow up to the 2 patches to add support for ANX7688 sent here: https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for the comments. I also added 2 patches to add support for a simple display MUX, as I'm facing similar issues while trying to implement it, i.e. the current DRM core does not seem to support this kind of simple pass-thru bridge very well: it is not very clear where connectors should be defined and attached. In this case, not defining any connectors in the 2 bridges (and reusing the connector in MTK HDMI driver) seem to work best, but makes little logical sense as the physical connectors are actually attached to the bridges. Bridges aren't really drm objects in themselves, they can just be thought of as entities that attach to an encoder. From a drm perspective, the connector is only linked to an encoder. It doesn't see any bridges. Therefore, it doesn't matter much if the bridge driver doesn't create connectors. The DT bindings, however, should be close to the physical connections. In any case, the board has the following layout: - MT8173 HDMI bridge - HDMI mux with 2 ports 1. ANX7688 for HDMI->DP over USB-C conversion 2. Native HDMI So, the MTK SoC's HDMI output (TMDS lines) can be routed to the connector on the board directly (native mode), or via the ANX7688 bridge using the gpio mux. Did I get this part right? Yes. Is there only one connector at the end of both the output paths? Err, there are: - 2 physical connectors (HDMI, USB-C) - 1 DT connector in the device tree (native HDMI), I don't bother adding a connector to anx7688, but in theory I could. - 1 DRM connector object (defined in the mtk hdmi driver) The mux is controlled by hardware, looking at the HPD signals from both ANX7688 and native HDMI, with a priority on the native HDMI output. I didn't understand this. I can see that ANX7688 could generate a HPD signal on behalf of the connected monitor, but why would the native MTK HDMI controller generate a HPD signal? I would expect it to receive HPD and trigger a CPU interrupt. Could you also give an idea about why the hardware switches between the two paths? It it based on what kind of device plugs into the connector? The mux is controlled in hardware, by looking at both HPD lines: - USB-C (HPD controlled by ANX7688, depending if there is a DP over USB-C device connected) - native HDMI (HPD controlled by monitor on remote side) Note that, like the other HDMI lines, HPD is "muxed" (depending on the logic above), and wired up to MTK SoC HDMI/CEC module, which generates the interrupts. Priority is set to native HDMI port, so if both HPD signals are active, the output will stay on the HDMI port. Thanks for the clarification. It's a strange setup. It would be ideal to have 2 connectors visible to userspace, with only one of them being 'DRM_MODE_CONNECTED' at a time. There would be a bit of an overkill whenever userspace gets a hotplug event, resulting in tearing down and setting up crtcs, encoders even though nothing really changes much upstream. I think the mux bridge part looks fine, but I don't know what's the best way how to describe the connectors here :) (one drm_connector representing both the physical connectors, or 2 separate drm_connector entities which both can't be connected at the same time). Maybe someone else from the list could help us out here. Archit Best, Nicolas Thanks, Archit The whole setup works fairly well without any Linux kernel drivers, except the 2 following cases: 1. When ANX7688 is active, DP bandwidth may be limited, so we need to filter resolutions that would exceed the available bandwidth. 2. When both outputs HPD signals are active, the kernel does not receive an HPD pulse when the HDMI input is unplugged. ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel to re-read the EDID on mux output change, and also issue 1 by filtering only when ANX7688 is active. I understand this patch series might not be acceptable as-is, but I hope this sort of setup can be taken into account when better support for connector drivers is introduced. Thanks! Best, Nicolas Nicolas Boichat (4): drm: bridge: anx7688: Add anx7688 bridge driver support. devicetree: Add ANX7688 transmitter binding drm: bridge: Generic GPIO mux driver devicetree: Add GPIO display mux binding .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 drivers/gpu/drm/bridge/Kconfig | 20 ++ drivers/gpu/drm/bridge/Makefile| 2 + drivers/gpu/drm/bridge/analogix-anx7688.c | 233 +++
Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers
Hi Archit, Sorry got swamped by other things and forgot to reply. On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja wrote: > > > On 06/27/2016 01:18 PM, Nicolas Boichat wrote: >> >> Hi all, >> >> This is a follow up to the 2 patches to add support for ANX7688 sent here: >> https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for >> the comments. >> >> I also added 2 patches to add support for a simple display MUX, as I'm >> facing >> similar issues while trying to implement it, i.e. the current DRM core >> does not >> seem to support this kind of simple pass-thru bridge very well: it is not >> very >> clear where connectors should be defined and attached. In this case, not >> defining any connectors in the 2 bridges (and reusing the connector in MTK >> HDMI driver) seem to work best, but makes little logical sense as the >> physical >> connectors are actually attached to the bridges. > > > Bridges aren't really drm objects in themselves, they can just be > thought of as entities that attach to an encoder. From a drm > perspective, the connector is only linked to an encoder. It > doesn't see any bridges. Therefore, it doesn't matter much > if the bridge driver doesn't create connectors. The DT bindings, > however, should be close to the physical connections. > >> >> In any case, the board has the following layout: >> - MT8173 HDMI bridge >> - HDMI mux with 2 ports >> 1. ANX7688 for HDMI->DP over USB-C conversion >> 2. Native HDMI >> > > So, the MTK SoC's HDMI output (TMDS lines) can be routed to the > connector on the board directly (native mode), or via the ANX7688 > bridge using the gpio mux. Did I get this part right? Yes. > Is there only one connector at the end of both the output paths? Err, there are: - 2 physical connectors (HDMI, USB-C) - 1 DT connector in the device tree (native HDMI), I don't bother adding a connector to anx7688, but in theory I could. - 1 DRM connector object (defined in the mtk hdmi driver) >> The mux is controlled by hardware, looking at the HPD signals from both >> ANX7688 >> and native HDMI, with a priority on the native HDMI output. > > > I didn't understand this. I can see that ANX7688 could generate a HPD > signal on behalf of the connected monitor, but why would the native MTK > HDMI controller generate a HPD signal? I would expect it to receive HPD > and trigger a CPU interrupt. > > Could you also give an idea about why the hardware switches between the > two paths? It it based on what kind of device plugs into the connector? The mux is controlled in hardware, by looking at both HPD lines: - USB-C (HPD controlled by ANX7688, depending if there is a DP over USB-C device connected) - native HDMI (HPD controlled by monitor on remote side) Note that, like the other HDMI lines, HPD is "muxed" (depending on the logic above), and wired up to MTK SoC HDMI/CEC module, which generates the interrupts. Priority is set to native HDMI port, so if both HPD signals are active, the output will stay on the HDMI port. Best, Nicolas > Thanks, > Archit > > >> >> The whole setup works fairly well without any Linux kernel drivers, except >> the >> 2 following cases: >> 1. When ANX7688 is active, DP bandwidth may be limited, so we need to >> filter >> resolutions that would exceed the available bandwidth. >> 2. When both outputs HPD signals are active, the kernel does not receive >> an >> HPD pulse when the HDMI input is unplugged. >> >> ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel >> to >> re-read the EDID on mux output change, and also issue 1 by filtering only >> when >> ANX7688 is active. >> >> I understand this patch series might not be acceptable as-is, but I hope >> this >> sort of setup can be taken into account when better support for connector >> drivers is introduced. >> >> Thanks! >> >> Best, >> >> Nicolas >> >> Nicolas Boichat (4): >>drm: bridge: anx7688: Add anx7688 bridge driver support. >>devicetree: Add ANX7688 transmitter binding >>drm: bridge: Generic GPIO mux driver >>devicetree: Add GPIO display mux binding >> >> .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ >> .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 >> drivers/gpu/drm/bridge/Kconfig | 20 ++ >> drivers/gpu/drm/bridge/Makefile| 2 + >> drivers/gpu/drm/bridge/analogix-anx7688.c | 233 ++ >> drivers/gpu/drm/bridge/generic-gpio-mux.c | 347 >> + >> 6 files changed, 693 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/drm/bridge/anx7688.txt >> create mode 100644 >> Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt >> create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c >> create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c >> > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Colla
Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers
On 06/27/2016 01:18 PM, Nicolas Boichat wrote: Hi all, This is a follow up to the 2 patches to add support for ANX7688 sent here: https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for the comments. I also added 2 patches to add support for a simple display MUX, as I'm facing similar issues while trying to implement it, i.e. the current DRM core does not seem to support this kind of simple pass-thru bridge very well: it is not very clear where connectors should be defined and attached. In this case, not defining any connectors in the 2 bridges (and reusing the connector in MTK HDMI driver) seem to work best, but makes little logical sense as the physical connectors are actually attached to the bridges. Bridges aren't really drm objects in themselves, they can just be thought of as entities that attach to an encoder. From a drm perspective, the connector is only linked to an encoder. It doesn't see any bridges. Therefore, it doesn't matter much if the bridge driver doesn't create connectors. The DT bindings, however, should be close to the physical connections. In any case, the board has the following layout: - MT8173 HDMI bridge - HDMI mux with 2 ports 1. ANX7688 for HDMI->DP over USB-C conversion 2. Native HDMI So, the MTK SoC's HDMI output (TMDS lines) can be routed to the connector on the board directly (native mode), or via the ANX7688 bridge using the gpio mux. Did I get this part right? Is there only one connector at the end of both the output paths? The mux is controlled by hardware, looking at the HPD signals from both ANX7688 and native HDMI, with a priority on the native HDMI output. I didn't understand this. I can see that ANX7688 could generate a HPD signal on behalf of the connected monitor, but why would the native MTK HDMI controller generate a HPD signal? I would expect it to receive HPD and trigger a CPU interrupt. Could you also give an idea about why the hardware switches between the two paths? It it based on what kind of device plugs into the connector? Thanks, Archit The whole setup works fairly well without any Linux kernel drivers, except the 2 following cases: 1. When ANX7688 is active, DP bandwidth may be limited, so we need to filter resolutions that would exceed the available bandwidth. 2. When both outputs HPD signals are active, the kernel does not receive an HPD pulse when the HDMI input is unplugged. ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel to re-read the EDID on mux output change, and also issue 1 by filtering only when ANX7688 is active. I understand this patch series might not be acceptable as-is, but I hope this sort of setup can be taken into account when better support for connector drivers is introduced. Thanks! Best, Nicolas Nicolas Boichat (4): drm: bridge: anx7688: Add anx7688 bridge driver support. devicetree: Add ANX7688 transmitter binding drm: bridge: Generic GPIO mux driver devicetree: Add GPIO display mux binding .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 drivers/gpu/drm/bridge/Kconfig | 20 ++ drivers/gpu/drm/bridge/Makefile| 2 + drivers/gpu/drm/bridge/analogix-anx7688.c | 233 ++ drivers/gpu/drm/bridge/generic-gpio-mux.c | 347 + 6 files changed, 693 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/anx7688.txt create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers
Hi all, This is a follow up to the 2 patches to add support for ANX7688 sent here: https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for the comments. I also added 2 patches to add support for a simple display MUX, as I'm facing similar issues while trying to implement it, i.e. the current DRM core does not seem to support this kind of simple pass-thru bridge very well: it is not very clear where connectors should be defined and attached. In this case, not defining any connectors in the 2 bridges (and reusing the connector in MTK HDMI driver) seem to work best, but makes little logical sense as the physical connectors are actually attached to the bridges. In any case, the board has the following layout: - MT8173 HDMI bridge - HDMI mux with 2 ports 1. ANX7688 for HDMI->DP over USB-C conversion 2. Native HDMI The mux is controlled by hardware, looking at the HPD signals from both ANX7688 and native HDMI, with a priority on the native HDMI output. The whole setup works fairly well without any Linux kernel drivers, except the 2 following cases: 1. When ANX7688 is active, DP bandwidth may be limited, so we need to filter resolutions that would exceed the available bandwidth. 2. When both outputs HPD signals are active, the kernel does not receive an HPD pulse when the HDMI input is unplugged. ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel to re-read the EDID on mux output change, and also issue 1 by filtering only when ANX7688 is active. I understand this patch series might not be acceptable as-is, but I hope this sort of setup can be taken into account when better support for connector drivers is introduced. Thanks! Best, Nicolas Nicolas Boichat (4): drm: bridge: anx7688: Add anx7688 bridge driver support. devicetree: Add ANX7688 transmitter binding drm: bridge: Generic GPIO mux driver devicetree: Add GPIO display mux binding .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 drivers/gpu/drm/bridge/Kconfig | 20 ++ drivers/gpu/drm/bridge/Makefile| 2 + drivers/gpu/drm/bridge/analogix-anx7688.c | 233 ++ drivers/gpu/drm/bridge/generic-gpio-mux.c | 347 + 6 files changed, 693 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/anx7688.txt create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c -- 2.8.0.rc3.226.g39d4020
