On Tue, Apr 03, 2018 at 07:27:18PM +0530, Ramalingam C wrote:
> Notifier Chain is defined to inform all its clients about the mei
> client device state change. Routine is defined for the clients to
> register and unregister for the notification on state change.
>
> v2:
> Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
>
> Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx>
For managing interactions between multiple drivers notifier chains are
fairly problematic. The main reason is the locking embedded in the
notifier chain. To make things safe, that lock must be held everytime we
add/remove any part of the link, and when calling any callback. Usually
that means you get a neat deadlock sooner or later, because the
load/unload code has inverse paths compared to normal operation.
Notifiers also not not provide a clean way to handle suspend/resume
ordering.
There's two parts to do this properly.
1. Finding the other driver. Multi-part drivers are assembled nowadays
using the component framework. We're using that already to manage the
interaction between drm/i915 and snd-hda. If not all components are ready
yet, then the driver load sequence must be aborted by returning
-EPROBE_DEFER. That's going to be lots of fun, since for the mei/i915
interaction it's probably going to be i915 that needs to abort and retry
the driver load. But we do CI test all the abort points in our driver
load, so should work well.
2. Handling the ordering restrictions for suspend/resume. For i915/snd-hda
we used a early_resume/late_suspend callback trickery, but that doesn't
really scale to multiple levels. Since we've done that device_link has
been added. As a bonus device_link can also ensure that not only
suspend/resume (including runtime suspend/resume) is ordered correctly,
but also that driver bind/unbind works correctly. Still needs the
component stuff and initial -EPROBE_DEFER, but will all least make sure
we' only reprobe once more. See device_link_add + docs in device_link.rst.
One thing I didn't check is whether we want the device linke to also
manage runtime pm for us. It would mean that we keep the ME awake as long
as anything is using the gpu (any display on or any rendering happening).
That might be too much, but could also be that it won't matter (and then
using DL_FLAG_PM_RUNTIME would simply our code).
We might also need to convert the i915/snd-hda interactions to device_link
first, since the early/late_resume/suspend hack probably doesn't interact
too well with proper device_links.
Cheers, Daniel
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 36 +++++++++++++++++++++++++++---
> include/linux/mei_hdcp.h | 48 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 81 insertions(+), 3 deletions(-)
> create mode 100644 include/linux/mei_hdcp.h
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
> index b334615728a7..2811a25f8c57 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -31,6 +31,32 @@
> #include <linux/slab.h>
> #include <linux/uuid.h>
> #include <linux/mei_cl_bus.h>
> +#include <linux/notifier.h>
> +#include <linux/mei_hdcp.h>
> +
> +static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
> +
> +void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
> +{
> + if (enabled)
> + blocking_notifier_call_chain(&mei_cldev_notifier_list,
> + MEI_CLDEV_ENABLED, cldev);
> + else
> + blocking_notifier_call_chain(&mei_cldev_notifier_list,
> + MEI_CLDEV_DISABLED, NULL);
> +}
> +
> +int mei_cldev_register_notify(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&mei_cldev_notifier_list, nb);
> +}
> +EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
> +
> +int mei_cldev_unregister_notify(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&mei_cldev_notifier_list, nb);
> +}
> +EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
>
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id)
> @@ -38,14 +64,18 @@ static int mei_hdcp_probe(struct mei_cl_device *cldev,
> int ret;
>
> ret = mei_cldev_enable(cldev);
> - if (ret < 0)
> + if (ret < 0) {
> dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
> + return ret;
> + }
>
> - return ret;
> + mei_cldev_state_notify_clients(cldev, true);
> + return 0;
> }
>
> static int mei_hdcp_remove(struct mei_cl_device *cldev)
> {
> + mei_cldev_state_notify_clients(cldev, false);
> mei_cldev_set_drvdata(cldev, NULL);
> return mei_cldev_disable(cldev);
> }
> @@ -71,4 +101,4 @@ module_mei_cl_driver(mei_hdcp_driver);
>
> MODULE_AUTHOR("Intel Corporation");
> MODULE_LICENSE("Dual BSD/GPL");
> -MODULE_DESCRIPTION("HDCP");
> +MODULE_DESCRIPTION("MEI HDCP");
> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
> new file mode 100644
> index 000000000000..3b46bebde718
> --- /dev/null
> +++ b/include/linux/mei_hdcp.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> +/*
> + * Copyright © 2017-2018 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
> + * OF THIS SOFTWARE.
> + *
> + * Authors:
> + * Ramalingam C <ramalingam.c@xxxxxxxxx>
> + */
> +
> +#ifndef _LINUX_MEI_HDCP_H
> +#define _LINUX_MEI_HDCP_H
> +
> +enum mei_cldev_state {
> + MEI_CLDEV_DISABLED,
> + MEI_CLDEV_ENABLED
> +};
> +
> +#ifdef CONFIG_INTEL_MEI_HDCP
> +int mei_cldev_register_notify(struct notifier_block *nb);
> +int mei_cldev_unregister_notify(struct notifier_block *nb);
> +#else
> +static int mei_cldev_register_notify(struct notifier_block *nb)
> +{
> + return -ENODEV;
> +}
> +static int mei_cldev_unregister_notify(struct notifier_block *nb)
> +{
> + return -ENODEV;
> +}
> +#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
> +#endif /* defined (_LINUX_MEI_HDCP_H) */
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
