[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #38 from Mathieu Belanger --- (In reply to Pierre-Eric Pelloux-Prayer from comment #33) > Created attachment 145323 [details] [review] > wip patch > > You can give a try to the attached kernel patch which hopefully could > prevent some sdma timeouts. > > I'm still testing it but the more testers the better :) So far so good. Your patch seam to have fixed the "random" crash That I was able to replicate when I was loading my 3 many tabs browsers and phpstorm in the same time and I can use my IDE without crashing too. Maybe I got really lucky too. But it's been more than a day without crash and without the nodma "fix" -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/20] drm: rcar-du: kms: Update CMM in atomic commit tail
Hi Jacopo,
On Fri, Jun 14, 2019 at 10:19:13AM +0200, Jacopo Mondi wrote:
> On Fri, Jun 07, 2019 at 03:06:33PM +0300, Laurent Pinchart wrote:
> > On Thu, Jun 06, 2019 at 04:22:20PM +0200, Jacopo Mondi wrote:
> >> Update CMM settings at in the atomic commit tail helper method.
> >>
> >> The CMM is updated with new gamma values provided to the driver
> >> in the GAMMA_LUT blob property.
> >>
> >> Signed-off-by: Jacopo Mondi
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 36 +++
> >> 1 file changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> index 5a910a04e1d9..29a2020a46b5 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> @@ -21,6 +21,7 @@
> >> #include
> >> #include
> >>
> >> +#include "rcar_cmm.h"
> >> #include "rcar_du_crtc.h"
> >> #include "rcar_du_drv.h"
> >> #include "rcar_du_encoder.h"
> >> @@ -367,6 +368,38 @@ rcar_du_fb_create(struct drm_device *dev, struct
> >> drm_file *file_priv,
> >> * Atomic Check and Update
> >> */
> >>
> >> +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> >> + struct drm_crtc_state *old_state)
> >> +{
> >> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> >> + struct rcar_cmm_config cmm_config = {};
> >> +
> >> + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> >> + return;
> >> +
> >> + if (!crtc->state->gamma_lut) {
> >> + cmm_config.lut.enable = false;
> >> + rcar_cmm_setup(rcrtc->cmm, _config);
> >> +
> >> + return;
> >> + }
> >> +
> >> + cmm_config.lut.enable = true;
> >> + cmm_config.lut.table = (struct drm_color_lut *)
> >> + crtc->state->gamma_lut->data;
> >> +
> >> + /* Set LUT table size to 0 if entries should not be updated. */
> >> + if (!old_state->gamma_lut ||
> >> + (old_state->gamma_lut->base.id !=
> >> + crtc->state->gamma_lut->base.id))
> >> + cmm_config.lut.size = crtc->state->gamma_lut->length
> >> + / sizeof(cmm_config.lut.table[0]);
> >
> > Do you need to call rcar_cmm_setup() at all in this case ?
>
> Do you mean in case the lut.size field is set to 0 ?
> I considered it useful when the CMM has to be re-enabled without
> updateing the LUT table entries? It is not required in your opinion?
You're right, I thought userspace couldn't do this, but it actually can.
> >> + else
> >> + cmm_config.lut.size = 0;
> >> +
> >> + rcar_cmm_setup(rcrtc->cmm, _config);
> >> +}
> >> +
> >> static int rcar_du_atomic_check(struct drm_device *dev,
> >>struct drm_atomic_state *state)
> >> {
> >> @@ -409,6 +442,9 @@ static void rcar_du_atomic_commit_tail(struct
> >> drm_atomic_state *old_state)
> >>rcdu->dpad1_source = rcrtc->index;
> >>}
> >>
> >> + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> >> + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> >> +
> >>/* Apply the atomic update. */
> >>drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >>drm_atomic_helper_commit_planes(dev, old_state,
--
Regards,
Laurent Pinchart
Re: [PATCH AUTOSEL 5.2 13/23] drm/i915/userptr: Acquire the page lock around set_page_dirty()
On Thu, Sep 12, 2019 at 11:51:33PM +0300, Thomas Backlund wrote:
Den 03-09-2019 kl. 19:24, skrev Sasha Levin:
From: Chris Wilson
[ Upstream commit aa56a292ce623734ddd30f52d73f527d1f3529b5 ]
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory
(userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-ch...@chris-wilson.co.uk
(cherry picked from commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 8079ea3af1039..b1fc15c7f5997 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -678,7 +678,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
- set_page_dirty(page);
+ /*
+* As this may not be anonymous memory (e.g. shmem)
+* but exist on a real mapping, we have to lock
+* the page in order to dirty it -- holding
+* the page reference is not sufficient to
+* prevent the inode from being truncated.
+* Play safe and take the lock.
+*/
+ set_page_dirty_lock(page);
mark_page_accessed(page);
put_page(page);
Please drop this one from all 5.2 and 4.19 stable queues
It has now been reverted in Linus tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=505a8ec7e11ae5236c4a154a1e24ef49a8349600
Now dropped, thank you.
--
Thanks,
Sasha
[Bug 204683] amdgpu: ring sdma0 timeout
https://bugzilla.kernel.org/show_bug.cgi?id=204683 --- Comment #10 from Matthias Heinz (m...@familie-heinz.name) --- Created attachment 284945 --> https://bugzilla.kernel.org/attachment.cgi?id=284945=edit Kernel trace Update 2 for today. With de00d253bc85, which is the predecessor of e6d2421343a7, I get this kernel bug. I have never seen this one after de00d253bc85, so my guess is that e6d2421343a7 fixes it partially. I will now start a bisect starting with the last known good kernel and de00d253bc85 and try to figure out when this one was introduced. (Back to kernel backing hell...) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: enable prime mmap support
On Thu, Sep 12, 2019 at 4:46 AM Gerd Hoffmann wrote:
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index 0c9553ea9f3f..96c240dbf452 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -200,6 +200,7 @@ static struct drm_driver driver = {
> #endif
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + .gem_prime_mmap = drm_gem_prime_mmap,
> .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
>
> .gem_create_object = virtio_gpu_create_object,
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: Fix warning in virtio_gpu_queue_fenced_ctrl_buffer.
On Thu, Sep 12, 2019 at 9:00 AM David Riley wrote:
>
> Fix warning introduced with commit e1218b8c0cc1
> ("drm/virtio: Use vmalloc for command buffer allocations.")
> from drm-misc-next.
>
> Signed-off-by: David Riley
Reviewed-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 9f9b782dd332..80176f379ad5 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -358,7 +358,7 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
> virtio_gpu_device *vgdev,
> sgt = vmalloc_to_sgt(vbuf->data_buf, vbuf->data_size,
> );
> if (!sgt)
> - return -ENOMEM;
> + return;
> vout = sgt->sgl;
> } else {
> sg_init_one(, vbuf->data_buf, vbuf->data_size);
> --
> 2.23.0.162.g0b9fbb3734-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] backlight: lm3630a: add an enable gpio for the HWEN pin
For now just enable it in the probe function to allow i2c
access. Disabling also means resetting the register values
to default and according to the datasheet does not give
power savings.
Tested on Kobo Clara HD.
Signed-off-by: Andreas Kemnade
Reviewed-by: Dan Murphy
Reviewed-by: Daniel Thompson
---
changes in v2:
- simplification
- correct gpio direction initialisation
changes in v3:
- removed legacy include
drivers/video/backlight/lm3630a_bl.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 8f84f3684f04..d9e67b9b2571 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -48,6 +49,7 @@ struct lm3630a_chip {
struct lm3630a_platform_data *pdata;
struct backlight_device *bleda;
struct backlight_device *bledb;
+ struct gpio_desc *enable_gpio;
struct regmap *regmap;
struct pwm_device *pwmd;
};
@@ -535,6 +537,13 @@ static int lm3630a_probe(struct i2c_client *client,
}
pchip->pdata = pdata;
+ pchip->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(pchip->enable_gpio)) {
+ rval = PTR_ERR(pchip->enable_gpio);
+ return rval;
+ }
+
/* chip initialize */
rval = lm3630a_chip_init(pchip);
if (rval < 0) {
--
2.20.1
[PATCH v4 0/2] backlight_lm3630a: add enable_gpios property
To be able to handle the HWEN pin of the lm3630a, add an enable gpio to the driver and a property. Tested on Kobo Clara HD. Changes in v2: simplification and reordering Changes in v3: added acked-by removed legacy include Changes in v4: added reviewed-by moved gpio to the right position in the bindings example Andreas Kemnade (2): dt-bindings: backlight: lm3630a: add enable_gpios backlight: lm3630a: add an enable gpio for the HWEN pin .../bindings/leds/backlight/lm3630a-backlight.yaml | 5 + drivers/video/backlight/lm3630a_bl.c | 9 + 2 files changed, 14 insertions(+) -- 2.20.1
[PATCH v4 1/2] dt-bindings: backlight: lm3630a: add enable_gpios
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
Acked-by: Daniel Thompson
---
changes in v2: added example
changes in v3: added Acked-by
changes in v4: moved enable-gpios to the right position
in the example
.../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index dc129d9a329e..c8470628fe02 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -29,6 +29,10 @@ properties:
'#size-cells':
const: 0
+ enable-gpios:
+description: GPIO to use to enable/disable the backlight (HWEN pin).
+maxItems: 1
+
required:
- compatible
- reg
@@ -96,6 +100,7 @@ examples:
led-controller@38 {
compatible = "ti,lm3630a";
reg = <0x38>;
+enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
--
2.20.1
[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=110199 --- Comment #15 from guimarcalsi...@gmail.com --- Tested today with Linux Manjaro 18.1 and kernel 5.2.11-1-MANJARO. The problem persists, but I can fix it by changing the refresh rate from 75 to 60 and back to 75 too after every boot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.2 13/23] drm/i915/userptr: Acquire the page lock around set_page_dirty()
Den 03-09-2019 kl. 19:24, skrev Sasha Levin:
From: Chris Wilson
[ Upstream commit aa56a292ce623734ddd30f52d73f527d1f3529b5 ]
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory
(userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-ch...@chris-wilson.co.uk
(cherry picked from commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 8079ea3af1039..b1fc15c7f5997 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -678,7 +678,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
- set_page_dirty(page);
+ /*
+* As this may not be anonymous memory (e.g. shmem)
+* but exist on a real mapping, we have to lock
+* the page in order to dirty it -- holding
+* the page reference is not sufficient to
+* prevent the inode from being truncated.
+* Play safe and take the lock.
+*/
+ set_page_dirty_lock(page);
mark_page_accessed(page);
put_page(page);
Please drop this one from all 5.2 and 4.19 stable queues
It has now been reverted in Linus tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=505a8ec7e11ae5236c4a154a1e24ef49a8349600
--
Thomas
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #98 from koala_man --- (In reply to koala_man from comment #95) > I am also seeing this issue on my stock Ubuntu. In my case it appears to have been faulty hardware. I tried it on Windows 10 with the latest drivers and still got crashes and reboots. Performance throttling did not help. I swapped out the GPU and haven't seen any crashes since. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
This 3 non-atomic drivers all have the same function getting the
only encoder available in the connector, also atomic drivers have
this fallback. So moving it a common place and sharing between atomic
and non-atomic drivers.
While at it I also removed the mention of
drm_atomic_helper_best_encoder() that was renamed in
commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
drm_atomic_helper_best_encoder").
v3: moving drm_connector_get_single_encoder to drm_kms_helper module
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/ast/ast_mode.c | 12
drivers/gpu/drm/drm_atomic_helper.c| 15 ++-
drivers/gpu/drm/drm_crtc_helper.c | 17 -
drivers/gpu/drm/drm_crtc_helper_internal.h | 3 +++
drivers/gpu/drm/mgag200/mgag200_mode.c | 11 ---
drivers/gpu/drm/udl/udl_connector.c| 8
include/drm/drm_modeset_helper_vtables.h | 6 +++---
7 files changed, 24 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index d349c721501c..eef95e1af06b 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -687,17 +687,6 @@ static void ast_encoder_destroy(struct drm_encoder
*encoder)
kfree(encoder);
}
-
-static struct drm_encoder *ast_best_single_encoder(struct drm_connector
*connector)
-{
- int enc_id = connector->encoder_ids[0];
- /* pick the encoder ids */
- if (enc_id)
- return drm_encoder_find(connector->dev, NULL, enc_id);
- return NULL;
-}
-
-
static const struct drm_encoder_funcs ast_enc_funcs = {
.destroy = ast_encoder_destroy,
};
@@ -847,7 +836,6 @@ static void ast_connector_destroy(struct drm_connector
*connector)
static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
.mode_valid = ast_mode_valid,
.get_modes = ast_get_modes,
- .best_encoder = ast_best_single_encoder,
};
static const struct drm_connector_funcs ast_connector_funcs = {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4706439fb490..9d7e4da6c292 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -97,17 +97,6 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
}
}
-/*
- * For connectors that support multiple encoders, either the
- * .atomic_best_encoder() or .best_encoder() operation must be implemented.
- */
-static struct drm_encoder *
-pick_single_encoder_for_connector(struct drm_connector *connector)
-{
- WARN_ON(connector->encoder_ids[1]);
- return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
-}
-
static int handle_conflicting_encoders(struct drm_atomic_state *state,
bool disable_conflicting_encoders)
{
@@ -135,7 +124,7 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
- new_encoder =
pick_single_encoder_for_connector(connector);
+ new_encoder =
drm_connector_get_single_encoder(connector);
if (new_encoder) {
if (encoder_mask & drm_encoder_mask(new_encoder)) {
@@ -359,7 +348,7 @@ update_connector_routing(struct drm_atomic_state *state,
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
- new_encoder = pick_single_encoder_for_connector(connector);
+ new_encoder = drm_connector_get_single_encoder(connector);
if (!new_encoder) {
DRM_DEBUG_ATOMIC("No suitable encoder found for
[CONNECTOR:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a51824a7e7c1..4a7447a53cea 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -460,6 +460,17 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
__drm_helper_disable_unused_functions(dev);
}
+/*
+ * For connectors that support multiple encoders, either the
+ * .atomic_best_encoder() or .best_encoder() operation must be implemented.
+ */
+struct drm_encoder *
+drm_connector_get_single_encoder(struct drm_connector *connector)
+{
+ WARN_ON(connector->encoder_ids[1]);
+ return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
+}
+
/**
* drm_crtc_helper_set_config - set a new config from userspace
* @set: mode set configuration
@@ -625,7 +636,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
new_encoder = connector->encoder;
for (ro = 0; ro <
[PATCH 2/2] drm/connector: Allow max possible encoders to attach to a connector
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Alex Deucher
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 -
drivers/gpu/drm/drm_client_modeset.c | 3 +-
drivers/gpu/drm/drm_connector.c | 31 +--
drivers/gpu/drm/drm_crtc_helper.c | 9 --
drivers/gpu/drm/drm_probe_helper.c| 3 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++--
include/drm/drm_connector.h | 18 +--
12 files changed, 55 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index ece55c8fa673..d8729285f731 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
- int i;
best_encoder = connector_funcs->best_encoder(connector);
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
@@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
int encoder_type)
{
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
@@ -347,10 +345,9 @@ static struct drm_encoder *
amdgpu_connector_best_single_encoder(struct drm_connector *connector)
{
struct drm_encoder *encoder;
- int i;
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
/* find analog encoder */
if (amdgpu_connector->dac_load_detect) {
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
continue;
@@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (amdgpu_connector->use_digital == true) {
if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
return encoder;
@@ -1134,7 +1129,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
/* then check use digitial */
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1271,9 +1266,8 @@ u16
amdgpu_connector_encoder_get_dp_bridge_encoder_id(struct drm_connector *conn
{
struct drm_encoder *encoder;
struct amdgpu_encoder *amdgpu_encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
Re: HDCP Content Type Interface
On 2019-09-12 10:57 a.m., Jani Nikula wrote: > On Thu, 12 Sep 2019, Harry Wentland wrote: >> On 2019-09-12 3:47 a.m., Ramalingam C wrote: >>> On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote: Hi all, This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233=11) There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. What are your thoughts? and what would be a good way to deal with it? >>> Hi, >>> >>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >>> supposed to exercise the highest version of HDCP supported on panel and >>> platform. >>> >>> As we implement the HDCP spec support, if a device is non-compliant with >>> HDCP spec after completing the HDCP authentication, I dont think we need >>> to worry about it. >>> >> >> Tell that to our (or your) customers. > > Agreed, let's rather not. > >> In this case an enduser might plug in a bad monitor or TV and be unable >> to play protected content. >> >> What if we add a new enum value to the content_type property that says >> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? > > In general, I think if the fix is to teach the user to jump through > hoops in case the output is not working, it is really not a fix. > > Would, say, a set top box or a Blu-ray player have a setting to force > HDCP 1.4, and a troubleshooting item in the manual to select that if the > display does not work? Or would OS X have that? > Not sure. AFAIU on other OS we're currently dealing with this through monitor quirks. We can probably pull the same quirks to DRM. > If broken HDCP 2.2 sink support is a widespread problem (is it?), what > do other HDCP sources do? If it's a Linux issue, what are we doing wrong > or different? Not a Linux issue and not overly widespread. Looks like a handful of receivers are problematic. Harry > > > BR, > Jani. > > > >> >> Harry >> >>> In case if you want to track and implement a quirk for it, like not to >>> project the HDCP2.2 capability, you can use the receiver id of that panel >>> to track it. >>> >>> Thanks, >>> -Ram Thanks, Bhawan >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: HDCP Content Type Interface
On 2019-09-12 10:49 a.m., Ramalingam C wrote: > On 2019-09-12 at 14:23:05 +, Harry Wentland wrote: >> On 2019-09-12 3:47 a.m., Ramalingam C wrote: >>> On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote: Hi all, This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233=11) There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. What are your thoughts? and what would be a good way to deal with it? >>> Hi, >>> >>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >>> supposed to exercise the highest version of HDCP supported on panel and >>> platform. >>> >>> As we implement the HDCP spec support, if a device is non-compliant with >>> HDCP spec after completing the HDCP authentication, I dont think we need >>> to worry about it. >>> >> >> Tell that to our (or your) customers. >> >> In this case an enduser might plug in a bad monitor or TV and be unable >> to play protected content. >> >> What if we add a new enum value to the content_type property that says >> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? > "content type" is for defining the stream type. Adding an entry into it > sounds like polluting it. > For sure > Separate uAPI for forcing a HDCP version might be need. Or wondering on > using the sysfs of connector for this dirty job!? > Did a bit more digging... On other OS we got a monitor quirk for a few displays and also something similar to a module parameter to force disable HDCP 2.x support. It looks like there aren't too many quirky receivers so that might be an acceptable solution. I'm still thinking a connector property might be useful to force a certain HDCP version but maybe I'm overthinking it. Harry > -Ram >> >> Harry >> >>> In case if you want to track and implement a quirk for it, like not to >>> project the HDCP2.2 capability, you can use the receiver id of that panel >>> to track it. >>> >>> Thanks, >>> -Ram Thanks, Bhawan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: IOCTL to label BO in DRM Core
On Thu, Sep 12, 2019 at 7:57 PM Eric Anholt wrote: > > Rohan Garg writes: > > > [ Unknown signature status ] > > Hi > > I'm investigating a way to label BO's in panfrost, similar to how VC4 does > > it > > and realised that this could be something that's might be useful to all > > drivers. > > > > With that in mind, would anyone be opposed to add a DRM_IOCTL_BO_SET_LABEL > > in > > DRM core that can be utilised by all drivers to label BO's? > > I would love to see something shared. msm has an object labeling > interface as well. > > vc4's had some overengineering due to wanting to keep a bucketed-by-name > usage list so we could dump that when we ran out of memory or from > debugfs. I think something much simpler would be better. I think there's even some patches floating to lift this to the dma-buf level (at least for output ind debugfs), but we'd still need a generic thing at the drm_gem_bo level. If we can subsume at least some of the existing ioctls (with a thin wrapper) to this new thing I'm all for it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Restore ttm prefaulting
From: Thomas Hellstrom
Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
Restore (almost) the original behaviour. Unfortunately we can no longer
with the new vm_fault_t return type determine whether a prefaulting
PTE insertion hit an already populated PTE, and terminate the insertion
loop. Instead we continue with the pre-determined number of prefaults.
Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
Cc: Souptick Joarder
Cc: Christian König
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 5a580adeb9d1..aa18e8a53727 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -290,15 +290,13 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
else
ret = vmf_insert_pfn(, address, pfn);
- /*
-* Somebody beat us to this PTE or prefaulting to
-* an already populated PTE, or prefaulting error.
-*/
-
- if (unlikely((ret == VM_FAULT_NOPAGE && i > 0)))
- break;
- else if (unlikely(ret & VM_FAULT_ERROR))
- goto out_io_unlock;
+ /* Never error on prefaulted PTEs */
+ if (unlikely((ret & VM_FAULT_ERROR))) {
+ if (i == 0)
+ goto out_io_unlock;
+ else
+ break;
+ }
address += PAGE_SIZE;
if (unlikely(++page_offset >= page_last))
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: IOCTL to label BO in DRM Core
Rohan Garg writes: > [ Unknown signature status ] > Hi > I'm investigating a way to label BO's in panfrost, similar to how VC4 does it > and realised that this could be something that's might be useful to all > drivers. > > With that in mind, would anyone be opposed to add a DRM_IOCTL_BO_SET_LABEL in > DRM core that can be utilised by all drivers to label BO's? I would love to see something shared. msm has an object labeling interface as well. vc4's had some overengineering due to wanting to keep a bucketed-by-name usage list so we could dump that when we ran out of memory or from debugfs. I think something much simpler would be better. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: clean caches at the end of render jobs on request from user space
Iago Toral Quiroga writes:
> Extends the user space ioctl for CL submissions so it can include a request
> to flush the cache once the CL execution has completed. Fixes memory
> write violation messages reported by the kernel in workloads involving
> shader memory writes (SSBOs, shader images, scratch, etc) which sometimes
> also lead to GPU resets during Piglit and CTS workloads.
Some context for any other reviewers: This patch is the interface change
necessary to expose GLES 3.1 on V3D. It turns out the HW packets for
flushing the caches were broken in multiple ways.
> Signed-off-by: Iago Toral Quiroga
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 51 +--
> include/uapi/drm/v3d_drm.h| 7 ++---
> 2 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 5d80507b539b..530fe9d9d5bd 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -530,13 +530,16 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
> struct drm_v3d_submit_cl *args = data;
> struct v3d_bin_job *bin = NULL;
> struct v3d_render_job *render;
> + struct v3d_job *clean_job = NULL;
> + struct v3d_job *last_job;
> struct ww_acquire_ctx acquire_ctx;
> int ret = 0;
>
> trace_v3d_submit_cl_ioctl(>drm, args->rcl_start, args->rcl_end);
>
> - if (args->pad != 0) {
> - DRM_INFO("pad must be zero: %d\n", args->pad);
> + if (args->flags != 0 &&
> + args->flags != DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG) {
> + DRM_INFO("invalid flags: %d\n", args->flags);
> return -EINVAL;
> }
>
> @@ -575,12 +578,28 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
> bin->render = render;
> }
>
> - ret = v3d_lookup_bos(dev, file_priv, >base,
> + if (args->flags & DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG) {
> + clean_job = kcalloc(1, sizeof(*clean_job), GFP_KERNEL);
> + if (!clean_job) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
> + ret = v3d_job_init(v3d, file_priv, clean_job, v3d_job_free, 0);
> + if (ret)
> + goto fail;
Only issue I see: If v3d_job_init() fails, we need to not v3d_job_put()
it. I'm fine with either kfree() it and NULL the ptr before jumping to
fail, or open code the bin/render puts.
With that,
Reviewed-by: Eric Anholt
> +
> + last_job = clean_job;
> + } else {
> + last_job = >base;
> + }
> +
> + ret = v3d_lookup_bos(dev, file_priv, last_job,
>args->bo_handles, args->bo_handle_count);
> if (ret)
> goto fail;
>
> - ret = v3d_lock_bo_reservations(>base, _ctx);
> + ret = v3d_lock_bo_reservations(last_job, _ctx);
> if (ret)
> goto fail;
>
> @@ -599,28 +618,44 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
> ret = v3d_push_job(v3d_priv, >base, V3D_RENDER);
> if (ret)
> goto fail_unreserve;
> +
> + if (clean_job) {
> + struct dma_fence *render_fence =
> + dma_fence_get(render->base.done_fence);
> + ret = drm_gem_fence_array_add(_job->deps, render_fence);
> + if (ret)
> + goto fail_unreserve;
> + ret = v3d_push_job(v3d_priv, clean_job, V3D_CACHE_CLEAN);
> + if (ret)
> + goto fail_unreserve;
> + }
> +
> mutex_unlock(>sched_lock);
>
> v3d_attach_fences_and_unlock_reservation(file_priv,
> - >base,
> + last_job,
>_ctx,
>args->out_sync,
> - render->base.done_fence);
> + last_job->done_fence);
>
> if (bin)
> v3d_job_put(>base);
> v3d_job_put(>base);
> + if (clean_job)
> + v3d_job_put(clean_job);
>
> return 0;
>
> fail_unreserve:
> mutex_unlock(>sched_lock);
> - drm_gem_unlock_reservations(render->base.bo,
> - render->base.bo_count, _ctx);
> + drm_gem_unlock_reservations(last_job->bo,
> + last_job->bo_count, _ctx);
> fail:
> if (bin)
> v3d_job_put(>base);
> v3d_job_put(>base);
> + if (clean_job)
> + v3d_job_put(clean_job);
>
> return ret;
> }
> diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
> index 58fbe48c91e9..58d2040ea48c 100644
> --- a/include/uapi/drm/v3d_drm.h
> +++ b/include/uapi/drm/v3d_drm.h
> @@ -48,6 +48,8 @@ extern "C" {
> #define DRM_IOCTL_V3D_SUBMIT_TFU
Re: [PATCH 1/4] mm/hmm: make full use of walk_page_range()
On 9/12/19 1:26 AM, Christoph Hellwig wrote:
+static int hmm_pfns_fill(unsigned long addr,
+unsigned long end,
+struct hmm_range *range,
+enum hmm_pfn_value_e value)
Nit: can we use the space a little more efficient, e.g.:
static int hmm_pfns_fill(unsigned long addr, unsigned long end,
struct hmm_range *range, enum hmm_pfn_value_e value)
+static int hmm_vma_walk_test(unsigned long start,
+unsigned long end,
+struct mm_walk *walk)
Same here.
+ if (!(vma->vm_flags & VM_READ)) {
+ (void) hmm_pfns_fill(start, end, range, HMM_PFN_NONE);
There should be no need for the void cast here.
OK. I'll post a v2 with the these changes.
Thanks for the reviews.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] mm/hmm: allow snapshot of the special zero page
On 9/12/19 1:26 AM, Christoph Hellwig wrote:
On Wed, Sep 11, 2019 at 03:28:27PM -0700, Ralph Campbell wrote:
Allow hmm_range_fault() to return success (0) when the CPU pagetable
entry points to the special shared zero page.
The caller can then handle the zero page by possibly clearing device
private memory instead of DMAing a zero page.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: Jason Gunthorpe
Cc: Christoph Hellwig
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 06041d4399ff..7217912bef13 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -532,7 +532,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
return -EBUSY;
} else if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) && pte_special(pte))
{
*pfn = range->values[HMM_PFN_SPECIAL];
- return -EFAULT;
+ return is_zero_pfn(pte_pfn(pte)) ? 0 : -EFAULT;
Any chance to just use a normal if here:
if (!is_zero_pfn(pte_pfn(pte)))
return -EFAULT;
return 0;
Sure, no problem.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Hi "Jos??, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc8 next-20190904] [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/Jos-Roberto-de-Souza/drm-connector-Share-with-non-atomic-drivers-the-function-to-get-the-single-encoder/20190912-213415 config: x86_64-randconfig-g003-201936 (attached as .config) compiler: gcc-7 (Debian 7.4.0-11) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "drm_connector_get_single_encoder" >> [drivers/gpu/drm/drm_kms_helper.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #38 from rol...@rptd.ch --- Could it be that your patch is not for version "mesa-19.0.8" as I'm using? (newer ones are keyworded) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: gpu: Convert Samsung Image Rotator to dt-schema
Convert Samsung Image Rotator to newer dt-schema format.
Signed-off-by: Maciej Falkowski
Signed-off-by: Marek Szyprowski
---
v2:
- add required properties
- add proper commit recipients
---
.../bindings/gpu/samsung-rotator.txt | 28 --
.../bindings/gpu/samsung-rotator.yaml | 52 +++
2 files changed, 52 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpu/samsung-rotator.txt
create mode 100644 Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
deleted file mode 100644
index 3aca2578da0b..
--- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Samsung Image Rotator
-
-Required properties:
- - compatible : value should be one of the following:
- * "samsung,s5pv210-rotator" for Rotator IP in S5PV210
- * "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
- * "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
- * "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
-
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
-
- - interrupts : Interrupt specifier for rotator interrupt, according to format
-specific to interrupt parent.
-
- - clocks : Clock specifier for rotator clock, according to generic clock
-bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
-
- - clock-names : Names of clocks. For exynos rotator, it should be "rotator".
-
-Example:
- rotator@1281 {
- compatible = "samsung,exynos4210-rotator";
- reg = <0x1281 0x1000>;
- interrupts = <0 83 0>;
- clocks = < 278>;
- clock-names = "rotator";
- };
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
new file mode 100644
index ..96afafe98388
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/samsung-rotator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Image Rotator
+
+maintainers:
+ - Inki Dae
+
+properties:
+ compatible:
+enum:
+ - "samsung,s5pv210-rotator"# for Rotator IP in S5PV210
+ - "samsung,exynos4210-rotator" # for Rotator IP in Exynos4210
+ - "samsung,exynos4212-rotator" # for Rotator IP in Exynos4212/4412
+ - "samsung,exynos5250-rotator" # for Rotator IP in Exynos5250
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+description: |
+ Clock specifier for rotator clock according to generic clock
+ bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
+maxItems: 1
+
+ clock-names:
+items:
+- const: rotator
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+rotator@1281 {
+compatible = "samsung,exynos4210-rotator";
+reg = <0x1281 0x1000>;
+interrupts = <0 83 0>;
+clocks = < 278>;
+clock-names = "rotator";
+};
+
--
2.17.1
[PATCH] drm/virtio: Fix warning in virtio_gpu_queue_fenced_ctrl_buffer.
Fix warning introduced with commit e1218b8c0cc1
("drm/virtio: Use vmalloc for command buffer allocations.")
from drm-misc-next.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9f9b782dd332..80176f379ad5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -358,7 +358,7 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
sgt = vmalloc_to_sgt(vbuf->data_buf, vbuf->data_size,
);
if (!sgt)
- return -ENOMEM;
+ return;
vout = sgt->sgl;
} else {
sg_init_one(, vbuf->data_buf, vbuf->data_size);
--
2.23.0.162.g0b9fbb3734-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm fixes for 5.3-rc9
Hey Linus, >From the maintainer summit, just some last minute fixes for final, details in the tag. Dave. drm-fixes-2019-09-13: drm fixes for 5.3-rc9 lima: - fix gem_wait ioctl core: - constify modes list i915: - DP MST high color depth regression - GPU hangs on vulkan compute workloads The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e: Linux 5.3-rc8 (2019-09-08 13:33:15 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-09-13 for you to fetch changes up to e6bb711600db23eef2fa0c16a2d361e17b45bb28: Merge tag 'drm-misc-fixes-2019-09-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2019-09-12 23:14:35 +1000) drm fixes for 5.3-rc8 lima: - fix gem_wait ioctl core: - constify modes list i915: - DP MST high color depth regression - GPU hangs on vulkan compute workloads Chris Wilson (1): drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+ Dave Airlie (2): Merge tag 'drm-intel-fixes-2019-09-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2019-09-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Maxime Ripard (1): drm/modes: Make the whitelist more const Vasily Khoruzhick (1): drm/lima: fix lima_gem_wait() return value Ville Syrjälä (1): drm/i915: Limit MST to <= 8bpc once again drivers/gpu/drm/drm_modes.c | 2 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 - drivers/gpu/drm/lima/lima_gem.c | 2 +- 4 files changed, 11 insertions(+), 8 deletions(-)
Re: [PATCH v7 04/11] drm: revocation check at drm subsystem
On 2019-09-12 2:54 a.m., Ramalingam C wrote: > On 2019-09-12 at 00:15:32 +, Harry Wentland wrote: >> Adding a couple AMD guys. >> >> I know this is already merged but I have a few questions after some >> internal discussions. >> >> On 2019-05-07 12:27 p.m., Ramalingam C wrote: >>> On every hdcp revocation check request SRM is read from fw file >>> /lib/firmware/display_hdcp_srm.bin >>> >> >> According to section 5 of the HDCP 2.3 spec [1] a device compliant with >> HDCP 2.0 and higher must be capable of storing and updating the SRM in >> non-volatile memory. Section 5.2 describes how this SRM needs to be >> updated when a new version is served alongside protected content. >> >> Isn't /lib/firmware intended for static firmware making updates to the >> folder problematic for anyone but the system's package maintainer? I've >> heard /lib might even be treated as read-only in certain environments. >> This would mean it'd be impossible to support HDCP 2.x on those systems. >> >> Wouldn't it be easier to provide a sysfs entry for SRM that allows >> userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM >> from the HDCP implementation for non-volatile storage and (b) to pass >> the SRM to the HDCP implementation for revocation checking? > > This uAPI is decided considering below points: > > userspace will handle the non-volatile storage of the SRM table and it's > upgrade > with latest versions received from content providers etc. > > Prior to any HDCP auth request userspace will write the latest SRM into > the /lib/firmware. > > And regarding the interface, binary sysfs based implementation [1] was > opposed by Greg KH. > And after the discussion on different alternate i/fs [2] request > firmware is choosen. > > [1]. https://patchwork.freedesktop.org/patch/296442/?series=57232=5uAPI > [2]. https://patchwork.freedesktop.org/patch/296439/?series=57232=5 > > I hope this addresses the questions above. > Interesting discussion. Thanks for sharing. It sounds like Greg's main concern was with the fact that DRM parses the binary. In our case we'll need to pass the blob to FW without touching it. A device sysfs sounds like a better use-case for that. On the other hand certain people are interested to have a non-FW approach to content protection for which your approach seems to work best. I still don't know how this solution can get HDCP 2.x certified. I was under the impression HDCP 2.x required a protected execution environment with stricter requirements than x86 kernel space can provide. Harry > -Ram > > >> >> [1] >> https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf >> >> Thanks, >> Harry >> >>> SRM table is parsed and stored at drm_hdcp.c, with functions exported >>> for the services for revocation check from drivers (which >>> implements the HDCP authentication) >>> >>> This patch handles the HDCP1.4 and 2.2 versions of SRM table. >>> >>> v2: >>> moved the uAPI to request_firmware_direct() [Daniel] >>> v3: >>> kdoc added. [Daniel] >>> srm_header unified and bit field definitions are removed. [Daniel] >>> locking improved. [Daniel] >>> vrl length violation is fixed. [Daniel] >>> v4: >>> s/__swab16/be16_to_cpu [Daniel] >>> be24_to_cpu is done through a global func [Daniel] >>> Unused variables are removed. [Daniel] >>> unchecked return values are dropped from static funcs [Daniel] >>> >>> Signed-off-by: Ramalingam C >>> Acked-by: Satyeshwar Singh >>> Reviewed-by: Daniel Vetter >>> --- >>> Documentation/gpu/drm-kms-helpers.rst | 6 + >>> drivers/gpu/drm/Makefile | 2 +- >>> drivers/gpu/drm/drm_hdcp.c| 333 ++ >>> drivers/gpu/drm/drm_internal.h| 4 + >>> drivers/gpu/drm/drm_sysfs.c | 2 + >>> include/drm/drm_hdcp.h| 24 ++ >>> 6 files changed, 370 insertions(+), 1 deletion(-) >>> create mode 100644 drivers/gpu/drm/drm_hdcp.c >>> >>> diff --git a/Documentation/gpu/drm-kms-helpers.rst >>> b/Documentation/gpu/drm-kms-helpers.rst >>> index 14102ae035dc..0fe726a6ee67 100644 >>> --- a/Documentation/gpu/drm-kms-helpers.rst >>> +++ b/Documentation/gpu/drm-kms-helpers.rst >>> @@ -181,6 +181,12 @@ Panel Helper Reference >>> .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c >>> :export: >>> >>> +HDCP Helper Functions Reference >>> +=== >>> + >>> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c >>> + :export: >>> + >>> Display Port Helper Functions Reference >>> === >>> >>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >>> index 72f5036d9bfa..dd02e9dec810 100644 >>> --- a/drivers/gpu/drm/Makefile >>> +++ b/drivers/gpu/drm/Makefile >>> @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \ >>> drm_plane.o drm_color_mgmt.o drm_print.o \ >>> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ >>>
Re: [PATCH v3] drm: bridge/dw_hdmi: add audio sample channel status setting
Dne sreda, 11. september 2019 ob 19:02:38 CEST je Cheng-yi Chiang napisal(a):
> On Thu, Sep 12, 2019 at 12:54 AM Jernej Škrabec
wrote:
> > Dne sreda, 11. september 2019 ob 18:23:59 CEST je Neil Armstrong
napisal(a):
> > > On 11/09/2019 10:26, Cheng-Yi Chiang wrote:
> > > > From: Yakir Yang
> > > >
> > > > When transmitting IEC60985 linear PCM audio, we configure the
> > > > Aduio Sample Channel Status information in the IEC60958 frame.
> > > > The status bit is already available in iec.status of
> > > > hdmi_codec_params.
> > > >
> > > > This fix the issue that audio does not come out on some monitors
> > > > (e.g. LG 22CV241)
> > > >
> > > > Note that these registers are only for interfaces:
> > > > I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> > > > (AHBAUDDMA).
> > > > For S/PDIF interface this information comes from the stream.
> > > >
> > > > Currently this function dw_hdmi_set_channel_status is only called
> > > > from dw-hdmi-i2s-audio in I2S setup.
> > > >
> > > > Signed-off-by: Yakir Yang
> > > > Signed-off-by: Cheng-Yi Chiang
> > > > ---
> > > >
> > > > Change from v2 to v3:
> > > > 1. Reuse what is already set in iec.status in hw_param.
> > > > 2. Remove all useless definition of registers and values.
> > > > 3. Note that the original sampling frequency is not written to
> > > >
> > > >the channel status as we reuse create_iec958_consumer in
> > > >pcm_iec958.c.
> > > >Without that it can still play audio fine.
> > > >
> > > > .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 20
> > > > +++
> > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > > > include/drm/bridge/dw_hdmi.h | 1 +
> > > > 4 files changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> > > > 34d8e837555f..20f4f92dd866 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > > > @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device
> > > > *dev,
> > > > void *data,>
> > > >
> > > > }
> > > >
> > > > dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> > > >
> > > > + dw_hdmi_set_channel_status(hdmi, hparms->iec.status);
> > > >
> > > > dw_hdmi_set_channel_count(hdmi, hparms->channels);
> > > > dw_hdmi_set_channel_allocation(hdmi, hparms-
> > >
> > >cea.channel_allocation);
> > >
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > > > bd65d0479683..aa7efd4da1c8 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > > @@ -582,6 +582,26 @@ static unsigned int hdmi_compute_n(unsigned int
> > > > freq,
> > > > unsigned long pixel_clk)>
> > > >
> > > > return n;
> > > >
> > > > }
> > > >
> > > > +/*
> > > > + * When transmitting IEC60958 linear PCM audio, these registers allow
> > > > to
> > > > + * configure the channel status information of all the channel status
> > > > + * bits in the IEC60958 frame. For the moment this configuration is
> > > > only
> > > > + * used when the I2S audio interface, General Purpose Audio (GPA),
> > > > + * or AHB audio DMA (AHBAUDDMA) interface is active
> > > > + * (for S/PDIF interface this information comes from the stream).
> > > > + */
> > > > +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> > > > + u8 *channel_status)
> > > > +{
> > > > + /*
> > > > +* Set channel status register for frequency and word length.
> > > > +* Use default values for other registers.
> > > > +*/
> > > > + hdmi_writeb(hdmi, channel_status[3], HDMI_FC_AUDSCHNLS7);
> > > > + hdmi_writeb(hdmi, channel_status[4], HDMI_FC_AUDSCHNLS8);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(dw_hdmi_set_channel_status);
> > > > +
> > > >
> > > > static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> > > >
> > > > unsigned long pixel_clk, unsigned int sample_rate)
> > > >
> > > > {
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> > > > 6988f12d89d9..fcff5059db24 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > > > @@ -158,6 +158,8 @@
> > > >
> > > > #define HDMI_FC_SPDDEVICEINF0x1062
> > > > #define HDMI_FC_AUDSCONF0x1063
> > > > #define HDMI_FC_AUDSSTAT0x1064
> > > >
> > > > +#define HDMI_FC_AUDSCHNLS7 0x106e
> > > > +#define HDMI_FC_AUDSCHNLS8 0x106f
> > > >
> > > > #define HDMI_FC_DATACH0FILL 0x1070
> > > > #define HDMI_FC_DATACH1FILL
Re: [PATCH v3 1/2] dt-bindings: backlight: lm3630a: add enable_gpios
Andreas
On 9/12/19 9:58 AM, Andreas Kemnade wrote:
On Thu, 12 Sep 2019 06:39:50 -0500
Dan Murphy wrote:
Andreas
On 9/11/19 12:21 PM, Andreas Kemnade wrote:
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
Acked-by: Daniel Thompson
---
changes in v2: added example
changes in v3: added Acked-by
.../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index dc129d9a329e..1fa83feffe16 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -29,6 +29,10 @@ properties:
'#size-cells':
const: 0
+ enable-gpios:
+description: GPIO to use to enable/disable the backlight (HWEN pin).
+maxItems: 1
+
required:
- compatible
- reg
@@ -92,6 +96,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
+enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
led-controller@38 {
compatible = "ti,lm3630a";
Looks good to me
well, the enable-gpios is still at the same place as in v2. This was sent
before your comments to v2 have been arrived.
Ah I overlooked that. Yeah that still needs to move I assumed you moved it.
Dan
Regards,
Andreas
[Bug 111527] obs-studio + latest mesa on amdgpu/vega64 leaks kernel memory rapidly
https://bugs.freedesktop.org/show_bug.cgi?id=111527 tele4...@hotmail.com changed: What|Removed |Added Blocks||111444 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111444 [Bug 111444] [TRACKER] Mesa 19.2 release tracker -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: backlight: lm3630a: add enable_gpios
On Thu, 12 Sep 2019 06:39:50 -0500
Dan Murphy wrote:
> Andreas
>
> On 9/11/19 12:21 PM, Andreas Kemnade wrote:
> > add enable-gpios to describe HWEN pin
> >
> > Signed-off-by: Andreas Kemnade
> > Acked-by: Daniel Thompson
> > ---
> > changes in v2: added example
> > changes in v3: added Acked-by
> > .../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > index dc129d9a329e..1fa83feffe16 100644
> > ---
> > a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > @@ -29,6 +29,10 @@ properties:
> > '#size-cells':
> > const: 0
> >
> > + enable-gpios:
> > +description: GPIO to use to enable/disable the backlight (HWEN pin).
> > +maxItems: 1
> > +
> > required:
> > - compatible
> > - reg
> > @@ -92,6 +96,7 @@ examples:
> > i2c {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
> >
> > led-controller@38 {
> > compatible = "ti,lm3630a";
>
> Looks good to me
>
well, the enable-gpios is still at the same place as in v2. This was sent
before your comments to v2 have been arrived.
Regards,
Andreas
pgpCpMwJJpC6G.pgp
Description: OpenPGP digital signature
Re: HDCP Content Type Interface
On Thu, 12 Sep 2019, Harry Wentland wrote: > On 2019-09-12 3:47 a.m., Ramalingam C wrote: >> On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote: >>> Hi all, >>> >>> This is regarding the recent hdcp content type patch that was merged into >>> drm-misc. >>> (https://patchwork.freedesktop.org/patch/320958/?series=57233=11) >>> >>> There are displays on the market that advertise HDCP 2.2 support and will >>> pass authentication and encryption but will then show a >>> corrupted/blue/black screen (the driver cannot detect this). These displays >>> work with HDCP 1.4 without any issues. Due to the large number of >>> HDCP-supporting devices on the market we might not be able to catch them >>> with a blacklist. >>> >>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same >>> thing. Meaning that this interface doesn't allow us to force the hdcp >>> version. Due to the problems mentioned above we might want to expose the >>> ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) >>> in case they experience problems. >>> >>> What are your thoughts? and what would be a good way to deal with it? >> Hi, >> >> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >> supposed to exercise the highest version of HDCP supported on panel and >> platform. >> >> As we implement the HDCP spec support, if a device is non-compliant with >> HDCP spec after completing the HDCP authentication, I dont think we need >> to worry about it. >> > > Tell that to our (or your) customers. Agreed, let's rather not. > In this case an enduser might plug in a bad monitor or TV and be unable > to play protected content. > > What if we add a new enum value to the content_type property that says > "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? In general, I think if the fix is to teach the user to jump through hoops in case the output is not working, it is really not a fix. Would, say, a set top box or a Blu-ray player have a setting to force HDCP 1.4, and a troubleshooting item in the manual to select that if the display does not work? Or would OS X have that? If broken HDCP 2.2 sink support is a widespread problem (is it?), what do other HDCP sources do? If it's a Linux issue, what are we doing wrong or different? BR, Jani. > > Harry > >> In case if you want to track and implement a quirk for it, like not to >> project the HDCP2.2 capability, you can use the receiver id of that panel >> to track it. >> >> Thanks, >> -Ram >>> >>> >>> Thanks, >>> >>> Bhawan > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: HDCP Content Type Interface
On 2019-09-12 at 14:23:05 +, Harry Wentland wrote: > On 2019-09-12 3:47 a.m., Ramalingam C wrote: > > On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote: > >> Hi all, > >> > >> This is regarding the recent hdcp content type patch that was merged into > >> drm-misc. > >> (https://patchwork.freedesktop.org/patch/320958/?series=57233=11) > >> > >> There are displays on the market that advertise HDCP 2.2 support and will > >> pass authentication and encryption but will then show a > >> corrupted/blue/black screen (the driver cannot detect this). These > >> displays work with HDCP 1.4 without any issues. Due to the large number of > >> HDCP-supporting devices on the market we might not be able to catch them > >> with a blacklist. > >> > >> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same > >> thing. Meaning that this interface doesn't allow us to force the hdcp > >> version. Due to the problems mentioned above we might want to expose the > >> ability for a user to force an HDCP downgrade to a certain level (e.g. > >> 1.4) in case they experience problems. > >> > >> What are your thoughts? and what would be a good way to deal with it? > > Hi, > > > > As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel > > supposed to exercise the highest version of HDCP supported on panel and > > platform. > > > > As we implement the HDCP spec support, if a device is non-compliant with > > HDCP spec after completing the HDCP authentication, I dont think we need > > to worry about it. > > > > Tell that to our (or your) customers. > > In this case an enduser might plug in a bad monitor or TV and be unable > to play protected content. > > What if we add a new enum value to the content_type property that says > "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? "content type" is for defining the stream type. Adding an entry into it sounds like polluting it. Separate uAPI for forcing a HDCP version might be need. Or wondering on using the sysfs of connector for this dirty job!? -Ram > > Harry > > > In case if you want to track and implement a quirk for it, like not to > > project the HDCP2.2 capability, you can use the receiver id of that panel > > to track it. > > > > Thanks, > > -Ram > >> > >> > >> Thanks, > >> > >> Bhawan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v5 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500
On Tue, Sep 10, 2019 at 03:59:13PM +0800, Wen He wrote:
> Configure the display Quality of service (QoS) levels priority if the
> optional property node "arm,malidp-aqros-value" is defined in DTS file.
>
> QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
> driven from the "RQOS" register, so needed to program the RQOS register
> to avoid the high resolutions flicker issue on the LS1028A platform.
>
> Signed-off-by: Wen He
Acked-by: Liviu Dudau
Thanks for the patch! I will pull this into the malidp code and push it to
drm-misc-next in the following days.
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 6 ++
> drivers/gpu/drm/arm/malidp_hw.c | 9 +
> drivers/gpu/drm/arm/malidp_hw.h | 3 +++
> drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> 4 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 333b88a5efb0..8a76315aaa0f 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -817,6 +817,12 @@ static int malidp_bind(struct device *dev)
>
> malidp->core_id = version;
>
> + ret = of_property_read_u32(dev->of_node,
> + "arm,malidp-arqos-value",
> + >arqos_value);
> + if (ret)
> + hwdev->arqos_value = 0x0;
> +
> /* set the number of lines used for output of RGB data */
> ret = of_property_read_u8_array(dev->of_node,
> "arm,malidp-output-port-lines",
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index bd8265f02e0b..ca570b135478 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -379,6 +379,15 @@ static void malidp500_modeset(struct malidp_hw_device
> *hwdev, struct videomode *
> malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> else
> malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> +
> + /*
> + * Program the RQoS register to avoid high resolutions flicker
> + * issue on the LS1028A.
> + */
> + if (hwdev->arqos_value) {
> + val = hwdev->arqos_value;
> + malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
> + }
> }
>
> int malidp_format_get_bpp(u32 fmt)
> diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
> index 968a65eed371..e4c36bc90bda 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.h
> +++ b/drivers/gpu/drm/arm/malidp_hw.h
> @@ -251,6 +251,9 @@ struct malidp_hw_device {
>
> /* size of memory used for rotating layers, up to two banks available */
> u32 rotation_memory[2];
> +
> + /* priority level of RQOS register used for driven the ARQOS signal */
> + u32 arqos_value;
> };
>
> static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
> diff --git a/drivers/gpu/drm/arm/malidp_regs.h
> b/drivers/gpu/drm/arm/malidp_regs.h
> index 993031542fa1..514c50dcb74d 100644
> --- a/drivers/gpu/drm/arm/malidp_regs.h
> +++ b/drivers/gpu/drm/arm/malidp_regs.h
> @@ -210,6 +210,16 @@
> #define MALIDP500_CONFIG_VALID 0x00f00
> #define MALIDP500_CONFIG_ID 0x00fd4
>
> +/*
> + * The quality of service (QoS) register on the DP500. RQOS register values
> + * are driven by the ARQOS signal, using AXI transacations, dependent on the
> + * FIFO input level.
> + * The RQOS register can also set QoS levels for:
> + *- RED_ARQOS @ A 4-bit signal value for close to underflow conditions
> + *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
> + */
> +#define MALIDP500_RQOS_QUALITY 0x00500
> +
> /* register offsets and bits specific to DP550/DP650 */
> #define MALIDP550_ADDR_SPACE_SIZE0x1
> #define MALIDP550_DE_CONTROL 0x00010
> --
> 2.17.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Without deferred IO support, hyperv_fb driver informs the host to refresh
the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
is screen update or not. This patch supports deferred IO for screens in
graphics mode and also enables the frame buffer on-demand refresh. The
highest refresh rate is still set at 20Hz.
Currently Hyper-V only takes a physical address from guest as the starting
address of frame buffer. This implies the guest must allocate contiguous
physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
accept address from MMIO region as frame buffer address. Due to these
limitations on Hyper-V host, we keep a shadow copy of frame buffer
in the guest. This means one more copy of the dirty rectangle inside
guest when doing the on-demand refresh. This can be optimized in the
future with help from host. For now the host performance gain from deferred
IO outweighs the shadow copy impact in the guest.
Signed-off-by: Wei Hu
---
v2: Incorporated review comments from Michael Kelley
- Increased dirty rectangle by one row in deferred IO case when sending
to Hyper-V.
- Corrected the dirty rectangle size in the text mode.
- Added more comments.
- Other minor code cleanups.
v3: Incorporated more review comments
- Removed a few unnecessary variable tests
v4: Incorporated test and review feedback from Dexuan Cui
- Not disable interrupt while acquiring docopy_lock in
hvfb_update_work(). This avoids significant bootup delay in
large vCPU count VMs.
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/hyperv_fb.c | 216 +---
2 files changed, 197 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 1b2f5f31fb6f..e781f89a1824 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2241,6 +2241,7 @@ config FB_HYPERV
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_DEFERRED_IO
help
This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index fe319fc39bec..711c46a5d5d2 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -237,6 +237,7 @@ struct synthvid_msg {
#define RING_BUFSIZE (256 * 1024)
#define VSP_TIMEOUT (10 * HZ)
#define HVFB_UPDATE_DELAY (HZ / 20)
+#define HVFB_ONDEMAND_THROTTLE (HZ / 20)
struct hvfb_par {
struct fb_info *info;
@@ -256,6 +257,17 @@ struct hvfb_par {
bool synchronous_fb;
struct notifier_block hvfb_panic_nb;
+
+ /* Memory for deferred IO and frame buffer itself */
+ unsigned char *dio_vp;
+ unsigned char *mmio_vp;
+ unsigned long mmio_pp;
+ spinlock_t docopy_lock; /* Lock to protect memory copy */
+
+ /* Dirty rectangle, protected by delayed_refresh_lock */
+ int x1, y1, x2, y2;
+ bool delayed_refresh;
+ spinlock_t delayed_refresh_lock;
};
static uint screen_width = HVFB_WIDTH;
@@ -264,6 +276,7 @@ static uint screen_width_max = HVFB_WIDTH;
static uint screen_height_max = HVFB_HEIGHT;
static uint screen_depth;
static uint screen_fb_size;
+static uint dio_fb_size; /* FB size for deferred IO */
/* Send message to Hyper-V host */
static inline int synthvid_send(struct hv_device *hdev,
@@ -350,28 +363,92 @@ static int synthvid_send_ptr(struct hv_device *hdev)
}
/* Send updated screen area (dirty rectangle) location to host */
-static int synthvid_update(struct fb_info *info)
+static int
+synthvid_update(struct fb_info *info, int x1, int y1, int x2, int y2)
{
struct hv_device *hdev = device_to_hv_device(info->device);
struct synthvid_msg msg;
memset(, 0, sizeof(struct synthvid_msg));
+ if (x2 == INT_MAX)
+ x2 = info->var.xres;
+ if (y2 == INT_MAX)
+ y2 = info->var.yres;
msg.vid_hdr.type = SYNTHVID_DIRT;
msg.vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
sizeof(struct synthvid_dirt);
msg.dirt.video_output = 0;
msg.dirt.dirt_count = 1;
- msg.dirt.rect[0].x1 = 0;
- msg.dirt.rect[0].y1 = 0;
- msg.dirt.rect[0].x2 = info->var.xres;
- msg.dirt.rect[0].y2 = info->var.yres;
+ msg.dirt.rect[0].x1 = (x1 > x2) ? 0 : x1;
+ msg.dirt.rect[0].y1 = (y1 > y2) ? 0 : y1;
+ msg.dirt.rect[0].x2 =
+ (x2 < x1 || x2 > info->var.xres) ? info->var.xres : x2;
+ msg.dirt.rect[0].y2 =
+ (y2 < y1 || y2 > info->var.yres) ? info->var.yres : y2;
synthvid_send(hdev, );
return 0;
}
+static void hvfb_docopy(struct hvfb_par *par,
+ unsigned long offset,
+ unsigned long size)
+{
+ if (!par || !par->mmio_vp || !par->dio_vp || !par->fb_ready ||
+ size == 0 ||
Re: HDCP Content Type Interface
On 2019-09-12 3:47 a.m., Ramalingam C wrote: > On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote: >> Hi all, >> >> This is regarding the recent hdcp content type patch that was merged into >> drm-misc. >> (https://patchwork.freedesktop.org/patch/320958/?series=57233=11) >> >> There are displays on the market that advertise HDCP 2.2 support and will >> pass authentication and encryption but will then show a corrupted/blue/black >> screen (the driver cannot detect this). These displays work with HDCP 1.4 >> without any issues. Due to the large number of HDCP-supporting devices on >> the market we might not be able to catch them with a blacklist. >> >> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same >> thing. Meaning that this interface doesn't allow us to force the hdcp >> version. Due to the problems mentioned above we might want to expose the >> ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) >> in case they experience problems. >> >> What are your thoughts? and what would be a good way to deal with it? > Hi, > > As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel > supposed to exercise the highest version of HDCP supported on panel and > platform. > > As we implement the HDCP spec support, if a device is non-compliant with > HDCP spec after completing the HDCP authentication, I dont think we need > to worry about it. > Tell that to our (or your) customers. In this case an enduser might plug in a bad monitor or TV and be unable to play protected content. What if we add a new enum value to the content_type property that says "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? Harry > In case if you want to track and implement a quirk for it, like not to > project the HDCP2.2 capability, you can use the receiver id of that panel > to track it. > > Thanks, > -Ram >> >> >> Thanks, >> >> Bhawan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On 12/09/2019 14:21, Andrzej Hajda wrote: > On 12.09.2019 04:38, John Stultz wrote: >> On Wed, Sep 4, 2019 at 3:26 AM Andrzej Hajda wrote: >>> On 03.09.2019 18:18, John Stultz wrote: On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda wrote: > On 30.08.2019 19:00, Rob Clark wrote: >> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda >> wrote: >>> Of course it seems you have different opinion what is the right thing in >>> this case, so if you convince us that your approach is better one can >>> revert the patch. >> I guess my strongest / most immediate opinion is to not break other >> existing adv75xx bridge users. > It is pity that breakage happened, and next time we should be more > strict about testing other platforms, before patch acceptance. > > But reverting it now will break also platform which depend on it. I'm really of no opinion of which approach is better here, but I will say that when a patch breaks previously working boards, that's a regression and justifying that some other board is now enabled that would be broken by the revert (of a patch that is not yet upstream) isn't really a strong argument. I'm happy to work with folks to try to fixup the kirin driver if this patch really is the right approach, but we need someone to do the same for the db410c, and I don't think its fair to just dump that work onto folks under the threat of the board breaking. >>> >>> These drivers should be fixed anyway - assumption that >>> drm_bridge/drm_panel will be registered before the bus it is attached to >>> is just incorrect. >>> >>> So instead of reverting, fixing and then re-applying the patch I have >>> gently proposed shorter path. If you prefer long path we can try to go >>> this way. >>> >>> Matt, is the pure revert OK for you or is it possible to prepare some >>> workaround allowing cooperation with both approaches? >> Rob/Andrzej: What's the call here? >> >> Should I resubmit the kirin fix for the adv7511 regression here? >> Or do we revert the adv7511 patch? I believe db410c still needs a fix. >> >> I'd just like to keep the HiKey board from breaking, so let me know so >> I can get the fix submitted if needed. > > > Since there is no response from Matt, we can perform revert, since there > are no other ideas. I will apply it tomorrow, if there are no objections. Hi, Sorry - yeah I think reverting is probably best at this point to avoid breaking in-tree platforms. It's a shame though that there is a built-in incompatibility within the tree between drivers. The way that the generic Synopsys DSI host driver probes is currently incompatible with the ADV7533 (hence the patch), other DSI host drivers are now compatible with the ADV7533 but break when we change it to probe in a similar way to panel drivers. > > And for the future: I guess it is not possible to make adv work with old > and new approach, but simple workaround for adv could be added later: > > if (source is msm or kirin) > > do_the_old_way > > else > > do_correctly. Maybe this would work, but how do we know that the list "msm or kirin" is exhaustive to cope with all platforms? It seems to me the built in incompatibility between DSI hosts needs to be resolved really rather than trying to work around it in the ADV7533 driver (and any other DSI bus device that falls into this trap). Anyway, my platform is out of tree so better to revert my patch and keep the in-tree platforms working. Thanks everyone. Matt > > > And remove it after fixing both dsi masters. > > > Regards > > Andrzej > > >> >> thanks >> -john >> >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/virtio: Export resource handles via DMA-buf API
Hi Gerd, On Thu, Sep 12, 2019 at 9:38 PM Gerd Hoffmann wrote: > > Hi, > > > To seamlessly enable buffer sharing with drivers using such frameworks, > > make the virtio-gpu driver expose the resource handle as the DMA address > > of the buffer returned from the DMA-buf mapping operation. Arguably, the > > resource handle is a kind of DMA address already, as it is the buffer > > identifier that the device needs to access the backing memory, which is > > exactly the same role a DMA address provides for native devices. First of all, thanks for taking a look at this. > > No. A scatter list has guest dma addresses, period. Stuffing something > else into a scatterlist is asking for trouble, things will go seriously > wrong when someone tries to use such a fake scatterlist as real scatterlist. What is a "guest dma address"? The definition of a DMA address in the Linux DMA API is an address internal to the DMA master address space. For virtio, the resource handle namespace may be such an address space. However, we could as well introduce a separate DMA address space if resource handles are not the right way to refer to the memory from other virtio devices. > > Also note that "the DMA address of the buffer" is bonkers in virtio-gpu > context. virtio-gpu resources are not required to be physically > contigous in memory, so typically you actually need a scatter list to > describe them. There is no such requirement even on a bare metal system, see any system that has an IOMMU, which is typical on ARM/ARM64. The DMA address space must be contiguous only from the DMA master point of view. Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111669] Navi GPU hang in Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=111669 --- Comment #1 from Pierre-Eric Pelloux-Prayer --- Thanks for the bug report and the trace. I can reproduce the hang. There's always a page fault before, e.g: amdgpu :0b:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32772, for process glretrace pid 8616 thread glretrace:cs0 pid 8617) amdgpu :0b:00.0: in page starting at address 0x00f03000 from client 27 amdgpu :0b:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301031 amdgpu :0b:00.0: MORE_FAULTS: 0x1 amdgpu :0b:00.0: WALKER_ERROR: 0x0 amdgpu :0b:00.0: PERMISSION_FAULTS: 0x3 amdgpu :0b:00.0: MAPPING_ERROR: 0x0 amdgpu :0b:00.0: RW: 0x0 I couldn't find the root cause yet. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 00/37] Introduce memory region concept (including device local memory)
Quoting Dave Airlie (2019-08-13 22:20:52) > On Sat, 10 Aug 2019 at 08:26, Matthew Auld wrote: > > > > In preparation for upcoming devices with device local memory, introduce the > > concept of different memory regions, and a simple buddy allocator to manage > > them in i915. > > > > One of the concerns raised from v1 was around not using enough of TTM, > > which is > > a fair criticism, so trying to get better alignment here is something we are > > investigating, though currently that is still WIP so in the meantime v3 > > still > > continues to push more of the low-level details forward, but not yet the TTM > > interactions. > > Can we bump the TTM work up the ladder here, as is I'm not willing to > accept any of this code upstream without some serious analysis, this > isn't a case of me making a nice suggestion and you having the option > to ignore it. Don't make me shout. Thanks for a reminder. TTM analysis was ongoing on the background and we now reserved enough time to conclude on how to best align with TTM in short-term and long-term. We decided to bite the bullet and apply dma_resv as the outer-most locking in i915 codepaths to align with the TTM locking. As a conclusion to those discussions we documented guidelines how to align with TTM locking: https://patchwork.freedesktop.org/patch/328266/ As refactoring of locking fundamentals of the driver is a massive undergoing with many opens along the path, we'd like to propose a staged approach to avoid stalling the upstream work while it's being done. Our first suggested step would be merging the i915 local memory related internal code reworks to unblock the display work. This step should not cause any conflicts with TTM. Following step would be to merge proposed memory allocation/ management uAPIs with TTM related functionality behind them for early debug. They would be protected by DRM_I915_DEBUG_EARLY_API kernel config flag (depending on EXPERT & STAGING & BROKEN). This would allow us to keep debugging these new IOCTLs with Mesa etc. while we rework the locking. The protection still leaving us a possibility to correcting the uAPIs if/when there is need after reworking the locking around dma_resv progresses. Draft of such proposal here: https://patchwork.freedesktop.org/patch/327908/ The final step (a rather long one) would be then to complete the locking rework in the driver and lift the DEBUG_EARLY_API protection once the locking has been sorted. If you could confirm the above plan sounds reasonable to you, we may then proceed with it. Regards, Joonas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On 12.09.2019 04:38, John Stultz wrote: > On Wed, Sep 4, 2019 at 3:26 AM Andrzej Hajda wrote: >> On 03.09.2019 18:18, John Stultz wrote: >>> On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda wrote: On 30.08.2019 19:00, Rob Clark wrote: > On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda > wrote: >> Of course it seems you have different opinion what is the right thing in >> this case, so if you convince us that your approach is better one can >> revert the patch. > I guess my strongest / most immediate opinion is to not break other > existing adv75xx bridge users. It is pity that breakage happened, and next time we should be more strict about testing other platforms, before patch acceptance. But reverting it now will break also platform which depend on it. >>> I'm really of no opinion of which approach is better here, but I will >>> say that when a patch breaks previously working boards, that's a >>> regression and justifying that some other board is now enabled that >>> would be broken by the revert (of a patch that is not yet upstream) >>> isn't really a strong argument. >>> >>> I'm happy to work with folks to try to fixup the kirin driver if this >>> patch really is the right approach, but we need someone to do the same >>> for the db410c, and I don't think its fair to just dump that work onto >>> folks under the threat of the board breaking. >> >> These drivers should be fixed anyway - assumption that >> drm_bridge/drm_panel will be registered before the bus it is attached to >> is just incorrect. >> >> So instead of reverting, fixing and then re-applying the patch I have >> gently proposed shorter path. If you prefer long path we can try to go >> this way. >> >> Matt, is the pure revert OK for you or is it possible to prepare some >> workaround allowing cooperation with both approaches? > Rob/Andrzej: What's the call here? > > Should I resubmit the kirin fix for the adv7511 regression here? > Or do we revert the adv7511 patch? I believe db410c still needs a fix. > > I'd just like to keep the HiKey board from breaking, so let me know so > I can get the fix submitted if needed. Since there is no response from Matt, we can perform revert, since there are no other ideas. I will apply it tomorrow, if there are no objections. And for the future: I guess it is not possible to make adv work with old and new approach, but simple workaround for adv could be added later: if (source is msm or kirin) do_the_old_way else do_correctly. And remove it after fixing both dsi masters. Regards Andrzej > > thanks > -john > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/virtio: Export resource handles via DMA-buf API
Hi, > To seamlessly enable buffer sharing with drivers using such frameworks, > make the virtio-gpu driver expose the resource handle as the DMA address > of the buffer returned from the DMA-buf mapping operation. Arguably, the > resource handle is a kind of DMA address already, as it is the buffer > identifier that the device needs to access the backing memory, which is > exactly the same role a DMA address provides for native devices. No. A scatter list has guest dma addresses, period. Stuffing something else into a scatterlist is asking for trouble, things will go seriously wrong when someone tries to use such a fake scatterlist as real scatterlist. Also note that "the DMA address of the buffer" is bonkers in virtio-gpu context. virtio-gpu resources are not required to be physically contigous in memory, so typically you actually need a scatter list to describe them. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #37 from Jeremy Silliman --- I purchased a 5700XT the other day, and what I've noticed is that anything that tries getting statistics from the GPU (radeontop, lm_sensors) induces a page fault hang within a couple of minutes. In my testing I either ran lm_sensors every three seconds, or radeontop, and left it idle while playing a game or watching a video, and without fail, a hang would happen shortly after. As soon as I stopped running either of those programs the hangs stopped. This may work as a reproducible test case for some of the hangs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Add r8a77980 support
On 12/09/2019 13:03, Geert Uytterhoeven wrote: > Hi Kieran, > > On Thu, Sep 12, 2019 at 12:26 PM Kieran Bingham > wrote: >> (pulling in +Geert for his opinion on compatible string usages) >> >> On 12/09/2019 11:00, Sergei Shtylyov wrote:> Hello! >>> On 11.09.2019 22:25, Kieran Bingham wrote: Add direct support for the r8a77980 (V3H). The V3H shares a common, compatible configuration with the r8a77970 (V3M) so that device info structure is reused. >>> >>>Do we really need to add yet another compatible in this case? >>> I just added r8a77970 to the compatible prop in the r8a77980 DT. That's why >>> a patch like this one didn't get posted by me. >> >> It's not just about the compatible string for me here, >> >> There is no indication in the driver that it supports the r8a77980, and >> no comment in the driver to explain that the r8a77980 is shared by the >> r8a77970. >> >> This patch makes that explicit at the driver. >> >> Also - I am considering sending a patch (that I've already created >> anyway) to remove the r8a77970 reference from the >> >> arch/arm64/boot/dts/renesas/r8a77980.dtsi file. >> >> This is the *only* non r8a77980 reference in this file, so it seems very >> out of place. > > Agreed. > >> In fact more so than that - except for a seemingly glaring typo, that >> I'll investigate and send a patch for next, this is the *only* cross-soc >> compatible reference: >> >> #!/bin/sh >> >> files=r8a77*.dtsi >> >> for f in $files; >> do >> soc=`basename $f .dtsi | sed 's/-.*//'` >> echo "F: $f soc: $soc"; >> >> # Find all references to all socs, then hide 'this' soc >> grep r8a77 $f | grep -v $soc > > This hides the complete line. So you better use e.g. > > sed -e "s/$soc/soc/ig" $f | grep -i r8a Aha yes, excellent point! (I'm glad I posted my working) > > instead. No new offenders, though. Phew, I still got the right answer :-D -- Kieran ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Add r8a77980 support
Hi Kieran,
On Thu, Sep 12, 2019 at 12:26 PM Kieran Bingham
wrote:
> (pulling in +Geert for his opinion on compatible string usages)
>
> On 12/09/2019 11:00, Sergei Shtylyov wrote:> Hello!
> > On 11.09.2019 22:25, Kieran Bingham wrote:
> >> Add direct support for the r8a77980 (V3H).
> >>
> >> The V3H shares a common, compatible configuration with the r8a77970
> >> (V3M) so that device info structure is reused.
> >
> >Do we really need to add yet another compatible in this case?
> > I just added r8a77970 to the compatible prop in the r8a77980 DT. That's why
> > a patch like this one didn't get posted by me.
>
> It's not just about the compatible string for me here,
>
> There is no indication in the driver that it supports the r8a77980, and
> no comment in the driver to explain that the r8a77980 is shared by the
> r8a77970.
>
> This patch makes that explicit at the driver.
>
> Also - I am considering sending a patch (that I've already created
> anyway) to remove the r8a77970 reference from the
>
> arch/arm64/boot/dts/renesas/r8a77980.dtsi file.
>
> This is the *only* non r8a77980 reference in this file, so it seems very
> out of place.
Agreed.
> In fact more so than that - except for a seemingly glaring typo, that
> I'll investigate and send a patch for next, this is the *only* cross-soc
> compatible reference:
>
> #!/bin/sh
>
> files=r8a77*.dtsi
>
> for f in $files;
> do
> soc=`basename $f .dtsi | sed 's/-.*//'`
> echo "F: $f soc: $soc";
>
> # Find all references to all socs, then hide 'this' soc
> grep r8a77 $f | grep -v $soc
This hides the complete line. So you better use e.g.
sed -e "s/$soc/soc/ig" $f | grep -i r8a
instead. No new offenders, though.
> done;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 14/14] drm/amdgpu: set TMZ bits in PTEs for secure bo (v2)
Am 12.09.19 um 12:27 schrieb Huang, Ray:
> On Wed, Sep 11, 2019 at 08:13:19PM +0800, Koenig, Christian wrote:
>> Am 11.09.19 um 13:50 schrieb Huang, Ray:
>>> From: Alex Deucher
>>>
>>> If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ
>>> bits of
>>> PTEs that belongs that bo should be set. Then psp is able to protect the
>>> pages
>>> of this bo to avoid the access from an "untrust" domain such as CPU.
>>>
>>> v1: design and draft the skeletion of tmz bits setting on PTEs (Alex)
>>> v2: return failure once create secure bo on no-tmz platform (Ray)
>>>
>>> Signed-off-by: Alex Deucher
>>> Reviewed-by: Huang Rui
>>> Signed-off-by: Huang Rui
>>> ---
>>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 12 +++-
>>>drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 10 ++
>>>drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 +
>>>3 files changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> index 22eab74..5332104 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> @@ -222,7 +222,8 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
>>> void *data,
>>> AMDGPU_GEM_CREATE_CPU_GTT_USWC |
>>> AMDGPU_GEM_CREATE_VRAM_CLEARED |
>>> AMDGPU_GEM_CREATE_VM_ALWAYS_VALID |
>>> - AMDGPU_GEM_CREATE_EXPLICIT_SYNC))
>>> + AMDGPU_GEM_CREATE_EXPLICIT_SYNC |
>>> + AMDGPU_GEM_CREATE_ENCRYPTED))
>>>
>>> return -EINVAL;
>>>
>>> @@ -230,6 +231,11 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
>>> void *data,
>>> if (args->in.domains & ~AMDGPU_GEM_DOMAIN_MASK)
>>> return -EINVAL;
>>>
>>> + if (!adev->tmz.enabled && (flags & AMDGPU_GEM_CREATE_ENCRYPTED)) {
>>> + DRM_ERROR("Cannot allocate secure buffer while tmz is
>>> disabled\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> /* create a gem object to contain this object in */
>>> if (args->in.domains & (AMDGPU_GEM_DOMAIN_GDS |
>>> AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
>>> @@ -251,6 +257,10 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
>>> void *data,
>>> resv = vm->root.base.bo->tbo.resv;
>>> }
>>>
>>> + if (flags & AMDGPU_GEM_CREATE_ENCRYPTED) {
>>> + /* XXX: pad out alignment to meet TMZ requirements */
>>> + }
>>> +
>>> r = amdgpu_gem_object_create(adev, size, args->in.alignment,
>>> (u32)(0x & args->in.domains),
>>> flags, ttm_bo_type_device, resv, );
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> index 5a3c177..286e2e2 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> @@ -224,6 +224,16 @@ static inline bool amdgpu_bo_explicit_sync(struct
>>> amdgpu_bo *bo)
>>> return bo->flags & AMDGPU_GEM_CREATE_EXPLICIT_SYNC;
>>>}
>>>
>>> +/**
>>> + * amdgpu_bo_encrypted - return whether the bo is encrypted
>>> + */
>>> +static inline bool amdgpu_bo_encrypted(struct amdgpu_bo *bo)
>>> +{
>>> + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>>> +
>>> + return adev->tmz.enabled && (bo->flags & AMDGPU_GEM_CREATE_ENCRYPTED);
>> Checking the adev->tmz.enabled flags should be dropped here.
>>
> That's fine. BO should be validated while it is created.
>
> But if the BO is created by vmid 0, is this checking needed?
>
>>> +}
>>> +
>>>bool amdgpu_bo_is_amdgpu_bo(struct ttm_buffer_object *bo);
>>>void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain);
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> index 3663655..8f00bb2 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> @@ -1434,6 +1434,8 @@ bool amdgpu_ttm_tt_is_readonly(struct ttm_tt *ttm)
>>>uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm, struct ttm_mem_reg
>>> *mem)
>>>{
>>> uint64_t flags = 0;
>>> + struct ttm_buffer_object *tbo = ttm_mem_reg_to_bo(mem);
>>> + struct amdgpu_bo *abo = ttm_to_amdgpu_bo(tbo);
>> That's a clear NAK. The function is not necessarily called with
>> >mem, which is also the reason why this function doesn't gets the BO
>> as parameter.
>>
> Do you mean we can revise the below functions to use bo as the parameter
> instead?
>
> uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm, struct amdgpu_bo *bo)
> uint64_t amdgpu_ttm_tt_pte_flags(struct ttm_tt *ttm, struct amdgpu_bo *bo)
If that is possible then this would indeed be a solution for the problem.
Christian.
>
> Thanks,
> Ray
>
>> Christian.
>>
>>>
>>> if (mem && mem->mem_type != TTM_PL_SYSTEM)
>>>
[PATCH] drm/virtio: enable prime mmap support
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 0c9553ea9f3f..96c240dbf452 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -200,6 +200,7 @@ static struct drm_driver driver = {
#endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
.gem_create_object = virtio_gpu_create_object,
--
2.18.1
Re: [PATCH v3 2/2] backlight: lm3630a: add an enable gpio for the HWEN pin
Andreas
On 9/11/19 12:21 PM, Andreas Kemnade wrote:
For now just enable it in the probe function to allow i2c
access. Disabling also means resetting the register values
to default and according to the datasheet does not give
power savings.
Tested on Kobo Clara HD.
Signed-off-by: Andreas Kemnade
---
changes in v2:
- simplification
- correct gpio direction initialisation
changes in v3:
- removed legacy include
drivers/video/backlight/lm3630a_bl.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 8f84f3684f04..d9e67b9b2571 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -48,6 +49,7 @@ struct lm3630a_chip {
struct lm3630a_platform_data *pdata;
struct backlight_device *bleda;
struct backlight_device *bledb;
+ struct gpio_desc *enable_gpio;
struct regmap *regmap;
struct pwm_device *pwmd;
};
@@ -535,6 +537,13 @@ static int lm3630a_probe(struct i2c_client *client,
}
pchip->pdata = pdata;
+ pchip->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(pchip->enable_gpio)) {
+ rval = PTR_ERR(pchip->enable_gpio);
+ return rval;
+ }
+
/* chip initialize */
rval = lm3630a_chip_init(pchip);
if (rval < 0) {
Thanks for the explanation
It looks good to me
Reviewed-by: Dan Murphy
Re: [PATCH v3 1/2] dt-bindings: backlight: lm3630a: add enable_gpios
Andreas
On 9/11/19 12:21 PM, Andreas Kemnade wrote:
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
Acked-by: Daniel Thompson
---
changes in v2: added example
changes in v3: added Acked-by
.../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index dc129d9a329e..1fa83feffe16 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -29,6 +29,10 @@ properties:
'#size-cells':
const: 0
+ enable-gpios:
+description: GPIO to use to enable/disable the backlight (HWEN pin).
+maxItems: 1
+
required:
- compatible
- reg
@@ -92,6 +96,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
+enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
led-controller@38 {
compatible = "ti,lm3630a";
Looks good to me
Reviewed-by: Dan Murphy
[PATCH v7 7/7] drm/i915/dp: Attach HDR metadata property to DP connector
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index abbf1d5c54c4..4084b06fcbfc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6539,6 +6539,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_colorspace_property(connector);
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ drm_object_attach_property(>base,
+
connector->dev->mode_config.hdr_output_metadata_property,
+ 0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.
Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register
size.
Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.
++---+
| [ Packet Type Value ] | [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
| [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++
v2: Add a missed blank line after function declaration.
v3: Remove not handled return values from
intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 89
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8dc030650801..306f6f9f0204 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3625,6 +3625,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7fe22b37474d..abbf1d5c54c4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4599,6 +4599,83 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
}
+static void
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
+ struct dp_sdp infoframe_sdp = {};
+ struct hdmi_drm_infoframe drm_infoframe = {};
+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
HDMI_DRM_INFOFRAME_SIZE;
+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+ ssize_t len;
+ int ret;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
+ if (ret) {
+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+ return;
+ }
+
+ len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
+ if (len < 0) {
+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
infoframe\n");
+ return;
+ }
+
+ if (len != infoframe_size) {
+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+ return;
+ }
+
+ /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+ /* Packet ID, 00h for non-Audio INFOFRAME */
+ infoframe_sdp.sdp_header.HB0 = 0;
+ /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+*/
+ infoframe_sdp.sdp_header.HB1 = drm_infoframe.type;
+ /*
+* Least Significant Eight Bits of (Data Byte
[PATCH v7 4/7] drm/i915/dp: Attach colorspace property
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3a8aef1c6036..7fe22b37474d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6448,6 +6448,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 5/7] drm/i915: Add new GMP register size for GEN11
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Uma's review comments.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c500fc9154c8..287999b31217 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -189,13 +189,19 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
}
}
-static int hsw_dip_data_size(unsigned int type)
+static int hsw_dip_data_size(struct drm_i915_private *dev_priv,
+unsigned int type)
{
switch (type) {
case DP_SDP_VSC:
return VIDEO_DIP_VSC_DATA_SIZE;
case DP_SDP_PPS:
return VIDEO_DIP_PPS_DATA_SIZE;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ if (INTEL_GEN(dev_priv) >= 11)
+ return VIDEO_DIP_GMP_DATA_SIZE;
+ else
+ return VIDEO_DIP_DATA_SIZE;
default:
return VIDEO_DIP_DATA_SIZE;
}
@@ -514,7 +520,7 @@ static void hsw_write_infoframe(struct intel_encoder
*encoder,
int i;
u32 val = I915_READ(ctl_reg);
- data_size = hsw_dip_data_size(type);
+ data_size = hsw_dip_data_size(dev_priv, type);
val &= ~hsw_infoframe_enable(type);
I915_WRITE(ctl_reg, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bf37ecebc82f..ff7f32b59363 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4677,6 +4677,7 @@ enum {
* (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
byte
* of the infoframe structure specified by CEA-861. */
#define VIDEO_DIP_DATA_SIZE 32
+#define VIDEO_DIP_GMP_DATA_SIZE 36
#define VIDEO_DIP_VSC_DATA_SIZE 36
#define VIDEO_DIP_PPS_DATA_SIZE 132
#define VIDEO_DIP_CTL _MMIO(0x61170)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/7] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.
Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 68
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
4 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e6394139964..98d69febd8e3 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3623,7 +3623,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+ intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index f4ddde171655..409544e0e2f8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -526,8 +526,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state);
int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d09133a958e1..a2a0214f771a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4449,8 +4449,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
}
static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4471,13 +4472,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp
*intel_dp,
*/
vsc_sdp.sdp_header.HB3 = 0x13;
- /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
- vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+ /* DP 1.4a spec, Table 2-120 */
+ switch (crtc_state->output_format) {
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+ break;
+ case INTEL_OUTPUT_FORMAT_RGB:
+ default:
+ /* RGB: DB16[7:4] = 0h */
+ break;
+ }
+
+ switch (conn_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ vsc_sdp.db[16] |= 0x1;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_601:
+ vsc_sdp.db[16] |= 0x2;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_709:
+ vsc_sdp.db[16] |= 0x3;
+ break;
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ vsc_sdp.db[16] |= 0x4;
+ break;
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ vsc_sdp.db[16] |= 0x5;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ vsc_sdp.db[16] |= 0x6;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ vsc_sdp.db[16] |= 0x7;
+ break;
+ case
[PATCH v7 2/7] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
v2: Remove useless parentheses
v3: Addressed review comments from Ville
- In order to checking output format and output colorspace on
intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state struct
value.
- Remove a pointless variable.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++--
.../drm/i915/display/intel_display_types.h| 3 ++
drivers/gpu/drm/i915/display/intel_dp.c | 29 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 98d69febd8e3..8dc030650801 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,11 +1737,12 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
/*
* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
* of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
*/
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (intel_dp_needs_vsc_sdp(crtc_state))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d5cc4b810d9e..4108570907d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -971,6 +971,9 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
+ /* Output colorspace sRGB/BT.2020 etc */
+ u32 output_colorspace;
+
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a2a0214f771a..3a8aef1c6036 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2187,6 +2187,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->output_colorspace = intel_conn_state->base.colorspace;
+
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
@@ -4448,6 +4450,31 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+bool
+intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state)
+{
+ /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut], in order to
+* sending YCBCR 420 or HDR BT.2020 signals we should use DP VSC SDP.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ return true;
+
+ switch (crtc_state->output_colorspace) {
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ return true;
+ default:
+ break;
+ }
+
+ return false;
+}
+
static void
intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
@@ -4576,7 +4603,7 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
- if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (!intel_dp_needs_vsc_sdp(crtc_state))
return;
intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
diff --git
[PATCH v7 3/7] drm: Add DisplayPort colorspace property
Because between HDMI and DP have different colorspaces, it renames
drm_mode_create_colorspace_property() function to
drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
And it adds drm_mode_create_dp_colorspace_property() function for creating
of DP colorspace property.
In order to apply changed and added drm api, i915 driver has channged.
v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for DP.
v4: Add additional comments to struct drm_prop_enum_list.
Polishing an enum string of struct drm_prop_enum_list
v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and
DP abbreviations.
Add missed variables on dp_colorspaces.
Fix typo. [Uma]
v6: Addressed review comments from Ilia and Ville
- Split drm_mode_create_colorspace_property() to DP and HDMI connector.
v7: Fix typo [Jani Saarinen]
Fix white space.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 110 +++---
.../gpu/drm/i915/display/intel_connector.c| 21 +++-
include/drm/drm_connector.h | 11 +-
3 files changed, 121 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..656f72c1b3d7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -882,6 +882,47 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+/*
+ * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry
+ * Format Table 2-120
+ */
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Colorimetry based on sRGB (IEC 61966-2-1) */
+ { DRM_MODE_COLORIMETRY_CEA_RGB, "CEA_RGB" },
+ { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
+ /* Colorimetry based on scRGB (IEC 61966-2-2) */
+ { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point"
},
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on SMPTE RP 431-2 */
+ { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
+ { DRM_MODE_COLORIMETRY_RGB_CUSTOM_COLOR_PROFILE,
"RGB_Custom_Color_Profile" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
+ { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /*
+* Colorimetry based on Digital Imaging and Communications in Medicine
+* (DICOM) Part 14: Grayscale Standard Display Function
+*/
+ { DRM_MODE_COLORIMETRY_Y_ONLY_DICOM_P14_GRAYSCALE,
"Y_ONLY_DICOM_Part_14_Grayscale" },
+ { DRM_MODE_COLORIMETRY_RAW_CUSTOM_COLOR_PROFILE,
"Raw_Custom_Color_Profile" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1674,7 +1715,6 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* DOC: standard connector properties
*
* Colorspace:
- * drm_mode_create_colorspace_property - create colorspace property
* This property helps select a suitable colorspace based on the sink
* capability. Modern sink devices support wider gamut like BT2020.
* This helps switch to BT2020 mode if the BT2020 encoded video stream
@@ -1694,32 +1734,68 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* - This property is just to inform sink what colorspace
*source is trying to drive.
*
+ * Because between HDMI and DP have different colorspaces,
+ * drm_mode_create_hdmi_colorspace_property() is used for HDMI connector and
+ * drm_mode_create_dp_colorspace_property() is used for DP connector.
+ */
+
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
* Called by a driver the first time it's needed, must be attached to desired
- * connectors.
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on
[PATCH v7 0/7] drm/i915/dp: Support for DP HDR outputs
Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite v2: - Add a missed blank line after function declaration. - Remove useless parentheses. - Minor style fix. v3: - Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] - Add handling of different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms [Uma] - Add new colorimetry options for DP 1.4a spec. [Ville] - Separate set of colorimetry enum values for DP. [Ville] - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville] - Remove a pointless variable. [Ville] v4: - Add additional comments to struct drm_prop_enum_list. - Polishing an enum string of struct drm_prop_enum_list. v5: - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and DP abbreviations. - Add missed variables on dp_colorspaces. - Fix typo. [Uma] v6: - Addressed review comments from Ilia and Ville Split drm_mode_create_colorspace_property() to DP and HDMI connector. Becasue between HDMI and DP have different colorspaces, it renames drm_mode_create_colorspace_property() function to drm_mode_create_hdmi_colorspace_property() function for HDMI connector. And it adds drm_mode_create_dp_colorspace_property() function for creating of DP colorspace property. In order to apply changed and added drm api, i915 driver has channged. v7: - Fix typo [Jani Saarinen] - Fix white space. Gwan-gyeong Mun (7): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Add DisplayPort colorspace property drm/i915/dp: Attach colorspace property drm/i915: Add new GMP register size for GEN11 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 110 -- .../gpu/drm/i915/display/intel_connector.c| 21 +- drivers/gpu/drm/i915/display/intel_ddi.c | 10 +- drivers/gpu/drm/i915/display/intel_display.h | 2 - .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_dp.c | 193 -- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +- drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_connector.h | 11 +- 10 files changed, 326 insertions(+), 42 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panfrost: Use generic code for devfreq
On Thu, Sep 12, 2019 at 12:28:03PM +0100, Steven Price wrote: > Use dev_pm_opp_set_rate() instead of open coding the devfreq > integration, simplifying the code. Reviewed-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panfrost: Simplify devfreq utilisation tracking
Instead of tracking per-slot utilisation track a single value for the
entire GPU. Ultimately it doesn't matter if the GPU is busy with only
vertex or a combination of vertex and fragment processing - if it's busy
then it's busy and devfreq should be scaling appropriately.
This also makes way for being able to submit multiple jobs per slot
which requires more values than the original boolean per slot.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 64 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.h | 12 ++--
drivers/gpu/drm/panfrost/panfrost_job.c | 14 ++---
4 files changed, 38 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 7ded282a5ca8..4c4e8a30a1ac 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -13,7 +13,7 @@
#include "panfrost_gpu.h"
#include "panfrost_regs.h"
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev,
int slot);
+static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev);
static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
@@ -32,37 +32,23 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
static void panfrost_devfreq_reset(struct panfrost_device *pfdev)
{
- ktime_t now = ktime_get();
- int i;
-
- for (i = 0; i < NUM_JOB_SLOTS; i++) {
- pfdev->devfreq.slot[i].busy_time = 0;
- pfdev->devfreq.slot[i].idle_time = 0;
- pfdev->devfreq.slot[i].time_last_update = now;
- }
+ pfdev->devfreq.busy_time = 0;
+ pfdev->devfreq.idle_time = 0;
+ pfdev->devfreq.time_last_update = ktime_get();
}
static int panfrost_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct panfrost_device *pfdev = dev_get_drvdata(dev);
- int i;
- for (i = 0; i < NUM_JOB_SLOTS; i++) {
- panfrost_devfreq_update_utilization(pfdev, i);
- }
+ panfrost_devfreq_update_utilization(pfdev);
status->current_frequency = clk_get_rate(pfdev->clock);
- status->total_time =
ktime_to_ns(ktime_add(pfdev->devfreq.slot[0].busy_time,
-
pfdev->devfreq.slot[0].idle_time));
-
- status->busy_time = 0;
- for (i = 0; i < NUM_JOB_SLOTS; i++) {
- status->busy_time +=
ktime_to_ns(pfdev->devfreq.slot[i].busy_time);
- }
+ status->total_time = ktime_to_ns(ktime_add(pfdev->devfreq.busy_time,
+ pfdev->devfreq.idle_time));
- /* We're scheduling only to one core atm, so don't divide for now */
- /* status->busy_time /= NUM_JOB_SLOTS; */
+ status->busy_time = ktime_to_ns(pfdev->devfreq.busy_time);
panfrost_devfreq_reset(pfdev);
@@ -134,14 +120,10 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
{
- int i;
-
if (!pfdev->devfreq.devfreq)
return;
panfrost_devfreq_reset(pfdev);
- for (i = 0; i < NUM_JOB_SLOTS; i++)
- pfdev->devfreq.slot[i].busy = false;
devfreq_resume_device(pfdev->devfreq.devfreq);
}
@@ -154,9 +136,8 @@ void panfrost_devfreq_suspend(struct panfrost_device *pfdev)
devfreq_suspend_device(pfdev->devfreq.devfreq);
}
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev,
int slot)
+static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
{
- struct panfrost_devfreq_slot *devfreq_slot = >devfreq.slot[slot];
ktime_t now;
ktime_t last;
@@ -164,22 +145,27 @@ static void panfrost_devfreq_update_utilization(struct
panfrost_device *pfdev, i
return;
now = ktime_get();
- last = pfdev->devfreq.slot[slot].time_last_update;
+ last = pfdev->devfreq.time_last_update;
- /* If we last recorded a transition to busy, we have been idle since */
- if (devfreq_slot->busy)
- pfdev->devfreq.slot[slot].busy_time += ktime_sub(now, last);
+ if (atomic_read(>devfreq.busy_count) > 0)
+ pfdev->devfreq.busy_time += ktime_sub(now, last);
else
- pfdev->devfreq.slot[slot].idle_time += ktime_sub(now, last);
+ pfdev->devfreq.idle_time += ktime_sub(now, last);
+
+ pfdev->devfreq.time_last_update = now;
+}
- pfdev->devfreq.slot[slot].time_last_update = now;
+void panfrost_devfreq_record_busy(struct panfrost_device *pfdev)
+{
+ panfrost_devfreq_update_utilization(pfdev);
+ atomic_inc(>devfreq.busy_count);
}
[PATCH 0/2] drm/panfrost: Tidy up the devfreq implementation
The devfreq implementation in panfrost is unnecessarily open coded. It also tracks utilisation metrics per slot which isn't very useful. Let's tidy it up! This should be picked up along with Mark's change[1] to fix regulator_get_optional() misuse. This also deletes the code changes from 52282163dfa6 and e21dd290881b which would otherwise need reverting, see the previous discussion[2]. [1] https://lore.kernel.org/lkml/20190904123032.23263-1-broo...@kernel.org/ [2] https://lore.kernel.org/lkml/ccd81530-2dbd-3c02-ca0a-1085b0066...@arm.com/ Steven Price (2): drm/panfrost: Use generic code for devfreq drm/panfrost: Simplify devfreq utilisation tracking drivers/gpu/drm/panfrost/panfrost_devfreq.c | 126 ++-- drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 +- drivers/gpu/drm/panfrost/panfrost_device.h | 14 +-- drivers/gpu/drm/panfrost/panfrost_job.c | 14 +-- 4 files changed, 48 insertions(+), 109 deletions(-) -- 2.20.1
[PATCH 1/2] drm/panfrost: Use generic code for devfreq
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 62 -
drivers/gpu/drm/panfrost/panfrost_device.h | 2 -
2 files changed, 10 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index a1f5fa6a742a..7ded282a5ca8 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -18,57 +18,14 @@ static void panfrost_devfreq_update_utilization(struct
panfrost_device *pfdev, i
static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
{
- struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev));
- struct dev_pm_opp *opp;
- unsigned long old_clk_rate = pfdev->devfreq.cur_freq;
- unsigned long target_volt, target_rate;
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
int err;
- opp = devfreq_recommended_opp(dev, freq, flags);
- if (IS_ERR(opp))
- return PTR_ERR(opp);
-
- target_rate = dev_pm_opp_get_freq(opp);
- target_volt = dev_pm_opp_get_voltage(opp);
- dev_pm_opp_put(opp);
-
- if (old_clk_rate == target_rate)
- return 0;
-
- /*
-* If frequency scaling from low to high, adjust voltage first.
-* If frequency scaling from high to low, adjust frequency first.
-*/
- if (old_clk_rate < target_rate && pfdev->regulator) {
- err = regulator_set_voltage(pfdev->regulator, target_volt,
- target_volt);
- if (err) {
- dev_err(dev, "Cannot set voltage %lu uV\n",
- target_volt);
- return err;
- }
- }
-
- err = clk_set_rate(pfdev->clock, target_rate);
- if (err) {
- dev_err(dev, "Cannot set frequency %lu (%d)\n", target_rate,
- err);
- if (pfdev->regulator)
- regulator_set_voltage(pfdev->regulator,
- pfdev->devfreq.cur_volt,
- pfdev->devfreq.cur_volt);
+ err = dev_pm_opp_set_rate(dev, *freq);
+ if (err)
return err;
- }
- if (old_clk_rate > target_rate && pfdev->regulator) {
- err = regulator_set_voltage(pfdev->regulator, target_volt,
- target_volt);
- if (err)
- dev_err(dev, "Cannot set voltage %lu uV\n",
target_volt);
- }
-
- pfdev->devfreq.cur_freq = target_rate;
- pfdev->devfreq.cur_volt = target_volt;
+ *freq = clk_get_rate(pfdev->clock);
return 0;
}
@@ -88,7 +45,7 @@ static void panfrost_devfreq_reset(struct panfrost_device
*pfdev)
static int panfrost_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
- struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev));
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
int i;
for (i = 0; i < NUM_JOB_SLOTS; i++) {
@@ -121,7 +78,7 @@ static int panfrost_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq
{
struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev));
- *freq = pfdev->devfreq.cur_freq;
+ *freq = clk_get_rate(pfdev->clock);
return 0;
}
@@ -137,6 +94,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
{
int ret;
struct dev_pm_opp *opp;
+ unsigned long cur_freq;
ret = dev_pm_opp_of_add_table(>pdev->dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
@@ -146,13 +104,13 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
panfrost_devfreq_reset(pfdev);
- pfdev->devfreq.cur_freq = clk_get_rate(pfdev->clock);
+ cur_freq = clk_get_rate(pfdev->clock);
- opp = devfreq_recommended_opp(>pdev->dev,
>devfreq.cur_freq, 0);
+ opp = devfreq_recommended_opp(>pdev->dev, _freq, 0);
if (IS_ERR(opp))
return PTR_ERR(opp);
- panfrost_devfreq_profile.initial_freq = pfdev->devfreq.cur_freq;
+ panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
pfdev->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index f503c566e99f..4c2b3c84baac 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -95,8 +95,6 @@ struct panfrost_device {
struct {
[Bug 111667] gem_render_copy failing on CCS subtests
https://bugs.freedesktop.org/show_bug.cgi?id=111667 --- Comment #2 from Chris Wilson --- There is no render copyfunc for gen12. This should have bailed out at data.render_copy = igt_get_render_copyfunc(data.devid); igt_require_f(data.render_copy, "no render-copy function\n"); -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Add r8a77980 support
Hi Sergei,
On 12/09/2019 11:26, Kieran Bingham wrote:
> Hi Sergei,
>
> (pulling in +Geert for his opinion on compatible string usages)
>
> On 12/09/2019 11:00, Sergei Shtylyov wrote:> Hello!
>>
>> On 11.09.2019 22:25, Kieran Bingham wrote:
>>
>>> Add direct support for the r8a77980 (V3H).
>>>
>>> The V3H shares a common, compatible configuration with the r8a77970
>>> (V3M) so that device info structure is reused.
>>
>> Do we really need to add yet another compatible in this case?
>> I just added r8a77970 to the compatible prop in the r8a77980 DT. That's why
>> a patch like this one didn't get posted by me.
Also, the documentation at :
Documentation/devicetree/bindings/display/renesas,du.txt
already states the the "renesas,du-r8a77980" compatible string is
supported thanks to [0], so actually - this addition is a requirement to
make the driver match the documentation.
[0] 4ffe5aa53791 ("dt-bindings: display: renesas: du: document R8A77980
bindings")
>>> Signed-off-by: Kieran Bingham
>> [...]
>>
>> MBR, Sergei
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111667] gem_render_copy failing on CCS subtests
https://bugs.freedesktop.org/show_bug.cgi?id=111667 --- Comment #1 from Mika Kahola --- Test results show as ./tests/gem_render_copy IGT-Version: 1.24-g07f67caf (x86_64) (Linux: 5.3.0-rc8-CI-CI_DIS_719+ x86_64) Starting subtest: linear Subtest linear: SUCCESS (0,255s) Starting subtest: x-tiled Subtest x-tiled: SUCCESS (0,251s) Starting subtest: y-tiled Subtest y-tiled: SUCCESS (0,252s) Starting subtest: yf-tiled Subtest yf-tiled: SUCCESS (0,237s) Starting subtest: y-tiled-ccs-to-linear (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) Stack trace: #0 ../lib/igt_core.c:1674 __igt_fail_assert() #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() #2 [+0xb946f500] Subtest y-tiled-ccs-to-linear failed. DEBUG (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9 (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9 (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) (gem_render_copy:4311) igt_core-INFO: Stack trace: (gem_render_copy:4311) igt_core-INFO: #0 ../lib/igt_core.c:1674 __igt_fail_assert() (gem_render_copy:4311) igt_core-INFO: #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() (gem_render_copy:4311) igt_core-INFO: #2 [+0xb946f500] END Subtest y-tiled-ccs-to-linear: FAIL (41,146s) Starting subtest: y-tiled-ccs-to-x-tiled (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) Stack trace: #0 ../lib/igt_core.c:1674 __igt_fail_assert() #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() #2 [+0xb946f500] Subtest y-tiled-ccs-to-x-tiled failed. DEBUG (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9 (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9 (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) (gem_render_copy:4311) igt_core-INFO: Stack trace: (gem_render_copy:4311) igt_core-INFO: #0 ../lib/igt_core.c:1674 __igt_fail_assert() (gem_render_copy:4311) igt_core-INFO: #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() (gem_render_copy:4311) igt_core-INFO: #2 [+0xb946f500] END Subtest y-tiled-ccs-to-x-tiled: FAIL (46,971s) Starting subtest: y-tiled-ccs-to-y-tiled (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) Stack trace: #0 ../lib/igt_core.c:1674 __igt_fail_assert() #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() #2 [+0xb946f500] Subtest y-tiled-ccs-to-y-tiled failed. DEBUG (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9 (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9 (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) (gem_render_copy:4311) igt_core-INFO: Stack trace: (gem_render_copy:4311) igt_core-INFO: #0 ../lib/igt_core.c:1674 __igt_fail_assert() (gem_render_copy:4311) igt_core-INFO: #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() (gem_render_copy:4311) igt_core-INFO: #2 [+0xb946f500] END Subtest y-tiled-ccs-to-y-tiled: FAIL (47,999s) Starting subtest: y-tiled-ccs-to-yf-tiled (gem_render_copy:4311) CRITICAL: Test assertion failure function scratch_buf_check, file ../tests/i915/gem_render_copy.c:491: (gem_render_copy:4311) CRITICAL: Failed assertion: buf_val == ref_val (gem_render_copy:4311) CRITICAL: Expected 0xff449bbb, found 0x1006401a at (10,10) Stack trace: #0 ../lib/igt_core.c:1674 __igt_fail_assert() #1 ../tests/i915/gem_render_copy.c:479 scratch_buf_check() #2 [+0xb946f500] Subtest y-tiled-ccs-to-yf-tiled failed. DEBUG (gem_render_copy:4311) DEBUG: Test requirement passed: intel_gen(data->devid) >= 9
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296 --- Comment #18 from woodr...@posteo.de --- Similar here on a Asrock B450M Pro4 with Athlon 200GE (Raven Ridge): Screen blanks on boot a few seconds, aswell on wakeups. [0.849231] Linux agpgart interface v0.103 [0.927246] [drm] amdgpu kernel modesetting enabled. [0.927385] Parsing CRAT table with 1 nodes [0.927395] Creating topology SYSFS entries [0.927433] Topology: Add APU node [0x0:0x0] [0.927434] Finished initializing topology [0.927497] amdgpu :07:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xe000 -> 0xefff [0.927498] amdgpu :07:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xf000 -> 0xf01f [0.927499] amdgpu :07:00.0: remove_conflicting_pci_framebuffers: bar 5: 0xfcb0 -> 0xfcb7 [0.927501] amdgpu :07:00.0: vgaarb: deactivate vga console [0.928793] Console: switching to colour dummy device 80x25 [0.929058] [drm] initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x1002:0x15DD 0xCB). [0.929072] [drm] register mmio base: 0xFCB0 [0.929072] [drm] register mmio size: 524288 [0.929130] [drm] add ip block number 0 [0.929131] [drm] add ip block number 1 [0.929131] [drm] add ip block number 2 [0.929132] [drm] add ip block number 3 [0.929132] [drm] add ip block number 4 [0.929133] [drm] add ip block number 5 [0.929133] [drm] add ip block number 6 [0.929134] [drm] add ip block number 7 [0.929135] [drm] add ip block number 8 [0.929186] [drm] VCN decode is enabled in VM mode [0.929187] [drm] VCN encode is enabled in VM mode [0.929187] [drm] VCN jpeg decode is enabled in VM mode [0.952670] [drm] BIOS signature incorrect 20 7 [0.952690] ATOM BIOS: 113-RAVEN-113 [0.952723] [drm] RAS INFO: ras initialized successfully, hardware ability[0] ras_mask[0] [0.952725] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [0.952737] amdgpu :07:00.0: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [0.952738] amdgpu :07:00.0: GART: 1024M 0x - 0x3FFF [0.952739] amdgpu :07:00.0: AGP: 267419648M 0x00F8 - 0x [0.952743] [drm] Detected VRAM RAM=2048M, BAR=2048M [0.952744] [drm] RAM width 128bits DDR4 [0.952804] [TTM] Zone kernel: Available graphics memory: 7173824 KiB [0.952804] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [0.952805] [TTM] Initializing pool allocator [0.952808] [TTM] Initializing DMA pool allocator [0.952865] [drm] amdgpu: 2048M of VRAM memory ready [0.952873] [drm] amdgpu: 3072M of GTT memory ready. [0.952884] [drm] GART: num cpu pages 262144, num gpu pages 262144 [0.953019] [drm] PCIE GART of 1024M enabled (table at 0x00F40090). [0.954302] [drm] use_doorbell being set to: [true] [0.954418] [drm] Found VCN firmware Version ENC: 1.9 DEC: 1 VEP: 0 Revision: 28 [0.954428] [drm] PSP loading VCN firmware [0.975073] [drm] reserve 0x40 from 0xf400c0 for PSP TMR SIZE [1.140184] [drm] DM_PPLIB: values for F clock [1.140185] [drm] DM_PPLIB: 0 in kHz [1.140186] [drm] DM_PPLIB: 0 in kHz [1.140186] [drm] DM_PPLIB: 0 in kHz [1.140186] [drm] DM_PPLIB: 1333000 in kHz [1.140187] [ cut here ] [1.140280] WARNING: CPU: 2 PID: 199 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1401 dcn_bw_update_from_pplib.cold+0x73/0x9c [amdgpu] [1.140281] Modules linked in: amdgpu(+) gpu_sched i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart [1.140287] CPU: 2 PID: 199 Comm: modprobe Not tainted 5.2.14-arch1-1-ARCH #1 [1.140288] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.50 07/18/2019 [1.140364] RIP: 0010:dcn_bw_update_from_pplib.cold+0x73/0x9c [amdgpu] [1.140366] Code: 48 8b 93 e0 02 00 00 db 42 78 83 f9 02 77 37 b8 02 00 00 00 8d 71 ff e9 ca 2b f7 ff 48 c7 c7 98 03 3e c0 31 c0 e8 6b 67 9b e1 <0f> 0b e9 44 2c f7 ff 48 c7 c7 98 03 3e c0 31 c0 e8 56 67 9b e1 0f [1.140367] RSP: 0018:9bbc81d2f668 EFLAGS: 00010246 [1.140369] RAX: 0024 RBX: 8addc5723000 RCX: [1.140369] RDX: RSI: 0092 RDI: [1.140370] RBP: 8addc620c980 R08: 02b3 R09: 0004 [1.140370] R10: R11: 0001 R12: 9bbc81d2f708 [1.140371] R13: 0001 R14: 000a R15: [1.140372] FS: 7fb896a9e740() GS:8addd068() knlGS: [1.140373] CS: 0010 DS: ES: CR0: 80050033 [1.140373] CR2: 565204d50058 CR3: 0004060c8000 CR4: 003406e0 [1.140374] Call Trace: [1.140458] dcn10_create_resource_pool+0x983/0xa50 [amdgpu] [
Re: [PATCH 14/14] drm/amdgpu: set TMZ bits in PTEs for secure bo (v2)
On Wed, Sep 11, 2019 at 08:13:19PM +0800, Koenig, Christian wrote:
> Am 11.09.19 um 13:50 schrieb Huang, Ray:
> > From: Alex Deucher
> >
> > If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ
> > bits of
> > PTEs that belongs that bo should be set. Then psp is able to protect the
> > pages
> > of this bo to avoid the access from an "untrust" domain such as CPU.
> >
> > v1: design and draft the skeletion of tmz bits setting on PTEs (Alex)
> > v2: return failure once create secure bo on no-tmz platform (Ray)
> >
> > Signed-off-by: Alex Deucher
> > Reviewed-by: Huang Rui
> > Signed-off-by: Huang Rui
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 12 +++-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 10 ++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 +
> > 3 files changed, 26 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > index 22eab74..5332104 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > @@ -222,7 +222,8 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
> > void *data,
> > AMDGPU_GEM_CREATE_CPU_GTT_USWC |
> > AMDGPU_GEM_CREATE_VRAM_CLEARED |
> > AMDGPU_GEM_CREATE_VM_ALWAYS_VALID |
> > - AMDGPU_GEM_CREATE_EXPLICIT_SYNC))
> > + AMDGPU_GEM_CREATE_EXPLICIT_SYNC |
> > + AMDGPU_GEM_CREATE_ENCRYPTED))
> >
> > return -EINVAL;
> >
> > @@ -230,6 +231,11 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
> > void *data,
> > if (args->in.domains & ~AMDGPU_GEM_DOMAIN_MASK)
> > return -EINVAL;
> >
> > + if (!adev->tmz.enabled && (flags & AMDGPU_GEM_CREATE_ENCRYPTED)) {
> > + DRM_ERROR("Cannot allocate secure buffer while tmz is
> > disabled\n");
> > + return -EINVAL;
> > + }
> > +
> > /* create a gem object to contain this object in */
> > if (args->in.domains & (AMDGPU_GEM_DOMAIN_GDS |
> > AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
> > @@ -251,6 +257,10 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
> > void *data,
> > resv = vm->root.base.bo->tbo.resv;
> > }
> >
> > + if (flags & AMDGPU_GEM_CREATE_ENCRYPTED) {
> > + /* XXX: pad out alignment to meet TMZ requirements */
> > + }
> > +
> > r = amdgpu_gem_object_create(adev, size, args->in.alignment,
> > (u32)(0x & args->in.domains),
> > flags, ttm_bo_type_device, resv, );
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > index 5a3c177..286e2e2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > @@ -224,6 +224,16 @@ static inline bool amdgpu_bo_explicit_sync(struct
> > amdgpu_bo *bo)
> > return bo->flags & AMDGPU_GEM_CREATE_EXPLICIT_SYNC;
> > }
> >
> > +/**
> > + * amdgpu_bo_encrypted - return whether the bo is encrypted
> > + */
> > +static inline bool amdgpu_bo_encrypted(struct amdgpu_bo *bo)
> > +{
> > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > +
> > + return adev->tmz.enabled && (bo->flags & AMDGPU_GEM_CREATE_ENCRYPTED);
>
> Checking the adev->tmz.enabled flags should be dropped here.
>
That's fine. BO should be validated while it is created.
But if the BO is created by vmid 0, is this checking needed?
> > +}
> > +
> > bool amdgpu_bo_is_amdgpu_bo(struct ttm_buffer_object *bo);
> > void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain);
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 3663655..8f00bb2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -1434,6 +1434,8 @@ bool amdgpu_ttm_tt_is_readonly(struct ttm_tt *ttm)
> > uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm, struct ttm_mem_reg
> > *mem)
> > {
> > uint64_t flags = 0;
> > + struct ttm_buffer_object *tbo = ttm_mem_reg_to_bo(mem);
> > + struct amdgpu_bo *abo = ttm_to_amdgpu_bo(tbo);
>
> That's a clear NAK. The function is not necessarily called with
> >mem, which is also the reason why this function doesn't gets the BO
> as parameter.
>
Do you mean we can revise the below functions to use bo as the parameter
instead?
uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm, struct amdgpu_bo *bo)
uint64_t amdgpu_ttm_tt_pte_flags(struct ttm_tt *ttm, struct amdgpu_bo *bo)
Thanks,
Ray
> Christian.
>
> >
> > if (mem && mem->mem_type != TTM_PL_SYSTEM)
> > flags |= AMDGPU_PTE_VALID;
> > @@ -1444,6 +1446,9 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm,
> > struct ttm_mem_reg *mem)
> > if
Re: [PATCH] drm: rcar-du: Add r8a77980 support
Hi Sergei, (pulling in +Geert for his opinion on compatible string usages) On 12/09/2019 11:00, Sergei Shtylyov wrote:> Hello! > > On 11.09.2019 22:25, Kieran Bingham wrote: > >> Add direct support for the r8a77980 (V3H). >> >> The V3H shares a common, compatible configuration with the r8a77970 >> (V3M) so that device info structure is reused. > > Do we really need to add yet another compatible in this case? > I just added r8a77970 to the compatible prop in the r8a77980 DT. That's why > a patch like this one didn't get posted by me. It's not just about the compatible string for me here, There is no indication in the driver that it supports the r8a77980, and no comment in the driver to explain that the r8a77980 is shared by the r8a77970. This patch makes that explicit at the driver. Also - I am considering sending a patch (that I've already created anyway) to remove the r8a77970 reference from the arch/arm64/boot/dts/renesas/r8a77980.dtsi file. This is the *only* non r8a77980 reference in this file, so it seems very out of place. In fact more so than that - except for a seemingly glaring typo, that I'll investigate and send a patch for next, this is the *only* cross-soc compatible reference: #!/bin/sh files=r8a77*.dtsi for f in $files; do soc=`basename $f .dtsi | sed 's/-.*//'` echo "F: $f soc: $soc"; # Find all references to all socs, then hide 'this' soc grep r8a77 $f | grep -v $soc done; Finds : > F: r8a774a1.dtsi soc: r8a774a1 > F: r8a774c0.dtsi soc: r8a774c0 > F: r8a7795-es1.dtsi soc: r8a7795 > F: r8a7795.dtsi soc: r8a7795 > F: r8a7796.dtsi soc: r8a7796 > F: r8a77965.dtsi soc: r8a77965 > * Based on r8a7796.dtsi > F: r8a77970.dtsi soc: r8a77970 > compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar"; > F: r8a77980.dtsi soc: r8a77980 >"renesas,du-r8a77970"; > F: r8a77990.dtsi soc: r8a77990 > F: r8a77995.dtsi soc: r8a77995 -- KB > >> Signed-off-by: Kieran Bingham > [...] > > MBR, Sergei
Re: [PATCH] backlight: ipaq_micro: Make structure micro_bl_props constant
On Tue, Aug 13, 2019 at 02:28:55PM +0530, Nishka Dasgupta wrote:
> Static structure micro_bl_props, having type backlight_properties, is
> used only once, when it is passed as the last argument to function
> devm_backlight_device_register(). devm_backlight_device_register() is
> defined with its last parameter being declared constant. Hence make
> micro_bl_props itself constant as well.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/ipaq_micro_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/ipaq_micro_bl.c
> b/drivers/video/backlight/ipaq_micro_bl.c
> index 1123f67c12b3..85b16cc82878 100644
> --- a/drivers/video/backlight/ipaq_micro_bl.c
> +++ b/drivers/video/backlight/ipaq_micro_bl.c
> @@ -44,7 +44,7 @@ static const struct backlight_ops micro_bl_ops = {
> .update_status = micro_bl_update_status,
> };
>
> -static struct backlight_properties micro_bl_props = {
> +static const struct backlight_properties micro_bl_props = {
> .type = BACKLIGHT_RAW,
> .max_brightness = 255,
> .power = FB_BLANK_UNBLANK,
> --
> 2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Add r8a77980 support
Hello! On 11.09.2019 22:25, Kieran Bingham wrote: Add direct support for the r8a77980 (V3H). The V3H shares a common, compatible configuration with the r8a77970 (V3M) so that device info structure is reused. Do we really need to add yet another compatible in this case? I just added r8a77970 to the compatible prop in the r8a77980 DT. That's why a patch like this one didn't get posted by me. Signed-off-by: Kieran Bingham [...] MBR, Sergei
Re: [PATCH 00/11] Add support for software nodes to gpiolib
On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov wrote: > If we agree in principle, I would like to have the very first 3 patches > in an immutable branch off maybe -rc8 so that it can be pulled into > individual subsystems so that patches switching various drivers to > fwnode_gpiod_get_index() could be applied. I think it seems a bit enthusiastic to have non-GPIO subsystems pick up these changes this close to the merge window so my plan is to merge patches 1.2.3 (1 already merged) and then you could massage the other subsystems in v5.4-rc1. But if other subsystems say "hey we want do fix this in like 3 days" then I'm game for an immutable branch as well. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/2] mdev: introduce device specific ops
On Thu, Sep 12, 2019 at 05:40:12PM +0800, Jason Wang wrote:
> Currently, except for the crate and remove. The rest fields of
better:
Currently, except for create and remove, the rest of the field in ...
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev driver. So follow the device id support by previous
> patch, this patch introduces device specific ops which points to
> device specific ops (e.g vfio ops). This allows the future drivers
> like virtio-mdev to implement its own device specific ops.
>
> Signed-off-by: Jason Wang
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 14 +++---
> drivers/s390/cio/vfio_ccw_ops.c | 14 +++---
> drivers/s390/crypto/vfio_ap_ops.c | 10 +++--
> drivers/vfio/mdev/vfio_mdev.c | 30 +++--
> include/linux/mdev.h | 72 ++-
> samples/vfio-mdev/mbochs.c| 16 ---
> samples/vfio-mdev/mdpy.c | 16 ---
> samples/vfio-mdev/mtty.c | 14 +++---
> 8 files changed, 113 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 19d51a35f019..64823998fd58 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1600,20 +1600,22 @@ static const struct attribute_group
> *intel_vgpu_groups[] = {
> NULL,
> };
>
> -static struct mdev_parent_ops intel_vgpu_ops = {
> - .mdev_attr_groups = intel_vgpu_groups,
> - .create = intel_vgpu_create,
> - .remove = intel_vgpu_remove,
> -
> +static struct vfio_mdev_parent_ops intel_vfio_vgpu_ops = {
> .open = intel_vgpu_open,
> .release= intel_vgpu_release,
> -
> .read = intel_vgpu_read,
> .write = intel_vgpu_write,
> .mmap = intel_vgpu_mmap,
> .ioctl = intel_vgpu_ioctl,
> };
>
> +static struct mdev_parent_ops intel_vgpu_ops = {
> + .mdev_attr_groups = intel_vgpu_groups,
> + .create = intel_vgpu_create,
> + .remove = intel_vgpu_remove,
> + .device_ops = _vfio_vgpu_ops,
> +};
> +
> static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops)
> {
> struct attribute **kvm_type_attrs;
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index f87d9409e290..96e9f18100ae 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -564,11 +564,7 @@ static ssize_t vfio_ccw_mdev_ioctl(struct mdev_device
> *mdev,
> }
> }
>
> -static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
> - .owner = THIS_MODULE,
> - .supported_type_groups = mdev_type_groups,
> - .create = vfio_ccw_mdev_create,
> - .remove = vfio_ccw_mdev_remove,
> +static const struct vfio_mdev_parent_ops vfio_mdev_ops = {
> .open = vfio_ccw_mdev_open,
> .release= vfio_ccw_mdev_release,
> .read = vfio_ccw_mdev_read,
> @@ -576,6 +572,14 @@ static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
> .ioctl = vfio_ccw_mdev_ioctl,
> };
>
> +static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
> + .owner = THIS_MODULE,
> + .supported_type_groups = mdev_type_groups,
> + .create = vfio_ccw_mdev_create,
> + .remove = vfio_ccw_mdev_remove,
> + .device_ops = _mdev_ops,
> +};
> +
> int vfio_ccw_mdev_reg(struct subchannel *sch)
> {
> return mdev_register_vfio_device(>dev, _ccw_mdev_ops);
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index eacbde3c7a97..a48282bff066 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1280,15 +1280,19 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device
> *mdev,
> return ret;
> }
>
> +static const struct vfio_mdev_parent_ops vfio_mdev_ops = {
> + .open = vfio_ap_mdev_open,
> + .release= vfio_ap_mdev_release,
> + .ioctl = vfio_ap_mdev_ioctl,
> +};
> +
> static const struct mdev_parent_ops vfio_ap_matrix_ops = {
> .owner = THIS_MODULE,
> .supported_type_groups = vfio_ap_mdev_type_groups,
> .mdev_attr_groups = vfio_ap_mdev_attr_groups,
> .create = vfio_ap_mdev_create,
> .remove = vfio_ap_mdev_remove,
> - .open = vfio_ap_mdev_open,
> - .release= vfio_ap_mdev_release,
> - .ioctl = vfio_ap_mdev_ioctl,
> + .device_ops = _mdev_ops,
> };
>
> int vfio_ap_mdev_register(void)
> diff --git a/drivers/vfio/mdev/vfio_mdev.c
Re: [PATCH v4 8/9] drm: rcar-du: kms: Update CMM in atomic commit tail
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Update CMM settings at in the atomic commit tail helper method.
> The CMM is updated with new gamma values provided to the driver
> in the GAMMA_LUT blob property.
>
> When resuming from system suspend, the DU driver is responsible for
> reprogramming and enabling the CMM unit if it was in use at the time the
> system entered the suspend state. Force the color_mgmt_changed flag to
> true if the DRM gamma lut color transformation property was set in the
> CRTC state duplicated at suspend time, as the CMM gets reprogrammed only
> if said flag is active in the rcar_du_atomic_commit_update_cmm() method.
>
> Reviewed-by: Ulrich Hecht
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
Also throwing in an LGTM here.
Reviewed-by: Kieran Bingham
> ---
>
> Daniel could you have a look if resume bits are worth being moved to the
> DRM core? The color_mgmt_changed flag is set to false when the state is
> duplicated if I read the code correctly, but when this happens in a
> suspend/resume sequence its value should probably be restored to true if
> any color management property was set in the crtc state when system entered
> suspend.
>
> ---
>
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 20 ++
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 38 +++
> 2 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 018480a8f35c..d1003d31cfaf 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -17,6 +17,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> @@ -482,6 +483,25 @@ static int rcar_du_pm_suspend(struct device *dev)
> static int rcar_du_pm_resume(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
> + struct drm_atomic_state *state = rcdu->ddev->mode_config.suspend_state;
> + unsigned int i;
> +
> + for (i = 0; i < rcdu->num_crtcs; ++i) {
> + struct drm_crtc *crtc = >crtcs[i].crtc;
> + struct drm_crtc_state *crtc_state;
> +
> + crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> + if (!crtc_state)
> + continue;
> +
> + /*
> + * Force re-enablement of CMM after system resume if any
> + * of the DRM color transformation properties was set in
> + * the state saved at system suspend time.
> + */
> + if (crtc_state->gamma_lut)
> + crtc_state->color_mgmt_changed = true;
> + }
>
> return drm_mode_config_helper_resume(rcdu->ddev);
> }
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 294630e56992..fc30fff0eb8d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -22,6 +22,7 @@
> #include
> #include
>
> +#include "rcar_cmm.h"
> #include "rcar_du_crtc.h"
> #include "rcar_du_drv.h"
> #include "rcar_du_encoder.h"
> @@ -368,6 +369,40 @@ rcar_du_fb_create(struct drm_device *dev, struct
> drm_file *file_priv,
> * Atomic Check and Update
> */
>
> +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_state)
> +{
> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> + struct rcar_cmm_config cmm_config = {};
> + struct device *dev = rcrtc->dev->dev;
> + struct drm_property_blob *lut_blob;
> +
> + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> + return;
> +
> + if (!crtc->state->gamma_lut) {
> + cmm_config.lut.enable = false;
> + rcar_cmm_setup(rcrtc->cmm, _config);
> + return;
> + }
> +
> + lut_blob = crtc->state->gamma_lut;
> + if (lut_blob->length != (CM2_LUT_SIZE * sizeof(struct drm_color_lut))) {
> + /*
> + * We only accept fully populated LUT tables;
> + * be loud here, otherwise the CMM gets silently ignored.
> + */
> + dev_err(dev, "invalid gamma lut size of %lu bytes\n",
> + lut_blob->length);
> + return;
> + }
> +
> + cmm_config.lut.enable = true;
> + cmm_config.lut.table = (struct drm_color_lut *)lut_blob->data;
> +
> + rcar_cmm_setup(rcrtc->cmm, _config);
> +}
> +
> static int rcar_du_atomic_check(struct drm_device *dev,
> struct drm_atomic_state *state)
> {
> @@ -410,6 +445,9 @@ static void rcar_du_atomic_commit_tail(struct
> drm_atomic_state *old_state)
> rcdu->dpad1_source = rcrtc->index;
> }
>
> + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> +
> /* Apply the atomic
Re: [PATCH v4 3/9] drm: rcar-du: Add support for CMM
Hi Jacopo,
On 12/09/2019 08:59, Jacopo Mondi wrote:
> Hi Kiernan,
>thanks for review
>
> On Wed, Sep 11, 2019 at 04:54:58PM +0100, Kieran Bingham wrote:
>> Hi Jacopo,
>>
>>
>>
>> On 06/09/2019 14:43, Jacopo Mondi wrote:
>>> Add a driver for the R-Car Display Unit Color Correction Module.
>>>
>>> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
>>> to perform image enhancement and color correction.
>>>
>>> Add support for CMM through a driver that supports configuration of
>>> the 1-dimensional LUT table. More advanced CMM feature will be
>>
>> s/feature/features/
>>
>>> implemented on top of this basic one.
>>
>> s/basic/initial/
>>
>>>
>>> Signed-off-by: Jacopo Mondi
>>> ---
>>> drivers/gpu/drm/rcar-du/Kconfig| 7 +
>>> drivers/gpu/drm/rcar-du/Makefile | 1 +
>>> drivers/gpu/drm/rcar-du/rcar_cmm.c | 251 +
>>> drivers/gpu/drm/rcar-du/rcar_cmm.h | 61 +++
>>> 4 files changed, 320 insertions(+)
>>> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
>>> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/Kconfig
>> b/drivers/gpu/drm/rcar-du/Kconfig
>>> index 1529849e217e..539d232790d1 100644
>>> --- a/drivers/gpu/drm/rcar-du/Kconfig
>>> +++ b/drivers/gpu/drm/rcar-du/Kconfig
>>> @@ -13,6 +13,13 @@ config DRM_RCAR_DU
>>> Choose this option if you have an R-Car chipset.
>>> If M is selected the module will be called rcar-du-drm.
>>>
>>> +config DRM_RCAR_CMM
>>> + bool "R-Car DU Color Management Module (CMM) Support"
>>> + depends on DRM && OF
>>> + depends on DRM_RCAR_DU
>>> + help
>>> + Enable support for R-Car Color Management Module (CMM).
>>> +
>>> config DRM_RCAR_DW_HDMI
>>> tristate "R-Car DU Gen3 HDMI Encoder Support"
>>> depends on DRM && OF
>>> diff --git a/drivers/gpu/drm/rcar-du/Makefile
>> b/drivers/gpu/drm/rcar-du/Makefile
>>> index 6c2ed9c46467..4d1187ccc3e5 100644
>>> --- a/drivers/gpu/drm/rcar-du/Makefile
>>> +++ b/drivers/gpu/drm/rcar-du/Makefile
>>> @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
>>> \
>>> rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>>> rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
>>>
>>> +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
>>> obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
>>> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
>>> obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
>> b/drivers/gpu/drm/rcar-du/rcar_cmm.c
>>> new file mode 100644
>>> index ..3cacdc4474c7
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
>>> @@ -0,0 +1,251 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * rcar_cmm.c -- R-Car Display Unit Color Management Module
>>> + *
>>> + * Copyright (C) 2019 Jacopo Mondi
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include
>>> +
>>> +#include "rcar_cmm.h"
>>> +
>>> +#define CM2_LUT_CTRL 0x
>>> +#define CM2_LUT_CTRL_LUT_ENBIT(0)
>>
>> I'd have a new line here
>>
>>> +#define CM2_LUT_TBL_BASE 0x0600
>>> +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
>>> +
>>> +struct rcar_cmm {
>>> + void __iomem *base;
>>> + bool enabled;
>>> +
>>> + /*
>>> +* @lut:1D-LUT status
>>> +* @lut.enabled:1D-LUT enabled flag
>>> +* @lut.table: Table of 1D-LUT entries scaled to hardware
>>> +* precision (8-bits per color component)
>>> +*/
>>> + struct {
>>> + bool enabled;
>>> + u32 table[CM2_LUT_SIZE];
>>> + } lut;
>>> +};
>>> +
>>> +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
>>> +{
>>> + return ioread32(rcmm->base + reg);
>>> +}
>>> +
>>> +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32
>> data)
>>> +{
>>> + iowrite32(data, rcmm->base + reg);
>>> +}
>>> +
>>> +/*
>>> + * rcar_cmm_lut_extract() - Scale down to hardware precision the DRM
>> LUT table
>>> + * entries and store them.
>>> + * @rcmm: Pointer to the CMM device
>>> + * @drm_lut: Pointer to the DRM LUT table
>>> + */
>>> +static void rcar_cmm_lut_extract(struct rcar_cmm *rcmm,
>>> +const struct drm_color_lut *drm_lut)
>>> +{
>>> + unsigned int i;
>>
>> I think you're missing the following here:
>>
>> if (!drm_lut)
>> return;
>>
>> You mention below that drm_lut could be passed in as NULL, which would
>> cause a segfault here otherwise.
>>
>
> Thanks for spotting, but I should have removed that comment, as I have
> killed that case in rcar_du_atomic_commit_update_cmm() in patch 8/9,
> as from my testing it seems it is not possible to provide from
> userspace a non populated LUT table to just re-enable the CMM.
>
> So we're fine here.
Great, in that case then with the
[RFC PATCH] drm/virtio: Export resource handles via DMA-buf API
This patch is an early RFC to judge the direction we are following in
our virtualization efforts in Chrome OS. The purpose is to start a
discussion on how to handle buffer sharing between multiple virtio
devices.
On a side note, we are also working on a virtio video decoder interface
and implementation, with a V4L2 driver for Linux. Those will be posted
for review in the near future as well.
Any feedback will be appreciated! Thanks in advance.
===
With the range of use cases for virtualization expanding, there is going
to be more virtio devices added to the ecosystem. Devices such as video
decoders, encoders, cameras, etc. typically work together with the
display and GPU in a pipeline manner, which can only be implemented
efficiently by sharing the buffers between producers and consumers.
Existing buffer management framework in Linux, such as the videobuf2
framework in V4L2, implements all the DMA-buf handling inside generic
code and do not expose any low level information about the buffers to
the drivers.
To seamlessly enable buffer sharing with drivers using such frameworks,
make the virtio-gpu driver expose the resource handle as the DMA address
of the buffer returned from the DMA-buf mapping operation. Arguably, the
resource handle is a kind of DMA address already, as it is the buffer
identifier that the device needs to access the backing memory, which is
exactly the same role a DMA address provides for native devices.
A virtio driver that does memory management fully on its own would have
code similar to following. The code is identical to what a regular
driver for real hardware would do to import a DMA-buf.
static int virtio_foo_get_resource_handle(struct virtio_foo *foo,
struct dma_buf *dma_buf, u32 *id)
{
struct dma_buf_attachment *attach;
struct sg_table *sgt;
int ret = 0;
attach = dma_buf_attach(dma_buf, foo->dev);
if (IS_ERR(attach))
return PTR_ERR(attach);
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto err_detach;
}
if (sgt->nents != 1) {
ret = -EINVAL;
goto err_unmap;
}
*id = sg_dma_address(sgt->sgl);
err_unmap:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
err_detach:
dma_buf_detach(dma_buf, attach);
return ret;
}
On the other hand, a virtio driver that uses an existing kernel
framework to manage buffers would not need to explicitly handle anything
at all, as the framework part responsible for importing DMA-bufs would
already do the work. For example, a V4L2 driver using the videobuf2
framework would just call thee vb2_dma_contig_plane_dma_addr() function
to get what the above open-coded function would return.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++
drivers/gpu/drm/virtio/virtgpu_prime.c | 81 ++
3 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 0fc32fa0b3c0..ac095f813134 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -210,6 +210,8 @@ static struct drm_driver driver = {
#endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_export = virtgpu_gem_prime_export,
+ .gem_prime_import = virtgpu_gem_prime_import,
.gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
.gem_prime_vmap = virtgpu_gem_prime_vmap,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index e28829661724..687cfce91885 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -367,6 +367,10 @@ void virtio_gpu_object_free_sg_table(struct
virtio_gpu_object *bo);
int virtio_gpu_object_wait(struct virtio_gpu_object *bo, bool no_wait);
/* virtgpu_prime.c */
+struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
+int flags);
+struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *buf);
struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index dc642a884b88..562eb1a2ed5b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -22,6 +22,9 @@
* Authors: Andreas Pokorny
*/
+#include
+#include
+
#include
[RFC PATCH 0/2] Mdev: support mutiple kinds of devices
Hi all: During the development of virtio-mdev[1]. I find that mdev needs to be extended to support devices other than vfio mdev device. So this series tries to extend the mdev to be able to differ from different devices by: - device id and matching for mdev bus - device speicfic callbacks and move vfio callbacks there Sent for early reivew, compile test only! Thanks [1] https://lkml.org/lkml/2019/9/10/135 Jason Wang (2): mdev: device id support mdev: introduce device specific ops drivers/gpu/drm/i915/gvt/kvmgt.c | 16 --- drivers/s390/cio/vfio_ccw_ops.c | 16 --- drivers/s390/crypto/vfio_ap_ops.c | 13 -- drivers/vfio/mdev/mdev_core.c | 14 +- drivers/vfio/mdev/mdev_driver.c | 14 ++ drivers/vfio/mdev/mdev_private.h | 1 + drivers/vfio/mdev/vfio_mdev.c | 36 ++- include/linux/mdev.h | 76 +++ include/linux/mod_devicetable.h | 6 +++ samples/vfio-mdev/mbochs.c| 18 +--- samples/vfio-mdev/mdpy.c | 18 +--- samples/vfio-mdev/mtty.c | 16 --- 12 files changed, 163 insertions(+), 81 deletions(-) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/2] mdev: introduce device specific ops
Currently, except for the crate and remove. The rest fields of
mdev_parent_ops is just designed for vfio-mdev driver and may not help
for kernel mdev driver. So follow the device id support by previous
patch, this patch introduces device specific ops which points to
device specific ops (e.g vfio ops). This allows the future drivers
like virtio-mdev to implement its own device specific ops.
Signed-off-by: Jason Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 14 +++---
drivers/s390/cio/vfio_ccw_ops.c | 14 +++---
drivers/s390/crypto/vfio_ap_ops.c | 10 +++--
drivers/vfio/mdev/vfio_mdev.c | 30 +++--
include/linux/mdev.h | 72 ++-
samples/vfio-mdev/mbochs.c| 16 ---
samples/vfio-mdev/mdpy.c | 16 ---
samples/vfio-mdev/mtty.c | 14 +++---
8 files changed, 113 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 19d51a35f019..64823998fd58 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1600,20 +1600,22 @@ static const struct attribute_group
*intel_vgpu_groups[] = {
NULL,
};
-static struct mdev_parent_ops intel_vgpu_ops = {
- .mdev_attr_groups = intel_vgpu_groups,
- .create = intel_vgpu_create,
- .remove = intel_vgpu_remove,
-
+static struct vfio_mdev_parent_ops intel_vfio_vgpu_ops = {
.open = intel_vgpu_open,
.release= intel_vgpu_release,
-
.read = intel_vgpu_read,
.write = intel_vgpu_write,
.mmap = intel_vgpu_mmap,
.ioctl = intel_vgpu_ioctl,
};
+static struct mdev_parent_ops intel_vgpu_ops = {
+ .mdev_attr_groups = intel_vgpu_groups,
+ .create = intel_vgpu_create,
+ .remove = intel_vgpu_remove,
+ .device_ops = _vfio_vgpu_ops,
+};
+
static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops)
{
struct attribute **kvm_type_attrs;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index f87d9409e290..96e9f18100ae 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -564,11 +564,7 @@ static ssize_t vfio_ccw_mdev_ioctl(struct mdev_device
*mdev,
}
}
-static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
- .owner = THIS_MODULE,
- .supported_type_groups = mdev_type_groups,
- .create = vfio_ccw_mdev_create,
- .remove = vfio_ccw_mdev_remove,
+static const struct vfio_mdev_parent_ops vfio_mdev_ops = {
.open = vfio_ccw_mdev_open,
.release= vfio_ccw_mdev_release,
.read = vfio_ccw_mdev_read,
@@ -576,6 +572,14 @@ static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
.ioctl = vfio_ccw_mdev_ioctl,
};
+static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
+ .owner = THIS_MODULE,
+ .supported_type_groups = mdev_type_groups,
+ .create = vfio_ccw_mdev_create,
+ .remove = vfio_ccw_mdev_remove,
+ .device_ops = _mdev_ops,
+};
+
int vfio_ccw_mdev_reg(struct subchannel *sch)
{
return mdev_register_vfio_device(>dev, _ccw_mdev_ops);
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index eacbde3c7a97..a48282bff066 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1280,15 +1280,19 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device
*mdev,
return ret;
}
+static const struct vfio_mdev_parent_ops vfio_mdev_ops = {
+ .open = vfio_ap_mdev_open,
+ .release= vfio_ap_mdev_release,
+ .ioctl = vfio_ap_mdev_ioctl,
+};
+
static const struct mdev_parent_ops vfio_ap_matrix_ops = {
.owner = THIS_MODULE,
.supported_type_groups = vfio_ap_mdev_type_groups,
.mdev_attr_groups = vfio_ap_mdev_attr_groups,
.create = vfio_ap_mdev_create,
.remove = vfio_ap_mdev_remove,
- .open = vfio_ap_mdev_open,
- .release= vfio_ap_mdev_release,
- .ioctl = vfio_ap_mdev_ioctl,
+ .device_ops = _mdev_ops,
};
int vfio_ap_mdev_register(void)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 887c57f10880..1196fbb6c3d2 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -25,15 +25,16 @@ static int vfio_mdev_open(void *device_data)
{
struct mdev_device *mdev = device_data;
struct mdev_parent *parent =
[RFC PATCH 1/2] mdev: device id support
Mdev bus only support vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
one example is virtio-mdev[1] driver. This means we need to add device
id support in bus match method to pair the mdev device and mdev driver
correctly.
So this patch add id_table to mdev_driver and id for mdev parent, and
implement the match method for mdev bus.
[1] https://lkml.org/lkml/2019/9/10/135
Signed-off-by: Jason Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/s390/cio/vfio_ccw_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
drivers/vfio/mdev/mdev_core.c | 14 --
drivers/vfio/mdev/mdev_driver.c | 14 ++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 ++
include/linux/mdev.h | 6 +-
include/linux/mod_devicetable.h | 6 ++
samples/vfio-mdev/mbochs.c| 2 +-
samples/vfio-mdev/mdpy.c | 2 +-
samples/vfio-mdev/mtty.c | 2 +-
12 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 23aa3e50cbf8..19d51a35f019 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1625,7 +1625,7 @@ static int kvmgt_host_init(struct device *dev, void *gvt,
const void *ops)
return -EFAULT;
intel_vgpu_ops.supported_type_groups = kvm_vgpu_type_groups;
- return mdev_register_device(dev, _vgpu_ops);
+ return mdev_register_vfio_device(dev, _vgpu_ops);
}
static void kvmgt_host_exit(struct device *dev)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 5eb61116ca6f..f87d9409e290 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -578,7 +578,7 @@ static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
int vfio_ccw_mdev_reg(struct subchannel *sch)
{
- return mdev_register_device(>dev, _ccw_mdev_ops);
+ return mdev_register_vfio_device(>dev, _ccw_mdev_ops);
}
void vfio_ccw_mdev_unreg(struct subchannel *sch)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 0604b49a4d32..eacbde3c7a97 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1295,7 +1295,8 @@ int vfio_ap_mdev_register(void)
{
atomic_set(_dev->available_instances, MAX_ZDEV_ENTRIES_EXT);
- return mdev_register_device(_dev->device, _ap_matrix_ops);
+ return mdev_register_vfio_device(_dev->device,
+_ap_matrix_ops);
}
void vfio_ap_mdev_unregister(void)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..fc07ff3ebe96 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -135,11 +135,14 @@ static int mdev_device_remove_cb(struct device *dev, void
*data)
* mdev_register_device : Register a device
* @dev: device structure representing parent device.
* @ops: Parent device operation structure to be registered.
+ * @id: device id.
*
* Add device to list of registered parent devices.
* Returns a negative value on error, otherwise 0.
*/
-int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops)
+int mdev_register_device(struct device *dev,
+const struct mdev_parent_ops *ops,
+u8 id)
{
int ret;
struct mdev_parent *parent;
@@ -175,6 +178,7 @@ int mdev_register_device(struct device *dev, const struct
mdev_parent_ops *ops)
parent->dev = dev;
parent->ops = ops;
+ parent->device_id = id;
if (!mdev_bus_compat_class) {
mdev_bus_compat_class = class_compat_register("mdev_bus");
@@ -208,7 +212,13 @@ int mdev_register_device(struct device *dev, const struct
mdev_parent_ops *ops)
put_device(dev);
return ret;
}
-EXPORT_SYMBOL(mdev_register_device);
+
+int mdev_register_vfio_device(struct device *dev,
+ const struct mdev_parent_ops *ops)
+{
+ return mdev_register_device(dev, ops, MDEV_ID_VFIO);
+}
+EXPORT_SYMBOL(mdev_register_vfio_device);
/*
* mdev_unregister_device : Unregister a parent device
diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c
index 0d3223aee20b..fd5e9541d18e 100644
--- a/drivers/vfio/mdev/mdev_driver.c
+++ b/drivers/vfio/mdev/mdev_driver.c
@@ -69,8 +69,22 @@ static int mdev_remove(struct device *dev)
return 0;
}
+static int mdev_match(struct device *dev, struct device_driver *drv)
+{
+ unsigned int i;
+ struct mdev_device *mdev = to_mdev_device(dev);
+ struct mdev_driver *mdrv = to_mdev_driver(drv);
+ const struct mdev_device_id *ids = mdrv->id_table;
+
+ for (i = 0; ids[i].id; i++)
+ if (ids[i].id == mdev->parent->device_id)
+
Re: [PATCH v3 2/2] backlight: lm3630a: add an enable gpio for the HWEN pin
On Wed, Sep 11, 2019 at 07:21:06PM +0200, Andreas Kemnade wrote:
> For now just enable it in the probe function to allow i2c
> access. Disabling also means resetting the register values
> to default and according to the datasheet does not give
> power savings.
>
> Tested on Kobo Clara HD.
>
> Signed-off-by: Andreas Kemnade
Make sure Dan is happy w.r.t. his review comments but if this driver is
unchanged when you spin v4 (for the DT changes) then feel free to add:
Reviewed-by: Daniel Thompson
Daniel.
> ---
> changes in v2:
> - simplification
> - correct gpio direction initialisation
>
> changes in v3:
> - removed legacy include
>
> drivers/video/backlight/lm3630a_bl.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c
> b/drivers/video/backlight/lm3630a_bl.c
> index 8f84f3684f04..d9e67b9b2571 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -48,6 +49,7 @@ struct lm3630a_chip {
> struct lm3630a_platform_data *pdata;
> struct backlight_device *bleda;
> struct backlight_device *bledb;
> + struct gpio_desc *enable_gpio;
> struct regmap *regmap;
> struct pwm_device *pwmd;
> };
> @@ -535,6 +537,13 @@ static int lm3630a_probe(struct i2c_client *client,
> }
> pchip->pdata = pdata;
>
> + pchip->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(pchip->enable_gpio)) {
> + rval = PTR_ERR(pchip->enable_gpio);
> + return rval;
> + }
> +
> /* chip initialize */
> rval = lm3630a_chip_init(pchip);
> if (rval < 0) {
> --
> 2.20.1
>
Re: [RESEND PATCH] drm/panfrost: Reduce the amount of logs on deferred probe
On 09/09/2019 16:51, Krzysztof Kozlowski wrote:
> There is no point to print deferred probe (and its failures to get
> resources) as an error.
>
> In case of multiple probe tries this would pollute the dmesg.
>
> Signed-off-by: Krzysztof Kozlowski
Looks like a good idea, however from what I can tell you haven't
completely silenced the 'error' as the return from
panfrost_regulator_init() will be -EPROBE_DEFER causing another
dev_err() output:
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
goto err_out0;
}
Can you fix that up as well? Or indeed drop it altogether since
panfrost_regulator_init() already outputs an appropriate message.
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
> b/drivers/gpu/drm/panfrost/panfrost_device.c
> index 46b0b02e4289..2252147bc285 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> @@ -95,7 +95,9 @@ static int panfrost_regulator_init(struct panfrost_device
> *pfdev)
> pfdev->regulator = NULL;
> if (ret == -ENODEV)
> return 0;
> - dev_err(pfdev->dev, "failed to get regulator: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(pfdev->dev, "failed to get regulator: %d\n",
> + ret);
> return ret;
> }
>
>
Re: [PATCH v4 5/9] drm: rcar-du: kms: Initialize CMM instances
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Implement device tree parsing to collect the available CMM instances
> described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
> store a mask of active CMMs in the DU group for later enablement.
>
> Enforce the probe and suspend/resume ordering of DU and CMM by creating
> a stateless device link between the two.
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +++
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 68 +
> 5 files changed, 80 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 2da46e3dc4ae..23f1d6cc1719 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int swindex,
> if (ret < 0)
> return ret;
>
> + /* CMM might be disabled for this CRTC. */
> + if (rcdu->cmms[swindex]) {
> + rcrtc->cmm = rcdu->cmms[swindex];
> + rgrp->cmms_mask |= BIT(hwindex % 2);
> + }
> +
Good - this checks out :-D
> drm_crtc_helper_add(crtc, _helper_funcs);
>
> /* Start with vertical blanking interrupt reporting disabled. */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 3b7fc668996f..5f2940c42225 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -39,6 +39,7 @@ struct rcar_du_vsp;
> * @vblank_wait: wait queue used to signal vertical blanking
> * @vblank_count: number of vertical blanking interrupts to wait for
> * @group: CRTC group this CRTC belongs to
> + * @cmm: CMM associated with this CRTC
> * @vsp: VSP feeding video to this CRTC
> * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
> * @writeback: the writeback connector
> @@ -64,6 +65,7 @@ struct rcar_du_crtc {
> unsigned int vblank_count;
>
> struct rcar_du_group *group;
> + struct platform_device *cmm;
> struct rcar_du_vsp *vsp;
> unsigned int vsp_pipe;
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index a00dccc447aa..6316a1c5236c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -13,6 +13,7 @@
> #include
> #include
>
> +#include "rcar_cmm.h"
> #include "rcar_du_crtc.h"
> #include "rcar_du_group.h"
> #include "rcar_du_vsp.h"
> @@ -86,6 +87,7 @@ struct rcar_du_device {
> struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
>
> struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
> + struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
> struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
>
> struct {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> index 87950c1f6a52..e9906609c635 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> @@ -22,6 +22,7 @@ struct rcar_du_device;
> * @mmio_offset: registers offset in the device memory map
> * @index: group index
> * @channels_mask: bitmask of populated DU channels in this group
> + * @cmms_mask: bitmask of available CMMs in this group
> * @num_crtcs: number of CRTCs in this group (1 or 2)
> * @use_count: number of users of the group (rcar_du_group_(get|put))
> * @used_crtcs: number of CRTCs currently in use
> @@ -37,6 +38,7 @@ struct rcar_du_group {
> unsigned int index;
>
> unsigned int channels_mask;
> + unsigned int cmms_mask;
> unsigned int num_crtcs;
> unsigned int use_count;
> unsigned int used_crtcs;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 2dc9caee8767..294630e56992 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -17,7 +17,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
> #include
>
> #include "rcar_du_crtc.h"
> @@ -614,6 +616,67 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> return ret;
> }
>
> +static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> +{
> + const struct device_node *np = rcdu->dev->of_node;
> + unsigned int i;
> + int cells;
> +
> + cells = of_property_count_u32_elems(np, "renesas,cmms");
> + if (cells == -EINVAL)
> + return 0;
> +
> + if (cells > rcdu->num_crtcs) {
> + dev_err(rcdu->dev,
> + "Invalid number of entries in 'renesas,cmms'\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i <
Re: [PATCH v4 6/9] drm: rcar-du: crtc: Enable and disable CMMs
Hi Jacopo,
On 12/09/2019 09:07, Jacopo Mondi wrote:
> Hi Kieran,
>
> On Wed, Sep 11, 2019 at 07:40:27PM +0100, Kieran Bingham wrote:
>> Hi Jacopo,
>>
>> On 06/09/2019 14:54, Jacopo Mondi wrote:
>>> Enable/disable the CMM associated with a CRTC at CRTC start and stop
>>> time and enable the CMM unit through the Display Extensional Functions
>>> register at group setup time.
>>>
>>> Reviewed-by: Ulrich Hecht
>>> Reviewed-by: Laurent Pinchart
>>> Signed-off-by: Jacopo Mondi
>>> ---
>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +++
>>> drivers/gpu/drm/rcar-du/rcar_du_group.c | 8
>>> drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 +
>>> 3 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>>> index 23f1d6cc1719..3dac605c3a67 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>>> @@ -21,6 +21,7 @@
>>> #include
>>> #include
>>>
>>> +#include "rcar_cmm.h"
>>> #include "rcar_du_crtc.h"
>>> #include "rcar_du_drv.h"
>>> #include "rcar_du_encoder.h"
>>> @@ -619,6 +620,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc
>>> *rcrtc)
>>> if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
>>> rcar_du_vsp_disable(rcrtc);
>>>
>>> + if (rcrtc->cmm)
>>> + rcar_cmm_disable(rcrtc->cmm);
>>> +
>>> /*
>>> * Select switch sync mode. This stops display operation and configures
>>> * the HSYNC and VSYNC signals as inputs.
>>> @@ -686,6 +690,9 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
>>> *crtc,
>>> }
>>>
>>> rcar_du_crtc_start(rcrtc);
>>> +
>>> + if (rcrtc->cmm)
>>> + rcar_cmm_enable(rcrtc->cmm);
>>> }
>>>
>>> static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
>>> b/drivers/gpu/drm/rcar-du/rcar_du_group.c
>>> index 9eee47969e77..25d0fc125d7a 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
>>> @@ -147,6 +147,14 @@ static void rcar_du_group_setup(struct rcar_du_group
>>> *rgrp)
>>>
>>> rcar_du_group_setup_pins(rgrp);
>>>
>>> + if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CMM)) {
>>> + u32 defr7 = DEFR7_CODE
>>> + | (rgrp->cmms_mask & BIT(1) ? DEFR7_CMME1 : 0)
>>> + | (rgrp->cmms_mask & BIT(0) ? DEFR7_CMME0 : 0);
>>> +
>>> + rcar_du_group_write(rgrp, DEFR7, defr7);
>>> + }
>>> +
>>
>> What's the effect here on platforms with a CMM, but with
>> CONFIG_DRM_RCAR_CMM unset?
>>
>> Will this incorrectly configure the DU ?
>>
>> Will it stall the display if the DU tries to interact with another
>> module which is not enabled?
>
> I recall I tested that (that's why I had to add stubs for CMM
> functions, as I had linkage errors otherwise) and thing seems to be
> fine as the CMM configuration/enblement resolve to an empty function.
Yes, I see the stubs to allow for linkage, but it's the hardware I'm
concerned about. If it passes the tests and doesn't break then that's
probably ok ... but I'm really weary that we're enabling a hardware
pipeline with a disabled component in the middle.
> Would you prefer to have this guarded by an #if IS_ENABLED() ?
I don't think we need a compile time conditional, but I'd say it
probably needs to be more about whether the CMM has actually probed or not
Aha, and I see that in rcar_du_cmm_init() we already do a
call to rcar_cmm_init(), which if fails will leave rcdu->cmms[i] as
NULL. So that's catered for, which results in the rgrp->cmms_mask being
correctly representative of whether there is a CMM connected or not.
... so I think that means the ...
"if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CMM))" is somewhat redundant:
This could be:
if (rgrp->cmms_mask) {
u32 defr7 = DEFR7_CODE
| (rgrp->cmms_mask & BIT(1) ? DEFR7_CMME1 : 0)
| (rgrp->cmms_mask & BIT(0) ? DEFR7_CMME0 : 0);
rcar_du_group_write(rgrp, DEFR7, defr7);
Or in fact, if we don't mind writing 0 to DEFR7 when there is no CMM
(which is safe by the looks of things as DEFR7 is available on all
platforms), then we can even remove the outer conditional, and leave
this all up to the ternary operators to write the correct value to the
defr7.
Phew ... net result - your current code *is* safe with the
CONFIG_DRM_RCAR_CMM option disabled. I'll leave it up to you if you want
to simplify the code here and remove the RCAR_DU_FEATURE_CMM.
As this RCAR_DU_FEATURE_CMM flag is only checked here, removing it would
however simplify all of the rcar_du_device_info structures.
So - with or without the _FEATURE_CMM" simplification, this patch looks
functional and safe so:
Reviewed-by: Kieran Bingham
> Thanks
>j
>>
>>
>>> if (rcdu->info->gen >= 2) {
>>> rcar_du_group_setup_defr8(rgrp);
>>> rcar_du_group_setup_didsr(rgrp);
>>> diff --git
Re: [PATCH v2 2/2] backlight: lm3630a: add an enable gpio for the HWEN pin
On Wed, Sep 11, 2019 at 01:48:36PM -0500, Dan Murphy wrote:
>
> On 9/11/19 5:25 AM, Daniel Thompson wrote:
> > On Tue, Sep 10, 2019 at 11:29:09PM +0200, Andreas Kemnade wrote:
> > > For now just enable it in the probe function to allow i2c
> > > access. Disabling also means resetting the register values
> > > to default and according to the datasheet does not give
> > > power savings
> > >
> > > Tested on Kobo Clara HD.
> > >
> > > Signed-off-by: Andreas Kemnade
> > > ---
> > > changes in v2:
> > > - simplification
> > > - correct gpio direction initialisation
> > >
> > > drivers/video/backlight/lm3630a_bl.c | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/video/backlight/lm3630a_bl.c
> > > b/drivers/video/backlight/lm3630a_bl.c
> > > index 8f84f3684f04..9d0639d4202d 100644
> > > --- a/drivers/video/backlight/lm3630a_bl.c
> > > +++ b/drivers/video/backlight/lm3630a_bl.c
> > > @@ -12,6 +12,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > Nitpicking... but I don't think linux/gpio.h is used anymore.
> >
> >
> > > #include
> > > #include
> > > @@ -48,6 +50,7 @@ struct lm3630a_chip {
> > > struct lm3630a_platform_data *pdata;
> > > struct backlight_device *bleda;
> > > struct backlight_device *bledb;
> > > + struct gpio_desc *enable_gpio;
> > > struct regmap *regmap;
> > > struct pwm_device *pwmd;
> > > };
> > > @@ -535,6 +538,13 @@ static int lm3630a_probe(struct i2c_client *client,
> > > }
> > > pchip->pdata = pdata;
> > > + pchip->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(pchip->enable_gpio)) {
> > > + rval = PTR_ERR(pchip->enable_gpio);
> > > + return rval;
>
> the enable gpio is optional so if it fails you log the error and move on
Isn't the effect of this to cope gracefully if enable-gpios is absent
but to fail with an error if enable-gpios exists and is broken. I
thought this code pattern is fairly common.
> Also on driver removal did you want to set the GPIO to low to disable the
> device to save power?
As it happens I offered to opposite feedback for v1:
https://lists.freedesktop.org/archives/dri-devel/2019-September/234918.html
Basically if the power matters then we should take care of things in the
PM code path (which for this driver means reacting properly to
suspended flag when updating the brightness). If the power doesn't matter
then, given unallocated GPIO pins are in an unknown state anyway, there
is no point in tidying up because we don't know what value to restore.
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panel: panel-innolux: Add support for P097PFZ behind SSD2858
Add driver to setup P097PFZ behing SSD2858 (4 to 8 lanes bridge).
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 103 +-
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 8db404fb5eeb..a658ccba30a0 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -138,7 +138,7 @@ static int innolux_panel_prepare(struct drm_panel *panel)
if (!innolux->enable_gpio[i])
break;
- /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
+ /* p079zca: t2 (20ms), p097pfg: t4 (15ms); ssd2858: 20ms */
usleep_range(2, 21000);
gpiod_set_value_cansleep(innolux->enable_gpio[i], 1);
}
@@ -162,6 +162,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
goto poweroff;
}
+ /*
+* If the command list contains exit sleep mode or set
+* display on, wait the appropriate time (needed for
+* displays behind a bridge).
+*/
+ /* T6: 120ms - 1000ms*/
+ if (cmd->data[0] == MIPI_DCS_EXIT_SLEEP_MODE)
+ msleep(120);
+/* T7: 5ms */
+ if (cmd->data[0] == MIPI_DCS_SET_DISPLAY_ON)
+ usleep_range(5000, 6000);
+
/*
* Included by random guessing, because without this
* (or at least, some delay), the panel sometimes
@@ -410,6 +422,92 @@ static const struct panel_desc innolux_p097pfg_panel_desc
= {
.sleep_mode_delay = 100, /* T15 */
};
+static const char * const innolux_p097pfg_ssd2858_supply_names[] = {
+ "avdd",
+ "avee",
+ "pp1800",
+ "pp3300",
+ "pp1200-bridge",
+ "vddio-bridge",
+};
+
+static const struct drm_display_mode innolux_p097pfg_ssd2858_mode = {
+ .clock = 211660,
+ .hdisplay = 1536,
+ .hsync_start = 1536 + 140,
+ .hsync_end = 1536 + 140 + 10,
+ .htotal = 1536 + 140 + 10 + 10,
+ .vdisplay = 2048,
+ .vsync_start = 2048 + 20,
+ .vsync_end = 2048 + 20 + 2,
+ .vtotal = 2048 + 20 + 2 + 10,
+ .vrefresh = 60,
+};
+
+static const struct panel_init_cmd innolux_p097pfg_ssd2858_init_cmds[] = {
+ /* SSD2858 config */
+ _INIT_CMD(0xff, 0x00),
+ /* LOCKCNT=0x1f4, MRX=0, POSTDIV=1 (/2), MULT=0x49
+* 27 Mhz => 985.5 Mhz
+*/
+ _INIT_CMD(0x00, 0x08, 0x01, 0xf4, 0x01, 0x49),
+ /* MTXDIV=1, SYSDIV=3 (=> 4) */
+ _INIT_CMD(0x00, 0x0c, 0x00, 0x00, 0x00, 0x03),
+ /* MTXVPF=24bpp, MRXLS=4 lanes, MRXVB=bypass, MRXECC=1, MRXEOT=1
+* MRXEE=1
+*/
+ _INIT_CMD(0x00, 0x14, 0x0c, 0x3d, 0x80, 0x0f),
+ _INIT_CMD(0x00, 0x20, 0x15, 0x92, 0x56, 0x7d),
+ _INIT_CMD(0x00, 0x24, 0x00, 0x00, 0x30, 0x00),
+
+ _INIT_CMD(0x10, 0x08, 0x01, 0x20, 0x08, 0x45),
+ _INIT_CMD(0x10, 0x1c, 0x00, 0x00, 0x00, 0x00),
+ _INIT_CMD(0x20, 0x0c, 0x00, 0x00, 0x00, 0x04),
+ /* Pixel clock 985.5 Mhz * 0x49/0x4b = 959 Mhz */
+ _INIT_CMD(0x20, 0x10, 0x00, 0x4b, 0x00, 0x49),
+ _INIT_CMD(0x20, 0xa0, 0x00, 0x00, 0x00, 0x00),
+ /* EOT=1, LPE = 0, LSOUT=4 lanes, LPD=25 */
+ _INIT_CMD(0x60, 0x08, 0x00, 0xd9, 0x00, 0x08),
+ _INIT_CMD(0x60, 0x14, 0x01, 0x00, 0x01, 0x06),
+ /* DSI0 enable (default: probably not needed) */
+ _INIT_CMD(0x60, 0x80, 0x00, 0x00, 0x00, 0x0f),
+ /* DSI1 enable */
+ _INIT_CMD(0x60, 0xa0, 0x00, 0x00, 0x00, 0x0f),
+
+ /* HSA=0x18, VSA=0x02, HBP=0x50, VBP=0x0c */
+ _INIT_CMD(0x60, 0x0c, 0x0c, 0x50, 0x02, 0x18),
+ /* VACT= 0x800 (2048), VFP= 0x14, HFP=0x50 */
+ _INIT_CMD(0x60, 0x10, 0x08, 0x00, 0x14, 0x50),
+ /* HACT=0x300 (768) */
+ _INIT_CMD(0x60, 0x84, 0x00, 0x00, 0x03, 0x00),
+ _INIT_CMD(0x60, 0xa4, 0x00, 0x00, 0x03, 0x00),
+
+ /* Take panel out of sleep. */
+ _INIT_CMD(0xff, 0x01),
+ _INIT_CMD(0x11),
+ _INIT_CMD(0x29),
+ _INIT_CMD(0xff, 0x00),
+
+ {},
+};
+
+static const struct panel_desc innolux_p097pfg_ssd2858_panel_desc = {
+ .mode = _p097pfg_ssd2858_mode,
+ .bpc = 8,
+ .size = {
+ .width = 147,
+ .height = 196,
+ },
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+ .init_cmds = innolux_p097pfg_ssd2858_init_cmds,
+ .lanes = 4,
+ .supply_names = innolux_p097pfg_ssd2858_supply_names,
+ .num_supplies = ARRAY_SIZE(innolux_p097pfg_ssd2858_supply_names),
+
[PATCH 1/3] drm/panel: panel-innolux: Allow 2 reset pins for panel
This is useful when there is a bridge between the SoC and the
panel.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index d92d1c98878c..8db404fb5eeb 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -54,7 +54,7 @@ struct innolux_panel {
struct backlight_device *backlight;
struct regulator_bulk_data *supplies;
- struct gpio_desc *enable_gpio;
+ struct gpio_desc *enable_gpio[2];
bool prepared;
bool enabled;
@@ -82,7 +82,7 @@ static int innolux_panel_disable(struct drm_panel *panel)
static int innolux_panel_unprepare(struct drm_panel *panel)
{
struct innolux_panel *innolux = to_innolux_panel(panel);
- int err;
+ int err, i;
if (!innolux->prepared)
return 0;
@@ -102,7 +102,8 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
if (innolux->desc->sleep_mode_delay)
msleep(innolux->desc->sleep_mode_delay);
- gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+ for (i = 0; i < ARRAY_SIZE(innolux->enable_gpio); i++)
+ gpiod_set_value_cansleep(innolux->enable_gpio[i], 0);
if (innolux->desc->power_down_delay)
msleep(innolux->desc->power_down_delay);
@@ -120,22 +121,27 @@ static int innolux_panel_unprepare(struct drm_panel
*panel)
static int innolux_panel_prepare(struct drm_panel *panel)
{
struct innolux_panel *innolux = to_innolux_panel(panel);
- int err;
+ int err, i;
if (innolux->prepared)
return 0;
- gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+ for (i = 0; i < ARRAY_SIZE(innolux->enable_gpio); i++)
+ gpiod_set_value_cansleep(innolux->enable_gpio[i], 0);
err = regulator_bulk_enable(innolux->desc->num_supplies,
innolux->supplies);
if (err < 0)
return err;
- /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
- usleep_range(2, 21000);
+ for (i = 0; i < ARRAY_SIZE(innolux->enable_gpio); i++) {
+ if (!innolux->enable_gpio[i])
+ break;
- gpiod_set_value_cansleep(innolux->enable_gpio, 1);
+ /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
+ usleep_range(2, 21000);
+ gpiod_set_value_cansleep(innolux->enable_gpio[i], 1);
+ }
/* p079zca: t4, p097pfg: t5 */
usleep_range(2, 21000);
@@ -195,7 +201,8 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
poweroff:
- gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+ for (i = 0; i < ARRAY_SIZE(innolux->enable_gpio); i++)
+ gpiod_set_value_cansleep(innolux->enable_gpio[i], 0);
regulator_bulk_disable(innolux->desc->num_supplies, innolux->supplies);
return err;
@@ -475,12 +482,14 @@ static int innolux_panel_add(struct mipi_dsi_device *dsi,
if (err < 0)
return err;
- innolux->enable_gpio = devm_gpiod_get_optional(dev, "enable",
- GPIOD_OUT_HIGH);
- if (IS_ERR(innolux->enable_gpio)) {
- err = PTR_ERR(innolux->enable_gpio);
- dev_dbg(dev, "failed to get enable gpio: %d\n", err);
- innolux->enable_gpio = NULL;
+ for (i = 0; i < ARRAY_SIZE(innolux->enable_gpio); i++) {
+ innolux->enable_gpio[i] = devm_gpiod_get_index_optional(dev,
+ "enable", i, GPIOD_OUT_HIGH);
+ if (IS_ERR(innolux->enable_gpio[i])) {
+ err = PTR_ERR(innolux->enable_gpio[i]);
+ dev_err(dev, "failed to get enable gpio: %d\n", err);
+ innolux->enable_gpio[i] = NULL;
+ }
}
innolux->backlight = devm_of_find_backlight(dev);
--
2.21.0
[PATCH 2/3] dt-bindings: display: Add documentation for innolux, p097pfg_ssd2858 panel
This adds documentation for innolux,p097pfg panel with bridge chip
ssd2858.
Signed-off-by: Jitao Shi
---
.../display/panel/innolux,p097pfg_ssd2858.txt | 39 +++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,p097pfg_ssd2858.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg_ssd2858.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg_ssd2858.txt
new file mode 100644
index ..4ce55e889ad2
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg_ssd2858.txt
@@ -0,0 +1,39 @@
+SSD2858 bridge + Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p097pfg_ssd2858"
+- reg: DSI virtual channel of the peripheral
+- avdd-supply: phandle of the regulator that provides panel positive voltage
+- avee-supply: phandle of the regulator that provides panel negative voltage
+- pp1800-supply: phandle of the regulator that provides panel 1.8V IO power
+- pp3300-supply: phandle of the regulator that provides ssd2858 3.3V URAM power
+- pp1200-bridge-supply: phandle of the regulator that provides ssd2858 1.2V
core power
+- vddio-bridge-supply: phandle of the regulator that provides ssd2858 1.8V IO
power
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+{
+ panel: panel@0 {
+ compatible = "innolux,p097pfg_ssd2858";
+ reg = <0>;
+ enable-gpios = < 45 0 73 0>;
+ avdd-supply = <...>;
+ avee-supply = <...>;
+ pp1800-supply = <...>;
+ pp3300-supply = <...>;
+ pp1200-bridge-supply = <...>;
+ vddio-bridge-supply = <...>;
+ backlight = <_lcd0>;
+ status = "okay";
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ };
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] add panel driver for innolux,p097pfg with ssd2825 bridge
Add driver to support panel innolux,p097pfg with bridge ssd2858. SSD2858 can spilt dsi 4 lanes to 8 lanes. Jitao Shi (3): drm/panel: panel-innolux: Allow 2 reset pins for panel dt-bindings: display: Add documentation for innolux,p097pfg_ssd2858 panel drm/panel: panel-innolux: Add support for P097PFZ behind SSD2858 .../display/panel/innolux,p097pfg_ssd2858.txt | 39 + drivers/gpu/drm/panel/panel-innolux-p079zca.c | 140 -- 2 files changed, 164 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,p097pfg_ssd2858.txt -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: dsi: higher pll out only in video burst mode
In order to better support video non-burst modes,
the +20% on pll out is added only in burst mode.
Signed-off-by: Philippe Cornu
Reviewed-by: Yannick FERTRE
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index a03a642..514efef 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -260,8 +260,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
/* Compute requested pll out */
bpp = mipi_dsi_pixel_format_to_bpp(format);
pll_out_khz = mode->clock * bpp / lanes;
+
/* Add 20% to pll out to be higher than pixel bw (burst mode only) */
- pll_out_khz = (pll_out_khz * 12) / 10;
+ if (mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+ pll_out_khz = (pll_out_khz * 12) / 10;
+
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
DRM_WARN("Warning max phy mbps is used\n");
--
2.7.4
Re: [PATCH v2 3/3] drm/mgag200: Add vblank support
On Thu, Sep 12, 2019 at 08:42:30AM +0200, Thomas Zimmermann wrote:
> There's no VBLANK interrupt on Matrox chipsets. The workaround that is
> being used here and in other free Matrox drivers is to program
> to the value of and enable the VLINE interrupt. This triggers
> an interrupt at the time when VBLANK begins.
>
> VLINE uses separate registers for enabling and clearing pending interrupts.
> No extra syncronization between irq handler and the rest of the driver is
> required.
>
> Signed-off-by: Thomas Zimmermann
Looks sane, can't justify on mga hardware details though.
Acked-by: Gerd Hoffmann
>
> v2:
> * only signal vblank on CRTC 0
> * use constants for registers and fields
> * set VLINECLR before enabling interrupt
> * test against STATUS and IEN in irq handler
> * coding-style fixes
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
> drivers/gpu/drm/mgag200/mgag200_drv.h | 1 +
> drivers/gpu/drm/mgag200/mgag200_main.c | 40 ++
> drivers/gpu/drm/mgag200/mgag200_mode.c | 47 +++---
> drivers/gpu/drm/mgag200/mgag200_reg.h | 5 +++
> 5 files changed, 90 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> index 4f9df3b93598..cff265973154 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -67,6 +67,7 @@ static struct drm_driver driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET,
> .load = mgag200_driver_load,
> .unload = mgag200_driver_unload,
> + .irq_handler = mgag200_irq_handler,
> .fops = _driver_fops,
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
> b/drivers/gpu/drm/mgag200/mgag200_drv.h
> index 1c93f8dc08c7..88cf256d135f 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> @@ -195,6 +195,7 @@ void mgag200_modeset_fini(struct mga_device *mdev);
> /* mgag200_main.c */
> int mgag200_driver_load(struct drm_device *dev, unsigned long flags);
> void mgag200_driver_unload(struct drm_device *dev);
> +irqreturn_t mgag200_irq_handler(int irq, void *arg);
>
> /* mgag200_i2c.c */
> struct mga_i2c_chan *mgag200_i2c_create(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
> b/drivers/gpu/drm/mgag200/mgag200_main.c
> index a9773334dedf..44273a66f5a5 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_main.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_main.c
> @@ -10,7 +10,9 @@
>
> #include
> #include
> +#include
> #include
> +#include
>
> #include "mgag200_drv.h"
>
> @@ -186,10 +188,18 @@ int mgag200_driver_load(struct drm_device *dev,
> unsigned long flags)
> }
> mdev->cursor.pixels_current = NULL;
>
> + r = drm_vblank_init(dev, 1);
> + if (r)
> + goto err_modeset;
> +
> r = drm_fbdev_generic_setup(mdev->dev, 0);
> if (r)
> goto err_modeset;
>
> + r = drm_irq_install(dev, dev->pdev->irq);
> + if (r)
> + goto err_modeset;
> +
> return 0;
>
> err_modeset:
> @@ -207,8 +217,38 @@ void mgag200_driver_unload(struct drm_device *dev)
>
> if (mdev == NULL)
> return;
> + drm_irq_uninstall(dev);
> mgag200_modeset_fini(mdev);
> drm_mode_config_cleanup(dev);
> mgag200_mm_fini(mdev);
> dev->dev_private = NULL;
> }
> +
> +irqreturn_t mgag200_irq_handler(int irq, void *arg)
> +{
> + struct drm_device *dev = arg;
> + struct mga_device *mdev = dev->dev_private;
> + struct drm_crtc *crtc;
> + u32 status, ien, iclear;
> +
> + status = RREG32(MGAREG_STATUS);
> +
> + if (status & MGA_VLINEPEN) {
> + ien = RREG32(MGAREG_IEN);
> + if (!(ien & MGA_VLINEIEN))
> + goto out;
> +
> + crtc = drm_crtc_from_index(dev, 0);
> + if (WARN_ON_ONCE(!crtc))
> + goto out;
> + drm_crtc_handle_vblank(crtc);
> +
> + iclear = RREG32(MGAREG_ICLEAR);
> + iclear |= MGA_VLINECLR;
> + WREG32(MGAREG_ICLEAR, iclear);
> + return IRQ_HANDLED;
> + }
> +
> +out:
> + return IRQ_NONE;
> +};
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 302ba40eb033..e13c3244fea9 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -905,6 +905,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
> const struct drm_framebuffer *fb = crtc->primary->fb;
> int hdisplay, hsyncstart, hsyncend, htotal;
> int vdisplay, vsyncstart, vsyncend, vtotal;
> + int linecomp;
> int pitch;
> int option = 0, option2 = 0;
> int i;
> @@ -1042,6 +1043,14 @@ static int
Re: [PATCH v2 1/3] drm/fb-helper: Synchronize dirty worker with vblank
On Thu, Sep 12, 2019 at 08:42:28AM +0200, Thomas Zimmermann wrote:
> Before updating the display from the console's shadow buffer, the dirty
> worker now waits for vblank. This allows several screen updates to pile
> up and acts as a rate limiter.
>
> v2:
> * don't hold helper->lock while waiting for vblank
>
> Signed-off-by: Thomas Zimmermann #
Reviewed-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index a7ba5b4902d6..d0cb1fa4f909 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -402,8 +402,18 @@ static void drm_fb_helper_dirty_work(struct work_struct
> *work)
> dirty_work);
> struct drm_clip_rect *clip = >dirty_clip;
> struct drm_clip_rect clip_copy;
> + struct drm_crtc *crtc;
> unsigned long flags;
> void *vaddr;
> + int ret;
> +
> + /* rate-limit update frequency */
> + crtc = helper->client.modesets[0].crtc;
> + ret = drm_crtc_vblank_get(crtc);
> + if (!ret) {
> + drm_crtc_wait_one_vblank(crtc);
> + drm_crtc_vblank_put(crtc);
> + }
>
> spin_lock_irqsave(>dirty_lock, flags);
> clip_copy = *clip;
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/mgag200: Rename constant MGAREG_Status to MGAREG_STATUS
On Thu, Sep 12, 2019 at 08:42:29AM +0200, Thomas Zimmermann wrote:
> Register constants are upper case. Fix MGAREG_Status accordingly.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
> drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 5e778b5f1a10..302ba40eb033 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -79,12 +79,12 @@ static inline void mga_wait_vsync(struct mga_device *mdev)
> unsigned int status = 0;
>
> do {
> - status = RREG32(MGAREG_Status);
> + status = RREG32(MGAREG_STATUS);
> } while ((status & 0x08) && time_before(jiffies, timeout));
> timeout = jiffies + HZ/10;
> status = 0;
> do {
> - status = RREG32(MGAREG_Status);
> + status = RREG32(MGAREG_STATUS);
> } while (!(status & 0x08) && time_before(jiffies, timeout));
> }
>
> @@ -93,7 +93,7 @@ static inline void mga_wait_busy(struct mga_device *mdev)
> unsigned long timeout = jiffies + HZ;
> unsigned int status = 0;
> do {
> - status = RREG8(MGAREG_Status + 2);
> + status = RREG8(MGAREG_STATUS + 2);
> } while ((status & 0x01) && time_before(jiffies, timeout));
> }
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_reg.h
> b/drivers/gpu/drm/mgag200/mgag200_reg.h
> index c096a9d6bcbc..6c460d9a2143 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_reg.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_reg.h
> @@ -101,7 +101,7 @@
> #define MGAREG_EXEC 0x0100
>
> #define MGAREG_FIFOSTATUS 0x1e10
> -#define MGAREG_Status 0x1e14
> +#define MGAREG_STATUS 0x1e14
> #define MGAREG_CACHEFLUSH 0x1fff
> #define MGAREG_ICLEAR 0x1e18
> #define MGAREG_IEN 0x1e1c
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: clean caches at the end of render jobs on request from user space
Extends the user space ioctl for CL submissions so it can include a request
to flush the cache once the CL execution has completed. Fixes memory
write violation messages reported by the kernel in workloads involving
shader memory writes (SSBOs, shader images, scratch, etc) which sometimes
also lead to GPU resets during Piglit and CTS workloads.
Signed-off-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_gem.c | 51 +--
include/uapi/drm/v3d_drm.h| 7 ++---
2 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 5d80507b539b..530fe9d9d5bd 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -530,13 +530,16 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
struct drm_v3d_submit_cl *args = data;
struct v3d_bin_job *bin = NULL;
struct v3d_render_job *render;
+ struct v3d_job *clean_job = NULL;
+ struct v3d_job *last_job;
struct ww_acquire_ctx acquire_ctx;
int ret = 0;
trace_v3d_submit_cl_ioctl(>drm, args->rcl_start, args->rcl_end);
- if (args->pad != 0) {
- DRM_INFO("pad must be zero: %d\n", args->pad);
+ if (args->flags != 0 &&
+ args->flags != DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG) {
+ DRM_INFO("invalid flags: %d\n", args->flags);
return -EINVAL;
}
@@ -575,12 +578,28 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
bin->render = render;
}
- ret = v3d_lookup_bos(dev, file_priv, >base,
+ if (args->flags & DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG) {
+ clean_job = kcalloc(1, sizeof(*clean_job), GFP_KERNEL);
+ if (!clean_job) {
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ ret = v3d_job_init(v3d, file_priv, clean_job, v3d_job_free, 0);
+ if (ret)
+ goto fail;
+
+ last_job = clean_job;
+ } else {
+ last_job = >base;
+ }
+
+ ret = v3d_lookup_bos(dev, file_priv, last_job,
args->bo_handles, args->bo_handle_count);
if (ret)
goto fail;
- ret = v3d_lock_bo_reservations(>base, _ctx);
+ ret = v3d_lock_bo_reservations(last_job, _ctx);
if (ret)
goto fail;
@@ -599,28 +618,44 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_push_job(v3d_priv, >base, V3D_RENDER);
if (ret)
goto fail_unreserve;
+
+ if (clean_job) {
+ struct dma_fence *render_fence =
+ dma_fence_get(render->base.done_fence);
+ ret = drm_gem_fence_array_add(_job->deps, render_fence);
+ if (ret)
+ goto fail_unreserve;
+ ret = v3d_push_job(v3d_priv, clean_job, V3D_CACHE_CLEAN);
+ if (ret)
+ goto fail_unreserve;
+ }
+
mutex_unlock(>sched_lock);
v3d_attach_fences_and_unlock_reservation(file_priv,
->base,
+last_job,
_ctx,
args->out_sync,
-render->base.done_fence);
+last_job->done_fence);
if (bin)
v3d_job_put(>base);
v3d_job_put(>base);
+ if (clean_job)
+ v3d_job_put(clean_job);
return 0;
fail_unreserve:
mutex_unlock(>sched_lock);
- drm_gem_unlock_reservations(render->base.bo,
- render->base.bo_count, _ctx);
+ drm_gem_unlock_reservations(last_job->bo,
+ last_job->bo_count, _ctx);
fail:
if (bin)
v3d_job_put(>base);
v3d_job_put(>base);
+ if (clean_job)
+ v3d_job_put(clean_job);
return ret;
}
diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
index 58fbe48c91e9..58d2040ea48c 100644
--- a/include/uapi/drm/v3d_drm.h
+++ b/include/uapi/drm/v3d_drm.h
@@ -48,6 +48,8 @@ extern "C" {
#define DRM_IOCTL_V3D_SUBMIT_TFU DRM_IOW(DRM_COMMAND_BASE +
DRM_V3D_SUBMIT_TFU, struct drm_v3d_submit_tfu)
#define DRM_IOCTL_V3D_SUBMIT_CSD DRM_IOW(DRM_COMMAND_BASE +
DRM_V3D_SUBMIT_CSD, struct drm_v3d_submit_csd)
+#define DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG0x01
+
/**
* struct drm_v3d_submit_cl - ioctl argument for submitting commands to the 3D
* engine.
@@ -61,7 +63,7 @@ extern "C" {
* flushed by the time the render done IRQ happens, which is the
* trigger for out_sync. Any dirtying of cachelines by the job (only
* possible using TMU
[Bug 111669] Navi GPU hang in Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=111669 Bug ID: 111669 Summary: Navi GPU hang in Minecraft Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: g...@dougty.com QA Contact: dri-devel@lists.freedesktop.org When playing Minecraft, being in a certain area of my world at night causes my GPU to hang. I'm using Optifine and Sildur's shaders. Sep 12 01:38:42 xxx kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Sep 12 01:38:47 xxx kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Sep 12 01:38:47 xxx kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Sep 12 01:38:47 xxx kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=19965, emitted seq=19967 Sep 12 01:38:47 xxx kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process java pid 1375 thread java:cs0 pid 1433 CPU: 3700X GPU: Sapphire 5700XT (reference) Motherboard: Gigabyte X570-I (BIOS F4) Kernel: 5.3.0-rc8-mainline Mesa: 19.3.0_devel.115190.f83f9d7daa0 LLVM: 10.0.0_r326348.d7d8bb937ad OpenGL string (as seen ingame): 4.5 (Compatibility Profile) Mesa 19.3.0-devel (git-f83f9d7daa), X.Org, AMD NAVI10 (DRM 3.33.0, 5.3.0-rc8-mainline, LLVM 10.0.0) I get the hang extremely reliably when in this specific spot at night, but only this one apitrace recreates the hang when I replay it. Apologies for the filesize. https://drive.google.com/open?id=16wAmCa27o2xxv3bFXnR6rGXAum0Wci_5 When the hangs occur, my screen freezes but everything is still running in the background, and I need to use REISUB hotkeys in order to reboot. Occurs with both PCIe 4.0 and 3.0 set in the BIOS. Please let me know if any more info is needed. Thank you. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/9] drm: rcar-du: crtc: Enable and disable CMMs
Hi Kieran,
On Wed, Sep 11, 2019 at 07:40:27PM +0100, Kieran Bingham wrote:
> Hi Jacopo,
>
> On 06/09/2019 14:54, Jacopo Mondi wrote:
> > Enable/disable the CMM associated with a CRTC at CRTC start and stop
> > time and enable the CMM unit through the Display Extensional Functions
> > register at group setup time.
> >
> > Reviewed-by: Ulrich Hecht
> > Reviewed-by: Laurent Pinchart
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +++
> > drivers/gpu/drm/rcar-du/rcar_du_group.c | 8
> > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 +
> > 3 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > index 23f1d6cc1719..3dac605c3a67 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> >
> > +#include "rcar_cmm.h"
> > #include "rcar_du_crtc.h"
> > #include "rcar_du_drv.h"
> > #include "rcar_du_encoder.h"
> > @@ -619,6 +620,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc
> > *rcrtc)
> > if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> > rcar_du_vsp_disable(rcrtc);
> >
> > + if (rcrtc->cmm)
> > + rcar_cmm_disable(rcrtc->cmm);
> > +
> > /*
> > * Select switch sync mode. This stops display operation and configures
> > * the HSYNC and VSYNC signals as inputs.
> > @@ -686,6 +690,9 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> > }
> >
> > rcar_du_crtc_start(rcrtc);
> > +
> > + if (rcrtc->cmm)
> > + rcar_cmm_enable(rcrtc->cmm);
> > }
> >
> > static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > index 9eee47969e77..25d0fc125d7a 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > @@ -147,6 +147,14 @@ static void rcar_du_group_setup(struct rcar_du_group
> > *rgrp)
> >
> > rcar_du_group_setup_pins(rgrp);
> >
> > + if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CMM)) {
> > + u32 defr7 = DEFR7_CODE
> > + | (rgrp->cmms_mask & BIT(1) ? DEFR7_CMME1 : 0)
> > + | (rgrp->cmms_mask & BIT(0) ? DEFR7_CMME0 : 0);
> > +
> > + rcar_du_group_write(rgrp, DEFR7, defr7);
> > + }
> > +
>
> What's the effect here on platforms with a CMM, but with
> CONFIG_DRM_RCAR_CMM unset?
>
> Will this incorrectly configure the DU ?
>
> Will it stall the display if the DU tries to interact with another
> module which is not enabled?
I recall I tested that (that's why I had to add stubs for CMM
functions, as I had linkage errors otherwise) and thing seems to be
fine as the CMM configuration/enblement resolve to an empty function.
Would you prefer to have this guarded by an #if IS_ENABLED() ?
Thanks
j
>
>
> > if (rcdu->info->gen >= 2) {
> > rcar_du_group_setup_defr8(rgrp);
> > rcar_du_group_setup_didsr(rgrp);
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> > index bc87f080b170..fb9964949368 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> > @@ -197,6 +197,11 @@
> > #define DEFR6_MLOS1(1 << 2)
> > #define DEFR6_DEFAULT (DEFR6_CODE | DEFR6_TCNE1)
> >
> > +#define DEFR7 0x000ec
> > +#define DEFR7_CODE (0x7779 << 16)
> > +#define DEFR7_CMME1BIT(6)
> > +#define DEFR7_CMME0BIT(4)
> > +
> > /*
> > -
> > * R8A7790-only Control Registers
> > */
> >
>
signature.asc
Description: PGP signature
Re: [PATCH v4 3/9] drm: rcar-du: Add support for CMM
Hi Kiernan,
thanks for review
On Wed, Sep 11, 2019 at 04:54:58PM +0100, Kieran Bingham wrote:
> Hi Jacopo,
>
>
>
> On 06/09/2019 14:43, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > to perform image enhancement and color correction.
> >
> > Add support for CMM through a driver that supports configuration of
> > the 1-dimensional LUT table. More advanced CMM feature will be
>
> s/feature/features/
>
> > implemented on top of this basic one.
>
> s/basic/initial/
>
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.c | 251 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.h | 61 +++
> > 4 files changed, 320 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> b/drivers/gpu/drm/rcar-du/Kconfig
> > index 1529849e217e..539d232790d1 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > Choose this option if you have an R-Car chipset.
> > If M is selected the module will be called rcar-du-drm.
> >
> > +config DRM_RCAR_CMM
> > + bool "R-Car DU Color Management Module (CMM) Support"
> > + depends on DRM && OF
> > + depends on DRM_RCAR_DU
> > + help
> > + Enable support for R-Car Color Management Module (CMM).
> > +
> > config DRM_RCAR_DW_HDMI
> > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > depends on DRM && OF
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> > index 6c2ed9c46467..4d1187ccc3e5 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > \
> > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> >
> > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > new file mode 100644
> > index ..3cacdc4474c7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > @@ -0,0 +1,251 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > + *
> > + * Copyright (C) 2019 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "rcar_cmm.h"
> > +
> > +#define CM2_LUT_CTRL 0x
> > +#define CM2_LUT_CTRL_LUT_ENBIT(0)
>
> I'd have a new line here
>
> > +#define CM2_LUT_TBL_BASE 0x0600
> > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > +
> > +struct rcar_cmm {
> > + void __iomem *base;
> > + bool enabled;
> > +
> > + /*
> > +* @lut:1D-LUT status
> > +* @lut.enabled:1D-LUT enabled flag
> > +* @lut.table: Table of 1D-LUT entries scaled to hardware
> > +* precision (8-bits per color component)
> > +*/
> > + struct {
> > + bool enabled;
> > + u32 table[CM2_LUT_SIZE];
> > + } lut;
> > +};
> > +
> > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > +{
> > + return ioread32(rcmm->base + reg);
> > +}
> > +
> > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32
> data)
> > +{
> > + iowrite32(data, rcmm->base + reg);
> > +}
> > +
> > +/*
> > + * rcar_cmm_lut_extract() - Scale down to hardware precision the DRM
> LUT table
> > + * entries and store them.
> > + * @rcmm: Pointer to the CMM device
> > + * @drm_lut: Pointer to the DRM LUT table
> > + */
> > +static void rcar_cmm_lut_extract(struct rcar_cmm *rcmm,
> > +const struct drm_color_lut *drm_lut)
> > +{
> > + unsigned int i;
>
> I think you're missing the following here:
>
> if (!drm_lut)
> return;
>
> You mention below that drm_lut could be passed in as NULL, which would
> cause a segfault here otherwise.
>
Thanks for spotting, but I should have removed that comment, as I have
killed that case in rcar_du_atomic_commit_update_cmm() in patch 8/9,
as from my testing it seems it is not possible to provide from
userspace a non populated LUT table to just re-enable the CMM.
So we're fine here.
>
> > +
> > + for (i = 0; i < CM2_LUT_SIZE; ++i) {
> > + const struct drm_color_lut *lut = _lut[i];
> > +
> > +
Re: [PATCH v4 2/2] drm/virtio: Use vmalloc for command buffer allocations.
On Wed, Sep 11, 2019 at 11:14:03AM -0700, David Riley wrote: > Userspace requested command buffer allocations could be too large > to make as a contiguous allocation. Use vmalloc if necessary to > satisfy those allocations. Both applied to drm-misc-next. thanks, Gerd
Re: HDCP Content Type Interface
On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote: > Hi all, > > This is regarding the recent hdcp content type patch that was merged into > drm-misc. > (https://patchwork.freedesktop.org/patch/320958/?series=57233=11) > > There are displays on the market that advertise HDCP 2.2 support and will > pass authentication and encryption but will then show a corrupted/blue/black > screen (the driver cannot detect this). These displays work with HDCP 1.4 > without any issues. Due to the large number of HDCP-supporting devices on the > market we might not be able to catch them with a blacklist. > > From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same > thing. Meaning that this interface doesn't allow us to force the hdcp > version. Due to the problems mentioned above we might want to expose the > ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) > in case they experience problems. > > What are your thoughts? and what would be a good way to deal with it? Hi, As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel supposed to exercise the highest version of HDCP supported on panel and platform. As we implement the HDCP spec support, if a device is non-compliant with HDCP spec after completing the HDCP authentication, I dont think we need to worry about it. In case if you want to track and implement a quirk for it, like not to project the HDCP2.2 capability, you can use the receiver id of that panel to track it. Thanks, -Ram > > > Thanks, > > Bhawan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
drm-misc-fixes-2019-09-12: drm-misc-fixes for v5.3 final: - Constify modes whitelist harder. - Fix lima driver gem_wait ioctl. The following changes since commit 424c38a4e32509ae82dc9d7300432295806cb911: drm/selftests: modes: Add more unit tests for the cmdline parser (2019-08-30 10:21:56 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-09-12 for you to fetch changes up to 21670bd78a25001cf8ef2679b378c73fb73b904f: drm/lima: fix lima_gem_wait() return value (2019-09-10 10:09:00 +0800) drm-misc-fixes for v5.3 final: - Constify modes whitelist harder. - Fix lima driver gem_wait ioctl. Maxime Ripard (1): drm/modes: Make the whitelist more const Vasily Khoruzhick (1): drm/lima: fix lima_gem_wait() return value drivers/gpu/drm/drm_modes.c | 2 +- drivers/gpu/drm/lima/lima_gem.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111667] gem_render_copy failing on CCS subtests
https://bugs.freedesktop.org/show_bug.cgi?id=111667 Bug ID: 111667 Summary: gem_render_copy failing on CCS subtests Product: DRI Version: DRI git Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: not set Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: mika.kah...@intel.com gem_render_copy is failing on CCS subtests on TGL y-tiled-ccs-to-linear y-tiled-ccs-to-x-tiled y-tiled-ccs-to-y-tiled y-tiled-ccs-to-yf-tiled yf-tiled-ccs-to-linear yf-tiled-ccs-to-x-tiled yf-tiled-ccs-to-y-tiled yf-tiled-ccs-to-yf-tiled It seems that at least, rendercopy support for GEN12 is missing from upstream IGT. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] gpu: no need to compile drm/ if CONFIG_DRM=n
Hi,
Le mer. 11 sept. 2019 à 19:35, Qian Cai a écrit :
> The commit c0e09200dc08 ("drm: reorganise drm tree to be more future
> proof.") changed the behavior from only compiling drm/ if CONFIG_DRM=y
> to always compiling drm/. This restores the behavior, so people don't
> need to waste time compiling stuff they don't need.
>
> Fixes: c0e09200dc08 ("drm: reorganise drm tree to be more future proof.")
You are missing your signed-off-by
Thanks,
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
