Re: [PATCH RESEND v2 05/19] media: vivid: Include in vivid-vid-cap.c
On 09/09/2024 09:53, Uros Bizjak wrote:
> Substitute the inclusion of header with
> to allow the removal of legacy inclusion
> of from .
>
> Signed-off-by: Uros Bizjak
Acked-by: Hans Verkuil
Regards,
Hans
> Cc: Hans Verkuil
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> ---
> drivers/media/test-drivers/vivid/vivid-vid-cap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/test-drivers/vivid/vivid-vid-cap.c
> b/drivers/media/test-drivers/vivid/vivid-vid-cap.c
> index 69620e0a35a0..184460eb356e 100644
> --- a/drivers/media/test-drivers/vivid/vivid-vid-cap.c
> +++ b/drivers/media/test-drivers/vivid/vivid-vid-cap.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
On 05/04/2024 12:18, Wolfram Sang wrote: > Hello Easwar, > > On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote: >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" >> with more appropriate terms. Inspired by and following on to Wolfram's >> series to fix drivers/i2c/[1], fix the terminology for users of the >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists >> in the specification. > > I really appreciate that you want to assist in this task to improve the > I2C core. I do. I am afraid, however, that you took the second step > before the first one, though. As I mentioned in my original cover > letter, this is not only about renaming but also improving the I2C API > (splitting up header files...). So, drivers are not a priority right > now. They can be better fixed once the core is ready. > > It is true that I changed quite some controller drivers within the i2c > realm. I did this to gain experience. As you also noticed quite some > questions came up. We need to agree on answers first. And once we are > happy with the answers we found, then IMO we can go outside of the i2c > realm and send patches to other subsystems referencing agreed > precedence. I intentionally did not go outside i2c yet. Since your > patches are already there, you probably want to foster them until they > are ready for inclusion. Yet, regarding further patches, my suggestion > is to wait until the core is ready. That might take a while, though. > However, there is enough to discuss until the core is ready. So, your > collaboration there is highly appreciated! > >> The last patch updating the .master_xfer method to .xfer depends on >> patch 1 of Wolfram's series below, but the series is otherwise >> independent. It may make sense for the last patch to go in with > > Please drop the last patch from this series. It will nicely remove the > dependency. Also, like above, I first want to gain experience with i2c > before going to other subsystems. That was intended. OK, based on this I'll mark the media patches in this series as 'Deferred' in our patchwork. Regards, Hans > > All the best and happy hacking, > >Wolfram >
Re: [Intel-gfx] [PATCH 4/6] drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid
On 24/08/2023 15:46, Jani Nikula wrote:
> Connectors have source physical address available in display
> info. There's no need to parse the EDID again for this. Add
> drm_dp_cec_attach() to do this.
>
> Seems like the set_edid/unset_edid naming is a bit specific now that
> there's no need to pass the EDID at all, so aim for attach/detach going
> forward.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_cec.c | 22 +++---
> include/drm/display/drm_dp_helper.h | 6 ++
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_cec.c
> b/drivers/gpu/drm/display/drm_dp_cec.c
> index ae39dc794190..da7a7d357446 100644
> --- a/drivers/gpu/drm/display/drm_dp_cec.c
> +++ b/drivers/gpu/drm/display/drm_dp_cec.c
> @@ -297,7 +297,7 @@ static void drm_dp_cec_unregister_work(struct work_struct
> *work)
> * were unchanged and just update the CEC physical address. Otherwise
> * unregister the old CEC adapter and create a new one.
> */
> -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address)
> {
> struct drm_connector *connector = aux->cec.connector;
> u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> @@ -339,7 +339,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(adap, source_physical_address, false);
As the kernel test robot indicated, this does not compile, this should
be aux->cec.adap.
> goto unlock;
> }
> /*
> @@ -370,11 +370,27 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>* from drm_dp_cec_register_connector() edid == NULL, so in
>* that case the phys addr is just invalidated.
>*/
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(adap, source_physical_address, false);
> }
> unlock:
> mutex_unlock(&aux->cec.lock);
> }
> +EXPORT_SYMBOL(drm_dp_cec_attach);
> +
> +/*
> + * Note: Prefer calling drm_dp_cec_attach() with
> + * connector->display_info.source_physical_address if possible.
> + */
> +void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +{
> + u16 source_physical_address = CEC_PHYS_ADDR_INVALID;
> +
> + if (edid && edid->extensions)
And this source needs to include , also as found by
the kernel test robot.
Regards,
Hans
> + pa = cec_get_edid_phys_addr((const u8 *)edid,
> + EDID_LENGTH * (edid->extensions +
> 1), NULL);
> +
> + drm_dp_cec_attach(aux, source_physical_address);
> +}
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
>
> /*
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 86f24a759268..3369104e2d25 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -699,6 +699,7 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux);
> void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> struct drm_connector *connector);
> void drm_dp_cec_unregister_connector(struct drm_dp_aux *aux);
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address);
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid);
> void drm_dp_cec_unset_edid(struct drm_dp_aux *aux);
> #else
> @@ -716,6 +717,11 @@ static inline void
> drm_dp_cec_unregister_connector(struct drm_dp_aux *aux)
> {
> }
>
> +static inline void drm_dp_cec_attach(struct drm_dp_aux *aux,
> + u16 source_physical_address)
> +{
> +}
> +
> static inline void drm_dp_cec_set_edid(struct drm_dp_aux *aux,
> const struct edid *edid)
> {
Re: [Intel-gfx] [PATCH 0/6] drm, cec and edid updates
On 31/08/2023 20:51, Jani Nikula wrote: > On Thu, 24 Aug 2023, Jani Nikula wrote: >> Avoid accessing the raw edid directly. Pre-parse the source physical >> address during normal EDID parsing and use that for CEC. >> >> Jani Nikula (6): >> drm/edid: add drm_edid_is_digital() >> drm/i915/display: use drm_edid_is_digital() >> drm/edid: parse source physical address >> drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid >> drm/i915/cec: switch to setting physical address directly > > Maarten, Maxime, Thomas, ack for merging patches 1, 3 and 4 via via > drm-intel? > >> media: cec: core: add note about *_from_edid() function usage in drm > > Hans, while there's no build dependency here, I think it would make > sense to merge this together with patches 3 and 4. Ack for merging via > drm-intel? That's fine, it makes sense to do that. If you need it, for this series: Acked-by: Hans Verkuil Regards, Hans > > Thanks, > Jani. > > >> >> drivers/gpu/drm/display/drm_dp_cec.c | 22 +++--- >> drivers/gpu/drm/drm_edid.c| 22 -- >> drivers/gpu/drm/i915/display/intel_crt.c | 11 --- >> drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- >> drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++- >> drivers/gpu/drm/i915/display/intel_sdvo.c | 7 ++- >> drivers/media/cec/core/cec-adap.c | 4 >> drivers/media/cec/core/cec-notifier.c | 4 >> include/drm/display/drm_dp_helper.h | 6 ++ >> include/drm/drm_connector.h | 8 >> include/drm/drm_edid.h| 1 + >> 11 files changed, 73 insertions(+), 27 deletions(-) >
Re: [Intel-gfx] [PATCH 3/6] drm/edid: parse source physical address
On 24/08/2023 15:46, Jani Nikula wrote:
> CEC needs the source physical address. Parsing it is trivial with the
> existing EDID CEA DB infrastructure.
>
> Default to CEC_PHYS_ADDR_INVALID (0x) instead of 0 to cater for
> easier CEC usage.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/gpu/drm/drm_edid.c | 5 +
> include/drm/drm_connector.h | 8
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1dbb15439468..39dd3f694544 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -29,6 +29,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -6192,6 +6193,8 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
> *connector, const u8 *db)
>
> info->is_hdmi = true;
>
> + info->source_physical_address = (db[4] << 8) | db[5];
> +
> if (len >= 6)
> info->dvi_dual = db[6] & 1;
> if (len >= 7)
> @@ -6470,6 +6473,8 @@ static void drm_reset_display_info(struct drm_connector
> *connector)
> info->vics_len = 0;
>
> info->quirks = 0;
> +
> + info->source_physical_address = CEC_PHYS_ADDR_INVALID;
> }
>
> static void update_displayid_info(struct drm_connector *connector,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index d300fde6c1a4..40a5e7acf2fa 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -816,6 +816,14 @@ struct drm_display_info {
>* @quirks: EDID based quirks. Internal to EDID parsing.
>*/
> u32 quirks;
> +
> + /**
> + * @source_physical_address: Source Physical Address from HDMI
> + * Vendor-Specific Data Block, for CEC usage.
> + *
> + * Defaults to CEC_PHYS_ADDR_INVALID (0x).
> + */
> + u16 source_physical_address;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
Re: [Intel-gfx] [PATCH 6/6] media: cec: core: add note about *_from_edid() function usage in drm
On 24/08/2023 15:46, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/media/cec/core/cec-adap.c | 4
> drivers/media/cec/core/cec-notifier.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/media/cec/core/cec-adap.c
> b/drivers/media/cec/core/cec-adap.c
> index 241b1621b197..2c627ed611ed 100644
> --- a/drivers/media/cec/core/cec-adap.c
> +++ b/drivers/media/cec/core/cec-adap.c
> @@ -1688,6 +1688,10 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16
> phys_addr, bool block)
> }
> EXPORT_SYMBOL_GPL(cec_s_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling cec_s_phys_addr() with
> + * connector->display_info.source_physical_address if possible.
> + */
I would rephrase this:
/*
* Note: in the drm subsystem, prefer calling (if possible):
*
* cec_s_phys_addr(adap, connector->display_info.source_physical_address,
false);
*/
I think it is important to indicate that the last argument should be 'false'.
> void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
> const struct edid *edid)
> {
> diff --git a/drivers/media/cec/core/cec-notifier.c
> b/drivers/media/cec/core/cec-notifier.c
> index 389dc664b211..13f043b3025b 100644
> --- a/drivers/media/cec/core/cec-notifier.c
> +++ b/drivers/media/cec/core/cec-notifier.c
> @@ -195,6 +195,10 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n,
> u16 pa)
> }
> EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling cec_notifier_set_phys_addr()
> with
> + * connector->display_info.source_physical_address if possible.
> + */
This comment is fine, there is no similar last argument here. But perhaps
it is good to use a similar format as above. Up to you.
> void cec_notifier_set_phys_addr_from_edid(struct cec_notifier *n,
> const struct edid *edid)
> {
Regards,
Hans
Re: [Intel-gfx] [PATCH v2] drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid
Hi Jani,
Sorry, I missed the v2.
On 25/08/2023 15:01, Jani Nikula wrote:
> Connectors have source physical address available in display
> info. There's no need to parse the EDID again for this. Add
> drm_dp_cec_attach() to do this.
>
> Seems like the set_edid/unset_edid naming is a bit specific now that
> there's no need to pass the EDID at all, so aim for attach/detach going
> forward.
>
> v2: Fix the embarrashing build failures
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/gpu/drm/display/drm_dp_cec.c | 23 ---
> include/drm/display/drm_dp_helper.h | 6 ++
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_cec.c
> b/drivers/gpu/drm/display/drm_dp_cec.c
> index ae39dc794190..007ceb281d00 100644
> --- a/drivers/gpu/drm/display/drm_dp_cec.c
> +++ b/drivers/gpu/drm/display/drm_dp_cec.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -297,7 +298,7 @@ static void drm_dp_cec_unregister_work(struct work_struct
> *work)
> * were unchanged and just update the CEC physical address. Otherwise
> * unregister the old CEC adapter and create a new one.
> */
> -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address)
> {
> struct drm_connector *connector = aux->cec.connector;
> u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> @@ -339,7 +340,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(aux->cec.adap, source_physical_address,
> false);
> goto unlock;
> }
> /*
> @@ -370,11 +371,27 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>* from drm_dp_cec_register_connector() edid == NULL, so in
>* that case the phys addr is just invalidated.
>*/
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(aux->cec.adap, source_physical_address, false);
> }
> unlock:
> mutex_unlock(&aux->cec.lock);
> }
> +EXPORT_SYMBOL(drm_dp_cec_attach);
> +
> +/*
> + * Note: Prefer calling drm_dp_cec_attach() with
> + * connector->display_info.source_physical_address if possible.
> + */
> +void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +{
> + u16 pa = CEC_PHYS_ADDR_INVALID;
> +
> + if (edid && edid->extensions)
> + pa = cec_get_edid_phys_addr((const u8 *)edid,
> + EDID_LENGTH * (edid->extensions +
> 1), NULL);
> +
> + drm_dp_cec_attach(aux, pa);
> +}
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
>
> /*
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 86f24a759268..3369104e2d25 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -699,6 +699,7 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux);
> void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> struct drm_connector *connector);
> void drm_dp_cec_unregister_connector(struct drm_dp_aux *aux);
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address);
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid);
> void drm_dp_cec_unset_edid(struct drm_dp_aux *aux);
> #else
> @@ -716,6 +717,11 @@ static inline void
> drm_dp_cec_unregister_connector(struct drm_dp_aux *aux)
> {
> }
>
> +static inline void drm_dp_cec_attach(struct drm_dp_aux *aux,
> + u16 source_physical_address)
> +{
> +}
> +
> static inline void drm_dp_cec_set_edid(struct drm_dp_aux *aux,
> const struct edid *edid)
> {
Re: [Intel-gfx] [PATCH v2] media: cec: core: add note about *_from_edid() function usage in drm
On 31/08/2023 12:51, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Thanks!
Hans
>
> ---
>
> v2: rephrase comments, in particular indicate cec_s_phys_addr() should
> be false (Hans)
> ---
> drivers/media/cec/core/cec-adap.c | 5 +
> drivers/media/cec/core/cec-notifier.c | 5 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/media/cec/core/cec-adap.c
> b/drivers/media/cec/core/cec-adap.c
> index 241b1621b197..1109af525c35 100644
> --- a/drivers/media/cec/core/cec-adap.c
> +++ b/drivers/media/cec/core/cec-adap.c
> @@ -1688,6 +1688,11 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16
> phys_addr, bool block)
> }
> EXPORT_SYMBOL_GPL(cec_s_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling (if possible):
> + *
> + * cec_s_phys_addr(adap, connector->display_info.source_physical_address,
> false);
> + */
> void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
> const struct edid *edid)
> {
> diff --git a/drivers/media/cec/core/cec-notifier.c
> b/drivers/media/cec/core/cec-notifier.c
> index 389dc664b211..d600be0f7b67 100644
> --- a/drivers/media/cec/core/cec-notifier.c
> +++ b/drivers/media/cec/core/cec-notifier.c
> @@ -195,6 +195,11 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n,
> u16 pa)
> }
> EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling (if possible):
> + *
> + * cec_notifier_set_phys_addr(n,
> connector->display_info.source_physical_address);
> + */
> void cec_notifier_set_phys_addr_from_edid(struct cec_notifier *n,
> const struct edid *edid)
> {
Re: [Intel-gfx] [PATCH 5/6] drm/i915/cec: switch to setting physical address directly
On 24/08/2023 15:46, Jani Nikula wrote: > Avoid parsing the EDID again for source physical address. Also gets rids > of a few remaining raw EDID usages. > > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Jani Nikula Reviewed-by: Hans Verkuil Regards, Hans > --- > drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- > drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++--- > 2 files changed, 4 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 7067ee3a4bd3..c4b8e0e74c15 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -5198,7 +5198,6 @@ intel_dp_set_edid(struct intel_dp *intel_dp) > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > struct intel_connector *connector = intel_dp->attached_connector; > const struct drm_edid *drm_edid; > - const struct edid *edid; > bool vrr_capable; > > intel_dp_unset_edid(intel_dp); > @@ -5216,10 +5215,8 @@ intel_dp_set_edid(struct intel_dp *intel_dp) > intel_dp_update_dfp(intel_dp, drm_edid); > intel_dp_update_420(intel_dp); > > - /* FIXME: Get rid of drm_edid_raw() */ > - edid = drm_edid_raw(drm_edid); > - > - drm_dp_cec_set_edid(&intel_dp->aux, edid); > + drm_dp_cec_attach(&intel_dp->aux, > + connector->base.display_info.source_physical_address); > } > > static void > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c > b/drivers/gpu/drm/i915/display/intel_hdmi.c > index aa9915098dda..5d6255ee8b54 100644 > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > @@ -2482,9 +2482,8 @@ intel_hdmi_set_edid(struct drm_connector *connector) > > intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref); > > - /* FIXME: Get rid of drm_edid_raw() */ > - cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, > - drm_edid_raw(drm_edid)); > + cec_notifier_set_phys_addr(intel_hdmi->cec_notifier, > + > connector->display_info.source_physical_address); > > return connected; > }
Re: [Intel-gfx] [PATCH v2 1/7] media: videobuf2: Don't assert held reservation lock for dma-buf mmapping
On 06/04/2023 18:06, Dmitry Osipenko wrote:
> Don't assert held dma-buf reservation lock on memory mapping of exported
> buffer.
>
> We're going to change dma-buf mmap() locking policy such that exporters
> will have to handle the lock. The previous locking policy caused deadlock
> problem for DRM drivers in a case of self-imported dma-bufs once these
> drivers are moved to use reservation lock universally. The problem is
> solved by moving the lock down to exporters. This patch prepares videobuf2
> for the locking policy update.
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 ---
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 ---
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 3 ---
> 3 files changed, 9 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 205d3cac425c..2fa455d4a048 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -11,7 +11,6 @@
> */
>
> #include
> -#include
> #include
> #include
> #include
> @@ -456,8 +455,6 @@ static int vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf,
> struct iosys_map *map)
> static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
> struct vm_area_struct *vma)
> {
> - dma_resv_assert_held(dbuf->resv);
> -
> return vb2_dc_mmap(dbuf->priv, vma);
> }
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index 183037fb1273..28f3fdfe23a2 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -10,7 +10,6 @@
> * the Free Software Foundation.
> */
>
> -#include
> #include
> #include
> #include
> @@ -498,8 +497,6 @@ static int vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf
> *dbuf,
> static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
> struct vm_area_struct *vma)
> {
> - dma_resv_assert_held(dbuf->resv);
> -
> return vb2_dma_sg_mmap(dbuf->priv, vma);
> }
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index a6c6d2fcaaa4..7c635e292106 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -10,7 +10,6 @@
> * the Free Software Foundation.
> */
>
> -#include
> #include
> #include
> #include
> @@ -319,8 +318,6 @@ static int vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf
> *dbuf,
> static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
> struct vm_area_struct *vma)
> {
> - dma_resv_assert_held(dbuf->resv);
> -
> return vb2_vmalloc_mmap(dbuf->priv, vma);
> }
>
Re: [Intel-gfx] [PATCH v7 13/21] media: videobuf2: Prepare to dynamic dma-buf locking specification
On 10/17/22 19:22, Dmitry Osipenko wrote:
> Prepare V4L2 memory allocators to the common dynamic dma-buf locking
> convention by starting to use the unlocked versions of dma-buf API
> functions.
>
> Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Thanks!
Hans
> Acked-by: Christian König
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 ++-
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 6 +++---
> 3 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 678b359717c4..79f4d8301fbb 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -101,7 +101,7 @@ static void *vb2_dc_vaddr(struct vb2_buffer *vb, void
> *buf_priv)
> if (buf->db_attach) {
> struct iosys_map map;
>
> - if (!dma_buf_vmap(buf->db_attach->dmabuf, &map))
> + if (!dma_buf_vmap_unlocked(buf->db_attach->dmabuf, &map))
> buf->vaddr = map.vaddr;
>
> return buf->vaddr;
> @@ -711,7 +711,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
> }
>
> /* get the associated scatterlist for this buffer */
> - sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
> + sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
> if (IS_ERR(sgt)) {
> pr_err("Error getting dmabuf scatterlist\n");
> return -EINVAL;
> @@ -722,7 +722,8 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
> if (contig_size < buf->size) {
> pr_err("contiguous chunk is too small %lu/%lu\n",
> contig_size, buf->size);
> - dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> + dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt,
> + buf->dma_dir);
> return -EFAULT;
> }
>
> @@ -750,10 +751,10 @@ static void vb2_dc_unmap_dmabuf(void *mem_priv)
> }
>
> if (buf->vaddr) {
> - dma_buf_vunmap(buf->db_attach->dmabuf, &map);
> + dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, &map);
> buf->vaddr = NULL;
> }
> - dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> + dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
>
> buf->dma_addr = 0;
> buf->dma_sgt = NULL;
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index fa69158a65b1..36ecdea8d707 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -309,7 +309,7 @@ static void *vb2_dma_sg_vaddr(struct vb2_buffer *vb, void
> *buf_priv)
>
> if (!buf->vaddr) {
> if (buf->db_attach) {
> - ret = dma_buf_vmap(buf->db_attach->dmabuf, &map);
> + ret = dma_buf_vmap_unlocked(buf->db_attach->dmabuf,
> &map);
> buf->vaddr = ret ? NULL : map.vaddr;
> } else {
> buf->vaddr = vm_map_ram(buf->pages, buf->num_pages, -1);
> @@ -565,7 +565,7 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv)
> }
>
> /* get the associated scatterlist for this buffer */
> - sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
> + sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
> if (IS_ERR(sgt)) {
> pr_err("Error getting dmabuf scatterlist\n");
> return -EINVAL;
> @@ -594,10 +594,10 @@ static void vb2_dma_sg_unmap_dmabuf(void *mem_priv)
> }
>
> if (buf->vaddr) {
> - dma_buf_vunmap(buf->db_attach->dmabuf, &map);
> + dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, &map);
> buf->vaddr = NULL;
> }
> - dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> + dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
>
> buf->dma_sgt = NULL;
> }
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> inde
Re: [Intel-gfx] [PATCH v7 14/21] media: tegra-vde: Prepare to dynamic dma-buf locking specification
On 10/17/22 19:22, Dmitry Osipenko wrote:
> Prepare Tegra video decoder driver to the common dynamic dma-buf
> locking convention by starting to use the unlocked versions of dma-buf
> API functions.
>
> Acked-by: Christian König
Acked-by: Hans Verkuil
Thanks!
Hans
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
> b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
> index 69c346148070..1c5b94989aec 100644
> --- a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
> +++ b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
> @@ -38,7 +38,7 @@ static void tegra_vde_release_entry(struct
> tegra_vde_cache_entry *entry)
> if (entry->vde->domain)
> tegra_vde_iommu_unmap(entry->vde, entry->iova);
>
> - dma_buf_unmap_attachment(entry->a, entry->sgt, entry->dma_dir);
> + dma_buf_unmap_attachment_unlocked(entry->a, entry->sgt, entry->dma_dir);
> dma_buf_detach(dmabuf, entry->a);
> dma_buf_put(dmabuf);
>
> @@ -102,7 +102,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
> goto err_unlock;
> }
>
> - sgt = dma_buf_map_attachment(attachment, dma_dir);
> + sgt = dma_buf_map_attachment_unlocked(attachment, dma_dir);
> if (IS_ERR(sgt)) {
> dev_err(dev, "Failed to get dmabufs sg_table\n");
> err = PTR_ERR(sgt);
> @@ -152,7 +152,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
> err_free:
> kfree(entry);
> err_unmap:
> - dma_buf_unmap_attachment(attachment, sgt, dma_dir);
> + dma_buf_unmap_attachment_unlocked(attachment, sgt, dma_dir);
> err_detach:
> dma_buf_detach(dmabuf, attachment);
> err_unlock:
Re: [Intel-gfx] [PATCH v3 8/9] media: videobuf2: Stop using internal dma-buf lock
Nice!
Acked-by: Hans Verkuil
Regards,
Hans
On 24/08/2022 12:22, Dmitry Osipenko wrote:
> All drivers that use dma-bufs have been moved to the updated locking
> specification and now dma-buf reservation is guaranteed to be locked
> by importers during the mapping operations. There is no need to take
> the internal dma-buf lock anymore. Remove locking from the videobuf2
> memory allocators.
>
> Acked-by: Tomasz Figa
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
> 3 files changed, 3 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index de762dbdaf78..2c69bf0470e7 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
> {
> struct vb2_dc_attachment *attach = db_attach->priv;
> - /* stealing dmabuf mutex to serialize map/unmap operations */
> - struct mutex *lock = &db_attach->dmabuf->lock;
> struct sg_table *sgt;
>
> - mutex_lock(lock);
> -
> sgt = &attach->sgt;
> /* return previously mapped sg table */
> - if (attach->dma_dir == dma_dir) {
> - mutex_unlock(lock);
> + if (attach->dma_dir == dma_dir)
> return sgt;
> - }
>
> /* release any previous cache */
> if (attach->dma_dir != DMA_NONE) {
> @@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
> DMA_ATTR_SKIP_CPU_SYNC)) {
> pr_err("failed to map scatterlist\n");
> - mutex_unlock(lock);
> return ERR_PTR(-EIO);
> }
>
> attach->dma_dir = dma_dir;
>
> - mutex_unlock(lock);
> -
> return sgt;
> }
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index 39e11600304a..e63e718c0bf7 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
> struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
> {
> struct vb2_dma_sg_attachment *attach = db_attach->priv;
> - /* stealing dmabuf mutex to serialize map/unmap operations */
> - struct mutex *lock = &db_attach->dmabuf->lock;
> struct sg_table *sgt;
>
> - mutex_lock(lock);
> -
> sgt = &attach->sgt;
> /* return previously mapped sg table */
> - if (attach->dma_dir == dma_dir) {
> - mutex_unlock(lock);
> + if (attach->dma_dir == dma_dir)
> return sgt;
> - }
>
> /* release any previous cache */
> if (attach->dma_dir != DMA_NONE) {
> @@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
> /* mapping to the client with new direction */
> if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
> pr_err("failed to map scatterlist\n");
> - mutex_unlock(lock);
> return ERR_PTR(-EIO);
> }
>
> attach->dma_dir = dma_dir;
>
> - mutex_unlock(lock);
> -
> return sgt;
> }
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 7831bf545874..41db707e43a4 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
> struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
> {
> struct vb2_vmalloc_attachment *attach = db_attach->priv;
> - /* stealing dmabuf mutex to serialize map/unmap operations */
> - struct mutex *lock = &db_attach->dmabuf->lock;
> struct sg_table *sgt;
>
> - mutex_lock(lock);
> -
> sgt = &attach->sgt;
> /* return previously mapped sg table */
> - if (attach->dma_dir == dma_dir) {
> - mutex_unlock(lock);
> + if (attach->dma_dir =
Re: [Intel-gfx] [PATCH v4] dma-buf-map: Rename to iosys-map
rs/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +- > drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 5 +- > drivers/gpu/drm/tegra/gem.c | 10 +- > drivers/gpu/drm/tiny/cirrus.c | 8 +- > drivers/gpu/drm/tiny/gm12u320.c | 7 +- > drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +- > drivers/gpu/drm/ttm/ttm_resource.c| 42 +-- > drivers/gpu/drm/ttm/ttm_tt.c | 8 +- > drivers/gpu/drm/udl/udl_modeset.c | 3 +- > drivers/gpu/drm/vboxvideo/vbox_mode.c | 4 +- > drivers/gpu/drm/vkms/vkms_composer.c | 4 +- > drivers/gpu/drm/vkms/vkms_drv.h | 6 +- > drivers/gpu/drm/vkms/vkms_plane.c | 2 +- > drivers/gpu/drm/vkms/vkms_writeback.c | 2 +- > drivers/gpu/drm/xen/xen_drm_front_gem.c | 7 +- > drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +- For these three: > .../common/videobuf2/videobuf2-dma-contig.c | 8 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 9 +- > .../common/videobuf2/videobuf2-vmalloc.c | 11 +- Acked-by: Hans Verkuil Regards, Hans
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
On 18/02/2021 09:52, Sean Young wrote:
> Hi,
>
> On Wed, Feb 17, 2021 at 05:29:46PM +0100, Hans Verkuil wrote:
>> On 17/02/2021 16:11, Sean Young wrote:
>>> On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
>>>> On 2/17/21 3:32 PM, Sean Young wrote:
>>>>> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
>>>>>> Hi Hans,
>>>>>>
>>>>>> On 17/02/2021 13:24, Hans de Goede wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> Fedora has a (opt-in) system to automatically collect backtraces from
>>>>>>> software
>>>>>>> crashing on users systems.
>>>>>>>
>>>>>>> This includes collecting kernel backtraces (including once triggered by
>>>>>>> WARN macros) while looking a the top 10 of the most reported backtrace
>>>>>>> during the
>>>>>>> last 2 weeks report from ABRT:
>>>>>>> https://retrace.fedoraproject.org/faf/problems/
>>>>>>>
>>>>>>> I noticed the following backtrace:
>>>>>>> https://retrace.fedoraproject.org/faf/problems/8150/
>>>>>>> which has been reported 17 times by Fedora users who have opted-in
>>>>>>> during the
>>>>>>> last 14 days.
>>>>>>>
>>>>>>> The issue here is that cec_register_adapter ends up calling
>>>>>>> request_module()
>>>>>>> from an async context, triggering this warn in kernel/kmod.c
>>>>>>> __request_module():
>>>>>>>
>>>>>>> /*
>>>>>>> * We don't allow synchronous module loading from async. Module
>>>>>>> * init may invoke async_synchronize_full() which will end up
>>>>>>> * waiting for this task which already is waiting for the module
>>>>>>> * loading to complete, leading to a deadlock.
>>>>>>> */
>>>>>>> WARN_ON_ONCE(wait && current_is_async());
>>>>>>>
>>>>>>> The call-path leading to this goes like this:
>>>>>>>
>>>>>>> ? kvasprintf+0x6d/0xa0
>>>>>>> ? kobject_set_name_vargs+0x6f/0x90
>>>>>>> rc_map_get+0x30/0x60
>>>>>>
>>>>>> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
>>>>>>
>>>>>> I've added Sean Young to the CC list.
>>>>>>
>>>>>> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is
>>>>>> set?
>>>>>>
>>>>>> I think this issue is very specific to CEC. I would not expect to see
>>>>>> this
>>>>>> with any other rc keymap.
>>>>>
>>>>> So CEC creates an RC device with a keymap (cec keymap, of course) and then
>>>>> the keymap needs to be loaded. We certainly don't want all keymaps as
>>>>> builtins, that would be a waste.
>>>>>
>>>>> The cec keymap is scanned once to build a map from cec codes to linux
>>>>> keycodes; making it builtin is not ideal, and makes the build system a
>>>>> bit messy.
>>>>>
>>>>> I don't think we can load the keymap later, user space may start remapping
>>>>> the keymap from udev.
>>>>>
>>>>> Possibly we could create the cec or rc device later but this could be a
>>>>> bit
>>>>> messy.
>>>>>
>>>>> Could CEC specify:
>>>>>
>>>>> #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
>>>>> MODULE_SOFTDEP("rc-cec")
>>>>> #endif
>>>>
>>>> That would need to be:
>>>>
>>>> MODULE_SOFTDEP("pre: rc-cec")
>>>>
>>>> I see that the drm_kms_helper and i915 drivers both depend on the cec
>>>> module already,
>>>> so yes if that module will request for rc-cec to be loaded before it is
>>>> loaded
>>>> (and thus before i915 is loaded) then that should work around this.
>>>>
>>>> Assuming the user is using a module-loader which honors the softdep...
>>>>
>>>> Also this assumes that rc_map_get is smart enough to not call
>>>> request_module()
>>>> if the module is already loaded, is that the case ?
>>>
>>> Yes, see rc_map_get().
>>
>> I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
>> y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
>> rc_main
>> is a module as well.
>
> Hmm, I'm not quite sure what is happening here. How can I reproduce this
> issue locally?
You need the right hardware for this, I'm afraid: this issue happens if you have
a DisplayPort-to-HDMI adapter that supports CEC and CONFIG_DRM_DP_CEC is set to
y.
In my case I have an Intel NUC with a USB-C to HDMI adapter from Club 3D
(CAC-2504).
I can easily test patches for you.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
On 17/02/2021 16:11, Sean Young wrote:
> Hi,
>
> On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
>> On 2/17/21 3:32 PM, Sean Young wrote:
>>> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
>>>> Hi Hans,
>>>>
>>>> On 17/02/2021 13:24, Hans de Goede wrote:
>>>>>
>>>>>
>>>>> Hi Hans,
>>>>>
>>>>> Fedora has a (opt-in) system to automatically collect backtraces from
>>>>> software
>>>>> crashing on users systems.
>>>>>
>>>>> This includes collecting kernel backtraces (including once triggered by
>>>>> WARN macros) while looking a the top 10 of the most reported backtrace
>>>>> during the
>>>>> last 2 weeks report from ABRT:
>>>>> https://retrace.fedoraproject.org/faf/problems/
>>>>>
>>>>> I noticed the following backtrace:
>>>>> https://retrace.fedoraproject.org/faf/problems/8150/
>>>>> which has been reported 17 times by Fedora users who have opted-in
>>>>> during the
>>>>> last 14 days.
>>>>>
>>>>> The issue here is that cec_register_adapter ends up calling
>>>>> request_module()
>>>>> from an async context, triggering this warn in kernel/kmod.c
>>>>> __request_module():
>>>>>
>>>>> /*
>>>>> * We don't allow synchronous module loading from async. Module
>>>>> * init may invoke async_synchronize_full() which will end up
>>>>> * waiting for this task which already is waiting for the module
>>>>> * loading to complete, leading to a deadlock.
>>>>> */
>>>>> WARN_ON_ONCE(wait && current_is_async());
>>>>>
>>>>> The call-path leading to this goes like this:
>>>>>
>>>>> ? kvasprintf+0x6d/0xa0
>>>>> ? kobject_set_name_vargs+0x6f/0x90
>>>>> rc_map_get+0x30/0x60
>>>>
>>>> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
>>>>
>>>> I've added Sean Young to the CC list.
>>>>
>>>> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is set?
>>>>
>>>> I think this issue is very specific to CEC. I would not expect to see this
>>>> with any other rc keymap.
>>>
>>> So CEC creates an RC device with a keymap (cec keymap, of course) and then
>>> the keymap needs to be loaded. We certainly don't want all keymaps as
>>> builtins, that would be a waste.
>>>
>>> The cec keymap is scanned once to build a map from cec codes to linux
>>> keycodes; making it builtin is not ideal, and makes the build system a
>>> bit messy.
>>>
>>> I don't think we can load the keymap later, user space may start remapping
>>> the keymap from udev.
>>>
>>> Possibly we could create the cec or rc device later but this could be a bit
>>> messy.
>>>
>>> Could CEC specify:
>>>
>>> #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
>>> MODULE_SOFTDEP("rc-cec")
>>> #endif
>>
>> That would need to be:
>>
>> MODULE_SOFTDEP("pre: rc-cec")
>>
>> I see that the drm_kms_helper and i915 drivers both depend on the cec module
>> already,
>> so yes if that module will request for rc-cec to be loaded before it is
>> loaded
>> (and thus before i915 is loaded) then that should work around this.
>>
>> Assuming the user is using a module-loader which honors the softdep...
>>
>> Also this assumes that rc_map_get is smart enough to not call
>> request_module()
>> if the module is already loaded, is that the case ?
>
> Yes, see rc_map_get().
I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
rc_main
is a module as well.
It was a good idea, though :-)
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
Hi Hans, On 17/02/2021 13:24, Hans de Goede wrote: > > > Hi Hans, > > Fedora has a (opt-in) system to automatically collect backtraces from software > crashing on users systems. > > This includes collecting kernel backtraces (including once triggered by > WARN macros) while looking a the top 10 of the most reported backtrace during > the > last 2 weeks report from ABRT: https://retrace.fedoraproject.org/faf/problems/ > > I noticed the following backtrace: > https://retrace.fedoraproject.org/faf/problems/8150/ > which has been reported 17 times by Fedora users who have opted-in during > the > last 14 days. > > The issue here is that cec_register_adapter ends up calling request_module() > from an async context, triggering this warn in kernel/kmod.c > __request_module(): > > /* > * We don't allow synchronous module loading from async. Module > * init may invoke async_synchronize_full() which will end up > * waiting for this task which already is waiting for the module > * loading to complete, leading to a deadlock. > */ > WARN_ON_ONCE(wait && current_is_async()); > > The call-path leading to this goes like this: > > ? kvasprintf+0x6d/0xa0 > ? kobject_set_name_vargs+0x6f/0x90 > rc_map_get+0x30/0x60 It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko. I've added Sean Young to the CC list. Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is set? I think this issue is very specific to CEC. I would not expect to see this with any other rc keymap. Regards, Hans > rc_register_device+0x108/0x510 > cec_register_adapter+0x5c/0x280 [cec] > drm_dp_cec_set_edid+0x11e/0x178 [drm_kms_helper] > intel_dp_set_edid+0x8d/0xc0 [i915] > intel_dp_detect+0x188/0x5c0 [i915] > drm_helper_probe_single_connector_modes+0xc2/0x6d0 [drm_kms_helper] > ? krealloc+0x7b/0xb0 > drm_client_modeset_probe+0x25b/0x1320 [drm] > ? kfree+0x1ea/0x200 > ? sched_clock+0x5/0x10 > ? sched_clock_cpu+0xc/0xa0 > __drm_fb_helper_initial_config_and_unlock+0x37/0x470 [drm_kms_helper] > ? _cond_resched+0x16/0x40 > intel_fbdev_initial_config+0x14/0x30 [i915] > async_run_entry_fn+0x39/0x160 > > So 2 questions: > > 1. Can we get this fixed please ? >Related to this, what happens if we make this an async modprobe >(when running from async context) is that a problem, or is it fine >if the rc_map module gets loaded later ? > > 2. If the answer to 1. is "tricky", "maybe" or some such then can we > look into a workaround here ? E.g. do we know in advance which module > is going to be requested (1), or does that depend on the EDID data ? > > Regards, > > Hans > > > 1) And can we thus do tricks with a softdep on it ? > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support
On 01/09/2020 08:22, Sam McNally wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org:
> - rebased
> - removed polling-related changes
> - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> ]
> Signed-off-by: Sam McNally
> ---
>
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 22 ++-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
> include/drm/drm_dp_helper.h | 6 +++--
> 5 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 461fa4da0a34..6e7075893ec9 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
> drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
> drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> - &aconnector->base);
> + &aconnector->base, false);
>
> if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
> return;
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index 3ab2609f9ec7..04ab7b88055c 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap) {
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> - /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> goto unlock;
> }
> /*
> @@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> cec_delete_adapter(aux->cec.adap);
> aux->cec.adap = NULL;
> - } else {
> - /*
> - * Update the phys addr for the new CEC adapter. When called
> - * from drm_dp_cec_register_connector() edid == NULL, so in
> - * that case the phys addr is just invalidated.
> - */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> }
> unlock:
> + /*
> + * Update the phys addr for the new CEC adapter. When called
> + * from drm_dp_cec_register_connector() edid == NULL, so in
> + * that case the phys addr is just invalidated.
> + */
The comment is no longer in sync with the code: if EDID == NULL, then
nothing is done due to the edid check in the 'if' below.
> + if (aux->cec.adap && edid) {
I think this should just be: if (aux->cec.adap)
Also, the {} aren't necessary here.
> + cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + }
> mutex_unlock(&aux->cec.lock);
> }
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
Frankly, the changes to this function should be dropped completely, from
what I can see they are not necessary. It was done in my original patch
because of the way I handled mst, but you did it differently (and I think
better), so these changes are no longer needed.
I know I am actually commenting on my old patch, but that patch was from a
work-in-progress git branch and was never meant as a 'proper' patch.
However, what complicates matters is that after digging a bit more I discovered
that commit 732300154980 ("drm: Do not call drm_dp_cec_set_edid() while
registering
DP connectors") changed drm_dp_cec_register_connector() so that it no longer
calls drm_dp_cec_set_edid(), but the comments there and in this function were
not updated. It would be nice if you can add a patch fixing these outdated
comments.
Regardless of that change in commit 732300154980, the edid pointer can still be
NULL and the existing behavior should be kept (i.e. create a CEC device, but
with
an invalid physical address since there is no EDID for some reason).
Regards,
Hans
> @@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edi
Re: [Intel-gfx] [PATCH v3 10/12] media: constify fb ops across all drivers
On 12/3/19 5:38 PM, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can start
> making the ops const as well.
>
> Remove the redundant fbops assignments while at it.
>
> v2:
> - actually add const in vivid
> - fix typo (Christophe de Dinechin)
>
> Cc: Hans Verkuil
> Cc: Andy Walls
> Cc: linux-me...@vger.kernel.org
> Cc: ivtv-de...@ivtvdriver.org
> Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
Acked-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/media/pci/ivtv/ivtvfb.c | 3 +--
> drivers/media/platform/vivid/vivid-osd.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
> index 95a56cce9b65..f2922b554b09 100644
> --- a/drivers/media/pci/ivtv/ivtvfb.c
> +++ b/drivers/media/pci/ivtv/ivtvfb.c
> @@ -925,7 +925,7 @@ static int ivtvfb_blank(int blank_mode, struct fb_info
> *info)
> return 0;
> }
>
> -static struct fb_ops ivtvfb_ops = {
> +static const struct fb_ops ivtvfb_ops = {
> .owner = THIS_MODULE,
> .fb_write = ivtvfb_write,
> .fb_check_var = ivtvfb_check_var,
> @@ -1049,7 +1049,6 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
>
> oi->ivtvfb_info.node = -1;
> oi->ivtvfb_info.flags = FBINFO_FLAG_DEFAULT;
> - oi->ivtvfb_info.fbops = &ivtvfb_ops;
> oi->ivtvfb_info.par = itv;
> oi->ivtvfb_info.var = oi->ivtvfb_defined;
> oi->ivtvfb_info.fix = oi->ivtvfb_fix;
> diff --git a/drivers/media/platform/vivid/vivid-osd.c
> b/drivers/media/platform/vivid/vivid-osd.c
> index f2e789bdf4a6..fbaec8acc161 100644
> --- a/drivers/media/platform/vivid/vivid-osd.c
> +++ b/drivers/media/platform/vivid/vivid-osd.c
> @@ -244,7 +244,7 @@ static int vivid_fb_blank(int blank_mode, struct fb_info
> *info)
> return 0;
> }
>
> -static struct fb_ops vivid_fb_ops = {
> +static const struct fb_ops vivid_fb_ops = {
> .owner = THIS_MODULE,
> .fb_check_var = vivid_fb_check_var,
> .fb_set_par = vivid_fb_set_par,
> @@ -311,7 +311,6 @@ static int vivid_fb_init_vidmode(struct vivid_dev *dev)
>
> dev->fb_info.node = -1;
> dev->fb_info.flags = FBINFO_FLAG_DEFAULT;
> - dev->fb_info.fbops = &vivid_fb_ops;
> dev->fb_info.par = dev;
> dev->fb_info.var = dev->fb_defined;
> dev->fb_info.fix = dev->fb_fix;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support
On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8
> 3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf
> *dbuf)
> vb2_dc_put(dbuf->priv);
> }
>
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_dc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
> static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
> .detach = vb2_dc_dmabuf_ops_detach,
> .map_dma_buf = vb2_dc_dmabuf_ops_map,
> .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> - .map = vb2_dc_dmabuf_ops_kmap,
> .vmap = vb2_dc_dmabuf_ops_vmap,
> .mmap = vb2_dc_dmabuf_ops_mmap,
> .release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf
> *dbuf)
> vb2_dma_sg_put(dbuf->priv);
> }
>
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
> static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
> .detach = vb2_dma_sg_dmabuf_ops_detach,
> .map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
> .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> - .map = vb2_dma_sg_dmabuf_ops_kmap,
> .vmap = vb2_dma_sg_dmabuf_ops_vmap,
> .mmap = vb2_dma_sg_dmabuf_ops_mmap,
> .release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct
> dma_buf *dbuf)
> vb2_vmalloc_put(dbuf->priv);
> }
>
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
> static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
> .detach = vb2_vmalloc_dmabuf_ops_detach,
> .map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
> .unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> - .map = vb2_vmalloc_dmabuf_ops_kmap,
> .vmap = vb2_vmalloc_dmabuf_ops_vmap,
> .mmap = vb2_vmalloc_dmabuf_ops_mmap,
> .release = vb2_vmalloc_dmabuf_ops_release,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 2/9] drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
On 8/22/19 10:03 AM, Hans Verkuil wrote:
> Ville or Rodrigo,
>
> Can one of you either merge this patch or Ack it so that I can merge this?
Ping!
Regards,
Hans
>
> Thank you!
>
> Regards,
>
> Hans
>
> On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
>> Use the new cec_notifier_conn_(un)register() functions to
>> (un)register the notifier for the HDMI connector, and fill in
>> the cec_connector_info.
>>
>> Signed-off-by: Dariusz Marcinkiewicz
>> Signed-off-by: Hans Verkuil
>> Tested-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> index b1ca8e5bdb56d..9fcf2c58c29c5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> @@ -2752,8 +2752,9 @@ intel_hdmi_connector_register(struct drm_connector
>> *connector)
>>
>> static void intel_hdmi_destroy(struct drm_connector *connector)
>> {
>> -if (intel_attached_hdmi(connector)->cec_notifier)
>> -cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
>> +struct cec_notifier *n = intel_attached_hdmi(connector)->cec_notifier;
>> +
>> +cec_notifier_conn_unregister(n);
>>
>> intel_connector_destroy(connector);
>> }
>> @@ -3068,6 +3069,7 @@ void intel_hdmi_init_connector(struct
>> intel_digital_port *intel_dig_port,
>> struct drm_device *dev = intel_encoder->base.dev;
>> struct drm_i915_private *dev_priv = to_i915(dev);
>> enum port port = intel_encoder->port;
>> +struct cec_connector_info conn_info;
>>
>> DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
>>port_name(port));
>> @@ -3120,8 +3122,11 @@ void intel_hdmi_init_connector(struct
>> intel_digital_port *intel_dig_port,
>> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>> }
>>
>> -intel_hdmi->cec_notifier = cec_notifier_get_conn(dev->dev,
>> - port_identifier(port));
>> +cec_fill_conn_info_from_drm(&conn_info, connector);
>> +
>> +intel_hdmi->cec_notifier =
>> +cec_notifier_conn_register(dev->dev, port_identifier(port),
>> + &conn_info);
>> if (!intel_hdmi->cec_notifier)
>> DRM_DEBUG_KMS("CEC notifier get failed\n");
>> }
>>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.
On 8/22/19 10:08 AM, Hans Verkuil wrote:
> Alex, Ville/Rodrigo, Ben,
>
> Can you (hopefully) Ack this patch so that I can merge it?
Ping!
Regards,
Hans
>
> Thank you!
>
> Hans
>
> On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
>> Pass the connector info to the CEC adapter. This makes it possible
>> to associate the CEC adapter with the corresponding drm connector.
>>
>> Signed-off-by: Dariusz Marcinkiewicz
>> Signed-off-by: Hans Verkuil
>> Tested-by: Hans Verkuil
>> ---
>> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
>> drivers/gpu/drm/drm_dp_cec.c | 25 ---
>> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
>> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
>> include/drm/drm_dp_helper.h | 17 ++---
>> 5 files changed, 27 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> index 16218a202b591..5ec14efd4d8cb 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
>> amdgpu_display_manager *dm,
>>
>> drm_dp_aux_register(&aconnector->dm_dp_aux.aux);
>> drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
>> - aconnector->base.name, dm->adev->dev);
>> + &aconnector->base);
>> aconnector->mst_mgr.cbs = &dm_mst_cbs;
>> drm_dp_mst_topology_mgr_init(
>> &aconnector->mst_mgr,
>> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
>> index b15cee85b702b..b457c16c3a8bb 100644
>> --- a/drivers/gpu/drm/drm_dp_cec.c
>> +++ b/drivers/gpu/drm/drm_dp_cec.c
>> @@ -8,7 +8,9 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> +#include
>> #include
>>
>> /*
>> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct
>> work_struct *work)
>> */
>> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
>> {
>> -u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
>> +struct drm_connector *connector = aux->cec.connector;
>> +u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
>> + CEC_CAP_CONNECTOR_INFO;
>> +struct cec_connector_info conn_info;
>> unsigned int num_las = 1;
>> u8 cap;
>>
>> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
>> struct edid *edid)
>>
>> /* Create a new adapter */
>> aux->cec.adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
>> - aux, aux->cec.name, cec_caps,
>> + aux, connector->name, cec_caps,
>> num_las);
>> if (IS_ERR(aux->cec.adap)) {
>> aux->cec.adap = NULL;
>> goto unlock;
>> }
>> -if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
>> +
>> +cec_fill_conn_info_from_drm(&conn_info, connector);
>> +cec_s_conn_info(aux->cec.adap, &conn_info);
>> +
>> +if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
>> cec_delete_adapter(aux->cec.adap);
>> aux->cec.adap = NULL;
>> } else {
>> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
>> /**
>> * drm_dp_cec_register_connector() - register a new connector
>> * @aux: DisplayPort AUX channel
>> - * @name: name of the CEC device
>> - * @parent: parent device
>> + * @connector: drm connector
>> *
>> * A new connector was registered with associated CEC adapter name and
>> * CEC adapter parent device. After registering the name and parent
>> * drm_dp_cec_set_edid() is called to check if the connector supports
>> * CEC and to register a CEC adapter if that is the case.
>> */
>> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
>> - struct device *parent)
>> +void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
>> + struct drm_connector *connector)
>> {
&
Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.
Alex, Ville/Rodrigo, Ben,
Can you (hopefully) Ack this patch so that I can merge it?
Thank you!
Hans
On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 25 ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
> include/drm/drm_dp_helper.h | 17 ++---
> 5 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b591..5ec14efd4d8cb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
> drm_dp_aux_register(&aconnector->dm_dp_aux.aux);
> drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> - aconnector->base.name, dm->adev->dev);
> + &aconnector->base);
> aconnector->mst_mgr.cbs = &dm_mst_cbs;
> drm_dp_mst_topology_mgr_init(
> &aconnector->mst_mgr,
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b15cee85b702b..b457c16c3a8bb 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,7 +8,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> /*
> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct
> work_struct *work)
> */
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> {
> - u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> + struct drm_connector *connector = aux->cec.connector;
> + u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> +CEC_CAP_CONNECTOR_INFO;
> + struct cec_connector_info conn_info;
> unsigned int num_las = 1;
> u8 cap;
>
> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>
> /* Create a new adapter */
> aux->cec.adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
> - aux, aux->cec.name, cec_caps,
> + aux, connector->name, cec_caps,
>num_las);
> if (IS_ERR(aux->cec.adap)) {
> aux->cec.adap = NULL;
> goto unlock;
> }
> - if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
> +
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> + cec_s_conn_info(aux->cec.adap, &conn_info);
> +
> + if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> cec_delete_adapter(aux->cec.adap);
> aux->cec.adap = NULL;
> } else {
> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> /**
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> - * @name: name of the CEC device
> - * @parent: parent device
> + * @connector: drm connector
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> * drm_dp_cec_set_edid() is called to check if the connector supports
> * CEC and to register a CEC adapter if that is the case.
> */
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -struct device *parent)
> +void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> +struct drm_connector *connector)
> {
> WARN_ON(aux->cec.adap);
> if (WARN_ON(!aux->transfer))
> return;
> - aux->cec.name = name;
> - aux->cec.parent = parent;
> + aux->cec.connector = connector;
> INIT_DELAYED_WORK(&aux->cec.unregister_work,
> drm_dp_cec_unregister_work);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 10
Re: [Intel-gfx] [PATCH v7 2/9] drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
Ville or Rodrigo,
Can one of you either merge this patch or Ack it so that I can merge this?
Thank you!
Regards,
Hans
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index b1ca8e5bdb56d..9fcf2c58c29c5 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2752,8 +2752,9 @@ intel_hdmi_connector_register(struct drm_connector
> *connector)
>
> static void intel_hdmi_destroy(struct drm_connector *connector)
> {
> - if (intel_attached_hdmi(connector)->cec_notifier)
> - cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
> + struct cec_notifier *n = intel_attached_hdmi(connector)->cec_notifier;
> +
> + cec_notifier_conn_unregister(n);
>
> intel_connector_destroy(connector);
> }
> @@ -3068,6 +3069,7 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> struct drm_device *dev = intel_encoder->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> enum port port = intel_encoder->port;
> + struct cec_connector_info conn_info;
>
> DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
> port_name(port));
> @@ -3120,8 +3122,11 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
>
> - intel_hdmi->cec_notifier = cec_notifier_get_conn(dev->dev,
> - port_identifier(port));
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> +
> + intel_hdmi->cec_notifier =
> + cec_notifier_conn_register(dev->dev, port_identifier(port),
> +&conn_info);
> if (!intel_hdmi->cec_notifier)
> DRM_DEBUG_KMS("CEC notifier get failed\n");
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API
On 8/19/19 4:48 PM, Neil Armstrong wrote: > Hi Dariusz, Hans, > > I can apply the dw-hdmi patches if necessary. I'd appreciate it if you can do that. Thanks, Hans > > Neil > > On 19/08/2019 11:38, Hans Verkuil wrote: >> Hi all, >> >> The patches in this series can be applied independently from each other. >> >> If you maintain one of these drivers and you want to merge it for v5.4 >> yourself, then please do so and let me know. If you prefer I commit it >> to drm-misc, then please review and (hopefully) Ack the patch. >> >> I would really like to get this in for v5.4 so I can get the userspace >> bits in for v5.4 as well through the media subsystem. >> >> Dariusz, can you post a v7.1 for patch 5/9 fixing the typo? >> >> Thanks! >> >> Hans >> >> On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote: >>> This series updates DRM drivers to use new CEC notifier API. >>> >>> Changes since v6: >>> Made CEC notifiers' registration and de-registration symmetric >>> in tda998x and dw-hdmi drivers. Also, accidentally dropped one >>> patch in v6 (change to drm_dp_cec), brought it back now. >>> Changes since v5: >>> Fixed a warning about a missing comment for a new member of >>> drm_dp_aux_cec struct. Sending to a wider audience, >>> including maintainers of respective drivers. >>> Changes since v4: >>> Addressing review comments. >>> Changes since v3: >>> Updated adapter flags in dw-hdmi-cec. >>> Changes since v2: >>> Include all DRM patches from "cec: improve notifier support, >>> add connector info connector info" series. >>> Changes since v1: >>> Those patches delay creation of notifiers until respective >>> connectors are constructed. It seems that those patches, for a >>> couple of drivers, by adding the delay, introduce a race between >>> notifiers' creation and the IRQs handling threads - at least I >>> don't see anything obvious in there that would explicitly forbid >>> such races to occur. v2 adds a write barrier to make sure IRQ >>> threads see the notifier once it is created (replacing the >>> WRITE_ONCE I put in v1). The best thing to do here, I believe, >>> would be not to have any synchronization and make sure that an IRQ >>> only gets enabled after the notifier is created. >>> Dariusz Marcinkiewicz (9): >>> drm_dp_cec: add connector info support. >>> drm/i915/intel_hdmi: use cec_notifier_conn_(un)register >>> dw-hdmi-cec: use cec_notifier_cec_adap_(un)register >>> tda9950: use cec_notifier_cec_adap_(un)register >>> drm: tda998x: use cec_notifier_conn_(un)register >>> drm: sti: use cec_notifier_conn_(un)register >>> drm: tegra: use cec_notifier_conn_(un)register >>> drm: dw-hdmi: use cec_notifier_conn_(un)register >>> drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register >>> >>> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++--- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +-- >>> drivers/gpu/drm/drm_dp_cec.c | 25 ++ >>> drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++-- >>> drivers/gpu/drm/i2c/tda9950.c | 12 ++--- >>> drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++- >>> drivers/gpu/drm/i915/display/intel_dp.c | 4 +- >>> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 -- >>> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- >>> drivers/gpu/drm/sti/sti_hdmi.c| 19 +--- >>> drivers/gpu/drm/tegra/output.c| 28 --- >>> include/drm/drm_dp_helper.h | 17 --- >>> 13 files changed, 155 insertions(+), 94 deletions(-) >>> >> > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API
On 8/19/19 1:28 PM, Dariusz Marcinkiewicz wrote: > On Mon, Aug 19, 2019 at 11:38 AM Hans Verkuil > wrote: >> >> Hi all, >> > Hi Hans. >> The patches in this series can be applied independently from each other. >> >> If you maintain one of these drivers and you want to merge it for v5.4 >> yourself, then please do so and let me know. If you prefer I commit it >> to drm-misc, then please review and (hopefully) Ack the patch. >> >> I would really like to get this in for v5.4 so I can get the userspace >> bits in for v5.4 as well through the media subsystem. >> >> Dariusz, can you post a v7.1 for patch 5/9 fixing the typo? >> > Done. > > I think it would be good to test v7 changes to dw-hdmi and tda998x on > a real hardware. Hans, do you think you would be able to test those? > > Thank you. > I'll try to do this for dw-hdmi today, but the tda998x testing will have to wait until next week. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API
Hi all, The patches in this series can be applied independently from each other. If you maintain one of these drivers and you want to merge it for v5.4 yourself, then please do so and let me know. If you prefer I commit it to drm-misc, then please review and (hopefully) Ack the patch. I would really like to get this in for v5.4 so I can get the userspace bits in for v5.4 as well through the media subsystem. Dariusz, can you post a v7.1 for patch 5/9 fixing the typo? Thanks! Hans On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote: > This series updates DRM drivers to use new CEC notifier API. > > Changes since v6: > Made CEC notifiers' registration and de-registration symmetric > in tda998x and dw-hdmi drivers. Also, accidentally dropped one > patch in v6 (change to drm_dp_cec), brought it back now. > Changes since v5: > Fixed a warning about a missing comment for a new member of > drm_dp_aux_cec struct. Sending to a wider audience, > including maintainers of respective drivers. > Changes since v4: > Addressing review comments. > Changes since v3: > Updated adapter flags in dw-hdmi-cec. > Changes since v2: > Include all DRM patches from "cec: improve notifier support, > add connector info connector info" series. > Changes since v1: > Those patches delay creation of notifiers until respective > connectors are constructed. It seems that those patches, for a > couple of drivers, by adding the delay, introduce a race between > notifiers' creation and the IRQs handling threads - at least I > don't see anything obvious in there that would explicitly forbid > such races to occur. v2 adds a write barrier to make sure IRQ > threads see the notifier once it is created (replacing the > WRITE_ONCE I put in v1). The best thing to do here, I believe, > would be not to have any synchronization and make sure that an IRQ > only gets enabled after the notifier is created. > Dariusz Marcinkiewicz (9): > drm_dp_cec: add connector info support. > drm/i915/intel_hdmi: use cec_notifier_conn_(un)register > dw-hdmi-cec: use cec_notifier_cec_adap_(un)register > tda9950: use cec_notifier_cec_adap_(un)register > drm: tda998x: use cec_notifier_conn_(un)register > drm: sti: use cec_notifier_conn_(un)register > drm: tegra: use cec_notifier_conn_(un)register > drm: dw-hdmi: use cec_notifier_conn_(un)register > drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++--- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +-- > drivers/gpu/drm/drm_dp_cec.c | 25 ++ > drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++-- > drivers/gpu/drm/i2c/tda9950.c | 12 ++--- > drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++- > drivers/gpu/drm/i915/display/intel_dp.c | 4 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 -- > drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- > drivers/gpu/drm/sti/sti_hdmi.c| 19 +--- > drivers/gpu/drm/tegra/output.c| 28 --- > include/drm/drm_dp_helper.h | 17 --- > 13 files changed, 155 insertions(+), 94 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/41] media/v4l2-core/mm: convert put_page() to put_user_page*()
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Mauro Carvalho Chehab
> Cc: Kees Cook
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Jan Kara
> Cc: Robin Murphy
> Cc: Souptick Joarder
> Cc: Dan Williams
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: John Hubbard
Acked-by: Hans Verkuil
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
> b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index 66a6c6c236a7..d6eeb437ec19 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -349,8 +349,7 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
> BUG_ON(dma->sglen);
>
> if (dma->pages) {
> - for (i = 0; i < dma->nr_pages; i++)
> - put_page(dma->pages[i]);
> + put_user_pages(dma->pages, dma->nr_pages);
> kfree(dma->pages);
> dma->pages = NULL;
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 10/41] media/ivtv: convert put_page() to put_user_page*()
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Andy Walls
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: John Hubbard
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/pci/ivtv/ivtv-udma.c | 14 --
> drivers/media/pci/ivtv/ivtv-yuv.c | 11 +++
> 2 files changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/pci/ivtv/ivtv-udma.c
> b/drivers/media/pci/ivtv/ivtv-udma.c
> index 5f8883031c9c..7c7f33c2412b 100644
> --- a/drivers/media/pci/ivtv/ivtv-udma.c
> +++ b/drivers/media/pci/ivtv/ivtv-udma.c
> @@ -92,7 +92,7 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
> {
> struct ivtv_dma_page_info user_dma;
> struct ivtv_user_dma *dma = &itv->udma;
> - int i, err;
> + int err;
>
> IVTV_DEBUG_DMA("ivtv_udma_setup, dst: 0x%08x\n", (unsigned
> int)ivtv_dest_addr);
>
> @@ -119,8 +119,7 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
> IVTV_DEBUG_WARN("failed to map user pages, returned %d instead
> of %d\n",
> err, user_dma.page_count);
> if (err >= 0) {
> - for (i = 0; i < err; i++)
> - put_page(dma->map[i]);
> + put_user_pages(dma->map, err);
> return -EINVAL;
> }
> return err;
> @@ -130,9 +129,7 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
>
> /* Fill SG List with new values */
> if (ivtv_udma_fill_sg_list(dma, &user_dma, 0) < 0) {
> - for (i = 0; i < dma->page_count; i++) {
> - put_page(dma->map[i]);
> - }
> + put_user_pages(dma->map, dma->page_count);
> dma->page_count = 0;
> return -ENOMEM;
> }
> @@ -153,7 +150,6 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long
> ivtv_dest_addr,
> void ivtv_udma_unmap(struct ivtv *itv)
> {
> struct ivtv_user_dma *dma = &itv->udma;
> - int i;
>
> IVTV_DEBUG_INFO("ivtv_unmap_user_dma\n");
>
> @@ -170,9 +166,7 @@ void ivtv_udma_unmap(struct ivtv *itv)
> ivtv_udma_sync_for_cpu(itv);
>
> /* Release User Pages */
> - for (i = 0; i < dma->page_count; i++) {
> - put_page(dma->map[i]);
> - }
> + put_user_pages(dma->map, dma->page_count);
> dma->page_count = 0;
> }
>
> diff --git a/drivers/media/pci/ivtv/ivtv-yuv.c
> b/drivers/media/pci/ivtv/ivtv-yuv.c
> index cd2fe2d444c0..2c61a11d391d 100644
> --- a/drivers/media/pci/ivtv/ivtv-yuv.c
> +++ b/drivers/media/pci/ivtv/ivtv-yuv.c
> @@ -30,7 +30,6 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, struct
> ivtv_user_dma *dma,
> struct yuv_playback_info *yi = &itv->yuv_info;
> u8 frame = yi->draw_frame;
> struct yuv_frame_info *f = &yi->new_frame_info[frame];
> - int i;
> int y_pages, uv_pages;
> unsigned long y_buffer_offset, uv_buffer_offset;
> int y_decode_height, uv_decode_height, y_size;
> @@ -81,8 +80,7 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, struct
> ivtv_user_dma *dma,
>uv_pages, uv_dma.page_count);
>
> if (uv_pages >= 0) {
> - for (i = 0; i < uv_pages; i++)
> - put_page(dma->map[y_pages + i]);
> + put_user_pages(&dma->map[y_pages], uv_pages);
> rc = -EFAULT;
> } else {
> rc = uv_pages;
> @@ -93,8 +91,7 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, struct
> ivtv_user_dma *dma,
>y_pages, y_dma.page_count);
> }
> if (y_pages >= 0) {
> - for (i = 0; i < y_pages; i++)
> - put_page(dma->map[i]);
> + put_user_pages(dma->map, y_pages);
> /*
>* Inherit the -EFAULT from rc's
>
Re: [Intel-gfx] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x79/0x80
Hi Jani,
On 2/25/19 2:40 PM, Jani Nikula wrote:
On Fri, 22 Feb 2019, Randy Dunlap wrote:
This is 5.0-rc7 on an old Toshiba Portege laptop.
No hdmi or other external video.
Linux dragon.dunlab 5.0.0-rc7mod #3 SMP PREEMPT Wed Feb 20 00:05:17 PST 2019
x86_64 x86_64 x86_64 GNU/Linux
on openSUSE LEAP 15.0 distro.
Full boot log is attached.
On a hunch, caused by 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to
intel_hdmi") referencing the encoder in connector destroy hook. We
should probably move the cec_notifier_put() call in the encoder destroy
hook.
So the intel_encoder_destroy function is/can be called before the
intel_hdmi_destroy function? Sounds odd. I would expect that the
connectors are destroyed before the encoders.
In any case, I am happy to try it in another destroy hook, but I need
advice which hook I should use and how I get to the cec_notifier from
whatever structure pointer I have in that destroy hook.
I tried to figure it out, but I became very confused :-)
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 12/03/2018 12:23 PM, Andrzej Hajda wrote: > On 30.11.2018 15:48, Hans Verkuil wrote: >> On 11/30/18 15:29, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >>>> Hi Ville, >>>> >>>> As Christoph cannot respond till middle next week I can try to respond >>>> in his absence, as I am familiar with the subject. >>>> >>>> On 30.11.2018 14:25, Ville Syrjälä wrote: >>>>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >>>>>> Hi, >>>>>> >>>>>> I am looking for a way to export the color encoding and range selection >>>>>> to user space. I came across those properties and am wondering, why >>>>>> they are meant only for non RGB color encodings. Would it be okay, to >>>>>> modify them and use with RGB formats as well? >>>>> What you trying to do? Input limited range RGB data and expand to full >>>>> range? >>>> >>>> For example. But there are two more general questions, which >>>> surprisingly we have not found answer for. >>>> >>>> 1. What color encoding and range drm should expect on its input RGB >>>> buffers by default? >>> RGB is just RGB. There is no encoding. > > > OK, Now I see I have confused encoding with colorspace, Hans thanks for > the documentation. > > As I understand drm by default should expect sRGB colorspace, also for > Y'CbCr buffers, and currently there are no standard ways to specify > buffer colorspace. > > Looking at current users of drm_plane_create_color_properties for Y'CbCr > buffers it seems default range should be LIMITED. Right. There is support for YCbCr quantization range signaling in HDMI, but that is for all intents and purposes broken in the standard. Don't use it, just output limited range YCbCr. On the other hand, RGB Quantization range signaling should *always* be used if the EDID signals support for it. I believe that's what drm does today already (this certainly works for i915). > > But default encoding is different: mali, armada, nouveau use > DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this > be somehow standardized? According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for everything else. So this is resolution dependent. Although strictly speaking it is only userspace that knows the right encoding, since it depends on the source material. You can have SDTV video encoded with 709, or HDTV encoded with 601. But in the absence of any information, the default rule above is what should be used. > > > What I still do not understand is colorspace conversion(not encoding!) - > between pipeline input (framebuffers) and output (HDMI connector for > example): > > 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost > identical in coverage' (according to wikipedia[1]) no colorspace > conversion is performed at all. That's correct. There is a slight difference between SMPTE170M and sRGB/Rec709, but basically invisible to the naked eye unless you see it side-by-side, and even then it's is hard to detect. However, sRGB uses a different transfer function compared to SMPTE170M and Rec709, and that difference *is* quite visible. Not all hardware (certainly not video capture hardware) is capable of converting between different transfer functions, though. I gather that this is more common for HDMI output hardware. > > 2. It is performed somewhere by HW, just my IP documentation is not > clear about it. > > > Another thing which still bothers me is RGB range in case of HDMI - > CEA-861 expects than on CEA modes limited RGB range should be sent, but > the pipeline on the particular hardware I have do not perform any > conversion of input buffers. So only limited range RGB buffers are > displayed correctly. In such case property describing plane with limited > RGB would be useful. Are you sure? Usually the same block that does YCbCr encoding conversion (601 to 709 or vice versa), also deals with limited/full range conversion. It is typically a 3x3 matrix + a vector adding the needed offsets. It is dead cheap to implement in hardware, so it would be very unusual if there is no support for this. > > > [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities > > >> It's assumed to be full range >>> because no one really uses anything else. >> For simple desktop usage that's true. When dealing with video inputs, >> this becomes much more complicated. > > > As I said earlier there are cases where output stream should be limit
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 11/30/18 16:16, Ville Syrjälä wrote: > On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote: >> On 11/30/18 15:29, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >>>> Hi Ville, >>>> >>>> As Christoph cannot respond till middle next week I can try to respond >>>> in his absence, as I am familiar with the subject. >>>> >>>> On 30.11.2018 14:25, Ville Syrjälä wrote: >>>>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >>>>>> Hi, >>>>>> >>>>>> I am looking for a way to export the color encoding and range selection >>>>>> to user space. I came across those properties and am wondering, why >>>>>> they are meant only for non RGB color encodings. Would it be okay, to >>>>>> modify them and use with RGB formats as well? >>>>> What you trying to do? Input limited range RGB data and expand to full >>>>> range? >>>> >>>> >>>> For example. But there are two more general questions, which >>>> surprisingly we have not found answer for. >>>> >>>> 1. What color encoding and range drm should expect on its input RGB >>>> buffers by default? >>> >>> RGB is just RGB. There is no encoding. It's assumed to be full range >>> because no one really uses anything else. >> >> For simple desktop usage that's true. When dealing with video inputs, >> this becomes much more complicated. >> >>> >>>> >>>> 2. How userspace should inform drm that given buffer has specified >>>> non-default color encoding and range? >>>> >>>> >>>> Hopefully this patch introduces such properties but only for YCbCr >>>> formats, the question is what should be the best way to expand it to RGB >>>> formats: >>>> >>>> A. Add another enums: DRM_COLOR_RGB_BT601 and friends. >>> >>> BT.601 specifies how to encoder RGB data as YCbCr. So without >>> YCbCr BT.601 does not mean anything. Well, the standard does >>> contain other things as well I suppose, but for the purposes >>> of the color encoding prop only that one part is relevant. >> >> Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601. >> This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed >> only defined for Y'CbCr. But it is often (ab)used as an alias for >> the SMPTE170M colorspace (used by SDTV). >> >> V4L2 has the following defines for colorspaces, transfer functions, >> Y'CbCr (and HSV) encodings and quantization ranges: >> >> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html > > Yeah, we're going to be introducing other properties to control > colorspace and transfer function in kms as well. Actually some > patches towards that have been floated a few times already. > Great. Let's try to keep drm and V4L2 in sync for this. It should be possible to convert from one to the other without having to do weird things. I'll try to pay attention to these patches, but just ping me if you want me to take a look at something. I put a lot of effort into the V4L2 colorspace documentation, trying to put all the information in one place, esp. all the formulas. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 11/30/18 15:20, Andrzej Hajda wrote:
> Hi Ville,
>
> As Christoph cannot respond till middle next week I can try to respond
> in his absence, as I am familiar with the subject.
>
> On 30.11.2018 14:25, Ville Syrjälä wrote:
>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote:
>>> Hi,
>>>
>>> I am looking for a way to export the color encoding and range selection
>>> to user space. I came across those properties and am wondering, why
>>> they are meant only for non RGB color encodings. Would it be okay, to
>>> modify them and use with RGB formats as well?
>> What you trying to do? Input limited range RGB data and expand to full
>> range?
>
>
> For example. But there are two more general questions, which
> surprisingly we have not found answer for.
>
> 1. What color encoding and range drm should expect on its input RGB
> buffers by default?
While I am not a drm expert, I am pretty certain it always expects
full range RGB.
There is a real use-case for being able to give drm limited range RGB:
if the image was filled from an HDMI receiver and that receiver got
limited range RGB. That said, most (but not all) receivers can expand
it to full range before writing to memory.
> 2. How userspace should inform drm that given buffer has specified
> non-default color encoding and range?
>
>
> Hopefully this patch introduces such properties but only for YCbCr
> formats, the question is what should be the best way to expand it to RGB
> formats:
>
> A. Add another enums: DRM_COLOR_RGB_BT601 and friends.
>
> B. Reuse current enums, but remove format information from them:
> DRM_COLOR_YCBCR_BT601 => DRM_COLOR_BT601.
The colorspace (BT601, REC709, BT2020) is independent of the quantization
range (full/limited) and of the color encoding (YCbCr, RGB). There is also
the transfer function, another independent setting.
More background info is here:
https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces.html
If all you use is a desktop, then it is all simple: full range sRGB. But if
you start mixing video captured from an HDMI receiver, then it can become
much more complex.
Regards,
Hans
>
>
> Regards
>
> Andrzej
>
>>
>>> Regards,
>>> Chris
>>>
>>>
>>> On 02/19/2018 09:28 PM, Ville Syrjala wrote:
>>>> From: Jyri Sarha
>>>>
>>>> Add a standard optional properties to support different non RGB color
>>>> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
>>>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
>>>> the value ranges within the selected color encoding. The properties
>>>> are stored to drm_plane object to allow different set of supported
>>>> encoding for different planes on the device.
>>>>
>>>> v2: Add/fix kerneldocs, verify bitmasks (danvet)
>>>>
>>>> Cc: Harry Wentland
>>>> Cc: Daniel Vetter
>>>> Cc: Daniel Stone
>>>> Cc: Russell King - ARM Linux
>>>> Cc: Ilia Mirkin
>>>> Cc: Hans Verkuil
>>>> Cc: Uma Shankar
>>>> Cc: Shashank Sharma
>>>> Reviewed-by: Ville Syrjälä
>>>> Signed-off-by: Jyri Sarha
>>>> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks]
>>>> Signed-off-by: Ville Syrjälä
>>>> Reviewed-by: Daniel Vetter
>>>> ---
>>>> drivers/gpu/drm/drm_atomic.c | 8 +++
>>>> drivers/gpu/drm/drm_color_mgmt.c | 103
>>>> +++
>>>> include/drm/drm_color_mgmt.h | 19
>>>> include/drm/drm_plane.h | 32
>>>> 4 files changed, 162 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>>> index 46733d534587..452a0b0bafbc 100644
>>>> --- a/drivers/gpu/drm/drm_atomic.c
>>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>>> @@ -759,6 +759,10 @@ static int drm_atomic_plane_set_property(struct
>>>> drm_plane *plane,
>>>>state->rotation = val;
>>>>} else if (property == plane->zpos_property) {
>>>>state->zpos = val;
>>>> + } else if (property == plane->color_encoding_property) {
>>>> + state->color_encoding = val;
>>>> + } else if (property == plane->color_range_property) {
>>>> + state->color_range = val;
>>>>} else if (plane->funcs->atomic_set_property) {
>>>>
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 11/30/18 15:29, Ville Syrjälä wrote: > On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >> Hi Ville, >> >> As Christoph cannot respond till middle next week I can try to respond >> in his absence, as I am familiar with the subject. >> >> On 30.11.2018 14:25, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >>>> Hi, >>>> >>>> I am looking for a way to export the color encoding and range selection >>>> to user space. I came across those properties and am wondering, why >>>> they are meant only for non RGB color encodings. Would it be okay, to >>>> modify them and use with RGB formats as well? >>> What you trying to do? Input limited range RGB data and expand to full >>> range? >> >> >> For example. But there are two more general questions, which >> surprisingly we have not found answer for. >> >> 1. What color encoding and range drm should expect on its input RGB >> buffers by default? > > RGB is just RGB. There is no encoding. It's assumed to be full range > because no one really uses anything else. For simple desktop usage that's true. When dealing with video inputs, this becomes much more complicated. > >> >> 2. How userspace should inform drm that given buffer has specified >> non-default color encoding and range? >> >> >> Hopefully this patch introduces such properties but only for YCbCr >> formats, the question is what should be the best way to expand it to RGB >> formats: >> >> A. Add another enums: DRM_COLOR_RGB_BT601 and friends. > > BT.601 specifies how to encoder RGB data as YCbCr. So without > YCbCr BT.601 does not mean anything. Well, the standard does > contain other things as well I suppose, but for the purposes > of the color encoding prop only that one part is relevant. Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601. This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed only defined for Y'CbCr. But it is often (ab)used as an alias for the SMPTE170M colorspace (used by SDTV). V4L2 has the following defines for colorspaces, transfer functions, Y'CbCr (and HSV) encodings and quantization ranges: https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html Missing in this list is the color encoding (RGB vs YCbCr vs HSV) which is set through the pixelformat fourcc. And indeed, we don't have an RGB encoding define since RGB is just RGB :-) Regards, Hans > >> >> B. Reuse current enums, but remove format information from them: >> DRM_COLOR_YCBCR_BT601 => DRM_COLOR_BT601. >> >> >> Regards >> >> Andrzej >> >>> >>>> Regards, >>>> Chris >>>> >>>> >>>> On 02/19/2018 09:28 PM, Ville Syrjala wrote: >>>>> From: Jyri Sarha >>>>> >>>>> Add a standard optional properties to support different non RGB color >>>>> encodings in DRM planes. COLOR_ENCODING select the supported non RGB >>>>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects >>>>> the value ranges within the selected color encoding. The properties >>>>> are stored to drm_plane object to allow different set of supported >>>>> encoding for different planes on the device. >>>>> >>>>> v2: Add/fix kerneldocs, verify bitmasks (danvet) >>>>> >>>>> Cc: Harry Wentland >>>>> Cc: Daniel Vetter >>>>> Cc: Daniel Stone >>>>> Cc: Russell King - ARM Linux >>>>> Cc: Ilia Mirkin >>>>> Cc: Hans Verkuil >>>>> Cc: Uma Shankar >>>>> Cc: Shashank Sharma >>>>> Reviewed-by: Ville Syrjälä >>>>> Signed-off-by: Jyri Sarha >>>>> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks] >>>>> Signed-off-by: Ville Syrjälä >>>>> Reviewed-by: Daniel Vetter >>>>> --- >>>>> drivers/gpu/drm/drm_atomic.c | 8 +++ >>>>> drivers/gpu/drm/drm_color_mgmt.c | 103 >>>>> +++ >>>>> include/drm/drm_color_mgmt.h | 19 >>>>> include/drm/drm_plane.h | 32 >>>>> 4 files changed, 162 insertions(+) >>>>> >>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c >>>>> index 46733d534587..452a0b0bafbc 100644 >>>>> --- a/drivers/gpu/d
Re: [Intel-gfx] [v2 1/2] drm: Add colorspace property
On 11/02/2018 03:29 PM, Jonas Karlman wrote:
On 2018-11-02 15:13, Shankar, Uma wrote:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, November 2, 2018 5:00 PM
To: Maarten Lankhorst
Cc: Shankar, Uma ; dri-de...@lists.freedesktop.org;
intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
Lankhorst, Maarten ; Hans Verkuil
Subject: Re: [Intel-gfx] [v2 1/2] drm: Add colorspace property
On Fri, Nov 02, 2018 at 10:19:10AM +0100, Maarten Lankhorst wrote:
Op 31-10-18 om 13:05 schreef Uma Shankar:
This patch adds a colorspace property enabling userspace to switch
to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 44
+++
include/drm/drm_connector.h | 7 +++
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 24 +
5 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f31..9e1d46b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -721,6 +721,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+ } else if (property == config->colorspace_property) {
+ state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -795,6 +797,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == config->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c index aa18b1d..5ad52a0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,38 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info, };
DRM_ENUM_NAME_FN(drm_get_content_protection_name,
drm_cp_enum_list)
+static const struct drm_prop_enum_list colorspace[] = {
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "601" },
+ { COLORIMETRY_ITU_709, "709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "709" },
2 definitions that share the same name?
All in all, I think the enum strings need to be more descriptive and self-
consistent.
+1
Sure, will modify this.
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "s601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_ADOBE_YCC_601, "adobe601" },
Hans (cc:d) recetly noted that these things aren't called Adobe
anymore in the CTA-861 spec. There is some new name for them, which I now
forget.
EC2 EC1 EC0 Extended Colorimetry
0 1 1 AdobeYCC601
This is the bit format mentioned in CEA861.F while defining the AVI infoframe,
so looks
like they are still keeping it that way. Not sure if its updated as part of any
latest spec
update.
New names is opRGB and opYCC601 according to the notice on the first page of
CTA-861-G [1]
Updated CTA-861-E/F/G can be found at
https://standards.cta.tech/kwspub/published_docs/
[1]
https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf
Correct. The names were updated since Adobe complained to the CTA about
trademark issues. And in all fairness, it makes sense to refer to the
official international standard name instead of a company standard, even
though they are effectively identical.
Basically, just avoid the name 'Adobe' :-)
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/18] video/hdmi: Constify infoframe passed to the pack functions
On 10/01/2018 09:10 PM, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 05:33:32PM +0300, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Let's make the infoframe pack functions usable with a const infoframe
>> structure. This allows us to precompute the infoframe earlier, and still
>> pack it later when we're no longer allowed to modify the structure.
>> So now we end up with a _check()+_pack_only() or _pack() functions
>> depending on whether you want to precompute the infoframes or not.
>> The names aren't great but I was lazy and didn't want to change all the
>> drivers.
>>
>> v2: Deal with exynos churn
>> Actually export the new funcs
>> v3: Fix various documentation fails (Hans)
>
> Hans, any more concerns about this patch?
Acked-by: Hans Verkuil
Regards,
Hans
>
>>
>> Cc: Thierry Reding
>> Cc: Hans Verkuil
>> Cc: linux-me...@vger.kernel.org
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/video/hdmi.c | 425
>> +++
>> include/linux/hdmi.h | 19 ++-
>> 2 files changed, 416 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index 53e7ee2c83fc..08d94ab00467 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe
>> *frame)
>> }
>> EXPORT_SYMBOL(hdmi_avi_infoframe_init);
>>
>> +static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
>> *frame)
>> +{
>> +if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
>> +frame->version != 2 ||
>> +frame->length != HDMI_AVI_INFOFRAME_SIZE)
>> +return -EINVAL;
>> +
>> +if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>> /**
>> - * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
>> + * hdmi_avi_infoframe_check() - check a HDMI AVI infoframe
>> + * @frame: HDMI AVI infoframe
>> + *
>> + * Validates that the infoframe is consistent and updates derived fields
>> + * (eg. length) based on other fields.
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
>> +{
>> +return hdmi_avi_infoframe_check_only(frame);
>> +}
>> +EXPORT_SYMBOL(hdmi_avi_infoframe_check);
>> +
>> +/**
>> + * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary
>> buffer
>> * @frame: HDMI AVI infoframe
>> * @buffer: destination buffer
>> * @size: size of buffer
>> @@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
>> * Returns the number of bytes packed into the binary buffer or a negative
>> * error code on failure.
>> */
>> -ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
>> *buffer,
>> -size_t size)
>> +ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
>> + void *buffer, size_t size)
>> {
>> u8 *ptr = buffer;
>> size_t length;
>> +int ret;
>> +
>> +ret = hdmi_avi_infoframe_check_only(frame);
>> +if (ret)
>> +return ret;
>>
>> length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
>>
>> if (size < length)
>> return -ENOSPC;
>>
>> -if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
>> -return -EINVAL;
>> -
>> memset(buffer, 0, size);
>>
>> ptr[0] = frame->type;
>> @@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct
>> hdmi_avi_infoframe *frame, void *buffer,
>>
>> return length;
>> }
>> +EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
>> +
>> +/**
>> + * hdmi_avi_infoframe_pack() - check a HDMI AVI infoframe,
>> + * and write it to binary buffer
>> + * @frame: HDMI AVI infoframe
>> + * @buffer: destination buffer
>> + * @size: size of buffer
>> + *
>> + * Validates that the infoframe is consistent and updates derived fields
>> + * (eg. length) based on other fields, after which it packs the information
>> + * contained in the @frame structure into a binary representation that
>> + * can be written into the corresponding
Re: [Intel-gfx] [PATCH 1/2] drm: Do not call drm_dp_cec_set_edid() while registering DP connectors
On 09/25/2018 03:16 AM, José Roberto de Souza wrote: drm_dp_cec_register_connector() is called when registering each DP connector in DRM, while sounds a good idea register CEC adapters as earlier as possible, it causes some driver initialization delay trying to do DPCD transactions in disconnected connectors. This change will cause no regressions as drm_dp_cec_set_edid() will still be called in further detection of connected connectors with a valid edid parameter. This change reduced the module load of i915 by average 0.5sec in a machine with just one DP port disconnected while reducing more than 3sec in a machine with 4 DP ports disconnected. Cc: Hans Verkuil Acked-by: Hans Verkuil Thanks, this makes sense. Hans Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/drm_dp_cec.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c index 8a718f85079a..b15cee85b702 100644 --- a/drivers/gpu/drm/drm_dp_cec.c +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -424,8 +424,6 @@ void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name, aux->cec.parent = parent; INIT_DELAYED_WORK(&aux->cec.unregister_work, drm_dp_cec_unregister_work); - - drm_dp_cec_set_edid(aux, NULL); } EXPORT_SYMBOL(drm_dp_cec_register_connector); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On 09/21/18 16:01, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
>> On 09/20/18 20:51, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> We'll be wanting to send more than just infoframes over HDMI. So add an
>>> enum for other packet types.
>>>
>>> TODO: Maybe just include the infoframe types in the packet type enum
>>> and get rid of the infoframe type enum?
>>
>> I think that's better, IMHO. With a comment that the types starting with
>> 0x81 are defined in CTA-861-G.
>>
>> It's really the same byte that is being checked, so having two enums is
>> a bit misleading. The main difference is really which standard defines
>> the packet types.
>
> Right. The only slight annoyance is that we'll get a bunch of warnings
> from the compiler if we don't handle all the enum valus in the switch
> statements. If we want to avoid that I guess I could limit this
> to just the null, gcp and gamut metadata packets initially and try to
> write some actual code for them. Those three are the only ones we
> care about in i915 at the moment.
Note that I don't have a terribly strong opinion on this, so if using
one enum instead of two causes more problems than it is worth, then
that's fine with me as well.
But you asked, and given a choice with all other things being equal,
then one enum has my preference.
Regards,
Hans
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Cc: Thierry Reding
>>> Cc: Hans Verkuil
>>> Cc: linux-me...@vger.kernel.org
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> include/linux/hdmi.h | 15 +++
>>> 1 file changed, 15 insertions(+)
>>>
>>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
>>> index c76b50a48e48..80521d9591a1 100644
>>> --- a/include/linux/hdmi.h
>>> +++ b/include/linux/hdmi.h
>>> @@ -27,6 +27,21 @@
>>> #include
>>> #include
>>>
>>> +enum hdmi_packet_type {
>>> + HDMI_PACKET_TYPE_NULL = 0x00,
>>> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
>>> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
>>> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
>>> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
>>> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
>>> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
>>> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
>>> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
>>> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
>>> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
>>> + /* + enum hdmi_infoframe_type */
>>> +};
>>> +
>>> enum hdmi_infoframe_type {
>>> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
>>> HDMI_INFOFRAME_TYPE_AVI = 0x82,
>>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting to send more than just infoframes over HDMI. So add an
> enum for other packet types.
>
> TODO: Maybe just include the infoframe types in the packet type enum
> and get rid of the infoframe type enum?
I think that's better, IMHO. With a comment that the types starting with
0x81 are defined in CTA-861-G.
It's really the same byte that is being checked, so having two enums is
a bit misleading. The main difference is really which standard defines
the packet types.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> include/linux/hdmi.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index c76b50a48e48..80521d9591a1 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -27,6 +27,21 @@
> #include
> #include
>
> +enum hdmi_packet_type {
> + HDMI_PACKET_TYPE_NULL = 0x00,
> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> + /* + enum hdmi_infoframe_type */
> +};
> +
> enum hdmi_infoframe_type {
> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> HDMI_INFOFRAME_TYPE_AVI = 0x82,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the NTSC VBI infoframe.
>
> I decided against parsing the PES_data_field and just leave
> it as an opaque blob, just dumping it out as hex in the log.
>
> Blindly typed from the spec, and totally untested.
Do we have any driver that uses this? I would prefer to wait until someone
actually need this.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 208
> +++
> include/linux/hdmi.h | 18 +
> 2 files changed, 226 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 3d24c7746c51..3c320d69fa0a 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
> hdmi_mpeg_source_infoframe *frame
> }
> EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
>
> +/**
> + * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
> + * @frame: HDMI NTSC VBI infoframe
> + * @pes_data_field: ANSI/SCTE 127 PES_data_field
> + * @length: ANSI/SCTE 127 PES_data_field length
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
> + const void *pes_data_field,
> + size_t length)
> +{
> + if (length < 1 || length > 27)
> + return -EINVAL;
> +
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
> + frame->version = 1;
> + frame->length = length;
> +
> + memcpy(frame->pes_data_field, pes_data_field, length);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
> +
> +static int hdmi_ntsc_vbi_infoframe_check_only(const struct
> hdmi_ntsc_vbi_infoframe *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
> + frame->version != 1 ||
> + frame->length < 1 || frame->length > 27)
> + return -EINVAL;
> +
> + if (frame->pes_data_field[0] != 0x99)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI
> infoframe
> + * @frame: HDMI NTSC VBI infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
> +{
> + return hdmi_ntsc_vbi_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
> binary buffer
> + * @frame: HDMI NTSC VBI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct
> hdmi_ntsc_vbi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> + int ret;
> +
> + ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
> + if (ret)
> + return ret;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* start infoframe payload */
> + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> +
> + memcpy(ptr, frame->pes_data_field, frame->length);
> +
> + hdmi_infoframe_set_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_pack() - Check and check a HDMI NTSC VBI
> infoframe,
> + * and write it to binary buffer
> + * @frame: H
Re: [Intel-gfx] [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the MPEG source infoframe.
>
> Blindly typed from the spec, and totally untested.
I'm not sure this patch should be added at all. The CTA-861-G spec (section 6.7)
says that the implementation of this infoframe is not recommended due to
unresolved
issues.
I don't think I've ever seen it either.
It obviously doesn't hurt to have this code, but I prefer to wait until there
are devices that actively set/use this infoframe.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 229
> +++
> include/linux/hdmi.h | 27 ++
> 2 files changed, 256 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 9507f668a569..3d24c7746c51 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
> hdmi_vendor_any_infoframe *frame,
> return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
> }
>
> +/**
> + * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source
> infoframe
> + * @frame: HDMI MPEG Source infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
> + frame->version = 1;
> + frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
> +
> +static int hdmi_mpeg_source_infoframe_check_only(const struct
> hdmi_mpeg_source_infoframe *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
> + frame->version != 1 ||
> + frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_mpeg_source_infoframe_check() - Check and check a HDMI MPEG Source
> infoframe
> + * @frame: HDMI MPEG Source infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe
> *frame)
> +{
> + return hdmi_mpeg_source_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
> +
> +/**
> + * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source infoframe
> to binary buffer
> + * @frame: HDMI MPEG Source infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
> hdmi_mpeg_source_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> + int ret;
> +
> + ret = hdmi_mpeg_source_infoframe_check_only(frame);
> + if (ret)
> + return ret;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* start infoframe payload */
> + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> +
> + ptr[0] = frame->mpeg_bit_rate >> 0;
> + ptr[1] = frame->mpeg_bit_rate >> 8;
> + ptr[2] = frame->mpeg_bit_rate >> 16;
> + ptr[3] = frame->mpeg_bit_rate >> 24;
> + ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
> +
> + hdmi_infoframe_set_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
> +
> +/**
> + * hdmi_mpeg_source_infoframe_pack() - Check and check a HDMI MPEG Source
> infoframe,
> + * and write it to b
Re: [Intel-gfx] [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make the infoframe pack functions usable with a const infoframe
> structure. This allows us to precompute the infoframe earlier, and still
> pack it later when we're no longer allowed to modify the structure.
> So now we end up with a _check()+_pack_only() or _pack() functions
> depending on whether you want to precompute the infoframes or not.
> The names aren't greate but I was lazy and didn't want to change all the
greate -> great
> drivers.
>
> v2: Deal with exynos churn
> Actually export the new funcs
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 425
> +++
> include/linux/hdmi.h | 19 ++-
> 2 files changed, 416 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 53e7ee2c83fc..9507f668a569 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe
> *frame)
> }
> EXPORT_SYMBOL(hdmi_avi_infoframe_init);
>
> +static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
> *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
> + frame->version != 2 ||
> + frame->length != HDMI_AVI_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /**
> - * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
> + * hdmi_avi_infoframe_check() - Check and check a HDMI AVI infoframe
"Check and check"? This is repeated elsewhere as well (clearly copy-and-paste).
> + * @frame: HDMI AVI infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
> +{
> + return hdmi_avi_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_avi_infoframe_check);
> +
> +/**
> + * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary buffer
> * @frame: HDMI AVI infoframe
> * @buffer: destination buffer
> * @size: size of buffer
> @@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> * Returns the number of bytes packed into the binary buffer or a negative
> * error code on failure.
> */
> -ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
> *buffer,
> - size_t size)
> +ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
> + void *buffer, size_t size)
> {
> u8 *ptr = buffer;
> size_t length;
> + int ret;
> +
> + ret = hdmi_avi_infoframe_check_only(frame);
> + if (ret)
> + return ret;
>
> length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
>
> if (size < length)
> return -ENOSPC;
>
> - if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> - return -EINVAL;
> -
> memset(buffer, 0, size);
>
> ptr[0] = frame->type;
> @@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct
> hdmi_avi_infoframe *frame, void *buffer,
>
> return length;
> }
> +EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
> +
> +/**
> + * hdmi_avi_infoframe_pack() - Check and check a HDMI AVI infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI AVI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
which packs -> which it packs
Ditto elsewhere.
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
Also -> This function also
Ditto elsewhere.
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + int ret;
> +
> + ret = hdmi_avi_
Re: [Intel-gfx] [PATCH 01/18] video/hdmi: Constify 'buffer' to the unpack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The unpack functions just read from the passed in buffer,
> so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 23 ---
> include/linux/hdmi.h | 3 ++-
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 38716eb50408..65b915ea4936 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -31,7 +31,7 @@
>
> #define hdmi_log(fmt, ...) dev_printk(level, dev, fmt, ##__VA_ARGS__)
>
> -static u8 hdmi_infoframe_checksum(u8 *ptr, size_t size)
> +static u8 hdmi_infoframe_checksum(const u8 *ptr, size_t size)
> {
> u8 csum = 0;
> size_t i;
> @@ -1016,9 +1016,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
> @@ -1079,9 +1079,9 @@ static int hdmi_avi_infoframe_unpack(struct
> hdmi_avi_infoframe *frame,
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_SPD ||
> @@ -1117,9 +1117,9 @@ static int hdmi_spd_infoframe_unpack(struct
> hdmi_spd_infoframe *frame,
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame,
> -void *buffer)
> +const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AUDIO ||
> @@ -1163,9 +1163,9 @@ static int hdmi_audio_infoframe_unpack(struct
> hdmi_audio_infoframe *frame,
> */
> static int
> hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> size_t length;
> int ret;
> u8 hdmi_video_format;
> @@ -1234,10 +1234,11 @@ hdmi_vendor_any_infoframe_unpack(union
> hdmi_vendor_any_infoframe *frame,
> *
> * Returns 0 on success or a negative error code on failure.
> */
> -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
> +int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> + const void *buffer)
> {
> int ret;
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
>
> switch (ptr[0]) {
> case HDMI_INFOFRAME_TYPE_AVI:
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index d271ff23984f..d3816170c062 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -332,7 +332,8 @@ union hdmi_infoframe {
>
> ssize_t
> hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size);
> -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer);
> +int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> + const void *buffer);
> void hdmi_infoframe_log(const char *level, struct device *dev,
> union hdmi_infoframe *frame);
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/18] video/hdmi: Pass buffer size to infoframe unpack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make sure the infoframe unpack functions don't end up examining
> stack garbage or oopsing, let's pass in the size of the buffer.
>
> v2: Convert tda1997x.c as well (kbuild test robot)
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/media/i2c/adv7511.c | 2 +-
> drivers/media/i2c/adv7604.c | 2 +-
> drivers/media/i2c/adv7842.c | 2 +-
> drivers/media/i2c/tc358743.c | 2 +-
> drivers/media/i2c/tda1997x.c | 4 ++--
> drivers/video/hdmi.c | 51
>
> include/linux/hdmi.h | 2 +-
> 7 files changed, 44 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
> index 55c2ea0720d9..b85b181bbb6c 100644
> --- a/drivers/media/i2c/adv7511.c
> +++ b/drivers/media/i2c/adv7511.c
> @@ -550,7 +550,7 @@ static void log_infoframe(struct v4l2_subdev *sd, const
> struct adv7511_cfg_read_
> buffer[3] = 0;
> buffer[3] = hdmi_infoframe_checksum(buffer, len + 4);
>
> - if (hdmi_infoframe_unpack(&frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 668be2bca57a..2e7a28dbad4e 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -2418,7 +2418,7 @@ static int adv76xx_read_infoframe(struct v4l2_subdev
> *sd, int index,
> buffer[i + 3] = infoframe_read(sd,
> adv76xx_cri[index].payload_addr + i);
>
> - if (hdmi_infoframe_unpack(frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
>adv76xx_cri[index].desc);
> return -ENOENT;
> diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
> index 4f8fbdd00e35..2cfd03f929b2 100644
> --- a/drivers/media/i2c/adv7842.c
> +++ b/drivers/media/i2c/adv7842.c
> @@ -2563,7 +2563,7 @@ static void log_infoframe(struct v4l2_subdev *sd,
> struct adv7842_cfg_read_infofr
> for (i = 0; i < len; i++)
> buffer[i + 3] = infoframe_read(sd, cri->payload_addr + i);
>
> - if (hdmi_infoframe_unpack(&frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index 44c41933415a..519bf92508d5 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -444,7 +444,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
>
> i2c_rd(sd, PK_AVI_0HEAD, buffer, HDMI_INFOFRAME_SIZE(AVI));
>
> - if (hdmi_infoframe_unpack(&frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of AVI infoframe failed\n", __func__);
> return;
> }
> diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
> index d114ac5243ec..195a1fc74ee8 100644
> --- a/drivers/media/i2c/tda1997x.c
> +++ b/drivers/media/i2c/tda1997x.c
> @@ -1253,7 +1253,7 @@ tda1997x_parse_infoframe(struct tda1997x_state *state,
> u16 addr)
>
> /* read data */
> len = io_readn(sd, addr, sizeof(buffer), buffer);
> - err = hdmi_infoframe_unpack(&frame, buffer);
> + err = hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer));
> if (err) {
> v4l_err(state->client,
> "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
> @@ -1928,7 +1928,7 @@ static int tda1997x_log_infoframe(struct v4l2_subdev
> *sd, int addr)
> /* read data */
> len = io_readn(sd, addr, sizeof(buffer), buffer);
> v4l2_dbg(1, debug, sd, "infoframe: addr=%d len=%d\n", addr, len);
> - err = hdmi_infoframe_unpack(&frame, buffer);
> + err = hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer));
> if (err) {
> v4l_err(state->client,
> "failed parsing %d byte infoframe: 0x%0
Re: [Intel-gfx] [PATCH 03/18] video/hdmi: Constify infoframe passed to the log functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The log functions don't modify the passed in infoframe so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 22 +++---
> include/linux/hdmi.h | 2 +-
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b5d491014b0b..53e7ee2c83fc 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -471,7 +471,7 @@ static const char *hdmi_infoframe_type_get_name(enum
> hdmi_infoframe_type type)
>
> static void hdmi_infoframe_log_header(const char *level,
> struct device *dev,
> - struct hdmi_any_infoframe *frame)
> + const struct hdmi_any_infoframe *frame)
> {
> hdmi_log("HDMI infoframe: %s, version %u, length %u\n",
> hdmi_infoframe_type_get_name(frame->type),
> @@ -673,10 +673,10 @@ hdmi_content_type_get_name(enum hdmi_content_type
> content_type)
> */
> static void hdmi_avi_infoframe_log(const char *level,
> struct device *dev,
> -struct hdmi_avi_infoframe *frame)
> +const struct hdmi_avi_infoframe *frame)
> {
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> hdmi_log("colorspace: %s\n",
> hdmi_colorspace_get_name(frame->colorspace));
> @@ -750,12 +750,12 @@ static const char *hdmi_spd_sdi_get_name(enum
> hdmi_spd_sdi sdi)
> */
> static void hdmi_spd_infoframe_log(const char *level,
> struct device *dev,
> -struct hdmi_spd_infoframe *frame)
> +const struct hdmi_spd_infoframe *frame)
> {
> u8 buf[17];
>
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> memset(buf, 0, sizeof(buf));
>
> @@ -886,10 +886,10 @@ hdmi_audio_coding_type_ext_get_name(enum
> hdmi_audio_coding_type_ext ctx)
> */
> static void hdmi_audio_infoframe_log(const char *level,
>struct device *dev,
> - struct hdmi_audio_infoframe *frame)
> + const struct hdmi_audio_infoframe *frame)
> {
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> if (frame->channels)
> hdmi_log("channels: %u\n", frame->channels - 1);
> @@ -949,12 +949,12 @@ hdmi_3d_structure_get_name(enum hdmi_3d_structure
> s3d_struct)
> static void
> hdmi_vendor_any_infoframe_log(const char *level,
> struct device *dev,
> - union hdmi_vendor_any_infoframe *frame)
> + const union hdmi_vendor_any_infoframe *frame)
> {
> - struct hdmi_vendor_infoframe *hvf = &frame->hdmi;
> + const struct hdmi_vendor_infoframe *hvf = &frame->hdmi;
>
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> if (frame->any.oui != HDMI_IEEE_OUI) {
> hdmi_log("not a HDMI vendor infoframe\n");
> @@ -984,7 +984,7 @@ hdmi_vendor_any_infoframe_log(const char *level,
> */
> void hdmi_infoframe_log(const char *level,
> struct device *dev,
> - union hdmi_infoframe *frame)
> + const union hdmi_infoframe *frame)
> {
> switch (frame->any.type) {
> case HDMI_INFOFRAME_TYPE_AVI:
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index a577d4ae2570..bce1abb1fe57 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -335,6 +335,6 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void
> *buffer, size_t size);
> int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> const void *buffer, size_t size);
> void hdmi_infoframe_log(const char *level, struct device *dev,
> - union hdmi_infoframe *frame);
> + const union hdmi_infoframe *frame);
>
> #endif /* _DRM_HDMI_H */
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)
On 16/07/18 15:10, Ville Syrjälä wrote: > On Sat, Jul 14, 2018 at 02:50:28PM +0200, Hans Verkuil wrote: >> On 11/07/18 17:24, Ville Syrjälä wrote: >>> On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote: >>>> Hi Ville, >>>> >>>> On 11/07/18 15:41, Patchwork wrote: >>>>> == Series Details == >>>>> >>>>> Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2) >>>>> URL : https://patchwork.freedesktop.org/series/46306/ >>>>> State : warning >>>>> >>>>> == Summary == >>>>> >>>>> $ dim sparse origin/drm-tip >>>>> Commit: drm: add support for DisplayPort CEC-Tunneling-over-AUX >>>>> + >>>>> +Error in reading or end of file. >>>> >>>> Any idea what this means? Do I need to do something? >>> >>> I think it has something to do with the new kconfig knob. Presumably we >>> would want dim_sparse() to use olddefconfig instead of oldconfig? >>> >> >> So is this patch series ready to be included in 4.19? And if not, then what >> do I need to do to make that happen? > > Already pushed to drm-misc-next. I just forgot to reply to the mail. > Sorry about that. > Fantastic! Thank you very much for all the reviews! Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)
On 11/07/18 17:24, Ville Syrjälä wrote: > On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote: >> Hi Ville, >> >> On 11/07/18 15:41, Patchwork wrote: >>> == Series Details == >>> >>> Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2) >>> URL : https://patchwork.freedesktop.org/series/46306/ >>> State : warning >>> >>> == Summary == >>> >>> $ dim sparse origin/drm-tip >>> Commit: drm: add support for DisplayPort CEC-Tunneling-over-AUX >>> + >>> +Error in reading or end of file. >> >> Any idea what this means? Do I need to do something? > > I think it has something to do with the new kconfig knob. Presumably we > would want dim_sparse() to use olddefconfig instead of oldconfig? > So is this patch series ready to be included in 4.19? And if not, then what do I need to do to make that happen? Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 0/6] Add ChromeOS EC CEC Support
On 12/07/18 14:42, Neil Armstrong wrote: > Hi Lee, > > On 12/07/2018 14:26, Lee Jones wrote: >> On Wed, 04 Jul 2018, Neil Armstrong wrote: >> >>> Hi All, >>> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >>> through it's Embedded Controller, to enable the Linux CEC Core to >>> communicate >>> with it and get the CEC Physical Address from the correct HDMI Connector, >>> the >>> following must be added/changed: >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver >>> - Add the CEC related commands and events definitions into the EC MFD driver >>> - Add a way to get a CEC notifier with it's (optional) connector name >>> - Add the CEC notifier to the i915 HDMI driver >>> - Add the proper ChromeOS EC CEC Driver >>> >>> The CEC notifier with the connector name is the tricky point, since even on >>> Device-Tree platforms, there is no way to distinguish between multiple HDMI >>> connectors from the same DRM driver. The solution I implemented is pretty >>> simple and only adds an optional connector name to eventually distinguish >>> an HDMI connector notifier from another if they share the same device. >>> >>> Feel free to comment this patchset ! >>> >>> Changes since v7: >>> - rebased on v4.18-rc1 >>> - Fixed whitespace issues on patch 3 >>> - Added Lee's tags >>> >>> Changes since v6: >>> - Added stable identifier comment in intel_display.h >>> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h >>> - Added Acked-by/Reviewed-By tags >>> >>> Changes since v5: >>> - Small fixups on include/linux/mfd/cros_ec_commands.h >>> - Fixed on cros-ec-cec driver accordingly >>> - Added Reviewed-By tags >>> >>> Changes since v4: >>> - Split patch 3 to move the mkbp event size change into a separate patch >>> >>> Changes since v3 (incorrectly reported as v2): >>> - Renamed "Chrome OS" to "ChromeOS" >>> - Updated cros_ec_commands.h new structs definitions to kernel doc format >>> - Added Reviewed-By tags >>> >>> Changes since v2: >>> - Add i915 port_identifier() and use this stable name as cec_notifier conn >>> name >>> - Fixed and cleaned up the CEC commands and events handling >>> - Rebased the CEC sub-device registration on top of Enric's serie >>> - Fixed comments typo on cec driver >>> - Protected the DMI match only with PCI and DMI Kconfigs >>> >>> Changes since v1: >>> - Added cec_notifier_put to intel_hdmi >>> - Fixed all small reported issues on the EC CEC driver >>> - Moved the cec_notifier_get out of the #if .. #else .. #endif >>> >>> Changes since RFC: >>> - Moved CEC sub-device registration after CEC commands and events >>> definitions patch >>> - Removed get_notifier_get_byname >>> - Added CEC_CORE select into i915 Kconfig >>> - Removed CEC driver fallback if notifier is not configured on HW, added >>> explicit warn >>> - Fixed CEC core return type on error >>> - Moved to cros-ec-cec media platform directory >>> - Use bus_find_device() to find the pci i915 device instead of >>> get_notifier_get_byname() >>> - Fix Logical Address setup >>> - Added comment about HW support >>> - Removed memset of msg structures >>> >>> Neil Armstrong (6): >>> media: cec-notifier: Get notifier by device and connector name >>> drm/i915: hdmi: add CEC notifier to intel_hdmi >>> mfd: cros-ec: Increase maximum mkbp event size >>> mfd: cros-ec: Introduce CEC commands and events definitions. >>> mfd: cros_ec_dev: Add CEC sub-device registration >>> media: platform: Add ChromeOS EC CEC driver >>> >>> drivers/gpu/drm/i915/Kconfig | 1 + >>> drivers/gpu/drm/i915/intel_display.h | 24 ++ >>> drivers/gpu/drm/i915/intel_drv.h | 2 + >>> drivers/gpu/drm/i915/intel_hdmi.c| 13 + >>> drivers/media/cec/cec-notifier.c | 11 +- >>> drivers/media/platform/Kconfig | 11 + >>> drivers/media/platform/Makefile | 2 + >>> drivers/media/platform/cros-ec-cec/Makefile | 1 + >>> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 >>> +++ >>> drivers/mfd/cros_ec_dev.c| 16 ++ >>> drivers/platform/chrome/cros_ec_proto.c | 40 ++- >>> include/linux/mfd/cros_ec.h | 2 +- >>> include/linux/mfd/cros_ec_commands.h | 97 +++ >>> include/media/cec-notifier.h | 27 +- >>> 14 files changed, 578 insertions(+), 16 deletions(-) >>> create mode 100644 drivers/media/platform/cros-ec-cec/Makefile >>> create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c >> >> How would you like to handle this set? >> > > Hans proposed you take all the patches throught mfd, > then drm-intel could merge your immutable branch to avoid any conflicts. > > Rodrigo Vivi gave an ack to merge it through other trees on the v6 patchset. > > Hans, should the media tree also merge the branch ? No, there is no need for that. It's fine if it all
[Intel-gfx] [PATCHv10 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even though a CEC device is created, it may not actually work. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_dp_cec.c| 428 drivers/gpu/drm/drm_dp_helper.c | 1 + include/drm/drm_dp_helper.h | 56 + 5 files changed, 496 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_cec.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 757825ac60df..4567b66e6434 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,16 @@ config DRM_LOAD_EDID_FIRMWARE default case is N. Details and instructions how to build your own EDID data are given in Documentation/EDID/HOWTO.txt. +config DRM_DP_CEC + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" + select CEC_CORE + help + Choose this option if you want to enable HDMI CEC support for + DisplayPort/USB-C to HDMI adapters. + + Note: not all adapters support this feature, and even for those + that do support this they often do not hook up the CEC pin. + config DRM_TTM tristate depends on DRM && MMU diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 9d66657ea117..2917953076a5 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -41,6 +41,7 @@ drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/ diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c new file mode 100644 index ..ddb1c5adebb9 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -0,0 +1,428 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DisplayPort CEC-Tunneling-over-AUX support + * + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + */ + +#include +#include +#include +#include +#include + +/* + * Unfortunately it turns out that we have a chicken-and-egg situation + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the + * Parade PS176), but they do not wire up the CEC pin, thus making CEC + * useless. + * + * Sadly there is no way for this driver to know this. What happens is + * that a /dev/cecX device is created that is isolated and unable to see + * any of the other CEC devices. Quite literally the CEC wire is cut + * (or in this case, never connected in the first place). + * + * The reason so few adapters support this is that this tunneling protocol + * was never supported by any OS. So there was no easy way of testing it, + * and no incentive to correctly wire up the CEC pin. + * + * Hopefully by creating this driver it will be easier for vendors to + * finally fix their adapters and test the CEC functionality. + * + * I keep a list of known working adapters here: + * + * https://hverkuil.home.xs4all.nl/cec-status.txt + * + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works + * and is not yet listed there. + * + * Note that the current implementation does not support CEC over an MST hub. + * As far as I can see there is no mechanism defined in the DisplayPort + * standard to transport CEC interrupts over an MST device. It might be + * possible to do this through polling, but I have not been able to get that + * to work. + */ + +/** + * DOC: dp cec helpers + * + * These functions take care of supporting the CEC-Tunneling-over-AUX + * feature of DisplayPort-to-HDMI adapters. + */ + +/* + * When the EDID is unset because the HPD went low, then the CEC DPCD registers + * typically can no longer be read (true for a DP-to-HDMI adapter since it is + * powered by the HPD). However, some displays toggle the HPD off and on for a + * short period for one reason or another, and that would cause the CEC adapter + * to be removed and added again, even though nothing else changed. + * + * This module parameter sets a delay in seconds before the CEC adapter is + * actually unregistered. Only if the HPD does not return within that time will + * the CEC adapter be unregistered. + * + * If it is set to a value >= NEVER_UNREG_DELAY, then the CEC adapter will never + * be unregistered for as long as the connector remains registered. + * + * If it is set to 0,
[Intel-gfx] [PATCHv10 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5be07e1d816d..6fefc5c244ee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4487,6 +4487,9 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
+ /* Handle CEC interrupts, if any */
+ drm_dp_cec_irq(&intel_dp->aux);
+
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
@@ -4803,6 +4806,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ drm_dp_cec_set_edid(&intel_dp->aux, edid);
}
static void
@@ -4810,6 +4814,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ drm_dp_cec_unset_edid(&intel_dp->aux);
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
@@ -4998,6 +5003,7 @@ static int
intel_dp_connector_register(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = connector->dev;
int ret;
ret = intel_connector_register(connector);
@@ -5010,13 +5016,20 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.name, connector->kdev->kobj.name);
intel_dp->aux.dev = connector->kdev;
- return drm_dp_aux_register(&intel_dp->aux);
+ ret = drm_dp_aux_register(&intel_dp->aux);
+ if (!ret)
+ drm_dp_cec_register_connector(&intel_dp->aux,
+ connector->name, dev->dev);
+ return ret;
}
static void
intel_dp_connector_unregister(struct drm_connector *connector)
{
- drm_dp_aux_unregister(&intel_attached_dp(connector)->aux);
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+
+ drm_dp_cec_unregister_connector(&intel_dp->aux);
+ drm_dp_aux_unregister(&intel_dp->aux);
intel_connector_unregister(connector);
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv10 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on top of drm-intel-next. The v10 is identical to v9, except it is rebased to drm-intel-next (v9 didn't apply cleanly) and two alignment warnings have been fixed. The cover letter of v8 can be found here: https://www.spinics.net/lists/dri-devel/msg181688.html Regards, Hans Hans Verkuil (3): drm: add support for DisplayPort CEC-Tunneling-over-AUX drm-kms-helpers.rst: document the DP CEC helpers drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Documentation/gpu/drm-kms-helpers.rst | 9 + drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_dp_cec.c | 428 ++ drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/i915/intel_dp.c | 17 +- include/drm/drm_dp_helper.h | 56 7 files changed, 520 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_cec.c -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv10 2/3] drm-kms-helpers.rst: document the DP CEC helpers
From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index e37557b30f62..62de583e9efe 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -169,6 +169,15 @@ Display Port Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c :export: +Display Port CEC Helper Functions Reference +=== + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :doc: dp cec helpers + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :export: + Display Port Dual Mode Adaptor Helper Functions Reference = -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv9 2/3] drm-kms-helpers.rst: document the DP CEC helpers
From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index e37557b30f62..62de583e9efe 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -169,6 +169,15 @@ Display Port Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c :export: +Display Port CEC Helper Functions Reference +=== + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :doc: dp cec helpers + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :export: + Display Port Dual Mode Adaptor Helper Functions Reference = -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv9 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on the current media master branch (https://git.linuxtv.org/media_tree.git/log/) but it applies fine on top of the current mainline tree. The v9 is identical to v8, the only change is that it is now also CCed to intel-gfx@lists.freedesktop.org. The cover letter of v8 can be found here: https://www.spinics.net/lists/dri-devel/msg181688.html Regards, Hans Hans Verkuil (3): drm: add support for DisplayPort CEC-Tunneling-over-AUX drm-kms-helpers.rst: document the DP CEC helpers drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Documentation/gpu/drm-kms-helpers.rst | 9 + drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_dp_cec.c | 427 ++ drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/i915/intel_dp.c | 17 +- include/drm/drm_dp_helper.h | 56 7 files changed, 519 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_cec.c -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv9 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 16faea30114a..c3045262eba1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4466,6 +4466,9 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
+ /* Handle CEC interrupts, if any */
+ drm_dp_cec_irq(&intel_dp->aux);
+
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
@@ -4780,6 +4783,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ drm_dp_cec_set_edid(&intel_dp->aux, edid);
}
static void
@@ -4787,6 +4791,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ drm_dp_cec_unset_edid(&intel_dp->aux);
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
@@ -4975,6 +4980,7 @@ static int
intel_dp_connector_register(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = connector->dev;
int ret;
ret = intel_connector_register(connector);
@@ -4987,13 +4993,20 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.name, connector->kdev->kobj.name);
intel_dp->aux.dev = connector->kdev;
- return drm_dp_aux_register(&intel_dp->aux);
+ ret = drm_dp_aux_register(&intel_dp->aux);
+ if (!ret)
+ drm_dp_cec_register_connector(&intel_dp->aux,
+ connector->name, dev->dev);
+ return ret;
}
static void
intel_dp_connector_unregister(struct drm_connector *connector)
{
- drm_dp_aux_unregister(&intel_attached_dp(connector)->aux);
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+
+ drm_dp_cec_unregister_connector(&intel_dp->aux);
+ drm_dp_aux_unregister(&intel_dp->aux);
intel_connector_unregister(connector);
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv9 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even though a CEC device is created, it may not actually work. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_dp_cec.c| 427 drivers/gpu/drm/drm_dp_helper.c | 1 + include/drm/drm_dp_helper.h | 56 + 5 files changed, 495 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_cec.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 2a72d2feb76d..d5e217fd0c14 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -122,6 +122,16 @@ config DRM_LOAD_EDID_FIRMWARE default case is N. Details and instructions how to build your own EDID data are given in Documentation/EDID/HOWTO.txt. +config DRM_DP_CEC + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" + select CEC_CORE + help + Choose this option if you want to enable HDMI CEC support for + DisplayPort/USB-C to HDMI adapters. + + Note: not all adapters support this feature, and even for those + that do support this they often do not hook up the CEC pin. + config DRM_TTM tristate depends on DRM && MMU diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index ef9f3dab287f..270266cc6eca 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -41,6 +41,7 @@ drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c new file mode 100644 index ..87b67cc1ea58 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -0,0 +1,427 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DisplayPort CEC-Tunneling-over-AUX support + * + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + */ + +#include +#include +#include +#include +#include + +/* + * Unfortunately it turns out that we have a chicken-and-egg situation + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the + * Parade PS176), but they do not wire up the CEC pin, thus making CEC + * useless. + * + * Sadly there is no way for this driver to know this. What happens is + * that a /dev/cecX device is created that is isolated and unable to see + * any of the other CEC devices. Quite literally the CEC wire is cut + * (or in this case, never connected in the first place). + * + * The reason so few adapters support this is that this tunneling protocol + * was never supported by any OS. So there was no easy way of testing it, + * and no incentive to correctly wire up the CEC pin. + * + * Hopefully by creating this driver it will be easier for vendors to + * finally fix their adapters and test the CEC functionality. + * + * I keep a list of known working adapters here: + * + * https://hverkuil.home.xs4all.nl/cec-status.txt + * + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works + * and is not yet listed there. + * + * Note that the current implementation does not support CEC over an MST hub. + * As far as I can see there is no mechanism defined in the DisplayPort + * standard to transport CEC interrupts over an MST device. It might be + * possible to do this through polling, but I have not been able to get that + * to work. + */ + +/** + * DOC: dp cec helpers + * + * These functions take care of supporting the CEC-Tunneling-over-AUX + * feature of DisplayPort-to-HDMI adapters. + */ + +/* + * When the EDID is unset because the HPD went low, then the CEC DPCD registers + * typically can no longer be read (true for a DP-to-HDMI adapter since it is + * powered by the HPD). However, some displays toggle the HPD off and on for a + * short period for one reason or another, and that would cause the CEC adapter + * to be removed and added again, even though nothing else changed. + * + * This module parameter sets a delay in seconds before the CEC adapter is + * actually unregistered. Only if the HPD does not return within that time will + * the CEC adapter be unregistered. + * + * If it is set to a value >= NEVER_UNREG_DELAY, then the CEC adapter will never + * be unregistered for as long as the connector remains registered. + * + * If it is set to 0, then
Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support
On 11/06/18 10:56, Neil Armstrong wrote: > Hi Lee, > > On 11/06/2018 08:03, Lee Jones wrote: >> On Fri, 08 Jun 2018, Hans Verkuil wrote: >>> On 08/06/18 10:17, Neil Armstrong wrote: >>>> On 08/06/2018 09:53, Hans Verkuil wrote: >>>>> On 06/01/2018 10:19 AM, Neil Armstrong wrote: >>>>>> Hi All, >>>>>> >>>>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >>>>>> through it's Embedded Controller, to enable the Linux CEC Core to >>>>>> communicate >>>>>> with it and get the CEC Physical Address from the correct HDMI >>>>>> Connector, the >>>>>> following must be added/changed: >>>>>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver >>>>>> - Add the CEC related commands and events definitions into the EC MFD >>>>>> driver >>>>>> - Add a way to get a CEC notifier with it's (optional) connector name >>>>>> - Add the CEC notifier to the i915 HDMI driver >>>>>> - Add the proper ChromeOS EC CEC Driver >>>>>> >>>>>> The CEC notifier with the connector name is the tricky point, since even >>>>>> on >>>>>> Device-Tree platforms, there is no way to distinguish between multiple >>>>>> HDMI >>>>>> connectors from the same DRM driver. The solution I implemented is pretty >>>>>> simple and only adds an optional connector name to eventually distinguish >>>>>> an HDMI connector notifier from another if they share the same device. >>>>> >>>>> This looks good to me, which brings me to the next question: how to merge >>>>> this? >>>>> >>>>> It touches on three subsystems (media, drm, mfd), so that makes this >>>>> tricky. >>>>> >>>>> I think there are two options: either the whole series goes through the >>>>> media tree, or patches 1+2 go through drm and 3-6 through media. If there >>>>> is a high chance of conflicts in the mfd code, then it is also an option >>>>> to >>>>> have patches 3-6 go through the mfd subsystem. >>>> >>>> I think patches 3-6 should go in the mfd tree, Lee is used to handle this, >>>> then I think the rest could go in the media tree. >>>> >>>> Lee, do you think it would be possible to have an immutable branch with >>>> patches 3-6 ? >>>> >>>> Could we have an immutable branch from media tree with patch 1 to be >>>> merged in >>>> the i915 tree for patch 2 ? >>>> >>>> Or patch 1+2 could me merged into the i915 tree and generate an immutable >>>> branch >>> >>> I think patches 1+2 can just go to the i915 tree. The i915 driver changes >>> often, >>> so going through that tree makes sense. The cec-notifier code is unlikely >>> to change, >>> and I am fine with that patch going through i915. >>> >>>> for media to merge the mfd branch + patch 7 ? >>> >>> Patch 7? I only count 6? >>> >>> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at >>> all. >>> There is chance of a conflict when this is eventually pushed to mainline for >>> the media Kconfig, but that's all. >> >> What are the *build* dependencies within the set? > > Here are the hard the build dependency : > > Patch 2 depends on Patch 1 > Patch 5 depends on Patch 4 > Patch 6 depends on Patches 1 & 4 Ah, I missed the dependency of patch 6 on patch 1. So the whole series needs to be merged as a single unit. > >> >> I'd be happy to send out a pull-request for either all of the patches, >> or just the MFD changes once I've had chance to review them. >> > > Great, thanks ! > > Neil > I'm OK if this goes through the mfd tree. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support
On 08/06/18 10:17, Neil Armstrong wrote: > Hi Hans, > > On 08/06/2018 09:53, Hans Verkuil wrote: >> On 06/01/2018 10:19 AM, Neil Armstrong wrote: >>> Hi All, >>> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >>> through it's Embedded Controller, to enable the Linux CEC Core to >>> communicate >>> with it and get the CEC Physical Address from the correct HDMI Connector, >>> the >>> following must be added/changed: >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver >>> - Add the CEC related commands and events definitions into the EC MFD driver >>> - Add a way to get a CEC notifier with it's (optional) connector name >>> - Add the CEC notifier to the i915 HDMI driver >>> - Add the proper ChromeOS EC CEC Driver >>> >>> The CEC notifier with the connector name is the tricky point, since even on >>> Device-Tree platforms, there is no way to distinguish between multiple HDMI >>> connectors from the same DRM driver. The solution I implemented is pretty >>> simple and only adds an optional connector name to eventually distinguish >>> an HDMI connector notifier from another if they share the same device. >> >> This looks good to me, which brings me to the next question: how to merge >> this? >> >> It touches on three subsystems (media, drm, mfd), so that makes this >> tricky. >> >> I think there are two options: either the whole series goes through the >> media tree, or patches 1+2 go through drm and 3-6 through media. If there >> is a high chance of conflicts in the mfd code, then it is also an option to >> have patches 3-6 go through the mfd subsystem. > > I think patches 3-6 should go in the mfd tree, Lee is used to handle this, > then I think the rest could go in the media tree. > > Lee, do you think it would be possible to have an immutable branch with > patches 3-6 ? > > Could we have an immutable branch from media tree with patch 1 to be merged in > the i915 tree for patch 2 ? > > Or patch 1+2 could me merged into the i915 tree and generate an immutable > branch I think patches 1+2 can just go to the i915 tree. The i915 driver changes often, so going through that tree makes sense. The cec-notifier code is unlikely to change, and I am fine with that patch going through i915. > for media to merge the mfd branch + patch 7 ? Patch 7? I only count 6? If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all. There is chance of a conflict when this is eventually pushed to mainline for the media Kconfig, but that's all. Regards, Hans > > Neil > >> >> Any opinions? >> >> Regards, >> >> Hans >> >>> >>> Feel free to comment this patchset ! >>> >>> Changes since v6: >>> - Added stable identifier comment in intel_display.h >>> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h >>> - Added Acked-by/Reviewed-By tags >>> >>> Changes since v5: >>> - Small fixups on include/linux/mfd/cros_ec_commands.h >>> - Fixed on cros-ec-cec driver accordingly >>> - Added Reviewed-By tags >>> >>> Changes since v4: >>> - Split patch 3 to move the mkbp event size change into a separate patch >>> >>> Changes since v3 (incorrectly reported as v2): >>> - Renamed "Chrome OS" to "ChromeOS" >>> - Updated cros_ec_commands.h new structs definitions to kernel doc format >>> - Added Reviewed-By tags >>> >>> Changes since v2: >>> - Add i915 port_identifier() and use this stable name as cec_notifier conn >>> name >>> - Fixed and cleaned up the CEC commands and events handling >>> - Rebased the CEC sub-device registration on top of Enric's serie >>> - Fixed comments typo on cec driver >>> - Protected the DMI match only with PCI and DMI Kconfigs >>> >>> Changes since v1: >>> - Added cec_notifier_put to intel_hdmi >>> - Fixed all small reported issues on the EC CEC driver >>> - Moved the cec_notifier_get out of the #if .. #else .. #endif >>> >>> Changes since RFC: >>> - Moved CEC sub-device registration after CEC commands and events >>> definitions patch >>> - Removed get_notifier_get_byname >>> - Added CEC_CORE select into i915 Kconfig >>> - Removed CEC driver fallback if notifier is not configured on HW, added >>> explicit warn >>> - Fixed CEC core return typ
Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support
On 06/01/2018 10:19 AM, Neil Armstrong wrote: > Hi All, > > The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > through it's Embedded Controller, to enable the Linux CEC Core to communicate > with it and get the CEC Physical Address from the correct HDMI Connector, the > following must be added/changed: > - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > - Add the CEC related commands and events definitions into the EC MFD driver > - Add a way to get a CEC notifier with it's (optional) connector name > - Add the CEC notifier to the i915 HDMI driver > - Add the proper ChromeOS EC CEC Driver > > The CEC notifier with the connector name is the tricky point, since even on > Device-Tree platforms, there is no way to distinguish between multiple HDMI > connectors from the same DRM driver. The solution I implemented is pretty > simple and only adds an optional connector name to eventually distinguish > an HDMI connector notifier from another if they share the same device. This looks good to me, which brings me to the next question: how to merge this? It touches on three subsystems (media, drm, mfd), so that makes this tricky. I think there are two options: either the whole series goes through the media tree, or patches 1+2 go through drm and 3-6 through media. If there is a high chance of conflicts in the mfd code, then it is also an option to have patches 3-6 go through the mfd subsystem. Any opinions? Regards, Hans > > Feel free to comment this patchset ! > > Changes since v6: > - Added stable identifier comment in intel_display.h > - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h > - Added Acked-by/Reviewed-By tags > > Changes since v5: > - Small fixups on include/linux/mfd/cros_ec_commands.h > - Fixed on cros-ec-cec driver accordingly > - Added Reviewed-By tags > > Changes since v4: > - Split patch 3 to move the mkbp event size change into a separate patch > > Changes since v3 (incorrectly reported as v2): > - Renamed "Chrome OS" to "ChromeOS" > - Updated cros_ec_commands.h new structs definitions to kernel doc format > - Added Reviewed-By tags > > Changes since v2: > - Add i915 port_identifier() and use this stable name as cec_notifier conn > name > - Fixed and cleaned up the CEC commands and events handling > - Rebased the CEC sub-device registration on top of Enric's serie > - Fixed comments typo on cec driver > - Protected the DMI match only with PCI and DMI Kconfigs > > Changes since v1: > - Added cec_notifier_put to intel_hdmi > - Fixed all small reported issues on the EC CEC driver > - Moved the cec_notifier_get out of the #if .. #else .. #endif > > Changes since RFC: > - Moved CEC sub-device registration after CEC commands and events > definitions patch > - Removed get_notifier_get_byname > - Added CEC_CORE select into i915 Kconfig > - Removed CEC driver fallback if notifier is not configured on HW, added > explicit warn > - Fixed CEC core return type on error > - Moved to cros-ec-cec media platform directory > - Use bus_find_device() to find the pci i915 device instead of > get_notifier_get_byname() > - Fix Logical Address setup > - Added comment about HW support > - Removed memset of msg structures > > Neil Armstrong (6): > media: cec-notifier: Get notifier by device and connector name > drm/i915: hdmi: add CEC notifier to intel_hdmi > mfd: cros-ec: Increase maximum mkbp event size > mfd: cros-ec: Introduce CEC commands and events definitions. > mfd: cros_ec_dev: Add CEC sub-device registration > media: platform: Add ChromeOS EC CEC driver > > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/intel_display.h | 24 ++ > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_hdmi.c| 13 + > drivers/media/cec/cec-notifier.c | 11 +- > drivers/media/platform/Kconfig | 11 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/cros-ec-cec/Makefile | 1 + > drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 > +++ > drivers/mfd/cros_ec_dev.c| 16 ++ > drivers/platform/chrome/cros_ec_proto.c | 40 ++- > include/linux/mfd/cros_ec.h | 2 +- > include/linux/mfd/cros_ec_commands.h | 100 +++ > include/media/cec-notifier.h | 27 +- > 14 files changed, 581 insertions(+), 16 deletions(-) > create mode 100644 drivers/media/platform/cros-ec-cec/Makefile > create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/platform/chrome/cros_ec_proto.c | 40
> +
> include/linux/mfd/cros_ec.h | 2 +-
> include/linux/mfd/cros_ec_commands.h| 19
> 3 files changed, 51 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
> *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> + }
> +
> + return ret;
> +}
> +
> static int get_next_event(struct cros_ec_device *ec_dev)
> {
> u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> + static int cmd_version = 1;
> int ret;
>
> if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> return -EHOSTDOWN;
> }
>
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event_v1));
> + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> + return ret;
>
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(&ec_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
> }
>
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
> }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
> };
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..cc0768e 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
> uint32_t sysrq;
> } __packed;
>
> +union ec_response_get_next_data_v1 {
> + uint8_t key_matrix[16];
> +
> + /* Unaligned */
> + uint32_t host_event;
> +
> + uint32_t buttons;
> + uint32_t switches;
> + uint32_t sysrq;
> + uint32_t cec_events;
> + uint8_tcec_message[16];
> +} __packed;
> +
> struct ec_response_get_next_event {
> uint8_t event_type;
> /* Followed by event data if any */
> union ec_response_get_next_data data;
> } __packed;
>
> +struct ec_response_get_next_event_v1 {
> + uint8_t event_type;
> + /* Followed by event data if any */
> + union ec_response_get_next_data_v1 data;
> +} __packed;
> +
> /* Bit indices for buttons and switches.*/
> /* Buttons */
> #define EC_MKBP_POWER_BUTTON 0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
On 24/05/18 11:57, Neil Armstrong wrote:
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
For whatever it is worth:
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/mfd/cros_ec_dev.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 1d6dc5c..272969e 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev
> *ec)
> kfree(msg);
> }
>
> +static const struct mfd_cell cros_ec_cec_cells[] = {
> + { .name = "cros-ec-cec" }
> +};
> +
> static const struct mfd_cell cros_ec_rtc_cells[] = {
> { .name = "cros-ec-rtc" }
> };
> @@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
>
> + /* Check whether this EC instance has CEC host command support */
> + if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
> + retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
> + cros_ec_cec_cells,
> + ARRAY_SIZE(cros_ec_cec_cells),
> + NULL, 0, NULL);
> + if (retval)
> + dev_err(ec->dev,
> + "failed to add cros-ec-cec device: %d\n",
> + retval);
> + }
> +
> /* Check whether this EC instance has RTC host command support */
> if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
> retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On 24/05/18 11:57, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
>
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> include/linux/mfd/cros_ec_commands.h | 81
>
> 1 file changed, 81 insertions(+)
>
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index cc0768e..fe33a81 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
> };
>
> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> EC_MKBP_EVENT_SYSRQ = 6,
>
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_EVENT_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
> /* Number of MKBP events */
> EC_MKBP_EVENT_COUNT,
> };
> @@ -2850,6 +2858,79 @@ struct ec_params_reboot_ec {
>
>
> /*/
> /*
> + * HDMI CEC commands
> + *
> + * These commands are for sending and receiving message via HDMI CEC
> + */
> +#define EC_MAX_CEC_MSG_LEN 16
> +
> +/* CEC message from the AP to be written on the CEC bus */
> +#define EC_CMD_CEC_WRITE_MSG 0x00B8
> +
> +/**
> + * struct ec_params_cec_write - Message to write to the CEC bus
> + * @msg: message content to write to the CEC bus
> + */
> +struct ec_params_cec_write {
> + uint8_t msg[EC_MAX_CEC_MSG_LEN];
> +} __packed;
> +
> +/* Set various CEC parameters */
> +#define EC_CMD_CEC_SET 0x00BA
> +
> +/**
> + * struct ec_params_cec_set - CEC parameters set
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + * @val: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
> + * or 1 to enable CEC functionnality, in case cmd is
> CEC_CMD_LOGICAL_ADDRESS,
> + * this field encodes the requested logical address between 0 and 15
> + * or 0xff to unregister
> + */
> +struct ec_params_cec_set {
> + uint8_t cmd; /* enum cec_command */
> + uint8_t val;
> +} __packed;
> +
> +/* Read various CEC parameters */
> +#define EC_CMD_CEC_GET 0x00BB
> +
> +/**
> + * struct ec_params_cec_get - CEC parameters get
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + */
> +struct ec_params_cec_get {
> + uint8_t cmd; /* enum cec_command */
> +} __packed;
> +
> +/**
> + * struct ec_response_cec_get - CEC parameters get response
> + * @val: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
> + * disabled or 1 if CEC functionnality is enabled,
> + * in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
> + * configured logical address between 0 and 15 or 0xff if unregistered
> + */
> +struct ec_response_cec_get {
> + uint8_t val;
> +} __packed;
> +
> +/* CEC parameters command */
> +enum ec_cec_command {
> + /* CEC reading, writing and events enable */
> + CEC_CMD_ENABLE,
> + /* CEC logical address */
> + CEC_CMD_LOGICAL_ADDRESS,
> +};
> +
> +/* Events from CEC to AP */
> +enum mkbp_cec_event {
> + /* Outgoing message was acknowledged by a follower */
> + EC_MKBP_CEC_SEND_OK = BIT(0),
> + /* Outgoing message was not acknowledged */
> + EC_MKBP_CEC_SEND_FAILED = BIT(1),
> +};
> +
> +/*/
> +/*
> * Special commands
> *
> * These do not follow the normal rules for commands. See each command for
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On 24/05/18 10:54, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
>
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
> ---
> include/linux/mfd/cros_ec_commands.h | 85
>
> 1 file changed, 85 insertions(+)
>
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index cc0768e..ea9646f 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
> };
>
> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> EC_MKBP_EVENT_SYSRQ = 6,
>
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
> /* Number of MKBP events */
> EC_MKBP_EVENT_COUNT,
> };
> @@ -2850,6 +2858,83 @@ struct ec_params_reboot_ec {
>
>
> /*/
> /*
> + * HDMI CEC commands
> + *
> + * These commands are for sending and receiving message via HDMI CEC
> + */
> +#define MAX_CEC_MSG_LEN 16
Can you rename this to EC_MAX_CEC_MSG_LEN? It is way too similar to the
CEC_MAX_MSG_LEN defined in cec.h. Since this is a property of the EC hw/fw
it makes sense to prefix it accordingly.
> +
> +/* CEC message from the AP to be written on the CEC bus */
> +#define EC_CMD_CEC_WRITE_MSG 0x00B8
> +
> +/**
> + * struct ec_params_cec_write - Message to write to the CEC bus
> + * @msg: message content to write to the CEC bus
> + */
> +struct ec_params_cec_write {
> + uint8_t msg[MAX_CEC_MSG_LEN];
> +} __packed;
> +
> +/* Set various CEC parameters */
> +#define EC_CMD_CEC_SET 0x00BA
> +
> +/**
> + * struct ec_params_cec_set - CEC parameters set
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + * @enable: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
> + * or 1 to enable CEC functionnality
> + * @address: in case cmd is CEC_CMD_LOGICAL_ADDRESS, this field encodes the
> + * requested logical address between 0 and 15 or 0xff to unregister
> + */
> +struct ec_params_cec_set {
> + uint8_t cmd; /* enum cec_command */
> + union {
> + uint8_t enable;
> + uint8_t address;
> + };
> +} __packed;
> +
> +/* Read various CEC parameters */
> +#define EC_CMD_CEC_GET 0x00BB
> +
> +/**
> + * struct ec_params_cec_get - CEC parameters get
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + */
> +struct ec_params_cec_get {
> + uint8_t cmd; /* enum cec_command */
> +} __packed;
> +
> +/**
> + * struct ec_response_cec_get - CEC parameters get response
> + * @enable: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
> + * disabled or 1 if CEC functionnality is enabled
> + * @address: in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
> + * configured logical address between 0 and 15 or 0xff if unregistered
> + */
> +struct ec_response_cec_get {
> + union {
> + uint8_t enable;
> + uint8_t address;
> + };
> +} __packed;
> +
> +/* CEC parameters command */
> +enum cec_command {
Same here: shouldn't all of this be prefixed with ec_ or EC_?
Regards,
Hans
> + /* CEC reading, writing and events enable */
> + CEC_CMD_ENABLE,
> + /* CEC logical address */
> + CEC_CMD_LOGICAL_ADDRESS,
> +};
> +
> +/* Events from CEC to AP */
> +enum mkbp_cec_event {
> + EC_MKBP_CEC_SEND_OK = BIT(0),
> + EC_MKBP_CEC_SEND_FAILED = BIT(1),
> +};
> +
> +/*/
> +/*
> * Special commands
> *
> * These do not follow the normal rules for commands. See each command for
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 6/6] media: platform: Add ChromeOS EC CEC driver
On 24/05/18 10:55, Neil Armstrong wrote:
> The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec-cec/Makefile | 1 +
> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347
> +++
> 4 files changed, 361 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
> create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..bc37ecf 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "ChromeOS EC CEC driver"
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + ChromeOS Embedded Controller's CEC.
> + The CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..830696f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y+= meson/
> +
> +obj-y+= cros-ec-cec/
> diff --git a/drivers/media/platform/cros-ec-cec/Makefile
> b/drivers/media/platform/cros-ec-cec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> new file mode 100644
> index 000..7f897a2
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -0,0 +1,347 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for ChromeOS Embedded Controller
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rx_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
Re: [Intel-gfx] [PATCH v5 1/6] media: cec-notifier: Get notifier by device and connector name
On 24/05/18 10:54, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/cec/cec-notifier.c | 11 ---
> include/media/cec-notifier.h | 27 ---
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..dd2078b 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,14 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = kstrdup(conn, GFP_KERNEL);
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> @@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
> container_of(kref, struct cec_notifier, kref);
>
> list_del(&n->head);
> + kfree(n->conn);
> kfree(n);
> }
>
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..814eeef 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,8 +20,10 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> - * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> * @dev: device that sends the events.
> + * @conn: the connector name from which the event occurs
> *
> * If a notifier for device @dev already exists, then increase the refcount
> * and return that notifier.
> @@ -31,7 +33,8 @@ struct cec_notifier;
> *
> * Return NULL if the memory could not be allocated.
> */
> -struct cec_notifier *cec_notifier_get(struct device *dev);
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +const char *conn);
>
> /**
> * cec_notifier_put - decrease refcount and delete when the refcount reaches
> 0.
> @@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
> struct cec_notifier *notifier);
>
> #else
> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> + const char *conn)
> {
> /* A non-NULL pointer is expected on success */
> return (struct cec_notifier *)0xdeadfeed;
> @@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct
> cec_adapter *adap,
> #endif
>
> /**
> + * cec_notifier_get - find
Re: [Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
Some small comments below:
On 05/15/18 14:47, Neil Armstrong wrote:
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec-cec/Makefile | 1 +
> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 336
> +++
> 4 files changed, 350 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
> create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..e55a8ed2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "Chrome OS EC CEC driver"
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + Chrome OS Embedded Controller's CEC.
> + The CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..830696f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y+= meson/
> +
> +obj-y+= cros-ec-cec/
> diff --git a/drivers/media/platform/cros-ec-cec/Makefile
> b/drivers/media/platform/cros-ec-cec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> new file mode 100644
> index 000..bbff5d6
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -0,0 +1,336 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for Chrome OS Embedded Controller
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * This handles the CEC interface to the ChromeOS Embedded Controller,
> + * but only a single CEC line tied to a single HDMI output is handled now.
> + */
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rx_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC_TX_STATUS_OK);
> +
> + /* FW takes care of all retries, tell core to avoid more retries */
> + if (events & EC_MKBP_CEC_SEND_FAILED)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC
Re: [Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/18 14:46, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
You haven't figured yet out where to place the cec_notifier_put() call?
Or did you forget?
Regards,
Hans
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
> select IOSF_MBI
> select CRC32
> + select CEC_CORE if CEC_NOTIFIER
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..9b94d72 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] media: cec-notifier: Get notifier by device and connector name
Hi Neil,
Two small comments below:
On 05/15/18 14:46, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/cec/cec-notifier.c | 12 +---
> include/media/cec-notifier.h | 30 --
> 2 files changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..7038abae1 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,14 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = kstrdup(conn, GFP_KERNEL);
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> @@ -62,6 +66,8 @@ static void cec_notifier_release(struct kref *kref)
> container_of(kref, struct cec_notifier, kref);
>
> list_del(&n->head);
> + if (n->conn)
No need for this if, kfree already tests the pointer.
> + kfree(n->conn);
> kfree(n);
> }
>
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..73f92c7 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,6 +20,23 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> + * @dev: device that sends the events.
> + * @conn: the connector name from which the event occurs
> + *
> + * If a notifier for device @dev already exists, then increase the refcount
> + * and return that notifier.
> + *
> + * If it doesn't exist, then allocate a new notifier struct and return a
> + * pointer to that new struct.
> + *
> + * Return NULL if the memory could not be allocated.
> + */
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +const char *conn);
> +
> +/**
> * cec_notifier_get - find or create a new cec_notifier for the given device.
> * @dev: device that sends the events.
> *
> @@ -31,7 +48,10 @@ struct cec_notifier;
> *
> * Return NULL if the memory could not be allocated.
> */
> -struct cec_notifier *cec_notifier_get(struct device *dev);
> +static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +{
> + return cec_notifier_get_conn(dev, NULL);
> +}
>
> /**
> * cec_notifier_put - decrease refcount and delete when the refcount reaches
> 0.
> @@ -85,12 +105,18 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
> struct cec_notifier *notifier);
>
> #else
> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> + const char *conn)
> {
> /* A non-NULL pointer is expected on success */
> return (struct cec_notifier *)0xdeadfeed;
> }
>
> +static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +{
> + return cec_notifier_get_conn(dev, NULL);
>
Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong
> ---
> +static SIMPLE_DEV_PM_OPS(cros_ec_cec_pm_ops,
> + cros_ec_cec_suspend, cros_ec_cec_resume);
> +
> +/*
> + * The Firmware only handles single CEC interface tied to a single HDMI
single CEC -> a single CEC
> + * connector we specify along the DRM device name handling the HDMI output
along -> along with
> + */
> +
> +struct cec_dmi_match {
> + char *sys_vendor;
> + char *product_name;
> + char *devname;
> + char *conn;
> +};
> +
Looks good!
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong
For what it is worth (not an MFD expert):
Acked-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/mfd/cros_ec_dev.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index eafd06f..57064ec 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev
> *ec)
> kfree(msg);
> }
>
> +static void cros_ec_cec_register(struct cros_ec_dev *ec)
> +{
> + int ret;
> + struct mfd_cell cec_cell = {
> + .name = "cros-ec-cec",
> + };
> +
> + ret = mfd_add_devices(ec->dev, 0, &cec_cell, 1, NULL, 0, NULL);
> + if (ret)
> + dev_err(ec->dev, "failed to add EC CEC\n");
> +}
> +
> static int ec_device_probe(struct platform_device *pdev)
> {
> int retval = -ENOMEM;
> @@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
>
> + /* check whether this EC handles CEC. */
> + if (cros_ec_check_features(ec, EC_FEATURE_CEC))
> + cros_ec_cec_register(ec);
> +
> /* Take control of the lightbar from the EC. */
> lb_manual_suspend_ctrl(ec, 1);
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil Armstrong
> ---
> drivers/platform/chrome/cros_ec_proto.c | 42 +
> include/linux/mfd/cros_ec.h | 2 +-
> include/linux/mfd/cros_ec_commands.h| 80
> +
> 3 files changed, 114 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..ba47f79 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,29 +504,53 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
> *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(&ec_dev->event_data, msg->data, size);
> + }
> +
> + return ret;
> +}
> +
> static int get_next_event(struct cros_ec_device *ec_dev)
> {
> u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> + static int cmd_version = 1;
> int ret;
>
> + BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
Use the define instead of hardcoding 16. I'm not really sure why you need this.
If cec_message uses the right define for the array size (see my comment below),
then this really can't go wrong, can it?
> +
> if (ec_dev->suspended) {
> dev_dbg(ec_dev->dev, "Device suspended.\n");
> return -EHOSTDOWN;
> }
>
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(ec_dev->event_data));
> + if (ret != EC_RES_INVALID_VERSION)
> + return ret;
>
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(&ec_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
> }
>
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
> }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 2d4e23c..f3415eb 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
> };
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..18df466 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
> };
>
> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> EC_MKBP_EVENT_SYSRQ = 6,
>
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
> /* Number of MKBP events */
> EC_MKBP_EVENT_COUNT,
> };
> @@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
> uint32_t sysrq;
> } __packed;
>
> +union ec_response_get_next_data_v1 {
> + uint8_t key_matrix[16];
> +
> + /* Unaligned */
> + uint32_t host_event;
> +
> + uint32_t buttons;
> + uint32_t switches;
> + uint32_t sysrq;
> + uint32_t cec_e
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 12
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
> select IOSF_MBI
> select CRC32
> + select CEC_CORE if CEC_NOTIFIER
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..e98103d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder,
>
> static void intel_hdmi_destroy(struct drm_connector *connector)
> {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> kfree(to_intel_connector(connector)->detect_edid);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name
On 05/15/2018 04:42 PM, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
The patch looks good, but I'm curious about this paragraph above.
Was this tested with devices with more than one HDMI output? Or only on
laptops with a single physical HDMI output? If there are two or more
outputs then I guess it is the HW designer that decides with output gets
CEC support?
Regards,
Hans
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/cec/cec-notifier.c | 11 ---
> include/media/cec-notifier.h | 27 ---
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..dd2078b 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,14 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = kstrdup(conn, GFP_KERNEL);
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> @@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
> container_of(kref, struct cec_notifier, kref);
>
> list_del(&n->head);
> + kfree(n->conn);
> kfree(n);
> }
>
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..814eeef 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,8 +20,10 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> - * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> * @dev: device that sends the events.
> + * @conn: the connector name from which the event occurs
> *
> * If a notifier for device @dev already exists, then increase the refcount
> * and return that notifier.
> @@ -31,7 +33,8 @@ struct cec_notifier;
> *
> * Return NULL if the memory could not be allocated.
> */
> -struct cec_notifier *cec_notifier_get(struct device *dev);
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +const char *conn);
>
> /**
> * cec_notifier_put - decrease refcount and delete when the refcount reaches
> 0.
> @@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
> struct cec_notifier *notifier);
>
> #else
> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> + const char *conn)
> {
> /* A non-NULL pointer is expected on success */
> return (struct cec_notifier *)0xdeadfeed;
> @@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct
> cec_adapter *adap,
> #endif
>
> /**
> + * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * @dev: device that sends the events.
> + *
> + * If a notifier for device @dev already exists, then increase the refcoun
Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/18 10:28, Neil Armstrong wrote:
> + int ret;
> +
> + cros_ec_cec = devm_kzalloc(&pdev->dev, sizeof(*cros_ec_cec),
> +GFP_KERNEL);
> + if (!cros_ec_cec)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, cros_ec_cec);
> + cros_ec_cec->cros_ec = cros_ec;
> +
> + ret = cros_ec_cec_get_notifier(&cros_ec_cec->notify);
> + if (ret) {
> + dev_warn(&pdev->dev, "no CEC notifier available\n");
> + cec_caps |= CEC_CAP_PHYS_ADDR;
Can this happen? What hardware has this? I am strongly opposed to CEC
drivers
using this capability unless there is no other option. It's a pain for
userspace.
>>>
>>> It's in case an HW having a CEC capable FW but not in the
>>> cec_dmi_match_table, in this case
>>> it won't fail but still enable the CEC interface without a notifier.
>>
>> I don't think that's a good idea. CAP_PHYS_ADDR should *only* be used in
>> situations
>> where it is truly impossible to tell which output is connected to the CEC
>> adapter.
>> That's the case with e.g. USB CEC dongles where you have no idea how the user
>> connected the HDMI cables.
>>
>> But I assume that in this case it just means that the cec_dmi_match_table
>> needs
>> to be updated, i.e. it is a driver bug.
>
> Yep, maybe a dev_warn should be added to notify this bug ?
Yes, a dev_warn and then return -ENODEV.
>
>>
>> Another thing: this driver assumes that there is only one CEC adapter for
>> only
>> one HDMI output. But what if there are more HDMI outputs? Will there be one
>> CEC adapter for each output? Or does the hardware have no provisions for
>> that?
>
> The current EC interface only exposes a single CEC interface for now, there
> is no
> plan yet for multiple HDMI outputs handling.
>
>>
>> Something should be mentioned about this in a comment.
>
> Ok
Thanks!
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/18 09:25, Neil Armstrong wrote: > Hi Hans, > > Thanks for the extensive review. > > On 15/05/2018 08:58, Hans Verkuil wrote: >> On 05/15/2018 12:40 AM, Neil Armstrong wrote: >>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the >>> driver for such feature of the Embedded Controller. >>> >>> This driver is part of the cros-ec MFD and will be add as a sub-device when >>> the feature bit is exposed by the EC. >>> >>> The controller will only handle a single logical address and handles >>> all the messages retries and will only expose Success or Error. >>> >>> When the logical address is invalid, the controller will act as a CEC >>> sniffer >>> and transfer all messages on the bus. >> >> I did not see any support for this. If this works as you state here, then >> adding >> support for CEC_CAP_MONITOR_ALL is highly recommended. > > Oops, I forgot to remove this phrase, the FW will maybe support it, but it > has been > dropped for the first revision. > >> >>> >>> Signed-off-by: Neil Armstrong >>> --- >>> drivers/media/platform/Kconfig | 11 + >>> drivers/media/platform/Makefile | 2 + >>> drivers/media/platform/cros-ec/Makefile | 1 + >>> drivers/media/platform/cros-ec/cros-ec-cec.c | 331 >>> +++ >>> 4 files changed, 345 insertions(+) >>> create mode 100644 drivers/media/platform/cros-ec/Makefile >>> create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c >> >> Shouldn't the directory be called cros-ec-cec? >> >>> >>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig >>> index c7a1cf8..e55a8ed2 100644 >>> --- a/drivers/media/platform/Kconfig >>> +++ b/drivers/media/platform/Kconfig >>> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS >>> >>> if CEC_PLATFORM_DRIVERS >>> >>> +config VIDEO_CROS_EC_CEC >>> + tristate "Chrome OS EC CEC driver" >>> + depends on MFD_CROS_EC || COMPILE_TEST >>> + select CEC_CORE >>> + select CEC_NOTIFIER >>> + ---help--- >>> + If you say yes here you will get support for the >>> + Chrome OS Embedded Controller's CEC. >>> + The CEC bus is present in the HDMI connector and enables communication >>> + between compatible devices. >>> + >>> config VIDEO_MESON_AO_CEC >>> tristate "Amlogic Meson AO CEC driver" >>> depends on ARCH_MESON || COMPILE_TEST >>> diff --git a/drivers/media/platform/Makefile >>> b/drivers/media/platform/Makefile >>> index 932515d..0e0582e 100644 >>> --- a/drivers/media/platform/Makefile >>> +++ b/drivers/media/platform/Makefile >>> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= >>> qcom/camss-8x16/ >>> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/ >>> >>> obj-y += meson/ >>> + >>> +obj-y += cros-ec/ >>> diff --git a/drivers/media/platform/cros-ec/Makefile >>> b/drivers/media/platform/cros-ec/Makefile >>> new file mode 100644 >>> index 000..9ce97f9 >>> --- /dev/null >>> +++ b/drivers/media/platform/cros-ec/Makefile >>> @@ -0,0 +1 @@ >>> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o >>> diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c >>> b/drivers/media/platform/cros-ec/cros-ec-cec.c >>> new file mode 100644 >>> index 000..fea90da >>> --- /dev/null >>> +++ b/drivers/media/platform/cros-ec/cros-ec-cec.c >>> @@ -0,0 +1,331 @@ >>> +// SPDX-License-Identifier: GPL-2.0+ >>> +/* >>> + * CEC driver for Chrome OS Embedded Controller >>> + * >>> + * Copyright (c) 2018 BayLibre, SAS >>> + * Author: Neil Armstrong >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#define DRV_NAME "cros-ec-cec" >>> + >>> +/** >>> + * struct cros_ec_cec - Driver data for EC CEC >>> + * >>> + * @cros_ec: Pointer to EC device >>> + * @notifie
Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/2018 12:40 AM, Neil Armstrong wrote:
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> When the logical address is invalid, the controller will act as a CEC sniffer
> and transfer all messages on the bus.
I did not see any support for this. If this works as you state here, then adding
support for CEC_CAP_MONITOR_ALL is highly recommended.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec/Makefile | 1 +
> drivers/media/platform/cros-ec/cros-ec-cec.c | 331
> +++
> 4 files changed, 345 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec/Makefile
> create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c
Shouldn't the directory be called cros-ec-cec?
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..e55a8ed2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "Chrome OS EC CEC driver"
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + Chrome OS Embedded Controller's CEC.
> + The CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..0e0582e 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y+= meson/
> +
> +obj-y+= cros-ec/
> diff --git a/drivers/media/platform/cros-ec/Makefile
> b/drivers/media/platform/cros-ec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec/cros-ec-cec.c
> new file mode 100644
> index 000..fea90da
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
> @@ -0,0 +1,331 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for Chrome OS Embedded Controller
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rc_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
How robust is the underlying code and hardware? What happens if a
CEC message with more than 16 bytes is received?
Hard to test unless you have an RPi3 set up as a CEC debugger. See
last section in https://hverkuil.home.xs4all.nl/cec-status.txt.
Since you worked with CEC for a while now I recommend you set up such
a system. It's cheap and very useful.
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> +
Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/2018 12:40 AM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to an eventual CEC adapter. > > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_hdmi.c | 10 ++ The Kconfig also needs to be changed. In the DRM_I915 you need to add: select CEC_CORE if CEC_NOTIFIER Otherwise you'll get problems if the cec driver is a module and i915 is built-in. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/2018 12:40 AM, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..9b94d72 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
You 'get' the notifier here, but where is the cec_notifier_put when the
connector is deleted?
Regards,
Hans
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name
Hi Neil,
Thanks for this patch series!
Some comments below:
On 05/15/2018 12:40 AM, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/cec/cec-notifier.c | 30 ---
> include/media/cec-notifier.h | 44
> ++--
> 2 files changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..716070a 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,34 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_byname(const char *name,
> + const char *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (!strcmp(dev_name(n->dev), name) &&
> + (!conn || !strcmp(n->conn, conn))) {
> + kref_get(&n->kref);
> + mutex_unlock(&cec_notifiers_lock);
> + return n;
> + }
> + }
> + mutex_unlock(&cec_notifiers_lock);
> +
> + return NULL;
This doesn't seem right. For one it doesn't act like the other cec_notifier_get*
functions in that it doesn't make a new notifier if it wasn't found yet in the
list.
For another, I think this function shouldn't be here at all. How about calling
bus_find_device_by_name(), then use cec_notifier_get_conn()?
> +}
> +EXPORT_SYMBOL_GPL(cec_notifier_get_byname);
> +
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> +{
> + struct cec_notifier *n;
> +
> + mutex_lock(&cec_notifiers_lock);
> + list_for_each_entry(n, &cec_notifiers, head) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +68,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = devm_kstrdup(dev, conn, GFP_KERNEL);
The use of devm_kstrdup worries me. The problem is that when the 'dev' device
is removed, this memory is also automatically freed. But the notifier might
still have a reference through the CEC driver, so you end up with a n->conn
pointer that points to freed memory.
I think it is better to just use kstrdup and kfree it when the last notifier
reference is released.
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..70f2974 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,6 +20,37 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> + * cec_notifier_get_byname - find a cec_notifier for the given device name
> + * and connector tuple.
> + * @name: device name that sends the events.
> + * @conn: the connector name from which the event occurs
> + *
> + * If a notifier for device @name exists, then increase the refcount and
> + * return that notifier.
> + *
> + * If it doesn't exist, return NULL
> + */
> +struct cec_notifier *cec_notifier_get_byname(const char *name,
> + const char *conn);
> +
> +/**
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> + * @dev: device that sends the events.
> + * @conn: the connector name from which t
Re: [Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector
_aspect_ratio;
>
> + /**
> + * @content_type: Connector property to control the
> + * HDMI infoframe content type setting.
> + * The %DRM_MODE_CONTENT_TYPE_\* values lowest 2 bits much
> + * match the values for &enum hdmi_content_type
> + */
> + enum hdmi_content_type content_type;
> +
> + /**
> + * @it_content: Connector property to control the
> + * HDMI infoframe it content setting(used with content type).
> + * The %DRM_MODE_CONTENT_TYPE_\* values bit 2
> + * match the values of it_content
> + */
> + bool it_content;
> +
> /**
>* @scaling_mode: Connector property to control the
>* upscaling, mostly used for built-in panels.
> @@ -1089,11 +1105,13 @@ int drm_mode_create_tv_properties(struct drm_device
> *dev,
> unsigned int num_modes,
> const char * const modes[]);
> int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> +int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mode_mask);
> int drm_connector_attach_content_protection_property(
> struct drm_connector *connector);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> +int drm_mode_create_content_type_property(struct drm_device *dev);
> int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
>
> int drm_mode_connector_set_path_property(struct drm_connector *connector,
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 33b3a96d66d0..fb45839179dd 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -726,6 +726,11 @@ struct drm_mode_config {
>* HDMI infoframe aspect ratio setting.
>*/
> struct drm_property *aspect_ratio_property;
> + /**
> + * @content_type_property: Optional connector property to control the
> + * HDMI infoframe content type setting.
> + */
> + struct drm_property *content_type_property;
> /**
>* @degamma_lut_property: Optional CRTC property to set the LUT used to
>* convert the framebuffer's colors to linear gamma.
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 50bcf4214ff9..3c234bfa80b9 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -94,6 +94,13 @@ extern "C" {
> #define DRM_MODE_PICTURE_ASPECT_4_3 1
> #define DRM_MODE_PICTURE_ASPECT_16_9 2
>
> +/* HDMI content type and itc bit bound together for simplicity */
> +#define DRM_MODE_CONTENT_TYPE_NO_DATA0
> +#define DRM_MODE_CONTENT_TYPE_GRAPHICS 4
> +#define DRM_MODE_CONTENT_TYPE_PHOTO 5
> +#define DRM_MODE_CONTENT_TYPE_CINEMA 6
> +#define DRM_MODE_CONTENT_TYPE_GAME 7
> +
> /* Aspect ratio flag bitmask (4 bits 22:19) */
> #define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19)
> #define DRM_MODE_FLAG_PIC_AR_NONE \
>
Other than that this looks good to me.
Acked-by: Hans Verkuil
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/2] i915: content-type property for HDMI connector
On 04/19/18 14:38, StanLis wrote: > From: Stanislav Lisovskiy > > Added encoding of drm content_type property from drm_connector_state > within AVI infoframe in order to properly handle external HDMI TV > content-type setting. > > This requires also manipulationg ITC bit, as stated in > HDMI spec. > > v2: > * Moved helper function which attaches content type property >to the drm core, as was suggested. >Removed redundant connector state initialization. > > v3: > * Removed caps in drm_content_type_enum_list. >After some discussion it turned out that HDMI Spec 1.4 >was wrongly assuming that IT Content(itc) bit doesn't affect >Content type states, however itc bit needs to be manupulated >as well. In order to not expose additional property for itc, >for sake of simplicity it was decided to bind those together >in same "content type" property. > > v4: > * Added it_content checking in intel_digital_connector_atomic_check. >Fixed documentation for new content type enum. > > v5: > * Moved patch revision's description to commit messages. > > Signed-off-by: Stanislav Lisovskiy Acked-by: Hans Verkuil Regards, Hans > --- > drivers/gpu/drm/i915/intel_atomic.c | 2 ++ > drivers/gpu/drm/i915/intel_hdmi.c | 4 > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c > b/drivers/gpu/drm/i915/intel_atomic.c > index 40285d1b91b7..96a42eb457c5 100644 > --- a/drivers/gpu/drm/i915/intel_atomic.c > +++ b/drivers/gpu/drm/i915/intel_atomic.c > @@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct > drm_connector *conn, > if (new_conn_state->force_audio != old_conn_state->force_audio || > new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || > new_conn_state->base.picture_aspect_ratio != > old_conn_state->base.picture_aspect_ratio || > + new_conn_state->base.content_type != > old_conn_state->base.content_type || > + new_conn_state->base.it_content != old_conn_state->base.it_content > || > new_conn_state->base.scaling_mode != > old_conn_state->base.scaling_mode) > crtc_state->mode_changed = true; > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index ee929f31f7db..078200908b7a 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct > drm_encoder *encoder, > > intel_hdmi->rgb_quant_range_selectable, > is_hdmi2_sink); > > + frame.avi.content_type = connector->state->content_type; > + frame.avi.itc = connector->state->it_content; > + > /* TODO: handle pixel repetition for YCBCR420 outputs */ > intel_write_infoframe(encoder, crtc_state, &frame); > } > @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi > *intel_hdmi, struct drm_connector *c > intel_attach_force_audio_property(connector); > intel_attach_broadcast_rgb_property(connector); > intel_attach_aspect_ratio_property(connector); > + drm_connector_attach_content_type_property(connector); > connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > } > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] i915: content-type property for HDMI connector
On 04/18/18 14:01, Lisovskiy, Stanislav wrote: > Hi, > > Please see my reply inline: > > From: dri-devel [dri-devel-boun...@lists.freedesktop.org] on behalf of Hans > Verkuil [hverk...@xs4all.nl] > Sent: Wednesday, April 18, 2018 2:35 PM > To: Lisovskiy, Stanislav; dri-de...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH v2 2/2] i915: content-type property for HDMI connector > > On 04/18/18 18:51, StanLis wrote: >> From: Stanislav Lisovskiy >> >> Added encoding of drm content_type property from >> drm_connector_state within AVI infoframe in order to properly handle >> external HDMI TV content-type setting. >> >> Signed-off-by: Stanislav Lisovskiy >> --- >> drivers/gpu/drm/i915/intel_atomic.c | 1 + >> drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ >> 2 files changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c >> b/drivers/gpu/drm/i915/intel_atomic.c >> index 40285d1b91b7..61ddb5871d8a 100644 >> --- a/drivers/gpu/drm/i915/intel_atomic.c >> +++ b/drivers/gpu/drm/i915/intel_atomic.c >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct >> drm_connector *conn, >> if (new_conn_state->force_audio != old_conn_state->force_audio || >> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || >> new_conn_state->base.picture_aspect_ratio != >> old_conn_state->base.picture_aspect_ratio || >> + new_conn_state->base.content_type != >> old_conn_state->base.content_type || >> new_conn_state->base.scaling_mode != >> old_conn_state->base.scaling_mode) >> crtc_state->mode_changed = true; >> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c >> b/drivers/gpu/drm/i915/intel_hdmi.c >> index ee929f31f7db..5cc72da9c086 100644 >> --- a/drivers/gpu/drm/i915/intel_hdmi.c >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c >> @@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct >> drm_encoder *encoder, >> >> intel_hdmi->rgb_quant_range_selectable, >> is_hdmi2_sink); >> >> + frame.avi.content_type = connector->state->content_type; >> + > >> Is the ITC bit set in the AVI InfoFrame? The content type bits are only >> valid if >> the ITC bit is 1. And if there is no content type property, then ITC should >> be 0. > > That's a good question, as I understood it is not set, however the HDMI 1.4 > spec > says: > > ITC CN1, CN0 Content Type > 00, 0 No Data > > 10, 0 IT content > > X 0, 1 Photo > X 1, 0 Cinema > X 1, 1 Game > > "X denotes don't care" > > So I wonder, should I probably add additional property to control the itc bit? Yeah, that's wrong in the HDMI Spec. The correct standard to use is the CEA (now CTA) 861. There it clearly defines that the CN bits are only valid if ITC=1. I know, I'm in the CTA-861 working group :-) I don't think anyone ever noticed this bug in the HDMI spec before (I didn't). The 2.1 HDMI spec kind of corrects it in Appendix G.1 where it copies the CTA-861-G text. Anyway, in V4L2 we implement this with an extra value "NO_ITC" which sets ITC to 0 and sets CN0 and CN1 to 0 as well: https://hverkuil.home.xs4all.nl/spec/uapi/v4l/extended-controls.html#digital-video-control-ids The NO_ITC case is usually used for YCbCr video encoding. Note that most displays will just ignore the content type. Regards, Hans > >> /* TODO: handle pixel repetition for YCBCR420 outputs */ >> intel_write_infoframe(encoder, crtc_state, &frame); >> } >> @@ -2065,6 +2067,7 @@ intel_hdmi_add_properties(struct intel_hdmi >> *intel_hdmi, struct drm_connector *c >> intel_attach_force_audio_property(connector); >> intel_attach_broadcast_rgb_property(connector); >> intel_attach_aspect_ratio_property(connector); >> + drm_connector_attach_content_type_property(connector); >> connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; >> } >> >> > > Regards, > > Hans > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm: content-type property for HDMI connector
On 04/18/18 18:51, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content_type property to
> drm_connector_state in order to properly handle
> external HDMI TV content-type setting.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> Documentation/gpu/kms-properties.csv | 1 +
> drivers/gpu/drm/drm_atomic.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 50
> drivers/gpu/drm/drm_edid.c | 1 +
> include/drm/drm_connector.h | 11 ++
> include/drm/drm_mode_config.h| 5 +++
> include/uapi/drm/drm_mode.h | 5 +++
> 7 files changed, 77 insertions(+)
>
> diff --git a/Documentation/gpu/kms-properties.csv
> b/Documentation/gpu/kms-properties.csv
> index 6b28b014cb7d..7a02b2782f33 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> Values,Object attached,De
> ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property
> to suggest an X offset for a connector
> ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest
> an Y offset for a connector
> ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""Graphics"", ""Photo"", ""Cinema"",
> ""Game"" }",Connector,TDB
> i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
> set, the hardware will be programmed with the result of the multiplication of
> CTM by the limited range matrix to ensure the pixels normaly in the range
> 0..1.0 are remapped to the range 16/255..235/255."
> ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..72fd2a1c801f 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1266,6 +1266,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->link_status = val;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + state->content_type = val;
> } else if (property == connector->scaling_mode_property) {
> state->scaling_mode = val;
> } else if (property == connector->content_protection_property) {
> @@ -1351,6 +1353,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->link_status;
> } else if (property == config->aspect_ratio_property) {
> *val = state->picture_aspect_ratio;
> + } else if (property == config->content_type_property) {
> + *val = state->content_type;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b3cde897cd80..5633494f6d78 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -720,6 +720,13 @@ static const struct drm_prop_enum_list
> drm_aspect_ratio_enum_list[] = {
> { DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
> };
>
> +static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
> + { DRM_MODE_CONTENT_TYPE_GRAPHICS, "GRAPHICS" },
> + { DRM_MODE_CONTENT_TYPE_PHOTO, "PHOTO" },
> + { DRM_MODE_CONTENT_TYPE_CINEMA, "CINEMA" },
> + { DRM_MODE_CONTENT_TYPE_GAME, "GAME" },
Just use "Graphics", "Photo", etc. Same as is used in drivers/video/hdmi.c
for logging the AVI InfoFrame.
Regards,
Hans
> +};
> +
> static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
> { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
> { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down" },
> @@ -996,6 +1003,22 @@ int drm_mode_create_dvi_i_properties(struct drm_device
> *dev)
> }
> EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
>
> +/**
> + * drm_connector_attach_content_type_property - attach content-type property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time a HDMI connector is made.
> + */
> +int drm_connector_attach_content_type_property(struct drm_connector
> *connector)
> +{
> + if (!drm_mode_create_content_type_property(connector->dev))
> + drm_object_attach_property(&connector->base,
> + connector->dev->mode_config.content_type_property,
> + DRM_MODE_CONTENT_TYPE_GRAPHICS);
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_cont
Re: [Intel-gfx] [PATCH v2 2/2] i915: content-type property for HDMI connector
On 04/18/18 18:51, StanLis wrote: > From: Stanislav Lisovskiy > > Added encoding of drm content_type property from > drm_connector_state within AVI infoframe in order to properly handle > external HDMI TV content-type setting. > > Signed-off-by: Stanislav Lisovskiy > --- > drivers/gpu/drm/i915/intel_atomic.c | 1 + > drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c > b/drivers/gpu/drm/i915/intel_atomic.c > index 40285d1b91b7..61ddb5871d8a 100644 > --- a/drivers/gpu/drm/i915/intel_atomic.c > +++ b/drivers/gpu/drm/i915/intel_atomic.c > @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct > drm_connector *conn, > if (new_conn_state->force_audio != old_conn_state->force_audio || > new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || > new_conn_state->base.picture_aspect_ratio != > old_conn_state->base.picture_aspect_ratio || > + new_conn_state->base.content_type != > old_conn_state->base.content_type || > new_conn_state->base.scaling_mode != > old_conn_state->base.scaling_mode) > crtc_state->mode_changed = true; > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index ee929f31f7db..5cc72da9c086 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct > drm_encoder *encoder, > > intel_hdmi->rgb_quant_range_selectable, > is_hdmi2_sink); > > + frame.avi.content_type = connector->state->content_type; > + Is the ITC bit set in the AVI InfoFrame? The content type bits are only valid if the ITC bit is 1. And if there is no content type property, then ITC should be 0. > /* TODO: handle pixel repetition for YCBCR420 outputs */ > intel_write_infoframe(encoder, crtc_state, &frame); > } > @@ -2065,6 +2067,7 @@ intel_hdmi_add_properties(struct intel_hdmi > *intel_hdmi, struct drm_connector *c > intel_attach_force_audio_property(connector); > intel_attach_broadcast_rgb_property(connector); > intel_attach_aspect_ratio_property(connector); > + drm_connector_attach_content_type_property(connector); > connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > } > > Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 4.16 Kernel Boot Crash
On 05/04/18 11:57, Mauro Carvalho Chehab wrote: > Em Wed, 4 Apr 2018 16:26:22 +0300 > Jaak Ristioja escreveu: > >> Hello, all! >> >> I experience the same issue with a Lenovo ThinkPad T440p (LENOVO >> 20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to >> bisect v4.15..v4.16 but failed. >> >> Best regards, >> J > > The real problem here is that the bit array is too short. > There's an additional problem at the WARN_ON() check, with lets > the code to do something that won't work. > > The enclosed patch should fix both issues. Please test. > > Regards, > Mauro > > [PATCH] media: v4l2-core: fix size of devnode_nums[] bitarray > > The size of devnode_nums[] bit array is too short to store information > for VFL_TYPE_TOUCH. That causes it to override other memory regions. > > Thankfully, on recent reports, it is overriding video_device[] array, > trigging a WARN_ON(). Yet, it just warns about the problem, but let > the code excecuting, with generates an OOPS: > > [ 43.177394] WARNING: CPU: 1 PID: 711 at > drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 > [videodev] > [ 43.177396] Modules linked in: hid_sensor_custom hid_sensor_als > hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d > hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf > joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev > hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 > snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core > snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi > snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine > snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal > snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi > snd_seq_midi_event snd_rawmidi crct10dif_pclmul > [ 43.177426] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq > aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd > snd_timer intel_cstate intel_rapl_perf input_leds serio_raw > intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop > sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal > acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid > int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp > intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev > auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 > hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev > vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper > syscopyarea sdhci_pci sysfillrect > [ 43.177466] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video > pinctrl_sunrisepoint pinctrl_intel > [ 43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1 > [ 43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 > [ 43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev] > [ 43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202 > [ 43.177484] RAX: RBX: 0005 RCX: > > [ 43.177485] RDX: c0c44cc0 RSI: RDI: > c0c44cc0 > [ 43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: > 8eda1a51f018 > [ 43.177487] R10: 0600 R11: 03b6 R12: > > [ 43.177488] R13: 0005 R14: c0c96900 R15: > 8eda1d6d91c0 > [ 43.177489] FS: 7fd2d8ef2480() GS:8eda3348() > knlGS: > [ 43.177490] CS: 0010 DS: ES: CR0: 80050033 > [ 43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: > 003606e0 > [ 43.177492] Call Trace: > [ 43.177498] ? devres_add+0x5f/0x70 > [ 43.177502] rmi_f54_probe+0x437/0x470 [rmi_core] > [ 43.177505] rmi_function_probe+0x25/0x30 [rmi_core] > [ 43.177507] driver_probe_device+0x310/0x480 > [ 43.177509] __device_attach_driver+0x86/0x100 > [ 43.177511] ? __driver_attach+0xf0/0xf0 > [ 43.177512] bus_for_each_drv+0x6b/0xb0 > [ 43.177514] __device_attach+0xdd/0x160 > [ 43.177516] device_initial_probe+0x13/0x20 > [ 43.177518] bus_probe_device+0x95/0xa0 > [ 43.177519] device_add+0x44b/0x680 > [ 43.177522] rmi_register_function+0x62/0xd0 [rmi_core] > [ 43.177525] rmi_create_function+0x112/0x1a0 [rmi_core] > [ 43.177527] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] > [ 43.177530] rmi_scan_pdt+0xca/0x1a0 [rmi_core] > [ 43.177535] rmi_init_functions+0x5b/0x120 [rmi_core] > [ 43.177537] rmi_driver_probe+0x152/0x3c0 [rmi_core] > [ 43.177547] ? sysfs_create_link+0x25/0x40 > [ 43.177549] driver_probe_device+0x310/0x480 > [ 43.177551] __device_attach_driver+0x86/0x100 > [ 43.177553
Re: [Intel-gfx] [PULL] drm/i915: Add HDCP support to i915
On 14/02/18 14:44, Sean Paul wrote: > On Wed, Feb 14, 2018 at 3:33 AM, Hans Verkuil wrote: >> Hi Sean, >> >> On 13/02/18 21:18, Sean Paul wrote: >>> >>> Hi Dave, >>> Here's the pull request for HDCP. Hopefully no surprises since it's been >>> baking >>> in drm-tip for a while now. >>> >>> topic/hdcp-2018-02-13: >>> Add HDCP support to i915 drm driver. >>> >>> Cheers, Sean >>> >>> >>> The following changes since commit b0caa1333b6d2d928a00304e9fb6674526c37b79: >>> >>> Merge tag 'imx-drm-next-2018-01-02' of >>> git://git.pengutronix.de/git/pza/linux into drm-next (2018-01-05 11:33:24 >>> +1000) >>> >>> are available in the Git repository at: >>> >>> git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdcp-2018-02-13 >>> >>> for you to fetch changes up to 2834d9dfaf0276e197158be6af8e1a1d59e58289: >>> >>> drm/i915: fix misalignment in HDCP register def (2018-02-05 12:59:29 >>> -0500) >>> >>> >>> Add HDCP support to i915 drm driver. >>> >>> >>> Chris Wilson (1): >>> drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link >>> >>> Ramalingam C (12): >>> drm/i915: Extending HDCP for HSW, BDW and BXT+ >>> drm/i915: II stage HDCP auth for repeater only >>> drm/i915: Start repeater auth on READY/CP_IRQ >>> drm/i915: Check for downstream topology errors >>> drm/i915: Handle failure from 2nd stage HDCP auth >>> drm/i915: Stop encryption for repeater with no sink >>> drm/i915: Connector info in HDCP debug msgs >>> drm/i915: Retry HDCP bksv read >>> drm/i915: Optimize HDCP key load >>> drm/i915: Detect panel's hdcp capability >>> drm/i915: Reauthenticate HDCP on failure >>> drm/i915: fix misalignment in HDCP register def >> >> Were these ever posted to dri-devel? I can't find them there. >> >> Do these patches from Ramalingam C add repeater support to the i915? >> If so, then I am certainly interested in seeing these since we (Cisco) >> are working on HDCP (including repeater support) for HDMI receivers. >> > > Hi Hans! > We had a conversation on these patches and repeater support when I > initially posted them :-) > https://lists.freedesktop.org/archives/intel-gfx/2017-December/149112.html Yes, your patches I've seen, but the 12 from Ramalingam I haven't seen. At least not on dri-devel. It's a bit weird. Regards, Hans > > It'd be great if you could try it out and report back. > > Cheers, > > Sean > >> Nothing public yet, it's too early for that. But it would be nice to >> test with the i915 driver. >> >> Regards, >> >> Hans >> >>> >>> Sean Paul (13): >>> drm: Fix link-status kerneldoc line lengths >>> drm/i915: Add more control to wait_for routines >>> drm: Add Content Protection property >>> drm: Add some HDCP related #defines >>> drm/i915: Add HDCP framework + base implementation >>> drm/i915: Make use of indexed write GMBUS feature >>> drm/i915: Add function to output Aksv over GMBUS >>> drm/i915: Implement HDCP for HDMI >>> drm/i915: Implement HDCP for DisplayPort >>> drm/i915: Don't allow HDCP on PORT E/F >>> drm/i915: Only disable HDCP when it's active >>> drm/i915: Restore HDCP DRM_INFO when with no downstream >>> drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS >>> >>> drivers/gpu/drm/drm_atomic.c | 8 + >>> drivers/gpu/drm/drm_connector.c | 87 +++- >>> drivers/gpu/drm/i915/Makefile| 1 + >>> drivers/gpu/drm/i915/i915_drv.h | 1 + >>> drivers/gpu/drm/i915/i915_reg.h | 86 >>> drivers/gpu/drm/i915/intel_atomic.c | 2 + >>> drivers/gpu/drm/i915/intel_ddi.c | 36 ++ >>> drivers/gpu/drm/i915/intel_display.c | 4 + >>> drivers/gpu/drm/i915/intel_dp.c | 277 +++- >>> drivers/gpu/drm/i915/intel_drv.h | 109 - >>> drivers/gpu/drm/i915/intel_hdcp.c| 807 >>> +++ >>> drivers/gpu/drm/i915/intel_hdmi.c| 250 +++ >>> drivers/gpu/drm/i915/intel_i2c.c | 81 +++- >>> drivers/gpu/drm/i915/intel_uncore.c | 23 +- >>> drivers/gpu/drm/i915/intel_uncore.h | 14 +- >>> include/drm/drm_connector.h | 16 + >>> include/drm/drm_dp_helper.h | 17 + >>> include/drm/drm_hdcp.h | 41 ++ >>> include/uapi/drm/drm_mode.h | 4 + >>> 19 files changed, 1821 insertions(+), 43 deletions(-) >>> create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c >>> create mode 100644 include/drm/drm_hdcp.h >>> >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm/i915: Add HDCP support to i915
Hi Sean, On 13/02/18 21:18, Sean Paul wrote: > > Hi Dave, > Here's the pull request for HDCP. Hopefully no surprises since it's been > baking > in drm-tip for a while now. > > topic/hdcp-2018-02-13: > Add HDCP support to i915 drm driver. > > Cheers, Sean > > > The following changes since commit b0caa1333b6d2d928a00304e9fb6674526c37b79: > > Merge tag 'imx-drm-next-2018-01-02' of > git://git.pengutronix.de/git/pza/linux into drm-next (2018-01-05 11:33:24 > +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdcp-2018-02-13 > > for you to fetch changes up to 2834d9dfaf0276e197158be6af8e1a1d59e58289: > > drm/i915: fix misalignment in HDCP register def (2018-02-05 12:59:29 -0500) > > > Add HDCP support to i915 drm driver. > > > Chris Wilson (1): > drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link > > Ramalingam C (12): > drm/i915: Extending HDCP for HSW, BDW and BXT+ > drm/i915: II stage HDCP auth for repeater only > drm/i915: Start repeater auth on READY/CP_IRQ > drm/i915: Check for downstream topology errors > drm/i915: Handle failure from 2nd stage HDCP auth > drm/i915: Stop encryption for repeater with no sink > drm/i915: Connector info in HDCP debug msgs > drm/i915: Retry HDCP bksv read > drm/i915: Optimize HDCP key load > drm/i915: Detect panel's hdcp capability > drm/i915: Reauthenticate HDCP on failure > drm/i915: fix misalignment in HDCP register def Were these ever posted to dri-devel? I can't find them there. Do these patches from Ramalingam C add repeater support to the i915? If so, then I am certainly interested in seeing these since we (Cisco) are working on HDCP (including repeater support) for HDMI receivers. Nothing public yet, it's too early for that. But it would be nice to test with the i915 driver. Regards, Hans > > Sean Paul (13): > drm: Fix link-status kerneldoc line lengths > drm/i915: Add more control to wait_for routines > drm: Add Content Protection property > drm: Add some HDCP related #defines > drm/i915: Add HDCP framework + base implementation > drm/i915: Make use of indexed write GMBUS feature > drm/i915: Add function to output Aksv over GMBUS > drm/i915: Implement HDCP for HDMI > drm/i915: Implement HDCP for DisplayPort > drm/i915: Don't allow HDCP on PORT E/F > drm/i915: Only disable HDCP when it's active > drm/i915: Restore HDCP DRM_INFO when with no downstream > drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS > > drivers/gpu/drm/drm_atomic.c | 8 + > drivers/gpu/drm/drm_connector.c | 87 +++- > drivers/gpu/drm/i915/Makefile| 1 + > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 86 > drivers/gpu/drm/i915/intel_atomic.c | 2 + > drivers/gpu/drm/i915/intel_ddi.c | 36 ++ > drivers/gpu/drm/i915/intel_display.c | 4 + > drivers/gpu/drm/i915/intel_dp.c | 277 +++- > drivers/gpu/drm/i915/intel_drv.h | 109 - > drivers/gpu/drm/i915/intel_hdcp.c| 807 > +++ > drivers/gpu/drm/i915/intel_hdmi.c| 250 +++ > drivers/gpu/drm/i915/intel_i2c.c | 81 +++- > drivers/gpu/drm/i915/intel_uncore.c | 23 +- > drivers/gpu/drm/i915/intel_uncore.h | 14 +- > include/drm/drm_connector.h | 16 + > include/drm/drm_dp_helper.h | 17 + > include/drm/drm_hdcp.h | 41 ++ > include/uapi/drm/drm_mode.h | 4 + > 19 files changed, 1821 insertions(+), 43 deletions(-) > create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c > create mode 100644 include/drm/drm_hdcp.h > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property
On 12/05/2017 06:15 AM, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be
> implemented
> by the driver using HDCP.
>
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
>
> The driver is responsible for downgrading ENABLED to DESIRED if the link
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.
>
> If this looks familiar, I posted [1] this 3 years ago. We have been using this
> in ChromeOS across exynos, mediatek, and rockchip over that time.
>
> Changes in v2:
> - Pimp kerneldoc for content_protection_property (Daniel)
> - Drop sysfs attribute
> Changes in v3:
> - None
>
> Cc: Daniel Vetter
> Signed-off-by: Sean Paul
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> ---
> drivers/gpu/drm/drm_atomic.c| 8 +
> drivers/gpu/drm/drm_connector.c | 71
> +
> drivers/gpu/drm/drm_sysfs.c | 1 +
> include/drm/drm_connector.h | 16 ++
> include/uapi/drm/drm_mode.h | 4 +++
> 5 files changed, 100 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..676025d755b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->picture_aspect_ratio = val;
> } else if (property == connector->scaling_mode_property) {
> state->scaling_mode = val;
> + } else if (property == connector->content_protection_property) {
> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> + return -EINVAL;
> + }
> + state->content_protection = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->picture_aspect_ratio;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> + } else if (property == connector->content_protection_property) {
> + *val = state->content_protection;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f14b48e6e839..8626aa8f485e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
> /**
> * DOC: standard connector properties
> *
> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> * after modeset, the kernel driver may set this to "BAD" and issue a
> * hotplug uevent. Drivers should update this value using
> * drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + * This property is used by userspace to request the kernel protect future
> + * content communicated over the link. When requested, kernel will apply
> + * the appropriate means of protection (most often HDCP), and use the
> + * property to tell userspace the protection is active.
> + *
> + * The value of this property can be one of the following:
> + *
> + * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> + * The link is not protected, content is transmitted in the clear.
> + * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> + * Userspace has requested content protection, but the link is not
> + * currently protected. When in this state, kernel should enable
> + * Content Protection as soon as possible.
> + * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
> + * Userspace has requested content protection, and the link is
> + * protected. Only the driver can set the property to this value.
Re: [Intel-gfx] [PATCH v2 0/8] drm/i915: Implement HDCP
Hi Sean, On 12/01/2017 06:20 PM, Sean Paul wrote: > Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO > list I set out in the first version (Annotated below for convenience). > > The big changes to take note of in v2 is locking. To account for atomic async > + > the property's mutability, I'm using a dedicated mutex and moved property > setting on the kernel side to the worker. I think this is actually a lot > easier > to read, and it opens the door to future improvements such as not doing the > enable/disable via modeset. > > TODO: > - DONE: Add kerneldoc for property > - DONE: Fix '//' comments > - DONE: Change to MIT license > - DONE: Improve documentation on drm_intel_hdcp_shim > - DONE: Fix async commit locking (ie: don't use connection_mutex) > - DONE: Don't change connector->state in enable, defer to worker > - Rebase on Ville's gmbus fixes (thanks Ville) > - Looks like these haven't landed, but I've rebased on drm-intel-next > - Add igt coverage for the feature. > - Working on this now Looking at this patch series it seems that there is no drm support to get the BKSV from the i915, right? If you want to use the i915 (or any HDMI/DP output) in a repeater scenario then userspace has to be able to obtain that information so it can be added to the BKSV of the HDMI receiver. For the record, the V4L2 subsystem used by HDMI receivers doesn't support HDCP yet, although patches exist. I can understand that you are not (yet) adding repeater support, but it should be documented somewhere in the patch series that this is not there yet and that a standard DRM API would be needed to obtain the BKSV from the transmitter. Second question: has this been tested with a MST hub? Regards, Hans > > Thanks! > > Sean > > Sean Paul (8): > drm: Fix link-status kerneldoc line lengths > drm/i915: Add more control to wait_for routines > drm: Add Content Protection property > drm: Add some HDCP related #defines > drm/i915: Add HDCP framework + base implementation > drm/i915: Add function to output Aksv over GMBUS > drm/i915: Implement HDCP for HDMI > drm/i915: Implement HDCP for DisplayPort > > drivers/gpu/drm/drm_atomic.c| 8 + > drivers/gpu/drm/drm_connector.c | 80 - > drivers/gpu/drm/drm_sysfs.c | 1 + > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 85 + > drivers/gpu/drm/i915/intel_atomic.c | 26 +- > drivers/gpu/drm/i915/intel_ddi.c| 64 > drivers/gpu/drm/i915/intel_dp.c | 245 - > drivers/gpu/drm/i915/intel_drv.h| 98 +- > drivers/gpu/drm/i915/intel_hdcp.c | 684 > > drivers/gpu/drm/i915/intel_hdmi.c | 254 + > drivers/gpu/drm/i915/intel_i2c.c| 54 ++- > drivers/gpu/drm/i915/intel_uncore.c | 23 +- > drivers/gpu/drm/i915/intel_uncore.h | 14 +- > include/drm/drm_connector.h | 16 + > include/drm/drm_dp_helper.h | 17 + > include/drm/drm_hdcp.h | 56 +++ > include/uapi/drm/drm_mode.h | 4 + > 19 files changed, 1697 insertions(+), 34 deletions(-) > create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c > create mode 100644 include/drm/drm_hdcp.h > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] video/hdmi: Pass buffer size to infoframe unpack functions
On 11/13/2017 06:04 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make sure the infoframe unpack functions don't end up examining
> stack garbage or oopsing, let's pass in the size of the buffer.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/media/i2c/adv7511.c | 2 +-
> drivers/media/i2c/adv7604.c | 2 +-
> drivers/media/i2c/adv7842.c | 2 +-
> drivers/media/i2c/tc358743.c | 2 +-
> drivers/video/hdmi.c | 51
>
> include/linux/hdmi.h | 2 +-
> 6 files changed, 42 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
> index 2817bafc67bf..dec09c18ea34 100644
> --- a/drivers/media/i2c/adv7511.c
> +++ b/drivers/media/i2c/adv7511.c
> @@ -562,7 +562,7 @@ static void log_infoframe(struct v4l2_subdev *sd, const
> struct adv7511_cfg_read_
> buffer[3] = 0;
> buffer[3] = hdmi_infoframe_checksum(buffer, len + 4);
>
> - if (hdmi_infoframe_unpack(&frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index f289b8aca1da..8500438af0d3 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -2429,7 +2429,7 @@ static int adv76xx_read_infoframe(struct v4l2_subdev
> *sd, int index,
> buffer[i + 3] = infoframe_read(sd,
> adv76xx_cri[index].payload_addr + i);
>
> - if (hdmi_infoframe_unpack(frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
>adv76xx_cri[index].desc);
> return -ENOENT;
> diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
> index 65f34e7e146f..fd5d5e84dcbf 100644
> --- a/drivers/media/i2c/adv7842.c
> +++ b/drivers/media/i2c/adv7842.c
> @@ -2576,7 +2576,7 @@ static void log_infoframe(struct v4l2_subdev *sd,
> struct adv7842_cfg_read_infofr
> for (i = 0; i < len; i++)
> buffer[i + 3] = infoframe_read(sd, cri->payload_addr + i);
>
> - if (hdmi_infoframe_unpack(&frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index e6f5c363ccab..f6a5ebffd9c6 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -453,7 +453,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
>
> i2c_rd(sd, PK_AVI_0HEAD, buffer, HDMI_INFOFRAME_SIZE(AVI));
>
> - if (hdmi_infoframe_unpack(&frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of AVI infoframe failed\n", __func__);
> return;
> }
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 65b915ea4936..b5d491014b0b 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1005,8 +1005,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
>
> /**
> * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe
> - * @buffer: source buffer
> * @frame: HDMI AVI infoframe
> + * @buffer: source buffer
> + * @size: size of buffer
> *
> * Unpacks the information contained in binary @buffer into a structured
> * @frame of the HDMI Auxiliary Video (AVI) information frame.
> @@ -1016,11 +1017,14 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame,
> - const void *buffer)
> + const void *buffer, size_t size)
> {
> const u8 *ptr = buffer;
> int ret;
>
> + if (size < HDMI_INFOFRAME_SIZE(AVI))
> + return -EINVAL;
> +
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
> ptr[1] != 2 ||
> ptr[2] != HDMI_AVI_INFOFRAME_SIZE)
> @@ -1068,8 +1072,9 @@ static int hdmi_avi_infoframe_unpack(struct
> hdmi_avi_infoframe *frame,
>
> /**
>
Re: [Intel-gfx] [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On 05/31/2017 01:57 AM, Clint Taylor wrote: On 05/26/2017 12:18 AM, Daniel Vetter wrote: On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote: From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even though a CEC device is created, it may not actually work. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/Kconfig | 3 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_dp_cec.c | 196 +++ include/drm/drm_dp_helper.h | 24 ++ 4 files changed, 224 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_cec.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 78d7fc0ebb57..dd771ce8a3d0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE default case is N. Details and instructions how to build your own EDID data are given in Documentation/EDID/HOWTO.txt. +config DRM_DP_CEC + bool We generally don't bother with a Kconfig for every little bit in drm, not worth the trouble (yes I know there's some exceptions, but somehow they're all from soc people). Just smash this into the KMS_HELPER one and live is much easier for drivers. Also allows you to drop the dummy inline functions. All of the functions like cec_register_adapter() require CONFIG_MEDIA_CEC_SUPPORT. This will add a new dependency to the DRM drivers. All instances of CONFIG_DRM_DP_CEC should be changed to CONFIG_MEDIA_CEC_SUPPORT so drm can still be used without the media CEC drivers. This has changed in the next version. I realized the same thing and there are CEC core patches pending for 4.12 to solve this. I plan on posting a new patch series for this later this week, and that will include those patches for 4.12 so it is easier to test this. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/31/2017 01:25 AM, Clint Taylor wrote: On 05/30/2017 02:29 PM, Hans Verkuil wrote: On 05/30/2017 10:32 PM, Clint Taylor wrote: On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. What is the output of: dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48 od -t x1 aux0 Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC. If the first byte is != 0x00, then it advertises CEC over Aux. For me it says 0x00. When you say "it does support CEC over Aux", does that mean you have actually tested it somehow? The only working solution I have seen mentioned for the NUC6i7KYK is a Pulse-Eight adapter. With the NUC7i Intel made BIOS support for CEC, but it is not at all clear to me if they used CEC tunneling or just hooked up the CEC pin to some microcontroller. The only working chipset I have seen is the Parade PS176. If it really is working on your NUC, then can you add the output of /sys/kernel/debug/dri/0/i915_display_info? [root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info Connector info -- connector 48: type DP-1, status: connected name: physical dimensions: 700x400mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: 175IB0 HW: 1.0 SW: 7.32 Max TMDS clock: 60 kHz Max bpc: 12 Huh. Based on this document: https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf this is the internal DP-to-HDMI adapter and it has the PS175. So it is a Parade chipset, and I have seen that work before (at least the PS176). This is the PS175 LSPCON on the NUC6. connector 55: type DP-2, status: connected name: physical dimensions: 620x340mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: BCTRC0 HW: 2.0 SW: 0.26 And is this from a USB-C to HDMI adapter? Which one? I don't recognize the ID. This is a LSPCON inside the Google USB-C->HDMI dongle. This is actually a MC2850 with what appears to be a custom ID. Datasheet claims CEC over Aux and the pin is wired, but FW has it currently disabled. OK, in other words the Parade chipsets work and the Megachip chipsets don't. And Intel in their wisdom decided to go with Megachip for the new NUCs. I have no idea if you have any ins with the NUC team, but it would be so nice if there would be a Megachip firmware update enabling this feature. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 10:32 PM, Clint Taylor wrote: On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. What is the output of: dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48 od -t x1 aux0 Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC. If the first byte is != 0x00, then it advertises CEC over Aux. For me it says 0x00. When you say "it does support CEC over Aux", does that mean you have actually tested it somehow? The only working solution I have seen mentioned for the NUC6i7KYK is a Pulse-Eight adapter. With the NUC7i Intel made BIOS support for CEC, but it is not at all clear to me if they used CEC tunneling or just hooked up the CEC pin to some microcontroller. The only working chipset I have seen is the Parade PS176. If it really is working on your NUC, then can you add the output of /sys/kernel/debug/dri/0/i915_display_info? [root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info Connector info -- connector 48: type DP-1, status: connected name: physical dimensions: 700x400mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: 175IB0 HW: 1.0 SW: 7.32 Max TMDS clock: 60 kHz Max bpc: 12 Huh. Based on this document: https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf this is the internal DP-to-HDMI adapter and it has the PS175. So it is a Parade chipset, and I have seen that work before (at least the PS176). connector 55: type DP-2, status: connected name: physical dimensions: 620x340mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: BCTRC0 HW: 2.0 SW: 0.26 And is this from a USB-C to HDMI adapter? Which one? I don't recognize the ID. For the record, this is the internal HDMI output of my NUC7i5BNK: connector 48: type DP-1, status: connected name: physical dimensions: 1050x590mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: MC2800 HW: 2.2 SW: 1.66 Max TMDS clock: 60 kHz Max bpc: 16 Clearly a Megachip. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. What is the output of: dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48 od -t x1 aux0 Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC. If the first byte is != 0x00, then it advertises CEC over Aux. For me it says 0x00. When you say "it does support CEC over Aux", does that mean you have actually tested it somehow? The only working solution I have seen mentioned for the NUC6i7KYK is a Pulse-Eight adapter. With the NUC7i Intel made BIOS support for CEC, but it is not at all clear to me if they used CEC tunneling or just hooked up the CEC pin to some microcontroller. The only working chipset I have seen is the Parade PS176. If it really is working on your NUC, then can you add the output of /sys/kernel/debug/dri/0/i915_display_info? Thanks, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. What is the output of: dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48 od -t x1 aux0 Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC. If the first byte is != 0x00, then it advertises CEC over Aux. For me it says 0x00. When you say "it does support CEC over Aux", does that mean you have actually tested it somehow? The only working solution I have seen mentioned for the NUC6i7KYK is a Pulse-Eight adapter. With the NUC7i Intel made BIOS support for CEC, but it is not at all clear to me if they used CEC tunneling or just hooked up the CEC pin to some microcontroller. The only working chipset I have seen is the Parade PS176. Regards, Hans -Clint BR, Jani. It would be so nice to get MegaChip CEC Tunneling working on the NUC, because then you have native CEC support without requiring any Pulse Eight adapter. And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C output as well. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It would be so nice to get MegaChip CEC Tunneling working on the NUC, because then you have native CEC support without requiring any Pulse Eight adapter. And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C output as well. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On 05/26/2017 09:18 AM, Daniel Vetter wrote: > On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> This adds support for the DisplayPort CEC-Tunneling-over-AUX >> feature that is part of the DisplayPort 1.3 standard. >> >> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a >> chip that has this capability actually hook up the CEC pin, so >> even though a CEC device is created, it may not actually work. >> >> Signed-off-by: Hans Verkuil >> --- >> drivers/gpu/drm/Kconfig | 3 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/drm_dp_cec.c | 196 >> +++ >> include/drm/drm_dp_helper.h | 24 ++ >> 4 files changed, 224 insertions(+) >> create mode 100644 drivers/gpu/drm/drm_dp_cec.c >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 78d7fc0ebb57..dd771ce8a3d0 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE >>default case is N. Details and instructions how to build your own >>EDID data are given in Documentation/EDID/HOWTO.txt. >> >> +config DRM_DP_CEC >> +bool > > We generally don't bother with a Kconfig for every little bit in drm, not > worth the trouble (yes I know there's some exceptions, but somehow they're > all from soc people). Just smash this into the KMS_HELPER one and live is > much easier for drivers. Also allows you to drop the dummy inline > functions. For all other CEC implementations I have placed it under a config option. The reason is that 1) CEC is an optional feature of HDMI and you may not actually want it, and 2) enabling CEC also pulls in the cec module. I still think turning this into a drm config option makes sense. This would replace the i915 config option I made in the next patch, i.e. this config option is moved up one level. Your choice, though. > The other nitpick: Pls kernel-doc the functions exported to drivers, and > then pull them into Documentation/gpu/drm-kms-helpers.rst, next to the > existing DP helper section. Will do. BTW, do you know if it is possible to detect when a DP-to-HDMI adapter is connected as I discussed in my cover letter? That's my main open question for this patch series. Regarding the other thing I discussed in the cover letter about detecting if the CEC pin is really hooked up: I think I shouldn't try to be smart. Yes, I can try to poll for a TV, but that doesn't really say anything about whether CEC is working or not since the TV itself may not have enabled CEC (actually quite common). One alternative might be to poll and, if no TV is detected, call dev_info to let the user know that either there is no CEC-enabled TV, or the CEC pin isn't connected. I'm not sure if that helps the user or not. Regards, Hans > > Thanks, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Implement support for this DisplayPort feature.
>>
>> The cec device is created whenever it detects an adapter that
>> has this feature. It is only removed when a new adapter is connected
>> that does not support this. If a new adapter is connected that has
>> different properties than the previous one, then the old cec device is
>> unregistered and a new one is registered to replace the old one.
>>
>> Signed-off-by: Hans Verkuil
>
> Some small comments below.
>
>> ---
>> drivers/gpu/drm/i915/Kconfig| 11 ++
>> drivers/gpu/drm/i915/intel_dp.c | 46
>> +
>> 2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index a5cd5dacf055..f317b13a1409 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
>>Choose this option if you want to enable KVMGT support for
>>Intel GVT-g.
>>
>> +config DRM_I915_DP_CEC
>> +tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
>> +depends on DRM_I915 && CEC_CORE
>> +select DRM_DP_CEC
>> +help
>> + Choose this option if you want to enable HDMI CEC support for
>> + DisplayPort/USB-C to HDMI adapters.
>> +
>> + Note: not all adapters support this feature, and even for those
>> + that do support this often do not hook up the CEC pin.
>
> Why Kconfig? There's not anything else optional in i915.ko (except debug
> stuff ofc), since generally just not worth the pain. Also doesn't seem to
> be wired up at all :-)
It selects DRM_DP_CEC, but you're right, it can be dropped.
>
>> +
>> menu "drm/i915 Debugging"
>> depends on DRM_I915
>> depends on EXPERT
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index ee77b519835c..38e17ee2548d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -32,6 +32,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp
>> *intel_dp)
>> static void
>> intel_dp_aux_fini(struct intel_dp *intel_dp)
>> {
>> +cec_unregister_adapter(intel_dp->aux.cec_adap);
>> kfree(intel_dp->aux.name);
>> }
>>
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> +bool handled = false;
>> +
>> +for (;;) {
>> +u8 cec_irq;
>> +int ret;
>> +
>> +ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> +DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> +&cec_irq);
>> +if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> +return handled;
>> +
>> +cec_irq &= ~DP_CEC_IRQ;
>> +drm_dp_cec_irq(&intel_dp->aux);
>> +handled = true;
>> +
>> +ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> +if (ret < 0)
>> +return handled;
>> +}
>> +}
>
> Shouldn't the above be a helper in the cec library? Doesn't look i915
> specific to me at least ...
Good point, this can be moved to drm_dp_cec_irq().
>
>> +
>> static void
>> intel_dp_retrain_link(struct intel_dp *intel_dp)
>> {
>> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
>> else
>> intel_dp->has_audio = drm_detect_monitor_audio(edid);
>> +cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>> }
>>
>> static void
>> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>>
>> kfree(intel_connector->detect_edid);
>> intel_connec
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/26/2017 12:13 PM, Jani Nikula wrote:
> On Thu, 25 May 2017, Hans Verkuil wrote:
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> +bool handled = false;
>> +
>> +for (;;) {
>> +u8 cec_irq;
>> +int ret;
>> +
>> +ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> +DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> +&cec_irq);
>> +if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> +return handled;
>> +
>> +cec_irq &= ~DP_CEC_IRQ;
>> +drm_dp_cec_irq(&intel_dp->aux);
>> +handled = true;
>> +
>> +ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> +if (ret < 0)
>> +return handled;
>> +}
>
> DP sinks suck. Please add a limit to the loop.
Good to know. I wondered about that.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
On 05/25/2017 05:30 PM, Mike Lothian wrote:
> Hi
>
> Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
> connector and no displayport
>
> Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
> based on your testing?
>
> I've been putting off buying one until I knew 4K@60Hz would work, CEC would
> be nice to have too
We have done a lot of testing of USB-C to HDMI adapters and many are awful.
Admittedly, we have a special requirement that the adapter shouldn't enable
HDCP if
the sink doesn't support HDCP. For whatever reason many of these adapters
enable HDCP
regardless, making them useless for video conferencing where you are not
allowed to
share HDCP encrypted video. Besides that issue many also have bad signal
integrity
or the voltage of the 5V pin is below the allowed minimum voltage.
The best is the Club 3D CAC-1504, but that is one that doesn't hook up the
CEC pin :-( That's a shame since this one was fully within the HDMI
specifications.
If you want CEC, then the Samsung EE-PW700 is best.
BTW, the Kramer adapter I mentioned below is indeed the ADC-U31C/HF model.
There are some more adapters that I can test next week, and I'll see if I can
also
test a bunch of (mini-)DP to HDMI adapters.
Regards,
Hans
>
> Thanks
>
> Mike
>
> On Thu, 25 May 2017 at 16:06 Hans Verkuil <mailto:hverk...@xs4all.nl>> wrote:
>
> From: Hans Verkuil <mailto:hans.verk...@cisco.com>>
>
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> protocol.
>
> This patch series is based on v4.12-rc2.
>
> The first four patches add support for a new CEC capability which is
> needed for these devices and for two helper functions.
>
> Then the DP CEC registers are added using Clint's patch.
>
> The core CEC tunneling support is added to drm_dp_cec.c.
>
> And finally this is hooked up in the i915 driver.
>
> Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
> adapter is connected/disconnected, but I have not been a able to find
> a way to distinguish between connecting/disconnecting the HDMI cable
> and connecting/disconnecting the actual DP-to-HDMI adapter.
>
> My current approach is to check the CEC tunneling support whenever a new
> display is connected:
>
> - if CEC tunneling is supported, but no CEC adapter exists, then create
> one.
> - if CEC tunneling is not supported, then unregister the CEC adapter if
> one
> was created earlier.
> - if CEC tunneling is supported and the capabilities are identical to the
> existing CEC adapter, then leave it be.
> - if CEC tunneling is supported and the capabilities are different to the
> existing CEC adapter, then unregister that CEC adapter and register a
> new one.
>
> This works well, but it would be much nicer if I would just know when the
> DP adapter is disconnected as opposed to when the HDMI cable is
> disconnected
> from the adapter. Suggestions are welcome.
>
> The other remaining problem is that there are DP/USB-C to HDMI adapters
> that
> support CEC tunneling in the chipset, but where the CEC pin is simply
> never
> hooked up. From the point of view of the driver CEC is supported, but
> you'll
> never see any other devices.
>
> I am considering sending a CEC POLL message to logical address 0 (the TV)
> to detect if the CEC pin is connected, but this is not 100% guaranteed to
> work. This can be put under a kernel config option, though.
>
> I think I need to do something for this since of the 5 USB-C to HDMI
> adapters I've tested that set the CEC tunneling capability, only 2 have
> the CEC pin hooked up. So this seems to be quite common.
>
> I have tested this with my Intel NUC7i5BNK and with the two working
> USB-C to HDMI adapters that I have found:
>
> a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think
> that's
> the model, I need to confirm this).
>
> As usual the specifications of these adapters never, ever tell you whether
> this is supported or not :-( It's trial and error to find one that works.
> In
> fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC
> tunneling
> at all, and of the remaining 5 only two had the CEC pin hooked up and so
> actually worked.
>
> BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.
>
> Output of cec-ctl -S (discovers the CEC topology):
>
> $ cec-ctl -S
> Driver Inf
