From: Hans Verkuil hans.verkuil@cisco.com
This patch series adds support for the OMAP4 HDMI CEC IP core.
Most of the patches leading up to the actual CEC implementation make changes to the HDMI core support. The reason for this is that CEC has to be enabled even if the HPD is low: some displays will set the HPD low when they go into standby or when they switch to another input, but CEC is still available and able to wake up/change input for such a display.
This corner case is explicitly allowed by the CEC standard, and such displays really exist, even in modern displays.
So CEC has to be able to wake up the HDMI core, even when there is no HPD.
I also looked at implementing CEC monitoring (i.e. 'snooping' the CEC bus for messages between other CEC devices), but I couldn't figure that out. The omap4 datasheet does not give sufficient information on how it is supposed to work. There is a CEC_SN bit in CEC_DBG_3 and a 'CEC Snoop Initiator' field in CEC_DBG_2, but no information on how to use those registers. Trying to enable CEC_SN gave me weird results, so I decided to leave that feature out.
Links to CEC documentation and utilities:
Public API:
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/cec/cec-api.html
Kernel API:
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/kapi/cec-core.html
CEC utilities (esp. cec-ctl):
https://git.linuxtv.org/v4l-utils.git/ (master branch)
To test:
First configure the CEC adapter as a playback device:
cec-ctl --playback
Then detect and query any other CEC devices, such as a CEC-enabled display:
cec-ctl -S
Regards,
Hans
Hans Verkuil (8): arm: omap4: enable CEC pin for Pandaboard A4 and ES omapdrm: encoder-tpd12s015: keep ls_oe_gpio high if CEC is enabled omapdrm: hdmi.h: extend hdmi_core_data with CEC fields omapdrm: hdmi4: make low-level functions available omapdrm: hdmi4: prepare irq handling for HDMI CEC support omapdrm: hdmi4: refcount hdmi_power_on/off_core omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support omapdrm: hdmi4: hook up the HDMI CEC support
arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- arch/arm/boot/dts/omap4-panda-es.dts | 2 +- .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 + drivers/gpu/drm/omapdrm/dss/Kconfig | 9 + drivers/gpu/drm/omapdrm/dss/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/hdmi.h | 6 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 58 +++- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 381 +++++++++++++++++++++ drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 55 +++ drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 6 +- drivers/gpu/drm/omapdrm/dss/hdmi4_core.h | 4 + 11 files changed, 513 insertions(+), 19 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
Change to PIN_INPUT so it can be used by the new CEC support.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- arch/arm/boot/dts/omap4-panda-es.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts index 78d363177762..f1a6476af371 100644 --- a/arch/arm/boot/dts/omap4-panda-a4.dts +++ b/arch/arm/boot/dts/omap4-panda-a4.dts @@ -13,7 +13,7 @@ /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = < - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >; diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 119f8e657edc..940fe4f7c5f6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -34,7 +34,7 @@ /* PandaboardES has external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = < - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >;
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
Change to PIN_INPUT so it can be used by the new CEC support.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com
arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- arch/arm/boot/dts/omap4-panda-es.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts index 78d363177762..f1a6476af371 100644 --- a/arch/arm/boot/dts/omap4-panda-a4.dts +++ b/arch/arm/boot/dts/omap4-panda-a4.dts @@ -13,7 +13,7 @@ /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = <
OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */
OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */
;diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 119f8e657edc..940fe4f7c5f6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -34,7 +34,7 @@ /* PandaboardES has external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = <
OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */
OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */
;
Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
Tomi
* Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
Change to PIN_INPUT so it can be used by the new CEC support.
...
Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
Sure will do.
Thanks,
Tony
Hi,
On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote:
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
Change to PIN_INPUT so it can be used by the new CEC support.
...
Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
Sure will do.
I guess the same patch should be applied to Droid 4?
-- Sebastian
* Sebastian Reichel sre@kernel.org [170428 11:29]:
Hi,
On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote:
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
Change to PIN_INPUT so it can be used by the new CEC support.
...
Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
Sure will do.
I guess the same patch should be applied to Droid 4?
I guess it depends if there is an external pull or not. If there's an external pull, the internal pull needs to be disabled as otherwise the resistors are parallel and pull value is much lower than intended.
Looks like on droid 4 we have:
$ grep 09a /sys/kernel/debug/pinctrl/4a100040.pinmux/pins pin 45 (PIN45) 4a10009a 00000118 pinctrl-single
$ grep PULL_ENA ./include/dt-bindings/pinctrl/omap.h #define PULL_ENA (1 << 3) ...
So bit 3 is set and internal pull is enabled in pinmux_dss_hdmi_pins for droid 4 also.
The pull seems to be enabled in the Android kernel too:
# rwmem -s16 0x4a10009a 0x4a10009a = 0x0118
So needs to be tested, what's the simplest test to check the CEC?
Hmm I wonder if disabling the internal pull also allows removing the "regulator-always-on" hack for hdmi_regulator there? Without regulator-always-on I noticed that HDMI panel resolutions are not detected. This I can test easily..
Regards,
Tony
* Tony Lindgren tony@atomide.com [170428 11:57]:
The pull seems to be enabled in the Android kernel too:
# rwmem -s16 0x4a10009a 0x4a10009a = 0x0118
So needs to be tested, what's the simplest test to check the CEC?
So on droid 4, with the internal pull enabled cec-ctl -m does not show anything. With the internal pull disabled, cec-ctl -m produces the following with a lapdock:
Initial Event: State Change: PA: 1.0.0.0, LA mask: 0x4000
Event: State Change: PA: f.f.f.f, LA mask: 0x0000
Event: State Change: PA: 1.0.0.0, LA mask: 0x0000 Transmitted by Specific to Specific (14 to 14): CEC_MSG_POLL Tx, Not Acknowledged (4), Max Retries
Event: State Change: PA: 1.0.0.0, LA mask: 0x4000 Transmitted by Specific to all (14 to 15): CEC_MSG_REPORT_FEATURES (0xa6): cec-version: version-2-0 (0x06) all-device-types: switch (0x04) rc-profile: tv-profile-none (0x00) dev-features: 0 (0x00) Transmitted by Specific to all (14 to 15): CEC_MSG_REPORT_PHYSICAL_ADDR (0x84): phys-addr: 1.0.0.0 prim-devtype: processor (0x07)
And looking at the ifixit.com board picture, there seems to be a IP4791CZ12 chip on droid 4. And it's docs seem to hint it has a pull in the IP4791CZ12.
So yeah my guess is the cec internal pull should be disabled on all omap4 devices with HDMI. I'll send a follow-up patch for that.
Hmm I wonder if disabling the internal pull also allows removing the "regulator-always-on" hack for hdmi_regulator there? Without regulator-always-on I noticed that HDMI panel resolutions are not detected. This I can test easily..
The regulator-fixed is still needed, I think this GPIO regulator powers the IP4791CZ12 which has no control channel. Not sure if we should still have encoder-ip4791cz12.c driver for it just to manage the regulator?
Regards,
Tony
Tomi,
* Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
...
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next?
Regards,
Tony
On 26/06/17 13:07, Tony Lindgren wrote:
Tomi,
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
...
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next?
Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review.
Tomi, any updates on this? It would be nice to get this in for 4.14.
Regards,
Hans
* Hans Verkuil hverkuil@xs4all.nl [170627 01:39]:
On 26/06/17 13:07, Tony Lindgren wrote:
Tomi,
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
...
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next?
Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review.
OK thanks for the update.
Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :)
Tomi, any updates on this? It would be nice to get this in for 4.14.
Yeah seems like we have real mainline kernel user needs for this one.
Regards,
Tony
On 06/27/17 12:14, Tony Lindgren wrote:
- Hans Verkuil hverkuil@xs4all.nl [170627 01:39]:
On 26/06/17 13:07, Tony Lindgren wrote:
Tomi,
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
...
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next?
Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review.
OK thanks for the update.
Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :)
As long as you do not expect a regular ALSA-volume to work.. But I don't see why some CEC application would not work. However, I guess one could implement this as feature to ALSA too but AFAIK no such thing exists at the moment.
Best regards, Jyri
Tomi, any updates on this? It would be nice to get this in for 4.14.
Yeah seems like we have real mainline kernel user needs for this one.
Regards,
Tony
On 27/06/17 11:14, Tony Lindgren wrote:
- Hans Verkuil hverkuil@xs4all.nl [170627 01:39]:
On 26/06/17 13:07, Tony Lindgren wrote:
Tomi,
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
...
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next?
Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review.
OK thanks for the update.
Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :)
I'm not quite sure what you mean. Do you want CEC to change the volume on the TV, or use the TV's remote to change the volume of the HDMI audio output of the omap4?
Anyway, either is supported, but it requires a userspace implementation.
Although TV remote control messages will be mapped to an input device, and if those are hooked up to the alsa audio volume, then this already works.
Regards,
Hans
Tomi, any updates on this? It would be nice to get this in for 4.14.
Yeah seems like we have real mainline kernel user needs for this one.
Regards,
Tony
On 06/27/17 12:27, Hans Verkuil wrote:
On 27/06/17 11:14, Tony Lindgren wrote:
- Hans Verkuil hverkuil@xs4all.nl [170627 01:39]:
On 26/06/17 13:07, Tony Lindgren wrote:
Tomi,
- Tomi Valkeinen tomi.valkeinen@ti.com [170428 04:15]:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The CEC pin was always pulled up, making it impossible to use it.
...
Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work.
So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next?
Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review.
OK thanks for the update.
Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :)
I'm not quite sure what you mean. Do you want CEC to change the volume on the TV, or use the TV's remote to change the volume of the HDMI audio output of the omap4?
There is no real volume on HDMI audio output as it is a digital interface, but it should be possible to provide some volume control using TV's volume trough CEC.
Anyway, either is supported, but it requires a userspace implementation.
A module to pulseaudio or some extra features to alsa-lib should be generic enough (who knows, maybe there is already something).
Just an idea. If someone really needs this, the pieces to put it together should be there.
Best regards, Jyri
Although TV remote control messages will be mapped to an input device, and if those are hooked up to the alsa audio volume, then this already works.
Regards,
Hans
Tomi, any updates on this? It would be nice to get this in for 4.14.
Yeah seems like we have real mainline kernel user needs for this one.
Regards,
Tony
* Jyri Sarha jsarha@ti.com [170627 02:47]:
There is no real volume on HDMI audio output as it is a digital interface, but it should be possible to provide some volume control using TV's volume trough CEC.
OK great!
Tony
* Hans Verkuil hverkuil@xs4all.nl [170627 02:27]:
On 27/06/17 11:14, Tony Lindgren wrote:
Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :)
I'm not quite sure what you mean. Do you want CEC to change the volume on the TV, or use the TV's remote to change the volume of the HDMI audio output of the omap4?
I'm hoping to change audio volume on a USB+HDMI lapdock from omap4.
Anyway, either is supported, but it requires a userspace implementation.
Although TV remote control messages will be mapped to an input device, and if those are hooked up to the alsa audio volume, then this already works.
OK great thanks,
Tony
From: Hans Verkuil hans.verkuil@cisco.com
When the OMAP4 CEC support is enabled the CEC pin should always be on. So keep ls_oe_gpio high when CONFIG_OMAP4_DSS_HDMI_CEC is set.
Background: even if the HPD is low it should still be possible to use CEC. Some displays will set the HPD low when they go into standby or when they switch to another input, but CEC is still available and able to wake up/change input for such a display.
This is explicitly allowed by the CEC standard.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c index 58276a48112e..757554e6d62f 100644 --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c @@ -46,6 +46,9 @@ static int tpd_connect(struct omap_dss_device *dssdev, dssdev->dst = dst;
gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1); +#ifdef CONFIG_OMAP4_DSS_HDMI_CEC + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1); +#endif /* DC-DC converter needs at max 300us to get to 90% of 5V */ udelay(300);
@@ -64,6 +67,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev, return;
gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0); + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
dst->src = NULL; dssdev->dst = NULL; @@ -146,11 +150,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev, if (!gpiod_get_value_cansleep(ddata->hpd_gpio)) return -ENODEV;
+#ifndef CONFIG_OMAP4_DSS_HDMI_CEC gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1); +#endif
r = in->ops.hdmi->read_edid(in, edid, len);
+#ifndef CONFIG_OMAP4_DSS_HDMI_CEC gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0); +#endif
return r; }
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
When the OMAP4 CEC support is enabled the CEC pin should always be on. So keep ls_oe_gpio high when CONFIG_OMAP4_DSS_HDMI_CEC is set.
Background: even if the HPD is low it should still be possible to use CEC. Some displays will set the HPD low when they go into standby or when they switch to another input, but CEC is still available and able to wake up/change input for such a display.
This is explicitly allowed by the CEC standard.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com
drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c index 58276a48112e..757554e6d62f 100644 --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c @@ -46,6 +46,9 @@ static int tpd_connect(struct omap_dss_device *dssdev, dssdev->dst = dst;
gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1); +#ifdef CONFIG_OMAP4_DSS_HDMI_CEC
- gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1);
+#endif /* DC-DC converter needs at max 300us to get to 90% of 5V */ udelay(300);
@@ -64,6 +67,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev, return;
gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
dst->src = NULL; dssdev->dst = NULL;
@@ -146,11 +150,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev, if (!gpiod_get_value_cansleep(ddata->hpd_gpio)) return -ENODEV;
+#ifndef CONFIG_OMAP4_DSS_HDMI_CEC gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1); +#endif
r = in->ops.hdmi->read_edid(in, edid, len);
+#ifndef CONFIG_OMAP4_DSS_HDMI_CEC gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0); +#endif
return r; }
Optimally, we want to enable LS_OE only when needed, which would be when reading EDID, using HDCP, or using CEC. But we don't have good means to convey that information at the moment, and I'd rather leave it for later when we have done the bigger restructuring of omapdrm.
For now, instead of the ifdef-confusion, I think we should just enable the LS_OE in tpd_connect and be done with it.
Tomi
From: Hans Verkuil hans.verkuil@cisco.com
Extend the hdmi_core_data struct with the additional fields needed for CEC.
Also fix a simple typo in a comment.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/dss/hdmi.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h b/drivers/gpu/drm/omapdrm/dss/hdmi.h index fb6cccd02374..3913859146b9 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi.h +++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h @@ -24,6 +24,7 @@ #include <linux/platform_device.h> #include <linux/hdmi.h> #include <sound/omap-hdmi-audio.h> +#include <media/cec.h>
#include "omapdss.h" #include "dss.h" @@ -254,6 +255,9 @@ struct hdmi_phy_data {
struct hdmi_core_data { void __iomem *base; + struct hdmi_wp_data *wp; + unsigned int core_pwr_cnt; + struct cec_adapter *adap; };
static inline void hdmi_write_reg(void __iomem *base_addr, const u32 idx, @@ -361,7 +365,7 @@ struct omap_hdmi { bool audio_configured; struct omap_dss_audio audio_config;
- /* This lock should be taken when booleans bellow are touched. */ + /* This lock should be taken when booleans below are touched. */ spinlock_t audio_playing_lock; bool audio_playing; bool display_enabled;
From: Hans Verkuil hans.verkuil@cisco.com
Three low-level functions in hdmi4.c and hdmi4_core.c are made available for use by the OMAP4 CEC support.
Renamed the prefix to hdmi4 since these are OMAP4 specific.
These function deal with the HDMI core and are needed to power it up for use with CEC, even when the HPD is low.
Background: even if the HPD is low it should still be possible to use CEC. Some displays will set the HPD low when they go into standby or when they switch to another input, but CEC is still available and able to wake up/change input for such a display.
This is explicitly allowed by the CEC standard.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 ++++++------ drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 6 +++--- drivers/gpu/drm/omapdrm/dss/hdmi4_core.h | 4 ++++ 3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index e7162c16de2e..bd6075e34c94 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -393,11 +393,11 @@ static void hdmi_display_disable(struct omap_dss_device *dssdev) mutex_unlock(&hdmi.lock); }
-static int hdmi_core_enable(struct omap_dss_device *dssdev) +int hdmi4_core_enable(struct omap_dss_device *dssdev) { int r = 0;
- DSSDBG("ENTER omapdss_hdmi_core_enable\n"); + DSSDBG("ENTER omapdss_hdmi4_core_enable\n");
mutex_lock(&hdmi.lock);
@@ -415,9 +415,9 @@ static int hdmi_core_enable(struct omap_dss_device *dssdev) return r; }
-static void hdmi_core_disable(struct omap_dss_device *dssdev) +void hdmi4_core_disable(struct omap_dss_device *dssdev) { - DSSDBG("Enter omapdss_hdmi_core_disable\n"); + DSSDBG("Enter omapdss_hdmi4_core_disable\n");
mutex_lock(&hdmi.lock);
@@ -475,7 +475,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, need_enable = hdmi.core_enabled == false;
if (need_enable) { - r = hdmi_core_enable(dssdev); + r = hdmi4_core_enable(dssdev); if (r) return r; } @@ -483,7 +483,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, r = read_edid(edid, len);
if (need_enable) - hdmi_core_disable(dssdev); + hdmi4_core_disable(dssdev);
return r; } diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index e05b7ac4f7dd..130b6dc3f184 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c @@ -208,9 +208,9 @@ static void hdmi_core_init(struct hdmi_core_video_config *video_cfg) video_cfg->tclk_sel_clkmult = HDMI_FPLL10IDCK; }
-static void hdmi_core_powerdown_disable(struct hdmi_core_data *core) +void hdmi4_core_powerdown_disable(struct hdmi_core_data *core) { - DSSDBG("Enter hdmi_core_powerdown_disable\n"); + DSSDBG("Enter hdmi4_core_powerdown_disable\n"); REG_FLD_MOD(core->base, HDMI_CORE_SYS_SYS_CTRL1, 0x1, 0, 0); }
@@ -336,7 +336,7 @@ void hdmi4_configure(struct hdmi_core_data *core, hdmi_core_swreset_assert(core);
/* power down off */ - hdmi_core_powerdown_disable(core); + hdmi4_core_powerdown_disable(core);
v_core_cfg.pkt_mode = HDMI_PACKETMODE24BITPERPIXEL; v_core_cfg.hdmi_dvi = cfg->hdmi_dvi_mode; diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h index a069f96ec6f6..b6ab579e44d2 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h @@ -266,6 +266,10 @@ void hdmi4_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s); int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core);
+int hdmi4_core_enable(struct omap_dss_device *dssdev); +void hdmi4_core_disable(struct omap_dss_device *dssdev); +void hdmi4_core_powerdown_disable(struct hdmi_core_data *core); + int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp); void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp); int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp,
From: Hans Verkuil hans.verkuil@cisco.com
Pass struct omap_hdmi to the irq handler since it will need access to hdmi.core.
Do not clear the IRQ_HDMI_CORE bit: that will be controlled by the HDMI CEC code.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index bd6075e34c94..4a164dc01f15 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -70,7 +70,8 @@ static void hdmi_runtime_put(void)
static irqreturn_t hdmi_irq_handler(int irq, void *data) { - struct hdmi_wp_data *wp = data; + struct omap_hdmi *hdmi = data; + struct hdmi_wp_data *wp = &hdmi->wp; u32 irqstatus;
irqstatus = hdmi_wp_get_irqstatus(wp); @@ -166,8 +167,8 @@ static int hdmi_power_on_full(struct omap_dss_device *dssdev) return r;
/* disable and clear irqs */ - hdmi_wp_clear_irqenable(wp, 0xffffffff); - hdmi_wp_set_irqstatus(wp, 0xffffffff); + hdmi_wp_clear_irqenable(wp, ~HDMI_IRQ_CORE); + hdmi_wp_set_irqstatus(wp, ~HDMI_IRQ_CORE);
vm = &hdmi.cfg.vm;
@@ -242,7 +243,7 @@ static void hdmi_power_off_full(struct omap_dss_device *dssdev) { enum omap_channel channel = dssdev->dispc_channel;
- hdmi_wp_clear_irqenable(&hdmi.wp, 0xffffffff); + hdmi_wp_clear_irqenable(&hdmi.wp, ~HDMI_IRQ_CORE);
hdmi_wp_video_stop(&hdmi.wp);
@@ -726,7 +727,7 @@ static int hdmi4_bind(struct device *dev, struct device *master, void *data)
r = devm_request_threaded_irq(&pdev->dev, irq, NULL, hdmi_irq_handler, - IRQF_ONESHOT, "OMAP HDMI", &hdmi.wp); + IRQF_ONESHOT, "OMAP HDMI", &hdmi); if (r) { DSSERR("HDMI IRQ request failed\n"); goto err;
From: Hans Verkuil hans.verkuil@cisco.com
The hdmi_power_on/off_core functions can be called multiple times: when the HPD changes and when the HDMI CEC support needs to power the HDMI core.
So use a counter to know when to really power on or off the HDMI core.
Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to power up the HDMI core (needed for CEC).
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index 4a164dc01f15..e371b47ff6ff 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) { int r;
+ if (hdmi.core.core_pwr_cnt++) + return 0; + r = regulator_enable(hdmi.vdda_reg); if (r) - return r; + goto err_reg_enable;
r = hdmi_runtime_get(); if (r) goto err_runtime_get;
+ hdmi4_core_powerdown_disable(&hdmi.core); + /* Make selection of HDMI in DSS */ dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
@@ -141,12 +146,17 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev)
err_runtime_get: regulator_disable(hdmi.vdda_reg); +err_reg_enable: + hdmi.core.core_pwr_cnt--;
return r; }
static void hdmi_power_off_core(struct omap_dss_device *dssdev) { + if (--hdmi.core.core_pwr_cnt) + return; + hdmi.core_enabled = false;
hdmi_runtime_put();
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The hdmi_power_on/off_core functions can be called multiple times: when the HPD changes and when the HDMI CEC support needs to power the HDMI core.
So use a counter to know when to really power on or off the HDMI core.
Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to power up the HDMI core (needed for CEC).
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index 4a164dc01f15..e371b47ff6ff 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) { int r;
- if (hdmi.core.core_pwr_cnt++)
return 0;
How's the locking between the CEC side and the DRM side? Normally these functions are protected with the DRM modesetting locks, but CEC doesn't come from there. We have the hdmi.lock, did you check that it's held when CEC side calls shared functions?
r = regulator_enable(hdmi.vdda_reg); if (r)
return r;
goto err_reg_enable;
r = hdmi_runtime_get(); if (r) goto err_runtime_get;
hdmi4_core_powerdown_disable(&hdmi.core);
I'd like to have the powerdown_disable as a separate patch. Also, now that you call it here, I believe it can be dropped from hdmi4_configure().
Hmm, but in hdmi4_configure we call hdmi_core_swreset_assert() before hdmi4_core_powerdown_disable(). I wonder what exactly that does, and whether we end up resetting also the CEC parts when we change the videomode.
Tomi
On 04/28/17 13:30, Tomi Valkeinen wrote:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
The hdmi_power_on/off_core functions can be called multiple times: when the HPD changes and when the HDMI CEC support needs to power the HDMI core.
So use a counter to know when to really power on or off the HDMI core.
Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to power up the HDMI core (needed for CEC).
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index 4a164dc01f15..e371b47ff6ff 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) { int r;
- if (hdmi.core.core_pwr_cnt++)
return 0;
How's the locking between the CEC side and the DRM side? Normally these functions are protected with the DRM modesetting locks, but CEC doesn't come from there. We have the hdmi.lock, did you check that it's held when CEC side calls shared functions?
Yes, the hdmi_power_on/off_core functions are all called from other functions with the hdmi.lock taken. The CEC code calls those higher level functions (hdmi4_core_enable/disable).
r = regulator_enable(hdmi.vdda_reg); if (r)
return r;
goto err_reg_enable;
r = hdmi_runtime_get(); if (r) goto err_runtime_get;
hdmi4_core_powerdown_disable(&hdmi.core);
I'd like to have the powerdown_disable as a separate patch.
Will do.
Also, now that you call it here, I believe it can be dropped from hdmi4_configure().
I was a bit scared of messing with that function. But if you say it can be removed, then who am I to argue? :-)
Hmm, but in hdmi4_configure we call hdmi_core_swreset_assert() before hdmi4_core_powerdown_disable(). I wonder what exactly that does, and whether we end up resetting also the CEC parts when we change the videomode.
Good one. I'll attempt to check this.
Regards,
Hans
Tomi
From: Hans Verkuil hans.verkuil@cisco.com
Add the source and header for the OMAP4 HDMI CEC support.
This code is not yet hooked up, that will happen in the next patch.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 381 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 55 +++++ 2 files changed, 436 insertions(+) create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c new file mode 100644 index 000000000000..d86873f2abe6 --- /dev/null +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c @@ -0,0 +1,381 @@ +/* + * HDMI CEC + * + * Based on the CEC code from hdmi_ti_4xxx_ip.c from Android. + * + * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ + * Authors: Yong Zhi + * Mythri pk mythripk@ti.com + * + * Heavily modified to use the linux CEC framework: + * + * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ + +#include <linux/kernel.h> +#include <linux/err.h> +#include <linux/io.h> +#include <linux/platform_device.h> +#include <linux/slab.h> + +#include "dss.h" +#include "hdmi.h" +#include "hdmi4_core.h" +#include "hdmi4_cec.h" + +/* HDMI CEC */ +#define HDMI_CEC_DEV_ID 0x900 +#define HDMI_CEC_SPEC 0x904 + +/* Not really a debug register, more a low-level control register */ +#define HDMI_CEC_DBG_3 0x91C +#define HDMI_CEC_TX_INIT 0x920 +#define HDMI_CEC_TX_DEST 0x924 +#define HDMI_CEC_SETUP 0x938 +#define HDMI_CEC_TX_COMMAND 0x93C +#define HDMI_CEC_TX_OPERAND 0x940 +#define HDMI_CEC_TRANSMIT_DATA 0x97C +#define HDMI_CEC_CA_7_0 0x988 +#define HDMI_CEC_CA_15_8 0x98C +#define HDMI_CEC_INT_STATUS_0 0x998 +#define HDMI_CEC_INT_STATUS_1 0x99C +#define HDMI_CEC_INT_ENABLE_0 0x990 +#define HDMI_CEC_INT_ENABLE_1 0x994 +#define HDMI_CEC_RX_CONTROL 0x9B0 +#define HDMI_CEC_RX_COUNT 0x9B4 +#define HDMI_CEC_RX_CMD_HEADER 0x9B8 +#define HDMI_CEC_RX_COMMAND 0x9BC +#define HDMI_CEC_RX_OPERAND 0x9C0 + +#define HDMI_CEC_TX_FIFO_INT_MASK 0x64 +#define HDMI_CEC_RETRANSMIT_CNT_INT_MASK 0x2 + +#define HDMI_CORE_CEC_RETRY 200 + +static void hdmi_cec_received_msg(struct hdmi_core_data *core) +{ + u32 cnt = hdmi_read_reg(core->base, HDMI_CEC_RX_COUNT) & 0xff; + + /* While there are CEC frames in the FIFO */ + while (cnt & 0x70) { + /* and the frame doesn't have an error */ + if (!(cnt & 0x80)) { + struct cec_msg msg = {}; + unsigned int i; + + /* then read the message */ + msg.len = cnt & 0xf; + msg.msg[0] = hdmi_read_reg(core->base, + HDMI_CEC_RX_CMD_HEADER); + msg.msg[1] = hdmi_read_reg(core->base, + HDMI_CEC_RX_COMMAND); + for (i = 0; i < msg.len; i++) { + unsigned int reg = HDMI_CEC_RX_OPERAND + i * 4; + + msg.msg[2 + i] = + hdmi_read_reg(core->base, reg); + } + msg.len += 2; + cec_received_msg(core->adap, &msg); + } + /* Clear the current frame from the FIFO */ + hdmi_write_reg(core->base, HDMI_CEC_RX_CONTROL, 1); + /* Wait until the current frame is cleared */ + while (hdmi_read_reg(core->base, HDMI_CEC_RX_CONTROL) & 1) + udelay(1); + /* + * Re-read the count register and loop to see if there are + * more messages in the FIFO. + */ + cnt = hdmi_read_reg(core->base, HDMI_CEC_RX_COUNT) & 0xff; + } +} + +static void hdmi_cec_transmit_fifo_empty(struct hdmi_core_data *core, u32 stat1) +{ + if (stat1 & 2) { + u32 dbg3 = hdmi_read_reg(core->base, HDMI_CEC_DBG_3); + + cec_transmit_done(core->adap, + CEC_TX_STATUS_NACK | + CEC_TX_STATUS_MAX_RETRIES, + 0, (dbg3 >> 4) & 7, 0, 0); + } else if (stat1 & 1) { + cec_transmit_done(core->adap, + CEC_TX_STATUS_ARB_LOST | + CEC_TX_STATUS_MAX_RETRIES, + 0, 0, 0, 0); + } else if (stat1 == 0) { + cec_transmit_done(core->adap, CEC_TX_STATUS_OK, + 0, 0, 0, 0); + } +} + +void hdmi4_cec_irq(struct hdmi_core_data *core) +{ + u32 stat0 = hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_0); + u32 stat1 = hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_1); + + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_0, stat0); + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_1, stat1); + + if (stat0 & 0x40) + REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7); + else if (stat0 & 0x24) + hdmi_cec_transmit_fifo_empty(core, stat1); + if (stat1 & 2) { + u32 dbg3 = hdmi_read_reg(core->base, HDMI_CEC_DBG_3); + + cec_transmit_done(core->adap, + CEC_TX_STATUS_NACK | + CEC_TX_STATUS_MAX_RETRIES, + 0, (dbg3 >> 4) & 7, 0, 0); + } else if (stat1 & 1) { + cec_transmit_done(core->adap, + CEC_TX_STATUS_ARB_LOST | + CEC_TX_STATUS_MAX_RETRIES, + 0, 0, 0, 0); + } + if (stat0 & 0x02) + hdmi_cec_received_msg(core); + if (stat1 & 0x3) + REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7); +} + +static bool hdmi_cec_clear_tx_fifo(struct cec_adapter *adap) +{ + struct hdmi_core_data *core = cec_get_drvdata(adap); + int retry = HDMI_CORE_CEC_RETRY; + int temp; + + REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7); + while (retry) { + temp = hdmi_read_reg(core->base, HDMI_CEC_DBG_3); + if (FLD_GET(temp, 7, 7) == 0) + break; + retry--; + } + return retry != 0; +} + +static bool hdmi_cec_clear_rx_fifo(struct cec_adapter *adap) +{ + struct hdmi_core_data *core = cec_get_drvdata(adap); + int retry = HDMI_CORE_CEC_RETRY; + int temp; + + hdmi_write_reg(core->base, HDMI_CEC_RX_CONTROL, 0x3); + retry = HDMI_CORE_CEC_RETRY; + while (retry) { + temp = hdmi_read_reg(core->base, HDMI_CEC_RX_CONTROL); + if (FLD_GET(temp, 1, 0) == 0) + break; + retry--; + } + return retry != 0; +} + +static int hdmi_cec_adap_enable(struct cec_adapter *adap, bool enable) +{ + struct hdmi_core_data *core = cec_get_drvdata(adap); + int temp, err; + + if (!enable) { + hdmi_write_reg(core->base, HDMI_CEC_INT_ENABLE_0, 0); + hdmi_write_reg(core->base, HDMI_CEC_INT_ENABLE_1, 0); + REG_FLD_MOD(core->base, HDMI_CORE_SYS_INTR_UNMASK4, 0, 3, 3); + hdmi_wp_clear_irqenable(core->wp, HDMI_IRQ_CORE); + hdmi_wp_set_irqstatus(core->wp, HDMI_IRQ_CORE); + hdmi4_core_disable(NULL); + return 0; + } + err = hdmi4_core_enable(NULL); + if (err) + return err; + + /* Clear TX FIFO */ + if (!hdmi_cec_clear_tx_fifo(adap)) { + pr_err("cec-%s: could not clear TX FIFO\n", adap->name); + return -EIO; + } + + /* Clear RX FIFO */ + if (!hdmi_cec_clear_rx_fifo(adap)) { + pr_err("cec-%s: could not clear RX FIFO\n", adap->name); + return -EIO; + } + + /* Clear CEC interrupts */ + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_1, + hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_1)); + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_0, + hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_0)); + + /* Enable HDMI core interrupts */ + hdmi_wp_set_irqenable(core->wp, HDMI_IRQ_CORE); + /* Unmask CEC interrupt */ + REG_FLD_MOD(core->base, HDMI_CORE_SYS_INTR_UNMASK4, 0x1, 3, 3); + /* + * Enable CEC interrupts: + * Transmit Buffer Full/Empty Change event + * Transmitter FIFO Empty event + * Receiver FIFO Not Empty event + */ + hdmi_write_reg(core->base, HDMI_CEC_INT_ENABLE_0, 0x26); + /* + * Enable CEC interrupts: + * RX FIFO Overrun Error event + * Short Pulse Detected event + * Frame Retransmit Count Exceeded event + * Start Bit Irregularity event + */ + hdmi_write_reg(core->base, HDMI_CEC_INT_ENABLE_1, 0x0f); + + /* cec calibration enable (self clearing) */ + hdmi_write_reg(core->base, HDMI_CEC_SETUP, 0x03); + msleep(20); + hdmi_write_reg(core->base, HDMI_CEC_SETUP, 0x04); + + temp = hdmi_read_reg(core->base, HDMI_CEC_SETUP); + if (FLD_GET(temp, 4, 4) != 0) { + temp = FLD_MOD(temp, 0, 4, 4); + hdmi_write_reg(core->base, HDMI_CEC_SETUP, temp); + + /* + * If we enabled CEC in middle of a CEC message on the bus, + * we could have start bit irregularity and/or short + * pulse event. Clear them now. + */ + temp = hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_1); + temp = FLD_MOD(0x0, 0x5, 2, 0); + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_1, temp); + } + return 0; +} + +static int hdmi_cec_adap_log_addr(struct cec_adapter *adap, u8 log_addr) +{ + struct hdmi_core_data *core = cec_get_drvdata(adap); + u32 v; + + if (log_addr == CEC_LOG_ADDR_INVALID) { + hdmi_write_reg(core->base, HDMI_CEC_CA_7_0, 0); + hdmi_write_reg(core->base, HDMI_CEC_CA_15_8, 0); + return 0; + } + if (log_addr <= 7) { + v = hdmi_read_reg(core->base, HDMI_CEC_CA_7_0); + v |= 1 << log_addr; + hdmi_write_reg(core->base, HDMI_CEC_CA_7_0, v); + } else { + v = hdmi_read_reg(core->base, HDMI_CEC_CA_15_8); + v |= 1 << (log_addr - 8); + hdmi_write_reg(core->base, HDMI_CEC_CA_15_8, v); + } + return 0; +} + +static int hdmi_cec_adap_transmit(struct cec_adapter *adap, u8 attempts, + u32 signal_free_time, struct cec_msg *msg) +{ + struct hdmi_core_data *core = cec_get_drvdata(adap); + int temp; + u32 i; + + /* Clear TX FIFO */ + if (!hdmi_cec_clear_tx_fifo(adap)) { + pr_err("cec-%s: could not clear TX FIFO for transmit\n", + adap->name); + return -EIO; + } + + /* Clear TX interrupts */ + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_0, + HDMI_CEC_TX_FIFO_INT_MASK); + + hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_1, + HDMI_CEC_RETRANSMIT_CNT_INT_MASK); + + /* Set the retry count */ + REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, attempts - 1, 6, 4); + + /* Set the initiator addresses */ + hdmi_write_reg(core->base, HDMI_CEC_TX_INIT, cec_msg_initiator(msg)); + + /* Set destination id */ + temp = cec_msg_destination(msg); + if (msg->len == 1) + temp |= 0x80; + hdmi_write_reg(core->base, HDMI_CEC_TX_DEST, temp); + if (msg->len == 1) + return 0; + + /* Setup command and arguments for the command */ + hdmi_write_reg(core->base, HDMI_CEC_TX_COMMAND, msg->msg[1]); + + for (i = 0; i < msg->len - 2; i++) + hdmi_write_reg(core->base, HDMI_CEC_TX_OPERAND + i * 4, + msg->msg[2 + i]); + + /* Operand count */ + hdmi_write_reg(core->base, HDMI_CEC_TRANSMIT_DATA, + (msg->len - 2) | 0x10); + return 0; +} + +static const struct cec_adap_ops hdmi_cec_adap_ops = { + .adap_enable = hdmi_cec_adap_enable, + .adap_log_addr = hdmi_cec_adap_log_addr, + .adap_transmit = hdmi_cec_adap_transmit, +}; + +void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa) +{ + cec_s_phys_addr(core->adap, pa, false); +} + +int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data *core, + struct hdmi_wp_data *wp) +{ + const u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS | + CEC_CAP_PASSTHROUGH | CEC_CAP_RC; + unsigned int ret; + + core->adap = cec_allocate_adapter(&hdmi_cec_adap_ops, core, + "omap4", caps, CEC_MAX_LOG_ADDRS); + ret = PTR_ERR_OR_ZERO(core->adap); + if (ret < 0) + return ret; + core->wp = wp; + + /* + * Initialize CEC clock divider: CEC needs 2MHz clock hence + * set the devider to 24 to get 48/24=2MHz clock + */ + REG_FLD_MOD(core->wp->base, HDMI_WP_CLK, 0x18, 5, 0); + + ret = cec_register_adapter(core->adap, &pdev->dev); + if (ret < 0) { + cec_delete_adapter(core->adap); + return ret; + } + return 0; +} + +void hdmi4_cec_uninit(struct hdmi_core_data *core) +{ + cec_unregister_adapter(core->adap); +} diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h new file mode 100644 index 000000000000..0292337c97cc --- /dev/null +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h @@ -0,0 +1,55 @@ +/* + * HDMI header definition for OMAP4 HDMI CEC IP + * + * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ + +#ifndef _HDMI4_CEC_H_ +#define _HDMI4_CEC_H_ + +struct hdmi_core_data; +struct hdmi_wp_data; +struct platform_device; + +/* HDMI CEC funcs */ +#ifdef CONFIG_OMAP4_DSS_HDMI_CEC +void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa); +void hdmi4_cec_irq(struct hdmi_core_data *core); +int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data *core, + struct hdmi_wp_data *wp); +void hdmi4_cec_uninit(struct hdmi_core_data *core); +#else +static inline void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16 pa) +{ +} + +static inline void hdmi4_cec_irq(struct hdmi_core_data *core) +{ +} + +static inline int hdmi4_cec_init(struct platform_device *pdev, + struct hdmi_core_data *core, + struct hdmi_wp_data *wp) +{ + return 0; +} + +static inline void hdmi4_cec_uninit(struct hdmi_core_data *core) +{ +} +#endif + +#endif
From: Hans Verkuil hans.verkuil@cisco.com
Hook up the HDMI CEC support in the hdmi4 driver.
It add the CEC irq handler, the CEC (un)init calls and tells the CEC implementation when the physical address changes.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com --- drivers/gpu/drm/omapdrm/dss/Kconfig | 9 +++++++++ drivers/gpu/drm/omapdrm/dss/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/hdmi4.c | 23 ++++++++++++++++++++++- 3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig b/drivers/gpu/drm/omapdrm/dss/Kconfig index d1fa730c7d54..d18e83902b74 100644 --- a/drivers/gpu/drm/omapdrm/dss/Kconfig +++ b/drivers/gpu/drm/omapdrm/dss/Kconfig @@ -71,9 +71,18 @@ config OMAP4_DSS_HDMI bool "HDMI support for OMAP4" default y select OMAP2_DSS_HDMI_COMMON + select MEDIA_CEC_EDID help HDMI support for OMAP4 based SoCs.
+config OMAP4_DSS_HDMI_CEC + bool "Enable HDMI CEC support for OMAP4" + depends on OMAP4_DSS_HDMI + select MEDIA_CEC_SUPPORT + default y + ---help--- + When selected the HDMI transmitter will support the CEC feature. + config OMAP5_DSS_HDMI bool "HDMI support for OMAP5" default n diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile b/drivers/gpu/drm/omapdrm/dss/Makefile index b651ec9751e6..d1c6acfbd134 100644 --- a/drivers/gpu/drm/omapdrm/dss/Makefile +++ b/drivers/gpu/drm/omapdrm/dss/Makefile @@ -11,5 +11,6 @@ omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \ hdmi_phy.o omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o +omapdss-$(CONFIG_OMAP4_DSS_HDMI_CEC) += hdmi4_cec.o omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index e371b47ff6ff..ebe5b27cee6f 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -35,9 +35,11 @@ #include <linux/component.h> #include <linux/of.h> #include <sound/omap-hdmi-audio.h> +#include <media/cec-edid.h>
#include "omapdss.h" #include "hdmi4_core.h" +#include "hdmi4_cec.h" #include "dss.h" #include "dss_features.h" #include "hdmi.h" @@ -96,6 +98,13 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data) } else if (irqstatus & HDMI_IRQ_LINK_DISCONNECT) { hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON); } + if (irqstatus & HDMI_IRQ_CORE) { + u32 intr4 = hdmi_read_reg(hdmi->core.base, HDMI_CORE_SYS_INTR4); + + hdmi_write_reg(hdmi->core.base, HDMI_CORE_SYS_INTR4, intr4); + if (intr4 & 8) + hdmi4_cec_irq(&hdmi->core); + }
return IRQ_HANDLED; } @@ -392,6 +401,8 @@ static void hdmi_display_disable(struct omap_dss_device *dssdev)
DSSDBG("Enter hdmi_display_disable\n");
+ hdmi4_cec_set_phys_addr(&hdmi.core, CEC_PHYS_ADDR_INVALID); + mutex_lock(&hdmi.lock);
spin_lock_irqsave(&hdmi.audio_playing_lock, flags); @@ -492,7 +503,11 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, }
r = read_edid(edid, len); - + if (r >= 256) + hdmi4_cec_set_phys_addr(&hdmi.core, + cec_get_edid_phys_addr(edid, r, NULL)); + else + hdmi4_cec_set_phys_addr(&hdmi.core, CEC_PHYS_ADDR_INVALID); if (need_enable) hdmi4_core_disable(dssdev);
@@ -728,6 +743,10 @@ static int hdmi4_bind(struct device *dev, struct device *master, void *data) if (r) goto err;
+ r = hdmi4_cec_init(pdev, &hdmi.core, &hdmi.wp); + if (r) + goto err; + irq = platform_get_irq(pdev, 0); if (irq < 0) { DSSERR("platform_get_irq failed\n"); @@ -772,6 +791,8 @@ static void hdmi4_unbind(struct device *dev, struct device *master, void *data)
hdmi_uninit_output(pdev);
+ hdmi4_cec_uninit(&hdmi.core); + hdmi_pll_uninit(&hdmi.pll);
pm_runtime_disable(&pdev->dev);
Hi Tomi,
I did some more testing, and I discovered a bug in this code, but I am not sure how to solve it.
On 04/14/2017 12:25 PM, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
Hook up the HDMI CEC support in the hdmi4 driver.
It add the CEC irq handler, the CEC (un)init calls and tells the CEC implementation when the physical address changes.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com
drivers/gpu/drm/omapdrm/dss/Kconfig | 9 +++++++++ drivers/gpu/drm/omapdrm/dss/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/hdmi4.c | 23 ++++++++++++++++++++++- 3 files changed, 32 insertions(+), 1 deletion(-)
<snip>
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index e371b47ff6ff..ebe5b27cee6f 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
<snip>
@@ -392,6 +401,8 @@ static void hdmi_display_disable(struct omap_dss_device *dssdev)
DSSDBG("Enter hdmi_display_disable\n");
hdmi4_cec_set_phys_addr(&hdmi.core, CEC_PHYS_ADDR_INVALID);
mutex_lock(&hdmi.lock);
spin_lock_irqsave(&hdmi.audio_playing_lock, flags);
My assumption was that hdmi_display_disable() was called when the hotplug would go away. But I discovered that that isn't the case, or at least not when X is running. It seems that the actual HPD check is done in hdmic_detect() in omapdrm/displays/connector-hdmi.c.
But there I have no access to hdmi.core (needed for the hdmi4_cec_set_phys_addr() call).
Any idea how to solve this? I am not all that familiar with drm, let alone omapdrm, so if you can point me in the right direction, then that would be very helpful.
Regards,
Hans
On 06/05/17 14:58, Hans Verkuil wrote:
My assumption was that hdmi_display_disable() was called when the hotplug would go away. But I discovered that that isn't the case, or at least not when X is running. It seems that the actual HPD check is done in hdmic_detect() in omapdrm/displays/connector-hdmi.c.
For some HW it's done there (in the case there's no IP handling the HPD), but in some cases it's done in tpd12s015 driver (e.g. pandaboard), and in some cases it also could be done in the hdmi driver (if the HPD is handled by the HDMI IP, but at the moment we don't have this case supported in the SW).
But there I have no access to hdmi.core (needed for the hdmi4_cec_set_phys_addr() call).
Any idea how to solve this? I am not all that familiar with drm, let alone omapdrm, so if you can point me in the right direction, then that would be very helpful.
Hmm, indeed, looks the the output is kept enabled even if HPD drops and the connector status is changed to disconnected.
I don't have a very good solution... I think we have to add a function to omapdss_hdmi_ops, which the connector-hdmi and tpd12s015 drivers can call when they detect a HPD change. That call would go to the HDMI IP driver.
Peter is about to send hotplug-interrupt-handling series, I think the HPD function work should be done on top of that, as otherwise it'll just conflict horribly.
Tomi
On 05/08/2017 12:26 PM, Tomi Valkeinen wrote:
On 06/05/17 14:58, Hans Verkuil wrote:
My assumption was that hdmi_display_disable() was called when the hotplug would go away. But I discovered that that isn't the case, or at least not when X is running. It seems that the actual HPD check is done in hdmic_detect() in omapdrm/displays/connector-hdmi.c.
For some HW it's done there (in the case there's no IP handling the HPD), but in some cases it's done in tpd12s015 driver (e.g. pandaboard), and in some cases it also could be done in the hdmi driver (if the HPD is handled by the HDMI IP, but at the moment we don't have this case supported in the SW).
But there I have no access to hdmi.core (needed for the hdmi4_cec_set_phys_addr() call).
Any idea how to solve this? I am not all that familiar with drm, let alone omapdrm, so if you can point me in the right direction, then that would be very helpful.
Hmm, indeed, looks the the output is kept enabled even if HPD drops and the connector status is changed to disconnected.
I don't have a very good solution... I think we have to add a function to omapdss_hdmi_ops, which the connector-hdmi and tpd12s015 drivers can call when they detect a HPD change. That call would go to the HDMI IP driver.
Right, I was thinking the same, I just wasn't sure if that was the correct solution.
Peter is about to send hotplug-interrupt-handling series, I think the HPD function work should be done on top of that, as otherwise it'll just conflict horribly.
OK, I'll do that.
I'll get CEC supported on the omap4 eventually! :-)
Regards,
Hans
Hi Tomi,
On 08/05/17 12:26, Tomi Valkeinen wrote:
On 06/05/17 14:58, Hans Verkuil wrote:
My assumption was that hdmi_display_disable() was called when the hotplug would go away. But I discovered that that isn't the case, or at least not when X is running. It seems that the actual HPD check is done in hdmic_detect() in omapdrm/displays/connector-hdmi.c.
For some HW it's done there (in the case there's no IP handling the HPD), but in some cases it's done in tpd12s015 driver (e.g. pandaboard), and in some cases it also could be done in the hdmi driver (if the HPD is handled by the HDMI IP, but at the moment we don't have this case supported in the SW).
But there I have no access to hdmi.core (needed for the hdmi4_cec_set_phys_addr() call).
Any idea how to solve this? I am not all that familiar with drm, let alone omapdrm, so if you can point me in the right direction, then that would be very helpful.
Hmm, indeed, looks the the output is kept enabled even if HPD drops and the connector status is changed to disconnected.
I don't have a very good solution... I think we have to add a function to omapdss_hdmi_ops, which the connector-hdmi and tpd12s015 drivers can call when they detect a HPD change. That call would go to the HDMI IP driver.
Peter is about to send hotplug-interrupt-handling series, I think the HPD function work should be done on top of that, as otherwise it'll just conflict horribly.
Has that been merged yet? And if so, what git repo/branch should I base my next version of this patch series on? If not, do you know when it is expected?
Regards,
Hans
On 08/06/17 10:34, Hans Verkuil wrote:
Peter is about to send hotplug-interrupt-handling series, I think the HPD function work should be done on top of that, as otherwise it'll just conflict horribly.
Has that been merged yet? And if so, what git repo/branch should I base my next version of this patch series on? If not, do you know when it is expected?
No, still pending review. The patches ("[PATCH v2 0/3] drm/omap: Support for hotplug detection") apply on top of latest drm-next, if you want to try.
Tomi
Hi Tomi,
On 06/08/2017 11:19 AM, Tomi Valkeinen wrote:
On 08/06/17 10:34, Hans Verkuil wrote:
Peter is about to send hotplug-interrupt-handling series, I think the HPD function work should be done on top of that, as otherwise it'll just conflict horribly.
Has that been merged yet? And if so, what git repo/branch should I base my next version of this patch series on? If not, do you know when it is expected?
No, still pending review. The patches ("[PATCH v2 0/3] drm/omap: Support for hotplug detection") apply on top of latest drm-next, if you want to try.
I gather[1] that this has been merged? Where can I find a git tree that has these patches? I'd like to get the omap4 CEC support in for 4.14.
Regards,
Hans
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
This patch series adds support for the OMAP4 HDMI CEC IP core.
What is this series based on? It doesn't apply to drm-next, and: fatal: sha1 information is lacking or useless (drivers/gpu/drm/omapdrm/dss/hdmi4.c).
Tomi
On 28/04/17 13:52, Tomi Valkeinen wrote:
On 14/04/17 13:25, Hans Verkuil wrote:
From: Hans Verkuil hans.verkuil@cisco.com
This patch series adds support for the OMAP4 HDMI CEC IP core.
What is this series based on? It doesn't apply to drm-next, and: fatal: sha1 information is lacking or useless (drivers/gpu/drm/omapdrm/dss/hdmi4.c).
That patch series was based on the media_tree master since I needed the latest CEC core code that supports CEC while HPD is down. I have rebased my series to the latest media_tree version. It's available in my panda-cec branch from my repo: git://linuxtv.org/hverkuil/media_tree.git.
As mentioned, once 4.12-rc1 has been released I'll rebase and repost.
Regards,
Hans
dri-devel@lists.freedesktop.org