Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
On 04/05/2017 02:41 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build
> (arm_multi_v7_defconfig) produced this warning:
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning:
> 'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function]
> static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
> ^
>
> Introduced by commit
>
> def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
> encodings")
>
Hi,
I'm preparing a fix for that, sorry for the noise.
Thanks,
Neil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm: Extract drm_ioctl.h
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > To match the drm_ioctl.c we already have. > > v2: Remove spurious space (Ville). > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> > Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > include/drm/drmP.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > index e1daa4f343cd..a5ddc2815bf4 100644 > --- a/include/drm/drmP.h > +++ b/include/drm/drmP.h > @@ -81,6 +81,7 @@ > #include > #include > #include > +#include > > struct module; > > Reviewed-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm: Consolidate and document sysfs support
r - Register a struct device in the drm class.
> + * drm_class_device_register - register new device with the DRM sysfs class
> + * @dev: device to register
> *
> - * @dev: pointer to struct device to register.
> - *
> - * @dev should have all relevant members pre-filled with the exception
> - * of the class member. In particular, the device_type member must
> - * be set.
> + * Registers a new device within the DRM sysfs class. Essentially
> only
> + * used by ttm to have a place for its global settings. Drivers should never
> use
> + * this.
> */
> -
> int drm_class_device_register(struct device *dev)
> {
> if (!drm_class || IS_ERR(drm_class))
> @@ -403,6 +379,14 @@ int drm_class_device_register(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(drm_class_device_register);
>
> +/**
> + * drm_class_device_unregister - unregister device with the DRM sysfs class
> + * @dev: device to unregister
> + *
> + * Unregisters a device from the DRM sysfs class. Essentially only
> used
> + * by ttm to have a place for its global settings. Drivers should never use
> + * this.
> + */
> void drm_class_device_unregister(struct device *dev)
> {
> return device_unregister(dev);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 3bfafcdb8710..e1daa4f343cd 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -80,6 +80,7 @@
> #include
> #include
> #include
> +#include
>
> struct module;
>
> @@ -512,10 +513,6 @@ static inline int drm_device_is_unplugged(struct
> drm_device *dev)
> * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
> */
>
> -/* sysfs support (drm_sysfs.c) */
> -extern void drm_sysfs_hotplug_event(struct drm_device *dev);
> -
> -
> /*@}*/
>
> /* returns true if currently okay to sleep */
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 23418c1f10d1..70c9a1074aca 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -1,12 +1,12 @@
> #ifndef _DRM_SYSFS_H_
> #define _DRM_SYSFS_H_
>
> -/**
> - * This minimalistic include file is intended for users (read TTM) that
> - * don't want to include the full drmP.h file.
> - */
> +struct drm_device;
> +struct device;
>
> int drm_class_device_register(struct device *dev);
> void drm_class_device_unregister(struct device *dev);
>
> +void drm_sysfs_hotplug_event(struct drm_device *dev);
> +
> #endif
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm: document drm_ioctl.[hc]
> - * \param cmd command.
> - * \param arg argument.
> + * This is the DRM ioctl typedef. Note that drm_ioctl() has alrady copied
> @data
> + * into kernel-space, and will also copy it back, depending upon the
> read/write
> + * settings in the ioctl command code.
> */
> typedef int drm_ioctl_t(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
>
> +/**
> + * drm_ioctl_compat_t - compatibility DRM ioctl function type.
> + * @filp: file pointer
> + * @cmd: ioctl command code
> + * @arg: DRM file this ioctl was made on
> + *
> + * Just a typedef to make declaring an array of compatibility handlers
> easier.
> + * New drivers shouldn't screw up the structure layout for their ioctl
> + * structures and hence never need this.
> + */
> typedef int drm_ioctl_compat_t(struct file *filp, unsigned int cmd,
> unsigned long arg);
>
> #define DRM_IOCTL_NR(n)_IOC_NR(n)
> #define DRM_MAJOR 226
>
> -#define DRM_AUTH 0x1
> -#define DRM_MASTER 0x2
> -#define DRM_ROOT_ONLY0x4
> -#define DRM_CONTROL_ALLOW 0x8
> -#define DRM_UNLOCKED 0x10
> -#define DRM_RENDER_ALLOW 0x20
> +/**
> + * enum drm_ioctl_flags - DRM ioctl flags
> + *
> + * Various flags that can be set in _ioctl_desc.flags to control how
> + * userspace can use a given ioctl.
> + */
> +enum drm_ioctl_flags {
> + /**
> + * @DRM_AUTH:
> + *
> + * This is for ioctl which are used for rendering, and require that the
> + * file descriptor is either for a render node, or if it's a
> + * legacy/primary node, then it must be authenticated.
> + */
> + DRM_AUTH= BIT(0),
> + /**
> + * @DRM_MASTER:
> + *
> + * This must be set for any ioctl which can change the modeset or
> + * display state. Userspace must call the ioctl through a primary node,
> + * while it is the active master.
> + *
> + * Note that read-only modeset ioctl can also be called by
> + * unauthenticated clients, or when a master is not the currently active
> + * one.
> + */
> + DRM_MASTER = BIT(1),
> + /**
> + * @DRM_ROOT_ONLY:
> + *
> + * Anything that could potentially wreak a master file descriptor needs
> + * to have this flag set. Current that's only for the SETMASTER and
> + * DROPMASTER ioctl, which e.g. logind can call to force a non-behaving
> + * master (display compositor) into compliance.
> + *
> + * This is equivalent to callers with the SYSADMIN capability.
> + */
> + DRM_ROOT_ONLY = BIT(2),
> + /**
> + * @DRM_CONTROL_ALLOW:
> + *
> + * Deprecated, do not use. Control nodes are in the process of getting
> + * removed.
> + */
> + DRM_CONTROL_ALLOW = BIT(3),
> + /**
> + * @DRM_UNLOCKED:
> + *
> + * Whether _ioctl_desc.func should be called with the DRM BKL held
> + * or not. Enforced as the default for all modern drivers, hence there
> + * should never be a need to set this flag.
> + */
> + DRM_UNLOCKED= BIT(4),
> + /**
> + * @DRM_RENDER_ALLOW:
> + *
> + * This is used for all ioctl needed for rendering only, for drivers
> + * which support render nodes. This should be all new render drivers,
> + * and hence it should be always set for any ioctl with DRM_AUTH set.
> + * Note though that read-only query ioctl might have this set, but have
> + * not set DRM_AUTH because they do not require authentication.
> + */
> + DRM_RENDER_ALLOW= BIT(5),
> +};
>
> +/**
> + * struct drm_ioctl_desc - DRM driver ioctl entry
> + * @cmd: ioctl command number, without flags
> + * @flags: a bitmask of drm_ioctl_flags
> + * @func: handler for this ioctl
> + * @name: user-readable name for debug output
> + *
> + * For convenience it's easier to create these using the DRM_IOCTL_DEF_DRV()
> + * macro.
> + */
> struct drm_ioctl_desc {
> unsigned int cmd;
> - int flags;
> + enum drm_ioctl_flags flags;
> drm_ioctl_t *func;
> const char *name;
> };
>
> /**
> - * Creates a driver or general drm_ioctl_desc array entry for the given
> - * ioctl, for use by drm_ioctl().
> + * DRM_IOCTL_DEF_DRV() - helper macro to fill out a drm_ioctl_desc
> + * @ioctl: ioctl command suffix
> + * @_func: handler for the ioctl
> + * @_flags: a bitmask of drm_ioctl_flags
> + *
> + * Small helper macro to create a drm_ioctl_desc entry. The ioctl
> + * command number is constructed by prepending ``DRM_IOCTL\_`` and passing
> that
> + * to DRM_IOCTL_NR().
> */
> -
> #define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)
> \
> [DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {\
> .cmd = DRM_IOCTL_##ioctl, \
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > There's really no reason for anything more: > - Calling this while the crtc vblank stuff isn't set up is a driver > bug. Those places arlready DRM_ERROR. s/arlready/already/ > - Calling this when the crtc is off is either a driver bug (callin s/callin/calling/ > drm_crtc_handle_vblank at the wrong time) or a core bug (for > anything else). Again, we DRM_ERROR. > - EINVAL is checked at higher levels already, and if we'd use struct > drm_crtc * instead of (dev, pipe) it would be real obvious that > those are again core bugs. > > The only valid failure mode is crap hardware that couldn't sample a > useful timestamp, to ask the core to just grab a not-so-accurate > timestampe. Bool is perfectly fine for that. s/timestampe/timestamp/ > > v2: Also fix up the one caller, I lost that in the shuffling (Jani). > > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: Mario Kleiner <mario.klei...@tuebingen.mpg.de> > Cc: Eric Anholt <e...@anholt.net> > Cc: Rob Clark <robdcl...@gmail.com> > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: Alex Deucher <alexander.deuc...@amd.com> > Cc: Christian König <christian.koe...@amd.com> > Cc: Ben Skeggs <bske...@redhat.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 ++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 14 - > drivers/gpu/drm/drm_irq.c | 49 > --- > drivers/gpu/drm/i915/i915_irq.c | 8 ++--- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 12 > drivers/gpu/drm/nouveau/nouveau_display.c | 4 +-- > drivers/gpu/drm/nouveau/nouveau_display.h | 4 +-- > drivers/gpu/drm/radeon/radeon_drv.c | 8 ++--- > drivers/gpu/drm/radeon/radeon_kms.c | 14 - > drivers/gpu/drm/vc4/vc4_crtc.c| 2 +- > drivers/gpu/drm/vc4/vc4_drv.h | 2 +- > include/drm/drmP.h| 1 - > include/drm/drm_drv.h | 7 ++--- > include/drm/drm_irq.h | 10 +++ > 14 files changed, 64 insertions(+), 79 deletions(-) > [...] With the commit log typo fixes, Reviewed-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp
max_error,
> - vblank_time, flags,
> + vblank_time, in_vblank_irq,
>>adjusted_mode);
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 8a5d0e12ee02..815cdeb54971 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -452,7 +452,7 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev,
> unsigned int crtc_id,
> const struct drm_display_mode *mode);
> bool vc4_crtc_get_vblank_timestamp(struct drm_device *dev, unsigned int
> crtc_id,
> int *max_error, struct timeval *vblank_time,
> - unsigned flags);
> + bool in_vblank_irq);
>
> /* vc4_debugfs.c */
> int vc4_debugfs_init(struct drm_minor *minor);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index da78e248d9d8..9fe6301edd6a 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -308,11 +308,10 @@ struct drm_driver {
>* Returns true upper bound on error for timestamp.
>* vblank_time:
>* Target location for returned vblank timestamp.
> - * flags:
> - * 0 = Defaults, no special treatment needed.
> - * DRM_CALLED_FROM_VBLIRQ = Function is called from vblank
> - * irq handler. Some drivers need to apply some workarounds
> - * for gpu-specific vblank irq quirks if flag is set.
> + * in_vblank_irq:
> + * True when called from drm_crtc_handle_vblank(). Some drivers
> + * need to apply some workarounds for gpu-specific vblank irq quirks
> + * if flag is set.
>*
>* Returns:
>*
> @@ -322,7 +321,7 @@ struct drm_driver {
> bool (*get_vblank_timestamp) (struct drm_device *dev, unsigned int pipe,
>int *max_error,
>struct timeval *vblank_time,
> - unsigned flags);
> + bool in_vblank_irq);
>
> /* these have to be filled in */
>
> diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
> index f0d5ccf9b282..445406efb8dc 100644
> --- a/include/drm/drm_irq.h
> +++ b/include/drm/drm_irq.h
> @@ -156,7 +156,7 @@ u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
> bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> unsigned int pipe, int *max_error,
> struct timeval *vblank_time,
> -unsigned flags,
> +bool in_vblank_irq,
> const struct drm_display_mode *mode);
> void drm_calc_timestamping_constants(struct drm_crtc *crtc,
>const struct drm_display_mode *mode);
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/vblank: Add FIXME comments about moving the vblank ts hooks
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> This is going to be a bit too much, but good to have at least a small
> note about where this should all head towards.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> include/drm/drm_drv.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 9fe6301edd6a..0a367cf5d8d5 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -274,6 +274,11 @@ struct drm_driver {
>* constant but unknown small number of scanlines wrt. real scanout
>* position.
>*
> + * FIXME:
> + *
> + * Since this is a helper to implement @get_vblank_timestamp, we should
> + * move it to drm_crtc_helper_funcs, like all the other
> + * helper-internal hooks.
>*/
> int (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
>unsigned int flags, int *vpos, int *hpos,
> @@ -317,6 +322,11 @@ struct drm_driver {
>*
>* True on success, false on failure, which means the core should
>* fallback to a simple timestamp taken in drm_crtc_handle_vblank().
> + *
> + * FIXME:
> + *
> + * We should move this hook to drm_crtc_funcs like all the other
> + * vblank hooks.
>*/
> bool (*get_vblank_timestamp) (struct drm_device *dev, unsigned int pipe,
>int *max_error,
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
= radeon_enable_vblank_kms,
> .disable_vblank = radeon_disable_vblank_kms,
> - .get_vblank_timestamp = radeon_get_vblank_timestamp_kms,
> + .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> .get_scanout_position = radeon_get_crtc_scanoutpos,
> .irq_preinstall = radeon_driver_irq_preinstall_kms,
> .irq_postinstall = radeon_driver_irq_postinstall_kms,
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 5bccdeae0773..6a68d440bc44 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -858,43 +858,6 @@ void radeon_disable_vblank_kms(struct drm_device *dev,
> int crtc)
> spin_unlock_irqrestore(>irq.lock, irqflags);
> }
>
> -/**
> - * radeon_get_vblank_timestamp_kms - get vblank timestamp
> - *
> - * @dev: drm dev pointer
> - * @crtc: crtc to get the timestamp for
> - * @max_error: max error
> - * @vblank_time: time value
> - * @flags: flags passed to the driver
> - *
> - * Gets the timestamp on the requested crtc based on the
> - * scanout position. (all asics).
> - * Returns true on success, false on failure.
> - */
> -bool radeon_get_vblank_timestamp_kms(struct drm_device *dev, int crtc,
> - int *max_error,
> - struct timeval *vblank_time,
> - bool in_vblank_irq)
> -{
> - struct drm_crtc *drmcrtc;
> - struct radeon_device *rdev = dev->dev_private;
> -
> - if (crtc < 0 || crtc >= dev->num_crtcs) {
> - DRM_ERROR("Invalid crtc %d\n", crtc);
> - return false;
> - }
> -
> - /* Get associated drm_crtc: */
> - drmcrtc = >mode_info.crtcs[crtc]->base;
> - if (!drmcrtc)
> - return false;
> -
> - /* Helper routine in DRM core does all the work: */
> - return drm_calc_vbltimestamp_from_scanoutpos(dev, crtc, max_error,
> - vblank_time, in_vblank_irq,
> - >hwmode);
> -}
> -
> const struct drm_ioctl_desc radeon_ioctls_kms[] = {
> DRM_IOCTL_DEF_DRV(RADEON_CP_INIT, drm_invalid_op,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(RADEON_CP_START, drm_invalid_op,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 38f5cc740cd1..2acfecc5b811 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -270,19 +270,6 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev,
> unsigned int crtc_id,
> return ret;
> }
>
> -bool vc4_crtc_get_vblank_timestamp(struct drm_device *dev, unsigned int
> crtc_id,
> - int *max_error, struct timeval *vblank_time,
> - bool in_vblank_irq)
> -{
> - struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id);
> - struct drm_crtc_state *state = crtc->state;
> -
> - /* Helper routine in DRM core does all the work: */
> - return drm_calc_vbltimestamp_from_scanoutpos(dev, crtc_id, max_error,
> - vblank_time, in_vblank_irq,
> - >adjusted_mode);
> -}
> -
> static void vc4_crtc_destroy(struct drm_crtc *crtc)
> {
> drm_crtc_cleanup(crtc);
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 61e674baf3a6..e864256e12e5 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -154,7 +154,7 @@ static struct drm_driver vc4_drm_driver = {
> .irq_uninstall = vc4_irq_uninstall,
>
> .get_scanout_position = vc4_crtc_get_scanoutpos,
> - .get_vblank_timestamp = vc4_crtc_get_vblank_timestamp,
> + .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
>
> #if defined(CONFIG_DEBUG_FS)
> .debugfs_init = vc4_debugfs_init,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 815cdeb54971..64c92e0eb8f7 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -450,9 +450,6 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev,
> unsigned int crtc_id,
> unsigned int flags, int *vpos, int *hpos,
> ktime_t *stime, ktime_t *etime,
> const struct drm_display_mode *mode);
> -bool vc4_crtc_get_vblank_timestamp(struct drm_device *dev, unsigned int
> crtc_id,
> - int *max_error, struct
Re: [Intel-gfx] [PATCH 09/11] drm/vblank: Simplify the get_scanout_position helper hook
{
Shouldn't this go in patch 06/11 ?
> /*
>* Assume the irq handler got called close to first
>* line of vblank, so PV has about a full vblank
> @@ -254,9 +252,10 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev,
> unsigned int crtc_id,
>* we are at the very beginning of vblank, as the hvs just
>* started refilling, and the stime and etime timestamps
>* truly correspond to start of vblank.
> + *
> + * Unfortunately there's no way to report this to upper levels
> + * and make it more useful.
>*/
> - if ((val & SCALER_DISPSTATX_FULL) != SCALER_DISPSTATX_FULL)
> - ret |= DRM_SCANOUTPOS_ACCURATE;
> } else {
> /*
>* No clue where we are inside vblank. Return a vpos of zero,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 64c92e0eb8f7..c34a0915e49d 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -446,10 +446,10 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *arg);
> extern struct platform_driver vc4_crtc_driver;
> bool vc4_event_pending(struct drm_crtc *crtc);
> int vc4_crtc_debugfs_regs(struct seq_file *m, void *arg);
> -int vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id,
> - unsigned int flags, int *vpos, int *hpos,
> - ktime_t *stime, ktime_t *etime,
> - const struct drm_display_mode *mode);
> +bool vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id,
> + bool in_vblank_irq, int *vpos, int *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode *mode);
>
> /* vc4_debugfs.c */
> int vc4_debugfs_init(struct drm_minor *minor);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 1b3f3cd7b230..6c7ea497e3a6 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -321,14 +321,6 @@ struct pci_controller;
> #define DRM_IF_VERSION(maj, min) (maj << 16 | min)
>
>
> -/* Flags and return codes for get_vblank_timestamp() driver function. */
> -#define DRM_CALLED_FROM_VBLIRQ 1
> -
> -/* get_scanout_position() return flags */
> -#define DRM_SCANOUTPOS_VALID(1 << 0)
> -#define DRM_SCANOUTPOS_IN_VBLANK(1 << 1)
> -#define DRM_SCANOUTPOS_ACCURATE (1 << 2)
> -
> /**
> * DRM device structure. This structure represent a complete card that
> * may contain multiple heads.
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 0a367cf5d8d5..e64e33b9dd26 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -241,8 +241,10 @@ struct drm_driver {
>* DRM device.
>* pipe:
>* Id of the crtc to query.
> - * flags:
> - * Flags from the caller (DRM_CALLED_FROM_VBLIRQ or 0).
> + * in_vblank_irq:
> + * True when called from drm_crtc_handle_vblank(). Some drivers
> + * need to apply some workarounds for gpu-specific vblank irq quirks
> + * if flag is set.
Same here, should be in 06/11 ?
>* vpos:
>* Target location for current vertical scanout position.
>* hpos:
> @@ -263,16 +265,8 @@ struct drm_driver {
>*
>* Returns:
>*
> - * Flags, or'ed together as follows:
> - *
> - * DRM_SCANOUTPOS_VALID:
> - * Query successful.
> - * DRM_SCANOUTPOS_INVBL:
> - * Inside vblank.
> - * DRM_SCANOUTPOS_ACCURATE: Returned position is accurate. A lack of
> - * this flag means that returned position may be offset by a
> - * constant but unknown small number of scanlines wrt. real scanout
> - * position.
> + * True on success, false if a reliable scanout position counter could
> + * not be read out.
>*
>* FIXME:
>*
> @@ -280,10 +274,10 @@ struct drm_driver {
>* move it to drm_crtc_helper_funcs, like all the other
>* helper-internal hooks.
>*/
> - int (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
> - unsigned int flags, int *vpos, int *hpos,
> - ktime_t *stime, ktime_t *etime,
> - const struct drm_display_mode *mode);
> + bool (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
> + bool in_vblank_irq, int *vpos, int *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode *mode);
>
> /**
>* @get_vblank_timestamp:
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/doc: Small markup fixup
On 04/04/2017 11:53 AM, Daniel Vetter wrote: > Drive-by cleanup. > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > drivers/gpu/drm/drm_probe_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_probe_helper.c > b/drivers/gpu/drm/drm_probe_helper.c > index 85005d57bde6..efb5e5e8ce62 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -44,7 +44,7 @@ > * > * This library provides some helper code for output probing. It provides an > * implementation of the core _connector_funcs.fill_modes interface with > - * drm_helper_probe_single_connector_modes. > + * drm_helper_probe_single_connector_modes(). > * > * It also provides support for polling connectors with a work item and for > * generic hotplug interrupt handling where the driver doesn't or cannot keep > Reviewed-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm: update todo.rst
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > Just drive-by, but we have gsoc running so better to update it now. > > Great news is that two entries can be removed because essentially all > done. > > v2: Keep a bunch of the todos, Gabriel is working on them. > > Cc: Gabriel Krisman Bertazi <kris...@collabora.co.uk> > Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> > --- > Documentation/gpu/todo.rst | 31 --- > 1 file changed, 4 insertions(+), 27 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index e255b36b34a3..1bdb7356a310 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -16,7 +16,7 @@ De-midlayer drivers > With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required > to have a ``drm_bus`` structure set up. Drivers can directly set up the > ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` > -and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` / > +and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / > ``->unload`` callbacks and open-code the load/unload sequence properly, using > the new two-stage ``drm_device`` setup/teardown. > > @@ -175,7 +175,7 @@ fine-grained per-buffer object and per-context lockings > scheme. Currently the > following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and > ``udl``. > > -Contact: Daniel Vetter > +Contact: Daniel Vetter, respective driver maintainers > > Switch to drm_connector_list_iter for any connector_list walking > > @@ -217,6 +217,8 @@ plan is to switch to per-file driver API headers, which > will also structure > the kerneldoc better. This should also allow more fine-grained ``#include`` > directives. > > +In the end no .c file should need to include ``drmP.h`` anymore. > + > Contact: Daniel Vetter > > Add missing kerneldoc for exported functions > @@ -244,13 +246,8 @@ be hidden so that driver writers don't accidentally end > up using it. And to > prevent security issues in those legacy IOCTLs from being exploited on modern > drivers. This has multiple possible subtasks: > > -* Make sure legacy IOCTLs can't be used on modern drivers. > * Extract support code for legacy features into a ``drm-legacy.ko`` kernel >module and compile it only when one of the legacy drivers is enabled. > -* Extract legacy functions into their own headers and remove it that from the > - monolithic ``drmP.h`` header. > -* Remove any lingering cruft from the OS abstraction layer from modern > - drivers. > > This is mostly done, the only thing left is to split up ``drm_irq.c`` into > legacy cruft and the parts needed by modern KMS drivers. > @@ -408,23 +405,3 @@ Contact: Noralf Trønnes, Daniel Vetter > > Outside DRM > === > - > -Better kerneldoc > - > - > -This is pretty much done, but there's some advanced topics: > - > -Come up with a way to hyperlink to struct members. Currently you can > hyperlink > -to the struct using ``#struct_name``, but not to a member within. Would need > -buy-in from kerneldoc maintainers, and the big question is how to make it > work > -without totally unsightly > -``drm_foo_bar_really_long_structure->even_longer_memeber`` all over the text > -which breaks text flow. > - > -Figure out how to integrate the asciidoc support for ascii-diagrams. We have > a > -few of those (e.g. to describe mode timings), and asciidoc supports > converting > -some ascii-art dialect into pngs. Would be really pretty to make that work. > - > -Contact: Daniel Vetter, Jani Nikula > - > -Jani is working on this already, hopefully lands in 4.8. > Reviewed-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] drm/vblank: Lock down vblank->hwmode more
e_config(>base.mode, > crtc_state); > @@ -15502,7 +15494,8 @@ static void intel_modeset_readout_hw_state(struct > drm_device *dev) > if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled) > pixclk = DIV_ROUND_UP(pixclk * 100, 95); > > - drm_calc_timestamping_constants(>base, > >base.hwmode); > + drm_calc_timestamping_constants(>base, > + > _state->base.adjusted_mode); > update_scanline_offset(crtc); > } > > Reviewed-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On 04/11/2017 11:03 AM, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> freedesktop.org has adopted a formal code of conduct: >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> Besides formalizing things a bit more I don't think this changes >> anything for us, we've already peer-enforced respectful and >> constructive interactions since a long time. But it's good to document >> things properly. >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> started chatting with the communities their hosting, which includs the >> X.org foundation board, to figure out how to fan out enforcement and >> allow projects to run things on their own (with fd.o still as the >> fallback). So the details of enforcement (and appealing decisions) >> might still change, but since this involves the board and lots more >> people it'll take a while to get there. For now this is good enough I >> think. >> >> For the text itself I went with the same blurb as the Wayland project, >> didn't feel creative yet this early in the morning: >> >> https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c >> >> Cc: Daniel Stone <dani...@collabora.com> >> Cc: Keith Packard <kei...@keithp.com> >> Cc: tfh...@err.no >> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> >> --- >> Documentation/gpu/introduction.rst | 11 +++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/Documentation/gpu/introduction.rst >> b/Documentation/gpu/introduction.rst >> index 05a82bdfbca4..0f5173e29bdc 100644 >> --- a/Documentation/gpu/introduction.rst >> +++ b/Documentation/gpu/introduction.rst >> @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one >> month where feature work >> can't be merged. The recommended way to deal with that is having a -next >> tree >> that's always open, but making sure to not feed it into linux-next during >> the >> blackout period. As an example, drm-misc works like that. >> + >> +Code of Conduct >> +--- >> + >> +As a freedesktop.org project, dri-devel and the DRM community follows the >> +Contributor Covenant, found at: >> https://www.freedesktop.org/wiki/CodeOfConduct > > Chris pointed out on irc that the grammar went a bit wrong here. I'll fix > this to > > "As a freedesktop.org project, dri-devel, and the DRM community, follows > the Contributor Covenant, ..." > > when applying. > -Daniel > >> + >> +Please conduct yourself in a respectful and civilised manner when >> +interacting with community members on mailing lists, IRC, or bug >> +trackers. The community represents the project as a whole, and abusive >> +or bullying behaviour is not tolerated by the project. >> -- >> 2.11.0 Acked-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms
Le 25/07/2017 10:01, Daniel Vetter a écrit : > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2: Rebase over the panel/brideg refactorings in stm/ltdc. > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > Cc: Archit Taneja <arch...@codeaurora.org> > Cc: Andrzej Hajda <a.ha...@samsung.com> > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > Cc: Peter Senna Tschudin <peter.se...@collabora.com> > Cc: Martin Donnelly <martin.donne...@ge.com> > Cc: Martyn Welch <martyn.we...@collabora.co.uk> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: Sean Paul <seanp...@chromium.org> > Cc: David Airlie <airl...@linux.ie> > Cc: Inki Dae <inki@samsung.com> > Cc: Joonyoung Shim <jy0922.s...@samsung.com> > Cc: Seung-Woo Kim <sw0312@samsung.com> > Cc: Kyungmin Park <kyungmin.p...@samsung.com> > Cc: Kukjin Kim <kg...@kernel.org> > Cc: Krzysztof Kozlowski <k...@kernel.org> > Cc: Stefan Agner <ste...@agner.ch> > Cc: Alison Wang <alison.w...@freescale.com> > Cc: Russell King <li...@armlinux.org.uk> > Cc: Philipp Zabel <p.za...@pengutronix.de> > Cc: CK Hu <ck...@mediatek.com> > Cc: Matthias Brugger <matthias@gmail.com> > Cc: Neil Armstrong <narmstr...@baylibre.com> > Cc: Carlo Caione <ca...@caione.org> > Cc: Kevin Hilman <khil...@baylibre.com> > Cc: Marek Vasut <ma...@denx.de> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Tomi Valkeinen <tomi.valkei...@ti.com> > Cc: Eric Anholt <e...@anholt.net> > Cc: Mark Yao <mark@rock-chips.com> > Cc: Heiko Stuebner <he...@sntech.de> > Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org> > Cc: Vincent Abriou <vincent.abr...@st.com> > Cc: Yannick Fertre <yannick.fer...@st.com> > Cc: Philippe Cornu <philippe.co...@st.com> > Cc: Maxime Ripard <maxime.rip...@free-electrons.com> > Cc: Chen-Yu Tsai <w...@csie.org> > Cc: Thierry Reding <thierry.red...@gmail.com> > Cc: Jonathan Hunter <jonath...@nvidia.com> > Cc: Jyri Sarha <jsa...@ti.com> > Cc: Gerd Hoffmann <kra...@redhat.com> > Cc: Shawn Guo <shawn...@kernel.org> > Cc: John Stultz <john.stu...@linaro.org> > Cc: Lars-Peter Clausen <l...@metafoo.de> > Cc: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> > Cc: Jeffy Chen <jeffy.c...@rock-chips.com> > Cc: Tomeu Vizoso <tomeu.viz...@collabora.com> > Cc: Yakir Yang <kuankua...@gmail.com> > Cc: Marek Szyprowski <m.szyprow...@samsung.com> > Cc: Jose Abreu <jose.ab...@synopsys.com> > Cc: Romain Perier <romain.per...@collabora.com> > Cc: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> > Cc: Xinliang Liu <z.liuxinli...@hisilicon.com> > Cc: Alexey Brodkin <abrod...@synopsys.com> > Cc: Alex Deucher <alexander.deuc...@amd.com> > Cc: Rongrong Zou <zourongr...@gmail.com> > Cc: Rob Clark <robdcl...@gmail.com> > Cc: Hai Li <h...@codeaurora.org> > Cc: "Noralf Trønnes" <nor...@tronnes.org> > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-te...@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: zain wang <w...@rock-chips.com> > Cc: Baoyou Xie <baoyou@linaro.org> > Cc: Boris Brezillon <boris.brezil...@free-electrons.com> > --- > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 - > drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 - > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 - > drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 - > .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 1 - > drivers/gpu/drm/bridge/nxp-ptn3460.c | 1 - > drivers/gpu/drm/bridge/panel.c | 1 - > drivers/gpu/drm/bridge/parade-ps8622.c | 1 - > drivers/gpu/drm/bridge/sii902x.c | 1 - > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 - > drivers/gpu/drm/bridge/tc358767.c | 1 - > drivers/gpu/drm/bridge/ti-tfp410.c | 1 - > drivers/gpu/drm/dr
Re: [Intel-gfx] [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)
25Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
> + 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},
> + /* 105 - 3840x2160p@30Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
> + 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},
> + /* 106 - 3840x2160p@50Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 4896,
> + 4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},
> + /* 107 - 3840x2160p@60Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 4016,
> + 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},
> };
>
> /*
> @@ -2902,6 +3117,16 @@ add_alternate_cea_modes(struct drm_connector
> *connector, struct edid *edid)
> return modes;
> }
>
> +static u8 svd_to_vic(u8 svd)
> +{
> +
> + /* 0-6 bit vic, 7th bit native mode indicator */
> + if (((svd >= 1) && (svd <= 64)) || ((svd >= 129) && (svd <= 192)))
> + return svd & 127;
> +
> + return svd;
> +}
> +
> static struct drm_display_mode *
> drm_display_mode_from_vic_index(struct drm_connector *connector,
> const u8 *video_db, u8 video_len,
> @@ -2915,7 +3140,7 @@ drm_display_mode_from_vic_index(struct drm_connector
> *connector,
> return NULL;
>
> /* CEA modes are numbered 1..127 */
> - vic = (video_db[video_index] & 127);
> + vic = svd_to_vic(video_db[video_index]);
> if (!drm_valid_cea_vic(vic))
> return NULL;
>
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames
gt; dssdev->driver->set_hdmi_infoframe(dssdev, );
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_audio.c
> b/drivers/gpu/drm/radeon/radeon_audio.c
> index aaacac1..770e31f 100644
> --- a/drivers/gpu/drm/radeon/radeon_audio.c
> +++ b/drivers/gpu/drm/radeon/radeon_audio.c
> @@ -516,7 +516,7 @@ static int radeon_audio_set_avi_packet(struct drm_encoder
> *encoder,
> if (!connector)
> return -EINVAL;
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %d\n", err);
> return err;
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 7d9b75e..7149968 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -294,7 +294,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
> *hdmi,
> union hdmi_infoframe frame;
> int rc;
>
> - rc = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + rc = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
>
> if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
> frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index a59c95a..dbc6a19 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -434,7 +434,7 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi
> *hdmi)
>
> DRM_DEBUG_DRIVER("\n");
>
> - ret = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + ret = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (ret < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %d\n", ret);
> return ret;
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> index cda0491..718d8db 100644
> --- a/drivers/gpu/drm/tegra/hdmi.c
> +++ b/drivers/gpu/drm/tegra/hdmi.c
> @@ -734,7 +734,7 @@ static void tegra_hdmi_setup_avi_infoframe(struct
> tegra_hdmi *hdmi,
> u8 buffer[17];
> ssize_t err;
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (err < 0) {
> dev_err(hdmi->dev, "failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index a8f5289..fb2709c 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -1904,7 +1904,7 @@ tegra_sor_hdmi_setup_avi_infoframe(struct tegra_sor
> *sor,
> value &= ~INFOFRAME_CTRL_ENABLE;
> tegra_sor_writel(sor, value, SOR_HDMI_AVI_INFOFRAME_CTRL);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (err < 0) {
> dev_err(sor->dev, "failed to setup AVI infoframe: %d\n", err);
> return err;
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ed63d4e..406d6d8 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -395,7 +395,7 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
> *encoder)
> union hdmi_infoframe frame;
> int ret;
>
> - ret = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + ret = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (ret < 0) {
> DRM_ERROR("couldn't fill AVI infoframe\n");
> return;
> diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
> index 0df7366..7e834e3 100644
> --- a/drivers/gpu/drm/zte/zx_hdmi.c
> +++ b/drivers/gpu/drm/zte/zx_hdmi.c
> @@ -124,7 +124,7 @@ static int zx_hdmi_config_video_avi(struct zx_hdmi *hdmi,
> union hdmi_infoframe frame;
> int ret;
>
> - ret = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> + ret = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (ret) {
> DRM_DEV_ERROR(hdmi->dev, "failed to get avi infoframe: %d\n",
> ret);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7b9f48b..89c0062 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -343,7 +343,8 @@ drm_load_edid_firmware(struct drm_connector *connector)
>
> int
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> - const struct drm_display_mode *mode);
> + const struct drm_display_mode *mode,
> + bool is_hdmi2_sink);
> int
> drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
> *frame,
> const struct drm_display_mode
> *mode);
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 02/15] drm: add YCBCR 420 capability identifier
On 06/21/2017 12:34 PM, Shashank Sharma wrote:
> This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
> structure. While handling the EDID from HDMI 2.0 sinks, its important to
> know if the source is capable of handling YCBCR 420 outputs or not, so that
> a lot of work can be done/bypassed based on this information. One such
> example is adding YCBCR420 only modes.
>
> If the driver knows that this source is not HDMI 2.0 capable, it will
> not add YCBCR420-only modes while adding EDID modes, and will prevent
> any runtime modeset failures.
>
> This variable will be initialized from I915 driver in the next patch
> and will be used in the EDID handling for HDMI 2.0 specific features,
> in this same series.
>
> V3: introduced the new variable
> V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)
>
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> ---
> include/drm/drm_connector.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index d8bb25f..7493fd3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -728,6 +728,15 @@ struct drm_connector {
> bool interlace_allowed;
> bool doublescan_allowed;
> bool stereo_allowed;
> +
> + /**
> + * @ycbcr_420_allowed : This bool indicates if this connector is
> + * capable of handling YCBCR 420 output. While parsing the EDID
> + * blocks, its very helpful to know, if the source is capable of
> + * handling YCBCR 420 outputs.
> + */
> + bool ycbcr_420_allowed;
> +
> /**
> * @registered: Is this connector exposed (registered) with userspace?
>* Protected by @mutex.
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/37] drm/meson: Drop drm_vblank_cleanup
On 05/24/2017 04:52 PM, Daniel Vetter wrote: > Again seems just cargo-culted. > > Cc: Neil Armstrong <narmstr...@baylibre.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > drivers/gpu/drm/meson/meson_drv.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/meson/meson_drv.c > b/drivers/gpu/drm/meson/meson_drv.c > index 75382f5f0fce..2c605a406ad5 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -285,7 +285,6 @@ static void meson_drv_unbind(struct device *dev) > drm_kms_helper_poll_fini(drm); > drm_fbdev_cma_fini(priv->fbdev); > drm_mode_config_cleanup(drm); > - drm_vblank_cleanup(drm); > drm_dev_unref(drm); > > } > Acked-by: Neil Armstrong <narmstr...@baylibre.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/37] drm: better document how to send out the crtc disable event
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> The kernel doc explained what needs to happen, but not how to most
> easily accomplish that using the functions. Fix that.
>
> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> include/drm/drm_crtc.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5f5d53973ca5..3a911a64c257 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -214,7 +214,9 @@ struct drm_crtc_state {
>*atomic commit. In that case the event can be send out any time
>*after the hardware has stopped scanning out the current
>*framebuffers. It should contain the timestamp and counter for the
> - *last vblank before the display pipeline was shut off.
> + *last vblank before the display pipeline was shut off. The simplest
> + *way to achieve that is calling drm_crtc_send_vblank_event()
> + *somewhen after drm_crtc_vblank_off() has been called.
>*
>* - For a CRTC which is enabled at the end of the commit (even when it
>* undergoes an full modeset) the vblank timestamp and counter must
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/37] drm: Remove drm_device->virtdev
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> This is a leftover from the drm_bus days, where we've had a
> bus-specific device type for every bus type in drm_device. Except for
> pci (which we can't remove because dri1 drivers) this is all gone. And
> the virt driver also doesn't really need it, dev_to_virtio works
> perfectly fine.
>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Gerd Hoffmann <kra...@redhat.com>
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 1 -
> drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++--
> include/drm/drmP.h | 2 --
> 3 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> index 43e1d5916c6c..7df8d0c9026a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> @@ -56,7 +56,6 @@ int drm_virtio_init(struct drm_driver *driver, struct
> virtio_device *vdev)
> dev = drm_dev_alloc(driver, >dev);
> if (IS_ERR(dev))
> return PTR_ERR(dev);
> - dev->virtdev = vdev;
> vdev->priv = dev;
>
> if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index 1e1c90b30d4a..6400506a06b0 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -138,7 +138,7 @@ int virtio_gpu_driver_load(struct drm_device *dev,
> unsigned long flags)
> u32 num_scanouts, num_capsets;
> int ret;
>
> - if (!virtio_has_feature(dev->virtdev, VIRTIO_F_VERSION_1))
> + if (!virtio_has_feature(dev_to_virtio(dev->dev), VIRTIO_F_VERSION_1))
> return -ENODEV;
>
> vgdev = kzalloc(sizeof(struct virtio_gpu_device), GFP_KERNEL);
> @@ -147,7 +147,7 @@ int virtio_gpu_driver_load(struct drm_device *dev,
> unsigned long flags)
>
> vgdev->ddev = dev;
> dev->dev_private = vgdev;
> - vgdev->vdev = dev->virtdev;
> + vgdev->vdev = dev_to_virtio(dev->dev);
> vgdev->dev = dev->dev;
>
> spin_lock_init(>display_info_lock);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 575b29b47811..c363f2fdff31 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -412,8 +412,6 @@ struct drm_device {
> struct pci_controller *hose;
> #endif
>
> - struct virtio_device *virtdev;
> -
> struct drm_sg_mem *sg; /**< Scatter gather memory */
> unsigned int num_crtcs; /**< Number of CRTCs on this
> device */
>
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/37] drm/doc: move printf helpers out of drmP.h
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> And document them lightly. Unfortunately kernel-doc isn't the most
> awesome for documenting #defines that don't look like functions, it
> makes functions out of them :-/
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> include/drm/drmP.h | 17 -
> include/drm/drm_modes.h | 17 +
> include/drm/drm_rect.h | 27 +++
> 3 files changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index b9b5566acfe6..575b29b47811 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -292,23 +292,6 @@ struct pci_controller;
> /* Format strings and argument splitters to simplify printing
> * various "complex" objects
> */
> -#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> -#define DRM_MODE_ARG(m) \
> - (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
> - (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> - (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> - (m)->type, (m)->flags
> -
> -#define DRM_RECT_FMT"%dx%d%+d%+d"
> -#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1,
> (r)->y1
> -
> -/* for rect's in fixed-point format: */
> -#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
> -#define DRM_RECT_FP_ARG(r) \
> - drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625)
> >> 10, \
> - drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) *
> 15625) >> 10, \
> - (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
> - (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
>
> /*@}*/
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 6dd34280e892..94ac771fe460 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -197,6 +197,8 @@ enum drm_mode_status {
> * there's the hardware timings, which are corrected for interlacing,
> * double-clocking and similar things. They are provided as a convenience,
> and
> * can be appropriately computed using drm_mode_set_crtcinfo().
> + *
> + * For printing you can use %DRM_MODE_FMT and DRM_MODE_ARG().
> */
> struct drm_display_mode {
> /**
> @@ -407,6 +409,21 @@ struct drm_display_mode {
> enum hdmi_picture_aspect picture_aspect_ratio;
> };
>
> +/**
> + * DRM_MODE_FMT - printf string for drm_display_mode
> + */
> +#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> +
> +/**
> + * DRM_MODE_ARG - printf arguments for drm_display_mode
> + * @m: display mode
> + */
> +#define DRM_MODE_ARG(m) \
> + (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
> + (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> + (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> + (m)->type, (m)->flags
> +
> #define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
>
> /**
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 83bb156d4356..44bc122b9ee0 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -43,6 +43,33 @@ struct drm_rect {
> };
>
> /**
> + * DRM_RECT_FMT - printf string for drm_rect
> + */
> +#define DRM_RECT_FMT"%dx%d%+d%+d"
> +/**
> + * DRM_RECT_ARG - printf arguments for drm_rect
> + * @r: rectangle struct
> + */
> +#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1,
> (r)->y1
> +
> +/**
> + * DRM_RECT_FP_FMT - printf string for drm_rect in 16.16 fixed point
> + */
> +#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
> +/**
> + * DRM_RECT_FP_ARG - printf arguments for drm_rect in 16.16 fixed
> point
> + * @r: rectangle struct
> + *
> + * This is useful for e.g. printing plane source rectangles, which are in
> 16.16
> + * fixed point.
> + */
> +#define DRM_RECT_FP_ARG(r) \
> + drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625)
> >> 10, \
> + drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) *
> 15625) >> 10, \
> + (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
> + (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
> +
> +/**
> * drm_rect_adjust_size - adjust the size of the rectangle
> * @r: rectangle to be adjusted
> * @dw: horizontal adjustment
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Enforce review requirements
On 05/24/2017 11:28 AM, Daniel Vetter wrote:
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
>
> Also update the docs to highlight that review requirements hold
> especially also for bugfixes.
>
> Cc: Patrik Jakobsson <patrik.r.jakobs...@gmail.com>
> Cc: Lukas Wunner <lu...@wunner.de>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Christian König <deathsim...@vodafone.de>
> Cc: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> dim | 42 ++
> drm-misc.rst | 4 +++-
> 2 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/dim b/dim
> index baa0b3832314..79738a1b37a0 100755
> --- a/dim
> +++ b/dim
> @@ -340,6 +340,15 @@ function git_branch_exists # branch
> fi
> }
>
> +function git_committer_email
> +{
> + if ! commiter_email=$(git config --get user.email) ; then
> + commiter_email=$EMAIL
> + fi
> +
> + echo $commiter_email
> +}
> +
> # get message id from file
> # $1 = file
> message_get_id ()
> @@ -632,11 +641,32 @@ function dim_rebuild_tip
> exit 1
> fi
> }
> +
> +# additional patch checks before pushing, e.g. for r-b tags
> +function checkpatch_commit_push
> +{
> + local sha1
> +
> + sha1=$1
> +
> + # check for a-b/r-b tag
> + if git show -s $sha1 | grep -qi '\(reviewed\|acked\)\S*-by:' ; then
> + return
> + fi
> +
> + # check for commiter != author
> + if [[ $(git show -s $sha1 --format="format:%ce") != $(git show -s $sha1
> --format="format:%ae") ]]; then
> + return
> + fi
> +
> + warn_or_fail "$sha1 is lacking mandatory review"
> +}
> +
> # push branch $1, rebuild drm-tip. the rest of the arguments are passed to
> git
> # push.
> function dim_push_branch
> {
> - local branch remote
> + local branch remote commiter_email
>
> branch=${1:?$usage}
> shift
> @@ -645,6 +675,12 @@ function dim_push_branch
>
> remote=$(branch_to_remote $branch)
>
> + commiter_email=$(git_committer_email)
> +
> + for sha1 in $(git rev-list $branch@{u}..$branch
> --committer="$commiter_email" --no-merges) ; do
> + checkpatch_commit_push $sha1
> + done
> +
> git push $DRY_RUN $remote $branch "$@"
>
> update_linux_next $branch drm-intel-next-queued drm-intel-next-fixes
> drm-intel-fixes
> @@ -690,9 +726,7 @@ function dim_apply_branch
>
> message_id=$(message_get_id $file)
>
> - if ! commiter_email=$(git config --get user.email) ; then
> - commiter_email=$EMAIL
> - fi
> + commiter_email=$(git_committer_email)
>
> patch_from=$(grep "From:" "$file" | head -1)
> if [[ "$patch_from" != *"$commiter_email"* ]] ; then
> diff --git a/drm-misc.rst b/drm-misc.rst
> index caba8dc77696..d56c3c7f92a3 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -90,7 +90,9 @@ Merge Criteria
> Right now the only hard merge criteria are:
>
> * Patch is properly reviewed or at least Ack, i.e. don't just push your own
> - stuff directly.
> + stuff directly. This rule holds even more for bugfix patches - it would be
> + embarrassing if the bugfix contains a small gotcha that review would have
> + caught.
>
> * drm-misc is for drm core (non-driver) patches, subsystem-wide refactorings,
>and small trivial patches all over (including drivers). For a detailed
> list of
>
Reviewed-by: Neil Armstrong <narmstr...@baylibre.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 4/5] mfd: cros-ec: Introduce CEC commands and events definitions.
From: Stefan Adolfsson <sadolfs...@chromium.org>
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
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(_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 *)
+ static int cmd_version = 1;
int ret;
+ BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
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(_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_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_g
[Intel-gfx] [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (!strcmp(dev_name(n->dev), name) &&
+ (!conn || !strcmp(n->conn, conn))) {
+ kref_get(>kref);
+ mutex_unlock(_notifiers_lock);
+ return n;
+ }
+ }
+ mutex_unlock(_notifiers_lock);
+
+ return NULL;
+}
+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(_notifiers_lock);
+ list_for_each_entry(n, _notifiers, head) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(>lock);
kref_init(>kref);
@@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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 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 +62,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
[Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
---
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");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
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.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
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
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 <narmstr...@baylibre.com>
+ */
+
+#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;
+ memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+ cec_received_msg(cros_ec_cec->adap, _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);
+
+ if (events & EC_MKBP_CEC_SEND_FAILED)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_ERROR);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+ unsigned long queued_during_suspend, void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_device *cros_ec;
+
+ cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+ cros_ec = cros_ec_cec->cros_ec;
+
+ if (cros_ec->event_data.event_type == EC_MKBP_CEC_EVENT) {
+ handle_cec_event(cros_ec_cec);
[Intel-gfx] [RFC PATCH 1/5] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
---
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, _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);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 0/5] Add ChromeOS EC CEC Support
Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support throught 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 ! Neil Armstrong (5): mfd: cros_ec_dev: Add CEC sub-device registration media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Introduce CEC commands and events definitions. media: platform: Add Chrome OS EC CEC driver drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 10 + drivers/media/cec/cec-notifier.c | 30 ++- 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 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 42 +++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 80 +++ include/media/cec-notifier.h | 44 +++- 12 files changed, 556 insertions(+), 15 deletions(-) create mode 100644 drivers/media/platform/cros-ec/Makefile create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c -- 2.7.4 ___ 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 15/05/2018 08:29, Hans Verkuil wrote:
> 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 <narmstr...@baylibre.com>
>> ---
>> 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?
Because I failed to find a safe place for this !
I will have a second look...
>
> 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 5/5] media: platform: Add Chrome OS EC CEC driver
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 <narmstr...@baylibre.com>
>> ---
>> 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 <narmstr...@baylibre.com>
>> + */
>> +
>> +#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;
>> +};
>> +
>> +st
Re: [Intel-gfx] [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name
On 15/05/2018 08:27, Hans Verkuil wrote:
> 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 <narmstr...@baylibre.com>
>> ---
>> 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(_notifiers_lock);
>> list_for_each_entry(n, _notifiers, head) {
>> -if (n->dev == dev) {
>> +if (!strcmp(dev_name(n->dev), name) &&
>> +(!conn || !strcmp(n->conn, conn))) {
>> +kref_get(>kref);
>> +mutex_unlock(_notifiers_lock);
>> +return n;
>> +}
>> +}
>> +mutex_unlock(_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()?
Yes, it's safer and will keep the original cec_notifier_get() behavior.
>
>> +}
>> +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(_notifiers_lock);
>> +list_for_each_entry(n, _notifiers, head) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>> kref_get(>kref);
>> mutex_unlock(_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.
Ok
>
>> n->phys_addr = CEC_PHYS_ADDR_INVALID;
>> mutex_init(>lock);
>> kref_init(>kref);
>> @@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>> mutex_unlock(_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.
Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 15/05/2018 08:34, Hans Verkuil wrote: > 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 <narmstr...@baylibre.com> >> --- >> 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 OK, thanks > > 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
[Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
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 <narmstr...@baylibre.com>
---
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 | 335 +++
4 files changed, 349 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..aed3368
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong <narmstr...@baylibre.com>
+ */
+
+#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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_dev
[Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
---
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, _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);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
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(_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 *)
+ static int cmd_version = 1;
int ret;
+ BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
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(_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_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_res
Re: [Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
Hi,
On 15/05/2018 14:56, Hans Verkuil wrote:
> 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?
I just figured it out, I was busy on the CEC driver and notifier, will re-spin
a v2 with this and the other small fixes you requested.
Thanks,
Neil
>
> Regards,
>
> Hans
>
>>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>> 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
[Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 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.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
_
[Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support
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 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 (5): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add Chrome OS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 12 + 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 | 335 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 42 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 80 ++ include/media/cec-notifier.h | 27 +- 13 files changed, 526 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 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
Hi Ville,
On 15/05/2018 17:35, Ville Syrjälä wrote:
> On Tue, May 15, 2018 at 04:42:19PM +0200, 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 <narmstr...@baylibre.com>
>> ---
>> 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(+)
>>
[..]
>> }
>>
>> @@ -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);
>
> What are we doing with the connector name here? Those are not actually
> guaranteed to be stable, and any change in the connector probe order
> may cause the name to change.
The i915 driver can expose multiple HDMI connectors, but each connected will
have a different EDID and CEC physical address, so we will need a different
notifier
for each connector.
The connector name is DRM dependent, but user-space actually uses this name for
operations, so I supposed it was kind of stable.
Anyway, is there another stable id/name/whatever that can be used to make a
name to
distinguish the HDMI connectors ?
Neil
>
>> +if (!intel_hdmi->notifier)
>> +DRM_DEBUG_KMS("CEC notifier get failed\n");
>> }
>>
>> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>> --
>> 2.7.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
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.
Hi Hans,
On 15/05/2018 17:28, Hans Verkuil wrote:
> 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 <sadolfs...@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>> 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(_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 *)
>> +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?
This is taken from the chrome kernelk, to be sure the size is ok, but yes it
should be 16, I'll see
if I can drop this.
>
>> +
>> 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(_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 {
>>
Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
Hi Enric,
On 15/05/2018 18:40, Enric Balletbo Serra wrote:
> Hi Neil,
>
> I suspect that this patch will conflict with some patches that will be
> queued for 4.18 that also introduces new devices, well, for now I
> don't see these merged in the Lee's tree.
Indeed, I found your patches, I'll rebase this one when Lee pushes them in his
tree.
>
> Based on some reviews I got when I send a patch to this file ...
>
> 2018-05-15 17:29 GMT+02:00 Hans Verkuil <hverk...@xs4all.nl>:
>> 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 <narmstr...@baylibre.com>
>>
>> For what it is worth (not an MFD expert):
>>
>> Acked-by: Hans Verkuil <hans.verk...@cisco.com>
>>
>> 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, _cell, 1, NULL, 0, NULL);
>>> + if (ret)
>>> + dev_err(ec->dev, "failed to add EC CEC\n");
>>> +}
>>> +
>
> Do not create a single function to only call mfd_add_devices, instead
> do the following on top:
>
> static const struct mfd_cell cros_ec_cec_cells[] = {
> { .name = "cros-ec-cec" }
> };
OK
>
>
>>> 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);
>>> +
>
> and use PLATFORM_DEVID_AUTO and the ARRAY_SIZE macro, something like this.
>
> /* Check whether this EC instance handles CEC */
> 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);
> }
Ok, like the RTC registration.
Thanks,
Neil
>
> Best regards,
> Enric
>
>>> /* Take control of the lightbar from the EC. */
>>> lb_manual_suspend_ctrl(ec, 1);
>>>
>>>
>>
>> ___
>> 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 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 16/05/2018 09:31, Neil Armstrong wrote:
> Hi Ville,
>
> On 15/05/2018 17:35, Ville Syrjälä wrote:
>> On Tue, May 15, 2018 at 04:42:19PM +0200, 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 <narmstr...@baylibre.com>
>>> ---
>>> 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(+)
>>>
>
> [..]
>
>>> }
>>>
>>> @@ -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);
>>
>> What are we doing with the connector name here? Those are not actually
>> guaranteed to be stable, and any change in the connector probe order
>> may cause the name to change.
>
> The i915 driver can expose multiple HDMI connectors, but each connected will
> have a different EDID and CEC physical address, so we will need a different
> notifier
> for each connector.
>
> The connector name is DRM dependent, but user-space actually uses this name
> for
> operations, so I supposed it was kind of stable.
>
> Anyway, is there another stable id/name/whatever that can be used to make a
> name to
> distinguish the HDMI connectors ?
Would "HDMI %c", port_name(port) be OK to use ?
Neil
>
> Neil
>
>>
>>> + if (!intel_hdmi->notifier)
>>> + DRM_DEBUG_KMS("CEC notifier get failed\n");
>>> }
>>>
>>> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>>> --
>>> 2.7.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
---
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, _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);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
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 <narmstr...@baylibre.com>
---
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 <narmstr...@baylibre.com>
+ */
+
+#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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+ unsigned lo
[Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
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(_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 *)
+ static int cmd_version = 1;
int ret;
+ BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
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(_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_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_res
[Intel-gfx] [PATCH 1/5] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>head);
+ if (n->conn)
+ 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);
+}
+
static inline void cec_notifier_put(struct cec_notifier *n)
{
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Add ChromeOS EC CEC Support
Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support throught 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 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 (5): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add Chrome OS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 10 + drivers/media/cec/cec-notifier.c | 12 +- 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 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 42 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 80 ++ include/media/cec-notifier.h | 30 +- 13 files changed, 530 insertions(+), 15 deletions(-) create mode 100644 drivers/media/platform/cros-ec-cec/Makefile create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c -- 2.7.4 ___ 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 15/05/2018 17:22, Hans Verkuil wrote:
> 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?
The driver exposes 2 HDMI connectors (I suspect one is connected to the USB-C
alt mode mux along the DP port),
and only one connected has the CEC line connected to the Embedded Controller.
Neil
>
> Regards,
>
> Hans
>
>>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>> 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(_notifiers_lock);
>> list_for_each_entry(n, _notifiers, head) {
>> -if (n->dev == dev) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>> kref_get(>kref);
>> mutex_unlock(_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(>lock);
>> kref_init(>kref);
>> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>> mutex_unlock(_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(>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_g
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
Hi Ville,
On 16/05/2018 16:07, Ville Syrjälä wrote:
> On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
>> On 16/05/2018 09:31, Neil Armstrong wrote:
>>> Hi Ville,
>>>
>>> On 15/05/2018 17:35, Ville Syrjälä wrote:
>>>> On Tue, May 15, 2018 at 04:42:19PM +0200, 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 <narmstr...@baylibre.com>
>>>>> ---
>>>>> 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(+)
>>>>>
>>>
>>> [..]
>>>
>>>>> }
>>>>>
>>>>> @@ -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);
>>>>
>>>> What are we doing with the connector name here? Those are not actually
>>>> guaranteed to be stable, and any change in the connector probe order
>>>> may cause the name to change.
>>>
>>> The i915 driver can expose multiple HDMI connectors, but each connected will
>>> have a different EDID and CEC physical address, so we will need a different
>>> notifier
>>> for each connector.
>>>
>>> The connector name is DRM dependent, but user-space actually uses this name
>>> for
>>> operations, so I supposed it was kind of stable.
>>>
>>> Anyway, is there another stable id/name/whatever that can be used to make a
>>> name to
>>> distinguish the HDMI connectors ?
>>
>> Would "HDMI %c", port_name(port) be OK to use ?
>
> Yeah, something like seems like a reasonable approach. That does mean
> we have to be a little careful with changing enum port or port_name()
> in the future, but I guess we could just add a small function to
> generated the name/id specifically for this thing.
>
> We're also going to have to think what to do with enum port and
> port_name() on ICL+ though. There we won't just have A-F but also
> TC1-TC. Hmm. Looks like what we have for those ports in our
> codebase ATM is a bit wonky since we haven't even changed
> port_name() to give us the TC type names.
>
> Also we might not want "HDMI" in the identifier since the physical
> port is not HDMI specific. There are different things we could call
> these but I think we could just go with a generic "Port A-F" and
> "Port TC1-TC" approach. I think something like that should work
> fine for current and upcoming hardware. And in theory that could
> then be used for other things as well which need a stable
> identifier.
>
> Oh, and now I recall that input subsystem at least has some kind
> of "physical path" property on devices. So I guess what we're
> dicussing is a somewhat similar idea. I think input drivers
> generally include the pci/usb/etc. device in the path as well.
> Even though we currently only ever have the one pci device it
> would seem like decent idea to include that information in our
> identifiers as well. Or what do you think?
>
Thanks for the clarifications !
Having a "Port " will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.
The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :
const char *port_identifier(struct drm_i915_private *dev_priv,
enum port port)
{
char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);
if (id)
return NULL;
snprintf("Port %c", port_name(port));
return id;
}
and use the result of this for the cec_notifier connector name ?
Neil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/5] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 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.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
_
[Intel-gfx] [PATCH v4 5/5] media: platform: Add ChromeOS EC CEC driver
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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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 <narmstr...@baylibre.com>
+ */
+
+#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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_n
[Intel-gfx] [PATCH v4 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/5] Add ChromeOS EC CEC Support
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 v3 (incorrectly reported as v2): - Renamed "Chrome OS" to "ChromeOS" - Updated cros_ec_commands.h new structs definitions to kernel doc format - Added Reviwed-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 (5): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi 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 | 20 ++ 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 | 103 +++ include/media/cec-notifier.h | 27 +- 14 files changed, 580 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 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
drivers/platform/chrome/cros_ec_proto.c | 40 ++---
include/linux/mfd/cros_ec.h | 2 +-
include/linux/mfd/cros_ec_commands.h| 103
3 files changed, 135 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(_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 *)
+ 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(_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..9b8bc4a 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_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
[Intel-gfx] [PATCH v4 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 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_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
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..d522b5b 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,11 @@ 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,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support
On 18/05/2018 16:04, Enric Balletbo Serra wrote: > Hi Neil, > > 2018-05-18 15:04 GMT+02:00 Neil Armstrong <narmstr...@baylibre.com>: >> 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 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 >> > > Just because I got confused when I saw two v2 in my inbox. This is v3, right? Yes, sorry it's v3... next will be v4. > >> 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 (5): >> media: cec-notifier: Get notifier by device and connector name >> drm/i915: hdmi: add CEC notifier to intel_hdmi >> mfd: cros-ec: Introduce CEC commands and events definitions. >> mfd: cros_ec_dev: Add CEC sub-device registration >> media: platform: Add Chrome OS EC CEC driver >> >> drivers/gpu/drm/i915/Kconfig | 1 + >> drivers/gpu/drm/i915/intel_display.h | 20 ++ >> 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 | 80 ++ >> include/media/cec-notifier.h | 27 +- >> 14 files changed, 557 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 >> >> -- >> 2.7.4 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/6] mfd: cros-ec: Increase maximum mkbp event size
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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(_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 *)
+ 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(_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
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
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 <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/6] Add ChromeOS EC CEC Support
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 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 Reviwed-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 | 20 ++ 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 | 104 +++ 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 -- 2.7.4 ___ 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.
Hi Benson,
On 24/05/2018 07:47, Benson Leung wrote:
> Hi Neil, Hi Stefan,
>
> On Fri, May 18, 2018 at 03:05:02PM +0200, 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 <sadolfs...@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>
> It looks like this change squashes together this chromeos-4.4 CL
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1061879
> and some other new changes to add cec to cros_ec_commands.
>
> Could you separate the two? One patch that's as close to Stefan's
> which introduces the 16 byte mkbp, and a second one that
> adds the HDMI CEC commands?
OK, will split.
Neil
>
> Thanks,
> Benson
>> ---
>> drivers/platform/chrome/cros_ec_proto.c | 40 +
>> include/linux/mfd/cros_ec.h | 2 +-
>> include/linux/mfd/cros_ec_commands.h| 80
>> +
>> 3 files changed, 112 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(_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 *)
>> +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(_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..16c3a2b 100644
>> --- a/include/
[Intel-gfx] [PATCH v5 6/6] media: platform: Add ChromeOS EC CEC driver
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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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 <narmstr...@baylibre.com>
+ */
+
+#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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_n
Re: [Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On 24/05/2018 11:11, Hans Verkuil wrote:
> 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 <narmstr...@baylibre.com>
>> Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
>> ---
>> 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.
Yes, it will make sense.
>
>> +
>> +/* 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_?
Exact, I will prefix them.
Thanks,
Neil
>
> 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
[Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 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_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
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..d522b5b 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,11 @@ 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,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 6/6] media: platform: Add ChromeOS EC CEC driver
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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
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..7bc4d8a
--- /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 <narmstr...@baylibre.com>
+ */
+
+#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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_
[Intel-gfx] [PATCH v6 0/6] Add ChromeOS EC CEC Support
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 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 | 20 ++ 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, 577 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 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
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 <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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
+
+/* 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 {
+ /* 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
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 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_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
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..d522b5b 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,11 @@ 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,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/6] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 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.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physi
[Intel-gfx] [PATCH v5 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/6] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 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.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
_
[Intel-gfx] [PATCH v6 3/6] mfd: cros-ec: Increase maximum mkbp event size
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
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(_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 *)
+ 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(_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
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name
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 <narmstr...@baylibre.com>
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 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.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
_
[Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
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 <narmstr...@baylibre.com>
---
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..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..7e1e275
--- /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 Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong <narmstr...@baylibre.com>
+ */
+
+#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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_dev
[Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
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 <narmstr...@baylibre.com>
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
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 <narmstr...@baylibre.com>
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 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_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
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..d522b5b 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,11 @@ 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,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support
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 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 (5): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add Chrome OS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_display.h | 20 ++ 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 | 80 ++ include/media/cec-notifier.h | 27 +- 14 files changed, 557 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 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
drivers/platform/chrome/cros_ec_proto.c | 40 +
include/linux/mfd/cros_ec.h | 2 +-
include/linux/mfd/cros_ec_commands.h| 80 +
3 files changed, 112 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(_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 *)
+ 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(_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..16c3a2b 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_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
Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 15/05/2018 10:10, Hans Verkuil wrote: > 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 <narmstr...@baylibre.com> >>>> --- >>>> 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? Forgot this one, moved to cros-ec-cec directory. >>> >>>> >>>> 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 <narmstr...@baylibre.com> >&g
Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name
Hi Sean,
On 18/05/2018 17:48, Sean Paul wrote:
> On Fri, May 18, 2018 at 03:05:00PM +0200, 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 <narmstr...@baylibre.com>
>
> Hi Neil,
> Thanks for posting these!
>
>> ---
>> 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(_notifiers_lock);
>> list_for_each_entry(n, _notifiers, head) {
>> -if (n->dev == dev) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>> kref_get(>kref);
>> mutex_unlock(_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(>lock);
>> kref_init(>kref);
>> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>> mutex_unlock(_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(>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
>
> Probably best to use "name" instead of connector, since it doesn't necessarily
> _have_ to be a connector name. So, cec_notifier_get_by_name(dev, name)
I don't have a stong opinion, but since the CEC is tied to a connector, it
should
mention connector, maybe conn_name ?
>
>> *
>> * 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
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
Hi Ville,
On 18/05/2018 15:24, Ville Syrjälä wrote:
> On Fri, May 18, 2018 at 03:05:01PM +0200, 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 <narmstr...@baylibre.com>
>> ---
>> drivers/gpu/drm/i915/Kconfig | 1 +
>> drivers/gpu/drm/i915/intel_display.h | 20
>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>> 4 files changed, 36 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_display.h
>> b/drivers/gpu/drm/i915/intel_display.h
>> index 4e7418b..c68d1c8 100644
>> --- a/drivers/gpu/drm/i915/intel_display.h
>> +++ b/drivers/gpu/drm/i915/intel_display.h
>> @@ -126,6 +126,26 @@ enum port {
>>
>> #define port_name(p) ((p) + 'A')
>>
>> +static inline const char *port_identifier(enum port port)
>> +{
>> +switch (port) {
>> +case PORT_A:
>> +return "Port A";
>> +case PORT_B:
>> +return "Port B";
>> +case PORT_C:
>> +return "Port C";
>> +case PORT_D:
>> +return "Port D";
>> +case PORT_E:
>> +return "Port E";
>> +case PORT_F:
>> +return "Port F";
>> +default:
>> +return "";
>> +}
>> +}
>
> I don't think we need this in the header. A static function will do.
I just followed how other functions were declared, in the same way.
> And I was actually thinking something a bit fancier like:
> snprintf("%s/port-%s", dev_name(dev), port_id(port));
>
> Oh, I see you already pass the device in so I guess we don't need
> that in the port id?
Indeed, my bad I forgot to answer your last question, we already pass a struct
device which provides the device bus, name and id, so it's unneeded here.
>
>> +
>> enum dpio_channel {
>> DPIO_CH0,
>> DPIO_CH1
>> 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;
>
> I was wondering if we need any ifdefs around this stuff, but I guess not
> since it's just a pointer and all the functions seem to have empty
> static inlines for the CEC=n case.
>
>> };
>>
>> 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..d522b5b 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 @
Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
Hi Enric,
On 18/05/2018 17:02, Enric Balletbo Serra wrote:
> Hi Neil,
>
> 2018-05-18 15:05 GMT+02:00 Neil Armstrong <narmstr...@baylibre.com>:
>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
>
> A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS
> Embedded Controller" or "ChromeOS EC". Yes, I know that you can see in
> the kernel many other ways to refer to the ChromeOS EC, but to
> standardize a little bit, could you replace all occurrences s/Chrome
> OS/ChromeOS/. Thanks.
Ok, I'll do a cleanup.
>
>> 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 <narmstr...@baylibre.com>
>> ---
>> 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..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"
>
> here
>
>> + 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.
>
> here
>
>> + 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..7e1e275
>> --- /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 Chrome OS Embedded Controller
>
> and here
>
>> + *
>> + * Copyright (c) 2018 BayLibre, SAS
>> + * Author: Neil Armstrong <narmstr...@baylibre.com>
>> + */
>> +
>> +#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 {
>
Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
Hi Enric,
On 18/05/2018 18:19, Enric Balletbo Serra wrote:
> Hi Neil,
>
> 2018-05-18 15:05 GMT+02:00 Neil Armstrong <narmstr...@baylibre.com>:
>> 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 <sadolfs...@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>> drivers/platform/chrome/cros_ec_proto.c | 40 +
>> include/linux/mfd/cros_ec.h | 2 +-
>> include/linux/mfd/cros_ec_commands.h| 80
>> +
>> 3 files changed, 112 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(_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 *)
>> + static int cmd_version = 1;
>
> Personal opinion, but I don't like this static here, and also I don't
> think this is scalable. Could we ask for the command version?
I don't have an opinion, I only followed how it was implemented on the
chromeos kernel and adapted to mainline. If you have a better way, I'll use it !
>
>> 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(_dev->event_data, msg->data,
>> - sizeof(ec_dev->event_data));
>> + /* Fallback to version 0 for future send attempts */
>> + cmd_version = 0;
>> }
>>
>
> So we always do a failed transfer on all these EC devices that does
> not support CEC. I am wondering if wouldn't be better pass the command
> version to the cros_ec_get_next_event function. The driver should know
> which version to use, just a random idea.
No, the driver cannot know the command version, this depends on the FW version
and the platform. AFAIK this must be discovered.
>
>> + 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_noti
Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support
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 for media to merge the mfd branch + patch 7 ? 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 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/i
Re: [Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
Hi Lee,
On 18/06/2018 09:44, Lee Jones wrote:
> On Fri, 01 Jun 2018, 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
>> ---
>> 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(_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 *)
>> +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(_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 */
>
> That's funny!
>
>> +uint32_t host_event;
>> +
>> +uint32_t buttons;
>> +uint32_t switches;
>> +uint32_t sysrq;
>> +uint32_t cec_events;
>> +uint8_tcec_message[16];
>
> Since there are some whitespace alignment issues in here.
>
>> +} __packed;
>
> How come these guys have kerneldoc headers?
Can you explicit what should be changed here ?
Thanks,
Neil
>
>> 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_BUTTON0
>
___
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
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 > > 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 6/6] media: platform: Add ChromeOS EC CEC driver
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
---
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..7bc4d8a
--- /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, _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_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_devic
[Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support
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 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 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
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
Reviewed-by: Ville Syrjälä
Acked-by: Rodrigo Vivi
---
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 +
4 files changed, 40 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_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..70a365f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,30 @@ enum port {
#define port_name(p) ((p) + 'A')
+/*
+ * Ports identifier referenced from other drivers.
+ * Expected to remain stable over time
+ */
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..a4e188d 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 *cec_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..0bd7549 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->cec_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->cec_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)->cec_notifier)
+ cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2358,6 +2366,11 @@ 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->cec_notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+ if (!intel_hdmi->cec_notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
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
---
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(_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 *)
+ 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(_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
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
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
Acked-by: Hans Verkuil
---
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,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
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
---
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 functionality, 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 functionality 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
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/6] media: cec-notifier: Get notifier by device and connector name
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
---
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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 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.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
___
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 30/05/2018 17:29, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, 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
>> ---
>> drivers/gpu/drm/i915/Kconfig | 1 +
>> drivers/gpu/drm/i915/intel_display.h | 20
>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>> 4 files changed, 36 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_display.h
>> b/drivers/gpu/drm/i915/intel_display.h
>> index 4e7418b..c68d1c8 100644
>> --- a/drivers/gpu/drm/i915/intel_display.h
>> +++ b/drivers/gpu/drm/i915/intel_display.h
>> @@ -126,6 +126,26 @@ enum port {
>>
>> #define port_name(p) ((p) + 'A')
>>
>> +static inline const char *port_identifier(enum port port)
>> +{
>> +switch (port) {
>> +case PORT_A:
>> +return "Port A";
>> +case PORT_B:
>> +return "Port B";
>> +case PORT_C:
>> +return "Port C";
>> +case PORT_D:
>> +return "Port D";
>> +case PORT_E:
>> +return "Port E";
>> +case PORT_F:
>> +return "Port F";
>> +default:
>> +return "";
>> +}
>> +}
>
> Could use a comment to make it clear that this identifier is
> expected to remain stable since it's referenced from other drivers.
>
>> +
>> enum dpio_channel {
>> DPIO_CH0,
>> DPIO_CH1
>> 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;
>
> "notifier" seems a bit too generic a name. "cec_notifier" would be
> better.
OK
>
> Apart from that this seems OK to me
> Reviewed-by: Ville Syrjälä
Thanks for the review !
Neil
>
>> };
>>
>> 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..d522b5b 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;
>> }
&
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 31/05/2018 01:26, Rodrigo Vivi wrote:
> On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
>> On Thu, May 24, 2018 at 11:57:17AM +0200, 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
>>> ---
>>> drivers/gpu/drm/i915/Kconfig | 1 +
>>> drivers/gpu/drm/i915/intel_display.h | 20
>>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>>> 4 files changed, 36 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_display.h
>>> b/drivers/gpu/drm/i915/intel_display.h
>>> index 4e7418b..c68d1c8 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.h
>>> +++ b/drivers/gpu/drm/i915/intel_display.h
>>> @@ -126,6 +126,26 @@ enum port {
>>>
>>> #define port_name(p) ((p) + 'A')
>>>
>>> +static inline const char *port_identifier(enum port port)
>>> +{
>>> + switch (port) {
>>> + case PORT_A:
>>> + return "Port A";
>>> + case PORT_B:
>>> + return "Port B";
>>> + case PORT_C:
>>> + return "Port C";
>>> + case PORT_D:
>>> + return "Port D";
>>> + case PORT_E:
>>> + return "Port E";
>>> + case PORT_F:
>>> + return "Port F";
>>> + default:
>>> + return "";
>>> + }
>>> +}
>>
>> Could use a comment to make it clear that this identifier is
>> expected to remain stable since it's referenced from other drivers.
>>
>>> +
>>> enum dpio_channel {
>>> DPIO_CH0,
>>> DPIO_CH1
>>> 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;
>>
>> "notifier" seems a bit too generic a name. "cec_notifier" would be
>> better.
>>
>> Apart from that this seems OK to me
>> Reviewed-by: Ville Syrjälä
>
> It seems that you will need to push this to other trees right?
> Feel free to use:
>
> Acked-by: Rodrigo Vivi
You are right, it will useful, thanks !
Neil
>
>>
>>> };
>>>
>>> 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..d522b5b 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-&g
Re: [Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
Hi Lee,
On 03/07/2018 11:43, Lee Jones wrote:
> On Mon, 18 Jun 2018, Neil Armstrong wrote:
>
>> Hi Lee,
>>
>> On 18/06/2018 09:44, Lee Jones wrote:
>>> On Fri, 01 Jun 2018, 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
>>>> ---
>>>> 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(_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 *)
>>>> + 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(_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;
>>>> };
>>>
Re: [Intel-gfx] [GIT PULL] Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 merge window
Hi Dave, Rodrigo. On 13/07/2018 09:46, Lee Jones wrote: > Enjoy! > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > ib-mfd-i915-media-platform-v4.19 > > for you to fetch changes up to cd70de2d356ee692477276bd5d6bc88c71a48733: > > media: platform: Add ChromeOS EC CEC driver (2018-07-13 08:44:46 +0100) > > > Immutable branch between MFD and DRM/i915, Media and Platform due for the > v4.19 merge window This PR is here to solve a complex interdependency over this patchset, Hans agreed all the media patches go to the MFD tree and Rodrigo acked the i915 patch so it could be applied to another tree, but who is suposed to take this PR to the DRM tree ? Neil > > -------- > 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 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
Hi Lee, On 04/07/2018 09:47, Lee Jones wrote: > On Fri, 01 Jun 2018, 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 >> Acked-by: Hans Verkuil >> --- >> drivers/mfd/cros_ec_dev.c | 16 >> 1 file changed, 16 insertions(+) > > For my own reference: > Acked-for-MFD-by: Lee Jones > Should I keep these Acked-for-MFD-by for the v8 ? Neil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
