* [PATCH v12 00/38] drm/i915: Implement HDCP2.2
@ 2019-02-09 7:11 Ramalingam C
2019-02-09 7:11 ` [PATCH v12 01/38] drm/doc: document recommended component helper usage Ramalingam C
0 siblings, 1 reply; 6+ messages in thread
From: Ramalingam C @ 2019-02-09 7:11 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel.vetter, tomas.winkler, uma.shankar
This series enables the HDCP2.2 Type 0 for I915. The sequence for
HDCP2.2 authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver for mei bus, so that for HDCP2.2
authentication, HDCP2.2 stack in I915 can avail the services from
ME FW. To enable this client driver set the config variable
CONFIG_INTEL_MEI_HDCP.
Userspace interface remains unchanged as version agnostic. When
userspace request for HDCP enable, Kernel will detect the HDCP source
and sink's HDCP version(1.4/2.2)capability and enable the best capable
version for that combination.
This series enables the HDCP2.2 for Type0 content streams.
Test-with: <1549566452-30175-1-git-send-email-ramalingam.c@intel.com>
Major changes in v12
- hdcp disable from unbind is removed.
- hdcp component init and del are moved away from conenctor ops.
- Review comemnts from Tomas are addressed. [Tomas]
- Collected the r-bs and Acks given for v11.
- ICL mei dev id patch is cherry-picked from
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git char-misc-linus
- Changes for component framework are merged into drm-tip already.
To ease the review process, series is hosted at
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v12
Daniel Vetter (1):
drm/doc: document recommended component helper usage
Ramalingam C (34):
drm/i915: Gathering the HDCP1.4 routines together
drm: header for i915 - MEI_HDCP interface
drm/i915: Initialize HDCP2.2
drm/i915: MEI interface definition
drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
drm/i915: Enable and Disable of HDCP2.2
drm/i915: Implement HDCP2.2 receiver authentication
drm: helper functions for hdcp2 seq_num to from u32
drm/i915: Implement HDCP2.2 repeater authentication
drm: HDCP2.2 link check period
drm/i915: Implement HDCP2.2 link integrity check
drm/i915: Handle HDCP2.2 downstream topology change
drm: removing the DP Errata msg and its msg id
drm/i915: Implement the HDCP2.2 support for DP
drm/i915: Implement the HDCP2.2 support for HDMI
drm/i915: CP_IRQ handling for DP HDCP2.2 msgs
drm/i915: Fix KBL HDCP2.2 encrypt status signalling
misc/mei/hdcp: Client driver for HDCP application
misc/mei/hdcp: Define ME FW interface for HDCP2.2
misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
misc/mei/hdcp: Verify Receiver Cert and prepare km
misc/mei/hdcp: Verify H_prime
misc/mei/hdcp: Store the HDCP Pairing info
misc/mei/hdcp: Initiate Locality check
misc/mei/hdcp: Verify L_prime
misc/mei/hdcp: Prepare Session Key
misc/mei/hdcp: Repeater topology verification and ack
misc/mei/hdcp: Verify M_prime
misc/mei/hdcp: Enabling the HDCP authentication
misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
misc/mei/hdcp: Component framework for I915 Interface
FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915
FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4
FOR_TESTING_ONLY: ICL: Limit clk to <= 340MHz
Tomas Winkler (3):
mei: bus: whitelist hdcp client
mei: bus: export to_mei_cl_device for mei client device drivers
mei: me: add ice lake point device id.
Documentation/driver-api/component.rst | 2 +
Documentation/gpu/drm-internals.rst | 5 +
drivers/gpu/drm/drm_drv.c | 14 +
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/intel_connector.c | 2 +
drivers/gpu/drm/i915/intel_display.c | 4 +
drivers/gpu/drm/i915/intel_dp.c | 350 ++++++++-
drivers/gpu/drm/i915/intel_drv.h | 83 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 1242 +++++++++++++++++++++++++++++---
drivers/gpu/drm/i915/intel_hdmi.c | 240 +++++-
drivers/misc/mei/Kconfig | 8 +
drivers/misc/mei/Makefile | 2 +
drivers/misc/mei/bus-fixup.c | 16 +
drivers/misc/mei/bus.c | 1 -
drivers/misc/mei/hdcp/Makefile | 7 +
drivers/misc/mei/hdcp/mei_hdcp.c | 842 ++++++++++++++++++++++
drivers/misc/mei/hdcp/mei_hdcp.h | 389 ++++++++++
drivers/misc/mei/hw-me-regs.h | 2 +
drivers/misc/mei/pci-me.c | 2 +
include/drm/drm_hdcp.h | 25 +-
include/drm/i915_component.h | 3 +
include/drm/i915_mei_hdcp_interface.h | 148 ++++
include/linux/mei_cl_bus.h | 2 +
25 files changed, 3280 insertions(+), 127 deletions(-)
create mode 100644 drivers/misc/mei/hdcp/Makefile
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
create mode 100644 include/drm/i915_mei_hdcp_interface.h
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v12 01/38] drm/doc: document recommended component helper usage
2019-02-09 7:11 [PATCH v12 00/38] drm/i915: Implement HDCP2.2 Ramalingam C
@ 2019-02-09 7:11 ` Ramalingam C
0 siblings, 0 replies; 6+ messages in thread
From: Ramalingam C @ 2019-02-09 7:11 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel.vetter, tomas.winkler, uma.shankar
Cc: Daniel Vetter, Russell King - ARM Linux admin
From: Daniel Vetter <daniel.vetter@intel.com>
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst | 5 +++++
drivers/gpu/drm/drm_drv.c | 14 ++++++++++++++
3 files changed, 21 insertions(+)
diff --git a/Documentation/driver-api/component.rst b/Documentation/driver-api/component.rst
index 2da4a8f20607..57e37590733f 100644
--- a/Documentation/driver-api/component.rst
+++ b/Documentation/driver-api/component.rst
@@ -1,3 +1,5 @@
+.. _component:
+
======================================
Component Helper for Aggregate Drivers
======================================
diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
index 3ae23a5454ac..966bd2d9f0cc 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -93,6 +93,11 @@ Device Instance and Driver Handling
Driver Load
-----------
+Component Helper Usage
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_drv.c
+ :doc: component helper usage recommendations
IRQ Helper Library
~~~~~~~~~~~~~~~~~~
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..aae413003705 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode)
}
/**
+ * DOC: component helper usage recommendations
+ *
+ * DRM drivers that drive hardware where a logical device consists of a pile of
+ * independent hardware blocks are recommended to use the :ref:`component helper
+ * library<component>`. The entire device initialization procedure should be run
+ * from the &component_master_ops.master_bind callback, starting with
+ * drm_dev_init(), then binding all components with component_bind_all() and
+ * finishing with drm_dev_register(). For consistency and easier sharing of
+ * components across drivers the opaque pointer passed to all components through
+ * component_bind_all() should point at &struct drm_device of the device
+ * instance, not some driver specific private structure.
+ */
+
+/**
* drm_dev_init - Initialise new DRM device
* @dev: DRM device
* @driver: DRM driver
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v12 00/38] drm/i915: Implement HDCP2.2
@ 2019-02-09 7:12 Ramalingam C
2019-02-09 7:12 ` [PATCH v12 01/38] drm/doc: document recommended component helper usage Ramalingam C
0 siblings, 1 reply; 6+ messages in thread
From: Ramalingam C @ 2019-02-09 7:12 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel.vetter, tomas.winkler, uma.shankar
This series enables the HDCP2.2 Type 0 for I915. The sequence for
HDCP2.2 authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver for mei bus, so that for HDCP2.2
authentication, HDCP2.2 stack in I915 can avail the services from
ME FW. To enable this client driver set the config variable
CONFIG_INTEL_MEI_HDCP.
Userspace interface remains unchanged as version agnostic. When
userspace request for HDCP enable, Kernel will detect the HDCP source
and sink's HDCP version(1.4/2.2)capability and enable the best capable
version for that combination.
This series enables the HDCP2.2 for Type0 content streams.
Test-with: <1549566452-30175-1-git-send-email-ramalingam.c@intel.com>
Major changes in v12
- hdcp disable from unbind is removed.
- hdcp component init and del are moved away from conenctor ops.
- Review comemnts from Tomas are addressed. [Tomas]
- Collected the r-bs and Acks given for v11.
- ICL mei dev id patch is cherry-picked from
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git char-misc-linus
- Changes for component framework are merged into drm-tip already.
To ease the review process, series is hosted at
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v12
Daniel Vetter (1):
drm/doc: document recommended component helper usage
Ramalingam C (34):
drm/i915: Gathering the HDCP1.4 routines together
drm: header for i915 - MEI_HDCP interface
drm/i915: Initialize HDCP2.2
drm/i915: MEI interface definition
drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
drm/i915: Enable and Disable of HDCP2.2
drm/i915: Implement HDCP2.2 receiver authentication
drm: helper functions for hdcp2 seq_num to from u32
drm/i915: Implement HDCP2.2 repeater authentication
drm: HDCP2.2 link check period
drm/i915: Implement HDCP2.2 link integrity check
drm/i915: Handle HDCP2.2 downstream topology change
drm: removing the DP Errata msg and its msg id
drm/i915: Implement the HDCP2.2 support for DP
drm/i915: Implement the HDCP2.2 support for HDMI
drm/i915: CP_IRQ handling for DP HDCP2.2 msgs
drm/i915: Fix KBL HDCP2.2 encrypt status signalling
misc/mei/hdcp: Client driver for HDCP application
misc/mei/hdcp: Define ME FW interface for HDCP2.2
misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
misc/mei/hdcp: Verify Receiver Cert and prepare km
misc/mei/hdcp: Verify H_prime
misc/mei/hdcp: Store the HDCP Pairing info
misc/mei/hdcp: Initiate Locality check
misc/mei/hdcp: Verify L_prime
misc/mei/hdcp: Prepare Session Key
misc/mei/hdcp: Repeater topology verification and ack
misc/mei/hdcp: Verify M_prime
misc/mei/hdcp: Enabling the HDCP authentication
misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
misc/mei/hdcp: Component framework for I915 Interface
FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915
FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4
FOR_TESTING_ONLY: ICL: Limit clk to <= 340MHz
Tomas Winkler (3):
mei: bus: whitelist hdcp client
mei: bus: export to_mei_cl_device for mei client device drivers
mei: me: add ice lake point device id.
Documentation/driver-api/component.rst | 2 +
Documentation/gpu/drm-internals.rst | 5 +
drivers/gpu/drm/drm_drv.c | 14 +
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/intel_connector.c | 2 +
drivers/gpu/drm/i915/intel_display.c | 4 +
drivers/gpu/drm/i915/intel_dp.c | 350 ++++++++-
drivers/gpu/drm/i915/intel_drv.h | 83 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 1242 +++++++++++++++++++++++++++++---
drivers/gpu/drm/i915/intel_hdmi.c | 240 +++++-
drivers/misc/mei/Kconfig | 8 +
drivers/misc/mei/Makefile | 2 +
drivers/misc/mei/bus-fixup.c | 16 +
drivers/misc/mei/bus.c | 1 -
drivers/misc/mei/hdcp/Makefile | 7 +
drivers/misc/mei/hdcp/mei_hdcp.c | 842 ++++++++++++++++++++++
drivers/misc/mei/hdcp/mei_hdcp.h | 389 ++++++++++
drivers/misc/mei/hw-me-regs.h | 2 +
drivers/misc/mei/pci-me.c | 2 +
include/drm/drm_hdcp.h | 25 +-
include/drm/i915_component.h | 3 +
include/drm/i915_mei_hdcp_interface.h | 148 ++++
include/linux/mei_cl_bus.h | 2 +
25 files changed, 3280 insertions(+), 127 deletions(-)
create mode 100644 drivers/misc/mei/hdcp/Makefile
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
create mode 100644 include/drm/i915_mei_hdcp_interface.h
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v12 01/38] drm/doc: document recommended component helper usage
2019-02-09 7:12 [PATCH v12 00/38] drm/i915: Implement HDCP2.2 Ramalingam C
@ 2019-02-09 7:12 ` Ramalingam C
2019-02-11 8:31 ` Daniel Vetter
2019-02-12 12:44 ` Laurent Pinchart
0 siblings, 2 replies; 6+ messages in thread
From: Ramalingam C @ 2019-02-09 7:12 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel.vetter, tomas.winkler, uma.shankar
Cc: Daniel Vetter, Russell King - ARM Linux admin
From: Daniel Vetter <daniel.vetter@intel.com>
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst | 5 +++++
drivers/gpu/drm/drm_drv.c | 14 ++++++++++++++
3 files changed, 21 insertions(+)
diff --git a/Documentation/driver-api/component.rst b/Documentation/driver-api/component.rst
index 2da4a8f20607..57e37590733f 100644
--- a/Documentation/driver-api/component.rst
+++ b/Documentation/driver-api/component.rst
@@ -1,3 +1,5 @@
+.. _component:
+
======================================
Component Helper for Aggregate Drivers
======================================
diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
index 3ae23a5454ac..966bd2d9f0cc 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -93,6 +93,11 @@ Device Instance and Driver Handling
Driver Load
-----------
+Component Helper Usage
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_drv.c
+ :doc: component helper usage recommendations
IRQ Helper Library
~~~~~~~~~~~~~~~~~~
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..aae413003705 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode)
}
/**
+ * DOC: component helper usage recommendations
+ *
+ * DRM drivers that drive hardware where a logical device consists of a pile of
+ * independent hardware blocks are recommended to use the :ref:`component helper
+ * library<component>`. The entire device initialization procedure should be run
+ * from the &component_master_ops.master_bind callback, starting with
+ * drm_dev_init(), then binding all components with component_bind_all() and
+ * finishing with drm_dev_register(). For consistency and easier sharing of
+ * components across drivers the opaque pointer passed to all components through
+ * component_bind_all() should point at &struct drm_device of the device
+ * instance, not some driver specific private structure.
+ */
+
+/**
* drm_dev_init - Initialise new DRM device
* @dev: DRM device
* @driver: DRM driver
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v12 01/38] drm/doc: document recommended component helper usage
2019-02-09 7:12 ` [PATCH v12 01/38] drm/doc: document recommended component helper usage Ramalingam C
@ 2019-02-11 8:31 ` Daniel Vetter
2019-02-12 12:44 ` Laurent Pinchart
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2019-02-11 8:31 UTC (permalink / raw)
To: Ramalingam C
Cc: daniel.vetter, intel-gfx, Russell King - ARM Linux admin,
dri-devel, Daniel Vetter, tomas.winkler
On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote:
> From: Daniel Vetter <daniel.vetter@intel.com>
>
> Now that component has docs it's worth spending a few words and
> hyperlinks on recommended best practices in drm.
>
> Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Just a quick reminder: When sending out other people's patches, you need
to add your own s-o-b line per https://developercertificate.org/
Cheers, Daniel
> ---
> Documentation/driver-api/component.rst | 2 ++
> Documentation/gpu/drm-internals.rst | 5 +++++
> drivers/gpu/drm/drm_drv.c | 14 ++++++++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/Documentation/driver-api/component.rst b/Documentation/driver-api/component.rst
> index 2da4a8f20607..57e37590733f 100644
> --- a/Documentation/driver-api/component.rst
> +++ b/Documentation/driver-api/component.rst
> @@ -1,3 +1,5 @@
> +.. _component:
> +
> ======================================
> Component Helper for Aggregate Drivers
> ======================================
> diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
> index 3ae23a5454ac..966bd2d9f0cc 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -93,6 +93,11 @@ Device Instance and Driver Handling
> Driver Load
> -----------
>
> +Component Helper Usage
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_drv.c
> + :doc: component helper usage recommendations
>
> IRQ Helper Library
> ~~~~~~~~~~~~~~~~~~
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..aae413003705 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode)
> }
>
> /**
> + * DOC: component helper usage recommendations
> + *
> + * DRM drivers that drive hardware where a logical device consists of a pile of
> + * independent hardware blocks are recommended to use the :ref:`component helper
> + * library<component>`. The entire device initialization procedure should be run
> + * from the &component_master_ops.master_bind callback, starting with
> + * drm_dev_init(), then binding all components with component_bind_all() and
> + * finishing with drm_dev_register(). For consistency and easier sharing of
> + * components across drivers the opaque pointer passed to all components through
> + * component_bind_all() should point at &struct drm_device of the device
> + * instance, not some driver specific private structure.
> + */
> +
> +/**
> * drm_dev_init - Initialise new DRM device
> * @dev: DRM device
> * @driver: DRM driver
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v12 01/38] drm/doc: document recommended component helper usage
2019-02-09 7:12 ` [PATCH v12 01/38] drm/doc: document recommended component helper usage Ramalingam C
2019-02-11 8:31 ` Daniel Vetter
@ 2019-02-12 12:44 ` Laurent Pinchart
2019-02-12 12:52 ` Daniel Vetter
1 sibling, 1 reply; 6+ messages in thread
From: Laurent Pinchart @ 2019-02-12 12:44 UTC (permalink / raw)
To: Ramalingam C
Cc: daniel.vetter, intel-gfx, Russell King - ARM Linux admin,
dri-devel, Daniel Vetter, tomas.winkler
Hi Daniel,
Thank you for the patch.
On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote:
> From: Daniel Vetter <daniel.vetter@intel.com>
>
> Now that component has docs it's worth spending a few words and
> hyperlinks on recommended best practices in drm.
>
> Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> Documentation/driver-api/component.rst | 2 ++
> Documentation/gpu/drm-internals.rst | 5 +++++
> drivers/gpu/drm/drm_drv.c | 14 ++++++++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/Documentation/driver-api/component.rst b/Documentation/driver-api/component.rst
> index 2da4a8f20607..57e37590733f 100644
> --- a/Documentation/driver-api/component.rst
> +++ b/Documentation/driver-api/component.rst
> @@ -1,3 +1,5 @@
> +.. _component:
> +
> ======================================
> Component Helper for Aggregate Drivers
> ======================================
> diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
> index 3ae23a5454ac..966bd2d9f0cc 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -93,6 +93,11 @@ Device Instance and Driver Handling
> Driver Load
> -----------
>
> +Component Helper Usage
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_drv.c
> + :doc: component helper usage recommendations
>
> IRQ Helper Library
> ~~~~~~~~~~~~~~~~~~
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..aae413003705 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode)
> }
>
> /**
> + * DOC: component helper usage recommendations
> + *
> + * DRM drivers that drive hardware where a logical device consists of a pile of
> + * independent hardware blocks are recommended to use the :ref:`component helper
> + * library<component>`.
That's the first recommendation I would challenge :-) When using
drm_bridge and drm_panel, the component framework is not strictly
needed. The DRM/KMS probe function can defer probe when a bridge or
panel is missing. Only when two-way dependencies exist between the
display controller and the external components is the component
framework required.
> The entire device initialization procedure should be run
> + * from the &component_master_ops.master_bind callback, starting with
> + * drm_dev_init(), then binding all components with component_bind_all() and
> + * finishing with drm_dev_register().
The omapdss driver, for instance, performs hardware-specific
initialization of the DSS in the probe() handler itself (DT-related
parsing, memory mapping, IRQ registration, ...). I don't see why this
would need to move to the .master_bind() callback.
> For consistency and easier sharing of
> + * components across drivers the opaque pointer passed to all components through
> + * component_bind_all() should point at &struct drm_device of the device
> + * instance, not some driver specific private structure.
I'd say "shall" instead of "should" to make this a hard requirement. The
opaque pointer is something that I have never really liked in the
component framework as it hinders reusability. I have a few ideas on how
to fix that but haven't had time to try them out yet as the changes
would be quite intrusive. Long term major changes will be needed there
anyway as it makes no sense to have to frameworks with similar purposes
in DRM/KMS and V4L2.
> + */
> +
> +/**
> * drm_dev_init - Initialise new DRM device
> * @dev: DRM device
> * @driver: DRM driver
--
Regards,
Laurent Pinchart
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v12 01/38] drm/doc: document recommended component helper usage
2019-02-12 12:44 ` Laurent Pinchart
@ 2019-02-12 12:52 ` Daniel Vetter
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2019-02-12 12:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: intel-gfx, Russell King - ARM Linux admin, dri-devel,
daniel.vetter, Daniel Vetter, tomas.winkler
On Tue, Feb 12, 2019 at 02:44:03PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote:
> > From: Daniel Vetter <daniel.vetter@intel.com>
> >
> > Now that component has docs it's worth spending a few words and
> > hyperlinks on recommended best practices in drm.
> >
> > Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > Documentation/driver-api/component.rst | 2 ++
> > Documentation/gpu/drm-internals.rst | 5 +++++
> > drivers/gpu/drm/drm_drv.c | 14 ++++++++++++++
> > 3 files changed, 21 insertions(+)
> >
> > diff --git a/Documentation/driver-api/component.rst b/Documentation/driver-api/component.rst
> > index 2da4a8f20607..57e37590733f 100644
> > --- a/Documentation/driver-api/component.rst
> > +++ b/Documentation/driver-api/component.rst
> > @@ -1,3 +1,5 @@
> > +.. _component:
> > +
> > ======================================
> > Component Helper for Aggregate Drivers
> > ======================================
> > diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
> > index 3ae23a5454ac..966bd2d9f0cc 100644
> > --- a/Documentation/gpu/drm-internals.rst
> > +++ b/Documentation/gpu/drm-internals.rst
> > @@ -93,6 +93,11 @@ Device Instance and Driver Handling
> > Driver Load
> > -----------
> >
> > +Component Helper Usage
> > +~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_drv.c
> > + :doc: component helper usage recommendations
> >
> > IRQ Helper Library
> > ~~~~~~~~~~~~~~~~~~
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 381581b01d48..aae413003705 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode)
> > }
> >
> > /**
> > + * DOC: component helper usage recommendations
> > + *
> > + * DRM drivers that drive hardware where a logical device consists of a pile of
> > + * independent hardware blocks are recommended to use the :ref:`component helper
> > + * library<component>`.
>
> That's the first recommendation I would challenge :-) When using
> drm_bridge and drm_panel, the component framework is not strictly
> needed. The DRM/KMS probe function can defer probe when a bridge or
> panel is missing. Only when two-way dependencies exist between the
> display controller and the external components is the component
> framework required.
In the component docs themselves (just landed) we explicitly restrict
component to only the cases where there's no other subsytem specific way
to assemble the pile. I'll add that here, explicitly pointing out
panels/bridges.
> > The entire device initialization procedure should be run
> > + * from the &component_master_ops.master_bind callback, starting with
> > + * drm_dev_init(), then binding all components with component_bind_all() and
> > + * finishing with drm_dev_register().
>
> The omapdss driver, for instance, performs hardware-specific
> initialization of the DSS in the probe() handler itself (DT-related
> parsing, memory mapping, IRQ registration, ...). I don't see why this
> would need to move to the .master_bind() callback.
It's a bit the odd one out then. Not sure whether there's a hard reason
for that or not.
> > For consistency and easier sharing of
> > + * components across drivers the opaque pointer passed to all components through
> > + * component_bind_all() should point at &struct drm_device of the device
> > + * instance, not some driver specific private structure.
>
> I'd say "shall" instead of "should" to make this a hard requirement. The
> opaque pointer is something that I have never really liked in the
> component framework as it hinders reusability. I have a few ideas on how
> to fix that but haven't had time to try them out yet as the changes
> would be quite intrusive. Long term major changes will be needed there
> anyway as it makes no sense to have to frameworks with similar purposes
> in DRM/KMS and V4L2.
We have a pile of components around i915 (but not for the core drm_device)
which point at anything but drm_device. Otoh you'll never going to reuse
those pieces. I think anytime you want to reuse component drivers across
drivers you actually want a new subsystem (like drm_bridge/panel) with
dedicated lookup functions, and no void * pointers anywhere. I'd go as far
and say code reuse across drivers is mostly out of scope for component.
-Daniel
>
> > + */
> > +
> > +/**
> > * drm_dev_init - Initialise new DRM device
> > * @dev: DRM device
> > * @driver: DRM driver
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-02-12 12:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-09 7:11 [PATCH v12 00/38] drm/i915: Implement HDCP2.2 Ramalingam C
2019-02-09 7:11 ` [PATCH v12 01/38] drm/doc: document recommended component helper usage Ramalingam C
-- strict thread matches above, loose matches on Subject: below --
2019-02-09 7:12 [PATCH v12 00/38] drm/i915: Implement HDCP2.2 Ramalingam C
2019-02-09 7:12 ` [PATCH v12 01/38] drm/doc: document recommended component helper usage Ramalingam C
2019-02-11 8:31 ` Daniel Vetter
2019-02-12 12:44 ` Laurent Pinchart
2019-02-12 12:52 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox