Re: [Intel-gfx] [WIP PATCH 01/15] drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()
On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote:
> There's no reason we need this, it's just confusing looking.
>
> Signed-off-by: Lyude Paul
> Cc: Juston Li
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ad0fb6d003be..9b1b5c9b1fa0 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1896,9 +1896,7 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> req_payload.num_slots = 0;
> }
>
> - if (mgr->payloads[i].start_slot != req_payload.start_slot) {
> - mgr->payloads[i].start_slot = req_payload.start_slot;
> - }
> + mgr->payloads[i].start_slot = req_payload.start_slot;
Entertaining!
Reviewed-by: Daniel Vetter
> /* work out what is required to happen with this payload */
> if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>
> --
> 2.19.2
>
--
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
Re: [Intel-gfx] [WIP PATCH 02/15] drm/dp_mst: Refactor drm_dp_update_payload_part1()
On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote:
> There should be no functional changes here
Would be good to explain what you did refactor here, instead of me trying
to reconstruct it from the patch. Especially pre-coffee that helps :-)
>
> Signed-off-by: Lyude Paul
> Cc: Juston Li
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
> 1 file changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 9b1b5c9b1fa0..2ab16c9e6243 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
>
> mutex_lock(&mgr->payload_lock);
> for (i = 0; i < mgr->max_payloads; i++) {
> + struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> + struct drm_dp_payload *payload = &mgr->payloads[i];
> +
> /* solve the current payloads - compare to the hw ones
> - update the hw view */
> req_payload.start_slot = cur_slots;
> - if (mgr->proposed_vcpis[i]) {
> - port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
> + if (vcpi) {
> + port = container_of(vcpi, struct drm_dp_mst_port,
> + vcpi);
> port = drm_dp_get_validated_port_ref(mgr, port);
> if (!port) {
> mutex_unlock(&mgr->payload_lock);
> return -EINVAL;
> }
> - req_payload.num_slots =
> mgr->proposed_vcpis[i]->num_slots;
> - req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi;
> + req_payload.num_slots = vcpi->num_slots;
> + req_payload.vcpi = vcpi->vcpi;
> } else {
> port = NULL;
> req_payload.num_slots = 0;
> }
>
> - mgr->payloads[i].start_slot = req_payload.start_slot;
> + payload->start_slot = req_payload.start_slot;
> /* work out what is required to happen with this payload */
> - if (mgr->payloads[i].num_slots != req_payload.num_slots) {
> + if (payload->num_slots != req_payload.num_slots) {
>
> /* need to push an update for this payload */
> if (req_payload.num_slots) {
> - drm_dp_create_payload_step1(mgr,
> mgr->proposed_vcpis[i]->vcpi, &req_payload);
> - mgr->payloads[i].num_slots =
> req_payload.num_slots;
> - mgr->payloads[i].vcpi = req_payload.vcpi;
> - } else if (mgr->payloads[i].num_slots) {
> - mgr->payloads[i].num_slots = 0;
> - drm_dp_destroy_payload_step1(mgr, port,
> mgr->payloads[i].vcpi, &mgr->payloads[i]);
> - req_payload.payload_state =
> mgr->payloads[i].payload_state;
> - mgr->payloads[i].start_slot = 0;
> + drm_dp_create_payload_step1(mgr, vcpi->vcpi,
> + &req_payload);
> + payload->num_slots = req_payload.num_slots;
> + payload->vcpi = req_payload.vcpi;
> +
> + } else if (payload->num_slots) {
> + payload->num_slots = 0;
> + drm_dp_destroy_payload_step1(mgr, port,
> + payload->vcpi,
> + payload);
> + req_payload.payload_state =
> + payload->payload_state;
> + payload->start_slot = 0;
> }
> - mgr->payloads[i].payload_state =
> req_payload.payload_state;
> + payload->payload_state = req_payload.payload_state;
> }
> cur_slots += req_payload.num_slots;
>
> @@ -1920,22 +1929,26 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> }
>
> for (i = 0; i < mgr->max_payloads; i++) {
> - if (mgr->payloads[i].payload_state == DP_PAYLOAD_DELETE_LOCAL) {
> - DRM_DEBUG_KMS("removing payload %d\n", i);
> - for (j = i; j < mgr->max_payloads - 1; j++) {
> - memcpy(&mgr->payloads[j], &mgr->payloads[j +
> 1], sizeof(struct drm_dp_payload));
> - mgr->proposed_vcpis[j] = mgr->proposed_vcpis[j
> + 1];
> - if (mgr->proposed_vcpis
Re: [Intel-gfx] [WIP PATCH 03/15] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things could be simplified.
>
> To the best of my understanding, the current scheme works like this:
> drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
> this refcount hits 0 for either of the two, they're removed from the
> topology state, but not immediately freed. Both ports and branch devices
> will reinitialize their kref once it's hit 0 before actually destroying
> themselves. The intended purpose behind this is so that we can avoid
> problems like not being able to free a remote payload that might still
> be active, due to us having removed all of the port/branch device
> structures in memory, as per:
>
> 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
>
> Which may have worked, but then it caused use-after-free errors. Being
> new to MST at the time, I tried fixing it;
>
> 263efde31f97 ("drm/dp/mst: Get validated port ref in
> drm_dp_update_payload_part1()")
>
> But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
> are validated in almost every DP MST helper function. Simply put, this
> means we go through the topology and try to see if the given
> drm_dp_mst_branch or drm_dp_mst_port is still attached to something
> before trying to use it in order to avoid dereferencing freed memory
> (something that has happened a LOT in the past with this library).
> Because of this it doesn't actually matter whether or not we keep keep
> the ports and branches around in memory as that's not enough, because
> any function that validates the branches and ports passed to it will
> still reject them anyway since they're no longer in the topology
> structure. So, use-after-free errors were fixed but payload deallocation
> was completely broken.
>
> Two years later, AMD informed me about this issue and I attempted to
> come up with a temporary fix, pending a long-overdue cleanup of this
> library:
>
> c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just
> ref")
>
> But then that introduced use-after-free errors, so I quickly reverted
> it:
>
> 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during destruction,
> just ref"")
>
> And in the process, learned that there is just no simple fix for this:
> the design is just broken. Unfortuntely, the usage of these helpers are
> quite broken as well. Some drivers like i915 have been smart enough to
> avoid accessing any kind of information from MST port structures, but
> others like nouveau have assumed, understandably so, that
> drm_dp_mst_port structures are normal and can just be accessed at any
> time without worrying about use-after-free errors.
>
> After a lot of discussion, me and Daniel Vetter came up with a better
> idea to replace all of this.
>
> To summarize, since this is documented far more indepth in the
> documentation this patch introduces, we make it so that drm_dp_mst_port
> and drm_dp_mst_branch structures have two different classes of
> refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
> the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
> given topology. Once it hits zero, any associated connectors are removed
> and the branch or port can no longer be validated. malloc_kref
> corresponds to the lifetime of the memory allocation for the actual
> structure, and will always be non-zero so long as the topology_kref is
> non-zero. This gives us a way to allow callers to hold onto port and
> branch device structures past their topology lifetime, and dramatically
> simplifies the lifetimes of both structures. This also finally fixes the
> port deallocation problem, properly.
>
> Additionally: since this now means that we can keep ports and branch
> devices allocated in memory for however long we need, we no longer need
> a significant amount of the port validation that we currently do.
>
> Additionally, there is one last scenario that this fixes, which couldn't
> have been fixed properly beforehand:
>
> - CPU1 unrefs port from topology (refcount 1->0)
> - CPU2 refs port in topology(refcount 0->1)
>
> Since we now can guarantee memory safety for ports and branches
> as-needed, we also can make our main reference counting functions fix
> this problem by using kref_get_unless_zero() internally so that topology
> refcounts can only ever reach 0 once.
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
> ---
> .../gpu/dp-mst/topology-figure-1.dot | 31 ++
> .../gpu/dp-mst/topology-figure-2.dot | 37 ++
> .../gpu/dp-mst/topology-figure-3.dot | 40 ++
> Documentation/gpu/drm-kms-helpers.rst | 125 -
> drivers
Re: [Intel-gfx] [WIP PATCH 06/15] drm/i915: Keep malloc references to MST ports
On Thu, Dec 13, 2018 at 08:25:35PM -0500, Lyude Paul wrote: > So that the ports stay around until we've destroyed the connectors, in > order to ensure that we don't pass an invalid pointer to any MST helpers > once we introduce the new MST VCPI helpers. > > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/i915/intel_connector.c | 4 > drivers/gpu/drm/i915/intel_dp_mst.c| 2 ++ > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_connector.c > b/drivers/gpu/drm/i915/intel_connector.c > index 18e370f607bc..37d2c644f4b8 100644 > --- a/drivers/gpu/drm/i915/intel_connector.c > +++ b/drivers/gpu/drm/i915/intel_connector.c > @@ -95,6 +95,10 @@ void intel_connector_destroy(struct drm_connector > *connector) > intel_panel_fini(&intel_connector->panel); > > drm_connector_cleanup(connector); > + > + if (intel_connector->port) We set this as the first thing in intel_dp_add_mst_connector, so this check isn't doing anything. > + drm_dp_mst_put_port_malloc(intel_connector->port); > + > kfree(connector); > } > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c > b/drivers/gpu/drm/i915/intel_dp_mst.c > index f05427b74e34..4d6ced34d465 100644 > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > @@ -484,6 +484,8 @@ static struct drm_connector > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo > if (ret) > goto err; > > + drm_dp_mst_get_port_malloc(port); Needs to be moved up where we assing intel_connector->port, or it'll underflow on cleanup on error paths. > + > return connector; > > err: > -- > 2.19.2 > -- 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
Re: [Intel-gfx] [WIP PATCH 05/15] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
On Thu, Dec 13, 2018 at 08:25:34PM -0500, Lyude Paul wrote:
> Up until now, freeing payloads on remote MST hubs that just had ports
> removed has almost never worked because we've been relying on port
> validation in order to stop us from accessing ports that have already
> been freed from memory, but ports which need their payloads released due
> to being removed will never be a valid part of the topology after
> they've been removed.
>
> Since we've introduced malloc refs, we can replace all of the validation
> logic in payload helpers which are used for deallocation with some
> well-placed malloc krefs. This ensures that regardless of whether or not
> the ports are still valid and in the topology, any port which has an
> allocated payload will remain allocated in memory until it's payloads
> have been removed - finally allowing us to actually release said
> payloads correctly.
>
> Signed-off-by: Lyude Paul
I think with this we can also remove the int return value (that everyone
ignored except for some debug output) from drm_dp_update_payload_part1/2.
Follow-up cleanup patch ofc.
This looks good.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
> 1 file changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ae9d019af9f2..93f08bfd2ab3 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1989,10 +1989,6 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> u8 sinks[DRM_DP_MAX_SDP_STREAMS];
> int i;
>
> - port = drm_dp_mst_topology_get_port_validated(mgr, port);
> - if (!port)
> - return -EINVAL;
> -
> port_num = port->port_num;
> mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
> if (!mstb) {
> @@ -2000,10 +1996,8 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> port->parent,
> &port_num);
>
> - if (!mstb) {
> - drm_dp_mst_topology_put_port(port);
> + if (!mstb)
> return -EINVAL;
> - }
> }
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> @@ -2032,7 +2026,6 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> kfree(txmsg);
> fail_put:
> drm_dp_mst_topology_put_mstb(mstb);
> - drm_dp_mst_topology_put_port(port);
> return ret;
> }
>
> @@ -2137,15 +2130,16 @@ static int drm_dp_destroy_payload_step2(struct
> drm_dp_mst_topology_mgr *mgr,
> */
> int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
> {
> - int i, j;
> - int cur_slots = 1;
> struct drm_dp_payload req_payload;
> struct drm_dp_mst_port *port;
> + int i, j;
> + int cur_slots = 1;
>
> mutex_lock(&mgr->payload_lock);
> for (i = 0; i < mgr->max_payloads; i++) {
> struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> struct drm_dp_payload *payload = &mgr->payloads[i];
> + bool put_port = false;
>
> /* solve the current payloads - compare to the hw ones
> - update the hw view */
> @@ -2153,12 +2147,20 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> if (vcpi) {
> port = container_of(vcpi, struct drm_dp_mst_port,
> vcpi);
> - port = drm_dp_mst_topology_get_port_validated(mgr,
> - port);
> - if (!port) {
> - mutex_unlock(&mgr->payload_lock);
> - return -EINVAL;
> +
> + /* Validated ports don't matter if we're releasing
> + * VCPI
> + */
> + if (vcpi->num_slots) {
> + port = drm_dp_mst_topology_get_port_validated(
> + mgr, port);
> + if (!port) {
> + mutex_unlock(&mgr->payload_lock);
> + return -EINVAL;
> + }
> + put_port = true;
> }
> +
> req_payload.num_slots = vcpi->num_slots;
> req_payload.vcpi = vcpi->vcpi;
> } else {
> @@ -2190,7 +2192,7 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> }
> cur_slots += req_payload.num_slots;
>
> - if (port)
> + if (put_port)
> drm_dp_mst_topology_put_po
Re: [Intel-gfx] [WIP PATCH 04/15] drm/dp_mst: Stop releasing VCPI when removing ports from topology
On Thu, Dec 13, 2018 at 08:25:33PM -0500, Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index c196fb580beb..ae9d019af9f2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1084,8 +1084,6 @@ static void drm_dp_destroy_port(struct kref *kref)
> struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>
> if (!port->input) {
> - port->vcpi.num_slots = 0;
> -
> kfree(port->cached_edid);
>
> /*
> @@ -3381,12 +3379,6 @@ static void drm_dp_destroy_connector_work(struct
> work_struct *work)
> drm_dp_port_teardown_pdt(port, port->pdt);
> port->pdt = DP_PEER_DEVICE_NONE;
>
> - if (!port->input && port->vcpi.vcpi > 0) {
> - drm_dp_mst_reset_vcpi_slots(mgr, port);
> - drm_dp_update_payload_part1(mgr);
> - drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
> - }
> -
> drm_dp_mst_put_port_malloc(port);
> send_hotplug = true;
> }
> --
> 2.19.2
>
--
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
Re: [Intel-gfx] [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)
Hi,
On Thu, Dec 13, 2018 at 01:55:25PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties. E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal. Let's add a helper function that drivers can use to test that a
> userspace-provided LUT is valid and doesn't violate hardware
> requirements.
>
> v2:
> - Combine into a single helper that just takes a bitmask of the tests
>to apply. (Brian Starkey)
> - Add additional check (always performed) that LUT property blob size
>is always a multiple of the LUT entry size. (stolen from ARM driver)
>
> Cc: Uma Shankar
> Cc: Swati Sharma
> Cc: Brian Starkey
> Signed-off-by: Matt Roper
> Reviewed-by(v1): Brian Starkey
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 64
>
> include/drm/drm_color_mgmt.h | 5
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..5c2a2d228412 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -462,3 +462,67 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_color_properties);
> +
> +/**
> + * drm_color_lut_check - check validity of lookup table
> + * @lut: property blob containing LUT to check
> + * @tests: bitmask of tests to run
> + *
> + * Helper to check whether a userspace-provided lookup table is valid and
> + * satisfies additional hardware requirements. All table sizes should be a
> + * multiple of sizeof(struct drm_color_lut). Drivers pass a bitmask
> indicating
> + * which of the following additional tests should also be performed:
> + *
> + * "DRM_COLOR_LUT_EQUAL_CHANNELS":
> + * Checks whether the entries of a LUT all have equal values for the red,
> + * green, and blue channels. Intended for hardware that only accepts a
> + * single value per LUT entry and assumes that value applies to all three
> + * color components.
> + *
> + * "DRM_COLOR_LUT_INCREASING":
> + * Checks whether the entries of a LUT are always flat or increasing
> + * (never decreasing).
> + *
> + * Returns 0 on success, -EINVAL on failure.
> + */
> +int drm_color_lut_check(struct drm_property_blob *lut,
> + uint32_t tests)
> +{
> + struct drm_color_lut *entry;
> + int i;
> +
> + if (!lut)
> + return 0;
> +
> + if (lut->length % sizeof(struct drm_color_lut)) {
> + DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry
> size (%lu)\n",
> + lut->length, sizeof(struct drm_color_lut));
> + return -EINVAL;
> + }
> +
Isn't this already covered by drm_atomic_replace_property_blob_from_id ?
Other than that feel free to add:
Reviewed-by: Alexandru Gheorghe
> + if (!tests)
> + return 0;
> +
> + entry = lut->data;
> + for (i = 0; i < drm_color_lut_size(lut); i++) {
> + if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
> + if (entry[i].red != entry[i].blue ||
> + entry[i].red != entry[i].green) {
> + DRM_DEBUG_KMS("All LUT entries must have equal
> r/g/b\n");
> + return -EINVAL;
> + }
> + }
> +
> + if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
> + if (entry[i].red < entry[i - 1].red ||
> + entry[i].green < entry[i - 1].green ||
> + entry[i].blue < entry[i - 1].blue) {
> + DRM_DEBUG_KMS("LUT entries must never
> decrease.\n");
> + return -EINVAL;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_color_lut_check);
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..7de16f70bcc3 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
> +#define DRM_COLOR_LUT_INCREASING BIT(1)
> +int drm_color_lut_check(struct drm_property_blob *lut,
> + uint32_t tests);
> #endif
> --
> 2.14.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
Intel-gfx mailing list
In
Re: [Intel-gfx] [PATCH v4 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
On Thu, Dec 13, 2018 at 04:35:31PM +0100, Hans de Goede wrote: > DSI LCD panels describe an initialization sequence in the Video BIOS > Tables using so called MIPI sequences. One possible element in these > sequences is a PMIC specific element of 15 bytes. > > Although this is not really an ACPI opregion, the ACPI opregion code is the > closest thing we have. We need to have support for these PMIC specific MIPI > sequence elements somwhere. Since we already instantiate a special platform > device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to, > with PMIC specific implementations of the OpRegion, the handling of MIPI > sequence PMIC elements fits very well in the ACPI PMIC OpRegion code. > > This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element() > function, which is to be backed by a PMIC specific > exec_mipi_pmic_seq_element callback. This function will be called by the > i915 code to execture MIPI sequence PMIC elements. > > Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Thu, Dec 13, 2018 at 04:35:32PM +0100, Hans de Goede wrote: > Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove > PMIC. > > On some CHT devices this fixes the LCD panel not lighting up when it was > not initialized by the GOP, because an external monitor was plugged in and > the GOP initialized only the external monitor. > > Signed-off-by: Hans de Goede One question see below, but regardless Reviewed-by: Mika Westerberg > --- > Changes in v4: > -The decoding of the raw data of the PMIC MIPI sequence element is now done > in our caller, so drop this and adjust the callback prototype to accept > the decoded addresses, value and mask > > Changes in v3: > -Use hex values for out of range checks > -Make intel_cht_wc_exec_mipi_pmic_seq_element return errors > > Changes in v2: > -Interpret data passed to the PMIC MIPI elements according to the docs > instead of my own reverse engineered interpretation > --- > drivers/acpi/pmic/intel_pmic_chtwc.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c > b/drivers/acpi/pmic/intel_pmic_chtwc.c > index 078b0448f30a..c5037c5c5219 100644 > --- a/drivers/acpi/pmic/intel_pmic_chtwc.c > +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include Why is this include needed? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] Dynamic EU configuration of Slice/Subslice/EU.
Quoting Ankit Navik (2018-12-11 12:14:17) > drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel > > Current GPU configuration code for i915 does not allow us to change > EU/Slice/Sub-slice configuration dynamically. Its done only once while context > is created. > > While particular graphics application is running, if we examine the command > requests from user space, we observe that command density is not consistent. > It means there is scope to change the graphics configuration dynamically even > while context is running actively. This patch series proposes the solution to > find the active pending load for all active context at given time and based on > that, dynamically perform graphics configuration for each context. > > We use a hr (high resolution) timer with i915 driver in kernel to get a > callback every few milliseconds (this timer value can be configured through > debugfs, default is '0' indicating timer is in disabled state i.e. original > system without any intervention).In the timer callback, we examine pending > commands for a context in the queue, essentially, we intercept them before > they are executed by GPU and we update context with required number of EUs. > > Two questions, how did we arrive at right timer value? and what's the right > number of EUs? For the prior one, empirical data to achieve best performance > in least power was considered. For the later one, we roughly categorized > number > of EUs logically based on platform. Now we compare number of pending commands > with a particular threshold and then set number of EUs accordingly with update > context. That threshold is also based on experiments & findings. If GPU is > able > to catch up with CPU, typically there are no pending commands, the EU config > would remain unchanged there. In case there are more pending commands we > reprogram context with higher number of EUs. Please note, here we are changing > EUs even while context is running by examining pending commands every 'x' > milliseconds. On the overall strategy. This will be unsuitable to be merged as a debugfs interface. So is the idea to evolve into a sysfs interface? As this seems to require tuning for each specific workload, I don't think that would scale too well if you consider a desktop distro? Also, there's the patch series to to enable/disable subslices with VME hardware (the other dynamic slice shutdown/SSEU series) depending on the type of load being run. Certain workloads would hang the system if they're executed with full subslice configuration. In that light, it would make more sense if the applications would be the ones reporting their optimal running configuration. > > With this solution in place, on KBL-GT3 + Android we saw following pnp > benefits, power numbers mentioned here are system power. > > App /KPI | % Power | >| Benefit | >| (mW) | > -| > 3D Mark (Ice storm)| 2.30% | > TRex On screen | 2.49% | > TRex Off screen| 1.32% | > ManhattanOn screen | 3.11% | > Manhattan Off screen | 0.89% | > AnTuTu 6.1.4 | 3.42% | > SynMark2 | 1.70% | Just to verify, these numbers are true while there's no negative effect on the benchmark scores? Regards, Joonas > Note - For KBL (GEN9) we cannot control at sub-slice level, it was always a > constraint. > We always controlled number of EUs rather than sub-slices/slices. > We have also observed GPU core residencies improves by 1.03%. > > Praveen Diwakar (4): > drm/i915: Get active pending request for given context > drm/i915: Update render power clock state configuration for given > context > drm/i915: set optimum eu/slice/sub-slice configuration based on load > type > drm/i915: Predictive governor to control eu/slice/subslice > > drivers/gpu/drm/i915/i915_debugfs.c | 90 > +++- > drivers/gpu/drm/i915/i915_drv.c | 4 ++ > drivers/gpu/drm/i915/i915_drv.h | 9 > drivers/gpu/drm/i915/i915_gem_context.c | 23 > drivers/gpu/drm/i915/i915_gem_context.h | 39 ++ > drivers/gpu/drm/i915/i915_request.c | 2 + > drivers/gpu/drm/i915/intel_device_info.c | 47 - > drivers/gpu/drm/i915/intel_lrc.c | 16 +- > 8 files changed, 226 insertions(+), 4 deletions(-) > > -- > 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 v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Hi, On 14-12-18 10:49, Mika Westerberg wrote: On Thu, Dec 13, 2018 at 04:35:32PM +0100, Hans de Goede wrote: Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove PMIC. On some CHT devices this fixes the LCD panel not lighting up when it was not initialized by the GOP, because an external monitor was plugged in and the GOP initialized only the external monitor. Signed-off-by: Hans de Goede One question see below, but regardless Reviewed-by: Mika Westerberg --- Changes in v4: -The decoding of the raw data of the PMIC MIPI sequence element is now done in our caller, so drop this and adjust the callback prototype to accept the decoded addresses, value and mask Changes in v3: -Use hex values for out of range checks -Make intel_cht_wc_exec_mipi_pmic_seq_element return errors Changes in v2: -Interpret data passed to the PMIC MIPI elements according to the docs instead of my own reverse engineered interpretation --- drivers/acpi/pmic/intel_pmic_chtwc.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c b/drivers/acpi/pmic/intel_pmic_chtwc.c index 078b0448f30a..c5037c5c5219 100644 --- a/drivers/acpi/pmic/intel_pmic_chtwc.c +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c @@ -12,6 +12,7 @@ #include #include #include +#include Why is this include needed? It is no longer needed in v4, since the parsing of the raw MIPI sequence data (which needed this include) has been moved to the i915 VBT code now. I've dropped this from my local version of the patch. Note sure if you (Mika) are the right person to ask, but in the coverletter of v1 I suggested merging all 3 patches through the i915 tree since the drivers/acpi/pmic/intel_pmic* files typically do not see all that churn. If I can get an Ack from you or Rafael for that then I can push the version with the include dropped to drm-next (through drm-intel-next-queued) myself once the 3th patch also has been acked. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Fri, Dec 14, 2018 at 11:48:35AM +0100, Hans de Goede wrote: > > > +#include > > > > Why is this include needed? > > It is no longer needed in v4, since the parsing of the raw > MIPI sequence data (which needed this include) has been moved > to the i915 VBT code now. > > I've dropped this from my local version of the patch. OK. > Note sure if you (Mika) are the right person to ask, but in the > coverletter of v1 I suggested merging all 3 patches through the i915 tree > since the drivers/acpi/pmic/intel_pmic* files typically do > not see all that churn. If I can get an Ack from you or > Rafael for that then I can push the version with the include > dropped to drm-next (through drm-intel-next-queued) myself > once the 3th patch also has been acked. I guess it is up to Rafael whether my ack is enough but here it is for both patches, Acked-by: Mika Westerberg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6] drm/i915/icl: Preempt-to-idle support in execlists.
Quoting Tvrtko Ursulin (2018-12-10 17:40:34)
>
> On 09/11/2018 17:18, Tomasz Lis wrote:
> > The patch adds support of preempt-to-idle requesting by setting a proper
> > bit within Execlist Control Register, and receiving preemption result from
> > Context Status Buffer.
> >
> > Preemption in previous gens required a special batch buffer to be executed,
> > so the Command Streamer never preempted to idle directly. In Icelake it is
> > possible, as there is a hardware mechanism to inform the kernel about
> > status of the preemption request.
> >
> > This patch does not cover using the new preemption mechanism when GuC is
> > active.
> >
> > The advantage of this new preemption path is that one less context switch is
> > needed, and returning information about preempion being complete is received
> > earlier. This leads to significant improvement in our IGT latency test.
> >
> > Test performed: `gem_exec_latency --run-subtest render-preemption`, executed
> > 100 times, on the same platform, same kernel, without and with this patch.
> > Then taken average of the execution latency times:
> >
> > subcase old preempt.icl preempt.
> > render-render 853.2036840.1176
> > render-bsd2328.8708 2083.2576
> > render-blt2080.1501 1852.0792
> > render-vebox 1553.5134 1428.762
> >
> > Improvement observed:
> >
> > subcase improvement
> > render-render 1.53%
> > render-bsd10.55%
> > render-blt10.96%
> > render-vebox 8.03%
>
> Who can explain what do the parts other than render-render mean? At
> least I can make sense of render-render - measure how long it takes for
> one context to preempt another, but render-$other draws a blank for me.
> How are engines pre-empting one another?
>
> But anyway, even if only the 1.53% improvement is the real one, FWIW
> that's I think good enough to justify the patch. It is sufficiently
> small and contained that I don't see a problem. So:
>
> Acked-by: Tvrtko Ursulin
According to Chris, the baseline measurements are off by a decade or so
compared to where they should be. This might be attributed to execution
on frequency locked parts?
Would it be worthy to repeat the numbers with some unlocked parts?
Regards, Joonas
>
> Regards,
>
> Tvrtko
>
> >
> > v2: Added needs_preempt_context() change so that it is not created when
> > preempt-to-idle is supported. (Chris)
> > Updated setting HWACK flag so that it is cleared after
> > preempt-to-dle. (Chris, Daniele)
> > Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris)
> >
> > v3: Fixed needs_preempt_context() change. (Chris)
> > Merged preemption trigger functions to one. (Chris)
> > Fixed conyext state tonot assume COMPLETED_MASK after preemption,
> > since idle-to-idle case will not have it set.
> >
> > v4: Simplified needs_preempt_context() change. (Daniele)
> > Removed clearing HWACK flag in idle-to-idle preempt. (Daniele)
> >
> > v5: Renamed inject_preempt_context(). (Daniele)
> > Removed duplicated GEM_BUG_ON() on HWACK (Daniele)
> >
> > v6: Added performance test results.
> >
> > Bspec: 18922
> > Cc: Joonas Lahtinen
> > Cc: Chris Wilson
> > Cc: Daniele Ceraolo Spurio
> > Cc: Michal Winiarski
> > Cc: Mika Kuoppala
> > Reviewed-by: Daniele Ceraolo Spurio
> > Signed-off-by: Tomasz Lis
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/i915_gem_context.c | 3 +-
> > drivers/gpu/drm/i915/i915_pci.c | 3 +-
> > drivers/gpu/drm/i915/intel_device_info.h | 1 +
> > drivers/gpu/drm/i915/intel_lrc.c | 109
> > +--
> > drivers/gpu/drm/i915/intel_lrc.h | 1 +
> > 6 files changed, 84 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 08d25aa..d2cc9f1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2579,6 +2579,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> > ((dev_priv)->info.has_logical_ring_elsq)
> > #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> > ((dev_priv)->info.has_logical_ring_preemption)
> > +#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
> > + ((dev_priv)->info.has_hw_preempt_to_idle)
> >
> > #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index b97963d..10b1d61 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -529,7 +529,8 @@ static void init_contexts(struct drm_i915_private *i915)
> >
> > static bool needs_preempt_context(struct drm_i915_private *i915)
> > {
> > - return HAS_LOGICAL_RING_PREEMPTION(i915);
> > + return HAS_LOGICAL_RING_PREEMPTION(i915) &&
> > +!HAS_HW
Re: [Intel-gfx] [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Fri, Dec 14, 2018 at 12:05 PM Mika Westerberg wrote: > > On Fri, Dec 14, 2018 at 11:48:35AM +0100, Hans de Goede wrote: > > > > +#include > > > > > > Why is this include needed? > > > > It is no longer needed in v4, since the parsing of the raw > > MIPI sequence data (which needed this include) has been moved > > to the i915 VBT code now. > > > > I've dropped this from my local version of the patch. > > OK. > > > Note sure if you (Mika) are the right person to ask, but in the > > coverletter of v1 I suggested merging all 3 patches through the i915 tree > > since the drivers/acpi/pmic/intel_pmic* files typically do > > not see all that churn. If I can get an Ack from you or > > Rafael for that then I can push the version with the include > > dropped to drm-next (through drm-intel-next-queued) myself > > once the 3th patch also has been acked. > > I guess it is up to Rafael whether my ack is enough Yes, it is. :-) > but here it is for both patches, > > Acked-by: Mika Westerberg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] Dynamic EU configuration of Slice/Subslice/EU.
Hi Joonas, On Fri, Dec 14, 2018 at 3:57 PM Joonas Lahtinen wrote: > > Quoting Ankit Navik (2018-12-11 12:14:17) > > drm/i915: Context aware user agnostic EU/Slice/Sub-slice control > > within kernel > > > > Current GPU configuration code for i915 does not allow us to change > > EU/Slice/Sub-slice configuration dynamically. Its done only once while > > context is created. > > > > While particular graphics application is running, if we examine the > > command requests from user space, we observe that command density is not > consistent. > > It means there is scope to change the graphics configuration > > dynamically even while context is running actively. This patch series > > proposes the solution to find the active pending load for all active > > context at given time and based on that, dynamically perform graphics > configuration for each context. > > > > We use a hr (high resolution) timer with i915 driver in kernel to get > > a callback every few milliseconds (this timer value can be configured > > through debugfs, default is '0' indicating timer is in disabled state > > i.e. original system without any intervention).In the timer callback, > > we examine pending commands for a context in the queue, essentially, > > we intercept them before they are executed by GPU and we update context > with required number of EUs. > > > > Two questions, how did we arrive at right timer value? and what's the > > right number of EUs? For the prior one, empirical data to achieve best > > performance in least power was considered. For the later one, we > > roughly categorized number of EUs logically based on platform. Now we > > compare number of pending commands with a particular threshold and > > then set number of EUs accordingly with update context. That threshold > > is also based on experiments & findings. If GPU is able to catch up > > with CPU, typically there are no pending commands, the EU config would > > remain unchanged there. In case there are more pending commands we > > reprogram context with higher number of EUs. Please note, here we are > changing EUs even while context is running by examining pending commands > every 'x' > > milliseconds. > > On the overall strategy. This will be unsuitable to be merged as a debugfs > interface. So is the idea to evolve into a sysfs interface? As this seems to > require > tuning for each specific workload, I don't think that would scale too well if > you > consider a desktop distro? We started initially as debugfs interface. I have added the comment to move the functionality into sysfs interface. Yes, I will consider the desktop distro and share the detail results. > > Also, there's the patch series to to enable/disable subslices with VME > hardware > (the other dynamic slice shutdown/SSEU series) depending on the type of load > being run. Certain workloads would hang the system if they're executed with > full > subslice configuration. In that light, it would make more sense if the > applications > would be the ones reporting their optimal running configuration. I think, the series expose rpcs for gen 11 only for VME use case. The patch I have tested on KBL (Gen 9). I will consider other gen 9 platform as well. > > > > > With this solution in place, on KBL-GT3 + Android we saw following pnp > > benefits, power numbers mentioned here are system power. > > > > App /KPI | % Power | > >| Benefit | > >| (mW) | > > -| > > 3D Mark (Ice storm)| 2.30% | > > TRex On screen | 2.49% | > > TRex Off screen| 1.32% | > > ManhattanOn screen | 3.11% | > > Manhattan Off screen | 0.89% | > > AnTuTu 6.1.4 | 3.42% | > > SynMark2 | 1.70% | > > Just to verify, these numbers are true while there's no negative effect on the > benchmark scores? Yes, There is no impact on the benchmark scores. Thank you Joonas for your valuable feedback. Regards, Ankit > > Regards, Joonas > > > Note - For KBL (GEN9) we cannot control at sub-slice level, it was > > always a constraint. > > We always controlled number of EUs rather than sub-slices/slices. > > We have also observed GPU core residencies improves by 1.03%. > > > > Praveen Diwakar (4): > > drm/i915: Get active pending request for given context > > drm/i915: Update render power clock state configuration for given > > context > > drm/i915: set optimum eu/slice/sub-slice configuration based on load > > type > > drm/i915: Predictive governor to control eu/slice/subslice > > > > drivers/gpu/drm/i915/i915_debugfs.c | 90 > +++- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++ > > drivers/gpu/drm/i915/i915_drv.h | 9 > > drivers/gpu/drm/i915/i915_gem_context.c | 23 > > drivers/gpu/drm/i915/i915_gem_context.h | 39 ++ > > drivers/gpu/drm/i915/i915_request.c | 2 + > > drivers/gpu/d
[Intel-gfx] [PATCH v5 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
Add support for PMIC MIPI sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
This fixes the DSI LCD panel not lighting up when not initialized by the
GOP (because an external monitor was connected) on GPD win and GPD pocket
devices.
Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
driven high, which is done through a PMIC MIPI sequence. Before this commit
if the sequence was not executed by the GOP the pin would stay low causing
the LCD panel to not work. Having the MIPI sequences properly control this
GPIO should also help save some power when the panel is off.
Changes in v2, v3:
-Only changes to other patches in this patch-set
Changes in v4:
-Move decoding of the raw 15 bytes PMIC MIPI sequence element into
i2c-address, register-address, value and mask into the mipi_exec_pmic()
function instead of passing the raw data to
intel_soc_pmic_exec_mipi_pmic_seq_element()
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index f27af47c6e49..ebe7e25614ce 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -29,9 +29,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include "i915_drv.h"
#include "intel_drv.h"
@@ -371,7 +373,25 @@ static const u8 *mipi_exec_spi(struct intel_dsi
*intel_dsi, const u8 *data)
static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
{
- DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+#ifdef CONFIG_PMIC_OPREGION
+ u32 value, mask, reg_address;
+ u16 i2c_address;
+ int ret;
+
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
+
+ ret = intel_soc_pmic_exec_mipi_pmic_seq_element(i2c_address,
+ reg_address,
+ value, mask);
+ if (ret)
+ DRM_ERROR("%s failed, error: %d\n", __func__, ret);
+#else
+ DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not
set\n");
+#endif
return data + 15;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Reviewed-by: Mika Westerberg
Signed-off-by: Hans de Goede
---
Changes in v4:
-The decoding of the raw data of the PMIC MIPI sequence element is now done
in our caller, so drop this and adjust the callback prototype to accept
the decoded addresses, value and mask
Changes in v3:
-Use hex values for out of range checks
-Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
instead of my own reverse engineered interpretation
---
drivers/acpi/pmic/intel_pmic_chtwc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..7ffd5624b8e1 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -231,6 +231,24 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
}
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ u16 i2c_client_address,
+ u32 reg_address,
+ u32 value, u32 mask)
+{
+ u32 address;
+
+ if (i2c_client_address > 0xff || reg_address > 0xff) {
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return -ERANGE;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+
+ return regmap_update_bits(regmap, address, mask, value);
+}
+
/*
* The thermal table and ops are empty, we do not support the Thermal opregion
* (DPTF) due to lacking documentation.
@@ -238,6 +256,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power = intel_cht_wc_pmic_get_power,
.update_power = intel_cht_wc_pmic_update_power,
+ .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count = ARRAY_SIZE(power_table),
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/3] ACPI/i915: Add support for PMIC MIPI sequence elements
Hi All, The main reason for sending out this v5 is because the CI failed v4 (even though it liked v1-v3 and nothing significant changed), this was likely a false positive, so the main goal of this version is to give this another CI run. Besides that I've dropped the unnecessary #include from the 2nd patch which Mika pointed out. Patches 1 and 2 have been Acked for merging through drm-intel-next-queued even though they are for the ACPI subsys, so that we can keep the set together. If I can get a Reviewed-by or Acked-by for the 3th patch from one of the i915 people, then I can push this set to dinq. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.
Reviewed-by: Mika Westerberg
Signed-off-by: Hans de Goede
---
Changes in v4:
-Pass i2c-address + register-address + value + mask as separate arguments to
the intel_soc_pmic_exec_mipi_pmic_seq_element function. Instead of passing
the 15 bytes of raw MIPI sequence data. The decoding will be done in the
i915 VBT code instead.
Changes in v3:
-Add kerneldoc for intel_soc_pmic_exec_mipi_pmic_seq_element
-Make intel_soc_pmic_exec_mipi_pmic_seq_element return errors
---
drivers/acpi/pmic/intel_pmic.c | 49 ++
drivers/acpi/pmic/intel_pmic.h | 2 ++
include/linux/mfd/intel_soc_pmic.h | 3 ++
3 files changed, 54 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..6bd25e96f41f 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
};
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
{
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev,
acpi_handle handle,
}
opregion->data = d;
+ intel_pmic_opregion = opregion;
return 0;
out_remove_thermal_handler:
@@ -319,3 +323,48 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
return ret;
}
EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
+/**
+ * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
+ * @i2c_address: I2C client address for the PMIC
+ * @reg_address: PMIC register address
+ * @value:New value for the register bits to change
+ * @mask: Mask indicating which register bits to change
+ *
+ * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
+ * BIOS Tables) using so called MIPI sequences. One possible element in these
+ * sequences is a PMIC specific element of 15 bytes.
+ *
+ * This function executes these PMIC specific elements sending the embedded
+ * commands to the PMIC.
+ *
+ * Return 0 on success, < 0 on failure.
+ */
+int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
+ u32 value, u32 mask)
+{
+ struct intel_pmic_opregion_data *d;
+ int ret;
+
+ if (!intel_pmic_opregion) {
+ pr_warn("%s: No PMIC registered\n", __func__);
+ return -ENXIO;
+ }
+
+ d = intel_pmic_opregion->data;
+ if (!d->exec_mipi_pmic_seq_element) {
+ pr_warn("%s: Not implemented\n", __func__);
+ pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
0x%x\n",
+ __func__, i2c_address, reg_address, value, mask);
+ return -EOPNOTSUPP;
+ }
+
+ mutex_lock(&intel_pmic_opregion->lock);
+ ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
+ i2c_address, reg_address,
+ value, mask);
+ mutex_unlock(&intel_pmic_opregion->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..5cd195fabca8 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,8 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+ int (*exec_mipi_pmic_seq_element)(struct regmap *r, u16 i2c_address,
+ u32 reg_address, u32 value, u32 mask);
struct pmic_table *power_table;
int power_table_count;
[Intel-gfx] [PATCH 7/7] drm/i915/selftests: Context SSEU reconfiguration tests
From: Tvrtko Ursulin
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 36 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 489 ++
2 files changed, 514 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 78d449b6245e..fcb19b6f635e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1042,24 +1042,23 @@ gen8_modify_rpcs_gpu(struct intel_context *ce,
return ret;
}
-static int
-i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+#if !IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+static
+#endif
+int
+__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
{
struct intel_context *ce = to_intel_context(ctx, engine);
- int ret;
+ int ret = 0;
GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
GEM_BUG_ON(engine->id != RCS);
- ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
- if (ret)
- return ret;
-
/* Nothing to do if unmodified. */
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
- goto out;
+ return 0;
/*
* If context is not idle we have to submit an ordered request to modify
@@ -1072,7 +1071,22 @@ i915_gem_context_reconfigure_sseu(struct
i915_gem_context *ctx,
if (!ret)
ce->sseu = sseu;
-out:
+ return ret;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ int ret;
+
+ ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
+ if (ret)
+ return ret;
+
+ ret = __i915_gem_context_reconfigure_sseu(ctx, engine, sseu);
+
mutex_unlock(&ctx->i915->drm.struct_mutex);
return ret;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 7d82043aff10..2b4eb5d05915 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -27,6 +27,8 @@
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
+#include "igt_reset.h"
+#include "igt_spinner.h"
#include "mock_drm.h"
#include "mock_gem_device.h"
@@ -650,6 +652,487 @@ static int igt_ctx_exec(void *arg)
return err;
}
+static struct i915_vma *rpcs_query_batch(struct i915_vma *vma)
+{
+ struct drm_i915_gem_object *obj;
+ u32 *cmd;
+ int err;
+
+ if (INTEL_GEN(vma->vm->i915) < 8)
+ return ERR_PTR(-EINVAL);
+
+ obj = i915_gem_object_create_internal(vma->vm->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(cmd)) {
+ err = PTR_ERR(cmd);
+ goto err;
+ }
+
+ *cmd++ = MI_STORE_REGISTER_MEM_GEN8;
+ *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE);
+ *cmd++ = lower_32_bits(vma->node.start);
+ *cmd++ = upper_32_bits(vma->node.start);
+ *cmd = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_unpin_map(obj);
+
+ err = i915_gem_object_set_to_gtt_domain(obj, false);
+ if (err)
+ goto err;
+
+ vma = i915_vma_instance(obj, vma->vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ goto err;
+
+ return vma;
+
+err:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+emit_rpcs_query(struct drm_i915_gem_object *obj,
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct i915_request **rq_out)
+{
+ struct i915_address_space *vm;
+ struct i915_request *rq;
+ struct i915_vma *batch;
+ struct i915_vma *vma;
+ int err;
+
+ GEM_BUG_ON(!ctx->ppgtt);
+ GEM_BUG_ON(!intel_engine_can_store_dword(engine));
+
+ vm = &ctx->ppgtt->vm;
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ err = i915_gem_object_set_to_gtt_domain(obj, false);
+ if (err)
+ return err;
+
+ err = i915_v
[Intel-gfx] [PATCH 5/7] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg =
{ .param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Cc: Dmitry Rogozhkin
Cc: Tvrtko Ursulin
Cc: Zhipeng Gong
Cc: Joonas Lahtinen
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 341 +++-
drivers
[Intel-gfx] [PATCH 4/7] drm/i915: Add timeline barrier support
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
v2:
* Assert barrier has been retired on timeline_fini. (Chris Wilson)
* Fix mock_timeline.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 13 +
drivers/gpu/drm/i915/i915_timeline.c | 3 +++
drivers/gpu/drm/i915/i915_timeline.h | 27 +++
.../gpu/drm/i915/selftests/mock_timeline.c| 2 ++
4 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 637909c59f1f..48c615db1810 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -566,6 +566,15 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static int add_timeline_barrier(struct i915_request *rq)
+{
+ struct i915_request *barrier =
+ i915_gem_active_raw(&rq->timeline->barrier,
+ &rq->i915->drm.struct_mutex);
+
+ return barrier ? i915_request_await_dma_fence(rq, &barrier->fence) : 0;
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -719,6 +728,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_timeline_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..5a87c5bd5154 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -37,6 +37,8 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(&timeline->requests);
i915_syncmap_init(&timeline->sync);
+
+ init_request_active(&timeline->barrier, NULL);
}
/**
@@ -69,6 +71,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
GEM_BUG_ON(!list_empty(&timeline->requests));
+ GEM_BUG_ON(i915_gem_active_isset(&timeline->barrier));
i915_syncmap_free(&timeline->sync);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index ebd71b487220..6ee301f20bab 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -72,6 +72,16 @@ struct i915_timeline {
*/
u32 global_sync[I915_NUM_ENGINES];
+ /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions be executed only after this barrier has been
+* completed.
+*/
+ struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
@@ -144,4 +154,21 @@ static inline bool i915_timeline_sync_is_later(struct
i915_timeline *tl,
void i915_timelines_park(struct drm_i915_private *i915);
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submitted to GPU
+ * until the barrier has been completed.
+ */
+static inline void
+i915_timeline_set_barrier(struct i915_timeline *timeline,
+ struct i915_request *rq)
+{
+ GEM_BUG_ON(timeline->fence_context == rq->timeline->fence_context);
+ i915_gem_active_set(&timeline->barrier, rq);
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index dcf3b16f5a07..a718b64c988e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -19,6 +19,8 @@ void mock_timeline_init(struct i915_timeline *timeline, u64
context)
i915_syncmap_init(&timeline->sync);
+ init_request_active(&timeline->barrier, NULL);
+
INIT_LIST_HEAD(&timeline->link);
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Record the sseu configuration per-context & engine
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Tvrtko Ursulin:
v7:
* Pass intel_sseu by pointer instead of value to make_rpcs.
* Rebase for make_rpcs changes.
v8:
* Rebase for RPCS edit on pin.
v9:
* Rebase for context image setup changes.
v10:
* Rename dev_priv to i915. (Chris Wilson)
v11:
* Rebase.
v12:
* Rebase for IS_GEN changes.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10
drivers/gpu/drm/i915/intel_lrc.c| 31 +
5 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c34198f51b13..f834602ed157 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3302,6 +3302,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)&dev_priv->info;
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = &INTEL_INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5905b6d8f291..a565643e9a26 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -343,6 +343,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = &ctx->__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(dev_priv);
}
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f6d870b1f73e..ef04e422cf9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -171,6 +172,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 90e9d170a0cd..07aaf9b43716 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 75d90918cac4..bfc31ccf5382 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1170,7 +1170,8 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32 make_rpcs(struct drm_i915_private *dev_priv);
+static u32
+make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
@@ -1185,7 +1186,8 @@ __execlists_update_reg_state(struct inte
[Intel-gfx] [PATCH 3/7] drm/i915/perf: lock powergating configuration to default when active
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Tvrtko Ursulin:
v4:
* Rebase for make_rpcs changes.
v5:
* Apply OA restriction from make_rpcs directly.
v6:
* Rebase for context image setup changes.
v7:
* Move stream assignment before metric enable.
v8-9:
* Rebase.
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_perf.c | 13 +
drivers/gpu/drm/i915/intel_lrc.c | 31 ---
drivers/gpu/drm/i915/intel_lrc.h | 2 ++
3 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4288c0e02f0c..7ac76c7aa4bf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,6 +1677,11 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(dev_priv,
+ &to_intel_context(ctx,
+dev_priv->engine[RCS])->sseu));
}
/*
@@ -2098,21 +2103,21 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
if (ret)
goto err_lock;
+ stream->ops = &i915_oa_stream_ops;
+ dev_priv->perf.oa.exclusive_stream = stream;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(stream);
if (ret) {
DRM_DEBUG("Unable to enable metric set\n");
goto err_enable;
}
- stream->ops = &i915_oa_stream_ops;
-
- dev_priv->perf.oa.exclusive_stream = stream;
-
mutex_unlock(&dev_priv->drm.struct_mutex);
return 0;
err_enable:
+ dev_priv->perf.oa.exclusive_stream = NULL;
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bfc31ccf5382..59e90d3e76f6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1170,9 +1170,6 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
-
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
struct intel_context *ce)
@@ -1186,8 +1183,8 @@ __execlists_update_reg_state(struct intel_engine_cs
*engine,
/* RPCS */
if (engine->class == RENDER_CLASS)
- regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915,
- &ce->sseu);
+ regs[CTX_R_PWR_CLK_STATE + 1] = gen8_make_rpcs(engine->i915,
+ &ce->sseu);
}
static struct intel_context *
@@ -2319,13 +2316,12 @@ int logical_xcs_ring_init(struct intel_engine_cs
*engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu)
+u32 gen8_make_rpcs(struct drm_
[Intel-gfx] [PATCH 0/7] Per context dynamic (sub)slice power-gating
From: Tvrtko Ursulin Re-send of the old series with the following highlights: * Rebased for drm-tip changes, mostly IS_GEN changes. * New patch adding some selftests for the feature. (Since majority of test code has been removed from the IGT.) Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (5): drm/i915/execlists: Move RPCS setup to context pin drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/icl: Support co-existence between per-context SSEU and OA drm/i915/selftests: Context SSEU reconfiguration tests drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 357 - drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 + drivers/gpu/drm/i915/intel_lrc.c | 100 ++-- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/i915_gem_context.c | 489 ++ .../gpu/drm/i915/selftests/mock_timeline.c| 2 + include/uapi/drm/i915_drm.h | 43 ++ 13 files changed, 1046 insertions(+), 37 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/icl: Support co-existence between per-context SSEU and OA
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
v3:
Lionel:
* Add bspec reference.
* Fix spelling in comment.
v4:
* Rebase for IS_GEN changes.
Signed-off-by: Tvrtko Ursulin
Bspec: 21140
Cc: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d392c2cef1d7..57a43d3d07f1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2333,13 +2333,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915,
struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* on the system.
+*
+* We could choose full enablement, but on ICL we know there are use
+* cases which disable slices for functional, apart for performance
+* reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN(i915, 11)) {
+ /*
+* We only need subslice count so it doesn't matter
+* which ones we select - just turn off low bits in the
+* amount of half of all available subslices per slice.
+*/
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915/execlists: Move RPCS setup to context pin
From: Tvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.
v2:
* Split image setup a bit differently. (Chris Wilson)
v3:
* Update context image after reset as well - otherwise the application
of pinned default state clears the RPCS.
v4:
* Use local variable throughout the function. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 45
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1c9748f391fe..75d90918cac4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1170,6 +1170,24 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
+static u32 make_rpcs(struct drm_i915_private *dev_priv);
+
+static void
+__execlists_update_reg_state(struct intel_engine_cs *engine,
+struct intel_context *ce)
+{
+ u32 *regs = ce->lrc_reg_state;
+ struct intel_ring *ring = ce->ring;
+
+ regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(ring->vma);
+ regs[CTX_RING_HEAD + 1] = ring->head;
+ regs[CTX_RING_TAIL + 1] = ring->tail;
+
+ /* RPCS */
+ if (engine->class == RENDER_CLASS)
+ regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915);
+}
+
static struct intel_context *
__execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
@@ -1208,10 +1226,8 @@ __execlists_context_pin(struct intel_engine_cs *engine,
GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
- ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
- i915_ggtt_offset(ce->ring->vma);
- ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
- ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
+
+ __execlists_update_reg_state(engine, ce);
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -1835,14 +1851,14 @@ static void execlists_reset(struct intel_engine_cs
*engine,
engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
engine->context_size - PAGE_SIZE);
}
- execlists_init_reg_state(regs,
-request->gem_context, engine, request->ring);
/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
- regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
-
request->ring->head = intel_ring_wrap(request->ring, request->postfix);
- regs[CTX_RING_HEAD + 1] = request->ring->head;
+
+ execlists_init_reg_state(regs, request->gem_context, engine,
+request->ring);
+
+ __execlists_update_reg_state(engine, request->hw_context);
intel_ring_update_space(request->ring);
@@ -2526,8 +2542,7 @@ static void execlists_init_reg_state(u32 *regs,
if (rcs) {
regs[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
- CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
- make_rpcs(dev_priv));
+ CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE, 0);
i915_oa_init_reg_state(engine, ctx, regs);
}
@@ -2688,12 +2703,8 @@ void intel_lr_context_resume(struct drm_i915_private
*i915)
intel_ring_reset(ce->ring, 0);
- if (ce->pin_count) { /* otherwise done in context_pin */
- u32 *regs = ce->lrc_reg_state;
-
- regs[CTX_RING_HEAD + 1] = ce->ring->head;
- regs[CTX_RING_TAIL + 1] = ce->ring->tail;
- }
+ if (ce->pin_count) /* otherwise done in context_pin */
+ __execlists_update_reg_state(engine, ce);
}
}
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for ACPI/i915: Add support for PMIC MIPI sequence elements
== Series Details ==
Series: ACPI/i915: Add support for PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/54050/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5317 -> Patchwork_11094
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54050/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11094 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bsw-n3050: PASS -> DMESG-FAIL [fdo#108656]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* {igt@runner@aborted}:
- fi-bsw-n3050: NOTRUN -> FAIL [fdo#108656]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 46)
--
Additional (1): fi-byt-j1900
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5317 -> Patchwork_11094
CI_DRM_5317: 10c50ecb5eaa0176514e610d0c8bfd13babf88e0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11094: 0abd01482433b40f1ba070ba3728eba1c0ff5460 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0abd01482433 drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
82e50ee72bc5 ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey
Cove PMIC
fdd18415794c ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11094/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev8)
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev8)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7bc81b868afe drm/i915/execlists: Move RPCS setup to context pin
5939874afc3d drm/i915: Record the sseu configuration per-context & engine
359b2f7b3643 drm/i915/perf: lock powergating configuration to default when
active
db1043fd7760 drm/i915: Add timeline barrier support
62f6ae9d552a drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11
only)
-:47: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#47:
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
-:499: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'user->min_eus_per_subslice !=
device->max_eus_per_subslice'
#499: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1171:
+ if ((user->min_eus_per_subslice !=
+device->max_eus_per_subslice) ||
+ (user->max_eus_per_subslice !=
+device->max_eus_per_subslice))
-:499: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'user->max_eus_per_subslice !=
device->max_eus_per_subslice'
#499: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1171:
+ if ((user->min_eus_per_subslice !=
+device->max_eus_per_subslice) ||
+ (user->max_eus_per_subslice !=
+device->max_eus_per_subslice))
total: 0 errors, 1 warnings, 2 checks, 479 lines checked
393ecc46aec2 drm/i915/icl: Support co-existence between per-context SSEU and OA
b3cba63fa219 drm/i915/selftests: Context SSEU reconfiguration tests
-:222: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#222: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:784:
+int
-:402: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#402: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:964:
+ return -EINVAL;
+ } else {
-:409: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#409: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:971:
+
+}
total: 0 errors, 2 warnings, 1 checks, 563 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating (rev8)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev8) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Move RPCS setup to context pin Okay! Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3562:16: warning: expression using sizeof(void) Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: Add timeline barrier support Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) +drivers/gpu/drm/i915/intel_lrc.c:2374:25: warning: expression using sizeof(void) Commit: drm/i915/icl: Support co-existence between per-context SSEU and OA Okay! Commit: drm/i915/selftests: Context SSEU reconfiguration tests +drivers/gpu/drm/i915/i915_gem_context.c:1049:1: warning: symbol '__i915_gem_context_reconfigure_sseu' was not declared. Should it be static? +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1223:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1223:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1223:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1223:25: warning: expression using sizeof(void) +./include/linux/slab.h:332:43: warning: dubious: x & !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/selftests: Context SSEU reconfiguration tests
Quoting Tvrtko Ursulin (2018-12-14 12:34:49)
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 78d449b6245e..fcb19b6f635e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -1042,24 +1042,23 @@ gen8_modify_rpcs_gpu(struct intel_context *ce,
> return ret;
> }
>
> -static int
> -i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> - struct intel_engine_cs *engine,
> - struct intel_sseu sseu)
> +#if !IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> +static
> +#endif
> +int
> +__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine,
> + struct intel_sseu sseu)
> {
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> index 7d82043aff10..2b4eb5d05915 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
selftests/i915_gem_context.c a continuation of i915_gem_context.c so it
has sneaky access to statics.
See the #include "selftests/i915_gem_context.c" at the end.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Per context dynamic (sub)slice power-gating (rev8)
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev8)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5317 -> Patchwork_11095
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48194/revisions/8/mbox/
Known issues
Here are the changes found in Patchwork_11095 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 46)
--
Additional (2): fi-icl-y fi-byt-j1900
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-ctg-p8600
fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5317 -> Patchwork_11095
CI_DRM_5317: 10c50ecb5eaa0176514e610d0c8bfd13babf88e0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11095: b3cba63fa219d779aea8de26f15d4d9e311a57e5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b3cba63fa219 drm/i915/selftests: Context SSEU reconfiguration tests
393ecc46aec2 drm/i915/icl: Support co-existence between per-context SSEU and OA
62f6ae9d552a drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11
only)
db1043fd7760 drm/i915: Add timeline barrier support
359b2f7b3643 drm/i915/perf: lock powergating configuration to default when
active
5939874afc3d drm/i915: Record the sseu configuration per-context & engine
7bc81b868afe drm/i915/execlists: Move RPCS setup to context pin
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11095/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/selftests: Context SSEU reconfiguration tests
Quoting Tvrtko Ursulin (2018-12-14 12:34:49)
> +static struct i915_vma *rpcs_query_batch(struct i915_vma *vma)
> +{
> + struct drm_i915_gem_object *obj;
> + u32 *cmd;
> + int err;
> +
> + if (INTEL_GEN(vma->vm->i915) < 8)
> + return ERR_PTR(-EINVAL);
> +
> + obj = i915_gem_object_create_internal(vma->vm->i915, PAGE_SIZE);
> + if (IS_ERR(obj))
> + return ERR_CAST(obj);
> +
> + cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
> + if (IS_ERR(cmd)) {
> + err = PTR_ERR(cmd);
> + goto err;
> + }
> +
> + *cmd++ = MI_STORE_REGISTER_MEM_GEN8;
> + *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE);
> + *cmd++ = lower_32_bits(vma->node.start);
> + *cmd++ = upper_32_bits(vma->node.start);
> + *cmd = MI_BATCH_BUFFER_END;
> +
> + i915_gem_object_unpin_map(obj);
> +
> + err = i915_gem_object_set_to_gtt_domain(obj, false);
> + if (err)
> + goto err;
> +
> + vma = i915_vma_instance(obj, vma->vm, NULL);
> + if (IS_ERR(vma)) {
> + err = PTR_ERR(vma);
> + goto err;
> + }
> +
> + err = i915_vma_pin(vma, 0, 0, PIN_USER);
> + if (err)
> + goto err;
> +
> + return vma;
> +
> +err:
> + i915_gem_object_put(obj);
> + return ERR_PTR(err);
> +}
> +
> +static int
> +emit_rpcs_query(struct drm_i915_gem_object *obj,
> + struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine,
> + struct i915_request **rq_out)
> +{
> + struct i915_address_space *vm;
> + struct i915_request *rq;
> + struct i915_vma *batch;
> + struct i915_vma *vma;
> + int err;
> +
> + GEM_BUG_ON(!ctx->ppgtt);
> + GEM_BUG_ON(!intel_engine_can_store_dword(engine));
> +
> + vm = &ctx->ppgtt->vm;
> +
> + vma = i915_vma_instance(obj, vm, NULL);
> + if (IS_ERR(vma))
> + return PTR_ERR(vma);
> +
> + err = i915_gem_object_set_to_gtt_domain(obj, false);
> + if (err)
> + return err;
> +
> + err = i915_vma_pin(vma, 0, 0, PIN_HIGH | PIN_USER);
> + if (err)
> + return err;
> +
> + batch = rpcs_query_batch(vma);
> + if (IS_ERR(batch)) {
> + err = PTR_ERR(batch);
> + goto err_vma;
> + }
Simpler would be to just emit the SRM into the ring. One less object+vma
to handle.
> +
> + rq = i915_request_alloc(engine, ctx);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + goto err_batch;
> + }
> +
> + err = engine->emit_bb_start(rq, batch->node.start, batch->node.size,
> 0);
> + if (err)
> + goto err_request;
> +
> + err = i915_vma_move_to_active(batch, rq, 0);
> + if (err)
> + goto skip_request;
> +
> + err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
> + if (err)
> + goto skip_request;
> +
> + i915_gem_object_set_active_reference(batch->obj);
> + i915_vma_unpin(batch);
> + i915_vma_close(batch);
> +
> + i915_vma_unpin(vma);
> +
> + *rq_out = i915_request_get(rq);
> +
> + i915_request_add(rq);
> +
> + return 0;
> +
> +skip_request:
> + i915_request_skip(rq, err);
> +err_request:
> + i915_request_add(rq);
> +err_batch:
> + i915_vma_unpin(batch);
> +err_vma:
> + i915_vma_unpin(vma);
> +
> + return err;
> +}
> +
> +#define TEST_IDLE (1 << 0)
> +#define TEST_BUSY (1 << 1)
> +#define TEST_RESET (1 << 2)
> +
> +int
> +__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine,
> + struct intel_sseu sseu);
> +
> +static int
> +__pre_set(struct drm_i915_private *i915,
> + unsigned int flags,
> + struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine,
> + struct igt_spinner **spin_out)
> +{
> + int ret = 0;
> +
> + if (flags & (TEST_BUSY | TEST_RESET)) {
> + struct igt_spinner *spin;
> + struct i915_request *rq;
> +
> + spin = kzalloc(sizeof(*spin), GFP_KERNEL);
> + if (!spin) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + ret = igt_spinner_init(spin, i915);
> + if (ret)
> + return ret;
> +
> + rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
> + if (IS_ERR(rq)) {
> + ret = PTR_ERR(rq);
> + igt_spinner_fini(spin);
> + kfree(spin);
> + goto out;
> + }
> +
> + i915_request_add(rq);
> +
> + if (!igt_wait_for_spinner(spin,
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Add timeline barrier support
Quoting Tvrtko Ursulin (2018-12-14 12:34:46)
> diff --git a/drivers/gpu/drm/i915/i915_timeline.h
> b/drivers/gpu/drm/i915/i915_timeline.h
> index ebd71b487220..6ee301f20bab 100644
> --- a/drivers/gpu/drm/i915/i915_timeline.h
> +++ b/drivers/gpu/drm/i915/i915_timeline.h
> @@ -72,6 +72,16 @@ struct i915_timeline {
> */
> u32 global_sync[I915_NUM_ENGINES];
>
> + /**
> +* Barrier provides the ability to serialize ordering between
> different
> +* timelines.
> +*
> +* Users can call i915_timeline_set_barrier which will make all
> +* subsequent submissions be executed only after this barrier has been
submissions on/to this timeline
then s/this barrier/the barrier/ to avoid repitation of this.
> +* completed.
> +*/
> + struct i915_gem_active barrier;
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Enable fastset for non-boot modesets.
Now that our state comparison functions are pretty complete, we should
enable fastset by default when a modeset can be avoided. Even if we're
not completely certain about the inherited state, we can be certain
after the first modeset that our sw state matches the hw state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 86e7b145fd98..2dd99e5437a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11651,6 +11651,11 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
(current_config->base.mode.private_flags &
I915_MODE_FLAG_INHERITED) &&
!(pipe_config->base.mode.private_flags &
I915_MODE_FLAG_INHERITED);
+ if (fixup_inherited && !i915_modparams.fastboot) {
+ drm_dbg(DRM_UT_KMS, "initial modeset and fastboot not set\n");
+ ret = false;
+ }
+
#define PIPE_CONF_CHECK_X(name) do { \
if (current_config->name != pipe_config->name) { \
pipe_config_err(adjust, __stringify(name), \
@@ -12674,8 +12679,7 @@ static int intel_atomic_check(struct drm_device *dev,
return ret;
}
- if (i915_modparams.fastboot &&
- intel_pipe_config_compare(dev_priv,
+ if (intel_pipe_config_compare(dev_priv,
to_intel_crtc_state(old_crtc_state),
pipe_config, true)) {
crtc_state->mode_changed = false;
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Re-enable fastset by default
Now that we've solved the backlight issue, I think it's time to enable this again by default. We've enabled it in the past, but backlight issues prevented us from enabling it by default. Our hardware readout is pretty complete, and with all of the connector state moved to atomic I'm hoping we finally have enough capability to re-enable fastset by default. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 7e56c516c815..149ab592a695 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -57,7 +57,7 @@ struct drm_printer; /* leave bools at the end to not create holes */ \ param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \ param(bool, enable_hangcheck, true) \ - param(bool, fastboot, false) \ + param(bool, fastboot, true) \ param(bool, prefault_disable, false) \ param(bool, load_detect_test, false) \ param(bool, force_reset_modeset_test, false) \ -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/backlight: Fix backlight takeover on LPT, v2.
On lynxpoint the bios sometimes sets up the backlight using the CPU
display, but the driver expects using the PWM PCH override register.
Read the value from the CPU register, then convert it to the other
units by converting from the old duty cycle, to freq, to the new units.
This value is then programmed in the override register, after which
we set the override and disable the CPU display control. This allows
us to switch the source without flickering, and make the backlight
controls work in the driver.
Changes since v1:
- Read BLC_PWM_CPU_CTL2 to cpu_ctl2.
- Clean up cpu_mode if slightly.
- Always disable BLM_PWM_ENABLE in cpu_ctl2.
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108225
Cc: Basil Eric Rabi
Cc: Hans de Goede
Cc: Tolga Cakir
Cc: Ville Syrjälä
Tested-by: Tolga Cakir
---
drivers/gpu/drm/i915/intel_panel.c | 40 +++---
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 799284fcd57d..3e3ce7a77700 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1484,8 +1484,8 @@ static int lpt_setup_backlight(struct intel_connector
*connector, enum pipe unus
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = &connector->panel;
- u32 pch_ctl1, pch_ctl2, val;
- bool alt;
+ u32 cpu_ctl2, pch_ctl1, pch_ctl2, val;
+ bool alt, cpu_mode;
if (HAS_PCH_LPT(dev_priv))
alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
@@ -1499,6 +1499,8 @@ static int lpt_setup_backlight(struct intel_connector
*connector, enum pipe unus
pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
panel->backlight.max = pch_ctl2 >> 16;
+ cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
+
if (!panel->backlight.max)
panel->backlight.max = get_backlight_max_vbt(connector);
@@ -1507,12 +1509,42 @@ static int lpt_setup_backlight(struct intel_connector
*connector, enum pipe unus
panel->backlight.min = get_backlight_min_vbt(connector);
- val = lpt_get_backlight(connector);
+ panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
+
+ cpu_mode = panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
+ !(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE) &&
+ (cpu_ctl2 & BLM_PWM_ENABLE);
+ if (cpu_mode) {
+ u32 freq;
+
+ /*
+* We're in cpu mode, convert to PCH units.
+*
+* Convert CPU pwm tick back to hz, back to new PCH units again.
+* this is the same formula as pch_hz_to_pwm, but the other way
+* around..
+*/
+ val = pch_get_backlight(connector);
+ freq = DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), val * 128);
+
+ DRM_DEBUG_KMS("Backlight PCH value: %u, converted to freq %u,
converted to lpt units %u, minmax: %u/%u\n",
+ val, freq, lpt_hz_to_pwm(connector, freq),
panel->backlight.min, panel->backlight.max);
+
+ val = lpt_hz_to_pwm(connector, freq);
+ } else
+ val = lpt_get_backlight(connector);
val = intel_panel_compute_brightness(connector, val);
panel->backlight.level = clamp(val, panel->backlight.min,
panel->backlight.max);
- panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
+ if (cpu_mode) {
+ /* Write converted CPU PWM value to PCH override register */
+ lpt_set_backlight(connector->base.state,
panel->backlight.level);
+ I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 |
BLM_PCH_OVERRIDE_ENABLE);
+ }
+
+ if (cpu_ctl2 & BLM_PWM_ENABLE)
+ I915_WRITE(BLC_PWM_CPU_CTL2, cpu_ctl2 & ~BLM_PWM_ENABLE);
return 0;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/backlight: Restore backlight on resume, v2.
Restore our saved values for backlight. This way even with fastset on
S4 resume we will correctly restore the backlight to the active values.
Changes since v1:
- Call enable_backlight() when backlight.level is set. On suspend
backlight.enabled is always cleared, this makes it not a good
indicator. Also check for crtc->state->active.
Signed-off-by: Maarten Lankhorst
Cc: Tolga Cakir
Cc: Basil Eric Rabi
Cc: Hans de Goede
Cc: Ville Syrjälä
Reported-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 30
3 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c3f3f68d506..86e7b145fd98 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15887,7 +15887,9 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state, &ctx);
+ intel_panel_restore_backlight(dev_priv);
intel_enable_ipc(dev_priv);
+
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d08f08f607dd..1fa6e167ddd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2000,6 +2000,7 @@ int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode,
struct drm_display_mode *downclock_mode);
void intel_panel_fini(struct intel_panel *panel);
+void intel_panel_restore_backlight(struct drm_i915_private *dev_priv);
void intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode);
void intel_pch_panel_fitting(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index ee3e0842d542..799284fcd57d 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1903,6 +1903,36 @@ intel_panel_init_backlight_funcs(struct intel_panel
*panel)
}
}
+void intel_panel_restore_backlight(struct drm_i915_private *dev_priv)
+{
+ struct intel_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+
+ /* Kill all the work that may have been queued by hpd. */
+ drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
+ for_each_intel_connector_iter(connector, &conn_iter) {
+ struct intel_panel *panel = &connector->panel;
+ const struct drm_connector_state *conn_state =
+ connector->base.state;
+
+ if (!panel->backlight.present)
+ continue;
+
+ if (panel->backlight.level && conn_state->crtc &&
+ conn_state->crtc->state->active) {
+ const struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(conn_state->crtc->state);
+
+ intel_panel_enable_backlight(crtc_state, conn_state);
+ } else {
+ WARN(panel->backlight.enabled, "Backlight enabled
without crtc\n");
+
+ intel_panel_disable_backlight(conn_state);
+ }
+ }
+ drm_connector_list_iter_end(&conn_iter);
+}
+
int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode,
struct drm_display_mode *downclock_mode)
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
Quoting Tvrtko Ursulin (2018-12-14 12:34:47)
> +static int get_sseu(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + struct drm_i915_gem_context_param_sseu user_sseu;
> + struct intel_engine_cs *engine;
> + struct intel_context *ce;
> + int ret;
> +
> + if (args->size == 0)
> + goto out;
> + else if (args->size < sizeof(user_sseu))
> + return -EINVAL;
> +
> + if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value),
> + sizeof(user_sseu)))
> + return -EFAULT;
> +
> + if (user_sseu.rsvd1 || user_sseu.rsvd2)
> + return -EINVAL;
I'd vote for s/rsvd2/flags/ straight away as already I can suggest we
allow for USE_CTX_ENGINE to swap class/instance for engine-id so that we
can set rpcs for, and not least, a virtual engine.
> +
> + engine = intel_engine_lookup_user(ctx->i915,
> + user_sseu.class,
> + user_sseu.instance);
> + if (!engine)
> + return -EINVAL;
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/backlight: Restore backlight on resume, v2.
== Series Details ==
Series: series starting with [1/4] drm/i915/backlight: Restore backlight on
resume, v2.
URL : https://patchwork.freedesktop.org/series/54052/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d772e5f0dbbb drm/i915/backlight: Restore backlight on resume, v2.
de921f1a6b4f drm/i915/backlight: Fix backlight takeover on LPT, v2.
-:67: CHECK:BRACES: braces {} should be used on all arms of this statement
#67: FILE: drivers/gpu/drm/i915/intel_panel.c:1517:
+ if (cpu_mode) {
[...]
+ } else
[...]
-:81: WARNING:LONG_LINE: line over 100 characters
#81: FILE: drivers/gpu/drm/i915/intel_panel.c:1531:
+ val, freq, lpt_hz_to_pwm(connector, freq),
panel->backlight.min, panel->backlight.max);
-:84: CHECK:BRACES: Unbalanced braces around else statement
#84: FILE: drivers/gpu/drm/i915/intel_panel.c:1534:
+ } else
total: 0 errors, 1 warnings, 2 checks, 62 lines checked
c496b3b7d6f5 drm/i915: Enable fastset for non-boot modesets.
-:36: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#36: FILE: drivers/gpu/drm/i915/intel_display.c:12683:
+ if (intel_pipe_config_compare(dev_priv,
to_intel_crtc_state(old_crtc_state),
total: 0 errors, 0 warnings, 1 checks, 20 lines checked
e071407b960f drm/i915: Re-enable fastset by default
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/backlight: Restore backlight on resume, v2.
== Series Details == Series: series starting with [1/4] drm/i915/backlight: Restore backlight on resume, v2. URL : https://patchwork.freedesktop.org/series/54052/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/backlight: Restore backlight on resume, v2. Okay! Commit: drm/i915/backlight: Fix backlight takeover on LPT, v2. -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_panel.c:1512:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_panel.c:1537:34: warning: expression using sizeof(void) Commit: drm/i915: Enable fastset for non-boot modesets. Okay! Commit: drm/i915: Re-enable fastset by default Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for ACPI/i915: Add support for PMIC MIPI sequence elements
== Series Details == Series: ACPI/i915: Add support for PMIC MIPI sequence elements URL : https://patchwork.freedesktop.org/series/54050/ State : success == Summary == CI Bug Log - changes from CI_DRM_5317_full -> Patchwork_11094_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11094_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] * igt@gem_cpu_reloc@full: - shard-skl: NOTRUN -> TIMEOUT [fdo#108248] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@i915_suspend@shrink: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#108784] * igt@i915_suspend@sysfs-reader: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1 * igt@kms_available_modes_crc@available_mode_test_crc: - shard-skl: NOTRUN -> FAIL [fdo#106641] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-apl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3 * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: - shard-glk: PASS -> FAIL [fdo#103184] * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled: - shard-iclb: NOTRUN -> WARN [fdo#108336] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> DMESG-FAIL [fdo#107724] +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] / [fdo#108336] +4 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] * igt@kms_pipe_crc_basic@read-crc-pipe-a: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] +10 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] +3 * igt@kms_plane_multiple@atomic-pipe-b-tiling-x: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_psr@no_drrs: - shard-iclb: PASS -> FAIL [fdo#108341] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] * igt@perf_pmu@rc6-runtime-pm: - shard-kbl: PASS -> FAIL [fdo#105010] * igt@pm_rpm@cursor-dpms: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@pm_rpm@dpms-mode-unset-non-lpsp: - shard-skl: SKIP -> INCOMPLETE [fdo#107807] Possible fixes * igt@kms_color@pipe-a-ctm-max: - shard-skl: FAIL [fdo#108147] -> PASS * igt@kms_color@pipe-c-ctm-negative: - shard-skl: FAIL [fdo#107361] -> PASS * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-skl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: - shard-iclb: FAIL -> PASS * igt@kms_draw_crc@draw-method-xrgb-mmap-cpu-untiled: - shard-skl: FAIL [fdo#108472] -> PASS * igt@kms_fbcon_fbt@fbc: - shard-skl: FAIL [fdo#103833] / [fdo#105682] -> PASS * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_flip@flip-vs-modeset-vs-hang: - shard-apl: INCOMPLETE [fdo#103927] -> PASS * igt@kms_flip_tiling@f
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/backlight: Restore backlight on resume, v2.
== Series Details ==
Series: series starting with [1/4] drm/i915/backlight: Restore backlight on
resume, v2.
URL : https://patchwork.freedesktop.org/series/54052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5317 -> Patchwork_11096
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54052/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11096:
### IGT changes ###
Possible regressions
* {igt@runner@aborted}:
- fi-skl-iommu: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_11096 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: PASS -> DMESG-FAIL [fdo#102614]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 47)
--
Additional (2): fi-icl-y fi-byt-j1900
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5317 -> Patchwork_11096
CI_DRM_5317: 10c50ecb5eaa0176514e610d0c8bfd13babf88e0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11096: e071407b960f3edda2700bc8a9d9d548aae298ad @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e071407b960f drm/i915: Re-enable fastset by default
c496b3b7d6f5 drm/i915: Enable fastset for non-boot modesets.
de921f1a6b4f drm/i915/backlight: Fix backlight takeover on LPT, v2.
d772e5f0dbbb drm/i915/backlight: Restore backlight on resume, v2.
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11096/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] PM/pm_runtime: move autosuspend on hrtimer
pm runtime uses the timer infrastructure for autosuspend. This implies that
the minimum time before autosuspending a device is in the range
of 1 tick included to 2 ticks excluded
-On arm64 this means between 4ms and 8ms with default jiffies configuration
-And on arm, it is between 10ms and 20ms
These values are quite high for embedded system which sometimes wants
duration in the range of 1 ms.
We can move autosuspend on hrtimer to get finer granularity for short
duration and takes advantage of slack to keep some margins and gathers
long timeout in minimum wakeups.
On an arm64 platform that uses 1ms for autosuspending timeout of its GPU,
the power consumption improves by 10% for idle use case with hrtimer.
The latency impact on arm64 hikey octo cores is :
- mark_last_busy: from 1.11 us to 1.25 us
- rpm_suspend: from 15.54 us to 15.38 us
Only the code path of rpm_suspend that starts hrtimer has been measured
arm64 image (arm64 default defconfig) decreases by around 3KB
with following details:
$ size vmlinux-timer
textdata bss dec hex filename
120346466869268 386840 192907541265a82 vmlinux
$ size vmlinux-hrtimer
textdata bss dec hex filename
120305506870164 387032 192877461264ec2 vmlinux
The latency impact on arm 32bits snowball dual cores is :
- mark_last_busy: from 0.31 us usec to 0.77 us
- rpm_suspend: from 6.83 us to 6.67 usec
The increase of the image for snowball platform that I used for testing
performance impact, is neglictable (244B)
$ size vmlinux-timer
textdata bss dec hex filename
7157961 2119580 264120 9541661 91981d build-ux500/vmlinux
size vmlinux-hrtimer
textdata bss dec hex filename
7157773 2119884 264248 9541905 919911 vmlinux-hrtimer
And arm 32bits image (multi_v7_defconfig) increases by around 1.7KB
with following details:
$ size vmlinux-timer
textdata bss dec hex filename
133044436803420 402768 20510631138f7a7 vmlinux
$ size vmlinux-hrtimer
textdata bss dec hex filename
133042996805276 402768 20512343138fe57 vmlinux
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 63
include/linux/pm.h | 5 ++--
include/linux/pm_runtime.h | 6 ++---
3 files changed, 40 insertions(+), 34 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index beb85c3..7062469 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -8,6 +8,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -93,7 +95,7 @@ static void __update_runtime_status(struct device *dev, enum
rpm_status status)
static void pm_runtime_deactivate_timer(struct device *dev)
{
if (dev->power.timer_expires > 0) {
- del_timer(&dev->power.suspend_timer);
+ hrtimer_cancel(&dev->power.suspend_timer);
dev->power.timer_expires = 0;
}
}
@@ -124,12 +126,11 @@ static void pm_runtime_cancel_pending(struct device *dev)
* This function may be called either with or without dev->power.lock held.
* Either way it can be racy, since power.last_busy may be updated at any time.
*/
-unsigned long pm_runtime_autosuspend_expiration(struct device *dev)
+u64 pm_runtime_autosuspend_expiration(struct device *dev)
{
int autosuspend_delay;
- long elapsed;
- unsigned long last_busy;
- unsigned long expires = 0;
+ u64 last_busy, expires = 0;
+ u64 now = ktime_to_ns(ktime_get());
if (!dev->power.use_autosuspend)
goto out;
@@ -139,19 +140,9 @@ unsigned long pm_runtime_autosuspend_expiration(struct
device *dev)
goto out;
last_busy = READ_ONCE(dev->power.last_busy);
- elapsed = jiffies - last_busy;
- if (elapsed < 0)
- goto out; /* jiffies has wrapped around. */
- /*
-* If the autosuspend_delay is >= 1 second, align the timer by rounding
-* up to the nearest second.
-*/
- expires = last_busy + msecs_to_jiffies(autosuspend_delay);
- if (autosuspend_delay >= 1000)
- expires = round_jiffies(expires);
- expires += !expires;
- if (elapsed >= expires - last_busy)
+ expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
+ if (expires <= now)
expires = 0;/* Already expired. */
out:
@@ -515,7 +506,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
/* If the autosuspend_delay time hasn't expired yet, reschedule. */
if ((rpmflags & RPM_AUTO)
&& dev->power.runtime_status != RPM_SUSPENDING) {
- unsigned long expires = pm_runtime_autosuspend_expiration(dev);
+ u64 expires = pm_runtime_autosuspend_expiration(dev);
if (expires != 0) {
/*
[Intel-gfx] [PATCH v2 2/3] PM/runtime:Replace jiffies based accouting with ktime based accounting
From: Thara Gopinath
This patch replaces jiffies based accoutning for runtime_active_time
and runtime_suspended_time with ktime base accounting. This makes the
runtime debug counters inline with genpd and other pm subsytems which
uses ktime based accounting.
Signed-off-by: Thara Gopinath
[move from ktime to raw nsec]
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 10 +-
drivers/base/power/sysfs.c | 11 ---
include/linux/pm.h | 6 +++---
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 7062469..89655e2 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -66,8 +66,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
*/
void update_pm_runtime_accounting(struct device *dev)
{
- unsigned long now = jiffies;
- unsigned long delta;
+ u64 now = ktime_to_ns(ktime_get());
+ u64 delta;
delta = now - dev->power.accounting_timestamp;
@@ -77,9 +77,9 @@ void update_pm_runtime_accounting(struct device *dev)
return;
if (dev->power.runtime_status == RPM_SUSPENDED)
- dev->power.suspended_jiffies += delta;
+ dev->power.suspended_time += delta;
else
- dev->power.active_jiffies += delta;
+ dev->power.active_time += delta;
}
static void __update_runtime_status(struct device *dev, enum rpm_status status)
@@ -1491,7 +1491,7 @@ void pm_runtime_init(struct device *dev)
dev->power.request_pending = false;
dev->power.request = RPM_REQ_NONE;
dev->power.deferred_resume = false;
- dev->power.accounting_timestamp = jiffies;
+ dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
INIT_WORK(&dev->power.work, pm_runtime_work);
dev->power.timer_expires = 0;
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d713738..96c8a22 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -125,9 +125,12 @@ static ssize_t runtime_active_time_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
int ret;
+ u64 tmp;
spin_lock_irq(&dev->power.lock);
update_pm_runtime_accounting(dev);
- ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies));
+ tmp = dev->power.active_time;
+ do_div(tmp, NSEC_PER_MSEC);
+ ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(&dev->power.lock);
return ret;
}
@@ -138,10 +141,12 @@ static ssize_t runtime_suspended_time_show(struct device
*dev,
struct device_attribute *attr, char *buf)
{
int ret;
+ u64 tmp;
spin_lock_irq(&dev->power.lock);
update_pm_runtime_accounting(dev);
- ret = sprintf(buf, "%i\n",
- jiffies_to_msecs(dev->power.suspended_jiffies));
+ tmp = dev->power.suspended_time;
+ do_div(tmp, NSEC_PER_MSEC);
+ ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(&dev->power.lock);
return ret;
}
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 0bd9de1..3d2cbf9 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -633,9 +633,9 @@ struct dev_pm_info {
int runtime_error;
int autosuspend_delay;
u64 last_busy;
- unsigned long active_jiffies;
- unsigned long suspended_jiffies;
- unsigned long accounting_timestamp;
+ u64 active_time;
+ u64 suspended_time;
+ u64 accounting_timestamp;
#endif
struct pm_subsys_data *subsys_data; /* Owned by the subsystem. */
void (*set_latency_tolerance)(struct device *, s32);
--
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/3] PM/pm_runtime: move on hrtimer and nsec
Move pm_runtime on hrtimer and raw ns time to get finer granularity Patch 1 moves runtime_pm autosuspend on hrtimer framework Patch 2 moves time accounting on raw ns. This patch initially used ktime instead of raw ns but it was easier to move i915 driver on raw ns than on ktime Patch 3 fixes drm/i915 driver that uses PM core fields Changes since v1: - updated commit message of patch 1 - Added patches 2 & 3 to move runtime_pm accounting on raw ns Thara Gopinath (1): PM/runtime:Replace jiffies based accouting with ktime based accounting Vincent Guittot (2): PM/pm_runtime: move autosuspend on hrtimer drm/i915: Move to new PM core fields drivers/base/power/runtime.c| 73 ++--- drivers/base/power/sysfs.c | 11 +-- drivers/gpu/drm/i915/i915_pmu.c | 12 +++ drivers/gpu/drm/i915/i915_pmu.h | 4 +-- include/linux/pm.h | 11 --- include/linux/pm_runtime.h | 6 ++-- 6 files changed, 64 insertions(+), 53 deletions(-) -- 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/3] drm/i915: Move to new PM core fields
With jiffies been replaced by raw ns in PM core accounting, 915 driver is
updated to use this new time infrastructure.
Signed-off-by: Vincent Guittot
---
drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d6c8f8f..cf6437d 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
*/
if (kdev->power.runtime_status == RPM_SUSPENDED) {
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
- i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
+ i915->pmu.suspended_time_last =
+ kdev->power.suspended_time;
- val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
- val += jiffies - kdev->power.accounting_timestamp;
+ val = kdev->power.suspended_time -
+ i915->pmu.suspended_time_last;
+ val += ktime_to_ns(ktime_get()) -
+ kdev->power.accounting_timestamp;
- val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 7f164ca..3dc2a30 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -95,9 +95,9 @@ struct i915_pmu {
*/
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
/**
-* @suspended_jiffies_last: Cached suspend time from PM core.
+* @suspended_time_last: Cached suspend time from PM core.
*/
- unsigned long suspended_jiffies_last;
+ u64 suspended_time_last;
/**
* @i915_attr: Memory block holding device attributes.
*/
--
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/2] drm: Add color management LUT validation helper (v2)
>-Original Message-
>From: Roper, Matthew D
>Sent: Friday, December 14, 2018 3:25 AM
>To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
>Cc: Roper, Matthew D ; Shankar, Uma
>; Sharma, Swati2 ; Brian
>Starkey
>Subject: [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)
>
>Some hardware may place additional restrictions on the gamma/degamma
>curves described by our LUT properties. E.g., that a gamma curve never
>decreases or that the red/green/blue channels of a LUT's entries must be equal.
>Let's add a helper function that drivers can use to test that a
>userspace-provided
>LUT is valid and doesn't violate hardware requirements.
>
>v2:
> - Combine into a single helper that just takes a bitmask of the tests
> to apply. (Brian Starkey)
> - Add additional check (always performed) that LUT property blob size
> is always a multiple of the LUT entry size. (stolen from ARM driver)
Looks ok to me.
Reviewed-By: Uma Shankar
>Cc: Uma Shankar
>Cc: Swati Sharma
>Cc: Brian Starkey
>Signed-off-by: Matt Roper
>Reviewed-by(v1): Brian Starkey
>---
> drivers/gpu/drm/drm_color_mgmt.c | 64
>
> include/drm/drm_color_mgmt.h | 5
> 2 files changed, 69 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>b/drivers/gpu/drm/drm_color_mgmt.c
>index 07dcf47daafe..5c2a2d228412 100644
>--- a/drivers/gpu/drm/drm_color_mgmt.c
>+++ b/drivers/gpu/drm/drm_color_mgmt.c
>@@ -462,3 +462,67 @@ int drm_plane_create_color_properties(struct
>drm_plane *plane,
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_color_properties);
>+
>+/**
>+ * drm_color_lut_check - check validity of lookup table
>+ * @lut: property blob containing LUT to check
>+ * @tests: bitmask of tests to run
>+ *
>+ * Helper to check whether a userspace-provided lookup table is valid
>+and
>+ * satisfies additional hardware requirements. All table sizes should
>+be a
>+ * multiple of sizeof(struct drm_color_lut). Drivers pass a bitmask
>+indicating
>+ * which of the following additional tests should also be performed:
>+ *
>+ * "DRM_COLOR_LUT_EQUAL_CHANNELS":
>+ * Checks whether the entries of a LUT all have equal values for the red,
>+ * green, and blue channels. Intended for hardware that only accepts a
>+ * single value per LUT entry and assumes that value applies to all three
>+ * color components.
>+ *
>+ * "DRM_COLOR_LUT_INCREASING":
>+ * Checks whether the entries of a LUT are always flat or increasing
>+ * (never decreasing).
>+ *
>+ * Returns 0 on success, -EINVAL on failure.
>+ */
>+int drm_color_lut_check(struct drm_property_blob *lut,
>+ uint32_t tests)
>+{
>+ struct drm_color_lut *entry;
>+ int i;
>+
>+ if (!lut)
>+ return 0;
>+
>+ if (lut->length % sizeof(struct drm_color_lut)) {
>+ DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry
>size (%lu)\n",
>+lut->length, sizeof(struct drm_color_lut));
>+ return -EINVAL;
>+ }
>+
>+ if (!tests)
>+ return 0;
>+
>+ entry = lut->data;
>+ for (i = 0; i < drm_color_lut_size(lut); i++) {
>+ if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
>+ if (entry[i].red != entry[i].blue ||
>+ entry[i].red != entry[i].green) {
>+ DRM_DEBUG_KMS("All LUT entries must have
>equal r/g/b\n");
>+ return -EINVAL;
>+ }
>+ }
>+
>+ if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
>+ if (entry[i].red < entry[i - 1].red ||
>+ entry[i].green < entry[i - 1].green ||
>+ entry[i].blue < entry[i - 1].blue) {
>+ DRM_DEBUG_KMS("LUT entries must never
>decrease.\n");
>+ return -EINVAL;
>+ }
>+ }
>+ }
>+
>+ return 0;
>+}
>+EXPORT_SYMBOL(drm_color_lut_check);
>diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>index 90ef9996d9a4..7de16f70bcc3 100644
>--- a/include/drm/drm_color_mgmt.h
>+++ b/include/drm/drm_color_mgmt.h
>@@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane
>*plane,
> u32 supported_ranges,
> enum drm_color_encoding
>default_encoding,
> enum drm_color_range default_range);
>+
>+#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
>+#define DRM_COLOR_LUT_INCREASING BIT(1)
>+int drm_color_lut_check(struct drm_property_blob *lut,
>+ uint32_t tests);
> #endif
>--
>2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Validate userspace-provided color management LUT's (v2)
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Matt Roper
>Sent: Friday, December 14, 2018 3:25 AM
>To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Sharma, Swati2
>
>Subject: [PATCH v2 2/2] drm/i915: Validate userspace-provided color
>management LUT's (v2)
>
>We currently program userspace-provided gamma and degamma LUT's into our
>hardware without really checking to see whether they satisfy our hardware's
>rules. We should try to catch tables that are invalid for our hardware early
>and
>reject the atomic transaction.
>
>All of our platforms that accept a degamma LUT expect that the entries in the
>LUT are always flat or increasing, never decreasing. Also, our GLK and ICL
>platforms only accept degamma tables with r=g=b entries; so we should also add
>the relevant checks for that in anticipation of degamma support landing for
>those
>platforms.
>
>v2:
> - Use new API (single check function with bitmask of tests to apply)
> - Call helper for our gamma table as well (with no additional tests
> specified) so that the table size will be validated.
Looks ok to me.
Reviewed-By: Uma Shankar
>Cc: Uma Shankar
>Cc: Swati Sharma
>Signed-off-by: Matt Roper
>---
> drivers/gpu/drm/i915/intel_color.c | 19 +++
> 1 file changed, 19 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_color.c
>b/drivers/gpu/drm/i915/intel_color.c
>index 37fd9ddf762e..5ad4459a5f3c 100644
>--- a/drivers/gpu/drm/i915/intel_color.c
>+++ b/drivers/gpu/drm/i915/intel_color.c
>@@ -609,10 +609,29 @@ int intel_color_check(struct intel_crtc_state
>*crtc_state) {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> size_t gamma_length, degamma_length;
>+ uint32_t tests = DRM_COLOR_LUT_INCREASING;
>
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
>+ /*
>+ * All of our platforms mandate that the degamma curve be
>+ * non-decreasing. Additionally, GLK and gen11 only accept a single
>+ * value for red, green, and blue in the degamma table. Make sure
>+ * userspace didn't try to pass us something we can't handle.
>+ *
>+ * We don't have any extra hardware constraints on the gamma table,
>+ * so we just test that it's a proper size multiple
>+ * (tablesize % entrysize == 0).
>+ */
>+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
>+ tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
>+
>+ if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
>+ return -EINVAL;
>+ if (drm_color_lut_check(crtc_state->base.gamma_lut, 0) != 0)
>+ return -EINVAL;
>+
> /*
>* We allow both degamma & gamma luts at the right size or
>* NULL.
>--
>2.14.4
>
>___
>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
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for PM/pm_runtime: move on hrtimer and nsec
== Series Details ==
Series: PM/pm_runtime: move on hrtimer and nsec
URL : https://patchwork.freedesktop.org/series/54059/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c435ac8f04a4 PM/pm_runtime: move autosuspend on hrtimer
-:142: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#142: FILE: drivers/base/power/runtime.c:523:
+ if (!(dev->power.timer_expires &&
+ dev->power.timer_expires <= expires)) {
-:153: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#153: FILE: drivers/base/power/runtime.c:533:
+
hrtimer_start_range_ns(&dev->power.suspend_timer,
+ ns_to_ktime(expires),
-:260: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#260: FILE: include/linux/pm_runtime.h:54:
+extern u64 pm_runtime_autosuspend_expiration(struct device *dev);
-:278: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#278: FILE: include/linux/pm_runtime.h:171:
+static inline u64 pm_runtime_autosuspend_expiration(
total: 0 errors, 0 warnings, 4 checks, 188 lines checked
62531c2b8c88 PM/runtime:Replace jiffies based accouting with ktime based
accounting
21ebcb40a07b drm/i915: Move to new PM core fields
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
wrote:
>
> With jiffies been replaced by raw ns in PM core accounting, 915 driver is
> updated to use this new time infrastructure.
>
> Signed-off-by: Vincent Guittot
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index d6c8f8f..cf6437d 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
> */
> if (kdev->power.runtime_status == RPM_SUSPENDED) {
> if
> (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> - i915->pmu.suspended_jiffies_last =
> -
> kdev->power.suspended_jiffies;
> + i915->pmu.suspended_time_last =
> + kdev->power.suspended_time;
>
Huh, so patch 2 introduces a complier error because of removing the
old fields. We can't have that.
Ideally the driver shouldn't touch these fields in the first place,
but because the fields are defined in a public header, there is always
a risk that they becomes abused. I would appreciate if we can change
the driver move away from using these fields and make that a patch
preceding patch 2.
> - val = kdev->power.suspended_jiffies -
> - i915->pmu.suspended_jiffies_last;
> - val += jiffies - kdev->power.accounting_timestamp;
> + val = kdev->power.suspended_time -
> + i915->pmu.suspended_time_last;
> + val += ktime_to_ns(ktime_get()) -
> + kdev->power.accounting_timestamp;
>
> - val = jiffies_to_nsecs(val);
> val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
>
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur =
> val;
> diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
> index 7f164ca..3dc2a30 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.h
> +++ b/drivers/gpu/drm/i915/i915_pmu.h
> @@ -95,9 +95,9 @@ struct i915_pmu {
> */
> struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
> /**
> -* @suspended_jiffies_last: Cached suspend time from PM core.
> +* @suspended_time_last: Cached suspend time from PM core.
> */
> - unsigned long suspended_jiffies_last;
> + u64 suspended_time_last;
> /**
> * @i915_attr: Memory block holding device attributes.
> */
> --
> 2.7.4
>
Kind regards
Uffe
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for PM/pm_runtime: move on hrtimer and nsec
== Series Details == Series: PM/pm_runtime: move on hrtimer and nsec URL : https://patchwork.freedesktop.org/series/54059/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: PM/pm_runtime: move autosuspend on hrtimer Okay! Commit: PM/runtime:Replace jiffies based accouting with ktime based accounting + ^ + ^ -drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void [noderef] **slot -drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void **slot -drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void **slot -drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void **slot -drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void [noderef] ** -drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void [noderef] ** -drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void [noderef] ** -drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void **slot -drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in argument 1 (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:758:45:expected void [noderef] **slot -drivers/gpu/drm/i915/gvt/gtt.c:758:45:got void **slot -drivers/gpu/drm/i915/gvt/gtt.c:758:45: warning: incorrect type in argument 1 (different address spaces) -drivers/gpu/drm/i915/gvt/mmio.c:282:23: warning: memcpy with byte count of 279040 -drivers/gpu/drm/i915/gvt/mmio.c:283:23: warning: memcpy with byte count of 279040 -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3548:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gpu_error.c:1043:21: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gpu_error.c:1043:21: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gpu_error.c:934:23: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gpu_error.c:934:23: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_perf.c:1422:15: warning: memset with byte count of 16777216 -drivers/gpu/drm/i915/i915_perf.c:1480:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_pmu.c:497:21: error: ‘struct dev_pm_info’ has no member named ‘suspended_jiffies’; did you mean ‘suspended_time’? +drivers/gpu/drm/i915/i915_pmu.c:497:62: error: no member 'suspended_jiffies' in struct dev_pm_info +drivers/gpu/drm/i915/i915_pmu.c:497:62: warning: unknown expression (8 46) +drivers/gpu/drm/i915/i915_pmu.c:499:22: error: ‘struct dev_pm_info’ has no member named ‘suspended_jiffies’; did you mean ‘suspended_time’? +drivers/gpu/drm/i915/i915_pmu.c:499:42: error: no member 'suspended_jiffies' in struct dev_pm_info +drivers/gpu/drm/i915/i915_pmu.c:499:42: warning: unknown expression (8 46) +drivers/gpu/drm/i915/i915_pmu.c:500:40: warning: unknown expression (8 46) +drivers/gpu/drm/i915/i915_pmu.c: In function ‘get_rc6’: -drivers/gpu/drm/i915/i915_vma.c:554:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_vma.c:554:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_vma.c:555:21: warning: expression using sizeof(void) -drivers/
[Intel-gfx] ✗ Fi.CI.BAT: failure for PM/pm_runtime: move on hrtimer and nsec
== Series Details ==
Series: PM/pm_runtime: move on hrtimer and nsec
URL : https://patchwork.freedesktop.org/series/54059/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5317 -> Patchwork_11097
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11097 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11097, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54059/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11097:
### IGT changes ###
Possible regressions
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11097 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-ilk-650: PASS -> DMESG-WARN [fdo#106387]
* igt@i915_selftest@live_sanitycheck:
- fi-gdg-551: PASS -> INCOMPLETE [fdo#108789] / [fdo#108799]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108789]: https://bugs.freedesktop.org/show_bug.cgi?id=108789
[fdo#108799]: https://bugs.freedesktop.org/show_bug.cgi?id=108799
Participating hosts (49 -> 47)
--
Additional (2): fi-icl-y fi-byt-j1900
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5317 -> Patchwork_11097
CI_DRM_5317: 10c50ecb5eaa0176514e610d0c8bfd13babf88e0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11097: 21ebcb40a07b6c5387a761e79635e9493139b161 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
21ebcb40a07b drm/i915: Move to new PM core fields
62531c2b8c88 PM/runtime:Replace jiffies based accouting with ktime based
accounting
c435ac8f04a4 PM/pm_runtime: move autosuspend on hrtimer
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11097/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Per context dynamic (sub)slice power-gating (rev8)
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev8)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5317_full -> Patchwork_11095_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11095_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11095_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11095_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_param@invalid-param-get:
- shard-skl: PASS -> FAIL
- shard-apl: PASS -> FAIL
- shard-iclb: PASS -> FAIL
- shard-glk: PASS -> FAIL
- shard-snb: PASS -> FAIL
- shard-hsw: PASS -> FAIL
- shard-kbl: PASS -> FAIL
Warnings
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-iclb: FAIL [fdo#108948] -> DMESG-FAIL
Known issues
Here are the changes found in Patchwork_11095_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-skl: NOTRUN -> FAIL [fdo#103158]
* igt@i915_suspend@debugfs-reader:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-iclb: PASS -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +3
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_draw_crc@draw-method-rgb565-blt-xtiled:
- shard-glk: PASS -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled:
- shard-skl: NOTRUN -> FAIL [fdo#103184]
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_flip@dpms-vs-vblank-race-interruptible:
- shard-kbl: PASS -> FAIL [fdo#103060]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-rgb565-draw-pwrite:
- shard-skl: NOTRUN -> FAIL [fdo#103167] +1
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-iclb: PASS -> FAIL [fdo#103166] +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_scaling@pipe-b-scaler-with-rotation:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724]
* igt@perf_pmu@rc6-runtime-pm:
- shard-kbl: PASS -> FAIL [fdo#105010]
* igt@pm_rpm@universal-planes:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#108654] / [fdo#108756]
* {igt@runner@aborted}:
- shard-iclb: NOTRUN -> FAIL [fdo#108654] / [fdo#108756]
Possible fixes
* igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
- shard-skl: FAIL [fdo#107815] / [fdo#108470] -> PASS
* igt@kms_color@pipe-a-ctm-max:
- shard-skl: FAIL [fdo#108147] -> PASS
* igt@kms_color@pipe-c-ctm-negative:
- shard-skl: FAIL [fdo#107361] -> PASS
* igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-skl: FAIL [fdo#103232] -> PASS +1
* igt@
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/backlight: Restore backlight on resume, v2.
== Series Details ==
Series: series starting with [1/4] drm/i915/backlight: Restore backlight on
resume, v2.
URL : https://patchwork.freedesktop.org/series/54052/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5317_full -> Patchwork_11096_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11096_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11096_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11096_full:
### IGT changes ###
Possible regressions
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- shard-iclb: PASS -> DMESG-WARN +2
- shard-skl: PASS -> DMESG-WARN +2
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: PASS -> DMESG-WARN
* {igt@runner@aborted}:
- shard-kbl: NOTRUN -> FAIL
- shard-skl: NOTRUN -> ( 3 FAIL )
- shard-iclb: NOTRUN -> ( 3 FAIL ) [fdo#108924]
Known issues
Here are the changes found in Patchwork_11096_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_cpu_reloc@full:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108248]
* igt@gem_eio@in-flight-internal-1us:
- shard-apl: PASS -> FAIL [fdo#105957]
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-skl: NOTRUN -> FAIL [fdo#103158]
* igt@i915_selftest@live_hangcheck:
- shard-iclb: PASS -> INCOMPLETE [fdo#108315]
* igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]
* igt@i915_suspend@shrink:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#108784]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-skl: NOTRUN -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-iclb: PASS -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +3
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105683] / [fdo#108040]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-move:
- shard-iclb: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* igt@kms_plane@pixel-format-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +2
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_plane_scaling@pipe-b-scaler-with-rotation:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +4
* igt@perf_pmu@rc6-runtime-pm:
- shard-kbl: PASS -> FAIL [fdo#105010]
* igt@pm_rpm@system-suspend-execbuf:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107807]
Possible fixes
* igt@kms_busy@extended-pageflip-hang-newfb-render-b:
- shard-
Re: [Intel-gfx] [WIP PATCH 13/15] drm/dp_mst: Start tracking per-port VCPI allocations
On Thu, Dec 13, 2018 at 08:25:42PM -0500, Lyude Paul wrote: > There has been a TODO waiting for quite a long time in > drm_dp_mst_topology.c: > > /* We cannot rely on port->vcpi.num_slots to update >* topology_state->avail_slots as the port may not exist if the parent >* branch device was unplugged. This should be fixed by tracking >* per-port slot allocation in drm_dp_mst_topology_state instead of >* depending on the caller to tell us how many slots to release. >*/ > > That's not the only reason we should fix this: forcing the driver to > track the VCPI allocations throughout a state's atomic check is > error prone, because it means that extra care has to be taken with the > order that drm_dp_atomic_find_vcpi_slots() and > drm_dp_atomic_release_vcpi_slots() are called in in order to ensure > idempotency. Currently the only driver actually using these helpers, > i915, doesn't even do this correctly: multiple ->best_encoder() checks > with i915's current implementation would not be idempotent and would > over-allocate VCPI slots, something I learned trying to implement > fallback retraining in MST. > > So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots() > and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for > each port. This allows us to ensure idempotency without having to rely > on the driver as much. Additionally: the driver doesn't need to do any > kind of VCPI slot tracking anymore if it doesn't need it for it's own > internal state. > > Additionally; this adds a new drm_dp_mst_atomic_check() helper which > must be used by atomic drivers to perform validity checks for the new > VCPI allocations incurred by a state. > > Also: update the documentation and make it more obvious that these > /must/ be called by /all/ atomic drivers supporting MST. > > Changes since v6: > - Keep a kref to all of the ports we have allocations on. This required >a good bit of changing to when we call drm_dp_find_vcpi_slots(), >mainly that we need to ensure that we only redo VCPI allocations on >actual mode or CRTC changes, not crtc_state->active changes. >Additionally, we no longer take the registration of the DRM connector >for each port into account because so long as we have a kref to the >port in the new or previous atomic state, the connector will stay >registered. > - Use the small changes to drm_dp_put_port() to add even more error >checking to make misusage of the helpers more obvious. I added this >after having to chase down various use-after-free conditions that >started popping up from the new helpers so no one else has to >troubleshoot that. > - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC() > - Update documentation again, note that find/release() should both not be >called on the same port in a single atomic check phase (but multiple >calls to one or the other is OK) > > Changes since v4: > - Don't skip the atomic checks for VCPI allocations if no new VCPI >allocations happen in a state. This makes the next change I'm about >to list here a lot easier to implement. > - Don't ignore VCPI allocations on destroyed ports, instead ensure that >when ports are destroyed and still have VCPI allocations in the >topology state, the only state changes allowed are releasing said >ports' VCPI. This prevents a state with a mix of VCPI allocations >from destroyed ports, and allocations from valid ports. > > Changes since v3: > - Don't release VCPI allocations in the topology state immediately in >drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip >over them in drm_dp_mst_duplicate_state(). This makes it so >drm_dp_atomic_release_vcpi_slots() is still idempotent while also >throwing warnings if the driver messes up it's book keeping and tries >to release VCPI slots on a port that doesn't have any pre-existing >VCPI allocation - danvet > - Change mst_state/state in some debugging messages to "mst state" > > Changes since v2: > - Use kmemdup() for duplicating MST state - danvet > - Move port validation out of duplicate state callback - danvet > - Handle looping through MST topology states in >drm_dp_mst_atomic_check() so the driver doesn't have to do it > - Fix documentation in drm_dp_atomic_find_vcpi_slots() > - Move the atomic check for each individual topology state into it's >own function, reduces indenting > - Don't consider "stale" MST ports when calculating the bandwidth >requirements. This is needed because originally we relied on the >state duplication functions to prune any stale ports from the new >state, which would prevent us from incorrectly considering their >bandwidth requirements alongside legitimate new payloads. > - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet > - Annotate atomic VCPI and atomic check functions with __must_
[Intel-gfx] [PATCH] drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
From: Clint Taylor Program PORT_TX_DW7 to the value specified in the DDI Buffer section of the BSPEC. BSEPC: 21257 Cc: Madhav Chauhan Cc: Jani Nikula Cc: Imre Deak Signed-off-by: Clint Taylor --- drivers/gpu/drm/i915/icl_dsi.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c index 4dd793b..f57aa0d 100644 --- a/drivers/gpu/drm/i915/icl_dsi.c +++ b/drivers/gpu/drm/i915/icl_dsi.c @@ -236,6 +236,16 @@ static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder) tmp |= RCOMP_SCALAR(0x98); I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp); + tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port)); + tmp &= ~(N_SCALAR_MASK); + tmp |= N_SCALAR(0x7f); + I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp); + + tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port)); + tmp &= ~(N_SCALAR_MASK); + tmp |= N_SCALAR(0x7f); + I915_WRITE(ICL_PORT_TX_DW7_AUX(port), tmp); + tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port)); tmp &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK | CURSOR_COEFF_MASK); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
== Series Details ==
Series: drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
URL : https://patchwork.freedesktop.org/series/54069/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/icl_dsi.o
In file included from drivers/gpu/drm/i915/intel_drv.h:33:0,
from drivers/gpu/drm/i915/intel_dsi.h:30,
from drivers/gpu/drm/i915/icl_dsi.c:30:
drivers/gpu/drm/i915/icl_dsi.c: In function ‘dsi_program_swing_and_deemphasis’:
drivers/gpu/drm/i915/icl_dsi.c:239:19: error: implicit declaration of function
‘ICL_PORT_TX_DW7_LN0’; did you mean ‘ICL_PORT_TX_DW4_LN0’?
[-Werror=implicit-function-declaration]
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:70: note: in definition of macro
‘I915_READ’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^~~
drivers/gpu/drm/i915/i915_drv.h:3438:69: error: incompatible type for argument
2 of ‘dev_priv->uncore.funcs.mmio_readl’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:69: note: expected ‘i915_reg_t {aka struct
}’ but argument is of type ‘int’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/icl_dsi.c:242:14: error: implicit declaration of function
‘ICL_PORT_TX_DW7_GRP’; did you mean ‘ICL_PORT_TX_DW5_GRP’?
[-Werror=implicit-function-declaration]
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^
drivers/gpu/drm/i915/i915_drv.h:3439:76: note: in definition of macro
‘I915_WRITE’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^~~
drivers/gpu/drm/i915/i915_drv.h:3439:75: error: incompatible type for argument
2 of ‘dev_priv->uncore.funcs.mmio_writel’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro ‘I915_WRITE’
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^~
drivers/gpu/drm/i915/i915_drv.h:3439:75: note: expected ‘i915_reg_t {aka struct
}’ but argument is of type ‘int’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro ‘I915_WRITE’
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^~
drivers/gpu/drm/i915/icl_dsi.c:244:19: error: implicit declaration of function
‘ICL_PORT_TX_DW7_AUX’; did you mean ‘ICL_PORT_TX_DW2_AUX’?
[-Werror=implicit-function-declaration]
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:70: note: in definition of macro
‘I915_READ’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^~~
drivers/gpu/drm/i915/i915_drv.h:3438:69: error: incompatible type for argument
2 of ‘dev_priv->uncore.funcs.mmio_readl’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:244:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:69: note: expected ‘i915_reg_t {aka struct
}’ but argument is of type ‘int’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:244:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3439:75: error: incompatible type for argument
2 of ‘dev_priv->uncore.funcs.mmio_writel’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
drivers/gpu/drm/i915/icl_dsi.c:247:3: note: in expansion of macro ‘I915_WRITE’
I915_WRITE(ICL_PORT_TX_DW7_AUX(port), tmp);
^
[Intel-gfx] [PATCH v7 1/4] drm/i915: Simplify MOCS table definition
Make the defines for LE and L3 caching options to contain the shifts and
remove the zeros from the tables as shifting zeros always result in
zero.
Starting from Ice Lake the MOCS table is defined in the spec and
contains all entries. So to simplify checking the table with the values
set in code, the value is now part of the macro name. This allows to
still give the most used option and sensible name, but also to easily
cross check the table from the spec for gen >= 11.
By removing the zeros we avoid maintaining a huge table since the one
from spec contains many more entries. The new table for Ice Lake will
be added by other patches, this only reformats the table.
While at it also fix the indentation.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 80 +++
1 file changed, 29 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index e976c5ce5479..4fbfb335bc4e 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -36,8 +36,8 @@ struct drm_i915_mocs_table {
};
/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
-#define LE_CACHEABILITY(value) ((value) << 0)
-#define LE_TGT_CACHE(value)((value) << 2)
+#define _LE_CACHEABILITY(value)((value) << 0)
+#define _LE_TGT_CACHE(value) ((value) << 2)
#define LE_LRUM(value) ((value) << 4)
#define LE_AOM(value) ((value) << 6)
#define LE_RSC(value) ((value) << 7)
@@ -48,28 +48,28 @@ struct drm_i915_mocs_table {
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
#define L3_SCC(value) ((value) << 1)
-#define L3_CACHEABILITY(value) ((value) << 4)
+#define _L3_CACHEABILITY(value)((value) << 4)
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are reserved. */
/* (e)LLC caching options */
-#define LE_PAGETABLE 0
-#define LE_UC 1
-#define LE_WT 2
-#define LE_WB 3
-
-/* L3 caching options */
-#define L3_DIRECT 0
-#define L3_UC 1
-#define L3_RESERVED2
-#define L3_WB 3
+#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
+#define LE_1_UC_LE_CACHEABILITY(1)
+#define LE_2_WT_LE_CACHEABILITY(2)
+#define LE_3_WB_LE_CACHEABILITY(3)
/* Target cache */
-#define LE_TC_PAGETABLE0
-#define LE_TC_LLC 1
-#define LE_TC_LLC_ELLC 2
-#define LE_TC_LLC_ELLC_ALT 3
+#define LE_TC_0_PAGETABLE _LE_TGT_CACHE(0)
+#define LE_TC_1_LLC_LE_TGT_CACHE(1)
+#define LE_TC_2_LLC_ELLC _LE_TGT_CACHE(2)
+#define LE_TC_3_LLC_ELLC_ALT _LE_TGT_CACHE(3)
+
+/* L3 caching options */
+#define L3_0_DIRECT_L3_CACHEABILITY(0)
+#define L3_1_UC_L3_CACHEABILITY(1)
+#define L3_2_RESERVED _L3_CACHEABILITY(2)
+#define L3_3_WB_L3_CACHEABILITY(3)
/*
* MOCS tables
@@ -99,31 +99,21 @@ struct drm_i915_mocs_table {
static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
[I915_MOCS_UNCACHED] = {
/* 0x0009 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
+ .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
/* 0x0010 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ .l3cc_value =L3_1_UC,
},
[I915_MOCS_PTE] = {
/* 0x0038 */
- .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
+ .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
/* 0x0030 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value =L3_3_WB,
},
[I915_MOCS_CACHED] = {
/* 0x003b */
- .control_value = LE_CACHEABILITY(LE_WB) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
+ .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
/* 0x0030 */
- .l3cc_value = L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value = L3_3_WB,
},
};
@@ -131,33 +121,21 @@ static const struct drm_i915_mocs_entry
skylake_mocs_table[] = {
static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
[I915_MOCS_UNCACHED] = {
/* 0x
[Intel-gfx] [PATCH v7 0/4] Define MOCS table for Icelake
This reworks v6 of the series (https://patchwork.freedesktop.org/series/51258/) to handle the comments there and some more of my own. I added 2 patches in which most of the changes were done and then rebased those commits to adhere to the new table format. All values for the table were cross checked with spec as well. Lucas De Marchi (2): drm/i915: Simplify MOCS table definition drm/i915: cache number of MOCS entries Tomasz Lis (2): drm/i915/skl: Rework MOCS tables to keep common part in a define drm/i915/icl: Define MOCS table for Icelake drivers/gpu/drm/i915/intel_mocs.c | 299 -- 1 file changed, 202 insertions(+), 97 deletions(-) -- 2.20.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 4/4] drm/i915: cache number of MOCS entries
Instead of checking the gen number every time we need to know the max
number of entries, just save it into the table struct so we don't need
extra branches throughout the code.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index dfc4edea020f..22c5f576a3c2 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -32,6 +32,7 @@ struct drm_i915_mocs_entry {
struct drm_i915_mocs_table {
u32 size;
+ u32 n_entries;
const struct drm_i915_mocs_entry *table;
};
@@ -56,9 +57,6 @@ struct drm_i915_mocs_table {
#define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are reserved. */
#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
-#define NUM_MOCS_ENTRIES(i915) \
- (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES : GEN11_NUM_MOCS_ENTRIES)
-
/* (e)LLC caching options */
#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
#define LE_1_UC_LE_CACHEABILITY(1)
@@ -283,14 +281,17 @@ static bool get_mocs_settings(struct drm_i915_private
*dev_priv,
if (IS_ICELAKE(dev_priv)) {
table->size = ARRAY_SIZE(icelake_mocs_table);
+ table->n_entries = GEN11_NUM_MOCS_ENTRIES;
table->table = icelake_mocs_table;
result = true;
} else if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
table->size = ARRAY_SIZE(skylake_mocs_table);
+ table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = skylake_mocs_table;
result = true;
} else if (IS_GEN9_LP(dev_priv)) {
table->size = ARRAY_SIZE(broxton_mocs_table);
+ table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = broxton_mocs_table;
result = true;
} else {
@@ -348,8 +349,6 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
if (!get_mocs_settings(dev_priv, &table))
return;
- GEM_BUG_ON(table.size > NUM_MOCS_ENTRIES(dev_priv));
-
for (index = 0; index < table.size; index++)
I915_WRITE(mocs_register(engine->id, index),
table.table[index].control_value);
@@ -362,7 +361,7 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
* Entry 0 in the table is uncached - so we are just writing
* that value to all the used entries.
*/
- for (; index < NUM_MOCS_ENTRIES(dev_priv); index++)
+ for (; index < table.n_entries; index++)
I915_WRITE(mocs_register(engine->id, index),
table.table[0].control_value);
}
@@ -380,19 +379,18 @@ void intel_mocs_init_engine(struct intel_engine_cs
*engine)
static int emit_mocs_control_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table)
{
- struct drm_i915_private *i915 = rq->i915;
enum intel_engine_id engine = rq->engine->id;
unsigned int index;
u32 *cs;
- if (WARN_ON(table->size > NUM_MOCS_ENTRIES(i915)))
+ if (GEM_WARN_ON(table->size > table->n_entries))
return -ENODEV;
- cs = intel_ring_begin(rq, 2 + 2 * NUM_MOCS_ENTRIES(i915));
+ cs = intel_ring_begin(rq, 2 + 2 * table->n_entries);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(NUM_MOCS_ENTRIES(i915));
+ *cs++ = MI_LOAD_REGISTER_IMM(table->n_entries);
for (index = 0; index < table->size; index++) {
*cs++ = i915_mmio_reg_offset(mocs_register(engine, index));
@@ -407,7 +405,7 @@ static int emit_mocs_control_table(struct i915_request *rq,
* Entry 0 in the table is uncached - so we are just writing
* that value to all the used entries.
*/
- for (; index < NUM_MOCS_ENTRIES(i915); index++) {
+ for (; index < table->n_entries; index++) {
*cs++ = i915_mmio_reg_offset(mocs_register(engine, index));
*cs++ = table->table[0].control_value;
}
@@ -440,18 +438,17 @@ static inline u32 l3cc_combine(const struct
drm_i915_mocs_table *table,
static int emit_mocs_l3cc_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table)
{
- struct drm_i915_private *i915 = rq->i915;
unsigned int i;
u32 *cs;
- if (WARN_ON(table->size > NUM_MOCS_ENTRIES(i915)))
+ if (GEM_WARN_ON(table->size > table->n_entries))
return -ENODEV;
- cs = intel_ring_begin(rq, 2 + NUM_MOCS_ENTRIES(i915));
+ cs = intel_ring_begin(rq, 2 + table->n_entries);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *
[Intel-gfx] [PATCH v7 2/4] drm/i915/skl: Rework MOCS tables to keep common part in a define
From: Tomasz Lis
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
to MOCS_ENTRIES. (Joonas)
v3 (Lucas):
- Fix indentation
- Rebase on rework done by additional patch
- Remove define for or-ing flags as it made the table more complex by
requiring zeroed values to be passed
- Do not embed comma in the macro, so to treat that just as another
item and please source code formatting tools
Signed-off-by: Tomasz Lis
Suggested-by: Lucas De Marchi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 57 ++-
1 file changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 4fbfb335bc4e..577633cefb8a 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -96,46 +96,39 @@ struct drm_i915_mocs_table {
* may only be updated incrementally by adding entries at the
* end.
*/
+
+#define GEN9_MOCS_ENTRIES \
+ [I915_MOCS_UNCACHED] = { \
+ /* 0x0009 */ \
+ .control_value = LE_1_UC | LE_TC_2_LLC_ELLC, \
+ /* 0x0010 */ \
+ .l3cc_value = L3_1_UC, \
+ }, \
+ [I915_MOCS_PTE] = { \
+ /* 0x0038 */ \
+ .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC |
LE_LRUM(3), \
+ /* 0x0030 */ \
+ .l3cc_value = L3_3_WB, \
+ }
+
static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
- /* 0x0010 */
- .l3cc_value =L3_1_UC,
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value =L3_3_WB,
- },
+ GEN9_MOCS_ENTRIES,
[I915_MOCS_CACHED] = {
- /* 0x003b */
- .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
+ /* 0x003b */
+ .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
+ /* 0x0030 */
+ .l3cc_value = L3_3_WB,
},
};
/* NOTE: the LE_TGT_CACHE is not used on Broxton */
static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
- /* 0x0010 */
- .l3cc_value = L3_1_UC,
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
- },
+ GEN9_MOCS_ENTRIES,
[I915_MOCS_CACHED] = {
- /* 0x0039 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
+ /* 0x0039 */
+ .control_value = LE_1_UC | LE_TC_2_LLC_ELLC | LE_LRUM(3),
+ /* 0x0030 */
+ .l3cc_value = L3_3_WB,
},
};
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/4] drm/i915/icl: Define MOCS table for Icelake
From: Tomasz Lis
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Meaning of each entry is now explained in bspec, and user mode clients
are expected to know what each entry means. The 3 entries used for previous
platforms are still compatible with their legacy definitions, but that is
not guaranteed to be true for future platforms.
v2: Fixed SCC values, improved commit comment (Daniele)
v3: Improved MOCS table comment (Daniele)
v4: Moved new entries below gen9 ones. Put common entries into
definition to be used in multiple arrays. (Lucas)
v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas)
v6: Removed definitions of reserved entries. (Michal)
Increased limit of entries sent to the hardware on gen11+.
v7: Simplify table as done for previou gens (Lucas)
BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis
Reviewed-by: Daniele Ceraolo Spurio
Reviewed-by: Lucas De Marchi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 187 ++
1 file changed, 162 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 577633cefb8a..dfc4edea020f 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
#define LE_SCC(value) ((value) << 8)
#define LE_PFM(value) ((value) << 11)
#define LE_SCF(value) ((value) << 14)
+#define LE_COS(value) ((value) << 15)
+#define LE_SSE(value) ((value) << 17)
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
@@ -52,6 +54,10 @@ struct drm_i915_mocs_table {
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are reserved. */
+#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
+
+#define NUM_MOCS_ENTRIES(i915) \
+ (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES : GEN11_NUM_MOCS_ENTRIES)
/* (e)LLC caching options */
#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
@@ -80,21 +86,21 @@ struct drm_i915_mocs_table {
* LNCFCMOCS0 - LNCFCMOCS32 registers.
*
* These tables are intended to be kept reasonably consistent across
- * platforms. However some of the fields are not applicable to all of
- * them.
+ * HW platforms, and for ICL+, be identical across OSes. To achieve
+ * that, for Icelake and above, list of entries is published as part
+ * of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be implicitly initialized to the strictest caching
- * configuration (uncached) to guarantee forwards compatibility with
- * userspace programs written against more recent kernels providing
- * additional MOCS entries.
+ * userspace is concerned and shouldn't be relied upon.
+ *
+ * The last two entries are reserved by the hardware. For ICL+ they
+ * should be initialized according to bspec and never used, for older
+ * platforms they should never be written to.
*
- * NOTE: These tables MUST start with being uncached and the length
- * MUST be less than 63 as the last two registers are reserved
- * by the hardware. These tables are part of the kernel ABI and
- * may only be updated incrementally by adding entries at the
- * end.
+ * NOTE: These tables are part of bspec and defined as part of hardware
+ * interface for ICL+. For older platforms, they are part of kernel
+ * ABI. It is expected that existing entries will remain constant
+ * and the tables will only be updated by adding new entries.
*/
#define GEN9_MOCS_ENTRIES \
@@ -132,6 +138,132 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
},
};
+#define GEN11_MOCS_ENTRIES \
+ [0] = { \
+ /* Base - Uncached (Deprecated) */ \
+ .control_value = LE_1_UC | LE_TC_1_LLC, \
+ .l3cc_value = L3_1_UC \
+ }, \
+ [1] = { \
+ /* Base - L3 + LeCC:PAT (Deprecated) */ \
+ .control_value = LE_0_PAGETABLE | LE_TC_1_LLC, \
+ .l3cc_value = L3_3_WB \
+ }, \
+ [2] = { \
+ /* Base - L3 + LLC */ \
+ .control_value = LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
+ .l3cc_value = L3_3_WB \
+ }, \
+ [3] = { \
+ /* Base - Uncached */ \
+ .control_value = LE_1_UC | LE_TC_1_LLC, \
+ .l3cc_value = L3_1_UC \
+ }, \
+ [4] = { \
+ /* Base - L3 */ \
+
Re: [Intel-gfx] [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)
On Fri, Dec 14, 2018 at 09:43:08AM +, Alexandru-Cosmin Gheorghe wrote:
...
> > +int drm_color_lut_check(struct drm_property_blob *lut,
> > +uint32_t tests)
> > +{
> > + struct drm_color_lut *entry;
> > + int i;
> > +
> > + if (!lut)
> > + return 0;
> > +
> > + if (lut->length % sizeof(struct drm_color_lut)) {
> > + DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry
> > size (%lu)\n",
> > + lut->length, sizeof(struct drm_color_lut));
> > + return -EINVAL;
> > + }
> > +
>
> Isn't this already covered by drm_atomic_replace_property_blob_from_id ?
> Other than that feel free to add:
>
> Reviewed-by: Alexandru Gheorghe
Ah, you're right. I thought there was a test somewhere but couldn't
find where we did it when I looked earlier. I'll drop this extra test;
thanks for pointing that out.
Matt
>
> > + if (!tests)
> > + return 0;
> > +
> > + entry = lut->data;
> > + for (i = 0; i < drm_color_lut_size(lut); i++) {
> > + if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
> > + if (entry[i].red != entry[i].blue ||
> > + entry[i].red != entry[i].green) {
> > + DRM_DEBUG_KMS("All LUT entries must have equal
> > r/g/b\n");
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
> > + if (entry[i].red < entry[i - 1].red ||
> > + entry[i].green < entry[i - 1].green ||
> > + entry[i].blue < entry[i - 1].blue) {
> > + DRM_DEBUG_KMS("LUT entries must never
> > decrease.\n");
> > + return -EINVAL;
> > + }
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_color_lut_check);
> > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > index 90ef9996d9a4..7de16f70bcc3 100644
> > --- a/include/drm/drm_color_mgmt.h
> > +++ b/include/drm/drm_color_mgmt.h
> > @@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane
> > *plane,
> > u32 supported_ranges,
> > enum drm_color_encoding default_encoding,
> > enum drm_color_range default_range);
> > +
> > +#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
> > +#define DRM_COLOR_LUT_INCREASING BIT(1)
> > +int drm_color_lut_check(struct drm_property_blob *lut,
> > + uint32_t tests);
> > #endif
> > --
> > 2.14.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Cheers,
> Alex G
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/bios: Parse the VBT TypeC and Thunderbolt port flags
This is needed by the next patch to determine if a DDI TypeC port is
physically wired to a legacy DP or legacy HDMI connector or if the port
is wired to a USB-C/Thunderbolt connector.
Cc: Jani Nikula
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_bios.c | 11 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e70707e79386..fd3cccaac89e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -935,6 +935,8 @@ struct ddi_vbt_port_info {
uint8_t supports_hdmi:1;
uint8_t supports_dp:1;
uint8_t supports_edp:1;
+ uint8_t supports_typec_usb:1;
+ uint8_t supports_tbt:1;
uint8_t alternate_aux_channel;
uint8_t alternate_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 6d3e0260d49c..e59a5af45e94 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1386,8 +1386,15 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
info->supports_dp = is_dp;
info->supports_edp = is_edp;
- DRM_DEBUG_KMS("Port %c VBT info: DP:%d HDMI:%d DVI:%d EDP:%d CRT:%d\n",
- port_name(port), is_dp, is_hdmi, is_dvi, is_edp, is_crt);
+ if (bdb_version >= 195)
+ info->supports_typec_usb = child->dp_usb_type_c;
+
+ if (bdb_version >= 209)
+ info->supports_tbt = child->tbt;
+
+ DRM_DEBUG_KMS("Port %c VBT info: DP:%d HDMI:%d DVI:%d EDP:%d CRT:%d
TCUSB:%d TBT:%d\n",
+ port_name(port), is_dp, is_hdmi, is_dvi, is_edp, is_crt,
+ info->supports_typec_usb, info->supports_tbt);
if (is_edp && is_dvi)
DRM_DEBUG_KMS("Internal DP port %c is TMDS compatible\n",
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/icl: Add a debug print for TypeC port disconnection
It's useful to see at which point a TypeC port gets disconnected, so add
a debug print for it.
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e94faa0a42eb..082594bb65a7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5066,28 +5066,38 @@ static bool icl_combo_port_connected(struct
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
}
+static const char *tc_type_name(enum tc_port_type type)
+{
+ static const char *names[] = {
+ [TC_PORT_UNKNOWN] = "unknown",
+ [TC_PORT_LEGACY] = "legacy",
+ [TC_PORT_TYPEC] = "typec",
+ [TC_PORT_TBT] = "tbt",
+ };
+
+ if (WARN_ON(type >= ARRAY_SIZE(names)))
+ type = TC_PORT_UNKNOWN;
+
+ return names[type];
+}
+
static void icl_update_tc_port_type(struct drm_i915_private *dev_priv,
struct intel_digital_port *intel_dig_port,
bool is_legacy, bool is_typec, bool is_tbt)
{
enum port port = intel_dig_port->base.port;
enum tc_port_type old_type = intel_dig_port->tc_type;
- const char *type_str;
WARN_ON(is_legacy + is_typec + is_tbt != 1);
- if (is_legacy) {
+ if (is_legacy)
intel_dig_port->tc_type = TC_PORT_LEGACY;
- type_str = "legacy";
- } else if (is_typec) {
+ else if (is_typec)
intel_dig_port->tc_type = TC_PORT_TYPEC;
- type_str = "typec";
- } else if (is_tbt) {
+ else if (is_tbt)
intel_dig_port->tc_type = TC_PORT_TBT;
- type_str = "tbt";
- } else {
+ else
return;
- }
/* Types are not supposed to be changed at runtime. */
WARN_ON(old_type != TC_PORT_UNKNOWN &&
@@ -5095,7 +5105,7 @@ static void icl_update_tc_port_type(struct
drm_i915_private *dev_priv,
if (old_type != intel_dig_port->tc_type)
DRM_DEBUG_KMS("Port %c has TC type %s\n", port_name(port),
- type_str);
+ tc_type_name(intel_dig_port->tc_type));
}
static void icl_tc_phy_disconnect(struct drm_i915_private *dev_priv,
@@ -5187,6 +5197,10 @@ static void icl_tc_phy_disconnect(struct
drm_i915_private *dev_priv,
I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
}
+ DRM_DEBUG_KMS("Port %c TC type %s disconnected\n",
+ port_name(dig_port->base.port),
+ tc_type_name(dig_port->tc_type));
+
dig_port->tc_type = TC_PORT_UNKNOWN;
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/icl: Fix HPD handling for TypeC legacy ports
Atm HPD disconnect events on TypeC ports will break things, since we'll
switch the TypeC mode (between legacy and disconnected modes as well as
among USB DP alternate, Thunderbolt alternate and disconnected modes) on
the fly from the HPD disconnect interrupt work while the port may be
still active.
Even if the port happens to be not active during the disconnect we'd
still have a problem during a subsequent modeset or AUX transfer that
could happen regardless of the port's connected state. For instance the
system resume display mode restore code and userspace could perform a
modeset on the port or userspace could start an AUX transfer even if the
port is in disconnected state.
To fix this keep TypeC legacy ports in legacy mode whenever we're not
suspended. This mode is a static configuration as opposed to the
Thunderbolt and USB DP alternate modes between which we can switch
dynamically.
We determine if a TypeC port is legacy (wired to a legacy HDMI or a
legacy DP connector) via the VBT DDI port specific USB-TypeC and
Thunderbolt flags. If both these flags are cleared then the port is
configured for legacy mode.
On such legacy ports we'll run the TypeC PHY connect sequence explicitly
during driver loading and system resume (vs. running the sequence during
HPD processing). The connect will succeed even if the display is not
connected to begin with (or disappears during the suspended state) since
for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED
flag is always set (as opposed to the USB DP alternate mode where it
gets set only when a display is connected).
Correspondingly run the TypeC PHY disconnect sequence during system
suspend and driver unloading. For the unloading case I had to split
up intel_dp_encoder_destroy() to be able to have the 1. flush any
pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and
kfree on the encoder object.
For now run the PHY disconnect during suspend only for TypeC legacy
ports. We will need to disconnect even in USB DP alternate mode in the
future, but atm we don't have a way to reconnect the port in this mode
during resume if the display disappears while being suspended. So for
now punt on this case.
Note that we do not disconnect the port during runtime suspend; in
legacy mode there are no shared HW resources (PHY lanes) with other HW
blocks (USB), so no need to release / reacquire these resources as with
USB DP alternate mode. The only reason to disconnect legacy ports during
system suspend is that the PORT_TX_DFLEXDPPMS /
DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
connected again during system resume. We'll also have to turn the check
for this flag into a poll, after figuring out what's the proper timeout
value for it.
v2:
- Remove the redundant special casing of legacy mode when doing a
disconnect in icl_tc_port_connected(). It's guaranteed already that we
won't disconnect legacy ports in that function.
- Add a note about the new intel_ddi_encoder_destroy() hook.
- Reword the commit message after switching to the VBT based detection.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 63 +++-
drivers/gpu/drm/i915/intel_dp.c | 21 +-
drivers/gpu/drm/i915/intel_drv.h | 5 +++-
3 files changed, 73 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f3e1d6a0b7dd..295d75c50688 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3901,9 +3901,50 @@ static bool intel_ddi_compute_config(struct
intel_encoder *encoder,
}
+static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_dp_encoder_suspend(encoder);
+
+ /*
+* TODO: disconnect also from USB DP alternate mode once we have a
+* way to handle the modeset restore in that mode during resume
+* even if the sink has disappeared while being suspended.
+*/
+ if (dig_port->tc_legacy_port)
+ icl_tc_phy_disconnect(i915, dig_port);
+}
+
+static void intel_ddi_encoder_reset(struct drm_encoder *drm_encoder)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(drm_encoder);
+ struct drm_i915_private *i915 = to_i915(drm_encoder->dev);
+
+ if (intel_port_is_tc(i915, dig_port->base.port))
+ intel_digital_port_connected(&dig_port->base);
+
+ intel_dp_encoder_reset(drm_encoder);
+}
+
+static void intel_ddi_encoder_destroy(struct drm_encoder *encoder)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(enco
[Intel-gfx] [PATCH v2 0/4] drm/i915/icl: Fix TypeC Legacy HPD handling
This is v2 of [1]. The changes in v2: - Use VBT for detecting legacy ports. There was already a flag for this in VBT, I just missed it. Thanks for Siva for pointing that out. With that we have a detection that works all the time for DP ports as well. - Remove a redundant special casing of legacy ports during disconnection in patch 3. [1] https://patchwork.freedesktop.org/series/54017/ Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: José Roberto de Souza Cc: Rodrigo Vivi Cc: Sivakumar Thulasimani Imre Deak (4): drm/i915/icl: Add a debug print for TypeC port disconnection drm/i915/bios: Parse the VBT TypeC and Thunderbolt port flags drm/i915/icl: Fix HPD handling for TypeC legacy ports drm/i915/icl: Add fallback detection method for TypeC legacy ports drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_bios.c | 11 +-- drivers/gpu/drm/i915/intel_ddi.c | 63 ++- drivers/gpu/drm/i915/intel_dp.c | 61 ++--- drivers/gpu/drm/i915/intel_drv.h | 5 +++- 5 files changed, 114 insertions(+), 28 deletions(-) -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add fallback detection method for TypeC legacy ports
Add a fallback detection method for TypeC legacy ports in case the VBT port information used to detect normally such ports is incorrect. For the fallback method we use the TypeC legacy mode specific HPD interrupt flag which should only be raised for a legacy port. WARN if the VBT port info is incorrect. In a case where we'd detect the port in a contradicting way both as a legacy and also as a USB DP and/or TBT alternate port treat the port as legacy (by also emitting a WARN from icl_update_tc_port_type). v2: - Repurpose the detection as a fallback method instead of using it only for the DP legacy case. By now we should normally use VBT to detect DP legacy ports as well. Suggested-by: Ville Syrjälä Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: José Roberto de Souza Cc: Rodrigo Vivi Signed-off-by: Imre Deak Reviewed-by: Rodrigo Vivi (v1) --- drivers/gpu/drm/i915/intel_dp.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index b2a3012478ca..d00af92cd089 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5220,8 +5220,14 @@ static bool icl_tc_port_connected(struct drm_i915_private *dev_priv, bool is_legacy, is_typec, is_tbt; u32 dpsp; - is_legacy = intel_dig_port->tc_legacy_port || - I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port); + /* +* WARN if we got a legacy port HPD, but VBT didn't mark the port as +* legacy. Treat the port as legacy from now on. +*/ + if (WARN_ON(!intel_dig_port->tc_legacy_port && + I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port))) + intel_dig_port->tc_legacy_port = true; + is_legacy = intel_dig_port->tc_legacy_port; /* * The spec says we shouldn't be using the ISR bits for detecting -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm: Add color management LUT validation helper (v3)
Some hardware may place additional restrictions on the gamma/degamma
curves described by our LUT properties. E.g., that a gamma curve never
decreases or that the red/green/blue channels of a LUT's entries must be
equal. Let's add a helper function that drivers can use to test that a
userspace-provided LUT is valid and doesn't violate hardware
requirements.
v2:
- Combine into a single helper that just takes a bitmask of the tests
to apply. (Brian Starkey)
- Add additional check (always performed) that LUT property blob size
is always a multiple of the LUT entry size. (stolen from ARM driver)
v3:
- Drop the LUT size check again since
drm_atomic_replace_property_blob_from_id() already covers this for
us. (Alexandru Gheorghe)
Cc: Uma Shankar
Cc: Swati Sharma
Cc: Brian Starkey
Signed-off-by: Matt Roper
Reviewed-by(v1): Brian Starkey
Reviewed-by: Alexandru Gheorghe
Reviewed-By: Uma Shankar
---
drivers/gpu/drm/drm_color_mgmt.c | 54
include/drm/drm_color_mgmt.h | 5
2 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 07dcf47daafe..684afcace58f 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -462,3 +462,57 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_properties);
+
+/**
+ * drm_color_lut_check - check validity of lookup table
+ * @lut: property blob containing LUT to check
+ * @tests: bitmask of tests to run
+ *
+ * Helper to check whether a userspace-provided lookup table is valid and
+ * satisfies hardware requirements. Drivers pass a bitmask indicating which of
+ * the following tests should be performed:
+ *
+ * "DRM_COLOR_LUT_EQUAL_CHANNELS":
+ * Checks whether the entries of a LUT all have equal values for the red,
+ * green, and blue channels. Intended for hardware that only accepts a
+ * single value per LUT entry and assumes that value applies to all three
+ * color components.
+ *
+ * "DRM_COLOR_LUT_INCREASING":
+ * Checks whether the entries of a LUT are always flat or increasing
+ * (never decreasing).
+ *
+ * Returns 0 on success, -EINVAL on failure.
+ */
+int drm_color_lut_check(struct drm_property_blob *lut,
+ uint32_t tests)
+{
+ struct drm_color_lut *entry;
+ int i;
+
+ if (!lut || !tests)
+ return 0;
+
+ entry = lut->data;
+ for (i = 0; i < drm_color_lut_size(lut); i++) {
+ if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
+ if (entry[i].red != entry[i].blue ||
+ entry[i].red != entry[i].green) {
+ DRM_DEBUG_KMS("All LUT entries must have equal
r/g/b\n");
+ return -EINVAL;
+ }
+ }
+
+ if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
+ if (entry[i].red < entry[i - 1].red ||
+ entry[i].green < entry[i - 1].green ||
+ entry[i].blue < entry[i - 1].blue) {
+ DRM_DEBUG_KMS("LUT entries must never
decrease.\n");
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_color_lut_check);
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 90ef9996d9a4..7de16f70bcc3 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
u32 supported_ranges,
enum drm_color_encoding default_encoding,
enum drm_color_range default_range);
+
+#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
+#define DRM_COLOR_LUT_INCREASING BIT(1)
+int drm_color_lut_check(struct drm_property_blob *lut,
+ uint32_t tests);
#endif
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915: Validate userspace-provided color management LUT's (v3)
We currently program userspace-provided gamma and degamma LUT's into our
hardware without really checking to see whether they satisfy our
hardware's rules. We should try to catch tables that are invalid for
our hardware early and reject the atomic transaction.
All of our platforms that accept a degamma LUT expect that the entries
in the LUT are always flat or increasing, never decreasing. Also, our
GLK and ICL platforms only accept degamma tables with r=g=b entries; so
we should also add the relevant checks for that in anticipation of
degamma support landing for those platforms.
v2:
- Use new API (single check function with bitmask of tests to apply)
- Call helper for our gamma table as well (with no additional tests
specified) so that the table size will be validated.
v3:
- Don't call on the gamma table since the LUT size is already tested at
property blob upload and we don't have any additional hardware
constraints for that LUT.
Cc: Uma Shankar
Cc: Swati Sharma
Signed-off-by: Matt Roper
Reviewed-By: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 37fd9ddf762e..6c5d030236b9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -609,10 +609,26 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
size_t gamma_length, degamma_length;
+ uint32_t tests = DRM_COLOR_LUT_INCREASING;
degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ /*
+* All of our platforms mandate that the degamma curve be
+* non-decreasing. Additionally, GLK and gen11 only accept a single
+* value for red, green, and blue in the degamma table. Make sure
+* userspace didn't try to pass us something we can't handle.
+*
+* We don't have any extra hardware constraints on the gamma table,
+* so no need to explicitly check it.
+*/
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
+
+ if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
+ return -EINVAL;
+
/*
* We allow both degamma & gamma luts at the right size or
* NULL.
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/2] Add gamma/degamma LUT validation helper
Previous version of the series was here: https://lists.freedesktop.org/archives/dri-devel/2018-December/200505.html The only change in this version is dropping the extra LUT size test I added in v2; Alexandru pointed out that that already gets tested when a new atomic blob is uploaded. Matt Roper (2): drm: Add color management LUT validation helper (v3) drm/i915: Validate userspace-provided color management LUT's (v3) drivers/gpu/drm/drm_color_mgmt.c | 54 ++ drivers/gpu/drm/i915/intel_color.c | 16 +++ include/drm/drm_color_mgmt.h | 5 3 files changed, 75 insertions(+) -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Define MOCS table for Icelake
== Series Details ==
Series: Define MOCS table for Icelake
URL : https://patchwork.freedesktop.org/series/54070/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5318 -> Patchwork_11099
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11099 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11099, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54070/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11099:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11099 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108622]
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* {igt@runner@aborted}:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622]
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (53 -> 45)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan
fi-ctg-p8600 fi-icl-u3 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5318 -> Patchwork_11099
CI_DRM_5318: 4ef95f23369b5408a57faa222c8c0f2bb8298de8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11099: 6b89fe176ee014b2f99d2681061bf1cb6e2b0b99 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6b89fe176ee0 drm/i915: cache number of MOCS entries
37abf4739ed3 drm/i915/icl: Define MOCS table for Icelake
ef18cd7d5a06 drm/i915/skl: Rework MOCS tables to keep common part in a define
4ec5ac2ffa38 drm/i915: Simplify MOCS table definition
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11099/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Fix TypeC legacy HPD handling (rev2)
== Series Details ==
Series: drm/i915/icl: Fix TypeC legacy HPD handling (rev2)
URL : https://patchwork.freedesktop.org/series/54017/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
39a8e2bef8b8 drm/i915/icl: Add a debug print for TypeC port disconnection
-:29: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should
probably be static const char * const
#29: FILE: drivers/gpu/drm/i915/intel_dp.c:5071:
+ static const char *names[] = {
total: 0 errors, 1 warnings, 0 checks, 65 lines checked
4038ff7e5289 drm/i915/bios: Parse the VBT TypeC and Thunderbolt port flags
-:43: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 15)
#43: FILE: drivers/gpu/drm/i915/intel_bios.c:1389:
+ if (bdb_version >= 195)
+ info->supports_typec_usb = child->dp_usb_type_c;
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
073e19935f67 drm/i915/icl: Fix HPD handling for TypeC legacy ports
-:270: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool
bitfields as unsigned int or u<8|16|32>
#270: FILE: drivers/gpu/drm/i915/intel_drv.h:1237:
+ bool tc_legacy_port:1;
total: 0 errors, 1 warnings, 0 checks, 188 lines checked
4b9db3b474f7 drm/i915/icl: Add fallback detection method for TypeC legacy ports
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/icl: Fix TypeC legacy HPD handling (rev2)
== Series Details == Series: drm/i915/icl: Fix TypeC legacy HPD handling (rev2) URL : https://patchwork.freedesktop.org/series/54017/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/icl: Add a debug print for TypeC port disconnection Okay! Commit: drm/i915/bios: Parse the VBT TypeC and Thunderbolt port flags -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) Commit: drm/i915/icl: Fix HPD handling for TypeC legacy ports Okay! Commit: drm/i915/icl: Add fallback detection method for TypeC legacy ports Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt: add timeline test cases v2
On 2018-12-11 5:37 a.m., Chunming Zhou wrote:
> v2: adapt to new transfer ioctl
>
> Signed-off-by: Chunming Zhou
+igt-dev
I think intel-gfx still works for IGT development but most of the IGT work
happens on igt-...@lists.freedesktop.org now.
Harry
> ---
> include/drm-uapi/drm.h | 33 ++
> lib/igt_syncobj.c| 206
> lib/igt_syncobj.h| 19 +
> tests/meson.build|1 +
> tests/syncobj_timeline.c | 1032 ++
> 5 files changed, 1291 insertions(+)
> create mode 100644 tests/syncobj_timeline.c
>
> diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> index 85c685a2..dcd245d9 100644
> --- a/include/drm-uapi/drm.h
> +++ b/include/drm-uapi/drm.h
> @@ -731,6 +731,8 @@ struct drm_syncobj_handle {
>
> #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
> #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> +/* wait for time point to become available */
> +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2)
> struct drm_syncobj_wait {
> __u64 handles;
> /* absolute timeout */
> @@ -741,11 +743,38 @@ struct drm_syncobj_wait {
> __u32 pad;
> };
>
> +struct drm_syncobj_timeline_wait {
> +__u64 handles;
> +/* wait on specific timeline point for every handles*/
> +__u64 points;
> +/* absolute timeout */
> +__s64 timeout_nsec;
> +__u32 count_handles;
> +__u32 flags;
> +__u32 first_signaled; /* only valid when not waiting all */
> +__u32 pad;
> +};
> +
> struct drm_syncobj_array {
> __u64 handles;
> __u32 count_handles;
> __u32 pad;
> };
> +struct drm_syncobj_timeline_array {
> + __u64 handles;
> + __u64 points;
> + __u32 count_handles;
> + __u32 pad;
> +};
> +
> +struct drm_syncobj_transfer {
> +__u32 src_handle;
> +__u32 dst_handle;
> +__u64 src_point;
> +__u64 dst_point;
> +__u32 flags;
> +__u32 pad;
> +};
>
> /* Query current scanout sequence number */
> struct drm_crtc_get_sequence {
> @@ -902,6 +931,10 @@ extern "C" {
> #define DRM_IOCTL_MODE_LIST_LESSEES DRM_IOWR(0xC7, struct
> drm_mode_list_lessees)
> #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
> drm_mode_get_lease)
> #define DRM_IOCTL_MODE_REVOKE_LEASE DRM_IOWR(0xC9, struct
> drm_mode_revoke_lease)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
> drm_syncobj_timeline_wait)
> +#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_SYNCOBJ_TRANSFERDRM_IOWR(0xCC, struct
> drm_syncobj_transfer)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct
> drm_syncobj_timeline_array)
>
> /**
> * Device specific ioctls should only be in their respective headers
> diff --git a/lib/igt_syncobj.c b/lib/igt_syncobj.c
> index d9114ca8..efa2adc4 100644
> --- a/lib/igt_syncobj.c
> +++ b/lib/igt_syncobj.c
> @@ -286,3 +286,209 @@ syncobj_signal(int fd, uint32_t *handles, uint32_t
> count)
> {
> igt_assert_eq(__syncobj_signal(fd, handles, count), 0);
> }
> +
> +static int
> +__syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points,
> uint32_t count)
> +{
> + struct drm_syncobj_timeline_array array = { 0 };
> + int err = 0;
> +
> + array.handles = to_user_pointer(handles);
> + array.points = to_user_pointer(points);
> + array.count_handles = count;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, &array))
> + err = -errno;
> + return err;
> +}
> +
> +/**
> + * syncobj_signal:
> + * @fd: The DRM file descriptor.
> + * @handles: Array of syncobj handles to signal
> + * @points: List of point of handles to signal.
> + * @count: Count of syncobj handles.
> + *
> + * Signal a set of syncobjs.
> + */
> +void
> +syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points,
> uint32_t count)
> +{
> + igt_assert_eq(__syncobj_timeline_signal(fd, handles, points, count), 0);
> +}
> +int
> +__syncobj_timeline_wait_ioctl(int fd, struct drm_syncobj_timeline_wait *args)
> +{
> + int err = 0;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, args))
> + err = -errno;
> + return err;
> +}
> +static int
> +__syncobj_timeline_wait(int fd, uint32_t *handles, uint64_t *points,
> + unsigned num_handles,
> + int64_t timeout_nsec, unsigned flags,
> + uint32_t *first_signaled)
> +{
> + struct drm_syncobj_timeline_wait args;
> + int ret;
> +
> + args.handles = to_user_pointer(handles);
> + args.points = (uint64_t)to_user_pointer(points);
> + args.timeout_nsec = timeout_nsec;
> + args.count_handles = num_handles;
> + args.flags = flags;
> + args.first_signaled = 0;
> + args.pad = 0;
> +
> + ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, &args);
> + if (ret < 0)
> + return -err
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
Oops, failure caused by ICL_PORT_TX_DW7 not being defined yet. Still
waiting on r-b for a patch that includes the DW7 definition.
-Clint
On 12/14/18 10:15, Patchwork wrote:
== Series Details ==
Series: drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
URL : https://patchwork.freedesktop.org/series/54069/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/icl_dsi.o
In file included from drivers/gpu/drm/i915/intel_drv.h:33:0,
from drivers/gpu/drm/i915/intel_dsi.h:30,
from drivers/gpu/drm/i915/icl_dsi.c:30:
drivers/gpu/drm/i915/icl_dsi.c: In function ‘dsi_program_swing_and_deemphasis’:
drivers/gpu/drm/i915/icl_dsi.c:239:19: error: implicit declaration of function
‘ICL_PORT_TX_DW7_LN0’; did you mean ‘ICL_PORT_TX_DW4_LN0’?
[-Werror=implicit-function-declaration]
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:70: note: in definition of macro
‘I915_READ’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^~~
drivers/gpu/drm/i915/i915_drv.h:3438:69: error: incompatible type for argument 2
of ‘dev_priv->uncore.funcs.mmio_readl’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:69: note: expected ‘i915_reg_t {aka struct
}’ but argument is of type ‘int’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/icl_dsi.c:242:14: error: implicit declaration of function
‘ICL_PORT_TX_DW7_GRP’; did you mean ‘ICL_PORT_TX_DW5_GRP’?
[-Werror=implicit-function-declaration]
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^
drivers/gpu/drm/i915/i915_drv.h:3439:76: note: in definition of macro
‘I915_WRITE’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^~~
drivers/gpu/drm/i915/i915_drv.h:3439:75: error: incompatible type for argument 2
of ‘dev_priv->uncore.funcs.mmio_writel’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro ‘I915_WRITE’
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^~
drivers/gpu/drm/i915/i915_drv.h:3439:75: note: expected ‘i915_reg_t {aka struct
}’ but argument is of type ‘int’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro ‘I915_WRITE’
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^~
drivers/gpu/drm/i915/icl_dsi.c:244:19: error: implicit declaration of function
‘ICL_PORT_TX_DW7_AUX’; did you mean ‘ICL_PORT_TX_DW2_AUX’?
[-Werror=implicit-function-declaration]
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:70: note: in definition of macro
‘I915_READ’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^~~
drivers/gpu/drm/i915/i915_drv.h:3438:69: error: incompatible type for argument 2
of ‘dev_priv->uncore.funcs.mmio_readl’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:244:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3438:69: note: expected ‘i915_reg_t {aka struct
}’ but argument is of type ‘int’
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
drivers/gpu/drm/i915/icl_dsi.c:244:9: note: in expansion of macro ‘I915_READ’
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3439:75: error: incompatible type for argument 2
of ‘dev_priv->uncore.funcs.mmio_writel’
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix TypeC legacy HPD handling (rev2)
== Series Details == Series: drm/i915/icl: Fix TypeC legacy HPD handling (rev2) URL : https://patchwork.freedesktop.org/series/54017/ State : success == Summary == CI Bug Log - changes from CI_DRM_5318 -> Patchwork_11100 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11100 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11100, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54017/revisions/2/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11100: ### IGT changes ### Warnings * igt@pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: SKIP -> PASS Known issues Here are the changes found in Patchwork_11100 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569] - fi-icl-u2: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] Possible fixes * igt@kms_chamelium@common-hpd-after-suspend: - fi-icl-u2: DMESG-FAIL [fdo#103375] / [fdo#107732] / [fdo#108070] / [fdo#108924] -> PASS * igt@kms_flip@basic-flip-vs-dpms: - fi-icl-u3: DMESG-WARN [fdo#108924] / [fdo#109044] -> PASS * igt@pm_rpm@basic-rte: - fi-bsw-kefka: FAIL -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 [fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924 [fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044 Participating hosts (53 -> 46) -- Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-bdw-samus Build changes - * Linux: CI_DRM_5318 -> Patchwork_11100 CI_DRM_5318: 4ef95f23369b5408a57faa222c8c0f2bb8298de8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11100: 4b9db3b474f751f0a624206dbf88ea911a54d6ce @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4b9db3b474f7 drm/i915/icl: Add fallback detection method for TypeC legacy ports 073e19935f67 drm/i915/icl: Fix HPD handling for TypeC legacy ports 4038ff7e5289 drm/i915/bios: Parse the VBT TypeC and Thunderbolt port flags 39a8e2bef8b8 drm/i915/icl: Add a debug print for TypeC port disconnection == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11100/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add gamma/degamma LUT validation helper (rev2)
== Series Details == Series: Add gamma/degamma LUT validation helper (rev2) URL : https://patchwork.freedesktop.org/series/54023/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6710b80676f0 drm: Add color management LUT validation helper (v3) -:30: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form #30: Reviewed-By: Uma Shankar total: 0 errors, 1 warnings, 0 checks, 66 lines checked ef446e6cd4b7 drm/i915: Validate userspace-provided color management LUT's (v3) -:31: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form #31: Reviewed-By: Uma Shankar total: 0 errors, 1 warnings, 0 checks, 26 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add gamma/degamma LUT validation helper (rev2)
== Series Details ==
Series: Add gamma/degamma LUT validation helper (rev2)
URL : https://patchwork.freedesktop.org/series/54023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5318 -> Patchwork_11101
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11101 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11101, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54023/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11101:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11101 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bsw-n3050: PASS -> DMESG-FAIL [fdo#108656]
* {igt@runner@aborted}:
- fi-bsw-n3050: NOTRUN -> FAIL [fdo#108656]
Possible fixes
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
Participating hosts (53 -> 45)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-j1900
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5318 -> Patchwork_11101
CI_DRM_5318: 4ef95f23369b5408a57faa222c8c0f2bb8298de8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11101: ef446e6cd4b712ef69df1f243b7d15bca3effdca @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ef446e6cd4b7 drm/i915: Validate userspace-provided color management LUT's (v3)
6710b80676f0 drm: Add color management LUT validation helper (v3)
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11101/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Define MOCS table for Icelake
== Series Details == Series: Define MOCS table for Icelake URL : https://patchwork.freedesktop.org/series/54070/ State : success == Summary == CI Bug Log - changes from CI_DRM_5318_full -> Patchwork_11099_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11099_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11099_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11099_full: ### IGT changes ### Warnings * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-snb: SKIP -> PASS +4 Known issues Here are the changes found in Patchwork_11099_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-c-ctm-negative: - shard-skl: PASS -> FAIL [fdo#107361] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@kms_draw_crc@draw-method-rgb565-render-ytiled: - shard-iclb: PASS -> WARN [fdo#108336] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +5 * igt@kms_lease@simple_lease: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +12 * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +1 * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_universal_plane@universal-plane-pipe-c-functional: - shard-iclb: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724] * igt@perf_pmu@rc6-runtime-pm: - shard-kbl: PASS -> FAIL [fdo#105010] * igt@pm_rpm@basic-rte: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] / [fdo#108990] Possible fixes * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +6 * igt@kms_draw_crc@draw-method-xrgb-blt-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-iclb: DMESG-FAIL [fdo#107724] -> PASS +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move: - shard-iclb: FAIL [fdo#103167] -> PASS +3 * igt@kms_frontbuffer_tracking@psr-rgb565-draw-pwrite: - shard-skl: FAIL [fdo#103167] -> PASS * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max: - shard-iclb: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +2 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: FAIL [fdo#103166] -> PASS - shard-apl: FAIL [fdo#103166] -> PASS +1 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-iclb: FAIL [fdo#103166] -> PASS * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-glk: DMESG-FAIL [fdo#105763] / [fdo#106538] -> PASS * igt@pm_rpm@modeset-lpsp-stress-no-wait: - shard-iclb: DMESG-WARN [fdo#108654] -> PASS * igt@pm_rpm@system-suspend-modeset: - shard-iclb: I
[Intel-gfx] [bug report] drm/i915: Pass around sg_table to get_pages/put_pages backend
[ This code is old, but it's pretty confusing so I decided to send the
email anyway. - dan ]
Hello Chris Wilson,
The patch 03ac84f1830e: "drm/i915: Pass around sg_table to
get_pages/put_pages backend" from Oct 28, 2016, leads to the
following static checker warning:
drivers/gpu/drm/i915/i915_gem_userptr.c:540
__i915_gem_userptr_get_pages_worker()
warn: passing zero to 'ERR_PTR'
drivers/gpu/drm/i915/i915_gem_userptr.c
507 ret = -ENOMEM;
^^
508 pinned = 0;
509
510 pvec = kvmalloc_array(npages, sizeof(struct page *),
GFP_KERNEL);
511 if (pvec != NULL) {
512 struct mm_struct *mm = obj->userptr.mm->mm;
513 unsigned int flags = 0;
514
515 if (!i915_gem_object_is_readonly(obj))
516 flags |= FOLL_WRITE;
517
518 ret = -EFAULT;
^
519 if (mmget_not_zero(mm)) {
520 down_read(&mm->mmap_sem);
521 while (pinned < npages) {
522 ret = get_user_pages_remote
^^^
ret can be negative or zero or positive.
523 (work->task, mm,
524 obj->userptr.ptr + pinned *
PAGE_SIZE,
525 npages - pinned,
526 flags,
527 pvec + pinned, NULL, NULL);
528 if (ret < 0)
529 break;
530
531 pinned += ret;
532 }
533 up_read(&mm->mmap_sem);
534 mmput(mm);
535 }
536 }
537
538 mutex_lock(&obj->mm.lock);
539 if (obj->userptr.work == &work->work) {
540 struct sg_table *pages = ERR_PTR(ret);
It looks to me like the static checker could right that "ret" might not
be a negative error code. Is that intentional?
541
542 if (pinned == npages) {
543 pages = __i915_gem_userptr_alloc_pages(obj,
pvec,
544 npages);
545 if (!IS_ERR(pages)) {
546 pinned = 0;
547 pages = NULL;
548 }
549 }
550
551 obj->userptr.work = ERR_CAST(pages);
552 if (IS_ERR(pages))
553 __i915_gem_userptr_set_active(obj, false);
554 }
555 mutex_unlock(&obj->mm.lock);
556
557 release_pages(pvec, pinned);
558 kvfree(pvec);
559
560 i915_gem_object_put(obj);
561 put_task_struct(work->task);
562 kfree(work);
563 }
regards,
dan carpenter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix TypeC legacy HPD handling (rev2)
== Series Details == Series: drm/i915/icl: Fix TypeC legacy HPD handling (rev2) URL : https://patchwork.freedesktop.org/series/54017/ State : success == Summary == CI Bug Log - changes from CI_DRM_5318_full -> Patchwork_11100_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11100_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11100_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11100_full: ### IGT changes ### Warnings * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-snb: SKIP -> PASS +3 Known issues Here are the changes found in Patchwork_11100_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] / [fdo#107139] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-glk: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +51 * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: - shard-glk: PASS -> FAIL [fdo#103184] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +4 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-cpu: - shard-glk: PASS -> FAIL [fdo#103167] +4 * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_rmfb@rmfb-ioctl: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@pm_rpm@i2c: - shard-iclb: PASS -> FAIL [fdo#104097] * igt@pm_rpm@modeset-non-lpsp-stress: - shard-skl: SKIP -> INCOMPLETE [fdo#107807] Possible fixes * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-snb: DMESG-WARN [fdo#107956] -> PASS * igt@kms_busy@extended-pageflip-hang-newfb-render-a: - shard-apl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-hsw: DMESG-WARN [fdo#107956] -> PASS - shard-skl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-skl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-256x85-random: - shard-glk: FAIL [fdo#103232] -> PASS * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +11 * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled: - shard-iclb: WARN [fdo#108336] -> PASS +2 * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite: - shard-glk: FAIL [fdo#103167] -> PASS +3 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-iclb: DMESG-FAIL [fdo#107724] -> PASS +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move: - shard-iclb: FAIL [fdo#103167] -> PASS +2 * igt@kms_frontbuffer_tracking@psr-rgb565-draw-pwrite: - shard-skl: FAIL [fdo#103167] -> PASS * igt@kms_plane@pixel-format-pipe-a-planes: - sh
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
On Fri, Dec 14, 2018 at 11:34:13AM -0800, Clint Taylor wrote:
>Oops, failure caused by ICL_PORT_TX_DW7 not being defined yet. Still
>waiting on r-b for a patch that includes the DW7 definition.
I believe it is easier to re-send both patches together. Specially
because apparently one justifies the other... Just preserve the authorship
and add your sign-off on the other patch and send as a series.
Thanks,
Rodrigo.
>
>-Clint
>
>On 12/14/18 10:15, Patchwork wrote:
>
> == Series Details ==
>
> Series: drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
> URL : [1]https://patchwork.freedesktop.org/series/54069/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
> DESCEND objtool
> CHK include/generated/compile.h
> CC [M] drivers/gpu/drm/i915/icl_dsi.o
> In file included from drivers/gpu/drm/i915/intel_drv.h:33:0,
> from drivers/gpu/drm/i915/intel_dsi.h:30,
> from drivers/gpu/drm/i915/icl_dsi.c:30:
> drivers/gpu/drm/i915/icl_dsi.c: In function
> ‘dsi_program_swing_and_deemphasis’:
> drivers/gpu/drm/i915/icl_dsi.c:239:19: error: implicit declaration of
> function ‘
> ICL_PORT_TX_DW7_LN0’; did you mean ‘ICL_PORT_TX_DW4_LN0’?
> [-Werror=implicit-func
> tion-declaration]
>tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
>^
> drivers/gpu/drm/i915/i915_drv.h:3438:70: note: in definition of macro
> ‘I915_READ
> ’
> #define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
> true
> )
> ^~~
> drivers/gpu/drm/i915/i915_drv.h:3438:69: error: incompatible type for
> argument 2
> of ‘dev_priv->uncore.funcs.mmio_readl’
> #define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
> true
> )
> ^
> drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro ‘I915_READ’
>tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
> ^
> drivers/gpu/drm/i915/i915_drv.h:3438:69: note: expected ‘i915_reg_t {aka
> struct
> }’ but argument is of type ‘int’
> #define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
> true
> )
> ^
> drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro ‘I915_READ’
>tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
> ^
> drivers/gpu/drm/i915/icl_dsi.c:242:14: error: implicit declaration of
> function ‘
> ICL_PORT_TX_DW7_GRP’; did you mean ‘ICL_PORT_TX_DW5_GRP’?
> [-Werror=implicit-func
> tion-declaration]
>I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
> ^
> drivers/gpu/drm/i915/i915_drv.h:3439:76: note: in definition of macro
> ‘I915_WRIT
> E’
> #define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
> (reg)
> , (val), true)
>
> ^~~
> drivers/gpu/drm/i915/i915_drv.h:3439:75: error: incompatible type for
> argument 2
> of ‘dev_priv->uncore.funcs.mmio_writel’
> #define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
> (reg)
> , (val), true)
>^
> drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro ‘I915_WRITE’
>I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
>^~
> drivers/gpu/drm/i915/i915_drv.h:3439:75: note: expected ‘i915_reg_t {aka
> struct
> }’ but argument is of type ‘int’
> #define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
> (reg)
> , (val), true)
>^
> drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro ‘I915_WRITE’
>I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
>^~
> drivers/gpu/drm/i915/icl_dsi.c:244:19: error: implicit declaration of
> function ‘
> ICL_PORT_TX_DW7_AUX’; did you mean ‘ICL_PORT_TX_DW2_AUX’?
> [-Werror=implicit-func
> tion-declaration]
>tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
>^
> drivers/gpu/drm/i915/i915_drv.h:3438:70: note: in definition of macro
> ‘I915_READ
> ’
> #define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
> true
> )
> ^~~
> drivers/gpu/drm/i915/i915_drv.h:3438:69: error: incompatible type for
> argument 2
> of ‘dev_priv->uncore.funcs.mmio_readl’
> #define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
> true
> )
> ^
> drivers/gpu/drm/i915/icl_dsi.c:244:9: note: in expansion of macro ‘I915_READ’
>tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
> ^
> drivers/gpu/drm/i915/i915_drv.h:3438:69: note: expected ‘i915_reg_t {aka
> struct
> }’ but argument
[Intel-gfx] ✓ Fi.CI.IGT: success for Add gamma/degamma LUT validation helper (rev2)
== Series Details == Series: Add gamma/degamma LUT validation helper (rev2) URL : https://patchwork.freedesktop.org/series/54023/ State : success == Summary == CI Bug Log - changes from CI_DRM_5318_full -> Patchwork_11101_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11101_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11101_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11101_full: ### IGT changes ### Warnings * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-snb: SKIP -> PASS +4 Known issues Here are the changes found in Patchwork_11101_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-b-gamma: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +29 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-glk: PASS -> FAIL [fdo#103232] +1 * igt@kms_draw_crc@draw-method-rgb565-render-ytiled: - shard-iclb: PASS -> WARN [fdo#108336] * igt@kms_flip@dpms-vs-vblank-race: - shard-skl: NOTRUN -> FAIL [fdo#103060] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: PASS -> DMESG-FAIL [fdo#107720] / [fdo#107724] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +5 * igt@kms_lease@simple_lease: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +12 * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: - shard-skl: PASS -> FAIL [fdo#107362] * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-glk: PASS -> FAIL [fdo#103166] +1 * igt@kms_universal_plane@universal-plane-pipe-b-functional: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_universal_plane@universal-plane-pipe-c-functional: - shard-iclb: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724] * igt@perf_pmu@rc6-runtime-pm: - shard-kbl: PASS -> FAIL [fdo#105010] * igt@pm_rpm@gem-mmap-gtt: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] +1 * igt@pm_rpm@i2c: - shard-iclb: PASS -> FAIL [fdo#104097] * igt@pm_rpm@pm-tiling: - shard-iclb: NOTRUN -> INCOMPLETE [fdo#107713] / [fdo#108840] * igt@pm_rpm@sysfs-read: - shard-skl: PASS -> INCOMPLETE [fdo#107807] Possible fixes * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-kbl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-skl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_cursor_crc@cursor-256x85-random: - sh
Re: [Intel-gfx] [PATCH 2/3] drm/i915/icl: Fix TypeC legacy HDMI HPD handling
On Fri, Dec 14, 2018 at 01:25:07AM +0200, Imre Deak wrote:
> On Thu, Dec 13, 2018 at 01:06:51PM -0800, Rodrigo Vivi wrote:
> > On Thu, Dec 13, 2018 at 09:48:49PM +0200, Imre Deak wrote:
> > > Atm HPD disconnect events on TypeC ports will break things, since we'll
> > > switch the TypeC mode (between Legacy and disconnected modes as well as
> > > among USB DP alternate, Thunderbolt alternate and disconnected modes) on
> > > the fly from the HPD disconnect interrupt work while the port may be
> > > still active.
> > >
> > > Even if the port happens to be not active during the disconnect we'd
> > > still have a problem during a subsequent modeset or AUX transfer that
> > > could happen regardless of the port's connected state. For instance the
> > > system resume display mode restore code and userspace could perform a
> > > modeset on the port or userspace could start an AUX transfer even if the
> > > port is in disconnected state.
> > >
> > > To fix this keep legacy TypeC ports in TypeC legacy mode whenever we're
> > > not suspended. The legacy mode is a static configuration as opposed to
> > > the Thunderbolt and USB DP alternate modes between which we can switch
> > > dynamically.
> > >
> > > We don't have yet an explicit way to detect TypeC legacy ports, but we
> > > can imply that at least in case of HDMI enabled ports, since HDMI can
> > > only be provided in legacy mode. So mark TypeC HDMI enabled ports as
> > > legacy and run the TypeC PHY connect sequence explicitly during driver
> > > loading and system resume. The connect will succeed even if the display
> > > is not connected to begin with (or disappears during the suspended
> > > state) since for legacy ports the PORT_TX_DFLEXDPPMS /
> > > DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB
> > > DP alternate mode where it gets set only when a display is connected).
> > >
> > > Correspondingly run the TypeC PHY disconnect sequence during system
> > > suspend and driver unloading, but disconnect during suspend only for
> > > legacy TypeC mode. We will need to disconnect even in USB DP alternate
> > > mode in the future, but atm we don't have a way to reconnect the port
> > > in this mode during resume if the display disappears while being
> > > suspended. So for now punt on this case.
> > >
> > > Note that we do not disconnect the port during runtime suspend; in
> > > legacy mode there are no shared HW resources (PHY lanes) with other HW
> > > blocks (USB), so no need to release / reacquire these resources as with
> > > USB DP alternate mode. The only reason to disconnect legacy ports during
> > > system suspend is that the PORT_TX_DFLEXDPPMS /
> > > DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
> > > connected again during system resume. We may also need to turn the check
> > > for this flag into a poll, depending on further tests and clarifications
> > > we are expecting from HW/FW people.
> > >
> > > If VBT says that the port provides only DP functionality then we can't
> > > assume that it's a legacy port as for HDMI (since it could as well be
> > > a TBT/DP Alt connector), so we'll solve HPD handling for the DP case
> > > with a different method in the next patch.
> > >
> > > Eventually - instead of the above method - we'll depend on an explicit
> > > detection method provided either via a VBT flag or a FW/HW register both
> > > for the HDMI and DP case.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
> > > Cc: Paulo Zanoni
> > > Cc: Ville Syrjälä
> > > Cc: José Roberto de Souza
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 54
> > > +---
> > > drivers/gpu/drm/i915/intel_dp.c | 29 ++---
> > > drivers/gpu/drm/i915/intel_drv.h | 5 +++-
> > > 3 files changed, 75 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index f3e1d6a0b7dd..2e47ffa1c95a 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3901,9 +3901,50 @@ static bool intel_ddi_compute_config(struct
> > > intel_encoder *encoder,
> > >
> > > }
> > >
> > > +static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> > > +{
> > > + struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > +
> > > + intel_dp_encoder_suspend(encoder);
> > > +
> > > + /*
> > > + * TODO: disconnect also from USB DP alternate mode once we have a
> > > + * way to handle the modeset restore in that mode during resume
> > > + * even if the sink has disappeared while being suspended.
> > > + */
> > > + if (dig_port->tc_legacy_port)
> > > + icl_tc_phy_disconnect(i915, dig_port);
> > > +}
> > > +
> >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/icl: Fix TypeC legacy HDMI HPD handling
On Fri, Dec 14, 2018 at 02:22:09PM -0800, Rodrigo Vivi wrote:
> On Fri, Dec 14, 2018 at 01:25:07AM +0200, Imre Deak wrote:
> > On Thu, Dec 13, 2018 at 01:06:51PM -0800, Rodrigo Vivi wrote:
> > > On Thu, Dec 13, 2018 at 09:48:49PM +0200, Imre Deak wrote:
> > > > Atm HPD disconnect events on TypeC ports will break things, since we'll
> > > > switch the TypeC mode (between Legacy and disconnected modes as well as
> > > > among USB DP alternate, Thunderbolt alternate and disconnected modes) on
> > > > the fly from the HPD disconnect interrupt work while the port may be
> > > > still active.
> > > >
> > > > Even if the port happens to be not active during the disconnect we'd
> > > > still have a problem during a subsequent modeset or AUX transfer that
> > > > could happen regardless of the port's connected state. For instance the
> > > > system resume display mode restore code and userspace could perform a
> > > > modeset on the port or userspace could start an AUX transfer even if the
> > > > port is in disconnected state.
> > > >
> > > > To fix this keep legacy TypeC ports in TypeC legacy mode whenever we're
> > > > not suspended. The legacy mode is a static configuration as opposed to
> > > > the Thunderbolt and USB DP alternate modes between which we can switch
> > > > dynamically.
> > > >
> > > > We don't have yet an explicit way to detect TypeC legacy ports, but we
> > > > can imply that at least in case of HDMI enabled ports, since HDMI can
> > > > only be provided in legacy mode. So mark TypeC HDMI enabled ports as
> > > > legacy and run the TypeC PHY connect sequence explicitly during driver
> > > > loading and system resume. The connect will succeed even if the display
> > > > is not connected to begin with (or disappears during the suspended
> > > > state) since for legacy ports the PORT_TX_DFLEXDPPMS /
> > > > DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB
> > > > DP alternate mode where it gets set only when a display is connected).
> > > >
> > > > Correspondingly run the TypeC PHY disconnect sequence during system
> > > > suspend and driver unloading, but disconnect during suspend only for
> > > > legacy TypeC mode. We will need to disconnect even in USB DP alternate
> > > > mode in the future, but atm we don't have a way to reconnect the port
> > > > in this mode during resume if the display disappears while being
> > > > suspended. So for now punt on this case.
> > > >
> > > > Note that we do not disconnect the port during runtime suspend; in
> > > > legacy mode there are no shared HW resources (PHY lanes) with other HW
> > > > blocks (USB), so no need to release / reacquire these resources as with
> > > > USB DP alternate mode. The only reason to disconnect legacy ports during
> > > > system suspend is that the PORT_TX_DFLEXDPPMS /
> > > > DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
> > > > connected again during system resume. We may also need to turn the check
> > > > for this flag into a poll, depending on further tests and clarifications
> > > > we are expecting from HW/FW people.
> > > >
> > > > If VBT says that the port provides only DP functionality then we can't
> > > > assume that it's a legacy port as for HDMI (since it could as well be
> > > > a TBT/DP Alt connector), so we'll solve HPD handling for the DP case
> > > > with a different method in the next patch.
> > > >
> > > > Eventually - instead of the above method - we'll depend on an explicit
> > > > detection method provided either via a VBT flag or a FW/HW register both
> > > > for the HDMI and DP case.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
> > > > Cc: Paulo Zanoni
> > > > Cc: Ville Syrjälä
> > > > Cc: José Roberto de Souza
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c | 54
> > > > +---
> > > > drivers/gpu/drm/i915/intel_dp.c | 29 ++---
> > > > drivers/gpu/drm/i915/intel_drv.h | 5 +++-
> > > > 3 files changed, 75 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index f3e1d6a0b7dd..2e47ffa1c95a 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -3901,9 +3901,50 @@ static bool intel_ddi_compute_config(struct
> > > > intel_encoder *encoder,
> > > >
> > > > }
> > > >
> > > > +static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> > > > +{
> > > > + struct intel_digital_port *dig_port =
> > > > enc_to_dig_port(&encoder->base);
> > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > +
> > > > + intel_dp_encoder_suspend(encoder);
> > > > +
> > > > + /*
> > > > +* TODO: disconnect also from USB DP alternate mod
[Intel-gfx] [PATCH] drm/i915/icl: restore WaEnableFloatBlendOptimization
From: talha nassar
Enables blend optimization for floating point RTs
This restores the workaround that was reverted in c358514ba8da
("Revert "drm/i915/icl: WaEnableFloatBlendOptimization"").
The revert was due to the register write seemingly not sticking,
but the HW team has confirmed that this is because the
register is WO and that the workaround is indeed required.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107338
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: talha nassar
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_workarounds.c | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0796526..5c43720 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2795,6 +2795,9 @@ enum i915_power_well_id {
#define GEN6_RCS_PWR_FSM _MMIO(0x22ac)
#define GEN9_RCS_FE_FSM2 _MMIO(0x22a4)
+#define GEN10_CACHE_MODE_SS_MMIO(0xe420)
+#define FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4)
+
/* Fuse readout registers for GT */
#define HSW_PAVP_FUSE1 _MMIO(0x911C)
#define HSW_F1_EU_DIS_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 7a86180..bc614f0 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -532,6 +532,10 @@ static void icl_ctx_workarounds_init(struct
intel_engine_cs *engine)
if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_A0))
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
+
+ /* WaEnableFloatBlendOptimization:icl */
+ WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS,
+ FLOAT_BLEND_OPTIMIZATION_ENABLE);
}
void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: Fix CNL macros for Voltage Swing programming
CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
Cc: Clint Taylor
Cc: Imre Deak
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0796526dc10f..db1332cd9dcd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1836,8 +1836,8 @@ enum i915_power_well_id {
#define _ICL_PORT_TX_DW_LN(dw, ln, port) (_ICL_COMBOPHY(port) + \
_ICL_PORT_TX_LN(ln) + 4 * (dw))
-#define CNL_PORT_TX_DW2_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(2, port))
-#define CNL_PORT_TX_DW2_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(2, port))
+#define CNL_PORT_TX_DW2_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(port, 2))
+#define CNL_PORT_TX_DW2_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(port, 2))
#define ICL_PORT_TX_DW2_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(2, port))
#define ICL_PORT_TX_DW2_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(2, port))
#define ICL_PORT_TX_DW2_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(2, 0, port))
@@ -1869,8 +1869,8 @@ enum i915_power_well_id {
#define CURSOR_COEFF(x) ((x) << 0)
#define CURSOR_COEFF_MASK(0x3F << 0)
-#define CNL_PORT_TX_DW5_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(5, port))
-#define CNL_PORT_TX_DW5_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(5, port))
+#define CNL_PORT_TX_DW5_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(port, 5))
+#define CNL_PORT_TX_DW5_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(port, 5))
#define ICL_PORT_TX_DW5_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(5, port))
#define ICL_PORT_TX_DW5_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(5, port))
#define ICL_PORT_TX_DW5_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(5, 0, port))
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: restore WaEnableFloatBlendOptimization
== Series Details ==
Series: drm/i915/icl: restore WaEnableFloatBlendOptimization
URL : https://patchwork.freedesktop.org/series/54091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7da6a989f1e7 drm/i915/icl: restore WaEnableFloatBlendOptimization
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c358514ba8da ("Revert
"drm/i915/icl: WaEnableFloatBlendOptimization"")'
#8:
This restores the workaround that was reverted in c358514ba8da
total: 1 errors, 0 warnings, 0 checks, 19 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: restore WaEnableFloatBlendOptimization
== Series Details ==
Series: drm/i915/icl: restore WaEnableFloatBlendOptimization
URL : https://patchwork.freedesktop.org/series/54091/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5320 -> Patchwork_11102
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11102 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11102, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54091/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11102:
### IGT changes ###
Possible regressions
* igt@gem_workarounds@basic-read:
- fi-icl-u3: PASS -> FAIL
- fi-icl-u2: PASS -> FAIL
* igt@i915_module_load@reload-with-fault-injection:
- fi-gdg-551: PASS -> INCOMPLETE
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: SKIP -> PASS +33
Known issues
Here are the changes found in Patchwork_11102 that come from known issues:
### IGT changes ###
Issues hit
* {igt@runner@aborted}:
- fi-gdg-551: NOTRUN -> FAIL [fdo#108926]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108926]: https://bugs.freedesktop.org/show_bug.cgi?id=108926
Participating hosts (54 -> 47)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5320 -> Patchwork_11102
CI_DRM_5320: 2abfab12278273a26679335d0c65980816c42206 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11102: 7da6a989f1e7d440d802da9c2d060413920678f4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7da6a989f1e7 drm/i915/icl: restore WaEnableFloatBlendOptimization
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11102/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Fix CNL macros for Voltage Swing programming
== Series Details == Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming URL : https://patchwork.freedesktop.org/series/54092/ State : success == Summary == CI Bug Log - changes from CI_DRM_5320 -> Patchwork_11103 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11103 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11103, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54092/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11103: ### IGT changes ### Warnings * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - fi-kbl-7567u: SKIP -> PASS +33 Known issues Here are the changes found in Patchwork_11103 that come from known issues: ### IGT changes ### Issues hit * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] Possible fixes * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 Participating hosts (54 -> 47) -- Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5320 -> Patchwork_11103 CI_DRM_5320: 2abfab12278273a26679335d0c65980816c42206 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11103: 1b05f6152b57fea4451bd79e91375d3cbf1ef968 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1b05f6152b57 drm/i915/cnl: Fix CNL macros for Voltage Swing programming == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11103/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 1/2] drm: Add colorspace connector property
Hi Uma, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.20-rc6 next-20181214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Uma-Shankar/drm-Add-colorspace-connector-property/20181212-114922 base: git://anongit.freedesktop.org/drm-intel for-linux-next reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info' kernel/rcu/tree.c:685: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf' include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array' include/linux/gpio/driver.h:375: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/iio/hw-c
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Fix CNL macros for Voltage Swing programming
== Series Details == Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming URL : https://patchwork.freedesktop.org/series/54092/ State : success == Summary == CI Bug Log - changes from CI_DRM_5320_full -> Patchwork_11103_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11103_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11103_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11103_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP -> PASS Known issues Here are the changes found in Patchwork_11103_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-internal-1us: - shard-glk: PASS -> FAIL [fdo#107799] * igt@gem_exec_schedule@pi-ringfull-vebox: - shard-iclb: NOTRUN -> FAIL [fdo#103158] * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-skl: NOTRUN -> INCOMPLETE [fdo#106887] * igt@gem_softpin@noreloc-s3: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +7 * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-apl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-glk: PASS -> DMESG-WARN [fdo#107956] - shard-apl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_cursor_crc@cursor-128x42-random: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled: - shard-iclb: PASS -> WARN [fdo#108336] * igt@kms_flip@2x-flip-vs-dpms: - shard-hsw: PASS -> DMESG-WARN [fdo#102614] * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: PASS -> FAIL [fdo#100368] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +6 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-iclb: NOTRUN -> FAIL [fdo#108948] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] * igt@pm_rpm@basic-pci-d3-state: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] * igt@pm_rpm@cursor: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@pm_rpm@pm-tiling: - shard-iclb: PASS -> DMESG-WARN [fdo#108654] * igt@pm_rps@reset: - shard-iclb: NOTRUN -> FAIL [fdo#102250] / [fdo#108059] Possible fixes * igt@gem_userptr_blits@readonly-unsync: - shard-iclb: TIMEOUT -> PASS * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-hsw: DMESG-WARN [fdo#107956] -> PASS * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: - shard-glk: FAIL [fdo#103184] -> PASS * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_flip@flip-vs-modeset-vs-hang: - shard-apl: INCOMPLETE [fdo#103927] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: FAIL [fdo#103167] -> PASS +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: - shard-iclb:
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Add PORT_TX_DW7 programming to DSI vswing sequence
Hi Clint,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20181214]
[cannot apply to v4.20-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/clinton-a-taylor-intel-com/drm-i915-dsi-Add-PORT_TX_DW7-programming-to-DSI-vswing-sequence/20181215-101421
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x013-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/i915/intel_drv.h:33:0,
from drivers/gpu/drm/i915/intel_dsi.h:30,
from drivers/gpu/drm/i915/icl_dsi.c:30:
drivers/gpu/drm/i915/icl_dsi.c: In function
'dsi_program_swing_and_deemphasis':
>> drivers/gpu/drm/i915/icl_dsi.c:239:19: error: implicit declaration of
>> function 'ICL_PORT_TX_DW7_LN0'; did you mean 'ICL_PORT_TX_DW4_LN0'?
>> [-Werror=implicit-function-declaration]
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/i915_drv.h:3452:70: note: in definition of macro
'I915_READ'
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^~~
>> drivers/gpu/drm/i915/i915_drv.h:3452:69: error: incompatible type for
>> argument 2 of 'dev_priv->uncore.funcs.mmio_readl'
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
>> drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro 'I915_READ'
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
drivers/gpu/drm/i915/i915_drv.h:3452:69: note: expected 'i915_reg_t {aka
struct }' but argument is of type 'int'
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^
>> drivers/gpu/drm/i915/icl_dsi.c:239:9: note: in expansion of macro 'I915_READ'
tmp = I915_READ(ICL_PORT_TX_DW7_LN0(port));
^
>> drivers/gpu/drm/i915/icl_dsi.c:242:14: error: implicit declaration of
>> function 'ICL_PORT_TX_DW7_GRP'; did you mean 'ICL_PORT_TX_DW5_GRP'?
>> [-Werror=implicit-function-declaration]
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^
drivers/gpu/drm/i915/i915_drv.h:3453:76: note: in definition of macro
'I915_WRITE'
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^~~
>> drivers/gpu/drm/i915/i915_drv.h:3453:75: error: incompatible type for
>> argument 2 of 'dev_priv->uncore.funcs.mmio_writel'
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
>> drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro
>> 'I915_WRITE'
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^~
drivers/gpu/drm/i915/i915_drv.h:3453:75: note: expected 'i915_reg_t {aka
struct }' but argument is of type 'int'
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv,
(reg), (val), true)
^
>> drivers/gpu/drm/i915/icl_dsi.c:242:3: note: in expansion of macro
>> 'I915_WRITE'
I915_WRITE(ICL_PORT_TX_DW7_GRP(port), tmp);
^~
>> drivers/gpu/drm/i915/icl_dsi.c:244:19: error: implicit declaration of
>> function 'ICL_PORT_TX_DW7_AUX'; did you mean 'ICL_PORT_TX_DW2_AUX'?
>> [-Werror=implicit-function-declaration]
tmp = I915_READ(ICL_PORT_TX_DW7_AUX(port));
^
drivers/gpu/drm/i915/i915_drv.h:3452:70: note: in definition of macro
'I915_READ'
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
^~~
>> drivers/gpu/drm/i915/i915_drv.h:3452:69: error: incompatible type for
>> argument 2 of 'dev_priv->uncore.funcs.mmio_readl'
#define I915_READ(reg) dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg),
true)
