From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-05-30 14:22:18
Hi,
This series adds dw-hdmi CEC support. This is done in four stages:
1. Remove definitions that are not required from dw-hdmi.h
2. Add cec-notifier support
3. Fix up the clkdis register support, as this register contains a
clock disable bit for the CEC module.
4. Add the driver.
The CEC driver has been updated to use the register accessors in the
main driver - it would be nice if it was possible to use the regmap
support directly, but there's some knowledge private to the main
driver that's required to correctly access the registers. (I don't
understand why the register stride isn't part of regmap.)
drivers/gpu/drm/bridge/synopsys/Kconfig | 8 +
drivers/gpu/drm/bridge/synopsys/Makefile | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320 ++++++++++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 87 ++++++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 ----
6 files changed, 423 insertions(+), 57 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Russell King <hidden> Date: 2017-05-30 14:23:07
We don't need the CEC engine register definitions, so let's remove them.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 -------------------------------
1 file changed, 45 deletions(-)
From: Russell King <hidden> Date: 2017-05-30 14:23:12
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
From: Russell King <hidden> Date: 2017-05-30 14:23:17
The video setup path aways sets the clock disable register to a specific
value, which has the effect of disabling the CEC engine. When we add the
CEC driver, this becomes a problem.
Fix this by only setting/clearing the bits that the video path needs to.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
I rather like the format HDMI_{REGISTER_NAME}_{FIELD_NAME} so
that it clearly identifies this is a internal driver register and
not a CEC core register, but I guess its up to you :)
Hi Russell,
On 30-05-2017 15:23, Russell King wrote:
The video setup path aways sets the clock disable register to a specific
value, which has the effect of disabling the CEC engine. When we add the
CEC driver, this becomes a problem.
Fix this by only setting/clearing the bits that the video path needs to.
Signed-off-by: Russell King <redacted>
Reviewed-by: Jose Abreu <redacted>
Best regards,
Jose Miguel Abreu
From: Hans Verkuil <hidden> Date: 2017-06-01 08:31:10
Hi Russell,
First a few top-level questions:
1) What was the reason for using the cec-notifier here? Isn't this
tightly integrated into the main dw-hdmi block? For the tda driver
it is clearly required, but for tightly coupled HDMI & CEC HW I
just create the adapter from the HDMI driver. As a small bonus it
avoids adding the cec-notifier code and the control flow is a bit
easier to trace.
2) I may have asked this before, apologies if I repeat myself: does
this CEC implementation support CEC monitoring (aka snooping)? If
it does, then I recommend that it is implemented since it is very
useful.
3) Is the CEC still active if there is no hotplug signal? Or is it
powered off in that case? Ideally it should still be possible to
send CEC messages even if there is no hotplug. This is explicitly
allowed by the CEC 2.0 spec to wake up displays that turn off the
HPD, but that still have a working CEC controller.
If this is not possible, then you need to use the CEC_CAP_NEEDS_HPD
capability. See: https://patchwork.linuxtv.org/patch/41478/
This will almost certainly be merged for 4.13 since other CEC drivers
need this as well.
On 05/30/17 16:23, Russell King wrote:
quoted hunk
Add a CEC driver for the dw-hdmi hardware.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 8 +
drivers/gpu/drm/bridge/synopsys/Makefile | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320 ++++++++++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 +++-
5 files changed, 387 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h
This will change. Patches to fix the config handling are pending for 4.12.
Here you can see the pending patches:
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
The patches from 'cec-notifier.h: handle unreachable CONFIG_CEC_CORE' to
'cec: drop MEDIA_CEC_DEBUG' should all be merged in 4.12.
That means that this config becomes:
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI
+ select CEC_CORE
+ select CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
Why handle retries here at all? Just mark this as CEC_TX_STATUS_ERROR and set
tx_done to true. The CEC core will just call dw_hdmi_cec_transmit again if
it needs to make another attempt. I suggest that the whole retry code is
dropped.
I think I will make a patch for a new helper function where you can just call:
cec_transmit_attempt_done(adap, cec->tx_status);
and that will call cec_transmit_done filling in the other arguments
based on the status.
Most CEC HW doesn't do retries so only make one attempt. In that case
only one of the remaining count arguments is 1 and that's based on the
status.
Having correct error counts is useful for debugging problems.
@@ -2223,6 +2224,29 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)return-ENODEV;}+staticvoiddw_hdmi_cec_enable(structdw_hdmi*hdmi)+{+mutex_lock(&hdmi->mutex);+hdmi->mc_clkdis&=~HDMI_MC_CLKDIS_CECCLK_DISABLE;+hdmi_writeb(hdmi,hdmi->mc_clkdis,HDMI_MC_CLKDIS);+mutex_unlock(&hdmi->mutex);+}++staticvoiddw_hdmi_cec_disable(structdw_hdmi*hdmi)+{+mutex_lock(&hdmi->mutex);+hdmi->mc_clkdis|=HDMI_MC_CLKDIS_CECCLK_DISABLE;+hdmi_writeb(hdmi,hdmi->mc_clkdis,HDMI_MC_CLKDIS);+mutex_unlock(&hdmi->mutex);+}++staticconststructdw_hdmi_cec_opsdw_hdmi_cec_ops={+.write=hdmi_writeb,+.read=hdmi_readb,+.enable=dw_hdmi_cec_enable,+.disable=dw_hdmi_cec_disable,+};+
This feels over-engineered and I suspect it is simplified if you just
add a cec_adapter pointer to struct dw_hdmi and link dw-hdmi-cec.c
together with dw-hdmi.c.
In other implementations I have done (see e.g. the recent drm displayport
CEC patch series) this works quite well.
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-06-01 09:46:33
On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
Hi Russell,
First a few top-level questions:
Hi Hans,
1) What was the reason for using the cec-notifier here? Isn't this
tightly integrated into the main dw-hdmi block? For the tda driver
it is clearly required, but for tightly coupled HDMI & CEC HW I
just create the adapter from the HDMI driver. As a small bonus it
avoids adding the cec-notifier code and the control flow is a bit
easier to trace.
It's to avoid complex dependencies. If it's all built in to the HDMI
driver, then the HDMI driver needs to depend on all the media stuff
being non-modular. For a video output device, this is sub-optimal,
because you want the video output device to work during boot.
I feel strongly about this point, especially as we have had many years
of users being able to use dw-hdmi without needing CEC enabled.
2) I may have asked this before, apologies if I repeat myself: does
this CEC implementation support CEC monitoring (aka snooping)? If
it does, then I recommend that it is implemented since it is very
useful.
It does not.
3) Is the CEC still active if there is no hotplug signal? Or is it
powered off in that case? Ideally it should still be possible to
send CEC messages even if there is no hotplug. This is explicitly
allowed by the CEC 2.0 spec to wake up displays that turn off the
HPD, but that still have a working CEC controller.
This is not specified in the documentation, so I don't think we know
without experimentation. This would be a future enhancement to the
patch set.
This will change. Patches to fix the config handling are pending for 4.12.
Here you can see the pending patches:
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
The patches from 'cec-notifier.h: handle unreachable CONFIG_CEC_CORE' to
'cec: drop MEDIA_CEC_DEBUG' should all be merged in 4.12.
That means that this config becomes:
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI
+ select CEC_CORE
+ select CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
You will also need to select MEDIA_SUPPORT to avoid dependency issues.
CEC_CORE and CEC_NOTIFIER are both lumped under an "if MEDIA_SUPPORT"
block in drivers/media/Kconfig, so they depend on this symbol. Asking
Kconfig to select these two symbols without MEDIA_SUPPORT creates an
invalid configuration - unless CEC has been moved out from being under
MEDIA_SUPPORT. (I haven't looked at your tree yet.)
Why handle retries here at all? Just mark this as CEC_TX_STATUS_ERROR and set
tx_done to true. The CEC core will just call dw_hdmi_cec_transmit again if
it needs to make another attempt. I suggest that the whole retry code is
dropped.
Probably comes from a previous iteration of your CEC core which required
the driver to do retries, so it can probably be fixed up in the way you
describe.
However, presumably this needs a different status other than
"CEC_TX_STATUS_MAX_RETRIES"? I don't see a way to report this error to
the CEC core in a way that it will retry.
I think I will make a patch for a new helper function where you can just call:
cec_transmit_attempt_done(adap, cec->tx_status);
and that will call cec_transmit_done filling in the other arguments
based on the status.
Most CEC HW doesn't do retries so only make one attempt. In that case
only one of the remaining count arguments is 1 and that's based on the
status.
Having correct error counts is useful for debugging problems.
It hasn't been clear to me which counts should be non-zero, and it seems
like entirely redundant information given that the status argument
indicates what happened to the message.
This feels over-engineered and I suspect it is simplified if you just
add a cec_adapter pointer to struct dw_hdmi and link dw-hdmi-cec.c
together with dw-hdmi.c.
As I mention above, to do so would mean that dw-hdmi has to be modular
if you want CEC to be modular, and I don't think that is reasonable
for a video output device, which may be the source of kernel boot
messages.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-06-01 10:44:42
On 06/01/17 11:46, Russell King - ARM Linux wrote:
On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
First a few top-level questions:
Hi Hans,
quoted
1) What was the reason for using the cec-notifier here? Isn't this
tightly integrated into the main dw-hdmi block? For the tda driver
it is clearly required, but for tightly coupled HDMI & CEC HW I
just create the adapter from the HDMI driver. As a small bonus it
avoids adding the cec-notifier code and the control flow is a bit
easier to trace.
It's to avoid complex dependencies. If it's all built in to the HDMI
driver, then the HDMI driver needs to depend on all the media stuff
being non-modular. For a video output device, this is sub-optimal,
because you want the video output device to work during boot.
This is no longer true after my rework of the CEC kernel config.
After doing a 'select CEC_CORE' the cec framework will be compiled
correctly.
It no longer depends on the media subsystem (except if you want to use
the remote control passthrough since the RC framework is part of media).
Selecting CEC_CORE will only select the cec core code.
I feel strongly about this point, especially as we have had many years
of users being able to use dw-hdmi without needing CEC enabled.
quoted
2) I may have asked this before, apologies if I repeat myself: does
this CEC implementation support CEC monitoring (aka snooping)? If
it does, then I recommend that it is implemented since it is very
useful.
It does not.
quoted
3) Is the CEC still active if there is no hotplug signal? Or is it
powered off in that case? Ideally it should still be possible to
send CEC messages even if there is no hotplug. This is explicitly
allowed by the CEC 2.0 spec to wake up displays that turn off the
HPD, but that still have a working CEC controller.
This is not specified in the documentation, so I don't think we know
without experimentation. This would be a future enhancement to the
patch set.
This will change. Patches to fix the config handling are pending for 4.12.
Here you can see the pending patches:
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
The patches from 'cec-notifier.h: handle unreachable CONFIG_CEC_CORE' to
'cec: drop MEDIA_CEC_DEBUG' should all be merged in 4.12.
That means that this config becomes:
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI
+ select CEC_CORE
+ select CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
You will also need to select MEDIA_SUPPORT to avoid dependency issues.
CEC_CORE and CEC_NOTIFIER are both lumped under an "if MEDIA_SUPPORT"
block in drivers/media/Kconfig, so they depend on this symbol.
No, they've been moved up. They no longer depend on the MEDIA_SUPPORT.
So that's been fixed.
Asking
Kconfig to select these two symbols without MEDIA_SUPPORT creates an
invalid configuration - unless CEC has been moved out from being under
MEDIA_SUPPORT. (I haven't looked at your tree yet.)
Why handle retries here at all? Just mark this as CEC_TX_STATUS_ERROR and set
tx_done to true. The CEC core will just call dw_hdmi_cec_transmit again if
it needs to make another attempt. I suggest that the whole retry code is
dropped.
Probably comes from a previous iteration of your CEC core which required
the driver to do retries, so it can probably be fixed up in the way you
describe.
However, presumably this needs a different status other than
"CEC_TX_STATUS_MAX_RETRIES"? I don't see a way to report this error to
the CEC core in a way that it will retry.
If the framework does the retries, then the cec driver will never return the
MAX_RETRIES status. Just whether the transmit was OK/NACKed/LOW_DRIVE/ERROR.
I think I will make a patch for a new helper function where you can just call:
cec_transmit_attempt_done(adap, cec->tx_status);
and that will call cec_transmit_done filling in the other arguments
based on the status.
Most CEC HW doesn't do retries so only make one attempt. In that case
only one of the remaining count arguments is 1 and that's based on the
status.
Having correct error counts is useful for debugging problems.
It hasn't been clear to me which counts should be non-zero, and it seems
like entirely redundant information given that the status argument
indicates what happened to the message.
True for HW that doesn't retry. Expect a patch today/tomorrow.
This feels over-engineered and I suspect it is simplified if you just
add a cec_adapter pointer to struct dw_hdmi and link dw-hdmi-cec.c
together with dw-hdmi.c.
As I mention above, to do so would mean that dw-hdmi has to be modular
if you want CEC to be modular, and I don't think that is reasonable
for a video output device, which may be the source of kernel boot
messages.
Indeed, but this dependency mess has been fixed, so this is no longer an
issue.
Regards,
Hans
Maybe you should check the config bit before enabling CEC :
/* CONFIG0_ID field values */
+ HDMI_CONFIG0_CEC = 0x2,
if (config0 & HDMI_CONFIG0_CEC) {
}
quoted hunk
+
/* Reset HDMI DDC I2C master controller and mute I2CM interrupts */
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
@@ -2475,6 +2511,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi) { if (hdmi->audio && !IS_ERR(hdmi->audio)) platform_device_unregister(hdmi->audio);+ if (!IS_ERR(hdmi->cec))+ platform_device_unregister(hdmi->cec); /* Disable all interrupts */ hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
Apart from that and the s/Synopsis/Synopsys/ typos:
Reviewed-by: Neil Armstrong <redacted>
Neil
I think you should check first if CEC engine is in normal
operation mode, as a safety measure.
I'm not sure what you mean there, because the iMX6 manuals don't mention
anything about that. The only "modes" it talks about is initiator mode
and follower mode. Moreover, there's nothing in what was FSL's driver
that hints at that either.
Maybe you could provide some further technical information on this
point?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
I think you should check first if CEC engine is in normal
operation mode, as a safety measure.
I'm not sure what you mean there, because the iMX6 manuals don't mention
anything about that. The only "modes" it talks about is initiator mode
and follower mode. Moreover, there's nothing in what was FSL's driver
that hints at that either.
Maybe you could provide some further technical information on this
point?
You should check that CEC is: not in standy, acknowledges
broadcast messages, signal free time is 5bit period, and not lost
arbitration, which basically means CEC_CTRL must be 0x2 and
IH_CEC_STAT0 must not have ARB_LOST set. I do know you set 0x3 at
the end of this function but according to all the docs I have you
must first set 0x2 before writing message.
Best regards,
Jose Miguel Abreu
I hadn't realized until Jose Abreu's latest reply, but you need to check the
ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.
I think CEC_STAT_ERROR_FOLL might equal CEC_TX_STATUS_LOW_DRIVE, but without
documentation I can't be sure.
My experience is that this low drive condition tends to be poorly reported by
hardware. Either that or poorly documented. This is why I added a
CEC_TX_STATUS_ERROR status as a catch-all error status when it is unclear from
the hardware/documentation what error occurred.
Jose, do you know which status bit is used to report a follower pulling the
CEC line low for a long time (approx. 3.6 ms) to signal a CEC error?
Regards,
Hans
Synopsys
Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+ select MEDIA_CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
and/or modify
+ * it under the terms of the GNU General Public License
version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+
+#include <drm/drm_edid.h>
+
+#include <media/cec.h>
+#include <media/cec-notifier.h>
+
+#include "dw-hdmi-cec.h"
+
+enum {
+ HDMI_IH_CEC_STAT0 = 0x0106,
+ HDMI_IH_MUTE_CEC_STAT0 = 0x0186,
+
+ HDMI_CEC_CTRL = 0x7d00,
+ CEC_CTRL_START = BIT(0),
+ CEC_CTRL_NORMAL = 1 << 1,
+
+ HDMI_CEC_STAT = 0x7d01,
+ CEC_STAT_DONE = BIT(0),
+ CEC_STAT_EOM = BIT(1),
+ CEC_STAT_NACK = BIT(2),
+ CEC_STAT_ARBLOST = BIT(3),
+ CEC_STAT_ERROR_INIT = BIT(4),
+ CEC_STAT_ERROR_FOLL = BIT(5),
+ CEC_STAT_WAKEUP = BIT(6),
I hadn't realized until Jose Abreu's latest reply, but you need
to check the
ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.
I think CEC_STAT_ERROR_FOLL might equal
CEC_TX_STATUS_LOW_DRIVE, but without
documentation I can't be sure.
My experience is that this low drive condition tends to be
poorly reported by
hardware. Either that or poorly documented. This is why I added a
CEC_TX_STATUS_ERROR status as a catch-all error status when it
is unclear from
the hardware/documentation what error occurred.
Jose, do you know which status bit is used to report a follower
pulling the
CEC line low for a long time (approx. 3.6 ms) to signal a CEC
error?
Bit 5 for follower error, bit 4 for initiator error.
Best regards,
Jose Miguel Abreu
Synopsys
Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+ select MEDIA_CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
and/or modify
+ * it under the terms of the GNU General Public License
version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+
+#include <drm/drm_edid.h>
+
+#include <media/cec.h>
+#include <media/cec-notifier.h>
+
+#include "dw-hdmi-cec.h"
+
+enum {
+ HDMI_IH_CEC_STAT0 = 0x0106,
+ HDMI_IH_MUTE_CEC_STAT0 = 0x0186,
+
+ HDMI_CEC_CTRL = 0x7d00,
+ CEC_CTRL_START = BIT(0),
+ CEC_CTRL_NORMAL = 1 << 1,
+
+ HDMI_CEC_STAT = 0x7d01,
+ CEC_STAT_DONE = BIT(0),
+ CEC_STAT_EOM = BIT(1),
+ CEC_STAT_NACK = BIT(2),
+ CEC_STAT_ARBLOST = BIT(3),
+ CEC_STAT_ERROR_INIT = BIT(4),
+ CEC_STAT_ERROR_FOLL = BIT(5),
+ CEC_STAT_WAKEUP = BIT(6),
I hadn't realized until Jose Abreu's latest reply, but you need
to check the
ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.
I think CEC_STAT_ERROR_FOLL might equal
CEC_TX_STATUS_LOW_DRIVE, but without
documentation I can't be sure.
My experience is that this low drive condition tends to be
poorly reported by
hardware. Either that or poorly documented. This is why I added a
CEC_TX_STATUS_ERROR status as a catch-all error status when it
is unclear from
the hardware/documentation what error occurred.
Jose, do you know which status bit is used to report a follower
pulling the
CEC line low for a long time (approx. 3.6 ms) to signal a CEC
error?
Bit 5 for follower error, bit 4 for initiator error.
I gathered that from the define names :-)
But what does it mean? What sort of error is reported here?
I'm guessing here that "follower error" means that one of the remote
CEC devices forced a Low Drive condition, where "initiator error"
means that our adapter forced a Low Drive condition on the bus.
Would that be correct?
If so, then the CEC_STAT_ERROR_INIT can be ignored and ERROR_FOLL
maps to the LOW_DRIVE status.
(Low Drive condition is what is described in section CEC 7.4 "CEC Line
Error Handling" of the HDMI 1.4 Specification).
Regards,
Hans
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-06-02 09:15:28
On Fri, Jun 02, 2017 at 06:02:28AM +0100, Jose Abreu wrote:
You should check that CEC is: not in standy, acknowledges
broadcast messages, signal free time is 5bit period, and not lost
arbitration, which basically means CEC_CTRL must be 0x2 and
IH_CEC_STAT0 must not have ARB_LOST set.
If ARB_LOST is set, that will trigger an interrupt, and the interrupt
handler will clear the bit. So all the time that the interrupt handler
is present, ARB_LOST should be clear whenever we try to send a message.
When we enable the CEC interface, we zero the CEC_CTRL register, which
takes the controller out of standby, and initialises the command
register.
Bits 2:1 select the signal free time, and there's no requirement
specified to require them to be set to '01' before writing the
message - in fact, it's legal for them to be set to other values,
particularly when retrying, which is something I've missed.
2-1 Frame Type bit
FRAME_TYP
00 Signal Free Time = 3-bit periods. Previous
attempt to send frame is unsuccessful.
01 Signal Free Time = 5-bit periods. New initiator
wants to send a frame.
10 Signal Free Time = 7-bit periods. Present
initiator wants to send another frame
immediately after its previous frame. (spec
CEC 9.1)
11 Illegal value. If software write this value,
hardware will set the value to the default 2'b01.
Clearly from that, there are times when we want to transmit a message
without a 5-bit signal free time period, particularly when we're
retrying or wanting to send another frame, so I don't believe that
there's a requirement for the control register to always be set to
0x02. I suspect that where that value is coming from is an application
note describing how to send a brand new message each time, and not
covering the other cases.
It could be that we need to set the frame type before loading the
message - that I'll buy, but not that it must always be set to 0x02.
Provided that the standby and BC_NACK bits are both cleared should
be sufficient.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Synopsys
Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+ select MEDIA_CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
and/or modify
+ * it under the terms of the GNU General Public License
version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+
+#include <drm/drm_edid.h>
+
+#include <media/cec.h>
+#include <media/cec-notifier.h>
+
+#include "dw-hdmi-cec.h"
+
+enum {
+ HDMI_IH_CEC_STAT0 = 0x0106,
+ HDMI_IH_MUTE_CEC_STAT0 = 0x0186,
+
+ HDMI_CEC_CTRL = 0x7d00,
+ CEC_CTRL_START = BIT(0),
+ CEC_CTRL_NORMAL = 1 << 1,
+
+ HDMI_CEC_STAT = 0x7d01,
+ CEC_STAT_DONE = BIT(0),
+ CEC_STAT_EOM = BIT(1),
+ CEC_STAT_NACK = BIT(2),
+ CEC_STAT_ARBLOST = BIT(3),
+ CEC_STAT_ERROR_INIT = BIT(4),
+ CEC_STAT_ERROR_FOLL = BIT(5),
+ CEC_STAT_WAKEUP = BIT(6),
I hadn't realized until Jose Abreu's latest reply, but you need
to check the
ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.
I think CEC_STAT_ERROR_FOLL might equal
CEC_TX_STATUS_LOW_DRIVE, but without
documentation I can't be sure.
My experience is that this low drive condition tends to be
poorly reported by
hardware. Either that or poorly documented. This is why I added a
CEC_TX_STATUS_ERROR status as a catch-all error status when it
is unclear from
the hardware/documentation what error occurred.
Jose, do you know which status bit is used to report a follower
pulling the
CEC line low for a long time (approx. 3.6 ms) to signal a CEC
error?
Bit 5 for follower error, bit 4 for initiator error.
I gathered that from the define names :-)
But what does it mean? What sort of error is reported here?
I think the problem is that no one really knows, the documentation is
quite poor:
5 An error is notified by a follower. Abnormal logic data
ERROR_FOLL bit error (for follower).
4 An error is detected on cec line (for initiator only).
ERROR_INIT
It is so vague that you can read anything into that description.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-06-02 09:28:08
On 06/02/17 11:15, Russell King - ARM Linux wrote:
On Fri, Jun 02, 2017 at 06:02:28AM +0100, Jose Abreu wrote:
quoted
You should check that CEC is: not in standy, acknowledges
broadcast messages, signal free time is 5bit period, and not lost
arbitration, which basically means CEC_CTRL must be 0x2 and
IH_CEC_STAT0 must not have ARB_LOST set.
If ARB_LOST is set, that will trigger an interrupt, and the interrupt
handler will clear the bit. So all the time that the interrupt handler
is present, ARB_LOST should be clear whenever we try to send a message.
When we enable the CEC interface, we zero the CEC_CTRL register, which
takes the controller out of standby, and initialises the command
register.
Bits 2:1 select the signal free time, and there's no requirement
specified to require them to be set to '01' before writing the
message - in fact, it's legal for them to be set to other values,
particularly when retrying, which is something I've missed.
2-1 Frame Type bit
FRAME_TYP
00 Signal Free Time = 3-bit periods. Previous
attempt to send frame is unsuccessful.
01 Signal Free Time = 5-bit periods. New initiator
wants to send a frame.
10 Signal Free Time = 7-bit periods. Present
initiator wants to send another frame
immediately after its previous frame. (spec
CEC 9.1)
11 Illegal value. If software write this value,
hardware will set the value to the default 2'b01.
The 'signal_free_time' argument of adap_transmit will have the recommended
signal free time. You can test against the CEC_SIGNAL_FREE_TIME_* defines
from media/cec.h. You probably saw this already, but just in case you missed
this...
Regards,
Hans
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-06-02 09:36:51
On Fri, Jun 02, 2017 at 11:28:08AM +0200, Hans Verkuil wrote:
The 'signal_free_time' argument of adap_transmit will have the recommended
signal free time. You can test against the CEC_SIGNAL_FREE_TIME_* defines
from media/cec.h. You probably saw this already, but just in case you missed
this...
Yes, it's a recent addition to the CEC core, which I've added support
for, but it doesn't make too much sense until the retrying stuff is
sorted out.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-06-02 12:07:02
On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
This will change. Patches to fix the config handling are pending for 4.12.
Here you can see the pending patches:
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
The patches from 'cec-notifier.h: handle unreachable CONFIG_CEC_CORE' to
'cec: drop MEDIA_CEC_DEBUG' should all be merged in 4.12.
Hi Hans,
I'll wait until these have hit mainline before generating another
patch series. Do you have any idea when that might happen?
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-06-02 12:29:32
On 06/02/17 14:07, Russell King - ARM Linux wrote:
On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
quoted
This will change. Patches to fix the config handling are pending for 4.12.
Here you can see the pending patches:
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
The patches from 'cec-notifier.h: handle unreachable CONFIG_CEC_CORE' to
'cec: drop MEDIA_CEC_DEBUG' should all be merged in 4.12.
Hi Hans,
I'll wait until these have hit mainline before generating another
patch series. Do you have any idea when that might happen?
rc6? Hard to tell, I know Mauro is very busy so it can be difficult to
predict.
Regards,
Hans
From: Neil Armstrong <hidden> Date: 2017-06-09 12:59:20
On 05/30/2017 04:23 PM, Russell King wrote:
quoted hunk
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
Hi Archit,
I think this one could go through drm-next since it's quite
standalone and will reduce the DW-HDMI CEC patchset and dependencies.
Tested on Amlogic SoCs using my in-development CEC driver.
Tested-by: Neil Armstrong <redacted>
Acked-by: Neil Armstrong <redacted>
Thanks Russell for the patch,
Neil
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-06-09 13:38:22
On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote:
On 05/30/2017 04:23 PM, Russell King wrote:
quoted
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
Hi Archit,
I think this one could go through drm-next since it's quite
standalone and will reduce the DW-HDMI CEC patchset and dependencies.
Not a good idea. If you read all the comments, Hans is suggesting that
CEC should be part of dw-hdmi itself, not stand-alone. That would mean
this patch probably changes - basically, with CEC support built-in to
dw-hdmi, we don't need the notifier stuff.
So, I'd suggest _not_ merging it at the moment, because the patch could
well become obsolete.
Wait until the CEC changes that Hans has talked about have hit mainline
and I've had a chance to rework this for those. We're waiting on Mauro
for that at the moment.
(I do find it rather frustrating that CEC seems to evolve very rapidly,
it makes it quite difficult to publish a patch set, and get it merged.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-06-09 13:51:49
On 09/06/17 15:38, Russell King - ARM Linux wrote:
On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote:
quoted
On 05/30/2017 04:23 PM, Russell King wrote:
quoted
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
Hi Archit,
I think this one could go through drm-next since it's quite
standalone and will reduce the DW-HDMI CEC patchset and dependencies.
Not a good idea. If you read all the comments, Hans is suggesting that
CEC should be part of dw-hdmi itself, not stand-alone. That would mean
this patch probably changes - basically, with CEC support built-in to
dw-hdmi, we don't need the notifier stuff.
So, I'd suggest _not_ merging it at the moment, because the patch could
well become obsolete.
Wait until the CEC changes that Hans has talked about have hit mainline
and I've had a chance to rework this for those. We're waiting on Mauro
for that at the moment.
The patches are in mainline now. Note: you may get the occasional kbuild
robot emails since there are a few more CEC patches pending for 4.12 but
that's just slight CEC header changes to fix obscure .config combinations.
It should not affect your patches. I expect those pending fixes to hit
mainline some time next week.
(I do find it rather frustrating that CEC seems to evolve very rapidly,
it makes it quite difficult to publish a patch set, and get it merged.)
It's a pretty new framework and yours and my own work on drm drivers showed
a few shortcomings, primarily in the way the kernel config options were set
up for CEC.
I believe this is now sorted with 4.12.
What makes CEC a bit tricky is that it straddles two subsystems: drm and media.
Always harder to synchronize things.
Regards,
Hans
From: Neil Armstrong <hidden> Date: 2017-06-09 13:56:39
On 06/09/2017 03:38 PM, Russell King - ARM Linux wrote:
On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote:
quoted
On 05/30/2017 04:23 PM, Russell King wrote:
quoted
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
Hi Archit,
I think this one could go through drm-next since it's quite
standalone and will reduce the DW-HDMI CEC patchset and dependencies.
Not a good idea. If you read all the comments, Hans is suggesting that
CEC should be part of dw-hdmi itself, not stand-alone. That would mean
this patch probably changes - basically, with CEC support built-in to
dw-hdmi, we don't need the notifier stuff.
Hi Russell,
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is not used,
but a custom one, so this notifier is actually useful for this platform and
maybe others.
So, I'd suggest _not_ merging it at the moment, because the patch could
well become obsolete.
It won't since the Meson platform needs it...
Wait until the CEC changes that Hans has talked about have hit mainline
and I've had a chance to rework this for those. We're waiting on Mauro
for that at the moment.
(I do find it rather frustrating that CEC seems to evolve very rapidly,
it makes it quite difficult to publish a patch set, and get it merged.)
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
Neil
From: Hans Verkuil <hidden> Date: 2017-06-09 14:04:20
On 09/06/17 15:56, Neil Armstrong wrote:
On 06/09/2017 03:38 PM, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote:
quoted
On 05/30/2017 04:23 PM, Russell King wrote:
quoted
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
Hi Archit,
I think this one could go through drm-next since it's quite
standalone and will reduce the DW-HDMI CEC patchset and dependencies.
Not a good idea. If you read all the comments, Hans is suggesting that
CEC should be part of dw-hdmi itself, not stand-alone. That would mean
this patch probably changes - basically, with CEC support built-in to
dw-hdmi, we don't need the notifier stuff.
Hi Russell,
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is not used,
but a custom one, so this notifier is actually useful for this platform and
maybe others.
quoted
So, I'd suggest _not_ merging it at the moment, because the patch could
well become obsolete.
It won't since the Meson platform needs it...
Ah, I wasn't aware of that when I wrote my original comments. In that case
we do need the notifier. Which is fine, as long as the reason for that is
documented.
quoted
Wait until the CEC changes that Hans has talked about have hit mainline
and I've had a chance to rework this for those. We're waiting on Mauro
for that at the moment.
(I do find it rather frustrating that CEC seems to evolve very rapidly,
it makes it quite difficult to publish a patch set, and get it merged.)
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
I'm OK with the notifier in this case.
Regards,
Hans
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-06-09 14:10:56
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-06-09 14:27:24
On 30/05/17 16:23, Russell King wrote:
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King <redacted>
Given the fact that there are devices that do not use the built-in dw-hdmi
CEC IP but something else, using a notifier here makes a lot of sense.
So:
Acked-by: Hans Verkuil <redacted>
Regards,
Hans
@@ -1870,6 +1875,7 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)hdmi->sink_is_hdmi=drm_detect_hdmi_monitor(edid);hdmi->sink_has_audio=drm_detect_monitor_audio(edid);drm_mode_connector_update_edid_property(connector,edid);+cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,edid);ret=drm_add_edid_modes(connector,edid);/* Store the ELD */drm_edid_to_eld(connector,edid);
From: Hans Verkuil <hidden> Date: 2017-06-09 14:28:03
On 30/05/17 16:23, Russell King wrote:
The video setup path aways sets the clock disable register to a specific
value, which has the effect of disabling the CEC engine. When we add the
CEC driver, this becomes a problem.
Fix this by only setting/clearing the bits that the video path needs to.
Signed-off-by: Russell King <redacted>
For what it is worth:
Acked-by: Hans Verkuil <redacted>
Regards,
Hans
From: Hans Verkuil <hidden> Date: 2017-06-09 14:38:22
On 09/06/17 16:10, Russell King - ARM Linux wrote:
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
I've Acked patches 1-3. Patch 4 can be rebased on top of the latest mainline
and just ignore any notifier-related comments I made in my review of this
patch.
I have no problem with patches 1-3 being merged now.
Regards,
Hans
From: Hans Verkuil <hidden> Date: 2017-06-12 08:42:02
On 06/01/2017 10:31 AM, Hans Verkuil wrote:
Hi Russell,
First a few top-level questions:
1) What was the reason for using the cec-notifier here? Isn't this
tightly integrated into the main dw-hdmi block? For the tda driver
it is clearly required, but for tightly coupled HDMI & CEC HW I
just create the adapter from the HDMI driver. As a small bonus it
avoids adding the cec-notifier code and the control flow is a bit
easier to trace.
2) I may have asked this before, apologies if I repeat myself: does
this CEC implementation support CEC monitoring (aka snooping)? If
it does, then I recommend that it is implemented since it is very
useful.
3) Is the CEC still active if there is no hotplug signal? Or is it
powered off in that case? Ideally it should still be possible to
send CEC messages even if there is no hotplug. This is explicitly
allowed by the CEC 2.0 spec to wake up displays that turn off the
HPD, but that still have a working CEC controller.
If this is not possible, then you need to use the CEC_CAP_NEEDS_HPD
capability. See: https://patchwork.linuxtv.org/patch/41478/
This will almost certainly be merged for 4.13 since other CEC drivers
need this as well.
FYI: I tested your patch series with my cubox-i and CEC doesn't work if there
is no HPD. I fiddles around a bit in dw_hdmi.c to prevent it from powering off
the HDMI and PHY, but without any luck. It could be a hardware issue on the
cubox-i (e.g. a level-shifter that powers off when the HPD goes low, although
I don't see anything like that in the schematics), or it can be a driver issue
or a Synopsys IP issue. I really can't tell.
I added text in my status document (https://hverkuil.home.xs4all.nl/cec-status.txt)
at the end on how to test this.
Otherwise the CEC support on the cubox-i was working very well.
Regards,
Hans
From: Hans Verkuil <hidden> Date: 2017-07-17 08:56:47
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
I've already Acked patches 1-3. I had some comments for patch 4, so that
needs a bit more work.
Note that there is now a cec_transmit_attempt_done() helper function that
will simplify your code.
Regards,
Hans
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-07-17 09:05:16
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-07-17 11:19:59
On 17/07/17 11:05, Russell King - ARM Linux wrote:
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
From: Hans Verkuil <hidden> Date: 2017-07-17 11:39:48
On 17/07/17 11:05, Russell King - ARM Linux wrote:
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
This will fix this:
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER <<<<<<
config DRM_DW_HDMI_CEC
tristate "Synopsis Designware CEC interface"
depends on DRM_DW_HDMI
select CEC_CORE
select CEC_NOTIFIER
help
Support the CE interface which is part of the Synopsis
Designware HDMI block.
This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
used instead (as is apparently the case for amlogic), then the
select CEC_CORE if CEC_NOTIFIER
line ensures that CONFIG_CEC_CORE has the right m/y value.
Regards,
Hans
PS: Sorry for the empty reply earlier: I accidentally pressed 'Send' too soon :-)
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-07-17 12:05:13
On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
On 17/07/17 11:05, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
This will fix this:
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER <<<<<<
config DRM_DW_HDMI_CEC
tristate "Synopsis Designware CEC interface"
depends on DRM_DW_HDMI
select CEC_CORE
select CEC_NOTIFIER
help
Support the CE interface which is part of the Synopsis
Designware HDMI block.
This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
used instead (as is apparently the case for amlogic), then the
select CEC_CORE if CEC_NOTIFIER
line ensures that CONFIG_CEC_CORE has the right m/y value.
I disagree with this approach.
If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
through dw-hdmi, even though we haven't asked for the CEC part to be
enabled.
You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
with it, because that's basically what this boils down to.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Hans Verkuil <hidden> Date: 2017-07-17 12:23:54
On 17/07/17 14:05, Russell King - ARM Linux wrote:
On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
quoted
On 17/07/17 11:05, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
This will fix this:
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER <<<<<<
config DRM_DW_HDMI_CEC
tristate "Synopsis Designware CEC interface"
depends on DRM_DW_HDMI
select CEC_CORE
select CEC_NOTIFIER
help
Support the CE interface which is part of the Synopsis
Designware HDMI block.
This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
used instead (as is apparently the case for amlogic), then the
select CEC_CORE if CEC_NOTIFIER
line ensures that CONFIG_CEC_CORE has the right m/y value.
I disagree with this approach.
If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
through dw-hdmi, even though we haven't asked for the CEC part to be
enabled.
If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
enabled (without CEC_CORE that driver wouldn't compile, obviously).
So I don't see the problem. All the select...if does is make sure that
the CEC_CORE can be reached from the HDMI driver if someone enabled the
CEC notifier (and thus CEC_CORE).
You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
with it, because that's basically what this boils down to.
That makes no sense.
If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
then only the CEC driver has to select CEC_CORE. In that case the CEC code
is typically either integrated into the HDMI driver or it is a standalone
device like the USB pulse8-cec driver.
Regards,
Hans
From: Hans Verkuil <hidden> Date: 2017-07-24 12:16:40
Hi Russell,
On 07/17/2017 02:23 PM, Hans Verkuil wrote:
On 17/07/17 14:05, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
quoted
On 17/07/17 11:05, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
This will fix this:
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER <<<<<<
config DRM_DW_HDMI_CEC
tristate "Synopsis Designware CEC interface"
depends on DRM_DW_HDMI
select CEC_CORE
select CEC_NOTIFIER
help
Support the CE interface which is part of the Synopsis
Designware HDMI block.
This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
used instead (as is apparently the case for amlogic), then the
select CEC_CORE if CEC_NOTIFIER
line ensures that CONFIG_CEC_CORE has the right m/y value.
I disagree with this approach.
If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
through dw-hdmi, even though we haven't asked for the CEC part to be
enabled.
If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
enabled (without CEC_CORE that driver wouldn't compile, obviously).
So I don't see the problem. All the select...if does is make sure that
the CEC_CORE can be reached from the HDMI driver if someone enabled the
CEC notifier (and thus CEC_CORE).
quoted
You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
with it, because that's basically what this boils down to.
That makes no sense.
If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
then only the CEC driver has to select CEC_CORE. In that case the CEC code
is typically either integrated into the HDMI driver or it is a standalone
device like the USB pulse8-cec driver.
Just to make sure you aren't waiting for me to do anything: as far as I can tell
the Kconfig above will ensure the right dependencies. If you have an example
where this fails, then let me know. I am not planning on making any changes.
Frankly, I wouldn't know what to change since AFAICT it is all working with
the above Kconfig.
Regards,
Hans
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-07-24 13:07:17
On Mon, Jul 24, 2017 at 02:16:40PM +0200, Hans Verkuil wrote:
Hi Russell,
On 07/17/2017 02:23 PM, Hans Verkuil wrote:
quoted
On 17/07/17 14:05, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
quoted
On 17/07/17 11:05, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
quoted
Hi Russell,
On 09/06/17 16:10, Russell King - ARM Linux wrote:
quoted
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
quoted
Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
not used, but a custom one, so this notifier is actually useful for
this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the config bit set?)
I'm just wondering if we're going to end up with two CEC drivers trying
to bind to the same notifier.
quoted
Should we really wait until I push the Amlogic AO CEC driver ? Having a
notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
It sounds like this adds additional information that has been missing
from the review of my patches - and I suspect changes Hans' comments.
So, I'll wait, it seems pointless to try and update the patches when
it's not clear how to proceed due to other dependencies, especially
when it means that their existing state is what's required (I'm pleased
that I've held off modifying the patches so far.)
If that means having to wait another kernel revision, then I guess that's
what will have to happen.
Can you respin your patch series, keeping the notifier support? The CEC
kernel config handling has been cleaned up (just select CEC_CORE and
CEC_NOTIFIER) so you should be good to go.
Not yet - the change to the way you're dealing with Kconfig in CEC is
fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
support.
As a result of these Kconfig changes, dw-hdmi-cec now fails if:
1. You build the CEC part as a module
2. You build the HDMI part into the kernel
This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
gets built, results in the stubs in the notifier code being used, rather
than the real functions. This in turn causes the CEC part to never
receive a physical address, which is therefore non-functional.
I did have a patch to fix this, but it was never committed, and I got
busy with other stuff (so it ended up being git reset --hard away.)
This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
This will fix this:
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER <<<<<<
config DRM_DW_HDMI_CEC
tristate "Synopsis Designware CEC interface"
depends on DRM_DW_HDMI
select CEC_CORE
select CEC_NOTIFIER
help
Support the CE interface which is part of the Synopsis
Designware HDMI block.
This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
used instead (as is apparently the case for amlogic), then the
select CEC_CORE if CEC_NOTIFIER
line ensures that CONFIG_CEC_CORE has the right m/y value.
I disagree with this approach.
If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
through dw-hdmi, even though we haven't asked for the CEC part to be
enabled.
If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
enabled (without CEC_CORE that driver wouldn't compile, obviously).
So I don't see the problem. All the select...if does is make sure that
the CEC_CORE can be reached from the HDMI driver if someone enabled the
CEC notifier (and thus CEC_CORE).
quoted
You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
with it, because that's basically what this boils down to.
That makes no sense.
If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
then only the CEC driver has to select CEC_CORE. In that case the CEC code
is typically either integrated into the HDMI driver or it is a standalone
device like the USB pulse8-cec driver.
Just to make sure you aren't waiting for me to do anything: as far as I can tell
the Kconfig above will ensure the right dependencies. If you have an example
where this fails, then let me know. I am not planning on making any changes.
Frankly, I wouldn't know what to change since AFAICT it is all working with
the above Kconfig.
No, I just haven't got around to it yet - I've been busy all last week
trying to work out what's been causing a USB host driver to fail for a
client, and as such haven't had any chance to look at much else post
merge window yet.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-07-24 16:34:27
On Mon, Jul 24, 2017 at 02:07:17PM +0100, Russell King - ARM Linux wrote:
On Mon, Jul 24, 2017 at 02:16:40PM +0200, Hans Verkuil wrote:
quoted
Just to make sure you aren't waiting for me to do anything: as far as I can tell
the Kconfig above will ensure the right dependencies. If you have an example
where this fails, then let me know. I am not planning on making any changes.
Frankly, I wouldn't know what to change since AFAICT it is all working with
the above Kconfig.
No, I just haven't got around to it yet - I've been busy all last week
trying to work out what's been causing a USB host driver to fail for a
client, and as such haven't had any chance to look at much else post
merge window yet.
It's going to be a while yet - today I've attempted to bring my tree
forward to v4.13-rc2, but it's proven a long and difficult task to get
anywhere close to finishing that... and I've just ended up rewinding
back to this morning's state (because I ended up having to drop some
branches that other stuff depended upon.)
I'll have another go later in the week.
Until I can do this, I can't do anything else with mainline work.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.