Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Deepak Am 11.09.20 um 02:38 schrieb Deepak Rawat: > On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: >> Hi Deepak, >> >> Do you have a new version of this patch now? >> I take a try with it. and meet some typo and “incompatible pointer” >> error. >> If you have a new version, could you share it with us? >> > > Hi Shaofeng, > > It seems you are running this with gen 2 VM, I have a patch to support > gen 2 VM's at https://github.com/deepak-rawat/linux.git branch hyperv_t > iny. I'm interested in merging this driver into the DRM upstream. What's the status? Are you still working on it? Best regards Thomas > > If you still run into error after applying gen2 patch, feel free to > reach out with details. > > Deepak > >> >> BR, Shaofeng > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fourcc: fix AMD modifiers PACKERS field doc
This field doesn't alias with BANK_XOR_BITS: PACKERS is bits 26:28 while
BANK_XOR_BITS is bits 23:25.
Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Signed-off-by: Simon Ser
Cc: Bas Nieuwenhuizen
Cc: Alex Deucher
Cc: Daniel Vetter
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ca48ed0e6bc1..29c7a8694479 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -1196,7 +1196,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 23
#define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
-#define AMD_FMT_MOD_PACKERS_SHIFT 26 /* aliases with BANK_XOR_BITS */
+#define AMD_FMT_MOD_PACKERS_SHIFT 26
#define AMD_FMT_MOD_PACKERS_MASK 0x7
#define AMD_FMT_MOD_RB_SHIFT 29
#define AMD_FMT_MOD_RB_MASK 0x7
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drm: convert drm_atomic_uapi.c to new debug helpers"
Total wipeout in boot!
<7>[3.739908] i915 :00:02.0:
[drm:__drm_fb_helper_initial_config_and_unlock] test CRTC 0 primary plane
<7>[3.739916] i915 :00:02.0:
[drm:__drm_fb_helper_initial_config_and_unlock] test CRTC 1 primary plane
9] Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS 8.11 10/24/2012
<4>[3.754904] Workqueue: events_unbound async_run_entry_fn
<4>[3.754908] RIP: 0010:drm_atomic_set_crtc_for_connector+0xe0/0x120
<4>[3.754910] Code: 24 28 be 10 00 00 00 48 c7 c2 60 b0 38 82 48 8b 78 18
ff 75 20 8b 85 d8 00 00 00 50 e8 89 45 ff ff 58 31 c0 5a 5b 5d 41 5c c3 <48> 8b
04 25 00 00 00 00 41 8b 4c 24 28 49 89 d9 be 10 00 00 00 4d
<4>[3.754911] RSP: 0018:c92bfa48 EFLAGS: 00010246
<4>[3.754912] RAX: 0005 RBX: 88800ff1a318 RCX:
0005
<4>[3.754913] RDX: 816d04f0 RSI: 82388e71 RDI:
88800fc51038
<4>[3.754914] RBP: R08: 88810414dc10 R09:
fffe
<4>[3.754915] R10: 682c1dc7 R11: 24f563d5 R12:
88800fc51000
<4>[3.754916] R13: R14: 88800ff1a318 R15:
88801aab9a00
<4>[3.754918] FS: () GS:88811b48()
knlGS:
c9/0x130
<4>[3.755084] do_bind_con_driver+0x1e5/0x2d0
<4>[3.755087] do_take_over_console+0x10e/0x180
<4>[3.755089] do_fbcon_takeover+0x53/0xb0
<4>[3.755092] register_framebuffer+0x22d/0x310
<4>[3.755095] __drm_fb_helper_initial_config_and_unlock+0x35d/0x530
<4>[3.755190] intel_fbdev_initial_config+0xf/0x20 [i915]
<4>[3.755192] async_run_entry_fn+0x34/0x160
<4>[3.755195] process_one_work+0x270/0x5c0
<4>[3.755199] worker_thread+0x37/0x380
<4>[3.755201] ? process_one_work+0x5c0/0x5c0
<4>[3.755203] kthread+0x146/0x170
<4>[3.755205] ? kthread_park+0x80/0x80
<4>[3.755208] ret_from_fork+0x22/0x30
<4>[3.755211] Modules linked in: i915 mei_hdcp x86_pkg_temp_thermal
coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel
snd_intel_dspcfg snd_hda_codec r8169 snd_hwdep snd_hda_core realtek mei_me
snd_pcm mei lpc_ich prime_numbers
<4>[3.755224] CR2:
<4>[3.755226] ---[ end trace df071a2078bd01b3 ]---
Fixes: e3aae683e861 ("drm: convert drm_atomic_uapi.c to new debug helpers")
Signed-off-by: Chris Wilson
Cc: Simon Ser
Cc: Daniel Vetter
Cc: Sam Ravnborg
---
drivers/gpu/drm/drm_atomic_uapi.c | 113 +-
1 file changed, 47 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9df7f2a170e3..d26077ed518a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -85,15 +85,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
*state,
drm_mode_copy(&state->mode, mode);
state->enable = true;
- drm_dbg_atomic(crtc->dev,
- "Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
- mode->name, crtc->base.id, crtc->name, state);
+ DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
+mode->name, crtc->base.id, crtc->name, state);
} else {
memset(&state->mode, 0, sizeof(state->mode));
state->enable = false;
- drm_dbg_atomic(crtc->dev,
- "Set [NOMODE] for [CRTC:%d:%s] state %p\n",
- crtc->base.id, crtc->name, state);
+ DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
+crtc->base.id, crtc->name, state);
}
return 0;
@@ -130,35 +128,31 @@ int drm_atomic_set_mode_prop_for_crtc(struct
drm_crtc_state *state,
int ret;
if (blob->length != sizeof(struct drm_mode_modeinfo)) {
- drm_dbg_atomic(crtc->dev,
- "[CRTC:%d:%s] bad mode blob length:
%zu\n",
- crtc->base.id, crtc->name,
- blob->length);
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length:
%zu\n",
+crtc->base.id, crtc->name,
+blob->length);
return -EINVAL;
}
ret = drm_mode_convert_umode(crtc->dev,
&state->mode, blob->data);
if (ret) {
- drm_dbg_atomic(crtc->dev,
- "[CRTC:%d:%s] invalid mode (ret=%d,
status=%s):\n",
- crtc->base.id, crtc->name,
- ret,
drm_get_mode_status_name(state->mode.status));
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s]
[PATCH] drm: fix oops in drm_atomic_set_crtc_for_connector
crtc can be NULL. connector, extracted from conn_state, can't.
Fixes: e3aae683e861 ("drm: convert drm_atomic_uapi.c to new debug helpers")
Signed-off-by: Simon Ser
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Sam Ravnborg
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9df7f2a170e3..268bb69c2e2f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -334,12 +334,12 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
drm_connector_get(conn_state->connector);
conn_state->crtc = crtc;
- drm_dbg_atomic(crtc->dev,
+ drm_dbg_atomic(connector->dev,
"Link [CONNECTOR:%d:%s] state %p to
[CRTC:%d:%s]\n",
connector->base.id, connector->name,
conn_state, crtc->base.id, crtc->name);
} else {
- drm_dbg_atomic(crtc->dev,
+ drm_dbg_atomic(connector->dev,
"Link [CONNECTOR:%d:%s] state %p to [NOCRTC]\n",
connector->base.id, connector->name,
conn_state);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: fix AMD modifiers PACKERS field doc
Reviewed-by: Bas Nieuwenhuizen
On Sun, Nov 15, 2020 at 10:39 AM Simon Ser wrote:
>
> This field doesn't alias with BANK_XOR_BITS: PACKERS is bits 26:28 while
> BANK_XOR_BITS is bits 23:25.
>
> Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
> Signed-off-by: Simon Ser
> Cc: Bas Nieuwenhuizen
> Cc: Alex Deucher
> Cc: Daniel Vetter
> ---
> include/uapi/drm/drm_fourcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ca48ed0e6bc1..29c7a8694479 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1196,7 +1196,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
> modifier)
> #define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
> #define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 23
> #define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
> -#define AMD_FMT_MOD_PACKERS_SHIFT 26 /* aliases with BANK_XOR_BITS */
> +#define AMD_FMT_MOD_PACKERS_SHIFT 26
> #define AMD_FMT_MOD_PACKERS_MASK 0x7
> #define AMD_FMT_MOD_RB_SHIFT 29
> #define AMD_FMT_MOD_RB_MASK 0x7
> --
> 2.29.2
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500: Remove 2D accel code
2D acceleration is only available on PSB and MRST and very slow on both
platforms. CPU acceleration is faster so don't bother with 2D accel
anymore.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/accel_2d.c| 292 ---
drivers/gpu/drm/gma500/cdv_device.c | 1 -
drivers/gpu/drm/gma500/framebuffer.c | 16 +-
drivers/gpu/drm/gma500/mdfld_device.c| 1 -
drivers/gpu/drm/gma500/oaktrail_device.c | 1 -
drivers/gpu/drm/gma500/psb_device.c | 1 -
drivers/gpu/drm/gma500/psb_drv.c | 1 -
drivers/gpu/drm/gma500/psb_drv.h | 7 -
8 files changed, 1 insertion(+), 319 deletions(-)
diff --git a/drivers/gpu/drm/gma500/accel_2d.c
b/drivers/gpu/drm/gma500/accel_2d.c
index adc0507545bf..437bbb6af9e6 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -58,295 +58,3 @@ void psb_spank(struct drm_psb_private *dev_priv)
(void) PSB_RSGX32(PSB_CR_BIF_CTRL);
PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
}
-
-/**
- * psb2_2d_wait_available - wait for FIFO room
- * @dev_priv: our DRM device
- * @size: size (in dwords) of the command we want to issue
- *
- * Wait until there is room to load the FIFO with our data. If the
- * device is not responding then reset it
- */
-static int psb_2d_wait_available(struct drm_psb_private *dev_priv,
- unsigned size)
-{
- uint32_t avail = PSB_RSGX32(PSB_CR_2D_SOCIF);
- unsigned long t = jiffies + HZ;
-
- while (avail < size) {
- avail = PSB_RSGX32(PSB_CR_2D_SOCIF);
- if (time_after(jiffies, t)) {
- psb_spank(dev_priv);
- return -EIO;
- }
- }
- return 0;
-}
-
-/**
- * psb_2d_submit - submit a 2D command
- * @dev_priv: our DRM device
- * @cmdbuf: command to issue
- * @size: length (in dwords)
- *
- * Issue one or more 2D commands to the accelerator. This needs to be
- * serialized later when we add the GEM interfaces for acceleration
- */
-static int psbfb_2d_submit(struct drm_psb_private *dev_priv, uint32_t *cmdbuf,
- unsigned size)
-{
- int ret = 0;
- int i;
- unsigned submit_size;
- unsigned long flags;
-
- spin_lock_irqsave(&dev_priv->lock_2d, flags);
- while (size > 0) {
- submit_size = (size < 0x60) ? size : 0x60;
- size -= submit_size;
- ret = psb_2d_wait_available(dev_priv, submit_size);
- if (ret)
- break;
-
- submit_size <<= 2;
-
- for (i = 0; i < submit_size; i += 4)
- PSB_WSGX32(*cmdbuf++, PSB_SGX_2D_SLAVE_PORT + i);
-
- (void)PSB_RSGX32(PSB_SGX_2D_SLAVE_PORT + i - 4);
- }
- spin_unlock_irqrestore(&dev_priv->lock_2d, flags);
- return ret;
-}
-
-
-/**
- * psb_accel_2d_copy_direction - compute blit order
- * @xdir: X direction of move
- * @ydir: Y direction of move
- *
- * Compute the correct order setings to ensure that an overlapping blit
- * correctly copies all the pixels.
- */
-static u32 psb_accel_2d_copy_direction(int xdir, int ydir)
-{
- if (xdir < 0)
- return (ydir < 0) ? PSB_2D_COPYORDER_BR2TL :
- PSB_2D_COPYORDER_TR2BL;
- else
- return (ydir < 0) ? PSB_2D_COPYORDER_BL2TR :
- PSB_2D_COPYORDER_TL2BR;
-}
-
-/**
- * psb_accel_2d_copy - accelerated 2D copy
- * @dev_priv: our DRM device
- * @src_offset in bytes
- * @src_stride in bytes
- * @src_format psb 2D format defines
- * @dst_offset in bytes
- * @dst_stride in bytes
- * @dst_format psb 2D format defines
- * @src_x offset in pixels
- * @src_y offset in pixels
- * @dst_x offset in pixels
- * @dst_y offset in pixels
- * @size_x of the copied area
- * @size_y of the copied area
- *
- * Format and issue a 2D accelerated copy command.
- */
-static int psb_accel_2d_copy(struct drm_psb_private *dev_priv,
-uint32_t src_offset, uint32_t src_stride,
-uint32_t src_format, uint32_t dst_offset,
-uint32_t dst_stride, uint32_t dst_format,
-uint16_t src_x, uint16_t src_y,
-uint16_t dst_x, uint16_t dst_y,
-uint16_t size_x, uint16_t size_y)
-{
- uint32_t blit_cmd;
- uint32_t buffer[10];
- uint32_t *buf;
- uint32_t direction;
-
- buf = buffer;
-
- direction =
- psb_accel_2d_copy_direction(src_x - dst_x, src_y - dst_y);
-
- if (direction == PSB_2D_COPYORDER_BR2TL ||
- directi
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Sun, 2020-11-15 at 10:14 +0100, Thomas Zimmermann wrote: > Hi Deepak > > Am 11.09.20 um 02:38 schrieb Deepak Rawat: > > On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: > > > Hi Deepak, > > > > > > Do you have a new version of this patch now? > > > I take a try with it. and meet some typo and “incompatible > > > pointer” > > > error. > > > If you have a new version, could you share it with us? > > > > > > > Hi Shaofeng, > > > > It seems you are running this with gen 2 VM, I have a patch to > > support > > gen 2 VM's at https://github.com/deepak-rawat/linux.git branch > > hyperv_t > > iny. > > I'm interested in merging this driver into the DRM upstream. What's > the > status? Are you still working on it? Hi Thomas, I am working on adding gen2 VM support and cursor support. Also for my next interation moving the driver out of tiny. Progress is slow lately as busy with other stuff at work. Hopefully I will be able to finish during coming holidays. Deepak > > Best regards > Thomas > > > > > If you still run into error after applying gen2 patch, feel free to > > reach out with details. > > > > Deepak > > > > > > > > BR, Shaofeng > > > > ___ > > 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: [git pull] drm next pull for 5.10-rc1
On Tue, Nov 3, 2020 at 2:20 PM Kirill A. Shutemov wrote:
>
> On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> > drm/nouveau/kms: Search for encoders' connectors properly
>
> This commit (09838c4efe9a) broke boot for me. These two hunks in
> particular:
Christ. It's been two weeks. I'm doing -rc4 today, and I still don't
have the fix.
The problem seems entirely obvious, as reported by Kirill: the nv50
code unconditionally calls the "atomic_{dis,en}able()" functions, even
when not everybody was converted.
The fix seems to be to either just do the conversion of the remaining
cases (which looks like just adding an argument to the remaining
functions, and using that for the "atomic" callback), or the trivial
suggestion by Kirill from two weeks ago:
> I hacked up patch to use help->disable/help->enable if atomic_ versions
> are NULL. It worked.
Kirill, since the nouveau people aren't fixing this, can you just send
me your tested patch?
Lyude/Ben - let me just say that I think this is all a huge disgrace.
You had a problem report with a bisected commit, a suggested fix, and
two weeks later there's absolutely _nothing_.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Remove 2D accel code
Hi Patrik. On Sun, Nov 15, 2020 at 06:54:20PM +0100, Patrik Jakobsson wrote: > 2D acceleration is only available on PSB and MRST and very slow on both > platforms. CPU acceleration is faster so don't bother with 2D accel > anymore. > > Signed-off-by: Patrik Jakobsson I like the patch and it follows up on the discussions to remove accellerations that is not really a benefit. But I tried to apply it on top of drm-misc-next and it failed in framebuffer.c - did you remove psbfb_roll_ops in another patch? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix oops in drm_atomic_set_crtc_for_connector
On Sun, Nov 15, 2020 at 03:39:07PM +, Simon Ser wrote:
> crtc can be NULL. connector, extracted from conn_state, can't.
>
> Fixes: e3aae683e861 ("drm: convert drm_atomic_uapi.c to new debug helpers")
> Signed-off-by: Simon Ser
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Remove 2D accel code
On Sun, Nov 15, 2020 at 7:32 PM Sam Ravnborg wrote: > > Hi Patrik. > On Sun, Nov 15, 2020 at 06:54:20PM +0100, Patrik Jakobsson wrote: > > 2D acceleration is only available on PSB and MRST and very slow on both > > platforms. CPU acceleration is faster so don't bother with 2D accel > > anymore. > > > > Signed-off-by: Patrik Jakobsson > > I like the patch and it follows up on the discussions to > remove accellerations that is not really a benefit. > But I tried to apply it on top of drm-misc-next and it failed in > framebuffer.c - did you remove psbfb_roll_ops in another patch? Hi Sam, Right, sorry I should have mentioned that it sits on top of https://patchwork.freedesktop.org/series/83153/ -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] dt-bindings: display: mcde: Convert to YAML schema
This moves the MCDE bindings over to using the YAML schema
to describe the ST-Ericsson MCDE display controller,
making use of the generic DSI controller schema.
In the process we correct an error in the old text bindings:
the clocks for the SDI host controllers were specified as
part of the main MCDE component while they should be
specified in the DSI host controller subnodes. This was
a leftover from an earlier iteration of the first patch
series adding the MCDE.
We also add the "port" node, we will use this when adding
LCD panels using the direct parallel interface DPI instead
of DSI.
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Add resets to the bindings for future-proofing, set
additionalProperties: false
- Extend commit message to explain the the old bindings
were incorrect.
ChangeLog v1->v2:
- Cut the description on the interrupts.
- Drop maxItems: 3 on clocks and clock-names: implicit from
the number of listed items.
- Tag the DSI ports with unevaluatedProperties: false
- Tag the MCDE as such with additionalProperties: true
- It was a bit hard to test this because of the code base
being out of phase with the validation tools but it seems
to check out.
---
.../devicetree/bindings/display/ste,mcde.txt | 104 ---
.../devicetree/bindings/display/ste,mcde.yaml | 169 ++
2 files changed, 169 insertions(+), 104 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/ste,mcde.txt
create mode 100644 Documentation/devicetree/bindings/display/ste,mcde.yaml
diff --git a/Documentation/devicetree/bindings/display/ste,mcde.txt
b/Documentation/devicetree/bindings/display/ste,mcde.txt
deleted file mode 100644
index 4c33c692bd5f..
--- a/Documentation/devicetree/bindings/display/ste,mcde.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-ST-Ericsson Multi Channel Display Engine MCDE
-
-The ST-Ericsson MCDE is a display controller with support for compositing
-and displaying several channels memory resident graphics data on DSI or
-LCD displays or bridges. It is used in the ST-Ericsson U8500 platform.
-
-Required properties:
-
-- compatible: must be:
- "ste,mcde"
-- reg: register base for the main MCDE control registers, should be
- 0x1000 in size
-- interrupts: the interrupt line for the MCDE
-- epod-supply: a phandle to the EPOD regulator
-- vana-supply: a phandle to the analog voltage regulator
-- clocks: an array of the MCDE clocks in this strict order:
- MCDECLK (main MCDE clock), LCDCLK (LCD clock), PLLDSI
- (HDMI clock), DSI0ESCLK (DSI0 energy save clock),
- DSI1ESCLK (DSI1 energy save clock), DSI2ESCLK (DSI2 energy
- save clock)
-- clock-names: must be the following array:
- "mcde", "lcd", "hdmi"
- to match the required clock inputs above.
-- #address-cells: should be <1> (for the DSI hosts that will be children)
-- #size-cells: should be <1> (for the DSI hosts that will be children)
-- ranges: this should always be stated
-
-Required subnodes:
-
-The devicetree must specify subnodes for the DSI host adapters.
-These must have the following characteristics:
-
-- compatible: must be:
- "ste,mcde-dsi"
-- reg: must specify the register range for the DSI host
-- vana-supply: phandle to the VANA voltage regulator
-- clocks: phandles to the high speed and low power (energy save) clocks
- the high speed clock is not present on the third (dsi2) block, so it
- should only have the "lp" clock
-- clock-names: "hs" for the high speed clock and "lp" for the low power
- (energy save) clock
-- #address-cells: should be <1>
-- #size-cells: should be <0>
-
-Display panels and bridges will appear as children on the DSI hosts, and
-the displays are connected to the DSI hosts using the common binding
-for video transmitter interfaces; see
-Documentation/devicetree/bindings/media/video-interfaces.txt
-
-If a DSI host is unused (not connected) it will have no children defined.
-
-Example:
-
-mcde@a035 {
- compatible = "ste,mcde";
- reg = <0xa035 0x1000>;
- interrupts = ;
- epod-supply = <&db8500_b2r2_mcde_reg>;
- vana-supply = <&ab8500_ldo_ana_reg>;
- clocks = <&prcmu_clk PRCMU_MCDECLK>, /* Main MCDE clock */
-<&prcmu_clk PRCMU_LCDCLK>, /* LCD clock */
-<&prcmu_clk PRCMU_PLLDSI>; /* HDMI clock */
- clock-names = "mcde", "lcd", "hdmi";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- dsi0: dsi@a0351000 {
- compatible = "ste,mcde-dsi";
- reg = <0xa0351000 0x1000>;
- vana-supply = <&ab8500_ldo_ana_reg>;
- clocks = <&prcmu_clk PRCMU_DSI0CLK>, <&prcmu_clk
PRCMU_DSI0ESCCLK>;
- clock-names = "hs", "lp";
- #address-cells = <1>;
- #size-cells = <0>;
-
- panel {
- compatible = "samsung,s6d16d0";
- reg = <0>;
- vdd1-supply = <&ab8500_ldo_aux1_re
Re: [PATCH] drm/gma500: Remove 2D accel code
Hi
Am 15.11.20 um 18:54 schrieb Patrik Jakobsson:
> 2D acceleration is only available on PSB and MRST and very slow on both
> platforms. CPU acceleration is faster so don't bother with 2D accel
> anymore.
>
> Signed-off-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/accel_2d.c| 292 ---
> drivers/gpu/drm/gma500/cdv_device.c | 1 -
> drivers/gpu/drm/gma500/framebuffer.c | 16 +-
> drivers/gpu/drm/gma500/mdfld_device.c| 1 -
> drivers/gpu/drm/gma500/oaktrail_device.c | 1 -
> drivers/gpu/drm/gma500/psb_device.c | 1 -
> drivers/gpu/drm/gma500/psb_drv.c | 1 -
> drivers/gpu/drm/gma500/psb_drv.h | 7 -
> 8 files changed, 1 insertion(+), 319 deletions(-)
Nice :)
Reviewed-by: Thomas Zimmermann
>
> diff --git a/drivers/gpu/drm/gma500/accel_2d.c
> b/drivers/gpu/drm/gma500/accel_2d.c
> index adc0507545bf..437bbb6af9e6 100644
> --- a/drivers/gpu/drm/gma500/accel_2d.c
> +++ b/drivers/gpu/drm/gma500/accel_2d.c
> @@ -58,295 +58,3 @@ void psb_spank(struct drm_psb_private *dev_priv)
> (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
> PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
> }
> -
> -/**
> - * psb2_2d_wait_available - wait for FIFO room
> - * @dev_priv: our DRM device
> - * @size: size (in dwords) of the command we want to issue
> - *
> - * Wait until there is room to load the FIFO with our data. If the
> - * device is not responding then reset it
> - */
> -static int psb_2d_wait_available(struct drm_psb_private *dev_priv,
> - unsigned size)
> -{
> - uint32_t avail = PSB_RSGX32(PSB_CR_2D_SOCIF);
> - unsigned long t = jiffies + HZ;
> -
> - while (avail < size) {
> - avail = PSB_RSGX32(PSB_CR_2D_SOCIF);
> - if (time_after(jiffies, t)) {
> - psb_spank(dev_priv);
> - return -EIO;
> - }
> - }
> - return 0;
> -}
> -
> -/**
> - * psb_2d_submit - submit a 2D command
> - * @dev_priv: our DRM device
> - * @cmdbuf: command to issue
> - * @size: length (in dwords)
> - *
> - * Issue one or more 2D commands to the accelerator. This needs to be
> - * serialized later when we add the GEM interfaces for acceleration
> - */
> -static int psbfb_2d_submit(struct drm_psb_private *dev_priv, uint32_t
> *cmdbuf,
> - unsigned size)
> -{
> - int ret = 0;
> - int i;
> - unsigned submit_size;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&dev_priv->lock_2d, flags);
> - while (size > 0) {
> - submit_size = (size < 0x60) ? size : 0x60;
> - size -= submit_size;
> - ret = psb_2d_wait_available(dev_priv, submit_size);
> - if (ret)
> - break;
> -
> - submit_size <<= 2;
> -
> - for (i = 0; i < submit_size; i += 4)
> - PSB_WSGX32(*cmdbuf++, PSB_SGX_2D_SLAVE_PORT + i);
> -
> - (void)PSB_RSGX32(PSB_SGX_2D_SLAVE_PORT + i - 4);
> - }
> - spin_unlock_irqrestore(&dev_priv->lock_2d, flags);
> - return ret;
> -}
> -
> -
> -/**
> - * psb_accel_2d_copy_direction - compute blit order
> - * @xdir: X direction of move
> - * @ydir: Y direction of move
> - *
> - * Compute the correct order setings to ensure that an overlapping blit
> - * correctly copies all the pixels.
> - */
> -static u32 psb_accel_2d_copy_direction(int xdir, int ydir)
> -{
> - if (xdir < 0)
> - return (ydir < 0) ? PSB_2D_COPYORDER_BR2TL :
> - PSB_2D_COPYORDER_TR2BL;
> - else
> - return (ydir < 0) ? PSB_2D_COPYORDER_BL2TR :
> - PSB_2D_COPYORDER_TL2BR;
> -}
> -
> -/**
> - * psb_accel_2d_copy - accelerated 2D copy
> - * @dev_priv: our DRM device
> - * @src_offset in bytes
> - * @src_stride in bytes
> - * @src_format psb 2D format defines
> - * @dst_offset in bytes
> - * @dst_stride in bytes
> - * @dst_format psb 2D format defines
> - * @src_x offset in pixels
> - * @src_y offset in pixels
> - * @dst_x offset in pixels
> - * @dst_y offset in pixels
> - * @size_x of the copied area
> - * @size_y of the copied area
> - *
> - * Format and issue a 2D accelerated copy command.
> - */
> -static int psb_accel_2d_copy(struct drm_psb_private *dev_priv,
> - uint32_t src_offset, uint32_t src_stride,
> - uint32_t src_format, uint32_t dst_offset,
> - uint32_t dst_stride, uint32_t dst_format,
> - uint16_t src_x, uint16_t src_y,
> - uint16_t dst_x, uint16_t dst_y,
> - uint16_t size_x, uint16_t size_y)
> -{
> - uint32_t blit_cmd;
> - uint32_t buffer[10];
> - uint32_t *buf;
> -
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Am 15.11.20 um 18:55 schrieb Deepak Rawat: > On Sun, 2020-11-15 at 10:14 +0100, Thomas Zimmermann wrote: >> Hi Deepak >> >> Am 11.09.20 um 02:38 schrieb Deepak Rawat: >>> On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: Hi Deepak, Do you have a new version of this patch now? I take a try with it. and meet some typo and “incompatible pointer” error. If you have a new version, could you share it with us? >>> >>> Hi Shaofeng, >>> >>> It seems you are running this with gen 2 VM, I have a patch to >>> support >>> gen 2 VM's at https://github.com/deepak-rawat/linux.git branch >>> hyperv_t >>> iny. >> >> I'm interested in merging this driver into the DRM upstream. What's >> the >> status? Are you still working on it? > > Hi Thomas, > > I am working on adding gen2 VM support and cursor support. Also for my > next interation moving the driver out of tiny. Progress is slow lately > as busy with other stuff at work. Hopefully I will be able to finish > during coming holidays. I see. Thanks for the update. I'd suggest to clean up what you have and send it for review. Having even a simple driver in upstream makes it so much easier for others to contribute and you'll get many of the upstream improvements automatically. Best regards Thomas > > Deepak > >> >> Best regards >> Thomas >> >>> >>> If you still run into error after applying gen2 patch, feel free to >>> reach out with details. >>> >>> Deepak >>> BR, Shaofeng >>> >>> ___ >>> 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 > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Remove 2D accel code
Hi Patrik, On Sun, Nov 15, 2020 at 07:51:27PM +0100, Patrik Jakobsson wrote: > On Sun, Nov 15, 2020 at 7:32 PM Sam Ravnborg wrote: > > > > Hi Patrik. > > On Sun, Nov 15, 2020 at 06:54:20PM +0100, Patrik Jakobsson wrote: > > > 2D acceleration is only available on PSB and MRST and very slow on both > > > platforms. CPU acceleration is faster so don't bother with 2D accel > > > anymore. > > > > > > Signed-off-by: Patrik Jakobsson > > > > I like the patch and it follows up on the discussions to > > remove accellerations that is not really a benefit. > > But I tried to apply it on top of drm-misc-next and it failed in > > framebuffer.c - did you remove psbfb_roll_ops in another patch? > > Hi Sam, > Right, sorry I should have mentioned that it sits on top of > https://patchwork.freedesktop.org/series/83153/ I thought I had seen something like this before. So all is good - patch is: Reviewed-by: Sam Ravnborg Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] dt-bindings: display: mcde: Convert to YAML schema
Hi Linus, On Sun, Nov 15, 2020 at 07:51:45PM +0100, Linus Walleij wrote: > This moves the MCDE bindings over to using the YAML schema > to describe the ST-Ericsson MCDE display controller, > making use of the generic DSI controller schema. > > In the process we correct an error in the old text bindings: > the clocks for the SDI host controllers were specified as > part of the main MCDE component while they should be > specified in the DSI host controller subnodes. This was > a leftover from an earlier iteration of the first patch > series adding the MCDE. > > We also add the "port" node, we will use this when adding > LCD panels using the direct parallel interface DPI instead > of DSI. > > Cc: devicet...@vger.kernel.org > Signed-off-by: Linus Walleij > --- > ChangeLog v2->v3: > - Add resets to the bindings for future-proofing, set > additionalProperties: false > - Extend commit message to explain the the old bindings > were incorrect. Thanks, all looks good now. Reviewed-by: Sam Ravnborg Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Remove 2D accel code
On Sun, Nov 15, 2020 at 8:08 PM Sam Ravnborg wrote: > > Hi Patrik, > On Sun, Nov 15, 2020 at 07:51:27PM +0100, Patrik Jakobsson wrote: > > On Sun, Nov 15, 2020 at 7:32 PM Sam Ravnborg wrote: > > > > > > Hi Patrik. > > > On Sun, Nov 15, 2020 at 06:54:20PM +0100, Patrik Jakobsson wrote: > > > > 2D acceleration is only available on PSB and MRST and very slow on both > > > > platforms. CPU acceleration is faster so don't bother with 2D accel > > > > anymore. > > > > > > > > Signed-off-by: Patrik Jakobsson > > > > > > I like the patch and it follows up on the discussions to > > > remove accellerations that is not really a benefit. > > > But I tried to apply it on top of drm-misc-next and it failed in > > > framebuffer.c - did you remove psbfb_roll_ops in another patch? > > > > Hi Sam, > > Right, sorry I should have mentioned that it sits on top of > > https://patchwork.freedesktop.org/series/83153/ > > I thought I had seen something like this before. > So all is good - patch is: > Reviewed-by: Sam Ravnborg Great, thanks for the review. Patches are pushed to drm-misc-next > > Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: bail out of nouveau_channel_new if channel init fails
On Sun, Nov 15, 2020 at 6:43 PM Salvatore Bonaccorso wrote:
>
> Hi,
>
> On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote:
> > Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC
> > ioctl. This was reported by trinity[1] fuzzer.
> >
> > [ 71.073906] nouveau :01:00.0: crashme[1329]: channel failed to
> > initialise, -17
> > [ 71.081730] BUG: kernel NULL pointer dereference, address:
> > 00a0
> > [ 71.088928] #PF: supervisor read access in kernel mode
> > [ 71.094059] #PF: error_code(0x) - not-present page
> > [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0
> > [ 71.104842] Oops: [#1] SMP NOPTI
> > [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2
> > [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014
> > [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380
> > [nouveau]
> > [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31
> > c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10
> > <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41
> > [ 71.147074] RSP: 0018:b4a1809cfd38 EFLAGS: 00010246
> > [ 71.152526] RAX: RBX: 98cedbaa1d20 RCX:
> > 03bf
> > [ 71.159651] RDX: 03be RSI: RDI:
> > 00030160
> > [ 71.166774] RBP: 98cee776de00 R08: dc0144198a08 R09:
> > 98ceeefd4000
> > [ 71.173901] R10: 98cee7e81780 R11: 0001 R12:
> > b4a1809cfe08
> > [ 71.181214] R13: 98cee776d000 R14: 98cec519e000 R15:
> > 98cee776def0
> > [ 71.188339] FS: 7fd926250500() GS:98ceeac8()
> > knlGS:
> > [ 71.196418] CS: 0010 DS: ES: CR0: 80050033
> > [ 71.202155] CR2: 00a0 CR3: 000106622000 CR4:
> > 000406e0
> > [ 71.209297] Call Trace:
> > [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
> > [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm]
> > [ 71.222421] drm_ioctl+0x211/0x3c0 [drm]
> > [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
> > [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau]
> > [ 71.237285] ksys_ioctl+0x86/0xc0
> > [ 71.240595] __x64_sys_ioctl+0x16/0x20
> > [ 71.244340] do_syscall_64+0x4c/0x90
> > [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [ 71.253162] RIP: 0033:0x7fd925d4b88b
> > [ 71.256731] Code: Bad RIP value.
> > [ 71.259955] RSP: 002b:7ffc743592d8 EFLAGS: 0206 ORIG_RAX:
> > 0010
> > [ 71.267514] RAX: ffda RBX: RCX:
> > 7fd925d4b88b
> > [ 71.274637] RDX: 00601080 RSI: c0586442 RDI:
> > 0003
> > [ 71.281986] RBP: 7ffc74359340 R08: 7fd926016ce0 R09:
> > 7fd926016ce0
> > [ 71.289111] R10: 0003 R11: 0206 R12:
> > 00400620
> > [ 71.296235] R13: 7ffc74359420 R14: R15:
> >
> > [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek
> > snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg
> > snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp
> > snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco
> > pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev
> > i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod
> > t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea
> > sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci
> > drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci
> > firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod
> > [ 71.365269] CR2: 00a0
> >
> > simplified reproducer
> > -8<
> > /*
> > * gcc -o crashme crashme.c
> > * ./crashme /dev/dri/renderD128
> > */
> >
> > struct drm_nouveau_channel_alloc {
> > uint32_t fb_ctxdma_handle;
> > uint32_t tt_ctxdma_handle;
> >
> > int channel;
> > uint32_t pushbuf_domains;
> >
> > /* Notifier memory */
> > uint32_t notifier_handle;
> >
> > /* DRM-enforced subchannel assignments */
> > struct {
> > uint32_t handle;
> > uint32_t grclass;
> > } subchan[8];
> > uint32_t nr_subchan;
> > };
> >
> > static struct drm_nouveau_channel_alloc channel;
> >
> > int main(int argc, char *argv[]) {
> > int fd;
> > int rv;
> >
> > if (argc != 2)
> > die("usage: %s ", 0, argv[0]);
> >
> > if ((fd = open(argv[1], O_RDONLY)) == -1)
> > die("open %s", errno, argv[1]);
> >
> > if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 &&
> > errn
Re: [git pull] drm next pull for 5.10-rc1
On Mon, 16 Nov 2020 at 03:57, Linus Torvalds
wrote:
>
> On Tue, Nov 3, 2020 at 2:20 PM Kirill A. Shutemov
> wrote:
> >
> > On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> > > drm/nouveau/kms: Search for encoders' connectors properly
> >
> > This commit (09838c4efe9a) broke boot for me. These two hunks in
> > particular:
>
> Christ. It's been two weeks. I'm doing -rc4 today, and I still don't
> have the fix.
>
> The problem seems entirely obvious, as reported by Kirill: the nv50
> code unconditionally calls the "atomic_{dis,en}able()" functions, even
> when not everybody was converted.
>
> The fix seems to be to either just do the conversion of the remaining
> cases (which looks like just adding an argument to the remaining
> functions, and using that for the "atomic" callback), or the trivial
> suggestion by Kirill from two weeks ago:
>
> > I hacked up patch to use help->disable/help->enable if atomic_ versions
> > are NULL. It worked.
>
> Kirill, since the nouveau people aren't fixing this, can you just send
> me your tested patch?
>
> Lyude/Ben - let me just say that I think this is all a huge disgrace.
>
> You had a problem report with a bisected commit, a suggested fix, and
> two weeks later there's absolutely _nothing_.
I do have a fixes pull from Ben from Saturday in my inbox, I can send
it on this morning.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm nouveau urgent fixes for 5.10-rc4
Hi Linus, As mentioned I did have a fixes pull from Ben from after I'd sent you out stuff, it contains the fix for the regression reported in the rc1 thread along with two others. Dave. drm-fixes-2020-11-16: drm nouveau fixes for 5.10-rc4 nouveau: - atomic modesetting regression fix - ttm pre-nv50 fix - connector NULL ptr deref fix The following changes since commit 41f3ed2cac86ba533ce6a334a2e7fae5c7082946: Merge tag 'amd-drm-fixes-5.10-2020-11-12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-11-13 16:05:31 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-16 for you to fetch changes up to 8f598d15ee6577a56d6617d9e4151591db34d8fa: Merge branch 'linux-5.10' of git://github.com/skeggsb/linux into drm-fixes (2020-11-16 06:36:31 +1000) drm nouveau fixes for 5.10-rc4 nouveau: - atomic modesetting regression fix - ttm pre-nv50 fix - connector NULL ptr deref fix Alexander Kapshuk (1): drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth Ben Skeggs (1): drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50 Dave Airlie (1): Merge branch 'linux-5.10' of git://github.com/skeggsb/linux into drm-fixes Lyude Paul (1): drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere drivers/gpu/drm/nouveau/dispnv50/disp.c | 29 ++--- drivers/gpu/drm/nouveau/nouveau_bo.c| 3 +-- drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +- 3 files changed, 24 insertions(+), 22 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm nouveau urgent fixes for 5.10-rc4
The pull request you sent on Mon, 16 Nov 2020 06:41:34 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-16 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a6af8718b98e1cd37a9ea9a02269c79577fc9138 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm nouveau urgent fixes for 5.10-rc4
On Sun, Nov 15, 2020 at 12:41 PM Dave Airlie wrote: > > As mentioned I did have a fixes pull from Ben from after I'd sent you > out stuff, it contains the fix for the regression reported in the rc1 > thread along with two others. Thanks, pulled, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Samsung s6e63m0 improvements
Hi Linus, On Wed, Nov 11, 2020 at 12:46:48AM +0100, Linus Walleij wrote: > These improvements to the Samsung s6e63m0 makes SPI > writing and reading to the panel simpler, and add some > support required by the Samsung GT-I9070. > > Tested and working fine on the Samsung GT-I9070 mobile > phone with the MCDE display controller in DPI mode. > > Linus Walleij (5): > drm/panel: s6e63m0: Simplify SPI writing > drm/panel: s6e63m0: Implement reading from panel > drm/panel: s6e63m0: Add some explanations > drm/panel: s6e63m0: Support 3WIRE protocol > drm/panel: s6e63m0: Set up some display info I have looked through the series - and all looks good. Acked-by: Sam Ravnborg Please commit patches yourself. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: bail out of nouveau_channel_new if channel init fails
On Mon, 16 Nov 2020 at 05:19, Karol Herbst wrote:
>
> On Sun, Nov 15, 2020 at 6:43 PM Salvatore Bonaccorso
> wrote:
> >
> > Hi,
> >
> > On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote:
> > > Unprivileged user can crash kernel by using
> > > DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC
> > > ioctl. This was reported by trinity[1] fuzzer.
> > >
> > > [ 71.073906] nouveau :01:00.0: crashme[1329]: channel failed to
> > > initialise, -17
> > > [ 71.081730] BUG: kernel NULL pointer dereference, address:
> > > 00a0
> > > [ 71.088928] #PF: supervisor read access in kernel mode
> > > [ 71.094059] #PF: error_code(0x) - not-present page
> > > [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0
> > > [ 71.104842] Oops: [#1] SMP NOPTI
> > > [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2
> > > [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014
> > > [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380
> > > [nouveau]
> > > [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45
> > > 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43
> > > 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41
> > > [ 71.147074] RSP: 0018:b4a1809cfd38 EFLAGS: 00010246
> > > [ 71.152526] RAX: RBX: 98cedbaa1d20 RCX:
> > > 03bf
> > > [ 71.159651] RDX: 03be RSI: RDI:
> > > 00030160
> > > [ 71.166774] RBP: 98cee776de00 R08: dc0144198a08 R09:
> > > 98ceeefd4000
> > > [ 71.173901] R10: 98cee7e81780 R11: 0001 R12:
> > > b4a1809cfe08
> > > [ 71.181214] R13: 98cee776d000 R14: 98cec519e000 R15:
> > > 98cee776def0
> > > [ 71.188339] FS: 7fd926250500() GS:98ceeac8()
> > > knlGS:
> > > [ 71.196418] CS: 0010 DS: ES: CR0: 80050033
> > > [ 71.202155] CR2: 00a0 CR3: 000106622000 CR4:
> > > 000406e0
> > > [ 71.209297] Call Trace:
> > > [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
> > > [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm]
> > > [ 71.222421] drm_ioctl+0x211/0x3c0 [drm]
> > > [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
> > > [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau]
> > > [ 71.237285] ksys_ioctl+0x86/0xc0
> > > [ 71.240595] __x64_sys_ioctl+0x16/0x20
> > > [ 71.244340] do_syscall_64+0x4c/0x90
> > > [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > [ 71.253162] RIP: 0033:0x7fd925d4b88b
> > > [ 71.256731] Code: Bad RIP value.
> > > [ 71.259955] RSP: 002b:7ffc743592d8 EFLAGS: 0206 ORIG_RAX:
> > > 0010
> > > [ 71.267514] RAX: ffda RBX: RCX:
> > > 7fd925d4b88b
> > > [ 71.274637] RDX: 00601080 RSI: c0586442 RDI:
> > > 0003
> > > [ 71.281986] RBP: 7ffc74359340 R08: 7fd926016ce0 R09:
> > > 7fd926016ce0
> > > [ 71.289111] R10: 0003 R11: 0206 R12:
> > > 00400620
> > > [ 71.296235] R13: 7ffc74359420 R14: R15:
> > >
> > > [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek
> > > snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg
> > > snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp
> > > snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco
> > > pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev
> > > i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c
> > > sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper
> > > syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib
> > > ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata
> > > firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log
> > > dm_mod
> > > [ 71.365269] CR2: 00a0
> > >
> > > simplified reproducer
> > > -8<
> > > /*
> > > * gcc -o crashme crashme.c
> > > * ./crashme /dev/dri/renderD128
> > > */
> > >
> > > struct drm_nouveau_channel_alloc {
> > > uint32_t fb_ctxdma_handle;
> > > uint32_t tt_ctxdma_handle;
> > >
> > > int channel;
> > > uint32_t pushbuf_domains;
> > >
> > > /* Notifier memory */
> > > uint32_t notifier_handle;
> > >
> > > /* DRM-enforced subchannel assignments */
> > > struct {
> > > uint32_t handle;
> > > uint32_t grclass;
> > > } subchan[8];
> > > uint32_t nr_subchan;
> > > };
> > >
> > > static struct drm_nouveau_channel_alloc channel;
> > >
> > > int main(int argc, char *argv[]) {
> > > int fd;
> > > int rv;
> > >
> > >
Re: [PATCH 01/40] drm/amd/include/vega10_ip_offset: Mark _BASE structs as __maybe_unused
On Fri, 2020-11-13 at 13:48 +, Lee Jones wrote:
> This patch fixes nearly 400 warnings!
>
> These structures are too widely used in too many varying
> configurations to be split-up into different headers or moved into
> source files.
>
> Instead, we'll mark them as __maybe_unused which tells the compiler
> that we're aware they're being included into source files which do not
> make use of them - but we've looked into it, and it's okay.
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Type-Attributes.html#Type-Attributes
Wouldn't it be simpler to mark the struct definitions as maybe_unused
instead of the declarations?
And perhaps remove all the unnecessary zeroed declarations?
Something like this example?
---
drivers/gpu/drm/amd/include/arct_ip_offset.h | 353 +++
1 file changed, 145 insertions(+), 208 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/arct_ip_offset.h
b/drivers/gpu/drm/amd/include/arct_ip_offset.h
index a7791a9e1f90..9f2d6b832dd9 100644
--- a/drivers/gpu/drm/amd/include/arct_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/arct_ip_offset.h
@@ -33,215 +33,152 @@ struct IP_BASE_INSTANCE
struct IP_BASE
{
struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
-
-
-static const struct IP_BASE ATHUB_BASE={ { { { 0x0C20,
0x00012460, 0x00408C00, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } } } };
-static const struct IP_BASE CLK_BASE={ { { { 0x000120C0,
0x00016C00, 0x00401800, 0, 0, 0 } },
-{ { 0x000120E0, 0x00016E00,
0x00401C00, 0, 0, 0 } },
-{ { 0x00012100, 0x00017000,
0x00402000, 0, 0, 0 } },
-{ { 0x00012120, 0x00017200,
0x00402400, 0, 0, 0 } },
-{ { 0x000136C0, 0x0001B000,
0x0042D800, 0, 0, 0 } },
-{ { 0x00013720, 0x0001B200,
0x0042E400, 0, 0, 0 } },
-{ { 0x000125E0, 0x00017E00,
0x0040BC00, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } } } };
-static const struct IP_BASE DF_BASE={ { { { 0x7000,
0x000125C0, 0x0040B800, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } } } };
-static const struct IP_BASE FUSE_BASE={ { { { 0x000120A0,
0x00017400, 0x00401400, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } } } };
-static const struct IP_BASE GC_BASE={ { { { 0x2000,
0xA000, 0x00012160, 0x00402C00, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } } } };
-static const struct IP_BASE HDP_BASE={ { { { 0x0F20,
0x00012520, 0x0040A400, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } },
-{ { 0, 0, 0, 0, 0, 0 } } } };
-static const struct IP_BASE MMHUB_BASE={ { { { 0x00012440,
0x0001A000, 0x00408800, 0, 0,
Re: [PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
Hi, Bilal:
Bilal Wasim 於 2020年11月16日 週一 上午3:25寫道：
>
> Hi CK,
>
> On Sun, 15 Nov 2020 08:53:24 +0800
> Chun-Kuang Hu wrote:
>
> > Hi, Bilal:
> >
> > Please help to test this patch on your Chromebook elm, thanks.
> >
> > Regards,
> > Chun-Kuang Hu
>
> Just tried this patch on the Chromebook Elm, and it doesn't work. The
> HDMI screen remains black, though the rest of the system keeps on
> operating normally.
Could you print this information, so I could find out the solution for
both small hbp and elm.
vm->hfront_porch, vm->hback_porch, dsi_tmp_buf_bpp,
data_phy_cycles_byte, and the final horizontal_frontporch_byte,
horizontal_backporch_byte.
Regards,
Chun-Kuang.
>
> >
> > Chun-Kuang Hu 於 2020年11月15日 週日
> > 上午8:14寫道：
> > >
> > > From: CK Hu
> > >
> > > Using vm->hfront_porch + vm->hback_porch to calculate
> > > horizontal_backporch_byte would make it negtive, so
> > > use horizontal_backporch_byte itself to make it positive.
> > >
> > > Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel
> > > with small hfp or hbp")
> > >
> > > Signed-off-by: CK Hu
> > > Signed-off-by: Chun-Kuang Hu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_dsi.c | 53
> > > ++ 1 file changed, 18 insertions(+), 35
> > > deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > b/drivers/gpu/drm/mediatek/mtk_dsi.c index
> > > 4a188a942c38..2a64fdaed9a7 100644 ---
> > > a/drivers/gpu/drm/mediatek/mtk_dsi.c +++
> > > b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -444,7 +444,10 @@ static
> > > void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) u32
> > > horizontal_sync_active_byte; u32 horizontal_backporch_byte;
> > > u32 horizontal_frontporch_byte;
> > > + u32 horizontal_front_back_byte;
> > > + u32 data_phy_cycles_byte;
> > > u32 dsi_tmp_buf_bpp, data_phy_cycles;
> > > + u32 delta;
> > > struct mtk_phy_timing *timing = &dsi->phy_timing;
> > >
> > > struct videomode *vm = &dsi->vm;
> > > @@ -474,42 +477,22 @@ static void mtk_dsi_config_vdo_timing(struct
> > > mtk_dsi *dsi) data_phy_cycles = timing->lpx + timing->da_hs_prepare
> > > + timing->da_hs_zero + timing->da_hs_exit;
> > >
> > > - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > > - if ((vm->hfront_porch + vm->hback_porch) *
> > > dsi_tmp_buf_bpp >
> > > - data_phy_cycles * dsi->lanes + 18) {
> > > - horizontal_frontporch_byte =
> > > - vm->hfront_porch * dsi_tmp_buf_bpp -
> > > - (data_phy_cycles * dsi->lanes + 18)
> > > *
> > > - vm->hfront_porch /
> > > - (vm->hfront_porch +
> > > vm->hback_porch); -
> > > - horizontal_backporch_byte =
> > > - horizontal_backporch_byte -
> > > - (data_phy_cycles * dsi->lanes + 18)
> > > *
> > > - vm->hback_porch /
> > > - (vm->hfront_porch +
> > > vm->hback_porch);
> > > - } else {
> > > - DRM_WARN("HFP less than d-phy, FPS will
> > > under 60Hz\n");
> > > - horizontal_frontporch_byte =
> > > vm->hfront_porch *
> > > -
> > > dsi_tmp_buf_bpp;
> > > - }
> > > + delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 :
> > > 12; +
> > > + horizontal_frontporch_byte = vm->hfront_porch *
> > > dsi_tmp_buf_bpp;
> > > + horizontal_front_back_byte = horizontal_frontporch_byte +
> > > horizontal_backporch_byte;
> > > + data_phy_cycles_byte = data_phy_cycles * dsi->lanes + delta;
> > > +
> > > + if (horizontal_front_back_byte > data_phy_cycles_byte) {
> > > + horizontal_frontporch_byte -= data_phy_cycles_byte *
> > > +
> > > horizontal_frontporch_byte /
> > > +
> > > horizontal_front_back_byte; +
> > > + horizontal_backporch_byte -= data_phy_cycles_byte *
> > > +
> > > horizontal_backporch_byte /
> > > +
> > > horizontal_front_back_byte; } else {
> > > - if ((vm->hfront_porch + vm->hback_porch) *
> > > dsi_tmp_buf_bpp >
> > > - data_phy_cycles * dsi->lanes + 12) {
> > > - horizontal_frontporch_byte =
> > > - vm->hfront_porch * dsi_tmp_buf_bpp -
> > > - (data_phy_cycles * dsi->lanes + 12)
> > > *
> > > - vm->hfront_porch /
> > > - (vm->hfront_porch +
> > > vm->hback_porch);
> > > - horizontal_backporch_byte =
> > > horizontal_backporch_byte -
> > > - (data_phy_cycles * dsi->lanes + 12)
> > > *
> > > - vm->hback_porch /
> > > - (vm->hfront_porch +
> > > vm->hback_porch);
> > > - } else {
> > > -
Re: [PATCH 00/11] Decouple Mediatek DRM sub driver
Chun-Kuang Hu 於 2020年11月3日 週二 上午8:34寫道： > > mtk ccorr is controlled by DRM and MDP [1]. In order to share > mtk_ccorr driver for DRM and MDP, decouple Mediatek DRM sub driver > which include mtk_ccorr, so MDP could use this decoupled mtk_ccorr. Applied the whole series into mediatek-drm-next [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > [1] https://patchwork.kernel.org/patch/11140751/ > > CK Hu (9): > drm/mediatek: Move clk info from struct mtk_ddp_comp to sub driver > private data > drm/mediatek: Move regs info from struct mtk_ddp_comp to sub driver > private data > drm/mediatek: Remove irq in struct mtk_ddp_comp > drm/mediatek: Use struct cmdq_client_reg to gather cmdq variable > drm/mediatek: Move cmdq_reg info from struct mtk_ddp_comp to sub > driver private data > drm/mediatek: Change sub driver interface from mtk_ddp_comp to device > drm/mediatek: Register vblank callback function > drm/mediatek: DRM driver directly refer to sub driver's function > drm/mediatek: Move mtk_ddp_comp_init() from sub driver to DRM driver > > Chun-Kuang Hu (2): > drm/mediatek: Get CMDQ client register for all ddp component > drm/mediatek: Use correct device pointer to get CMDQ client register > > drivers/gpu/drm/mediatek/mtk_disp_color.c | 86 ++--- > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 69 > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 215 ++- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 169 + > drivers/gpu/drm/mediatek/mtk_dpi.c | 44 +-- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 ++-- > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 - > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 389 > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 100 ++--- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- > drivers/gpu/drm/mediatek/mtk_dsi.c | 47 +-- > 12 files changed, 658 insertions(+), 569 deletions(-) > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_drv.h > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warnings after merge of the drm tree
Hi all,
On Thu, 5 Nov 2020 17:50:31 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (htmldocs) produced
> these warnings:
>
> include/linux/dma-buf-map.h:106: warning: Excess function parameter 'vaddr'
> description in 'DMA_BUF_MAP_INIT_VADDR'
> include/linux/dma-buf-map.h:106: warning: Function parameter or member
> 'vaddr_' not described in 'DMA_BUF_MAP_INIT_VADDR'
> include/linux/dma-buf-map.h:106: warning: Excess function parameter 'vaddr'
> description in 'DMA_BUF_MAP_INIT_VADDR'
>
> Introduced by commit
>
> 20e76f1a7059 ("dma-buf: Use struct dma_buf_map in dma_buf_vunmap()
> interfaces")
I am still getting these warnings.
--
Cheers,
Stephen Rothwell
pgpvS7F1nm1KX.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Samsung s6e63m0 improvements
On Sun, Nov 15, 2020 at 11:55 PM Sam Ravnborg wrote: > I have looked through the series - and all looks good. > Acked-by: Sam Ravnborg > > Please commit patches yourself. Thanks a lot Sam, I pushed the patches. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the drm tree
Hi Stephen,
On Thu, 5 Nov 2020 18:02:50 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (htmldocs) produced
> this warning:
>
> Documentation/gpu/drm-kms:466: drivers/gpu/drm/drm_crtc.c:236: WARNING:
> Unexpected indentation.
> Documentation/gpu/drm-kms:466: drivers/gpu/drm/drm_crtc.c:237: WARNING: Block
> quote ends without a blank line; unexpected unindent.
> Documentation/gpu/drm-kms:472: drivers/gpu/drm/drm_blend.c:203: WARNING:
> Unexpected indentation.
> Documentation/gpu/drm-kms:472: drivers/gpu/drm/drm_blend.c:204: WARNING:
> Block quote ends without a blank line; unexpected unindent.
>
> Introduced by commit
>
> 5c759eda9b04 ("drm: Introduce plane and CRTC scaling filter properties")
I am still getting these warnings.
--
Cheers,
Stephen Rothwell
pgptR46me7vHu.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/40] drm/lima/lima_drv: Demote kernel-doc formatting abuse
Applied to drm-misc-next.
On Fri, Nov 13, 2020 at 9:50 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/lima/lima_drv.c:264: warning: cannot understand function
> prototype: 'const struct drm_driver lima_drm_driver = '
>
> Cc: Qiang Yu
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: l...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/lima/lima_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
> index d497af91d8505..7b8d7178d09aa 100644
> --- a/drivers/gpu/drm/lima/lima_drv.c
> +++ b/drivers/gpu/drm/lima/lima_drv.c
> @@ -255,7 +255,7 @@ static const struct drm_ioctl_desc
> lima_drm_driver_ioctls[] = {
>
> DEFINE_DRM_GEM_FOPS(lima_drm_driver_fops);
>
> -/**
> +/*
> * Changelog:
> *
> * - 1.1.0 - add heap buffer support
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 23/40] drm/lima/lima_sched: Remove unused and unnecessary variable 'ret'
Applied to drm-misc-next. On Fri, Nov 13, 2020 at 9:50 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/lima/lima_sched.c: In function ‘lima_sched_run_job’: > drivers/gpu/drm/lima/lima_sched.c:227:20: warning: variable ‘ret’ set but > not used [-Wunused-but-set-variable] > > Cc: Qiang Yu > Cc: David Airlie > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: "Christian König" > Cc: dri-devel@lists.freedesktop.org > Cc: l...@lists.freedesktop.org > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/lima/lima_sched.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/lima/lima_sched.c > b/drivers/gpu/drm/lima/lima_sched.c > index a070a85f8f368..63b4c5643f9cd 100644 > --- a/drivers/gpu/drm/lima/lima_sched.c > +++ b/drivers/gpu/drm/lima/lima_sched.c > @@ -224,7 +224,6 @@ static struct dma_fence *lima_sched_run_job(struct > drm_sched_job *job) > struct lima_sched_pipe *pipe = to_lima_pipe(job->sched); > struct lima_device *ldev = pipe->ldev; > struct lima_fence *fence; > - struct dma_fence *ret; > int i, err; > > /* after GPU reset */ > @@ -246,7 +245,7 @@ static struct dma_fence *lima_sched_run_job(struct > drm_sched_job *job) > /* for caller usage of the fence, otherwise irq handler > * may consume the fence before caller use it > */ > - ret = dma_fence_get(task->fence); > + dma_fence_get(task->fence); > > pipe->current_task = task; > > -- > 2.25.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/lima: simplify the return expression of lima_devfreq_target
Applied to drm-misc-next.
On Sat, Sep 19, 2020 at 6:43 PM Qiang Yu wrote:
>
> Looks good for me, patch is:
> Reviewed-by: Qiang Yu
>
> Regards,
> Qiang
>
> On Sat, Sep 19, 2020 at 5:47 PM Liu Shixin wrote:
> >
> > Simplify the return expression.
> >
> > Signed-off-by: Liu Shixin
> > ---
> > drivers/gpu/drm/lima/lima_devfreq.c | 7 +--
> > 1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> > b/drivers/gpu/drm/lima/lima_devfreq.c
> > index bbe02817721b..5914442936ed 100644
> > --- a/drivers/gpu/drm/lima/lima_devfreq.c
> > +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> > @@ -35,18 +35,13 @@ static int lima_devfreq_target(struct device *dev,
> > unsigned long *freq,
> >u32 flags)
> > {
> > struct dev_pm_opp *opp;
> > - int err;
> >
> > opp = devfreq_recommended_opp(dev, freq, flags);
> > if (IS_ERR(opp))
> > return PTR_ERR(opp);
> > dev_pm_opp_put(opp);
> >
> > - err = dev_pm_opp_set_rate(dev, *freq);
> > - if (err)
> > - return err;
> > -
> > - return 0;
> > + return dev_pm_opp_set_rate(dev, *freq);
> > }
> >
> > static void lima_devfreq_reset(struct lima_devfreq *devfreq)
> > --
> > 2.25.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 Resend 1/2] drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
Applied to drm-misc-next.
On Wed, Oct 28, 2020 at 2:44 PM Viresh Kumar wrote:
>
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
> Reviewed-by: Qiang Yu
> Signed-off-by: Viresh Kumar
>
> ---
> V2: Applied Reviewed by tag.
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 6 +-
> drivers/gpu/drm/lima/lima_devfreq.h | 1 -
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> b/drivers/gpu/drm/lima/lima_devfreq.c
> index bbe02817721b..cd290d866a04 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.c
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -105,10 +105,7 @@ void lima_devfreq_fini(struct lima_device *ldev)
> devfreq->devfreq = NULL;
> }
>
> - if (devfreq->opp_of_table_added) {
> - dev_pm_opp_of_remove_table(ldev->dev);
> - devfreq->opp_of_table_added = false;
> - }
> + dev_pm_opp_of_remove_table(ldev->dev);
>
> if (devfreq->regulators_opp_table) {
> dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
> @@ -162,7 +159,6 @@ int lima_devfreq_init(struct lima_device *ldev)
> ret = dev_pm_opp_of_add_table(dev);
> if (ret)
> goto err_fini;
> - ldevfreq->opp_of_table_added = true;
>
> lima_devfreq_reset(ldevfreq);
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
> b/drivers/gpu/drm/lima/lima_devfreq.h
> index 5eed2975a375..2d9b3008ce77 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.h
> +++ b/drivers/gpu/drm/lima/lima_devfreq.h
> @@ -18,7 +18,6 @@ struct lima_devfreq {
> struct opp_table *clkname_opp_table;
> struct opp_table *regulators_opp_table;
> struct thermal_cooling_device *cooling;
> - bool opp_of_table_added;
>
> ktime_t busy_time;
> ktime_t idle_time;
> --
> 2.25.0.rc1.19.g042ed3e048af
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/lima: dev_pm_opp_put_*() accepts NULL argument
Looks good for me, patch is:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Fri, Nov 6, 2020 at 3:05 PM Viresh Kumar wrote:
>
> The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
> there is no need for us to carry the extra check. Drop them.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> b/drivers/gpu/drm/lima/lima_devfreq.c
> index bbe02817721b..e7b7b8dfd792 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.c
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -110,15 +110,10 @@ void lima_devfreq_fini(struct lima_device *ldev)
> devfreq->opp_of_table_added = false;
> }
>
> - if (devfreq->regulators_opp_table) {
> - dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
> - devfreq->regulators_opp_table = NULL;
> - }
> -
> - if (devfreq->clkname_opp_table) {
> - dev_pm_opp_put_clkname(devfreq->clkname_opp_table);
> - devfreq->clkname_opp_table = NULL;
> - }
> + dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
> + dev_pm_opp_put_clkname(devfreq->clkname_opp_table);
> + devfreq->regulators_opp_table = NULL;
> + devfreq->clkname_opp_table = NULL;
> }
>
> int lima_devfreq_init(struct lima_device *ldev)
> --
> 2.25.0.rc1.19.g042ed3e048af
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/msm/dp: promote irq_hpd handle to handle link training correctly
Some dongles require link training done at irq_hpd request instead
of plugin request. This patch promote irq_hpd handler to handle link
training and setup hpd_state correctly.
Changes in V2:
-- fix Fixes tag text
Fixes: fdaf9a5e3c15 ("drm/msm/dp: fixes wrong connection state caused by
failure of link training")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0c0573ad34e6..27e7e27b8b90 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -449,10 +449,9 @@ static int dp_display_handle_irq_hpd(struct
dp_display_private *dp)
sink_request = dp->link->sink_request;
if (sink_request & DS_PORT_STATUS_CHANGED) {
- dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
if (dp_display_is_sink_count_zero(dp)) {
DRM_DEBUG_DP("sink count is zero, nothing to do\n");
- return 0;
+ return -ENOTCONN;
}
return dp_display_process_hpd_high(dp);
@@ -469,7 +468,9 @@ static int dp_display_handle_irq_hpd(struct
dp_display_private *dp)
static int dp_display_usbpd_attention_cb(struct device *dev)
{
int rc = 0;
+ u32 sink_request;
struct dp_display_private *dp;
+ struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -483,10 +484,26 @@ static int dp_display_usbpd_attention_cb(struct device
*dev)
return -ENODEV;
}
+ hpd = dp->usbpd;
+
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
- if (!rc)
- dp_display_handle_irq_hpd(dp);
+ if (!rc) {
+ sink_request = dp->link->sink_request;
+ if (sink_request & DS_PORT_STATUS_CHANGED) {
+ /* same as unplugged */
+ hpd->hpd_high = 0;
+ dp->hpd_state = ST_DISCONNECT_PENDING;
+ dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
+ }
+
+ rc = dp_display_handle_irq_hpd(dp);
+
+ if (!rc && (sink_request & DS_PORT_STATUS_CHANGED)) {
+ hpd->hpd_high = 1;
+ dp->hpd_state = ST_CONNECT_PENDING;
+ }
+ }
return rc;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 12/17] ARM: tegra: Add interconnect properties to Tegra30 device-tree
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra30.dtsi | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index aeae8c092d41..2caf6cc6f4b1 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -210,6 +210,17 @@ dc@5420 {
nvidia,head = <0>;
+ interconnects = <&mc TEGRA30_MC_DISPLAY0A &emc>,
+ <&mc TEGRA30_MC_DISPLAY0B &emc>,
+ <&mc TEGRA30_MC_DISPLAY1B &emc>,
+ <&mc TEGRA30_MC_DISPLAY0C &emc>,
+ <&mc TEGRA30_MC_DISPLAYHC &emc>;
+ interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -229,6 +240,17 @@ dc@5424 {
nvidia,head = <1>;
+ interconnects = <&mc TEGRA30_MC_DISPLAY0AB &emc>,
+ <&mc TEGRA30_MC_DISPLAY0BB &emc>,
+ <&mc TEGRA30_MC_DISPLAY1BB &emc>,
+ <&mc TEGRA30_MC_DISPLAY0CB &emc>,
+ <&mc TEGRA30_MC_DISPLAYHCB &emc>;
+ interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -748,15 +770,18 @@ mc: memory-controller@7000f000 {
#iommu-cells = <1>;
#reset-cells = <1>;
+ #interconnect-cells = <1>;
};
- memory-controller@7000f400 {
+ emc: memory-controller@7000f400 {
compatible = "nvidia,tegra30-emc";
reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA30_CLK_EMC>;
nvidia,memory-controller = <&mc>;
+
+ #interconnect-cells = <0>;
};
fuse@7000f800 {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] vc4: Convert to drm_atomic_helper_commit
Hi, Here's a conversion of vc4 to remove the hand-rolled atomic_commit helper from vc4 in favour of the generic one. This requires some rework of vc4, but also a new hook and some documentation for corner-cases in the DRM core that have been reported and explained by Daniel recently. Let me know what you think, Maxime Maxime Ripard (8): drm: Introduce an atomic_commit_setup function drm: Document use-after-free gotcha with private objects drm/vc4: kms: Move HVS state helpers around drm/vc4: kms: Simplify a bit the private obj state hooks drm/vc4: Simplify a bit the global atomic_check drm/vc4: kms: Wait on previous FIFO users before a commit drm/vc4: kms: Remove async modeset semaphore drm/vc4: kms: Convert to atomic helpers drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/vc4/vc4_crtc.c | 13 -- drivers/gpu/drm/vc4/vc4_drv.h| 2 - drivers/gpu/drm/vc4/vc4_kms.c| 269 +++ include/drm/drm_atomic.h | 18 ++ include/drm/drm_modeset_helper_vtables.h | 18 ++ 6 files changed, 173 insertions(+), 153 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 4/6] RDMA/mlx5: Support dma-buf based userspace memory region
On Fri, Nov 13, 2020 at 03:51:20AM +, Xiong, Jianxin wrote:
> > > +static void mlx5_ib_dmabuf_invalidate_cb(struct dma_buf_attachment
> > > +*attach) {
> > > + struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> > > + struct mlx5_ib_mr *mr = umem_dmabuf->private;
> > > +
> > > + dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> > > +
> > > + if (mr)
> >
> > I don't think this 'if (mr)' test is needed anymore? I certainly prefer it
> > gone as it is kind of messy. I expect unmapping the dma to ensure this
> > function is not running, and won't run again.
>
> It is still needed. When the dma-buf moves, the callback function of every
> attached importer is invoked, regardless if the importer has mapped the dma
> or not.
>
> >
> > > +/**
> > > + * mlx5_ib_fence_dmabuf_mr - Stop all access to the dmabuf MR
> > > + * @mr: to fence
> > > + *
> > > + * On return no parallel threads will be touching this MR and no DMA
> > > +will be
> > > + * active.
> > > + */
> > > +void mlx5_ib_fence_dmabuf_mr(struct mlx5_ib_mr *mr) {
> > > + struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(mr->umem);
> > > +
> > > + /* Prevent new page faults and prefetch requests from succeeding */
> > > + xa_erase(&mr->dev->odp_mkeys, mlx5_base_mkey(mr->mmkey.key));
> > > +
> > > + /* Wait for all running page-fault handlers to finish. */
> > > + synchronize_srcu(&mr->dev->odp_srcu);
> > > +
> > > + wait_event(mr->q_deferred_work,
> > > +!atomic_read(&mr->num_deferred_work));
> > > +
> > > + dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> > > + mlx5_mr_cache_invalidate(mr);
> > > + umem_dmabuf->private = NULL;
> > > + ib_umem_dmabuf_unmap_pages(umem_dmabuf);
> > > + dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
> > > +
> > > + if (!mr->cache_ent) {
> > > + mlx5_core_destroy_mkey(mr->dev->mdev, &mr->mmkey);
> > > + WARN_ON(mr->descs);
> > > + }
> >
> > I didn't check carefully, but are you sure this destroy_mkey should be
> > here??
>
> To my understanding, yes. This is similar to what dma_fence_odp_mr() does,
> just inlined here since it's not called from other places.
I think you should put the calls to dma_buf_dynamic_attach() and
dma_buf_detach() into mlx5, it makes the whole thing a little cleaner,
then the umem->private isn't needed any more either.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
Hi CK,
On Sun, 15 Nov 2020 08:53:24 +0800
Chun-Kuang Hu wrote:
> Hi, Bilal:
>
> Please help to test this patch on your Chromebook elm, thanks.
>
> Regards,
> Chun-Kuang Hu
Just tried this patch on the Chromebook Elm, and it doesn't work. The
HDMI screen remains black, though the rest of the system keeps on
operating normally.
>
> Chun-Kuang Hu 於 2020年11月15日 週日
> 上午8:14寫道：
> >
> > From: CK Hu
> >
> > Using vm->hfront_porch + vm->hback_porch to calculate
> > horizontal_backporch_byte would make it negtive, so
> > use horizontal_backporch_byte itself to make it positive.
> >
> > Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel
> > with small hfp or hbp")
> >
> > Signed-off-by: CK Hu
> > Signed-off-by: Chun-Kuang Hu
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 53
> > ++ 1 file changed, 18 insertions(+), 35
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c index
> > 4a188a942c38..2a64fdaed9a7 100644 ---
> > a/drivers/gpu/drm/mediatek/mtk_dsi.c +++
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -444,7 +444,10 @@ static
> > void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) u32
> > horizontal_sync_active_byte; u32 horizontal_backporch_byte;
> > u32 horizontal_frontporch_byte;
> > + u32 horizontal_front_back_byte;
> > + u32 data_phy_cycles_byte;
> > u32 dsi_tmp_buf_bpp, data_phy_cycles;
> > + u32 delta;
> > struct mtk_phy_timing *timing = &dsi->phy_timing;
> >
> > struct videomode *vm = &dsi->vm;
> > @@ -474,42 +477,22 @@ static void mtk_dsi_config_vdo_timing(struct
> > mtk_dsi *dsi) data_phy_cycles = timing->lpx + timing->da_hs_prepare
> > + timing->da_hs_zero + timing->da_hs_exit;
> >
> > - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > - if ((vm->hfront_porch + vm->hback_porch) *
> > dsi_tmp_buf_bpp >
> > - data_phy_cycles * dsi->lanes + 18) {
> > - horizontal_frontporch_byte =
> > - vm->hfront_porch * dsi_tmp_buf_bpp -
> > - (data_phy_cycles * dsi->lanes + 18)
> > *
> > - vm->hfront_porch /
> > - (vm->hfront_porch +
> > vm->hback_porch); -
> > - horizontal_backporch_byte =
> > - horizontal_backporch_byte -
> > - (data_phy_cycles * dsi->lanes + 18)
> > *
> > - vm->hback_porch /
> > - (vm->hfront_porch +
> > vm->hback_porch);
> > - } else {
> > - DRM_WARN("HFP less than d-phy, FPS will
> > under 60Hz\n");
> > - horizontal_frontporch_byte =
> > vm->hfront_porch *
> > -
> > dsi_tmp_buf_bpp;
> > - }
> > + delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 :
> > 12; +
> > + horizontal_frontporch_byte = vm->hfront_porch *
> > dsi_tmp_buf_bpp;
> > + horizontal_front_back_byte = horizontal_frontporch_byte +
> > horizontal_backporch_byte;
> > + data_phy_cycles_byte = data_phy_cycles * dsi->lanes + delta;
> > +
> > + if (horizontal_front_back_byte > data_phy_cycles_byte) {
> > + horizontal_frontporch_byte -= data_phy_cycles_byte *
> > +
> > horizontal_frontporch_byte /
> > +
> > horizontal_front_back_byte; +
> > + horizontal_backporch_byte -= data_phy_cycles_byte *
> > +
> > horizontal_backporch_byte /
> > +
> > horizontal_front_back_byte; } else {
> > - if ((vm->hfront_porch + vm->hback_porch) *
> > dsi_tmp_buf_bpp >
> > - data_phy_cycles * dsi->lanes + 12) {
> > - horizontal_frontporch_byte =
> > - vm->hfront_porch * dsi_tmp_buf_bpp -
> > - (data_phy_cycles * dsi->lanes + 12)
> > *
> > - vm->hfront_porch /
> > - (vm->hfront_porch +
> > vm->hback_porch);
> > - horizontal_backporch_byte =
> > horizontal_backporch_byte -
> > - (data_phy_cycles * dsi->lanes + 12)
> > *
> > - vm->hback_porch /
> > - (vm->hfront_porch +
> > vm->hback_porch);
> > - } else {
> > - DRM_WARN("HFP less than d-phy, FPS will
> > under 60Hz\n");
> > - horizontal_frontporch_byte =
> > vm->hfront_porch *
> > -
> > dsi_tmp_buf_bpp;
> > - }
> > + DRM_WARN("HFP + HBP less than d-phy, FPS will under
> > 60Hz\n"); }
> >
> > writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> > --
> > 2.17.1
> >
Thanks,
Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mail
[PATCH v1 3/4] drm: bridge: cdns-mhdp8546: Remove setting of bus format using connector info
As we are using bus negotiations for selecting bus format
remove the setting of bus format using the connector info
structure.
Signed-off-by: Yuti Amonkar
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 623eadb8948f..6f900bceb50c 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1630,7 +1630,6 @@ static const struct drm_connector_funcs
cdns_mhdp_conn_funcs = {
static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
{
- u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
struct drm_connector *conn = &mhdp->connector;
struct drm_bridge *bridge = &mhdp->bridge;
int ret;
@@ -1651,11 +1650,6 @@ static int cdns_mhdp_connector_init(struct
cdns_mhdp_device *mhdp)
drm_connector_helper_add(conn, &cdns_mhdp_conn_helper_funcs);
- ret = drm_display_info_set_bus_formats(&conn->display_info,
- &bus_format, 1);
- if (ret)
- return ret;
-
ret = drm_connector_attach_encoder(conn, bridge->encoder);
if (ret) {
dev_err(mhdp->dev, "Failed to attach connector to encoder\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/vc4: kms: Convert to atomic helpers
Now that the semaphore is gone, our atomic_commit implementation is
basically drm_atomic_helper_commit with a somewhat custom commit_tail,
the main difference being that we're using wait_for_flip_done instead of
wait_for_vblanks used in the drm_atomic_helper_commit_tail helper.
Let's switch to using drm_atomic_helper_commit.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 112 +-
1 file changed, 3 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 79ab7b8a5e0e..ede5d2b6ac65 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -333,8 +333,7 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
}
}
-static void
-vc4_atomic_complete_commit(struct drm_atomic_state *state)
+static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -357,10 +356,6 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
if (vc4->hvs->hvs5)
clk_set_min_rate(hvs->core_clk, 5);
- drm_atomic_helper_wait_for_fences(dev, state, false);
-
- drm_atomic_helper_wait_for_dependencies(state);
-
old_hvs_state = vc4_hvs_get_old_global_state(state);
if (!old_hvs_state)
return;
@@ -408,20 +403,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
- drm_atomic_helper_commit_cleanup_done(state);
-
if (vc4->hvs->hvs5)
clk_set_min_rate(hvs->core_clk, 0);
-
- drm_atomic_state_put(state);
-}
-
-static void commit_work(struct work_struct *work)
-{
- struct drm_atomic_state *state = container_of(work,
- struct drm_atomic_state,
- commit_work);
- vc4_atomic_complete_commit(state);
}
static int vc4_atomic_commit_setup(struct drm_atomic_state *state)
@@ -454,96 +437,6 @@ static int vc4_atomic_commit_setup(struct drm_atomic_state
*state)
return 0;
}
-/**
- * vc4_atomic_commit - commit validated state object
- * @dev: DRM device
- * @state: the driver state object
- * @nonblock: nonblocking commit
- *
- * This function commits a with drm_atomic_helper_check() pre-validated state
- * object. This can still fail when e.g. the framebuffer reservation fails. For
- * now this doesn't implement asynchronous commits.
- *
- * RETURNS
- * Zero for success or -errno.
- */
-static int vc4_atomic_commit(struct drm_device *dev,
-struct drm_atomic_state *state,
-bool nonblock)
-{
- int ret;
-
- if (state->async_update) {
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret) {
- up(&vc4->async_modeset);
- return ret;
- }
-
- drm_atomic_helper_async_commit(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
-
- return 0;
- }
-
- /* We know for sure we don't want an async update here. Set
-* state->legacy_cursor_update to false to prevent
-* drm_atomic_helper_setup_commit() from auto-completing
-* commit->flip_done.
-*/
- state->legacy_cursor_update = false;
- ret = drm_atomic_helper_setup_commit(state, nonblock);
- if (ret)
- return ret;
-
- INIT_WORK(&state->commit_work, commit_work);
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- if (!nonblock) {
- ret = drm_atomic_helper_wait_for_fences(dev, state, true);
- if (ret) {
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
- }
- }
-
- /*
-* This is the point of no return - everything below never fails except
-* when the hw goes bonghits. Which means we can commit the new state on
-* the software side now.
-*/
-
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-
Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
13.11.2020 19:15, Mark Brown пишет: > On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote: >> 13.11.2020 17:29, Mark Brown пишет: > >>> It's not clear if it matters - it's more a policy decision on the part >>> of the driver about what it thinks safe error handling is. If it's not > >> If regulator_get() returns a dummy regulator, then this means that >> regulator isn't specified in a device-tree. But then the only way for a >> consumer driver to check whether regulator is dummy, is to check >> presence of the supply property in a device-tree. > > My point here is that the driver shouldn't be checking for a dummy > regulator, the driver should be checking the features that are provided > to it by the regulator and handling those. I understand yours point, but then we need dummy regulator to provide all the features, and currently it does the opposite. > It doesn't matter if this is > a dummy regulator or an actual regulator with limited features, the > effect is the same and the handling should be the same. If the driver > is doing anything to handle dummy regulators explicitly as dummy > regulators it is doing it wrong. It matters because dummy regulator errors out all checks and changes other than enable/disable, instead of accepting them. If we could add an option for dummy regulator to succeed all the checks and accept all the values, then it could become more usable. >> We want to emit error messages when something goes wrong, for example >> when regulator voltage fails to change. It's fine that voltage changes >> are failing for a dummy regulator, but then consumer driver shouldn't >> recognize it as a error condition. > > If you're fine with that you should also be fine with any other > regulator for which you failed to enumerate any voltages which you can > set. It's not fine. In the case of this driver the dummy regulator should succeed instead of failing. >> The regulator_get_optional() provides a more consistent and >> straightforward way for consumer drivers to check presence of a physical >> voltage regulator in comparison to dealing with a regulator_get(). The >> dummy regulator is nice to use when there is no need to change >> regulator's voltage, which doesn't work for a dummy regulator. > > To repeat you should *only* be using regulator_get_optional() in the > case where the supply may be physically absent which is not the case > here. > Alright, but then we either need to improve regulator core to make dummy regulator a bit more usable, or continue to work around it in drivers. What should we do? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 02/17] memory: tegra124-emc: Make driver modular
Add modularization support to the Tegra124 EMC driver, which now can be
compiled as a loadable kernel module.
Note that EMC clock must be registered at clk-init time, otherwise PLLM
will be disabled as unused clock at boot time if EMC driver is compiled
as a module. Hence add a prepare/complete callbacks. similarly to what is
done for the Tegra20/30 EMC drivers.
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/Kconfig| 3 ++
drivers/clk/tegra/Makefile | 2 +-
drivers/clk/tegra/clk-tegra124-emc.c | 41
drivers/clk/tegra/clk-tegra124.c | 26 --
drivers/clk/tegra/clk.h | 18
drivers/memory/tegra/Kconfig | 3 +-
drivers/memory/tegra/tegra124-emc.c | 31 ++---
include/linux/clk/tegra.h| 8 ++
include/soc/tegra/emc.h | 16 ---
9 files changed, 106 insertions(+), 42 deletions(-)
delete mode 100644 include/soc/tegra/emc.h
diff --git a/drivers/clk/tegra/Kconfig b/drivers/clk/tegra/Kconfig
index deaa4605824c..90df619dc087 100644
--- a/drivers/clk/tegra/Kconfig
+++ b/drivers/clk/tegra/Kconfig
@@ -7,3 +7,6 @@ config TEGRA_CLK_DFLL
depends on ARCH_TEGRA_124_SOC || ARCH_TEGRA_210_SOC
select PM_OPP
def_bool y
+
+config TEGRA124_CLK_EMC
+ bool
diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index eec2313fd37e..7b1816856eb5 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC) +=
clk-tegra20-emc.o
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += clk-tegra114.o
obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124.o
obj-$(CONFIG_TEGRA_CLK_DFLL) += clk-tegra124-dfll-fcpu.o
-obj-$(CONFIG_TEGRA124_EMC) += clk-tegra124-emc.o
+obj-$(CONFIG_TEGRA124_CLK_EMC) += clk-tegra124-emc.o
obj-$(CONFIG_ARCH_TEGRA_132_SOC) += clk-tegra124.o
obj-y += cvb.o
obj-$(CONFIG_ARCH_TEGRA_210_SOC) += clk-tegra210.o
diff --git a/drivers/clk/tegra/clk-tegra124-emc.c
b/drivers/clk/tegra/clk-tegra124-emc.c
index 745f9faa98d8..bdf6f4a51617 100644
--- a/drivers/clk/tegra/clk-tegra124-emc.c
+++ b/drivers/clk/tegra/clk-tegra124-emc.c
@@ -11,7 +11,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -21,7 +23,6 @@
#include
#include
-#include
#include "clk.h"
@@ -80,6 +81,9 @@ struct tegra_clk_emc {
int num_timings;
struct emc_timing *timings;
spinlock_t *lock;
+
+ tegra124_emc_prepare_timing_change_cb *prepare_timing_change;
+ tegra124_emc_complete_timing_change_cb *complete_timing_change;
};
/* Common clock framework callback implementations */
@@ -176,6 +180,9 @@ static struct tegra_emc *emc_ensure_emc_driver(struct
tegra_clk_emc *tegra)
if (tegra->emc)
return tegra->emc;
+ if (!tegra->prepare_timing_change || !tegra->complete_timing_change)
+ return NULL;
+
if (!tegra->emc_node)
return NULL;
@@ -241,7 +248,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
div = timing->parent_rate / (timing->rate / 2) - 2;
- err = tegra_emc_prepare_timing_change(emc, timing->rate);
+ err = tegra->prepare_timing_change(emc, timing->rate);
if (err)
return err;
@@ -259,7 +266,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
spin_unlock_irqrestore(tegra->lock, flags);
- tegra_emc_complete_timing_change(emc, timing->rate);
+ tegra->complete_timing_change(emc, timing->rate);
clk_hw_reparent(&tegra->hw, __clk_get_hw(timing->parent));
clk_disable_unprepare(tegra->prev_parent);
@@ -473,8 +480,8 @@ static const struct clk_ops tegra_clk_emc_ops = {
.get_parent = emc_get_parent,
};
-struct clk *tegra_clk_register_emc(void __iomem *base, struct device_node *np,
- spinlock_t *lock)
+struct clk *tegra124_clk_register_emc(void __iomem *base, struct device_node
*np,
+ spinlock_t *lock)
{
struct tegra_clk_emc *tegra;
struct clk_init_data init;
@@ -538,3 +545,27 @@ struct clk *tegra_clk_register_emc(void __iomem *base,
struct device_node *np,
return clk;
};
+
+void tegra124_clk_set_emc_callbacks(tegra124_emc_prepare_timing_change_cb
*prep_cb,
+ tegra124_emc_complete_timing_change_cb
*complete_cb)
+{
+ struct clk *clk = __clk_lookup("emc");
+ struct tegra_clk_emc *tegra;
+ struct clk_hw *hw;
+
+ if (clk) {
+ hw = __clk_get_hw(clk);
+ tegra = container_of(hw, struct tegra_clk_emc, hw);
+
+ tegra->prepare_timing_change = prep_cb;
+ tegra->complete_timing_change = complete_cb;
+
[PATCH v9 06/17] drm/tegra: dc: Extend debug stats with total number of events
It's useful to know the total number of underflow events and currently
the debug stats are getting reset each time CRTC is being disabled. Let's
account the overall number of events that doesn't get a reset.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 10 ++
drivers/gpu/drm/tegra/dc.h | 5 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 5c587cfd1bb2..b6676f1fe358 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1539,6 +1539,11 @@ static int tegra_dc_show_stats(struct seq_file *s, void
*data)
seq_printf(s, "underflow: %lu\n", dc->stats.underflow);
seq_printf(s, "overflow: %lu\n", dc->stats.overflow);
+ seq_printf(s, "frames total: %lu\n", dc->stats.frames_total);
+ seq_printf(s, "vblank total: %lu\n", dc->stats.vblank_total);
+ seq_printf(s, "underflow total: %lu\n", dc->stats.underflow_total);
+ seq_printf(s, "overflow total: %lu\n", dc->stats.overflow_total);
+
return 0;
}
@@ -2310,6 +2315,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): frame end\n", __func__);
*/
+ dc->stats.frames_total++;
dc->stats.frames++;
}
@@ -2318,6 +2324,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
dev_dbg(dc->dev, "%s(): vertical blank\n", __func__);
*/
drm_crtc_handle_vblank(&dc->base);
+ dc->stats.vblank_total++;
dc->stats.vblank++;
}
@@ -2325,6 +2332,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): underflow\n", __func__);
*/
+ dc->stats.underflow_total++;
dc->stats.underflow++;
}
@@ -2332,11 +2340,13 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): overflow\n", __func__);
*/
+ dc->stats.overflow_total++;
dc->stats.overflow++;
}
if (status & HEAD_UF_INT) {
dev_dbg_ratelimited(dc->dev, "%s(): head underflow\n",
__func__);
+ dc->stats.underflow_total++;
dc->stats.underflow++;
}
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 0d7bdf66a1ec..ba4ed35139fb 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -48,6 +48,11 @@ struct tegra_dc_stats {
unsigned long vblank;
unsigned long underflow;
unsigned long overflow;
+
+ unsigned long frames_total;
+ unsigned long vblank_total;
+ unsigned long underflow_total;
+ unsigned long overflow_total;
};
struct tegra_windowgroup_soc {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
which otherwise doesn't provide any method for cleaning/invalidating the
cache to sync with the device.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 21 +
drivers/gpu/drm/msm/msm_drv.h | 2 ++
drivers/gpu/drm/msm/msm_gem.c | 23 +++
include/uapi/drm/msm_drm.h| 20
4 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bae48afca82e..3f17acdf6594 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -959,6 +959,26 @@ static int msm_ioctl_submitqueue_close(struct drm_device
*dev, void *data,
return msm_submitqueue_remove(file->driver_priv, id);
}
+static int msm_ioctl_gem_sync_cache(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_msm_gem_sync_cache *args = data;
+ struct drm_gem_object *obj;
+
+ if (args->flags & ~MSM_GEM_SYNC_CACHE_FLAGS)
+ return -EINVAL;
+
+ obj = drm_gem_object_lookup(file, args->handle);
+ if (!obj)
+ return -ENOENT;
+
+ msm_gem_sync_cache(obj, args->flags, args->offset, args->end);
+
+ drm_gem_object_put(obj);
+
+ return 0;
+}
+
static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW, msm_ioctl_gem_new,
DRM_RENDER_ALLOW),
@@ -971,6 +991,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(MSM_GEM_SYNC_CACHE,msm_ioctl_gem_sync_cache,
DRM_RENDER_ALLOW),
};
static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 22ebecb28349..f170f843010e 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -318,6 +318,8 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct
msm_gpu *gpu);
void msm_gem_active_put(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+ size_t range_start, size_t range_end);
void msm_gem_free_object(struct drm_gem_object *obj);
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
uint32_t size, uint32_t flags, uint32_t *handle, char *name);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 3d8254b5de16..039738696f9a 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -797,6 +797,29 @@ int msm_gem_cpu_fini(struct drm_gem_object *obj)
return 0;
}
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+ size_t range_start, size_t range_end)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct device *dev = msm_obj->base.dev->dev;
+
+ /* exit early if get_pages() hasn't been called yet */
+ if (!msm_obj->pages)
+ return;
+
+ /* TODO: sync only the specified range */
+
+ if (flags & MSM_GEM_SYNC_FOR_DEVICE) {
+ dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
+ msm_obj->sgt->nents, DMA_TO_DEVICE);
+ }
+
+ if (flags & MSM_GEM_SYNC_FOR_CPU) {
+ dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
+ msm_obj->sgt->nents, DMA_FROM_DEVICE);
+ }
+}
+
#ifdef CONFIG_DEBUG_FS
static void describe_fence(struct dma_fence *fence, const char *type,
struct seq_file *m)
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 474497e8743a..c8288f328528 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -319,6 +319,24 @@ struct drm_msm_submitqueue_query {
__u32 pad;
};
+/*
+ * Host cache maintenance (relevant for MSM_BO_CACHED)
+ * driver may both clean/invalidate (flush) for clean
+ */
+
+#define MSM_GEM_SYNC_FOR_DEVICE0x1
+#define MSM_GEM_SYNC_FOR_CPU 0x2
+
+#define MSM_GEM_SYNC_CACHE_FLAGS (MSM_GEM_SYNC_FOR_DEVICE | \
+MSM_GEM_SYNC_FOR_CPU)
+
+struct drm_msm_gem_sync_cache {
+ __u32 handle;
+ __u32 flags;
+ __u64 offset;
+ __u64 end; /* offset + size */
+};
+
#define DRM_MSM_GET_PARAM 0x00
/* placeholder:
#define DRM_MSM_SET_PARAM 0x01
@@ -336,6 +354,7 @@ struct drm_msm_su
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On Thu, 12 Nov 2020 at 23:14, Dmitry Osipenko wrote: > > 12.11.2020 23:43, Thierry Reding пишет: > >> The difference in comparison to using voltage regulator directly is > >> minimal, basically the core-supply phandle is replaced is replaced with > >> a power-domain phandle in a device tree. > > These new power-domain handles would have to be added to devices that > > potentially already have a power-domain handle, right? Isn't that going > > to cause issues? I vaguely recall that we already have multiple power > > domains for the XUSB controller and we have to jump through extra hoops > > to make that work. > > I modeled the core PD as a parent of the PMC sub-domains, which > presumably is a correct way to represent the domains topology. > > https://gist.github.com/digetx/dfd92c7f7e0aa6cef20403c4298088d7 That could make sense, it seems. Anyway, this made me realize that dev_pm_genpd_set_performance_state(dev) returns -EINVAL, in case the device's genpd doesn't have the ->set_performance_state() assigned. This may not be correct. Instead we should likely consider an empty callback as okay and continue to walk the topology upwards to the parent domain, etc. Just wanted to point this out. I intend to post a patch as soon as I can for this. [...] Kind regards Uffe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 5/5] drm/msm: bump up the uapi version
Increase the minor version to indicate the presence of new features.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 3f17acdf6594..7230d3c0eee5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -39,9 +39,10 @@
* GEM object's debug name
* - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
* - 1.6.0 - Syncobj support
+ * - 1.7.0 - MSM_BO_CACHED_COHERENT and DRM_IOCTL_MSM_GEM_SYNC_CACHE
*/
#define MSM_VERSION_MAJOR 1
-#define MSM_VERSION_MINOR 6
+#define MSM_VERSION_MINOR 7
#define MSM_VERSION_PATCHLEVEL 0
static const struct drm_mode_config_funcs mode_config_funcs = {
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/vc4: kms: Simplify a bit the private obj state hooks
Some fields that we're going to add cannot be just copied over to the
new state, and thus kmemdup is a bit unnecessary. Let's move to kzalloc
instead, and clean it up in the process.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index d6712924681e..3d0065df10f9 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -695,23 +695,25 @@ static int vc4_load_tracker_obj_init(struct vc4_dev *vc4)
static struct drm_private_state *
vc4_hvs_channels_duplicate_state(struct drm_private_obj *obj)
{
+ struct vc4_hvs_state *old_state = to_vc4_hvs_state(obj->state);
struct vc4_hvs_state *state;
- state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
return NULL;
__drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
+ state->unassigned_channels = old_state->unassigned_channels;
+
return &state->base;
}
static void vc4_hvs_channels_destroy_state(struct drm_private_obj *obj,
struct drm_private_state *state)
{
- struct vc4_hvs_state *hvs_state;
+ struct vc4_hvs_state *hvs_state = to_vc4_hvs_state(state);
- hvs_state = to_vc4_hvs_state(state);
kfree(hvs_state);
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm: Introduce an atomic_commit_setup function
Private objects storing a state shared across all CRTCs need to be
carefully handled to avoid a use-after-free issue.
The proper way to do this to track all the commits using that shared
state and wait for the previous commits to be done before going on with
the current one to avoid the reordering of commits that could occur.
However, this commit setup needs to be done after
drm_atomic_helper_setup_commit(), because before the CRTC commit
structure hasn't been allocated before, and before the workqueue is
scheduled, because we would be potentially reordered already otherwise.
That means that drivers currently have to roll their own
drm_atomic_helper_commit() function, even though it would be identical
if not for the commit setup.
Let's introduce a hook to do so that would be called as part of
drm_atomic_helper_commit, allowing us to reuse the atomic helpers.
Suggested-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_helper.c | 6 ++
include/drm/drm_modeset_helper_vtables.h | 18 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ddd0e3239150..7d69c7844dfc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2083,8 +2083,11 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_crtc_commit *commit;
+ const struct drm_mode_config_helper_funcs *funcs;
int i, ret;
+ funcs = state->dev->mode_config.helper_private;
+
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
commit = kzalloc(sizeof(*commit), GFP_KERNEL);
if (!commit)
@@ -2169,6 +2172,9 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
new_plane_state->commit = drm_crtc_commit_get(commit);
}
+ if (funcs && funcs->atomic_commit_setup)
+ return funcs->atomic_commit_setup(state);
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index f2de050085be..56470baf0513 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1396,6 +1396,24 @@ struct drm_mode_config_helper_funcs {
* drm_atomic_helper_commit_tail().
*/
void (*atomic_commit_tail)(struct drm_atomic_state *state);
+
+ /**
+* @atomic_commit_setup:
+*
+* This hook is used by the default atomic_commit() hook implemented in
+* drm_atomic_helper_commit() together with the nonblocking helpers (see
+* drm_atomic_helper_setup_commit()) to extend the DRM commit setup. It
+* is not used by the atomic helpers.
+*
+* This function is called at the end of
+* drm_atomic_helper_setup_commit(), so once the commit has been
+* properly setup across the generic DRM object states. It allows
+* drivers to do some additional commit tracking that isn't related to a
+* CRTC, plane or connector, typically a private object.
+*
+* This hook is optional.
+*/
+ int (*atomic_commit_setup)(struct drm_atomic_state *state);
};
#endif
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
13.11.2020 17:45, Ulf Hansson пишет: > On Thu, 12 Nov 2020 at 23:14, Dmitry Osipenko wrote: >> >> 12.11.2020 23:43, Thierry Reding пишет: The difference in comparison to using voltage regulator directly is minimal, basically the core-supply phandle is replaced is replaced with a power-domain phandle in a device tree. >>> These new power-domain handles would have to be added to devices that >>> potentially already have a power-domain handle, right? Isn't that going >>> to cause issues? I vaguely recall that we already have multiple power >>> domains for the XUSB controller and we have to jump through extra hoops >>> to make that work. >> >> I modeled the core PD as a parent of the PMC sub-domains, which >> presumably is a correct way to represent the domains topology. >> >> https://gist.github.com/digetx/dfd92c7f7e0aa6cef20403c4298088d7 > > That could make sense, it seems. > > Anyway, this made me realize that > dev_pm_genpd_set_performance_state(dev) returns -EINVAL, in case the > device's genpd doesn't have the ->set_performance_state() assigned. > This may not be correct. Instead we should likely consider an empty > callback as okay and continue to walk the topology upwards to the > parent domain, etc. > > Just wanted to point this out. I intend to post a patch as soon as I > can for this. Thank you, I was also going to make the same change, but haven't bothered to do it so far. Please feel free to CC me on the patch. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 01/17] memory: tegra30: Support interconnect framework
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS. MC driver now
supports tuning of memory arbitration latency, which needs to be done
for ISO memory clients, like a Display client for example.
Tested-by: Peter Geis
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/Kconfig | 1 +
drivers/memory/tegra/tegra30-emc.c | 349 +++--
drivers/memory/tegra/tegra30.c | 173 +-
3 files changed, 501 insertions(+), 22 deletions(-)
diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 2a4a16bcf91c..ca7077a06f4c 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -24,6 +24,7 @@ config TEGRA30_EMC
tristate "NVIDIA Tegra30 External Memory Controller driver"
default y
depends on TEGRA_MC && ARCH_TEGRA_3x_SOC
+ select PM_OPP
help
This driver is for the External Memory Controller (EMC) found on
Tegra30 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/tegra30-emc.c
b/drivers/memory/tegra/tegra30-emc.c
index 3488786da03b..1974b067789f 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -14,16 +14,21 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include
#include
+#include
#include
#include "mc.h"
@@ -323,9 +328,21 @@ struct emc_timing {
bool emc_cfg_dyn_self_ref;
};
+enum emc_rate_request_type {
+ EMC_RATE_DEBUG,
+ EMC_RATE_ICC,
+ EMC_RATE_TYPE_MAX,
+};
+
+struct emc_rate_request {
+ unsigned long min_rate;
+ unsigned long max_rate;
+};
+
struct tegra_emc {
struct device *dev;
struct tegra_mc *mc;
+ struct icc_provider provider;
struct notifier_block clk_nb;
struct clk *clk;
void __iomem *regs;
@@ -352,6 +369,15 @@ struct tegra_emc {
unsigned long min_rate;
unsigned long max_rate;
} debugfs;
+
+ /*
+* There are multiple sources in the EMC driver which could request
+* a min/max clock rate, these rates are contained in this array.
+*/
+ struct emc_rate_request requested_rate[EMC_RATE_TYPE_MAX];
+
+ /* protect shared rate-change code path */
+ struct mutex rate_lock;
};
static int emc_seq_update_timing(struct tegra_emc *emc)
@@ -1094,6 +1120,83 @@ static long emc_round_rate(unsigned long rate,
return timing->rate;
}
+static void tegra_emc_rate_requests_init(struct tegra_emc *emc)
+{
+ unsigned int i;
+
+ for (i = 0; i < EMC_RATE_TYPE_MAX; i++) {
+ emc->requested_rate[i].min_rate = 0;
+ emc->requested_rate[i].max_rate = ULONG_MAX;
+ }
+}
+
+static int emc_request_rate(struct tegra_emc *emc,
+ unsigned long new_min_rate,
+ unsigned long new_max_rate,
+ enum emc_rate_request_type type)
+{
+ struct emc_rate_request *req = emc->requested_rate;
+ unsigned long min_rate = 0, max_rate = ULONG_MAX;
+ unsigned int i;
+ int err;
+
+ /* select minimum and maximum rates among the requested rates */
+ for (i = 0; i < EMC_RATE_TYPE_MAX; i++, req++) {
+ if (i == type) {
+ min_rate = max(new_min_rate, min_rate);
+ max_rate = min(new_max_rate, max_rate);
+ } else {
+ min_rate = max(req->min_rate, min_rate);
+ max_rate = min(req->max_rate, max_rate);
+ }
+ }
+
+ if (min_rate > max_rate) {
+ dev_err_ratelimited(emc->dev, "%s: type %u: out of range: %lu
%lu\n",
+ __func__, type, min_rate, max_rate);
+ return -ERANGE;
+ }
+
+ /*
+* EMC rate-changes should go via OPP API because it manages voltage
+* changes.
+*/
+ err = dev_pm_opp_set_rate(emc->dev, min_rate);
+ if (err)
+ return err;
+
+ emc->requested_rate[type].min_rate = new_min_rate;
+ emc->requested_rate[type].max_rate = new_max_rate;
+
+ return 0;
+}
+
+static int emc_set_min_rate(struct tegra_emc *emc, unsigned long rate,
+ enum emc_rate_request_type type)
+{
+ struct emc_rate_request *req = &emc->requested_rate[type];
+ int ret;
+
+ mutex_lock(&emc->rate_lock);
+ ret = emc_request_rate(emc, rate, req->max_rate, type);
+ mutex_unlock(&emc->rate_lock);
+
+ return ret;
+}
+
+static int emc_set_max_rate(struct tegra_emc *emc, unsigned long rate,
+ enum emc_rate_request_type t
[PATCH -next] drm/virtio: Make virtgpu_dmabuf_ops with static keyword
Fix the following sparse warning:
./virtgpu_prime.c:46:33: warning: symbol 'virtgpu_dmabuf_ops' was not declared.
Should it be static?
Signed-off-by: Zou Wei
---
drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 1ef1e2f..807a27a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -43,7 +43,7 @@ static int virtgpu_virtio_get_uuid(struct dma_buf *buf,
return 0;
}
-const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
+static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
.ops = {
.cache_sgt_mapping = true,
.attach = virtio_dma_buf_attach,
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] vc4: Convert to drm_atomic_helper_commit
Hi, Here's a conversion of vc4 to remove the hand-rolled atomic_commit helper from vc4 in favour of the generic one. This requires some rework of vc4, but also a new hook and some documentation for corner-cases in the DRM core that have been reported and explained by Daniel recently. Let me know what you think, Maxime Maxime Ripard (8): drm: Introduce an atomic_commit_setup function drm: Document use-after-free gotcha with private objects drm/vc4: kms: Move HVS state helpers around drm/vc4: kms: Simplify a bit the private obj state hooks drm/vc4: Simplify a bit the global atomic_check drm/vc4: kms: Wait on previous FIFO users before a commit drm/vc4: kms: Remove async modeset semaphore drm/vc4: kms: Convert to atomic helpers drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/vc4/vc4_crtc.c | 13 -- drivers/gpu/drm/vc4/vc4_drv.h| 2 - drivers/gpu/drm/vc4/vc4_kms.c| 269 +++ include/drm/drm_atomic.h | 18 ++ include/drm/drm_modeset_helper_vtables.h | 18 ++ 6 files changed, 173 insertions(+), 153 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: fsl-imx-drm: fix example compatible string
Example `display-subsystem` has an incorrect compatible string.
Required properties section tells that developers should use
"fsl,imx-display-subsystem" as "compatible" string but the example
misses 'imx-' prefix.
Change example to have correct "compatible" string.
Signed-off-by: Cengiz Can
---
Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
index 5a99490c17b9..3c35338a2867 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
@@ -12,7 +12,7 @@ Required properties:
example:
display-subsystem {
- compatible = "fsl,display-subsystem";
+ compatible = "fsl,imx-display-subsystem";
ports = <&ipu_di0>;
};
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/msm/dp: deinitialize mainlink if link training failed
DP compo phy have to be enable to start link training. When
link training failed phy need to be disabled so that next
link traning can be proceed smoothly at next plug in. This
patch de-initialize mainlink to disable phy if link training
failed. This prevent system crash due to
disp_cc_mdss_dp_link_intf_clk stuck at "off" state. This patch
also perform checking power_on flag at dp_display_enable() and
dp_display_disable() to avoid crashing when unplug cable while
display is off.
Changes in V2:
-- fix Fixes tag text
Fixes: fdaf9a5e3c15 ("drm/msm/dp: fixes wrong connection state caused by
failure of link training")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 2 +-
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 40 +++--
drivers/gpu/drm/msm/dp/dp_display.c | 15 ++-
drivers/gpu/drm/msm/dp/dp_panel.c | 2 +-
5 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 4963bfe6a472..c2fe0009b092 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -572,7 +572,7 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
*dp_catalog)
dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
}
-u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog)
+u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 6d257dbebf29..176a9020a520 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -97,7 +97,7 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
u32 intr_mask, bool en);
void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog);
-u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog);
+u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog);
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_phy_reset(struct dp_catalog *dp_catalog);
int dp_catalog_ctrl_update_vx_px(struct dp_catalog *dp_catalog, u8 v_level,
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index cee161c8ecc6..c7af040ce252 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1468,6 +1468,30 @@ static int dp_ctrl_reinitialize_mainlink(struct
dp_ctrl_private *ctrl)
return ret;
}
+static int dp_ctrl_deinitialize_mainlink(struct dp_ctrl_private *ctrl)
+{
+ struct dp_io *dp_io;
+ struct phy *phy;
+ int ret;
+
+ dp_io = &ctrl->parser->io;
+ phy = dp_io->phy;
+
+ dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, false);
+
+ dp_catalog_ctrl_reset(ctrl->catalog);
+
+ ret = dp_power_clk_enable(ctrl->power, DP_CTRL_PM, false);
+ if (ret) {
+ DRM_ERROR("Failed to disable link clocks. ret=%d\n", ret);
+ }
+
+ phy_power_off(phy);
+ phy_exit(phy);
+
+ return 0;
+}
+
static int dp_ctrl_link_maintenance(struct dp_ctrl_private *ctrl)
{
int ret = 0;
@@ -1648,8 +1672,7 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
if (rc)
return rc;
- while (--link_train_max_retries &&
- !atomic_read(&ctrl->dp_ctrl.aborted)) {
+ while (--link_train_max_retries) {
rc = dp_ctrl_reinitialize_mainlink(ctrl);
if (rc) {
DRM_ERROR("Failed to reinitialize mainlink. rc=%d\n",
@@ -1664,6 +1687,10 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
break;
} else if (training_step == DP_TRAINING_1) {
/* link train_1 failed */
+ if (!dp_catalog_link_is_connected(ctrl->catalog)) {
+ break;
+ }
+
rc = dp_ctrl_link_rate_down_shift(ctrl);
if (rc < 0) { /* already in RBR = 1.6G */
if (cr.lane_0_1 & DP_LANE0_1_CR_DONE) {
@@ -1683,6 +1710,10 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
}
} else if (training_step == DP_TRAINING_2) {
/* link train_2 failed, lower lane rate */
+ if (!dp_catalog_link_is_connected(ctrl->catalog)) {
+ break;
+ }
+
rc = dp_ctrl_link_lane_down_shift(ctrl);
if (rc < 0) {
/* end with failure */
@@ -1703,6 +1734,11 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
[PATCH 5/8] drm/vc4: Simplify a bit the global atomic_check
When we can't allocate a new channel, we can simply return instead of
having to handle both cases, and that simplifies a bit the code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 3d0065df10f9..3034a5a6637e 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -794,6 +794,7 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
to_vc4_crtc_state(new_crtc_state);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
unsigned int matching_channels;
+ unsigned int channel;
/* Nothing to do here, let's skip it */
if ((old_crtc_state->enable && new_crtc_state->enable) ||
@@ -837,14 +838,12 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
* but it works so far.
*/
matching_channels = hvs_state->unassigned_channels &
vc4_crtc->data->hvs_available_channels;
- if (matching_channels) {
- unsigned int channel = ffs(matching_channels) - 1;
-
- new_vc4_crtc_state->assigned_channel = channel;
- hvs_state->unassigned_channels &= ~BIT(channel);
- } else {
+ if (!matching_channels)
return -EINVAL;
- }
+
+ channel = ffs(matching_channels) - 1;
+ new_vc4_crtc_state->assigned_channel = channel;
+ hvs_state->unassigned_channels &= ~BIT(channel);
}
return 0;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/vc4: kms: Wait on previous FIFO users before a commit
If we're having two subsequent, non-blocking, commits on two different
CRTCs that share no resources, there's no guarantee on the order of
execution of both commits.
However, the second one will consider the first one as the old state,
and will be in charge of freeing it once that second commit is done.
If the first commit happens after that second commit, it might access
some resources related to its state that has been freed, resulting in a
use-after-free bug.
The standard DRM objects are protected against this, but our HVS private
state isn't so let's make sure we wait for all the previous FIFO users
to finish their commit before going with our own.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 118 +-
1 file changed, 117 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 3034a5a6637e..849bc6b4cea4 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -40,6 +40,11 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct
drm_private_state *priv)
struct vc4_hvs_state {
struct drm_private_state base;
unsigned int unassigned_channels;
+
+ struct {
+ unsigned in_use: 1;
+ struct drm_crtc_commit *last_user;
+ } fifo_state[HVS_NUM_CHANNELS];
};
static struct vc4_hvs_state *
@@ -182,6 +187,32 @@ vc4_ctm_commit(struct vc4_dev *vc4, struct
drm_atomic_state *state)
VC4_SET_FIELD(ctm_state->fifo, SCALER_OLEDOFFS_DISPFIFO));
}
+static struct vc4_hvs_state *
+vc4_hvs_get_new_global_state(struct drm_atomic_state *state)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_new_private_obj_state(state,
&vc4->hvs_channels);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_vc4_hvs_state(priv_state);
+}
+
+static struct vc4_hvs_state *
+vc4_hvs_get_old_global_state(struct drm_atomic_state *state)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_old_private_obj_state(state,
&vc4->hvs_channels);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_vc4_hvs_state(priv_state);
+}
+
static struct vc4_hvs_state *
vc4_hvs_get_global_state(struct drm_atomic_state *state)
{
@@ -310,6 +341,7 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
struct vc4_hvs *hvs = vc4->hvs;
struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
+ struct vc4_hvs_state *old_hvs_state;
int i;
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -329,6 +361,32 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
drm_atomic_helper_wait_for_dependencies(state);
+ old_hvs_state = vc4_hvs_get_old_global_state(state);
+ if (!old_hvs_state)
+ return;
+
+ for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
+ struct vc4_crtc_state *vc4_crtc_state =
+ to_vc4_crtc_state(crtc_state);
+ unsigned int channel =
+ vc4_crtc_state->assigned_channel;
+
+ if (channel == VC4_HVS_CHANNEL_DISABLED)
+ continue;
+
+ if (!old_hvs_state->fifo_state[channel].in_use)
+ continue;
+
+ commit = old_hvs_state->fifo_state[i].last_user;
+ ret = wait_for_completion_timeout(&commit->hw_done, 10 * HZ);
+ if (!ret)
+ DRM_DEV_ERROR(dev, "Timed out waiting for hw_done\n");
+
+ ret = wait_for_completion_timeout(&commit->flip_done, 10 * HZ);
+ if (!ret)
+ DRM_DEV_ERROR(dev, "Timed out waiting for flip_done\n");
+ }
+
drm_atomic_helper_commit_modeset_disables(dev, state);
vc4_ctm_commit(vc4, state);
@@ -368,6 +426,36 @@ static void commit_work(struct work_struct *work)
vc4_atomic_complete_commit(state);
}
+static int vc4_atomic_commit_setup(struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct vc4_hvs_state *hvs_state;
+ struct drm_crtc *crtc;
+ unsigned int i;
+
+ hvs_state = vc4_hvs_get_new_global_state(state);
+ if (!hvs_state)
+ return -EINVAL;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ struct vc4_crtc_state *vc4_crtc_state =
+ to_vc4_crtc_state(crtc_state);
+ unsigned int channel =
+ vc4_crtc_state->assigned_channel;
+
+ if (channel == VC4_HVS_CHANNEL_DISABLED)
+ continue;
+
+ if (!hvs_state->fifo_state[channel].in_use)
+ continue;
+
+
[PATCH 0/8] vc4: Convert to drm_atomic_helper_commit
Hi, Here's a conversion of vc4 to remove the hand-rolled atomic_commit helper from vc4 in favour of the generic one. This requires some rework of vc4, but also a new hook and some documentation for corner-cases in the DRM core that have been reported and explained by Daniel recently. Let me know what you think, Maxime Maxime Ripard (8): drm: Introduce an atomic_commit_setup function drm: Document use-after-free gotcha with private objects drm/vc4: kms: Move HVS state helpers around drm/vc4: kms: Simplify a bit the private obj state hooks drm/vc4: Simplify a bit the global atomic_check drm/vc4: kms: Wait on previous FIFO users before a commit drm/vc4: kms: Remove async modeset semaphore drm/vc4: kms: Convert to atomic helpers drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/vc4/vc4_crtc.c | 13 -- drivers/gpu/drm/vc4/vc4_drv.h| 2 - drivers/gpu/drm/vc4/vc4_kms.c| 269 +++ include/drm/drm_atomic.h | 18 ++ include/drm/drm_modeset_helper_vtables.h | 18 ++ 6 files changed, 173 insertions(+), 153 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/msm/dp: skip checking LINK_STATUS_UPDATED bit
Some dongle will not clear LINK_STATUS_UPDATED bit after
DPCD read which cause link training failed. This patch
just read 6 bytes of DPCD link status from sink and return
without checking LINK_STATUS_UPDATED bit.
Only 8 bits are used to represent link rate at sinker DPCD.
The really link rate is 2.7Mb times the 8 bits value.
For example, 0x0A at DPCD is equal to 2.7Gb (10 * 2.7Mb).
This patch also convert 8 bits value of DPCD to really link
rate to fix worng link rate error during phy compliance test.
Changes in V2:
-- fix Fixes tag text
Fixes: fd4a29bed29b ("drm/msm/dp: DisplayPort PHY compliance tests fixup")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 20 ++--
drivers/gpu/drm/msm/dp/dp_link.c | 29 ++---
2 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index c7af040ce252..b9ca844ce2ad 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1061,23 +1061,15 @@ static bool dp_ctrl_train_pattern_set(struct
dp_ctrl_private *ctrl,
static int dp_ctrl_read_link_status(struct dp_ctrl_private *ctrl,
u8 *link_status)
{
- int len = 0;
- u32 const offset = DP_LANE_ALIGN_STATUS_UPDATED - DP_LANE0_1_STATUS;
- u32 link_status_read_max_retries = 100;
-
- while (--link_status_read_max_retries) {
- len = drm_dp_dpcd_read_link_status(ctrl->aux,
- link_status);
- if (len != DP_LINK_STATUS_SIZE) {
- DRM_ERROR("DP link status read failed, err: %d\n", len);
- return len;
- }
+ int ret = 0, len;
- if (!(link_status[offset] & DP_LINK_STATUS_UPDATED))
- return 0;
+ len = drm_dp_dpcd_read_link_status(ctrl->aux, link_status);
+ if (len != DP_LINK_STATUS_SIZE) {
+ DRM_ERROR("DP link status read failed, err: %d\n", len);
+ ret = -EINVAL;
}
- return -ETIMEDOUT;
+ return ret;
}
static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index 49d7fad36fc4..be986da78c4a 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -773,7 +773,8 @@ static int dp_link_process_link_training_request(struct
dp_link_private *link)
link->request.test_lane_count);
link->dp_link.link_params.num_lanes = link->request.test_lane_count;
- link->dp_link.link_params.rate = link->request.test_link_rate;
+ link->dp_link.link_params.rate =
+ drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
return 0;
}
@@ -943,22 +944,20 @@ static u8 get_link_status(const u8
link_status[DP_LINK_STATUS_SIZE], int r)
*/
static int dp_link_process_link_status_update(struct dp_link_private *link)
{
- if (!(get_link_status(link->link_status,
- DP_LANE_ALIGN_STATUS_UPDATED) &
- DP_LINK_STATUS_UPDATED) ||
- (drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes) &&
- drm_dp_channel_eq_ok(link->link_status,
- link->dp_link.link_params.num_lanes)))
- return -EINVAL;
+ bool channel_eq_done = drm_dp_channel_eq_ok(link->link_status,
+ link->dp_link.link_params.num_lanes);
- DRM_DEBUG_DP("channel_eq_done = %d, clock_recovery_done = %d\n",
- drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes),
- drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes));
+ bool clock_recovery_done = drm_dp_clock_recovery_ok(link->link_status,
+ link->dp_link.link_params.num_lanes);
- return 0;
+ DRM_DEBUG_DP("channel_eq_done = %d, clock_recovery_done = %d\n",
+channel_eq_done, clock_recovery_done);
+
+ if (channel_eq_done && clock_recovery_done)
+ return -EINVAL;
+
+
+ return 0;
}
/**
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 17/17] ARM: tegra: Add EMC OPP and ICC properties to Tegra124 EMC and ACTMON device-tree nodes
Add EMC OPP DVFS/DFS tables and interconnect paths that will be used for
dynamic memory bandwidth scaling based on memory utilization statistics.
Update board device-trees by removing unsupported EMC OPPs.
Note that ACTMON watches all memory interconnect paths, but we use a
single CPU-READ interconnect path for driving memory bandwidth, for
simplicity.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra124-apalis-emc.dtsi| 8 +
.../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi | 8 +
arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi | 10 +
.../arm/boot/dts/tegra124-nyan-blaze-emc.dtsi | 10 +
.../boot/dts/tegra124-peripherals-opp.dtsi| 419 ++
arch/arm/boot/dts/tegra124.dtsi | 6 +
6 files changed, 461 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
diff --git a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
index 32401457ae71..a7ac805eeed5 100644
--- a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
@@ -1465,3 +1465,11 @@ timing-92400 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@12,1100;
+};
+
+&emc_bw_dfs_opp_table {
+ /delete-node/ opp@12;
+};
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
b/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
index 861d3f22116b..df4e463afbd1 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
@@ -2420,3 +2420,11 @@ timing-92400 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@12,1100;
+};
+
+&emc_bw_dfs_opp_table {
+ /delete-node/ opp@12;
+};
diff --git a/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
b/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
index c91647d13a50..a0f56cc9da5c 100644
--- a/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
@@ -6649,3 +6649,13 @@ timing-79200 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@92400,1100;
+ /delete-node/ opp@12,1100;
+};
+
+&emc_bw_dfs_opp_table {
+ /delete-node/ opp@92400;
+ /delete-node/ opp@12;
+};
diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze-emc.dtsi
b/arch/arm/boot/dts/tegra124-nyan-blaze-emc.dtsi
index d2beea0bd15f..35c98734d35f 100644
--- a/arch/arm/boot/dts/tegra124-nyan-blaze-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan-blaze-emc.dtsi
@@ -2048,3 +2048,13 @@ timing-79200 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@92400,1100;
+ /delete-node/ opp@12,1100;
+};
+
+&emc_bw_dfs_opp_table {
+ /delete-node/ opp@92400;
+ /delete-node/ opp@12;
+};
diff --git a/arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
b/arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
new file mode 100644
index ..49d9420a3289
--- /dev/null
+++ b/arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
@@ -0,0 +1,419 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ emc_icc_dvfs_opp_table: emc-dvfs-opp-table {
+ compatible = "operating-points-v2";
+
+ opp@1275,800 {
+ opp-microvolt = <80 80 115>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0003>;
+ };
+
+ opp@1275,950 {
+ opp-microvolt = <95 95 115>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0008>;
+ };
+
+ opp@1275,1050 {
+ opp-microvolt = <105 105 115>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0010>;
+ };
+
+ opp@1275,1110 {
+ opp-microvolt = <111 111 115>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0004>;
+ };
+
+ opp@2040,800 {
+ opp-microvolt = <80 80 115>;
+ opp-hz = /bits/ 64 <2040>;
+ opp-supported-hw = <0x0003>;
+ };
+
+ opp@2040,950 {
+ opp-microvolt = <95 95 115>;
+ opp-hz = /bits/ 64 <2040>;
+ opp-supported-hw = <0x0008>;
+ };
+
+ opp@2040,1050 {
+ opp-microvolt = <105 105 115>;
+ opp-hz = /bits/ 64 <2040>;
+ opp-supported-hw = <0x0010>;
+ };
+
+ opp@2040,1110 {
+ opp-microvolt = <111 111 1150
[PATCH v9 15/17] ARM: tegra: Add EMC OPP properties to Tegra20 device-trees
Add EMC OPP DVFS tables and update board device-trees by removing
unsupported OPPs.
Signed-off-by: Dmitry Osipenko
---
.../boot/dts/tegra20-acer-a500-picasso.dts| 5 +
arch/arm/boot/dts/tegra20-colibri.dtsi| 4 +
arch/arm/boot/dts/tegra20-paz00.dts | 4 +
.../arm/boot/dts/tegra20-peripherals-opp.dtsi | 92 +++
arch/arm/boot/dts/tegra20.dtsi| 3 +
5 files changed, 108 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index dd6fb134ee39..a29b44837855 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -1451,3 +1451,8 @@ emc-table@30 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@66600;
+ /delete-node/ opp@76000;
+};
diff --git a/arch/arm/boot/dts/tegra20-colibri.dtsi
b/arch/arm/boot/dts/tegra20-colibri.dtsi
index 6162d193e12c..585a5b441cf6 100644
--- a/arch/arm/boot/dts/tegra20-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
@@ -742,6 +742,10 @@ sound {
};
};
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@76000;
+};
+
&gpio {
lan-reset-n {
gpio-hog;
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
index ada2bed8b1b5..7e49112cd9a1 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -662,3 +662,7 @@ cpu@1 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@76000;
+};
diff --git a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
new file mode 100644
index ..25b1ba73951e
--- /dev/null
+++ b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ emc_icc_dvfs_opp_table: emc-dvfs-opp-table {
+ compatible = "operating-points-v2";
+
+ opp@3600 {
+ opp-microvolt = <95 95 130>;
+ opp-hz = /bits/ 64 <3600>;
+ };
+
+ opp@4750 {
+ opp-microvolt = <95 95 130>;
+ opp-hz = /bits/ 64 <4750>;
+ };
+
+ opp@5000 {
+ opp-microvolt = <95 95 130>;
+ opp-hz = /bits/ 64 <5000>;
+ };
+
+ opp@5400 {
+ opp-microvolt = <95 95 130>;
+ opp-hz = /bits/ 64 <5400>;
+ };
+
+ opp@5700 {
+ opp-microvolt = <95 95 130>;
+ opp-hz = /bits/ 64 <5700>;
+ };
+
+ opp@1 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <1>;
+ };
+
+ opp@10800 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <10800>;
+ };
+
+ opp@12000 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <12000>;
+ };
+
+ opp@15000 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <15000>;
+ };
+
+ opp@19000 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <19000>;
+ };
+
+ opp@21600 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <21600>;
+ };
+
+ opp@3 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <3>;
+ };
+
+ opp@33300 {
+ opp-microvolt = <100 100 130>;
+ opp-hz = /bits/ 64 <33300>;
+ };
+
+ opp@38000 {
+ opp-microvolt = <110 110 130>;
+ opp-hz = /bits/ 64 <38000>;
+ };
+
+ opp@6 {
+ opp-microvolt = <120 120 130>;
+ opp-hz = /bits/ 64 <6>;
+ };
+
+ opp@66600 {
+ opp-microvolt = <120 120 130>;
+ opp-hz = /bits/ 64 <66600>;
+ };
+
+ opp@76000 {
+ opp-microvolt = <130 130 130>;
+
[PATCH 3/8] drm/vc4: kms: Move HVS state helpers around
We're going to use those helpers in functions higher in that file, let's
move it around.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 7ef164afa9e2..d6712924681e 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -182,6 +182,19 @@ vc4_ctm_commit(struct vc4_dev *vc4, struct
drm_atomic_state *state)
VC4_SET_FIELD(ctm_state->fifo, SCALER_OLEDOFFS_DISPFIFO));
}
+static struct vc4_hvs_state *
+vc4_hvs_get_global_state(struct drm_atomic_state *state)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_private_obj_state(state,
&vc4->hvs_channels);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_vc4_hvs_state(priv_state);
+}
+
static void vc4_hvs_pv_muxing_commit(struct vc4_dev *vc4,
struct drm_atomic_state *state)
{
@@ -730,19 +743,6 @@ static int vc4_hvs_channels_obj_init(struct vc4_dev *vc4)
return drmm_add_action_or_reset(&vc4->base, vc4_hvs_channels_obj_fini,
NULL);
}
-static struct vc4_hvs_state *
-vc4_hvs_get_global_state(struct drm_atomic_state *state)
-{
- struct vc4_dev *vc4 = to_vc4_dev(state->dev);
- struct drm_private_state *priv_state;
-
- priv_state = drm_atomic_get_private_obj_state(state,
&vc4->hvs_channels);
- if (IS_ERR(priv_state))
- return ERR_CAST(priv_state);
-
- return to_vc4_hvs_state(priv_state);
-}
-
/*
* The BCM2711 HVS has up to 7 output connected to the pixelvalves and
* the TXP (and therefore all the CRTCs found on that platform).
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 13/17] ARM: tegra: Add interconnect properties to Tegra124 device-tree
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra124.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 64f488ba1e72..1801e30b1d3a 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -113,6 +113,19 @@ dc@5420 {
iommus = <&mc TEGRA_SWGROUP_DC>;
nvidia,head = <0>;
+
+ interconnects = <&mc TEGRA124_MC_DISPLAY0A &emc>,
+ <&mc TEGRA124_MC_DISPLAY0B &emc>,
+ <&mc TEGRA124_MC_DISPLAY0C &emc>,
+ <&mc TEGRA124_MC_DISPLAYHC &emc>,
+ <&mc TEGRA124_MC_DISPLAYD &emc>,
+ <&mc TEGRA124_MC_DISPLAYT &emc>;
+ interconnect-names = "wina",
+"winb",
+"winc",
+"cursor",
+"wind",
+"wint";
};
dc@5424 {
@@ -127,6 +140,15 @@ dc@5424 {
iommus = <&mc TEGRA_SWGROUP_DCB>;
nvidia,head = <1>;
+
+ interconnects = <&mc TEGRA124_MC_DISPLAY0AB &emc>,
+ <&mc TEGRA124_MC_DISPLAY0BB &emc>,
+ <&mc TEGRA124_MC_DISPLAY0CB &emc>,
+ <&mc TEGRA124_MC_DISPLAYHCB &emc>;
+ interconnect-names = "wina",
+"winb",
+"winc",
+"cursor";
};
hdmi: hdmi@5428 {
@@ -628,6 +650,7 @@ mc: memory-controller@70019000 {
#iommu-cells = <1>;
#reset-cells = <1>;
+ #interconnect-cells = <1>;
};
emc: external-memory-controller@7001b000 {
@@ -637,6 +660,8 @@ emc: external-memory-controller@7001b000 {
clock-names = "emc";
nvidia,memory-controller = <&mc>;
+
+ #interconnect-cells = <0>;
};
sata@7002 {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: fix connect/disconnect handled at ir_hdp
Some usb type-c dongle use irq_hpd request to perform device
connect and disconnect. This patch add handling of both connection
and disconnection are based on hpd_state and sink_count.
Fixes: 6c6e8b2e04d5 ("drm/msm/dp: promote irq_hpd handle to handle link
training correctly")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 78 +
1 file changed, 45 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 27e7e27b8b90..4e84f500b721 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -279,13 +279,25 @@ static void dp_display_send_hpd_event(struct msm_dp
*dp_display)
drm_helper_hpd_irq_event(connector->dev);
}
-static int dp_display_send_hpd_notification(struct dp_display_private *dp,
- bool hpd)
+
+static void dp_display_set_encoder_mode(struct dp_display_private *dp)
{
- static bool encoder_mode_set;
struct msm_drm_private *priv = dp->dp_display.drm_dev->dev_private;
struct msm_kms *kms = priv->kms;
+ static bool encoder_mode_set;
+
+ if (!encoder_mode_set && dp->dp_display.encoder &&
+ kms->funcs->set_encoder_mode) {
+ kms->funcs->set_encoder_mode(kms,
+ dp->dp_display.encoder, false);
+ encoder_mode_set = true;
+ }
+}
+
+static int dp_display_send_hpd_notification(struct dp_display_private *dp,
+ bool hpd)
+{
if ((hpd && dp->dp_display.is_connected) ||
(!hpd && !dp->dp_display.is_connected)) {
DRM_DEBUG_DP("HPD already %s\n", (hpd ? "on" : "off"));
@@ -298,15 +310,6 @@ static int dp_display_send_hpd_notification(struct
dp_display_private *dp,
dp->dp_display.is_connected = hpd;
- if (dp->dp_display.is_connected && dp->dp_display.encoder
- && !encoder_mode_set
- && kms->funcs->set_encoder_mode) {
- kms->funcs->set_encoder_mode(kms,
- dp->dp_display.encoder, false);
- DRM_DEBUG_DP("set_encoder_mode() Completed\n");
- encoder_mode_set = true;
- }
-
dp_display_send_hpd_event(&dp->dp_display);
return 0;
@@ -359,6 +362,8 @@ static void dp_display_host_init(struct dp_display_private
*dp)
if (dp->usbpd->orientation == ORIENTATION_CC2)
flip = true;
+ dp_display_set_encoder_mode(dp);
+
dp_power_init(dp->power, flip);
dp_ctrl_host_init(dp->ctrl, flip);
dp_aux_init(dp->aux);
@@ -448,15 +453,6 @@ static int dp_display_handle_irq_hpd(struct
dp_display_private *dp)
sink_request = dp->link->sink_request;
- if (sink_request & DS_PORT_STATUS_CHANGED) {
- if (dp_display_is_sink_count_zero(dp)) {
- DRM_DEBUG_DP("sink count is zero, nothing to do\n");
- return -ENOTCONN;
- }
-
- return dp_display_process_hpd_high(dp);
- }
-
dp_ctrl_handle_sink_request(dp->ctrl);
if (dp->link->sink_request & DP_TEST_LINK_VIDEO_PATTERN)
@@ -491,17 +487,29 @@ static int dp_display_usbpd_attention_cb(struct device
*dev)
if (!rc) {
sink_request = dp->link->sink_request;
if (sink_request & DS_PORT_STATUS_CHANGED) {
- /* same as unplugged */
- hpd->hpd_high = 0;
- dp->hpd_state = ST_DISCONNECT_PENDING;
- dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
- }
-
- rc = dp_display_handle_irq_hpd(dp);
-
- if (!rc && (sink_request & DS_PORT_STATUS_CHANGED)) {
- hpd->hpd_high = 1;
- dp->hpd_state = ST_CONNECT_PENDING;
+ if (dp_display_is_sink_count_zero(dp)) {
+ DRM_DEBUG_DP("sink count is zero, nothing to
do\n");
+ if (dp->hpd_state != ST_DISCONNECTED) {
+ hpd->hpd_high = 0;
+ dp->hpd_state = ST_DISCONNECT_PENDING;
+ dp_add_event(dp, EV_USER_NOTIFICATION,
false, 0);
+ }
+ rc = -ENOTCONN;
+ } else {
+ if (dp->hpd_state == ST_DISCONNECTED) {
+ hpd->hpd_high = 1;
+ dp->hpd_state = ST_CONNECT_PENDING;
+
+ rc = dp_display_process_hpd_high(dp);
+ if (rc) {
+ hpd->hpd_
Re: [PATCH v8 08/26] memory: tegra30-emc: Continue probing if timings are missing in device-tree
14.11.2020 18:42, Krzysztof Kozlowski пишет: > On Wed, Nov 11, 2020 at 04:14:38AM +0300, Dmitry Osipenko wrote: >> EMC driver will become mandatory after turning it into interconnect >> provider because interconnect users, like display controller driver, will >> fail to probe using newer device-trees that have interconnect properties. >> Thus make EMC driver to probe even if timings are missing in device-tree. >> >> Signed-off-by: Dmitry Osipenko >> --- >> drivers/memory/tegra/tegra30-emc.c | 29 +++-- >> 1 file changed, 15 insertions(+), 14 deletions(-) > > Thanks, applied 1-8. For the rest I see discussion on going, so I guess > there will be a v9. The v9 will be ready soon, thank you. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: output: Do not put OF node twice
13.11.2020 23:41, Thierry Reding пишет:
> From: Thierry Reding
>
> The original patch for commit 3d2e7aec7013 ("drm/tegra: output: Don't
> leak OF node on error") contained this hunk, but it was accidentally
> dropped during conflict resolution. This causes use-after-free errors
> on devices that use an I2C controller for HDMI DDC/CI on Tegra210 and
> later.
>
> Fixes: 3d2e7aec7013 ("drm/tegra: output: Don't leak OF node on error")
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/output.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index 5a4fd0dbf4cf..47d26b5d9945 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -129,7 +129,6 @@ int tegra_output_probe(struct tegra_output *output)
>
> if (!output->ddc) {
> err = -EPROBE_DEFER;
> - of_node_put(ddc);
> return err;
> }
> }
>
Reviewed-by: Dmitry Osipenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 11/17] ARM: tegra: Add interconnect properties to Tegra20 device-tree
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 9347f7789245..2e1304493f7d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -111,6 +111,17 @@ dc@5420 {
nvidia,head = <0>;
+ interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
+ <&mc TEGRA20_MC_DISPLAY0B &emc>,
+ <&mc TEGRA20_MC_DISPLAY1B &emc>,
+ <&mc TEGRA20_MC_DISPLAY0C &emc>,
+ <&mc TEGRA20_MC_DISPLAYHC &emc>;
+ interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -128,6 +139,17 @@ dc@5424 {
nvidia,head = <1>;
+ interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>,
+ <&mc TEGRA20_MC_DISPLAY0BB &emc>,
+ <&mc TEGRA20_MC_DISPLAY1BB &emc>,
+ <&mc TEGRA20_MC_DISPLAY0CB &emc>,
+ <&mc TEGRA20_MC_DISPLAYHCB &emc>;
+ interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -630,15 +652,17 @@ mc: memory-controller@7000f000 {
interrupts = ;
#reset-cells = <1>;
#iommu-cells = <0>;
+ #interconnect-cells = <1>;
};
- memory-controller@7000f400 {
+ emc: memory-controller@7000f400 {
compatible = "nvidia,tegra20-emc";
reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
#address-cells = <1>;
#size-cells = <0>;
+ #interconnect-cells = <0>;
};
fuse@7000f800 {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On 11/14/20 2:39 PM, Rob Clark wrote:
On Sat, Nov 14, 2020 at 10:58 AM Jonathan Marek wrote:
On 11/14/20 1:46 PM, Rob Clark wrote:
On Sat, Nov 14, 2020 at 8:24 AM Christoph Hellwig wrote:
On Sat, Nov 14, 2020 at 10:17:12AM -0500, Jonathan Marek wrote:
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+ size_t range_start, size_t range_end)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct device *dev = msm_obj->base.dev->dev;
+
+ /* exit early if get_pages() hasn't been called yet */
+ if (!msm_obj->pages)
+ return;
+
+ /* TODO: sync only the specified range */
+
+ if (flags & MSM_GEM_SYNC_FOR_DEVICE) {
+ dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
+ msm_obj->sgt->nents, DMA_TO_DEVICE);
+ }
+
+ if (flags & MSM_GEM_SYNC_FOR_CPU) {
+ dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
+ msm_obj->sgt->nents, DMA_FROM_DEVICE);
+ }
Splitting this helper from the only caller is rather strange, epecially
with the two unused arguments. And I think the way this is specified
to take a range, but ignoring it is actively dangerous. User space will
rely on it syncing everything sooner or later and then you are stuck.
So just define a sync all primitive for now, and if you really need a
range sync and have actually implemented it add a new ioctl for that.
We do already have a split of ioctl "layer" which enforces valid ioctl
params, etc, and gem (or other) module code which is called by the
ioctl func. So I think it is fine to keep this split here. (Also, I
think at some point there will be a uring type of ioctl alternative
which would re-use the same gem func.)
But I do agree that the range should be respected or added later..
drm_ioctl() dispatch is well prepared for extending ioctls.
And I assume there should be some validation that the range is aligned
to cache-line? Or can we flush a partial cache line?
The range is intended to be "sync at least this range", so that
userspace doesn't have to worry about details like that.
I don't think userspace can *not* worry about details like that.
Consider a case where the cpu and gpu are simultaneously accessing
different parts of a buffer (for ex, sub-allocation). There needs to
be cache-line separation between the two.
Right.. and it also seems like we can't get away with just
flushing/invalidating the whole thing.
qcom's vulkan driver has nonCoherentAtomSize=1, and it looks like
dma_sync_single_for_cpu() does deal in some way with the partial cache
line case, although I'm not sure that means we can have a
nonCoherentAtomSize=1.
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 14/17] ARM: tegra: Add nvidia, memory-controller phandle to Tegra20 EMC device-tree
Add nvidia,memory-controller to the Tegra20 External Memory Controller
node. This allows to perform a direct lookup of the Memory Controller
instead of walking up the whole tree. This puts Tegra20 device-tree on
par with Tegra30+.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 2e1304493f7d..8f8ad81916e7 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -663,6 +663,8 @@ emc: memory-controller@7000f400 {
#address-cells = <1>;
#size-cells = <0>;
#interconnect-cells = <0>;
+
+ nvidia,memory-controller = <&mc>;
};
fuse@7000f800 {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 07/17] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
This patch moves ACTMON driver away from generating OPP table by itself,
transitioning it to use the table which comes from device-tree. This
change breaks compatibility with older device-trees in order to bring
support for the interconnect framework to the driver. This is a mandatory
change which needs to be done in order to implement interconnect-based
memory DVFS. Users of legacy device-trees will get a message telling that
theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Acked-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 86 ---
1 file changed, 44 insertions(+), 42 deletions(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra30-devfreq.c
index 38cc0d014738..ed6d4469c8c7 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -19,6 +19,8 @@
#include
#include
+#include
+
#include "governor.h"
#define ACTMON_GLB_STATUS 0x0
@@ -155,6 +157,7 @@ struct tegra_devfreq_device {
struct tegra_devfreq {
struct devfreq *devfreq;
+ struct opp_table*opp_table;
struct reset_control*reset;
struct clk *clock;
@@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq *tegra)
static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
{
- struct tegra_devfreq *tegra = dev_get_drvdata(dev);
- struct devfreq *devfreq = tegra->devfreq;
struct dev_pm_opp *opp;
- unsigned long rate;
- int err;
+ int ret;
opp = devfreq_recommended_opp(dev, freq, flags);
if (IS_ERR(opp)) {
dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
return PTR_ERR(opp);
}
- rate = dev_pm_opp_get_freq(opp);
- dev_pm_opp_put(opp);
-
- err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
- if (err)
- return err;
-
- err = clk_set_rate(tegra->emc_clock, 0);
- if (err)
- goto restore_min_rate;
- return 0;
-
-restore_min_rate:
- clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
+ ret = dev_pm_opp_set_bw(dev, opp);
+ dev_pm_opp_put(opp);
- return err;
+ return ret;
}
static int tegra_devfreq_get_dev_status(struct device *dev,
@@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device *dev,
stat->private_data = tegra;
/* The below are to be used by the other governors */
- stat->current_frequency = cur_freq;
+ stat->current_frequency = cur_freq * KHZ;
actmon_dev = &tegra->devices[MCALL];
@@ -705,7 +693,12 @@ static int tegra_governor_get_target(struct devfreq
*devfreq,
target_freq = max(target_freq, dev->target_freq);
}
- *freq = target_freq;
+ /*
+* tegra-devfreq driver operates with KHz units, while OPP table
+* entries use Hz units. Hence we need to convert the units for the
+* devfreq core.
+*/
+ *freq = target_freq * KHZ;
return 0;
}
@@ -774,6 +767,7 @@ static struct devfreq_governor tegra_devfreq_governor = {
static int tegra_devfreq_probe(struct platform_device *pdev)
{
+ u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
struct tegra_devfreq_device *dev;
struct tegra_devfreq *tegra;
struct devfreq *devfreq;
@@ -781,6 +775,13 @@ static int tegra_devfreq_probe(struct platform_device
*pdev)
long rate;
int err;
+ /* legacy device-trees don't have OPP table and must be updated */
+ if (!device_property_present(&pdev->dev, "operating-points-v2")) {
+ dev_err(&pdev->dev,
+ "OPP table not found, please update your device
tree\n");
+ return -ENODEV;
+ }
+
tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
if (!tegra)
return -ENOMEM;
@@ -822,11 +823,25 @@ static int tegra_devfreq_probe(struct platform_device
*pdev)
return err;
}
+ tegra->opp_table = dev_pm_opp_set_supported_hw(&pdev->dev,
+ &hw_version, 1);
+ err = PTR_ERR_OR_ZERO(tegra->opp_table);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to set supported HW: %d\n", err);
+ return err;
+ }
+
+ err = dev_pm_opp_of_add_table(&pdev->dev);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to add OPP table: %d\n", err);
+ goto put_hw;
+ }
+
err = clk_prepare_enable(tegra->clock);
if (err) {
dev_err(&pdev->dev,
"
[RESEND PATCH v2 1/5] drm/msm: add MSM_BO_CACHED_COHERENT
Add a new cache mode for creating coherent host-cached BOs.
Signed-off-by: Jonathan Marek
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_gem.c | 8
include/uapi/drm/msm_drm.h | 5 ++---
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 58e03b20e1c7..21c9bc954f38 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -410,6 +410,7 @@ static int adreno_bind(struct device *dev, struct device
*master, void *data)
config.rev.minor, config.rev.patchid);
priv->is_a2xx = config.rev.core == 2;
+ priv->has_cached_coherent = config.rev.core >= 6;
gpu = info->init(drm);
if (IS_ERR(gpu)) {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index f33281ac7913..22ebecb28349 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -168,6 +168,7 @@ struct msm_drm_private {
struct msm_file_private *lastctx;
/* gpu is only set on open(), but we need this info earlier */
bool is_a2xx;
+ bool has_cached_coherent;
struct drm_fb_helper *fbdev;
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 04be4cf1..3d8254b5de16 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -420,6 +420,9 @@ static int msm_gem_pin_iova(struct drm_gem_object *obj,
if (msm_obj->flags & MSM_BO_MAP_PRIV)
prot |= IOMMU_PRIV;
+ if (msm_obj->flags & MSM_BO_CACHED_COHERENT)
+ prot |= IOMMU_CACHE;
+
WARN_ON(!mutex_is_locked(&msm_obj->lock));
if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
@@ -1004,6 +1007,7 @@ static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
struct drm_gem_object **obj)
{
+ struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_object *msm_obj;
switch (flags & MSM_BO_CACHE_MASK) {
@@ -1011,6 +1015,10 @@ static int msm_gem_new_impl(struct drm_device *dev,
case MSM_BO_CACHED:
case MSM_BO_WC:
break;
+ case MSM_BO_CACHED_COHERENT:
+ if (priv->has_cached_coherent)
+ break;
+ /* fallthrough */
default:
DRM_DEV_ERROR(dev->dev, "invalid cache flag: %x\n",
(flags & MSM_BO_CACHE_MASK));
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index a6c1f3eb2623..474497e8743a 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -94,12 +94,11 @@ struct drm_msm_param {
#define MSM_BO_CACHED0x0001
#define MSM_BO_WC0x0002
#define MSM_BO_UNCACHED 0x0004
+#define MSM_BO_CACHED_COHERENT 0x08
#define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
MSM_BO_GPU_READONLY | \
- MSM_BO_CACHED | \
- MSM_BO_WC | \
- MSM_BO_UNCACHED)
+ MSM_BO_CACHE_MASK)
struct drm_msm_gem_new {
__u64 size; /* in */
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/4] drm: bridge: cdns-mhdp8546: Add output bus format negotiation
This patch adds minimal output bus format negotiation support.
Currently we are adding support for only MEDIA_BUS_FMT_FIXED.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c| 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 6beccd2a408e..bdb0d95aa412 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2102,6 +2102,23 @@ static u32 *cdns_mhdp_get_input_bus_fmts(struct
drm_bridge *bridge,
return input_fmts;
}
+static u32 *cdns_mhdp_get_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state
*conn_state,
+ unsigned int *num_output_fmts)
+{
+ u32 *output_fmts;
+
+ output_fmts = kzalloc(sizeof(*output_fmts), GFP_KERNEL);
+ if (!output_fmts)
+ return NULL;
+
+ *num_output_fmts = 1;
+ output_fmts[0] = MEDIA_BUS_FMT_FIXED;
+ return output_fmts;
+}
+
static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
@@ -2170,6 +2187,7 @@ static const struct drm_bridge_funcs
cdns_mhdp_bridge_funcs = {
.atomic_destroy_state = cdns_mhdp_bridge_atomic_destroy_state,
.atomic_reset = cdns_mhdp_bridge_atomic_reset,
.atomic_get_input_bus_fmts = cdns_mhdp_get_input_bus_fmts,
+ .atomic_get_output_bus_fmts = cdns_mhdp_get_output_bus_fmts,
.detect = cdns_mhdp_bridge_detect,
.get_edid = cdns_mhdp_bridge_get_edid,
.hpd_enable = cdns_mhdp_bridge_hpd_enable,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
13.11.2020 20:28, Mark Brown пишет: > On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote: >> 13.11.2020 19:15, Mark Brown пишет: > >>> My point here is that the driver shouldn't be checking for a dummy >>> regulator, the driver should be checking the features that are provided >>> to it by the regulator and handling those. > >> I understand yours point, but then we need dummy regulator to provide >> all the features, and currently it does the opposite. > > As could any other regulator? Yes >>> It doesn't matter if this is >>> a dummy regulator or an actual regulator with limited features, the >>> effect is the same and the handling should be the same. If the driver >>> is doing anything to handle dummy regulators explicitly as dummy >>> regulators it is doing it wrong. > >> It matters because dummy regulator errors out all checks and changes >> other than enable/disable, instead of accepting them. If we could add an >> option for dummy regulator to succeed all the checks and accept all the >> values, then it could become more usable. > > I'm a bit confused here TBH - I'm not sure I see a substantial > difference between a consumer detecting that it can't set any voltages > at all and the handling for an optional regulator. Either way if it's > going to carry on and assume that whatever voltage is there works for > everything it boils down to setting a flag saying to skip the set > voltage operation. I think you are too focused on the specific > implementation you currently have here. > > We obviously can't just accept voltage change operations when we've no > idea what the current voltage of the device is. > >>> To repeat you should *only* be using regulator_get_optional() in the >>> case where the supply may be physically absent which is not the case >>> here. >> >> Alright, but then we either need to improve regulator core to make dummy >> regulator a bit more usable, or continue to work around it in drivers. >> What should we do? > > As I keep saying the consumer driver should be enumerating the voltages > it can set, if it can't find any and wants to continue then it can just > skip setting voltages later on. If only some are unavailable then it > probably wants to eliminate those specific OPPs instead. I'm seeing a dummy regulator as a helper for consumer drivers which removes burden of handling an absent (optional) regulator. Is this a correct understanding of a dummy regulator? Older DTBs don't have a regulator and we want to keep them working. This is equal to a physically absent regulator and in this case it's an optional regulator, IMO. Consumer drivers definitely should check voltages, but this should be done only for a physical regulator. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 08/17] PM / devfreq: tegra30: Separate configurations per-SoC generation
Previously we were using count-weight of the T124 for T30 in order to
get EMC clock rate that was reasonable for T30. In fact the count-weight
should be x2 times smaller on T30, but then devfreq was producing a bit
too low EMC clock rate for ISO memory clients, like display controller
for example.
Now both Tegra ACTMON and Tegra DRM display drivers support interconnect
framework and display driver tells to ICC what a minimum memory bandwidth
is needed, preventing FIFO underflows. Thus, now we can use a proper
count-weight value for Tegra30 and MC_ALL device config needs a bit more
aggressive boosting.
Add a separate ACTMON driver configuration that is specific to Tegra30.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Acked-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 68 ---
1 file changed, 54 insertions(+), 14 deletions(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra30-devfreq.c
index ed6d4469c8c7..36ba82c3898c 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -57,13 +57,6 @@
#define ACTMON_BELOW_WMARK_WINDOW 3
#define ACTMON_BOOST_FREQ_STEP 16000
-/*
- * Activity counter is incremented every 256 memory transactions, and each
- * transaction takes 4 EMC clocks for Tegra124; So the COUNT_WEIGHT is
- * 4 * 256 = 1024.
- */
-#define ACTMON_COUNT_WEIGHT0x400
-
/*
* ACTMON_AVERAGE_WINDOW_LOG2: default value for @DEV_CTRL_K_VAL, which
* translates to 2 ^ (K_VAL + 1). ex: 2 ^ (6 + 1) = 128
@@ -111,7 +104,7 @@ enum tegra_actmon_device {
MCCPU,
};
-static const struct tegra_devfreq_device_config actmon_device_configs[] = {
+static const struct tegra_devfreq_device_config tegra124_device_configs[] = {
{
/* MCALL: All memory accesses (including from the CPUs) */
.offset = 0x1c0,
@@ -133,6 +126,28 @@ static const struct tegra_devfreq_device_config
actmon_device_configs[] = {
},
};
+static const struct tegra_devfreq_device_config tegra30_device_configs[] = {
+ {
+ /* MCALL: All memory accesses (including from the CPUs) */
+ .offset = 0x1c0,
+ .irq_mask = 1 << 26,
+ .boost_up_coeff = 200,
+ .boost_down_coeff = 50,
+ .boost_up_threshold = 20,
+ .boost_down_threshold = 10,
+ },
+ {
+ /* MCCPU: memory accesses from the CPUs */
+ .offset = 0x200,
+ .irq_mask = 1 << 25,
+ .boost_up_coeff = 800,
+ .boost_down_coeff = 40,
+ .boost_up_threshold = 27,
+ .boost_down_threshold = 10,
+ .avg_dependency_threshold = 16000, /* 16MHz in kHz units */
+ },
+};
+
/**
* struct tegra_devfreq_device - state specific to an ACTMON device
*
@@ -155,6 +170,12 @@ struct tegra_devfreq_device {
unsigned long target_freq;
};
+struct tegra_devfreq_soc_data {
+ const struct tegra_devfreq_device_config *configs;
+ /* Weight value for count measurements */
+ unsigned int count_weight;
+};
+
struct tegra_devfreq {
struct devfreq *devfreq;
struct opp_table*opp_table;
@@ -171,11 +192,13 @@ struct tegra_devfreq {
struct delayed_work cpufreq_update_work;
struct notifier_block cpu_rate_change_nb;
- struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
+ struct tegra_devfreq_device devices[2];
unsigned intirq;
boolstarted;
+
+ const struct tegra_devfreq_soc_data *soc;
};
struct tegra_actmon_emc_ratio {
@@ -488,7 +511,7 @@ static void tegra_actmon_configure_device(struct
tegra_devfreq *tegra,
tegra_devfreq_update_avg_wmark(tegra, dev);
tegra_devfreq_update_wmark(tegra, dev);
- device_writel(dev, ACTMON_COUNT_WEIGHT, ACTMON_DEV_COUNT_WEIGHT);
+ device_writel(dev, tegra->soc->count_weight, ACTMON_DEV_COUNT_WEIGHT);
device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
val |= ACTMON_DEV_CTRL_ENB_PERIODIC;
@@ -786,6 +809,8 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
if (!tegra)
return -ENOMEM;
+ tegra->soc = of_device_get_match_data(&pdev->dev);
+
tegra->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(tegra->regs))
return PTR_ERR(tegra->regs);
@@ -859,9 +884,9 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
tegra->max_freq = rate / KHZ;
- for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
+ for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
dev = tegra->devices + i;
- dev->config = actmon_device_configs + i;
+
[PATCH 2/8] drm: Document use-after-free gotcha with private objects
The private objects have a gotcha that could result in a use-after-free,
make sure it's properly documented.
Signed-off-by: Maxime Ripard
---
include/drm/drm_atomic.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 413fd0ca56a8..24b52b3a459f 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -248,6 +248,24 @@ struct drm_private_state_funcs {
*drm_dev_register()
* 2/ all calls to drm_atomic_private_obj_fini() must be done after calling
*drm_dev_unregister()
+ *
+ * If that private object is used to store a state shared my multiple
+ * CRTCs, proper care must be taken to ensure that non-blocking commits are
+ * properly ordered to avoid a use-after-free issue.
+ *
+ * Indeed, assuming a sequence of two non-blocking commits on two different
+ * CRTCs using different planes and connectors, so with no resources shared,
+ * there's no guarantee on which commit is going to happen first. However, the
+ * second commit will consider the first private state its old state, and will
+ * be in charge of freeing it whenever the second commit is done.
+ *
+ * If the first commit happens after it, it will consider its private state the
+ * new state and will be likely to access it, resulting in an access to a freed
+ * memory region. A way to circumvent this is to store (and get a reference to)
+ * the crtc commit in our private state in
+ * &drm_mode_config_helper_funcs.atomic_commit_setup, and then wait for that
+ * commit to complete as part of
+ * &drm_mode_config_helper_funcs.atomic_commit_tail.
*/
struct drm_private_obj {
/**
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/4] drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge function
Modify atomic_get_input_bus_format function to return input formats
based on the output format instead of using hardcoded value.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 110 --
1 file changed, 100 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index bdb0d95aa412..623eadb8948f 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2078,27 +2078,117 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge
*bridge)
return &cdns_mhdp_state->base;
}
+static const u32 cdns_mhdp_bus_fmts[] = {
+ MEDIA_BUS_FMT_YUV16_1X48,
+ MEDIA_BUS_FMT_RGB161616_1X48,
+ MEDIA_BUS_FMT_UYVY12_1X24,
+ MEDIA_BUS_FMT_YUV12_1X36,
+ MEDIA_BUS_FMT_RGB121212_1X36,
+ MEDIA_BUS_FMT_UYVY10_1X20,
+ MEDIA_BUS_FMT_YUV10_1X30,
+ MEDIA_BUS_FMT_RGB101010_1X30,
+ MEDIA_BUS_FMT_UYVY8_1X16,
+ MEDIA_BUS_FMT_YUV8_1X24,
+ MEDIA_BUS_FMT_RGB888_1X24
+};
+
+static bool cdns_mhdp_format_supported(u32 output_fmt)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(cdns_mhdp_bus_fmts); i++) {
+ if (output_fmt == cdns_mhdp_bus_fmts[i])
+ return true;
+ }
+
+ return false;
+}
+
+#define MAX_INPUT_FORMAT 4
+
static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
- struct drm_bridge_state *bridge_state,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state,
- u32 output_fmt,
- unsigned int *num_input_fmts)
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
{
u32 *input_fmts;
- u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
+ unsigned int i = 0;
*num_input_fmts = 0;
- if (output_fmt != MEDIA_BUS_FMT_FIXED)
+ if (!cdns_mhdp_format_supported(output_fmt) &&
+ output_fmt != MEDIA_BUS_FMT_FIXED)
return NULL;
- input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ input_fmts = kcalloc(MAX_INPUT_FORMAT,
+sizeof(*input_fmts), GFP_KERNEL);
if (!input_fmts)
return NULL;
- *num_input_fmts = 1;
- input_fmts[0] = default_bus_format;
+ switch (output_fmt) {
+ /* RGB */
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+
+ /* YUV444 */
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48;
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36;
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ break;
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36;
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ break;
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ break;
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ break;
+
+ /* YUV422 */
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24;
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ break;
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ input_fmts[i++]
[PATCH v9 10/17] ARM: tegra: Correct EMC registers size in Tegra20 device-tree
Fix the size of Tegra20 EMC registers, which should be twice bigger.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 72a4211a618f..9347f7789245 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -634,7 +634,7 @@ mc: memory-controller@7000f000 {
memory-controller@7000f400 {
compatible = "nvidia,tegra20-emc";
- reg = <0x7000f400 0x200>;
+ reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
#address-cells = <1>;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] fix dp link training failed at irq_hpd request
Some dongle require link training be done at irq_hpd request. This serial patches address the issues so that DP/HDMI display can be lit up properlly. This serial Patch also fixes clock stuck at "off" state error caused by previous link training failed. Kuogee Hsieh (3): drm/msm/dp: deinitialize mainlink if link training failed drm/msm/dp: skip checking LINK_STATUS_UPDATED bit drm/msm/dp: promote irq_hpd handle to handle link training correctly drivers/gpu/drm/msm/dp/dp_catalog.c | 2 +- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +- drivers/gpu/drm/msm/dp/dp_ctrl.c| 60 + drivers/gpu/drm/msm/dp/dp_display.c | 40 --- drivers/gpu/drm/msm/dp/dp_link.c| 29 +++--- drivers/gpu/drm/msm/dp/dp_panel.c | 2 +- 6 files changed, 96 insertions(+), 39 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
Hi!
Thanks for the patch.
Dne četrtek, 12. november 2020 ob 14:14:51 CET je Xiongfeng Wang napisal(a):
> Fix to return a negative error code from the error handling case instead
> of 0 in function sun8i_dw_hdmi_bind().
>
> Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
> Reported-by: Hulk Robot
> Signed-off-by: Xiongfeng Wang
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index d4c0804..f010fe8 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -208,6 +208,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
> device *master, phy_node = of_parse_phandle(dev->of_node, "phys", 0);
> if (!phy_node) {
> dev_err(dev, "Can't found PHY phandle\n");
> + ret = -ENODEV;
That should be EINVAL because DT node doesn't have mandatory property.
With that fixed, you can add:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> goto err_disable_clk_tmds;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/6] RDMA/umem: Support importing dma-buf as user memory region
On Fri, Nov 13, 2020 at 03:30:04AM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, November 12, 2020 4:31 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian Koenig
> > ; Vetter, Daniel
> >
> > Subject: Re: [PATCH v10 1/6] RDMA/umem: Support importing dma-buf as user
> > memory region
> >
> > On Tue, Nov 10, 2020 at 01:41:12PM -0800, Jianxin Xiong wrote:
> > > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > > +unsigned long offset, size_t size,
> > > +int fd, int access,
> > > +const struct dma_buf_attach_ops *ops) {
> > > + struct dma_buf *dmabuf;
> > > + struct ib_umem_dmabuf *umem_dmabuf;
> > > + struct ib_umem *umem;
> > > + unsigned long end;
> > > + long ret;
> > > +
> > > + if (check_add_overflow(offset, (unsigned long)size, &end))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> > > + return ERR_PTR(-EINVAL);
> >
> > This is weird, what does it do?
>
> This sequence is modeled after the following code from ib_umem_init_odp():
>
> if (check_add_overflow(umem_odp->umem.address,
>(unsigned long)umem_odp->umem.length,
>&end))
> return -EOVERFLOW;
> end = ALIGN(end, page_size);
> if (unlikely(end < page_size))
> return -EOVERFLOW;
>
> The weird part seems to be checking if 'end' is 0, but that should have been
> covered
> by check_add_overflow() already.
I think the
+ if (unlikely(!ib_umem_num_pages(umem))) {
Catches the same condition, no need to do it twice
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 05/17] drm/tegra: dc: Support memory bandwidth management
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The Memory Controller drivers provide facility for memory bandwidth
management via interconnect API. Let's wire up the interconnect API
support to the DC driver in order to fix the distorted display output
on T30 Ouya, T124 TK1 and other Tegra devices.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/dc.c| 349 ++
drivers/gpu/drm/tegra/dc.h| 14 ++
drivers/gpu/drm/tegra/drm.c | 14 ++
drivers/gpu/drm/tegra/hub.c | 3 +
drivers/gpu/drm/tegra/plane.c | 121
drivers/gpu/drm/tegra/plane.h | 15 ++
7 files changed, 517 insertions(+)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 5043dcaf1cf9..1650a448eabd 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -9,6 +9,7 @@ config DRM_TEGRA
select DRM_MIPI_DSI
select DRM_PANEL
select TEGRA_HOST1X
+ select INTERCONNECT
select IOMMU_IOVA
select CEC_CORE if CEC_NOTIFIER
help
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 85dd7131553a..5c587cfd1bb2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -616,6 +617,9 @@ static int tegra_plane_atomic_check(struct drm_plane *plane,
struct tegra_dc *dc = to_tegra_dc(state->crtc);
int err;
+ plane_state->peak_memory_bandwidth = 0;
+ plane_state->avg_memory_bandwidth = 0;
+
/* no need for further checks if the plane is being disabled */
if (!state->crtc)
return 0;
@@ -802,6 +806,12 @@ static struct drm_plane *tegra_primary_plane_create(struct
drm_device *drm,
formats = dc->soc->primary_formats;
modifiers = dc->soc->modifiers;
+ err = tegra_plane_interconnect_init(plane);
+ if (err) {
+ kfree(plane);
+ return ERR_PTR(err);
+ }
+
err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
&tegra_plane_funcs, formats,
num_formats, modifiers, type, NULL);
@@ -833,9 +843,13 @@ static const u32 tegra_cursor_plane_formats[] = {
static int tegra_cursor_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct tegra_plane_state *plane_state = to_tegra_plane_state(state);
struct tegra_plane *tegra = to_tegra_plane(plane);
int err;
+ plane_state->peak_memory_bandwidth = 0;
+ plane_state->avg_memory_bandwidth = 0;
+
/* no need for further checks if the plane is being disabled */
if (!state->crtc)
return 0;
@@ -973,6 +987,12 @@ static struct drm_plane
*tegra_dc_cursor_plane_create(struct drm_device *drm,
num_formats = ARRAY_SIZE(tegra_cursor_plane_formats);
formats = tegra_cursor_plane_formats;
+ err = tegra_plane_interconnect_init(plane);
+ if (err) {
+ kfree(plane);
+ return ERR_PTR(err);
+ }
+
err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
&tegra_plane_funcs, formats,
num_formats, NULL,
@@ -1087,6 +1107,12 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
num_formats = dc->soc->num_overlay_formats;
formats = dc->soc->overlay_formats;
+ err = tegra_plane_interconnect_init(plane);
+ if (err) {
+ kfree(plane);
+ return ERR_PTR(err);
+ }
+
if (!cursor)
type = DRM_PLANE_TYPE_OVERLAY;
else
@@ -1204,6 +1230,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
{
struct tegra_dc_state *state = to_dc_state(crtc->state);
struct tegra_dc_state *copy;
+ unsigned int i;
copy = kmalloc(sizeof(*copy), GFP_KERNEL);
if (!copy)
@@ -1215,6 +1242,9 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->div = state->div;
copy->planes = state->planes;
+ for (i = 0; i < ARRAY_SIZE(state->plane_peak_bw); i++)
+ copy->plane_peak_bw[i] = state->plane_peak_bw[i];
+
return ©->base;
}
@@ -1741,6 +1771,106 @@ static int tegra_dc_wait_idle(struct tegra_dc *dc,
unsigned long timeout)
return -ETIMEDOUT;
}
+static void
+tegra_crtc_update_memory_bandwidth(struct drm_crtc *crtc,
+ struct
[RESEND PATCH v2 0/5] drm/msm: support for host-cached BOs
v2: - added patches 2/3 to enable using dma_ops_bypass - changed DRM_MSM_GEM_SYNC_CACHE patch to use dma_sync_sg_for_device() and dma_sync_sg_for_cpu(), and renamed sync flags. Not sure I did the right thing with for the dma_ops_bypass part, this is what I came up with reading the emails. Jonathan Marek (5): drm/msm: add MSM_BO_CACHED_COHERENT dma-direct: add dma_direct_bypass() to force direct ops drm/msm: call dma_direct_bypass() drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance drm/msm: bump up the uapi version drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/msm/adreno/adreno_device.c | 1 + drivers/gpu/drm/msm/msm_drv.c | 32 +++--- drivers/gpu/drm/msm/msm_drv.h | 3 ++ drivers/gpu/drm/msm/msm_gem.c | 31 + include/linux/dma-direct.h | 9 ++ include/uapi/drm/msm_drm.h | 25 +++-- kernel/dma/direct.c| 23 8 files changed, 118 insertions(+), 7 deletions(-) -- 2.26.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 3/5] drm/msm: call dma_direct_bypass()
Always use direct dma ops and no swiotlb. Note: arm-smmu-qcom already avoids creating iommu dma ops, but not everything uses arm-smmu-qcom and this also sets the dma mask. Signed-off-by: Jonathan Marek --- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/msm_drv.c | 8 +--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index e5816b498494..07c50405970a 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -20,6 +20,7 @@ config DRM_MSM select SND_SOC_HDMI_CODEC if SND_SOC select SYNC_FILE select PM_OPP + select DMA_OPS_BYPASS help DRM/KMS driver for MSM/snapdragon. diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 49685571dc0e..bae48afca82e 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -6,6 +6,7 @@ */ #include +#include #include #include #include @@ -1288,10 +1289,11 @@ static int msm_pdev_probe(struct platform_device *pdev) if (ret) goto fail; - /* on all devices that I am aware of, iommu's which can map -* any address the cpu can see are used: + /* always use direct dma ops and no swiotlb +* note: arm-smmu-qcom already avoids creating iommu dma ops, but +* not everything uses arm-smmu-qcom and this also sets the dma mask */ - ret = dma_set_mask_and_coherent(&pdev->dev, ~0); + ret = dma_direct_bypass(&pdev->dev); if (ret) goto fail; -- 2.26.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 16/17] ARM: tegra: Add EMC OPP and ICC properties to Tegra30 EMC and ACTMON device-tree nodes
Add EMC OPP tables and interconnect paths that will be used for
dynamic memory bandwidth scaling based on memory utilization statistics.
Update board device-trees by removing unsupported EMC OPPs.
Note that ACTMON watches all memory interconnect paths, but we use a
single CPU-READ interconnect path for driving memory bandwidth, for
simplicity.
Signed-off-by: Dmitry Osipenko
---
...30-asus-nexus7-grouper-memory-timings.dtsi | 12 +
arch/arm/boot/dts/tegra30-ouya.dts| 8 +
.../arm/boot/dts/tegra30-peripherals-opp.dtsi | 383 ++
arch/arm/boot/dts/tegra30.dtsi| 6 +
4 files changed, 409 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-memory-timings.dtsi
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-memory-timings.dtsi
index bc0f6f29b956..bcff0997ee51 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-memory-timings.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-memory-timings.dtsi
@@ -1563,3 +1563,15 @@ timing-66700 {
};
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@75000,1300;
+ /delete-node/ opp@8,1300;
+ /delete-node/ opp@9,1350;
+};
+
+&emc_bw_dfs_opp_table {
+ /delete-node/ opp@75000;
+ /delete-node/ opp@8;
+ /delete-node/ opp@9;
+};
diff --git a/arch/arm/boot/dts/tegra30-ouya.dts
b/arch/arm/boot/dts/tegra30-ouya.dts
index a5f16ad6c8f4..74da1360d297 100644
--- a/arch/arm/boot/dts/tegra30-ouya.dts
+++ b/arch/arm/boot/dts/tegra30-ouya.dts
@@ -4509,3 +4509,11 @@ drive_groups {
nvidia,slew-rate-falling = ;
};
};
+
+&emc_icc_dvfs_opp_table {
+ /delete-node/ opp@9,1350;
+};
+
+&emc_bw_dfs_opp_table {
+ /delete-node/ opp@9;
+};
diff --git a/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
b/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
new file mode 100644
index ..cbe84d25e726
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ emc_icc_dvfs_opp_table: emc-dvfs-opp-table {
+ compatible = "operating-points-v2";
+
+ opp@1275,950 {
+ opp-microvolt = <95 95 135>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0006>;
+ };
+
+ opp@1275,1000 {
+ opp-microvolt = <100 100 135>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0001>;
+ };
+
+ opp@1275,1250 {
+ opp-microvolt = <125 125 135>;
+ opp-hz = /bits/ 64 <1275>;
+ opp-supported-hw = <0x0008>;
+ };
+
+ opp@2550,950 {
+ opp-microvolt = <95 95 135>;
+ opp-hz = /bits/ 64 <2550>;
+ opp-supported-hw = <0x0006>;
+ };
+
+ opp@2550,1000 {
+ opp-microvolt = <100 100 135>;
+ opp-hz = /bits/ 64 <2550>;
+ opp-supported-hw = <0x0001>;
+ };
+
+ opp@2550,1250 {
+ opp-microvolt = <125 125 135>;
+ opp-hz = /bits/ 64 <2550>;
+ opp-supported-hw = <0x0008>;
+ };
+
+ opp@2700,950 {
+ opp-microvolt = <95 95 135>;
+ opp-hz = /bits/ 64 <2700>;
+ opp-supported-hw = <0x0006>;
+ };
+
+ opp@2700,1000 {
+ opp-microvolt = <100 100 135>;
+ opp-hz = /bits/ 64 <2700>;
+ opp-supported-hw = <0x0001>;
+ };
+
+ opp@2700,1250 {
+ opp-microvolt = <125 125 135>;
+ opp-hz = /bits/ 64 <2700>;
+ opp-supported-hw = <0x0008>;
+ };
+
+ opp@5100,950 {
+ opp-microvolt = <95 95 135>;
+ opp-hz = /bits/ 64 <5100>;
+ opp-supported-hw = <0x0006>;
+ };
+
+ opp@5100,1000 {
+ opp-microvolt = <100 100 135>;
+ opp-hz = /bits/ 64 <5100>;
+ opp-supported-hw = <0x0001>;
+ };
+
+ opp@5100,1250 {
+ opp-microvolt = <125 125 135>;
+ opp-hz = /bits/ 64 <5100>;
+
[PATCH v1 4/4] drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus format
Get the pixel format and bpc based on the output bus format
negotiated instead of hardcoding the values.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 82 +++
1 file changed, 64 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 6f900bceb50c..44d79b0bd6d2 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1512,24 +1512,8 @@ static int cdns_mhdp_get_modes(struct drm_connector
*connector)
drm_connector_update_edid_property(connector, edid);
num_modes = drm_add_edid_modes(connector, edid);
- kfree(edid);
- /*
-* HACK: Warn about unsupported display formats until we deal
-* with them correctly.
-*/
- if (connector->display_info.color_formats &&
- !(connector->display_info.color_formats &
- mhdp->display_fmt.color_format))
- dev_warn(mhdp->dev,
-"%s: No supported color_format found (0x%08x)\n",
- __func__, connector->display_info.color_formats);
-
- if (connector->display_info.bpc &&
- connector->display_info.bpc < mhdp->display_fmt.bpc)
- dev_warn(mhdp->dev, "%s: Display bpc only %d < %d\n",
-__func__, connector->display_info.bpc,
-mhdp->display_fmt.bpc);
+ kfree(edid);
return num_modes;
}
@@ -1689,6 +1673,66 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
return 0;
}
+static void cdns_mhdp_get_display_fmt(struct cdns_mhdp_device *mhdp,
+ struct drm_bridge_state *state)
+{
+ u32 bus_fmt, bpc, pxlfmt;
+
+ bus_fmt = state->output_bus_cfg.format;
+ switch (bus_fmt) {
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ pxlfmt = DRM_COLOR_FORMAT_RGB444;
+ bpc = 16;
+ break;
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+ bpc = 16;
+ break;
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ pxlfmt = DRM_COLOR_FORMAT_RGB444;
+ bpc = 12;
+ break;
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+ bpc = 12;
+ break;
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+ bpc = 12;
+ break;
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ pxlfmt = DRM_COLOR_FORMAT_RGB444;
+ bpc = 10;
+ break;
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+ bpc = 10;
+ break;
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+ bpc = 10;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ pxlfmt = DRM_COLOR_FORMAT_RGB444;
+ bpc = 8;
+ break;
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+ bpc = 8;
+ break;
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+ bpc = 8;
+ break;
+ default:
+ pxlfmt = DRM_COLOR_FORMAT_RGB444;
+ bpc = 8;
+ }
+
+ mhdp->display_fmt.color_format = pxlfmt;
+ mhdp->display_fmt.bpc = bpc;
+}
+
static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
const struct drm_display_mode *mode)
{
@@ -2211,6 +2255,8 @@ static int cdns_mhdp_atomic_check(struct drm_bridge
*bridge,
struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ cdns_mhdp_get_display_fmt(mhdp, bridge_state);
+
mutex_lock(&mhdp->link_mutex);
if (!cdns_mhdp_bandwidth_ok(mhdp, mode, mhdp->link.num_lanes,
@@ -2539,7 +2585,7 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
mhdp->link.rate = mhdp->host.link_rate;
mhdp->link.num_lanes = mhdp->host.lanes_cnt;
- /* The only currently supported format */
+ /* Initialize color format bpc and y_only to default values*/
mhdp->display_fmt.y_only = false;
mhdp->display_fmt.color_format = DRM_COLOR_FORMAT_RGB444;
mhdp->display_fmt.bpc = 8;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 00/17] Introduce memory interconnect for NVIDIA Tegra SoCs
This series brings initial support for memory interconnect to Tegra20, Tegra30 and Tegra124 SoCs. For the starter only display controllers and devfreq devices are getting interconnect API support, others could be supported later on. The display controllers have the biggest demand for interconnect API right now because dynamic memory frequency scaling can't be done safely without taking into account bandwidth requirement from the displays. In particular this series fixes distorted display output on T30 Ouya and T124 TK1 devices. Changelog: v9: - Squashed "memory: tegra30-emc: Factor out clk initialization" into patch "tegra30: Support interconnect framework". Suggested by Krzysztof Kozlowski. - Improved Kconfig in the patch "memory: tegra124-emc: Make driver modular" by adding CONFIG_TEGRA124_CLK_EMC entry, which makes clk-driver changes to look a bit more cleaner. Suggested by Krzysztof Kozlowski. - Dropped voltage regulator support from ICC and DT patches for now because there is a new discussion about using a power domain abstraction for controlling the regulator, which is likely to happen. - Replaced direct "operating-points-v2" property checking in EMC drivers with checking of a returned error code from dev_pm_opp_of_add_table(). Note that I haven't touched T20 EMC driver because it's very likely that we'll replace that code with a common helper soon anyways. Suggested by Viresh Kumar. - The T30 DT patches now include EMC OPP changes for Ouya board, which is available now in linux-next. Dmitry Osipenko (17): memory: tegra30: Support interconnect framework memory: tegra124-emc: Make driver modular memory: tegra124-emc: Continue probing if timings are missing in device-tree memory: tegra124: Support interconnect framework drm/tegra: dc: Support memory bandwidth management drm/tegra: dc: Extend debug stats with total number of events PM / devfreq: tegra30: Support interconnect and OPPs from device-tree PM / devfreq: tegra30: Separate configurations per-SoC generation PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver ARM: tegra: Correct EMC registers size in Tegra20 device-tree ARM: tegra: Add interconnect properties to Tegra20 device-tree ARM: tegra: Add interconnect properties to Tegra30 device-tree ARM: tegra: Add interconnect properties to Tegra124 device-tree ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC device-tree ARM: tegra: Add EMC OPP properties to Tegra20 device-trees ARM: tegra: Add EMC OPP and ICC properties to Tegra30 EMC and ACTMON device-tree nodes ARM: tegra: Add EMC OPP and ICC properties to Tegra124 EMC and ACTMON device-tree nodes MAINTAINERS | 1 - arch/arm/boot/dts/tegra124-apalis-emc.dtsi| 8 + .../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi | 8 + arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi | 10 + .../arm/boot/dts/tegra124-nyan-blaze-emc.dtsi | 10 + .../boot/dts/tegra124-peripherals-opp.dtsi| 419 ++ arch/arm/boot/dts/tegra124.dtsi | 31 ++ .../boot/dts/tegra20-acer-a500-picasso.dts| 5 + arch/arm/boot/dts/tegra20-colibri.dtsi| 4 + arch/arm/boot/dts/tegra20-paz00.dts | 4 + .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 92 arch/arm/boot/dts/tegra20.dtsi| 33 +- ...30-asus-nexus7-grouper-memory-timings.dtsi | 12 + arch/arm/boot/dts/tegra30-ouya.dts| 8 + .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 383 arch/arm/boot/dts/tegra30.dtsi| 33 +- drivers/clk/tegra/Kconfig | 3 + drivers/clk/tegra/Makefile| 2 +- drivers/clk/tegra/clk-tegra124-emc.c | 41 +- drivers/clk/tegra/clk-tegra124.c | 26 +- drivers/clk/tegra/clk.h | 18 +- drivers/devfreq/Kconfig | 10 - drivers/devfreq/Makefile | 1 - drivers/devfreq/tegra20-devfreq.c | 210 - drivers/devfreq/tegra30-devfreq.c | 154 --- drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c| 359 +++ drivers/gpu/drm/tegra/dc.h| 19 + drivers/gpu/drm/tegra/drm.c | 14 + drivers/gpu/drm/tegra/hub.c | 3 + drivers/gpu/drm/tegra/plane.c | 121 + drivers/gpu/drm/tegra/plane.h | 15 + drivers/memory/tegra/Kconfig | 5 +- drivers/memory/tegra/tegra124-emc.c | 382 ++-- drivers/memory/tegra/tegra124.c | 82 +++- drivers/memory/tegra/tegra30-emc.c| 349 ++- drivers/memory/tegra/tegra30.c| 173 +++- include/linux/clk/tegra.h | 8 + include/soc/tegra/e
[PATCH 7/8] drm/vc4: kms: Remove async modeset semaphore
Now that we have proper ordering guaranteed by the previous patch, the
semaphore is redundant and can be removed.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 13 -
drivers/gpu/drm/vc4/vc4_drv.h | 2 --
drivers/gpu/drm/vc4/vc4_kms.c | 20 +---
3 files changed, 1 insertion(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 29b77f4b4e56..65d43e2e1d51 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -699,7 +699,6 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
container_of(cb, struct vc4_async_flip_state, cb);
struct drm_crtc *crtc = flip_state->crtc;
struct drm_device *dev = crtc->dev;
- struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_plane *plane = crtc->primary;
vc4_plane_async_set_fb(plane, flip_state->fb);
@@ -731,8 +730,6 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
}
kfree(flip_state);
-
- up(&vc4->async_modeset);
}
/* Implements async (non-vblank-synced) page flips.
@@ -747,7 +744,6 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
uint32_t flags)
{
struct drm_device *dev = crtc->dev;
- struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_plane *plane = crtc->primary;
int ret = 0;
struct vc4_async_flip_state *flip_state;
@@ -776,15 +772,6 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
flip_state->crtc = crtc;
flip_state->event = event;
- /* Make sure all other async modesetes have landed. */
- ret = down_interruptible(&vc4->async_modeset);
- if (ret) {
- drm_framebuffer_put(fb);
- vc4_bo_dec_usecnt(bo);
- kfree(flip_state);
- return ret;
- }
-
/* Save the current FB before it's replaced by the new one in
* drm_atomic_set_fb_for_plane(). We'll need the old FB in
* vc4_async_page_flip_complete() to decrement the BO usecnt and keep
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 9eefd76cb09e..60062afba7b6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -215,8 +215,6 @@ struct vc4_dev {
struct work_struct reset_work;
} hangcheck;
- struct semaphore async_modeset;
-
struct drm_modeset_lock ctm_state_lock;
struct drm_private_obj ctm_manager;
struct drm_private_obj hvs_channels;
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 849bc6b4cea4..79ab7b8a5e0e 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -414,8 +414,6 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
clk_set_min_rate(hvs->core_clk, 0);
drm_atomic_state_put(state);
-
- up(&vc4->async_modeset);
}
static void commit_work(struct work_struct *work)
@@ -473,14 +471,9 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct drm_atomic_state *state,
bool nonblock)
{
- struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
if (state->async_update) {
- ret = down_interruptible(&vc4->async_modeset);
- if (ret)
- return ret;
-
ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret) {
up(&vc4->async_modeset);
@@ -491,8 +484,6 @@ static int vc4_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
- up(&vc4->async_modeset);
-
return 0;
}
@@ -508,21 +499,14 @@ static int vc4_atomic_commit(struct drm_device *dev,
INIT_WORK(&state->commit_work, commit_work);
- ret = down_interruptible(&vc4->async_modeset);
- if (ret)
- return ret;
-
ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret) {
- up(&vc4->async_modeset);
+ if (ret)
return ret;
- }
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret) {
drm_atomic_helper_cleanup_planes(dev, state);
- up(&vc4->async_modeset);
return ret;
}
}
@@ -1006,8 +990,6 @@ int vc4_kms_load(struct drm_device *dev)
vc4->load_tracker_enabled = true;
}
- sema_init(&vc4->async_modeset, 1);
-
/* Set support for vblank irq fast disable, before drm_vblank_init() */
dev->vblank_disable_immediate = true;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
[PATCH v1 0/4] Add bus format negotiation support for Cadence MHDP8546 driver
This patch series add bus format negotiation support for Cadence MHDP8546 bridge driver. The patch series has four patches in the below sequence: 1. drm: bridge: cdns-mhdp8546: Add output bus format negotiation Add minimal output bus format negotiation support. 2. drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge function. Get the input format based on output format supported. 3. drm: bridge: cdns-mhdp8546: Remove setting of bus format using connector info Remove the bus format configuration using connector info structure. 4. drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus format Get the pixel format and bpc based on negotiated output bus format. This patch series is dependent on tidss series [1] for the new connector model support. [1] https://patchwork.kernel.org/project/dri-devel/cover/20201109170601.21557-1-nikhil...@ti.com/ Yuti Amonkar (4): drm: bridge: cdns-mhdp8546: Add output bus format negotiation drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge function drm: bridge: cdns-mhdp8546: Remove setting of bus format using connector info drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus format .../drm/bridge/cadence/cdns-mhdp8546-core.c | 216 +++--- 1 file changed, 182 insertions(+), 34 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 09/17] PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
Remove tegra20-devfreq in order to replace it with a EMC_STAT based
devfreq driver. Previously we were going to use MC_STAT based
tegra20-devfreq driver because EMC_STAT wasn't working properly, but
now that problem is resolved. This resolves complications imposed by
the removed driver since it was depending on both EMC and MC drivers
simultaneously.
Acked-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 1 -
drivers/devfreq/Kconfig | 10 --
drivers/devfreq/Makefile | 1 -
drivers/devfreq/tegra20-devfreq.c | 210 --
4 files changed, 222 deletions(-)
delete mode 100644 drivers/devfreq/tegra20-devfreq.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0818a5b03832..f1fd25d7e9ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11389,7 +11389,6 @@ L: linux...@vger.kernel.org
L: linux-te...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git
S: Maintained
-F: drivers/devfreq/tegra20-devfreq.c
F: drivers/devfreq/tegra30-devfreq.c
MEMORY MANAGEMENT
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 0ee36ae2fa79..00704efe6398 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -121,16 +121,6 @@ config ARM_TEGRA_DEVFREQ
It reads ACTMON counters of memory controllers and adjusts the
operating frequencies and voltages with OPP support.
-config ARM_TEGRA20_DEVFREQ
- tristate "NVIDIA Tegra20 DEVFREQ Driver"
- depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
- depends on COMMON_CLK
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- help
- This adds the DEVFREQ driver for the Tegra20 family of SoCs.
- It reads Memory Controller counters and adjusts the operating
- frequencies and voltages with OPP support.
-
config ARM_RK3399_DMC_DEVFREQ
tristate "ARM RK3399 DMC DEVFREQ Driver"
depends on (ARCH_ROCKCHIP && HAVE_ARM_SMCCC) || \
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 3ca1ad0ecb97..a16333ea7034 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -13,7 +13,6 @@ obj-$(CONFIG_ARM_IMX_BUS_DEVFREQ) += imx-bus.o
obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra30-devfreq.o
-obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/tegra20-devfreq.c
b/drivers/devfreq/tegra20-devfreq.c
deleted file mode 100644
index fd801534771d..
--- a/drivers/devfreq/tegra20-devfreq.c
+++ /dev/null
@@ -1,210 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * NVIDIA Tegra20 devfreq driver
- *
- * Copyright (C) 2019 GRATE-DRIVER project
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "governor.h"
-
-#define MC_STAT_CONTROL0x90
-#define MC_STAT_EMC_CLOCK_LIMIT0xa0
-#define MC_STAT_EMC_CLOCKS 0xa4
-#define MC_STAT_EMC_CONTROL0xa8
-#define MC_STAT_EMC_COUNT 0xb8
-
-#define EMC_GATHER_CLEAR (1 << 8)
-#define EMC_GATHER_ENABLE (3 << 8)
-
-struct tegra_devfreq {
- struct devfreq *devfreq;
- struct clk *emc_clock;
- void __iomem *regs;
-};
-
-static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
- u32 flags)
-{
- struct tegra_devfreq *tegra = dev_get_drvdata(dev);
- struct devfreq *devfreq = tegra->devfreq;
- struct dev_pm_opp *opp;
- unsigned long rate;
- int err;
-
- opp = devfreq_recommended_opp(dev, freq, flags);
- if (IS_ERR(opp))
- return PTR_ERR(opp);
-
- rate = dev_pm_opp_get_freq(opp);
- dev_pm_opp_put(opp);
-
- err = clk_set_min_rate(tegra->emc_clock, rate);
- if (err)
- return err;
-
- err = clk_set_rate(tegra->emc_clock, 0);
- if (err)
- goto restore_min_rate;
-
- return 0;
-
-restore_min_rate:
- clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
-
- return err;
-}
-
-static int tegra_devfreq_get_dev_status(struct device *dev,
- struct devfreq_dev_status *stat)
-{
- struct tegra_devfreq *tegra = dev_get_drvdata(dev);
-
- /*
-* EMC_COUNT returns number of memory events, that number is lower
-* than the number of clocks. Conversion ratio of 1/8 results in a
-* bit higher bandwidth than actually needed, it is good enough for
-* the time being because drivers don't support requesting minimum
-* needed memory bandwidth yet.
-*
-* TODO: ad
[PATCH v9 04/17] memory: tegra124: Support interconnect framework
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS.
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/Kconfig| 1 +
drivers/memory/tegra/tegra124-emc.c | 325 +++-
drivers/memory/tegra/tegra124.c | 82 ++-
3 files changed, 396 insertions(+), 12 deletions(-)
diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index f5b451403c58..a70967a56e52 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -36,6 +36,7 @@ config TEGRA124_EMC
default y
depends on TEGRA_MC && ARCH_TEGRA_124_SOC
select TEGRA124_CLK_EMC
+ select PM_OPP
help
This driver is for the External Memory Controller (EMC) found on
Tegra124 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/tegra124-emc.c
b/drivers/memory/tegra/tegra124-emc.c
index 8fb8c1af25c9..ed34ca982364 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -12,20 +12,26 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include "mc.h"
+
#define EMC_FBIO_CFG5 0x104
#defineEMC_FBIO_CFG5_DRAM_TYPE_MASK0x3
#defineEMC_FBIO_CFG5_DRAM_TYPE_SHIFT 0
+#define EMC_FBIO_CFG5_DRAM_WIDTH_X64 BIT(4)
#define EMC_INTSTATUS 0x0
#define EMC_INTSTATUS_CLKCHANGE_COMPLETE BIT(4)
@@ -461,6 +467,17 @@ struct emc_timing {
u32 emc_zcal_interval;
};
+enum emc_rate_request_type {
+ EMC_RATE_DEBUG,
+ EMC_RATE_ICC,
+ EMC_RATE_TYPE_MAX,
+};
+
+struct emc_rate_request {
+ unsigned long min_rate;
+ unsigned long max_rate;
+};
+
struct tegra_emc {
struct device *dev;
@@ -471,6 +488,7 @@ struct tegra_emc {
struct clk *clk;
enum emc_dram_type dram_type;
+ unsigned int dram_bus_width;
unsigned int dram_num;
struct emc_timing last_timing;
@@ -482,6 +500,17 @@ struct tegra_emc {
unsigned long min_rate;
unsigned long max_rate;
} debugfs;
+
+ struct icc_provider provider;
+
+ /*
+* There are multiple sources in the EMC driver which could request
+* a min/max clock rate, these rates are contained in this array.
+*/
+ struct emc_rate_request requested_rate[EMC_RATE_TYPE_MAX];
+
+ /* protect shared rate-change code path */
+ struct mutex rate_lock;
};
/* Timing change sequence functions */
@@ -870,6 +899,14 @@ static void emc_read_current_timing(struct tegra_emc *emc,
static int emc_init(struct tegra_emc *emc)
{
emc->dram_type = readl(emc->regs + EMC_FBIO_CFG5);
+
+ if (emc->dram_type & EMC_FBIO_CFG5_DRAM_WIDTH_X64)
+ emc->dram_bus_width = 64;
+ else
+ emc->dram_bus_width = 32;
+
+ dev_info(emc->dev, "%ubit DRAM bus\n", emc->dram_bus_width);
+
emc->dram_type &= EMC_FBIO_CFG5_DRAM_TYPE_MASK;
emc->dram_type >>= EMC_FBIO_CFG5_DRAM_TYPE_SHIFT;
@@ -1009,6 +1046,83 @@ tegra_emc_find_node_by_ram_code(struct device_node
*node, u32 ram_code)
return NULL;
}
+static void tegra_emc_rate_requests_init(struct tegra_emc *emc)
+{
+ unsigned int i;
+
+ for (i = 0; i < EMC_RATE_TYPE_MAX; i++) {
+ emc->requested_rate[i].min_rate = 0;
+ emc->requested_rate[i].max_rate = ULONG_MAX;
+ }
+}
+
+static int emc_request_rate(struct tegra_emc *emc,
+ unsigned long new_min_rate,
+ unsigned long new_max_rate,
+ enum emc_rate_request_type type)
+{
+ struct emc_rate_request *req = emc->requested_rate;
+ unsigned long min_rate = 0, max_rate = ULONG_MAX;
+ unsigned int i;
+ int err;
+
+ /* select minimum and maximum rates among the requested rates */
+ for (i = 0; i < EMC_RATE_TYPE_MAX; i++, req++) {
+ if (i == type) {
+ min_rate = max(new_min_rate, min_rate);
+ max_rate = min(new_max_rate, max_rate);
+ } else {
+ min_rate = max(req->min_rate, min_rate);
+ max_rate = min(req->max_rate, max_rate);
+ }
+ }
+
+ if (min_rate > max_rate) {
+ dev_err_ratelimited(emc->dev, "%s: type %u: out of range: %lu
%lu\n",
+ __func__, type, min_rate, max_rate);
+ return -ERANGE;
+ }
+
+ /*
+* EMC rate-changes should go via OPP API because it manages voltage
+* changes.
+*/
+
Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
13.11.2020 17:29, Mark Brown пишет: > On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote: >> 12.11.2020 23:01, Mark Brown пишет: But it's not allowed to change voltage of a dummy regulator, is it intentional? > >>> Of course not, we can't know if the requested new voltage is valid - the >>> driver would have to have explict support for handling situations where >>> it's not possible to change the voltage (which it can detect through >>> enumerating the values it wants to set at startup). > >>> [Requesting the same supply multiple times] > >> But how driver is supposed to recognize that it's a dummy or buggy >> regulator if it rejects all voltages? > > It's not clear if it matters - it's more a policy decision on the part > of the driver about what it thinks safe error handling is. If it's not > possible to read voltages from the regulator the consumer driver has to > decide what it thinks it's safe for it to do, either way it has no idea > what the actual current voltage is. It could assume that it's something > that supports all the use cases it wants to use and just carry on with > no configuration of voltages, it could decide that it might not support > everything and not make any changes to be safe, or do something like > try to figure out that if we're currently at a given OPP that's the top > OPP possible. Historically when we've not had regulator control in > these drivers so they have effectively gone with the first option of > just assuming it's a generally safe value, this often aligns with what > the power on requirements for SoCs are so it's not unreasonable. I don't think that in a case of this particular driver there is a way to make any decisions other than to assume that all changes are safe to be done if regulator isn't specified in a device-tree. If regulator_get() returns a dummy regulator, then this means that regulator isn't specified in a device-tree. But then the only way for a consumer driver to check whether regulator is dummy, is to check presence of the supply property in a device-tree. We want to emit error messages when something goes wrong, for example when regulator voltage fails to change. It's fine that voltage changes are failing for a dummy regulator, but then consumer driver shouldn't recognize it as a error condition. The regulator_get_optional() provides a more consistent and straightforward way for consumer drivers to check presence of a physical voltage regulator in comparison to dealing with a regulator_get(). The dummy regulator is nice to use when there is no need to change regulator's voltage, which doesn't work for a dummy regulator. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 03/17] memory: tegra124-emc: Continue probing if timings are missing in device-tree
EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/tegra124-emc.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/memory/tegra/tegra124-emc.c
b/drivers/memory/tegra/tegra124-emc.c
index edfbf6d6d357..8fb8c1af25c9 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -1201,23 +1201,15 @@ static int tegra_emc_probe(struct platform_device *pdev)
ram_code = tegra_read_ram_code();
np = tegra_emc_find_node_by_ram_code(pdev->dev.of_node, ram_code);
- if (!np) {
- dev_err(&pdev->dev,
- "no memory timings for RAM code %u found in DT\n",
- ram_code);
- return -ENOENT;
- }
-
- err = tegra_emc_load_timings_from_dt(emc, np);
- of_node_put(np);
- if (err)
- return err;
-
- if (emc->num_timings == 0) {
- dev_err(&pdev->dev,
- "no memory timings for RAM code %u registered\n",
- ram_code);
- return -ENOENT;
+ if (np) {
+ err = tegra_emc_load_timings_from_dt(emc, np);
+ of_node_put(np);
+ if (err)
+ return err;
+ } else {
+ dev_info(&pdev->dev,
+"no memory timings for RAM code %u found in DT\n",
+ram_code);
}
err = emc_init(emc);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On 11/14/20 1:46 PM, Rob Clark wrote:
On Sat, Nov 14, 2020 at 8:24 AM Christoph Hellwig wrote:
On Sat, Nov 14, 2020 at 10:17:12AM -0500, Jonathan Marek wrote:
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+ size_t range_start, size_t range_end)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct device *dev = msm_obj->base.dev->dev;
+
+ /* exit early if get_pages() hasn't been called yet */
+ if (!msm_obj->pages)
+ return;
+
+ /* TODO: sync only the specified range */
+
+ if (flags & MSM_GEM_SYNC_FOR_DEVICE) {
+ dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
+ msm_obj->sgt->nents, DMA_TO_DEVICE);
+ }
+
+ if (flags & MSM_GEM_SYNC_FOR_CPU) {
+ dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
+ msm_obj->sgt->nents, DMA_FROM_DEVICE);
+ }
Splitting this helper from the only caller is rather strange, epecially
with the two unused arguments. And I think the way this is specified
to take a range, but ignoring it is actively dangerous. User space will
rely on it syncing everything sooner or later and then you are stuck.
So just define a sync all primitive for now, and if you really need a
range sync and have actually implemented it add a new ioctl for that.
We do already have a split of ioctl "layer" which enforces valid ioctl
params, etc, and gem (or other) module code which is called by the
ioctl func. So I think it is fine to keep this split here. (Also, I
think at some point there will be a uring type of ioctl alternative
which would re-use the same gem func.)
But I do agree that the range should be respected or added later..
drm_ioctl() dispatch is well prepared for extending ioctls.
And I assume there should be some validation that the range is aligned
to cache-line? Or can we flush a partial cache line?
The range is intended to be "sync at least this range", so that
userspace doesn't have to worry about details like that.
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
13.11.2020 19:35, Thierry Reding пишет: > On Fri, Nov 13, 2020 at 01:14:45AM +0300, Dmitry Osipenko wrote: >> 12.11.2020 23:43, Thierry Reding пишет: The difference in comparison to using voltage regulator directly is minimal, basically the core-supply phandle is replaced is replaced with a power-domain phandle in a device tree. >>> These new power-domain handles would have to be added to devices that >>> potentially already have a power-domain handle, right? Isn't that going >>> to cause issues? I vaguely recall that we already have multiple power >>> domains for the XUSB controller and we have to jump through extra hoops >>> to make that work. >> >> I modeled the core PD as a parent of the PMC sub-domains, which >> presumably is a correct way to represent the domains topology. >> >> https://gist.github.com/digetx/dfd92c7f7e0aa6cef20403c4298088d7 >> The only thing which makes me feel a bit uncomfortable is that there is no real hardware node for the power domain node in a device-tree. >>> Could we anchor the new power domain at the PMC for example? That would >>> allow us to avoid the "virtual" node. >> >> I had a thought about using PMC for the core domain, but not sure >> whether it will be an entirely correct hardware description. Although, >> it will be nice to have it this way. >> >> This is what Tegra TRM says about PMC: >> >> "The Power Management Controller (PMC) block interacts with an external >> or Power Manager Unit (PMU). The PMC mostly controls the entry and exit >> of the system from different sleep modes. It provides power-gating >> controllers for SOC and CPU power-islands and also provides scratch >> storage to save some of the context during sleep modes (when CPU and/or >> SOC power rails are off). Additionally, PMC interacts with the external >> Power Manager Unit (PMU)." >> >> The core voltage regulator is a part of the PMU. >> >> Not all core SoC devices are behind PMC, IIUC. > > There are usually some SoC devices that are always-on. Things like the > RTC for example, can never be power-gated, as far as I recall. On newer > chips there are usually many more blocks that can't be powergated at > all. The RTC is actually a special power domain on Tegra, it's not a part of the CORE domain, they are separate from each other. We need to know what blocks belong to a power domain and what's the power topology of these blocks. I think we already have this knowledge, so it shouldn't be a problem. >>> On the other hand, if we were to >>> use a regulator, we'd be adding a node for that, right? So isn't this >>> effectively going to be the same node if we use a power domain? Both >>> software constructs are using the same voltage regulator, so they should >>> be able to be described by the same device tree node, shouldn't they? >> >> I'm not exactly sure what you're meaning by "use a regulator" and "we'd >> be adding a node for that", could you please clarify? This v1 approach >> uses a core-supply phandle (i.e. regulator is used), it doesn't require >> extra nodes. > > What I meant to say was that the actual supply voltage is generated by > some device (typically one of the SD outputs of the PMIC). Whether we > model this as a power domain or a regulator doesn't really matter, > right? So I'm wondering if the device that generates the voltage should > be the power domain provider, just like it is the provider of the > regulator if this was modelled as a regulator. Technically this could be done and it shouldn't be difficult to add GENPD support to the regulator framework, but I think this is an inaccurate hardware description. It shouldn't be correct to describe internal SoC parts as directly-connected to an external voltage regulator. The core voltage regulator is connected to a one of several power rails of the Tegra chip. There is no good way to describe hardware in terms of voltage regulators, hence that's why this v1 series added a core-supply to each SoC component of each board's DT individually. It's actually one of the benefits of using a separate DT node for the power-domain, which describes the "Tegra Core" part of the Tegra SoC, and thus, it all stays within tegra.dtsi. This means that PD explicitly belongs to the SoC internals in oppose to describing PD like it's an external/off-chip component. Initially I didn't like much that there is no hardware address to back up the power domain node in a DT, but actually there is no address for the power rail. Hence it should be better to describe hardware by keeping PD internally to the SoC. Note that potentially PD may require knowledge about specifics of a particular SoC, while external regulator doesn't belong to a SoC. Also, I guess technically there could be multiple external regulators which power a single SoC rail. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder
On 02-11-20, 07:08, Chun-Kuang Hu wrote:
> + Vinod:
>
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年10月30日 週五 下午2:24寫道：
> >
> > On Thu, 2020-10-29 at 23:27 +0800, Chun-Kuang Hu wrote:
> > > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> > > more suitable to place a phy driver into phy driver folder, so move
> > > mtk_mipi_dsi_phy driver into phy driver folder.
> > >
> > > Signed-off-by: Chun-Kuang Hu
> > > ---
> > > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > > drivers/gpu/drm/mediatek/Makefile | 6 --
> > > drivers/phy/mediatek/Kconfig | 7 +++
> > > drivers/phy/mediatek/Makefile | 5 +
> > > .../mediatek/phy-mtk-mipi-dsi-mt8173.c}| 2 +-
> > > .../mediatek/phy-mtk-mipi-dsi-mt8183.c}| 2 +-
> > > .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 2 +-
> > > .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0
> > > 8 files changed, 15 insertions(+), 16 deletions(-)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h =>
> > > phy/mediatek/phy-mtk-mipi-dsi.h} (100%)
> >
> > Reviewed-by: Chunfeng Yun
>
> I would like to apply the whole series into my tree, would you please
> give an acked-by tag on this patch, so I could apply this patch into
> my tree.
I would prefer this to go thru phy tree, unless there are dependencies,
which I am not clear looking at above
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/virtio: Make virtgpu_dmabuf_ops with static keyword
On Sat, Nov 14, 2020 at 03:16:13PM +0800, Zou Wei wrote: > Fix the following sparse warning: > > ./virtgpu_prime.c:46:33: warning: symbol 'virtgpu_dmabuf_ops' was not > declared. Should it be static? Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
