On 2/23/21 11:59 AM, Daniel Vetter wrote:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices,
On 2/23/21 7:36 PM, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add any changes destined for v5.13 to your linux-next
> included branches until after v5.12-rc1 has been released.
>
> Changes since 20210223:
>
on i386:
ERROR: modpost: "__udivdi3" [drive
When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().
Signed-off-by: Hsin-Yi Wang
anx7625 requires 3 power supply regulators.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Rob Herring
Reviewed-by: Robert Foss
---
v3->v4: rebase to drm-misc/for-linux-next
---
.../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
1 file changed, 15 insertions(+)
diff --git
Hi
Am 23.02.21 um 16:45 schrieb Alan Stern:
On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -29,6 +29,7 @@
#include
#include
#include
Hi
Am 23.02.21 um 18:30 schrieb Greg KH:
On Tue, Feb 23, 2021 at 11:00:54AM -0500, Alan Stern wrote:
On Tue, Feb 23, 2021 at 03:06:07PM +0100, Thomas Zimmermann wrote:
Hi
Am 23.02.21 um 14:44 schrieb Takashi Iwai:
Aside from the discussion whether this "workaround" is needed, the use
of
[AMD Public Use]
Acked-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, February 24, 2021 11:35 AM
To: Pan, Xinhui
Cc: Deucher, Alexander ; Maling list - DRI
developers ; Koenig, Christian
; amd-gfx list
Subject: Re:
Currently, for WLED5, after FSC register update MOD_SYNC_BIT
is toggled instead of SYNC_BIT. MOD_SYNC_BIT has to be toggled
after the brightness update and SYNC_BIT has to be toggled after
FSC update for WLED5. Fix it.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 25
Currently the FSC SYNC_BIT and MOD_SYNC_BIT are toggled
from 1 to 0 to update the FSC and brightenss settings.
Change this sequence form 0 to 1 as per the hardware team
recommendation to update the FSC and brightness correctly.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c
The FSC (Full scale current) setting is not updated properly due to the
wrong register toggling for WLED5. Also the ILED_SYNC toggle and MOD_SYNC
toggle sequence is updated as per the hardware team recommendation to fix
the FSC update and brightness update issue.
Kiran Gunda (2):
backlight:
On 2021-02-19 23:38, Pavel Machek wrote:
Hi!
The FSC (Full scale current) setting is not updated properly due to
the
wrong register toggling for WLED5. Also the ILED_SYNC toggle and
MOD_SYNC
toggle sequence is updated as per the hardware team recommendation to
fix
the FSC update and
On Tue, Feb 23, 2021 at 10:28 PM xinhui pan wrote:
>
> BO would be added into swap list if it is validated into system domain.
> If BO is validated again into non-system domain, say, VRAM domain. It
> actually should not be in the swap list.
>
> Signed-off-by: xinhui pan
Acked-by: Alex Deucher
BO would be added into swap list if it is validated into system domain.
If BO is validated again into non-system domain, say, VRAM domain. It
actually should not be in the swap list.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Something that didn't get noticed until I started running cursor tests:
we're accidentally disabling an option for CRC calculation that's enabled
by default: WidePipeCrc, which controls whether we use the full width of
the data in the display pipe in order calculate CRCs. Having this disabled
Update the mediatek,dpi binding to use the graph schema. Missed
this one from the mass conversion since it's not part of drm-misc.
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: CK Hu
Cc: Jitao shi
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
On Sat, 6 Feb 2021 14:50:20 +0100, Heiko Stuebner wrote:
> The panel is able to work when dsi clock is non-continuous, thus
> the system power consumption can be reduced using such feature.
>
> Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags.
>
> Also the flag actually becomes necessary
On Tue, 11 Aug 2020 16:26:31 -0400, Alyssa Rosenzweig wrote:
> The AFBC decoder used in the Rockchip VOP assumes the use of the
> YUV-like colourspace transform (YTR). YTR is lossless for RGB(A)
> buffers, which covers the RGBA8 and RGB565 formats supported in
> vop_convert_afbc_format. Use of YTR
By having selected DRM_XEN, I was assuming I would build the frontend
driver. As it turns out this is a dummy option, and I have really not
been building this (because I had DRM disabled). Make it a promptless
one, moving the "depends on" to the other, real option, and "select"ing
the dummy one.
From: Colin Ian King
The recent commit 6c63e6e14da7 ("drm/i915/hdcp: No HDCP when encoder
is't initialized") added a null pointer check on connector->encoder
hence implying that it could potentially be null. This means that
the initialization of dig_port via the call intel_attached_dig_port
may
Hi Brian,
On Tue, 23 Feb 2021 at 18:34, Brian Starkey wrote:
> On Tue, Feb 23, 2021 at 05:10:16PM +, Alyssa Rosenzweig wrote:
> > But it seems to me allowing
> > both BGR+YTR and RGB+YTR upstream is the better route than simply
> > preventing hardware from using AFBC at all, and there are
On Tue, Feb 23, 2021 at 05:10:16PM +, Alyssa Rosenzweig wrote:
> > If YTR can't be turned off, then according to the AFBC spec - correct.
>
> There is no public AFBC spec, so I'm not sure how to respond to this.
>
> > If the hardware allows it to be configured to use YTR with other
> >
Pushed, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
wrote:
>
> Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> > Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > > I'd recommend using xf86-video-nouveau in any case, but some distros
> >
> > I would like try this out. Do you know how to force the xorg
Lontium Lt8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912.c | 764
4
Lontium LT8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reviewed-by: Rob Herring
---
.../display/bridge/lontium,lt8912.yaml| 102 ++
MAINTAINERS | 5 +
2 files changed, 107 insertions(+)
create mode 100644
Hi,
this patch set adds the support of the Lontium lt8912 MIPI to HDMI
bridge in the kernel.
It's only support the video part, not the audio part yet
since I don't have the datasheet of this component.
I get the current i2c configuration from Digi and
Boundary drivers.
Developed using the
On Wed, Feb 10, 2021 at 10:14 PM Simon Ser wrote:
>
> On Wednesday, February 10th, 2021 at 10:04 PM, Mario Kleiner
> wrote:
>
> > Ping!
>
> I now understand the problem better.
>
> Reviewed-by: Simon Ser
>
> I'll push to drm-misc-next in a few days if no-one complains. Ping me
> again if I
On Mon, Feb 22, 2021 at 10:44 PM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/amdgpu/athub_v2_1.c:79:40-45: WARNING: conversion
> to bool not needed here.
>
> ./drivers/gpu/drm/amd/amdgpu/athub_v2_1.c:81:40-45: WARNING: conversion
> to bool not needed
On Mon, Feb 22, 2021 at 3:13 PM Souptick Joarder wrote:
>
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> >> warning: variable 'i' is uninitialized when used here
> >> [-Wuninitialized]
>timing = >detailed_timings[i];
>
On Tuesday, February 23rd, 2021 at 6:42 PM, Alex Deucher
wrote:
> yeah, fdo ran out of disk space so I moved to gitlab:
>
> https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next
Ah, thanks for the info, my bad!
___
dri-devel mailing list
yeah, fdo ran out of disk space so I moved to gitlab:
https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next
Alex
On Mon, Feb 22, 2021 at 7:26 PM Bas Nieuwenhuizen
wrote:
>
> I think Alex moved to gitlab for his branches
>
> On Tue, Feb 23, 2021, 12:50 AM Simon Ser wrote:
>>
>> On
On Wed, Feb 10, 2021 at 8:14 AM Daniel Vetter wrote:
>
> On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote:
> > Reviewed-by: Christian König for the series.
>
> Smash it into -misc?
@Christian Koenig did these ever land? I don't see them in drm-misc.
Alex
> -Daniel
>
> >
> > Am
On Tue, Feb 23, 2021 at 11:00:54AM -0500, Alan Stern wrote:
> On Tue, Feb 23, 2021 at 03:06:07PM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 23.02.21 um 14:44 schrieb Takashi Iwai:
>
> > > Aside from the discussion whether this "workaround" is needed, the use
> > > of udev->bus->controller
> If YTR can't be turned off, then according to the AFBC spec - correct.
There is no public AFBC spec, so I'm not sure how to respond to this.
> If the hardware allows it to be configured to use YTR with other
> component orders, I don't know exactly what the impact would be -
> maybe nothing.
On Tue, Feb 23, 2021 at 03:29:13PM +, Daniel Stone wrote:
> On Tue, 23 Feb 2021 at 14:58, Brian Starkey wrote:
> > On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote:
> > > Mark, or others from Rockchip, can you please:
> > > - explain if there is a way to enable/disable the YTR
On Tue, Feb 23, 2021 at 4:59 PM Neil Roberts wrote:
>
> Daniel Vetter writes:
>
> > drm_gem_shmem_fault() does not seem to check for purged objects at all.
> >
> > No idea how this works, or if it ever worked, but yeah something is
> > clearly still busted.
>
> Oh of course, the fault handler
Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > I'd recommend using xf86-video-nouveau in any case, but some distros
>
> I would like try this out. Do you know how to force the xorg server to
> choose this driver instead of modesetting?
Found
On Tue, 23 Feb 2021 17:00:54 +0100,
Alan Stern wrote:
>
> On Tue, Feb 23, 2021 at 03:06:07PM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 23.02.21 um 14:44 schrieb Takashi Iwai:
>
> > > Aside from the discussion whether this "workaround" is needed, the use
> > > of udev->bus->controller
This was already fixed by a patch from Yang Li .
Alex
On Tue, Feb 23, 2021 at 1:13 AM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8260:16-21: WARNING:
> conversion to bool not needed here.
>
> Reported-by: Abaci Robot
Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
> > > wrote:
> > > >
> > > > This change broke X cursor in my setup, and reverting the
On Tue, Feb 23, 2021 at 03:06:07PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 23.02.21 um 14:44 schrieb Takashi Iwai:
> > Aside from the discussion whether this "workaround" is needed, the use
> > of udev->bus->controller here looks a bit suspicious. As the old USB
> > code (before the commit
Daniel Vetter writes:
> drm_gem_shmem_fault() does not seem to check for purged objects at all.
>
> No idea how this works, or if it ever worked, but yeah something is
> clearly still busted.
Oh of course, the fault handler doesn’t check this. I’ve added a second
patch to make it check and
When mmapping the shmem, it would previously adjust the pgoff in the
vm_area_struct to remove the fake offset that is added to be able to
identify the buffer. This patch removes the adjustment and makes the
fault handler use the vm_fault address to calculate the page offset
instead. Although using
When a buffer is madvised as not needed and then purged, any attempts to
access the buffer from user-space should cause a bus fault. This patch
adds a check for that.
Cc: sta...@vger.kernel.org
Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
Signed-off-by: Neil Roberts
---
These two patches fix a problem with the madvise purging code for the
shmem helpers where the mmaping for a purged buffer wouldn't get
invalidated correctly. This presumably ends up as a security hole
where the mapping can be accessed from user-space to read and write
random pages from other
On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen
wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
> > wrote:
> > > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > >
Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
> wrote:
> > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > index
On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
> On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -29,6 +29,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> >
On Tue, 23 Feb 2021 at 14:58, Brian Starkey wrote:
> On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote:
> > Mark, or others from Rockchip, can you please:
> > - explain if there is a way to enable/disable the YTR transform in the
> > VOP's AFBC decoder, similar to the split-block
Hey Hsin-Yi,
This patch looks good to me, feel free to add my r-b.
Reviewed-by: Robert Foss
On Fri, 15 Jan 2021 at 08:05, Hsin-Yi Wang wrote:
>
> When suspending the driver, anx7625_power_standby() will be called to
> turn off reset-gpios and enable-gpios. However, power supplies are not
>
On 2021-02-22 21:38, Rob Clark wrote:
On Thu, Feb 18, 2021 at 4:36 AM Kalyan Thota
wrote:
Set the flag vblank_disable_immediate = true to turn off vblank irqs
immediately as soon as drm_vblank_put is requested so that there are
no irqs triggered during idle state. This will reduce cpu wakeups
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master next-20210223]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next v5.11]
[If your patch
Hey Hsin-Yi,
Thanks for the patch, and sorry about the delays in reviewing this.
This patch does not apply to the drm-misc/for-linux-next branch due to
some other changes having been merged.
On Sat, 20 Feb 2021 at 07:10, Hsin-Yi Wang wrote:
>
> anx7625 requires 3 power supply regulators.
>
>
Hi,
On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote:
> Mark, or others from Rockchip, can you please:
> - explain if there is a way to enable/disable the YTR transform in the
> VOP's AFBC decoder, similar to the split-block control bit?
> - ack this patch which correctly declares
On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
wrote:
>
> Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index c6367035970e..5f4f09a601d4 100644
> > ---
On Fri, Feb 19, 2021 at 04:53:15PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() in
> drm_dp_link_train_clock_recovery_delay().
>
> Signed-off-by: Lyude Paul
I wonder if we could have a drm_dp so we encapsulate both aux and dpcd
related information...
But this one already
Hi,
On Tue, 23 Feb 2021 at 14:27, Daniel Stone wrote:
> Bumping this one: it seems like the Rockchip VOP either always applies
> the YTR transform, or has a YTR control bit which is not documented in
> the driver's register definitions. This means that it is incorrect to
> advertise the
Hi Thomas,
On Mon, Feb 22, 2021 at 10:12:49AM +0100, Thomas Zimmermann wrote:
> Am 19.02.21 um 13:00 schrieb Maxime Ripard:
> > Many drivers reference the plane->state pointer in order to get the
> > current plane state in their atomic_check hook, which would be the old
> > plane state in the
Hi,
On Wed, 12 Aug 2020 at 08:05, Alyssa Rosenzweig
wrote:
> The AFBC decoder used in the Rockchip VOP assumes the use of the
> YUV-like colourspace transform (YTR). YTR is lossless for RGB(A)
> buffers, which covers the RGBA8 and RGB565 formats supported in
> vop_convert_afbc_format. Use of YTR
Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index c6367035970e..5f4f09a601d4 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2663,6
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master next-20210223]
[cannot apply to drm/drm-next v5.11]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Hi
Am 23.02.21 um 14:44 schrieb Takashi Iwai:
On Tue, 23 Feb 2021 11:58:42 +0100,
Thomas Zimmermann wrote:
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Importing dmabuf into a USB-based driver fails, which
break joining and mirroring of display in
On Tue, 23 Feb 2021 11:58:42 +0100,
Thomas Zimmermann wrote:
>
> USB devices cannot perform DMA and hence have no dma_mask set in their
> device structure. Importing dmabuf into a USB-based driver fails, which
> break joining and mirroring of display in X11.
>
> For USB devices, pick the
Hi
Am 23.02.21 um 13:52 schrieb Greg KH:
On Tue, Feb 23, 2021 at 01:49:50PM +0100, Daniel Vetter wrote:
On Tue, Feb 23, 2021 at 1:44 PM Greg KH wrote:
On Tue, Feb 23, 2021 at 01:37:09PM +0100, Thomas Zimmermann wrote:
Hi
Am 23.02.21 um 12:19 schrieb Greg KH:
On Tue, Feb 23, 2021 at
On Tue, Feb 23, 2021 at 05:32:32AM +, Lin, Wayne wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Tuesday, February 23, 2021 1:09 AM
> > To: Lin, Wayne
> > Cc: Brol, Eryk ; Zhuo, Qingqing ;
> > sta...@vger.kernel.org; Zuo, Jerry
> > ;
On Tue, Feb 23, 2021 at 05:32:36AM +, Lin, Wayne wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Tuesday, February 23, 2021 1:00 AM
> > To: Lin, Wayne
> > Cc: dri-devel@lists.freedesktop.org; Brol, Eryk ; Zhuo,
> > Qingqing ;
> >
On Tue, Feb 23, 2021 at 01:51:09PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 23.02.21 um 13:24 schrieb Greg KH:
> > On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 23, 2021 at 1:02 PM Greg KH
> > > wrote:
> > > >
> > > > On Tue, Feb 23, 2021 at 12:46:20PM
On Tue, Feb 23, 2021 at 1:50 PM Greg KH wrote:
>
> On Tue, Feb 23, 2021 at 01:40:51PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 23, 2021 at 1:24 PM Greg KH wrote:
> > >
> > > On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 23, 2021 at 1:02 PM Greg KH
> > >
On Tue, Feb 23, 2021 at 1:42 PM Neil Roberts wrote:
>
> Daniel Vetter writes:
>
> > Yeah plus Cc: stable for backporting and I think an igt or similar for
> > panfrost to check this works correctly would be pretty good too. Since
> > if it took us over 1 year to notice this bug it's pretty clear
On Tue, Feb 23, 2021 at 01:49:50PM +0100, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 1:44 PM Greg KH wrote:
> >
> > On Tue, Feb 23, 2021 at 01:37:09PM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 23.02.21 um 12:19 schrieb Greg KH:
> > > > On Tue, Feb 23, 2021 at 11:58:42AM +0100,
Hi
Am 23.02.21 um 13:24 schrieb Greg KH:
On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote:
On Tue, Feb 23, 2021 at 1:02 PM Greg KH wrote:
On Tue, Feb 23, 2021 at 12:46:20PM +0100, Daniel Vetter wrote:
On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
On Tue, Feb 23,
On Tue, Feb 23, 2021 at 01:40:51PM +0100, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 1:24 PM Greg KH wrote:
> >
> > On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 23, 2021 at 1:02 PM Greg KH
> > > wrote:
> > > >
> > > > On Tue, Feb 23, 2021 at 12:46:20PM
On Tue, Feb 23, 2021 at 1:44 PM Greg KH wrote:
>
> On Tue, Feb 23, 2021 at 01:37:09PM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 23.02.21 um 12:19 schrieb Greg KH:
> > > On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > > > USB devices cannot perform DMA and hence have
On Tue, Feb 23, 2021 at 1:37 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 23.02.21 um 12:19 schrieb Greg KH:
> > On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> >> USB devices cannot perform DMA and hence have no dma_mask set in their
> >> device structure. Importing dmabuf into
On Tue, Feb 23, 2021 at 01:37:09PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 23.02.21 um 12:19 schrieb Greg KH:
> > On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > > USB devices cannot perform DMA and hence have no dma_mask set in their
> > > device structure. Importing
Daniel Vetter writes:
> Yeah plus Cc: stable for backporting and I think an igt or similar for
> panfrost to check this works correctly would be pretty good too. Since
> if it took us over 1 year to notice this bug it's pretty clear that
> normal testing doesn't catch this. So very likely we'll
On Tue, Feb 23, 2021 at 1:24 PM Greg KH wrote:
>
> On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 23, 2021 at 1:02 PM Greg KH wrote:
> > >
> > > On Tue, Feb 23, 2021 at 12:46:20PM +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg
Hi
Am 23.02.21 um 12:19 schrieb Greg KH:
On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Importing dmabuf into a USB-based driver fails, which
break joining and mirroring of display in
On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 1:02 PM Greg KH wrote:
> >
> > On Tue, Feb 23, 2021 at 12:46:20PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
> > > > On Tue, Feb 23, 2021 at 11:58:42AM +0100,
On 02/23, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 11:21 AM Melissa Wen wrote:
> >
> > On 02/22, Daniel Vetter wrote:
> > > On Sat, Feb 20, 2021 at 11:42:12AM -0300, Melissa Wen wrote:
> > > > Add support to overlay plane, in addition to primary and cursor
> > > > planes. In this approach,
On Tue, Feb 23, 2021 at 1:02 PM Greg KH wrote:
>
> On Tue, Feb 23, 2021 at 12:46:20PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
> > > On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > > > USB devices cannot perform DMA and hence
On Thu, Feb 18, 2021 at 5:02 PM Andrzej Hajda wrote:
>
> Hi Michael,
>
> W dniu 18.02.2021 o 09:04, Michael Tretter pisze:
> > On Wed, 10 Feb 2021 10:10:37 +0100, Frieder Schrempf wrote:
> >> On 04.02.21 18:46, Daniel Vetter wrote:
> >>> On Thu, Feb 4, 2021 at 6:26 PM Laurent Pinchart
> >>>
On Tue, Feb 23, 2021 at 12:46:20PM +0100, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
> > On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > > USB devices cannot perform DMA and hence have no dma_mask set in their
> > > device structure.
On Tue, 23 Feb 2021 at 11:51, Adrien Grassein wrote:
>
> Hey Robert,
>
> Le ven. 19 févr. 2021 à 22:47, Adrien Grassein
> a écrit :
> >
> > Le ven. 19 févr. 2021 à 22:28, Robert Foss a écrit
> > :
> > >
> > > On Fri, 19 Feb 2021 at 16:01, Adrien Grassein
> > > wrote:
> > > >
> > > > Hey
On Thu, Jan 21, 2021 at 04:29:48PM +0100, Daniel Vetter wrote:
> Hi all,
>
> Finally gotten around to refreshing all the various fence anntotions I've
> hast last summer. Or well parts of it:
>
> - entire amdgpu and drm/scheduler annotations postponed for now, because
> there's way too many
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking
On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
> On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > USB devices cannot perform DMA and hence have no dma_mask set in their
> > device structure. Importing dmabuf into a USB-based driver fails, which
> > break joining and
On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
> On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> > USB devices cannot perform DMA and hence have no dma_mask set in their
> > device structure. Importing dmabuf into a USB-based driver fails, which
> > break joining and
On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:
> USB devices cannot perform DMA and hence have no dma_mask set in their
> device structure. Importing dmabuf into a USB-based driver fails, which
> break joining and mirroring of display in X11.
>
> For USB devices, pick the
Hi
Am 23.02.21 um 11:59 schrieb Daniel Vetter:
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Importing dmabuf into a USB-based driver fails, which
break joining and mirroring of display in X11.
For USB devices, pick the associated USB controller as attachment device,
so that it can perform DMA. If
Hey Robert,
Le ven. 19 févr. 2021 à 22:47, Adrien Grassein
a écrit :
>
> Le ven. 19 févr. 2021 à 22:28, Robert Foss a écrit :
> >
> > On Fri, 19 Feb 2021 at 16:01, Adrien Grassein
> > wrote:
> > >
> > > Hey Robert,
> > >
> > > Le ven. 19 févr. 2021 à 14:27, Robert Foss a
> > > écrit :
> > >
On Tue, Feb 23, 2021 at 11:21 AM Melissa Wen wrote:
>
> On 02/22, Daniel Vetter wrote:
> > On Sat, Feb 20, 2021 at 11:42:12AM -0300, Melissa Wen wrote:
> > > Add support to overlay plane, in addition to primary and cursor
> > > planes. In this approach, the plane composition still requires an
> >
On 02/22, Daniel Vetter wrote:
> On Sat, Feb 20, 2021 at 11:42:12AM -0300, Melissa Wen wrote:
> > Add support to overlay plane, in addition to primary and cursor
> > planes. In this approach, the plane composition still requires an
> > active primary plane and planes are composed associatively in
On Mon, Feb 22, 2021 at 06:30:35PM +0100, Noralf Trønnes wrote:
>
>
> Den 22.02.2021 08.54, skrev Thomas Zimmermann:
> > Hi
> >
> > Am 20.02.21 um 14:02 schrieb Noralf Trønnes:
> >>
> >>
> >> Den 19.02.2021 14.40, skrev Thomas Zimmermann:
> >>> Fixes a regression for udl and probably other
On Tue, Feb 23, 2021 at 10:42 AM Melissa Wen wrote:
>
> On 02/22, Daniel Vetter wrote:
> > On Sat, Feb 20, 2021 at 11:38:50AM -0300, Melissa Wen wrote:
> > > Initialize CRTC only with primary plane (without cursor) as a preparation
> > > to init overlay plane before cursor plane and keep cursor
On 02/22, Daniel Vetter wrote:
> On Sat, Feb 20, 2021 at 11:38:50AM -0300, Melissa Wen wrote:
> > Initialize CRTC only with primary plane (without cursor) as a preparation
> > to init overlay plane before cursor plane and keep cursor on the top.
> >
> > Signed-off-by: Melissa Wen
>
> Why can't
Le lun. 22 févr. 2021 à 17:36, Shuah Khan a
écrit :
>
> Cool. A quick check shows me 1031 strscpy() calls with no return
> checks. All or some of these probably need to be reviewed and add
> return checks. Is this something that is in the plan to address as
> part of this work?
>
> thanks,
> --
1 - 100 of 103 matches
Mail list logo
