| Message ID | E1dFi3E-0004lh-Pu@rmk-PC.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 05/30/2017 04:23 PM, 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 <rmk+kernel@armlinux.org.uk> > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 4e1f54a675d8..966422576c44 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -36,7 +36,10 @@ > #include "dw-hdmi.h" > #include "dw-hdmi-audio.h" > > +#include <media/cec-notifier.h> > + > #define DDC_SEGMENT_ADDR 0x30 > + > #define HDMI_EDID_LEN 512 > > enum hdmi_datamap { > @@ -173,6 +176,8 @@ struct dw_hdmi { > > unsigned int reg_shift; > struct regmap *regm; > + > + struct cec_notifier *cec_notifier; > }; > > #define HDMI_IH_PHY_STAT0_RX_SENSE \ > @@ -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); > @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) > * ask the source to re-read the EDID. > */ > if (intr_stat & > - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) > + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { > __dw_hdmi_setup_rx_sense(hdmi, > phy_stat & HDMI_PHY_HPD, > phy_stat & HDMI_PHY_RX_SENSE); > > + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) > + cec_notifier_set_phys_addr(hdmi->cec_notifier, > + CEC_PHYS_ADDR_INVALID); > + } > + > if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { > dev_dbg(hdmi->dev, "EVENT=%s\n", > phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); > @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, > if (ret) > goto err_iahb; > > + hdmi->cec_notifier = cec_notifier_get(dev); > + if (!hdmi->cec_notifier) { > + ret = -ENOMEM; > + goto err_iahb; > + } > + > /* > * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator > * N and cts values before enabling phy > @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, > hdmi->ddc = NULL; > } > > + if (hdmi->cec_notifier) > + cec_notifier_put(hdmi->cec_notifier); > + > clk_disable_unprepare(hdmi->iahb_clk); > err_isfr: > clk_disable_unprepare(hdmi->isfr_clk); > 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 <narmstrong@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Thanks Russell for the patch, Neil
On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote: > On 05/30/2017 04:23 PM, 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 <rmk+kernel@armlinux.org.uk> > > --- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- > > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > index 4e1f54a675d8..966422576c44 100644 > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > @@ -36,7 +36,10 @@ > > #include "dw-hdmi.h" > > #include "dw-hdmi-audio.h" > > > > +#include <media/cec-notifier.h> > > + > > #define DDC_SEGMENT_ADDR 0x30 > > + > > #define HDMI_EDID_LEN 512 > > > > enum hdmi_datamap { > > @@ -173,6 +176,8 @@ struct dw_hdmi { > > > > unsigned int reg_shift; > > struct regmap *regm; > > + > > + struct cec_notifier *cec_notifier; > > }; > > > > #define HDMI_IH_PHY_STAT0_RX_SENSE \ > > @@ -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); > > @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) > > * ask the source to re-read the EDID. > > */ > > if (intr_stat & > > - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) > > + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { > > __dw_hdmi_setup_rx_sense(hdmi, > > phy_stat & HDMI_PHY_HPD, > > phy_stat & HDMI_PHY_RX_SENSE); > > > > + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) > > + cec_notifier_set_phys_addr(hdmi->cec_notifier, > > + CEC_PHYS_ADDR_INVALID); > > + } > > + > > if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { > > dev_dbg(hdmi->dev, "EVENT=%s\n", > > phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); > > @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, > > if (ret) > > goto err_iahb; > > > > + hdmi->cec_notifier = cec_notifier_get(dev); > > + if (!hdmi->cec_notifier) { > > + ret = -ENOMEM; > > + goto err_iahb; > > + } > > + > > /* > > * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator > > * N and cts values before enabling phy > > @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, > > hdmi->ddc = NULL; > > } > > > > + if (hdmi->cec_notifier) > > + cec_notifier_put(hdmi->cec_notifier); > > + > > clk_disable_unprepare(hdmi->iahb_clk); > > err_isfr: > > clk_disable_unprepare(hdmi->isfr_clk); > > > > 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.)
On 09/06/17 15:38, Russell King - ARM Linux wrote: > On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote: >> On 05/30/2017 04:23 PM, 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 <rmk+kernel@armlinux.org.uk> >>> --- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- >>> 1 file changed, 21 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index 4e1f54a675d8..966422576c44 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -36,7 +36,10 @@ >>> #include "dw-hdmi.h" >>> #include "dw-hdmi-audio.h" >>> >>> +#include <media/cec-notifier.h> >>> + >>> #define DDC_SEGMENT_ADDR 0x30 >>> + >>> #define HDMI_EDID_LEN 512 >>> >>> enum hdmi_datamap { >>> @@ -173,6 +176,8 @@ struct dw_hdmi { >>> >>> unsigned int reg_shift; >>> struct regmap *regm; >>> + >>> + struct cec_notifier *cec_notifier; >>> }; >>> >>> #define HDMI_IH_PHY_STAT0_RX_SENSE \ >>> @@ -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); >>> @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) >>> * ask the source to re-read the EDID. >>> */ >>> if (intr_stat & >>> - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) >>> + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { >>> __dw_hdmi_setup_rx_sense(hdmi, >>> phy_stat & HDMI_PHY_HPD, >>> phy_stat & HDMI_PHY_RX_SENSE); >>> >>> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) >>> + cec_notifier_set_phys_addr(hdmi->cec_notifier, >>> + CEC_PHYS_ADDR_INVALID); >>> + } >>> + >>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { >>> dev_dbg(hdmi->dev, "EVENT=%s\n", >>> phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); >>> @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, >>> if (ret) >>> goto err_iahb; >>> >>> + hdmi->cec_notifier = cec_notifier_get(dev); >>> + if (!hdmi->cec_notifier) { >>> + ret = -ENOMEM; >>> + goto err_iahb; >>> + } >>> + >>> /* >>> * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator >>> * N and cts values before enabling phy >>> @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, >>> hdmi->ddc = NULL; >>> } >>> >>> + if (hdmi->cec_notifier) >>> + cec_notifier_put(hdmi->cec_notifier); >>> + >>> clk_disable_unprepare(hdmi->iahb_clk); >>> err_isfr: >>> clk_disable_unprepare(hdmi->isfr_clk); >>> >> >> 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
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: >> On 05/30/2017 04:23 PM, 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 <rmk+kernel@armlinux.org.uk> >>> --- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- >>> 1 file changed, 21 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index 4e1f54a675d8..966422576c44 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -36,7 +36,10 @@ >>> #include "dw-hdmi.h" >>> #include "dw-hdmi-audio.h" >>> >>> +#include <media/cec-notifier.h> >>> + >>> #define DDC_SEGMENT_ADDR 0x30 >>> + >>> #define HDMI_EDID_LEN 512 >>> >>> enum hdmi_datamap { >>> @@ -173,6 +176,8 @@ struct dw_hdmi { >>> >>> unsigned int reg_shift; >>> struct regmap *regm; >>> + >>> + struct cec_notifier *cec_notifier; >>> }; >>> >>> #define HDMI_IH_PHY_STAT0_RX_SENSE \ >>> @@ -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); >>> @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) >>> * ask the source to re-read the EDID. >>> */ >>> if (intr_stat & >>> - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) >>> + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { >>> __dw_hdmi_setup_rx_sense(hdmi, >>> phy_stat & HDMI_PHY_HPD, >>> phy_stat & HDMI_PHY_RX_SENSE); >>> >>> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) >>> + cec_notifier_set_phys_addr(hdmi->cec_notifier, >>> + CEC_PHYS_ADDR_INVALID); >>> + } >>> + >>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { >>> dev_dbg(hdmi->dev, "EVENT=%s\n", >>> phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); >>> @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, >>> if (ret) >>> goto err_iahb; >>> >>> + hdmi->cec_notifier = cec_notifier_get(dev); >>> + if (!hdmi->cec_notifier) { >>> + ret = -ENOMEM; >>> + goto err_iahb; >>> + } >>> + >>> /* >>> * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator >>> * N and cts values before enabling phy >>> @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, >>> hdmi->ddc = NULL; >>> } >>> >>> + if (hdmi->cec_notifier) >>> + cec_notifier_put(hdmi->cec_notifier); >>> + >>> clk_disable_unprepare(hdmi->iahb_clk); >>> err_isfr: >>> clk_disable_unprepare(hdmi->isfr_clk); >>> >> >> 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
On 09/06/17 15:56, Neil Armstrong wrote: > 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: >>> On 05/30/2017 04:23 PM, 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 <rmk+kernel@armlinux.org.uk> >>>> --- >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- >>>> 1 file changed, 21 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>>> index 4e1f54a675d8..966422576c44 100644 >>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>>> @@ -36,7 +36,10 @@ >>>> #include "dw-hdmi.h" >>>> #include "dw-hdmi-audio.h" >>>> >>>> +#include <media/cec-notifier.h> >>>> + >>>> #define DDC_SEGMENT_ADDR 0x30 >>>> + >>>> #define HDMI_EDID_LEN 512 >>>> >>>> enum hdmi_datamap { >>>> @@ -173,6 +176,8 @@ struct dw_hdmi { >>>> >>>> unsigned int reg_shift; >>>> struct regmap *regm; >>>> + >>>> + struct cec_notifier *cec_notifier; >>>> }; >>>> >>>> #define HDMI_IH_PHY_STAT0_RX_SENSE \ >>>> @@ -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); >>>> @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) >>>> * ask the source to re-read the EDID. >>>> */ >>>> if (intr_stat & >>>> - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) >>>> + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { >>>> __dw_hdmi_setup_rx_sense(hdmi, >>>> phy_stat & HDMI_PHY_HPD, >>>> phy_stat & HDMI_PHY_RX_SENSE); >>>> >>>> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) >>>> + cec_notifier_set_phys_addr(hdmi->cec_notifier, >>>> + CEC_PHYS_ADDR_INVALID); >>>> + } >>>> + >>>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { >>>> dev_dbg(hdmi->dev, "EVENT=%s\n", >>>> phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); >>>> @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, >>>> if (ret) >>>> goto err_iahb; >>>> >>>> + hdmi->cec_notifier = cec_notifier_get(dev); >>>> + if (!hdmi->cec_notifier) { >>>> + ret = -ENOMEM; >>>> + goto err_iahb; >>>> + } >>>> + >>>> /* >>>> * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator >>>> * N and cts values before enabling phy >>>> @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, >>>> hdmi->ddc = NULL; >>>> } >>>> >>>> + if (hdmi->cec_notifier) >>>> + cec_notifier_put(hdmi->cec_notifier); >>>> + >>>> clk_disable_unprepare(hdmi->iahb_clk); >>>> err_isfr: >>>> clk_disable_unprepare(hdmi->isfr_clk); >>>> >>> >>> 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... 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. > >> >> 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
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.
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 <rmk+kernel@armlinux.org.uk> 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 <hans.verkuil@cisco.com> Regards, Hans > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 4e1f54a675d8..966422576c44 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -36,7 +36,10 @@ > #include "dw-hdmi.h" > #include "dw-hdmi-audio.h" > > +#include <media/cec-notifier.h> > + > #define DDC_SEGMENT_ADDR 0x30 > + > #define HDMI_EDID_LEN 512 > > enum hdmi_datamap { > @@ -173,6 +176,8 @@ struct dw_hdmi { > > unsigned int reg_shift; > struct regmap *regm; > + > + struct cec_notifier *cec_notifier; > }; > > #define HDMI_IH_PHY_STAT0_RX_SENSE \ > @@ -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); > @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) > * ask the source to re-read the EDID. > */ > if (intr_stat & > - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) > + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { > __dw_hdmi_setup_rx_sense(hdmi, > phy_stat & HDMI_PHY_HPD, > phy_stat & HDMI_PHY_RX_SENSE); > > + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) > + cec_notifier_set_phys_addr(hdmi->cec_notifier, > + CEC_PHYS_ADDR_INVALID); > + } > + > if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { > dev_dbg(hdmi->dev, "EVENT=%s\n", > phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); > @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, > if (ret) > goto err_iahb; > > + hdmi->cec_notifier = cec_notifier_get(dev); > + if (!hdmi->cec_notifier) { > + ret = -ENOMEM; > + goto err_iahb; > + } > + > /* > * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator > * N and cts values before enabling phy > @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, > hdmi->ddc = NULL; > } > > + if (hdmi->cec_notifier) > + cec_notifier_put(hdmi->cec_notifier); > + > clk_disable_unprepare(hdmi->iahb_clk); > err_isfr: > clk_disable_unprepare(hdmi->isfr_clk); >
On 09/06/17 16:10, Russell King - ARM Linux wrote: > 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. > 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
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: >> 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. 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
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: > > 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. > > 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.)
On 17/07/17 11:05, Russell King - ARM Linux wrote: > 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: >>> 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. >> >> 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.) >
On 17/07/17 11:05, Russell King - ARM Linux wrote: > 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: >>> 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. >> >> 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 :-)
On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote: > On 17/07/17 11:05, Russell King - ARM Linux wrote: > > 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: > >>> 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. > >> > >> 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.
On 17/07/17 14:05, Russell King - ARM Linux wrote: > On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote: >> On 17/07/17 11:05, Russell King - ARM Linux wrote: >>> 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: >>>>> 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. >>>> >>>> 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
Hi Russell, On 07/17/2017 02:23 PM, Hans Verkuil wrote: > On 17/07/17 14:05, Russell King - ARM Linux wrote: >> On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote: >>> On 17/07/17 11:05, Russell King - ARM Linux wrote: >>>> 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: >>>>>> 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. >>>>> >>>>> 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. 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
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: > >On 17/07/17 14:05, Russell King - ARM Linux wrote: > >>On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote: > >>>On 17/07/17 11:05, Russell King - ARM Linux wrote: > >>>>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: > >>>>>>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. > >>>>> > >>>>>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. > > 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.
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: > > 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.
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 4e1f54a675d8..966422576c44 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -36,7 +36,10 @@ #include "dw-hdmi.h" #include "dw-hdmi-audio.h" +#include <media/cec-notifier.h> + #define DDC_SEGMENT_ADDR 0x30 + #define HDMI_EDID_LEN 512 enum hdmi_datamap { @@ -173,6 +176,8 @@ struct dw_hdmi { unsigned int reg_shift; struct regmap *regm; + + struct cec_notifier *cec_notifier; }; #define HDMI_IH_PHY_STAT0_RX_SENSE \ @@ -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); @@ -2108,11 +2114,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) * ask the source to re-read the EDID. */ if (intr_stat & - (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { __dw_hdmi_setup_rx_sense(hdmi, phy_stat & HDMI_PHY_HPD, phy_stat & HDMI_PHY_RX_SENSE); + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) + cec_notifier_set_phys_addr(hdmi->cec_notifier, + CEC_PHYS_ADDR_INVALID); + } + if (intr_stat & HDMI_IH_PHY_STAT0_HPD) { dev_dbg(hdmi->dev, "EVENT=%s\n", phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout"); @@ -2365,6 +2376,12 @@ __dw_hdmi_probe(struct platform_device *pdev, if (ret) goto err_iahb; + hdmi->cec_notifier = cec_notifier_get(dev); + if (!hdmi->cec_notifier) { + ret = -ENOMEM; + goto err_iahb; + } + /* * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator * N and cts values before enabling phy @@ -2437,6 +2454,9 @@ __dw_hdmi_probe(struct platform_device *pdev, hdmi->ddc = NULL; } + if (hdmi->cec_notifier) + cec_notifier_put(hdmi->cec_notifier); + clk_disable_unprepare(hdmi->iahb_clk); err_isfr: clk_disable_unprepare(hdmi->isfr_clk);
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 <rmk+kernel@armlinux.org.uk> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)