Hi
Am 26.02.21 um 21:33 schrieb Pavel Machek:
Hi!
+ struct device *dmadev;
+ struct drm_gem_object *obj;
+
+ if (!dev_is_usb(dev->dev))
+ return ERR_PTR(-ENODEV);
+
+ dmadev = usb_intf_get_dma_device(to_usb_interface(dev->dev));
+ if (drm_WARN_ONCE(
DMA_TO_DEVICE synchronisation must be done after the last modification
of the memory region by the software and before it is handed off to
the device.
Signed-off-by: Hui Tang
---
drivers/video/fbdev/grvga.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fb
On 2/27/21 1:19 PM, Dmitry Osipenko wrote:
03.02.2021 14:18, Mikko Perttunen пишет:
...
I'll need more time to think about it.
How about something like this:
Turn the syncpt_incr field back into an array of structs like
#define DRM_TEGRA_SUBMIT_SYNCPT_INCR_REPLACE_SYNCOBJ (1<<0)
#def
Fix the following sparse warning:
drivers/gpu/drm/drm_file.c:789:6: warning: symbol
'drm_send_event_helper' was not declared. Should it be static?
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/drm_file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
Hi
Am 28.02.21 um 05:46 schrieb Tong Zhang:
drm_fbdev_cleanup() can be called when fb_helper->buffer is null, hence
fb_helper->buffer should be checked before calling
drm_client_buffer_vunmap(). This buffer is also checked in
drm_client_framebuffer_delete(), so we should also do the same thing f
On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
wrote:
> On 2/26/21 2:28 PM, Daniel Vetter wrote:
> > So I think it stops gup. But I haven't verified at all. Would be good
> > if Christian can check this with some direct io to a buffer in system
> > memory.
>
> Hmm,
>
> Docs (again vm_nor
On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
> From: Philip Yang
>
> Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
> allocate vram backing pages for page migration.
>
> Signed-off-by: Philip Yang
> Signed-off-by: Felix Kuehling
So maybe I'm getting this all
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
wrote:
On 2/26/21 2:28 PM, Daniel Vetter wrote:
So I think it stops gup. But I haven't verified at all. Would be good
if Christian can check this with some direct io to a buffer in system
memo
On Mon, Mar 01, 2021 at 09:33:18AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> i915 has some reason to want to avoid the track_pfn_remap overhead in
> remap_pfn_range. Add a function to the core VM to do just that rather
> than reinventing the functionality poorly in the driver.
It's not _notr
On 2021-02-26 22:56, Daniel Thompson wrote:
On Fri, Feb 26, 2021 at 05:42:24PM +0530, Kiran Gunda wrote:
As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are transitioned from 1 to 0.
This still seems to incorrectly describe the current beha
On 3/1/21 9:32 AM, Daniel Vetter wrote:
On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
From: Philip Yang
Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
allocate vram backing pages for page migration.
Signed-off-by: Philip Yang
Signed-off-by: Felix Kuehling
Hi Robert,
Thanks for your review comments.
I will fix this in next version of patch set.
Regards,
Parshuram Thombare
>-Original Message-
>From: Robert Foss
>Sent: Friday, February 26, 2021 10:06 PM
>To: Parshuram Raju Thombare
>Cc: Rob Herring ; Laurent Pinchart
>; David Airlie ; Dani
On Mon, Mar 01, 2021 at 09:46:44AM +0100, Thomas Hellström (Intel) wrote:
> On 3/1/21 9:32 AM, Daniel Vetter wrote:
> > On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
> > > From: Philip Yang
> > >
> > > Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
> > > allocat
On Thu, Feb 11, 2021 at 4:34 AM Nicolas Boichat wrote:
> Many of the DSI flags have names opposite to their actual effects,
> e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
> be disabled. Fix this by including _NO_ in the flag names, e.g.
> MIPI_DSI_MODE_NO_EOT_PACKET.
Unless
On Sun, Feb 28, 2021 at 05:36:58PM +0100, Pavel Turinský wrote:
> The original bugzilla seems to be read-only now, linking to the gitlab
> for new bugs.
>
> Signed-off-by: Pavel Turinský
> Cc: triv...@kernel.org
Queued up for 5.12, thanks for your patch.
-Daniel
> ---
> MAINTAINERS | 2 +-
> 1
On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel) wrote:
> Hi,
>
> On 3/1/21 9:28 AM, Daniel Vetter wrote:
> > On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
> > wrote:
> > > On 2/26/21 2:28 PM, Daniel Vetter wrote:
> > > > So I think it stops gup. But I haven't verifie
Hi Robert,
On Fri, 2021-02-26 at 14:07 +0100, Robert Foss wrote:
> Hey Liu,
>
> With the below nit straightened out, feel free to add my r-b.
>
> Reviewed-by: Robert Foss
Thanks for reviewing this patch.
>
> On Thu, 18 Feb 2021 at 04:58, Liu Ying wrote:
> > This patch adds a drm bridge driv
On Mon, Mar 01, 2021 at 09:45:59AM +0100, Christoph Hellwig wrote:
> On Mon, Mar 01, 2021 at 09:44:13AM +0100, Daniel Vetter wrote:
> > On Mon, Mar 01, 2021 at 09:33:18AM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > >
> > > i915 has some reason to want to avoid the track_pfn_remap overhead in
On Mon, Mar 01, 2021 at 04:19:50PM +0800, Jiapeng Chong wrote:
> Fix the following sparse warning:
>
> drivers/gpu/drm/drm_file.c:789:6: warning: symbol
> 'drm_send_event_helper' was not declared. Should it be static?
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/
On 3/1/21 10:05 AM, Daniel Vetter wrote:
On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
wrote:
On 2/26/21 2:28 PM, Daniel Vetter wrote:
So I think it stops gup. B
This patch series has the following two WLED fixes
1. As per the current implementation, for WLED5, after
the FSC (Full Scale Current) update the driver is incorrectly
toggling the MOD_SYNC register instead of toggling the SYNC register.
The patch 1/2 fixes this by toggling the SYNC re
As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are transitioned from set-then-clear.
But, the FSC and brightness sync takes place during a clear-then-set
transition of the sync bits. So the hardware team recommends a
clear-then-set approach in
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adoptin
On 3/1/21 9:58 AM, Daniel Vetter wrote:
On Mon, Mar 01, 2021 at 09:46:44AM +0100, Thomas Hellström (Intel) wrote:
On 3/1/21 9:32 AM, Daniel Vetter wrote:
On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
From: Philip Yang
Register vram memory as MEMORY_DEVICE_PRIVATE type reso
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Therefore importing dmabuf into a USB-based driver
fails, which breaks joining and mirroring of display in X11.
For USB devices, pick the associated USB controller as attachment device.
This allows the DRM imp
On Mon, Mar 01, 2021 at 02:15:12PM +0530, kgu...@codeaurora.org wrote:
> On 2021-02-26 22:56, Daniel Thompson wrote:
> > On Fri, Feb 26, 2021 at 05:42:24PM +0530, Kiran Gunda wrote:
> > > As per the current implementation, after FSC (Full Scale Current)
> > > and brightness update the sync bits are
Nothing checks userptr.ro except this call to pup_fast, which means
there's nothing actually preventing userspace from writing to this.
Which means you can just read-only mmap any file you want, userptr it
and then write to it with the gpu. Not good.
The right way to handle this is FOLL_WRITE | FO
There's no mmu notifier or anything like that, releasing this pin is
entirely up to userspace. Hence FOLL_LONGTERM.
No cc: stable for this patch since a lot of the infrastructure around
FOLL_LONGETRM (like not allowing it for pages currently sitting in
ZONE_MOVEABLE before they're migrated) is sti
(cc'ing amd devs)
Hi
Am 28.02.21 um 17:10 schrieb Pavel Turinský:
The checks were removed in commit d693def4fd1c ("drm: Remove obsolete GEM
and PRIME callbacks from struct drm_driver") and can lead to following
kernel oops:
Thanks for reporting. All drivers are supposed to set the funcs point
On Mon, Mar 01, 2021 at 02:58:36PM +0530, Kiran Gunda wrote:
> As per the current implementation, after FSC (Full Scale Current)
> and brightness update the sync bits are transitioned from set-then-clear.
This does not makes sense since there are too many verbs. Set and clear
are both verbs so in
On Mon, Mar 1, 2021 at 10:56 AM Thomas Zimmermann wrote:
>
> (cc'ing amd devs)
>
> Hi
>
> Am 28.02.21 um 17:10 schrieb Pavel Turinský:
> > The checks were removed in commit d693def4fd1c ("drm: Remove obsolete GEM
> > and PRIME callbacks from struct drm_driver") and can lead to following
> > kernel
On 2/24/21 6:17 PM, Daniel Vetter wrote:
> On Wed, Feb 24, 2021 at 8:55 AM Oleksandr Andrushchenko
> wrote:
>> Hello, Jan!
>>
>> On 2/23/21 6:41 PM, Jan Beulich wrote:
>>> By having selected DRM_XEN, I was assuming I would build the frontend
>>> driver. As it turns out this is a dummy option, an
Am 01.03.21 um 10:21 schrieb Thomas Hellström (Intel):
On 3/1/21 10:05 AM, Daniel Vetter wrote:
On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel)
wrote:
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
wrote:
On 2/26/21
Am 01.03.21 um 11:04 schrieb Daniel Vetter:
On Mon, Mar 1, 2021 at 10:56 AM Thomas Zimmermann wrote:
(cc'ing amd devs)
Hi
Am 28.02.21 um 17:10 schrieb Pavel Turinský:
The checks were removed in commit d693def4fd1c ("drm: Remove obsolete GEM
and PRIME callbacks from struct drm_driver") and
On 3/1/21 01:52, Daniel Vetter wrote:
There's no mmu notifier or anything like that, releasing this pin is
entirely up to userspace. Hence FOLL_LONGTERM.
No cc: stable for this patch since a lot of the infrastructure around
FOLL_LONGETRM (like not allowing it for pages currently sitting in
^
Am Montag, dem 01.03.2021 um 10:52 +0100 schrieb Daniel Vetter:
> Nothing checks userptr.ro except this call to pup_fast, which means
> there's nothing actually preventing userspace from writing to this.
> Which means you can just read-only mmap any file you want, userptr it
> and then write to it
On Thu, Jan 14, 2021 at 11:00 AM Geert Uytterhoeven
wrote:
> On Wed, Jan 13, 2021 at 6:02 PM Kieran Bingham
> wrote:
> > The encoder allocation was converted to a DRM managed resource at the
> > same time as the addition of a new helper drmm_encoder_alloc() which
> > simplifies the same process.
This is a note to let you know that I've just added the patch titled
drm/nouveau/kms: handle mDP connectors
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-kms-
https://bugzilla.kernel.org/show_bug.cgi?id=211997
Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) changed:
What|Removed |Added
CC||
This is a note to let you know that I've just added the patch titled
drm/nouveau/kms: handle mDP connectors
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-kms
On Mon, 1 Mar 2021 at 10:07, Liu Ying wrote:
>
> Hi Robert,
>
> On Fri, 2021-02-26 at 14:07 +0100, Robert Foss wrote:
> > Hey Liu,
> >
> > With the below nit straightened out, feel free to add my r-b.
> >
> > Reviewed-by: Robert Foss
>
> Thanks for reviewing this patch.
>
> >
> > On Thu, 18 Feb 2
On 19/02/2021 13:02, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Thu, Feb 11, 2021 at 11:36:59AM +0100, Hans Verkuil wrote:
>> Add bridge cec_init/exit ops. These ops will be responsible for
>> creating and destroying the CEC adapter for the bridge that supports
>> CEC.
This is a note to let you know that I've just added the patch titled
drm/nouveau/kms: handle mDP connectors
to the 5.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-kms
On 19/02/2021 13:07, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Thu, Feb 11, 2021 at 11:37:00AM +0100, Hans Verkuil wrote:
>> Implement the new CEC bridge ops. This makes it possible to associate
>> a CEC adapter with a drm connector, which helps userspace determine
>>
This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver.
Changes since v1:
- Move sapb reg block right after apb reg block
- Corresponding changes in binding and example
Parshuram Thombare (2):
dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
drm: bridge: cdns-mhd
Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
This binding is not used in any upstreamed DTS yet, so changing
index of property 'j721e-intg' should not affect anything.
Signed-off-by: Parshuram Thombare
---
.../display/bridge/cdns,mhdp8546.yaml | 29
This patch enable HDCP in MHDP driver.
Signed-off-by: Parshuram Thombare
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/cadence/Makefile | 2 +-
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 105 +++-
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 21 +
.../drm/bridge/cadence/c
Laurent,
On 01/03/2021 10:30, Geert Uytterhoeven wrote:
> On Thu, Jan 14, 2021 at 11:00 AM Geert Uytterhoeven
> wrote:
>> On Wed, Jan 13, 2021 at 6:02 PM Kieran Bingham
>> wrote:
>>> The encoder allocation was converted to a DRM managed resource at the
>>> same time as the addition of a new he
On 19/02/2021 12:09, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 11/02/2021 12:37, Hans Verkuil wrote:
>> Add HDMI CEC support for OMAP5.
>>
>> Many thanks to Tomi for helping out how to enable CEC for omap5.
>>
>> Signed-off-by: Hans Verkuil
>> Thanks-to: Tomi Valkeinen
>> ---
>> drivers/gpu/drm/o
On Mon, Mar 1, 2021 at 11:28 AM Lucas Stach wrote:
>
> Am Montag, dem 01.03.2021 um 10:52 +0100 schrieb Daniel Vetter:
> > Nothing checks userptr.ro except this call to pup_fast, which means
> > there's nothing actually preventing userspace from writing to this.
> > Which means you can just read-o
On Mon, Mar 1, 2021 at 11:17 AM Christian König
wrote:
>
>
>
> Am 01.03.21 um 10:21 schrieb Thomas Hellström (Intel):
> >
> > On 3/1/21 10:05 AM, Daniel Vetter wrote:
> >> On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel)
> >> wrote:
> >>> Hi,
> >>>
> >>> On 3/1/21 9:28 AM, Daniel
Am 27.02.21 um 04:45 schrieb Felix Kuehling:
Move fences that have already signaled should not prevent memory
allocations with no_wait_gpu.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Hi Parshuram,
Thank you for the patch.
On Mon, Mar 01, 2021 at 12:22:26PM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
> This binding is not used in any upstreamed DTS yet, so changing
> index of property 'j721e-intg' should not affect any
After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.
The backlight still turns back on after reboot, but the LCD shows an
all black display. The
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adoptin
This patch series has the following two WLED fixes
1. As per the current implementation, for WLED5, after
the FSC (Full Scale Current) update the driver is incorrectly
toggling the MOD_SYNC register instead of toggling the SYNC register.
The patch 1/2 fixes this by toggling the SYNC re
On Fri, Feb 26, 2021 at 06:18:27PM +1100, Alistair Popple wrote:
> The behaviour of try_to_unmap_one() is difficult to follow because it
> performs different operations based on a fairly large set of flags used
> in different combinations.
>
> TTU_MUNLOCK is one such flag. However it is exclusivel
As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are set-then-cleared.
But, the FSC and brightness sync takes place when the sync bits are
set (e.g. on a rising edge). So the hardware team recommends a
clear-then-set approach in order to guarante
Hi Laurent,
>Is this a property of the hardware, that is, are there multiple versions
>of this IP core covered by the same compatible string that support HDCP
>1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given
>system will offer ?[]
MHDP hardware supports both HDCP 2.2 and
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
Unfortunately my previous email seems to not have been received by many
people. I will send this email separately to each mailing list to
hopefully get better coverage.
The nomination period is currently ongoing. So far we have received 3
nominations and will need at least 4 to fill the vacant
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
Hi Hans,
(CC'ing the DRM bridge maintainers and Daniel Vetter)
On Mon, Mar 01, 2021 at 11:56:28AM +0100, Hans Verkuil wrote:
> On 19/02/2021 13:02, Laurent Pinchart wrote:
> > On Thu, Feb 11, 2021 at 11:36:59AM +0100, Hans Verkuil wrote:
> >> Add bridge cec_init/exit ops. These ops will be respon
Hi Hans,
On Mon, Mar 01, 2021 at 12:07:56PM +0100, Hans Verkuil wrote:
> On 19/02/2021 13:07, Laurent Pinchart wrote:
> > On Thu, Feb 11, 2021 at 11:37:00AM +0100, Hans Verkuil wrote:
> >> Implement the new CEC bridge ops. This makes it possible to associate
> >> a CEC adapter with a drm connector
Hi Parshuram,
On Mon, Mar 01, 2021 at 04:14:54PM +, Parshuram Raju Thombare wrote:
> Hi Laurent,
>
> > Is this a property of the hardware, that is, are there multiple versions
> > of this IP core covered by the same compatible string that support HDCP
> > 1.4 only, DHCP 2.2 only or both ? Or
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
On 2021-03-01 15:32, Daniel Thompson wrote:
On Mon, Mar 01, 2021 at 02:58:36PM +0530, Kiran Gunda wrote:
As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are transitioned from
set-then-clear.
This does not makes sense since there are too ma
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
On my test box with latest v5.12-rc1, running with all trace events
enabled, I consistently trigger this warning.
It appears to get triggered by the trace_intel_pipe_disable() code.
-- Steve
[ cut here ]
i915 :00:02.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends u
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
From: John Stultz
[ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ]
Copied in from somewhere else, the makefile was including
the kerne's usr/include dir, which caused the asm/ioctl.h file
to be used.
Unfortunately, that file has different values for _IOC_SIZEBITS
and _IOC_WRITE than
On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote:
>
> On my test box with latest v5.12-rc1, running with all trace events
> enabled, I consistently trigger this warning.
>
> It appears to get triggered by the trace_intel_pipe_disable() code.
>
> -- Steve
>
> [ cut her
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends u
+ Andrey
On Mon, Mar 1, 2021 at 5:25 AM Christian König
wrote:
>
>
>
> Am 01.03.21 um 11:04 schrieb Daniel Vetter:
> > On Mon, Mar 1, 2021 at 10:56 AM Thomas Zimmermann
> > wrote:
> >> (cc'ing amd devs)
> >>
> >> Hi
> >>
> >> Am 28.02.21 um 17:10 schrieb Pavel Turinský:
> >>> The checks were re
When creating a new framebuffer, verify that the bo size associated with
it can handle the fb size.
drm_gem_fb_init_with_funcs implements this check by calculating the
minimum expected size of each plane. amdgpu now uses this function to
initialize its fb as it performs the required checks.
The bu
https://bugzilla.kernel.org/show_bug.cgi?id=208115
--- Comment #3 from Adarion from userland (h_mailingli...@posteo.de) ---
A little (and very late, sorry, but I have a v. stressful "real life") update
from my side.
I recently found the time to plug the RX 590 back into the Zen+ setup. (was
runni
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prev
On Fri, Feb 26, 2021 at 06:18:25PM +1100, Alistair Popple wrote:
> Remove the migration and device private entry_to_page() and
> entry_to_pfn() inline functions and instead open code them directly.
> This results in shorter code which is easier to understand.
>
> Signed-off-by: Alistair Popple
>
On Fri, Feb 26, 2021 at 06:18:26PM +1100, Alistair Popple wrote:
> Both migration and device private pages use special swap entries which
> are manipluated by a range of inline functions. The arguments to these
> are somewhat inconsitent so rework them to remove flag type arguments
> and to make th
From: John Stultz
[ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ]
Copied in from somewhere else, the makefile was including
the kerne's usr/include dir, which caused the asm/ioctl.h file
to be used.
Unfortunately, that file has different values for _IOC_SIZEBITS
and _IOC_WRITE than
On Mon, 1 Mar 2021 19:20:59 +0200
Ville Syrjälä wrote:
> > ilk_crtc_disable+0x85/0x390 [i915]
>
> But this part is confusing me. intel_crtc_get_vblank_counter() is
> only supposed to do drm_crtc_accurate_vblank_count() fallback when
> the hardware lacks a working frame counter, and that sho
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
> Some devices require exclusive write access to shared virtual
> memory (SVM) ranges to perform atomic operations on that memory. This
> requires CPU page tables to be updated to deny access whilst atomic
> operations are occurring.
On Fri, Feb 26, 2021 at 06:18:30PM +1100, Alistair Popple wrote:
> Adds some selftests for exclusive device memory.
>
> Signed-off-by: Alistair Popple
> ---
> lib/test_hmm.c | 124 ++
> lib/test_hmm_uapi.h| 2 +
> tools/testing/selftests/
From: Stephen Boyd
[ Upstream commit 182b4a2d251305201b6f9cae29067f7112f05835 ]
A missing semicolon here causes my external display to stop working.
Indeed, missing the semicolon on the return statement leads to
dp_panel_update_tu_timings() not existing because the compiler thinks
it's part of t
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends u
> From: Jason Gunthorpe
> Sent: Monday, March 1, 2021 9:56 AM
> To: Alistair Popple
> Cc: linux...@kvack.org; nouv...@lists.freedesktop.org;
> bske...@redhat.com; a...@linux-foundation.org; linux-...@vger.kernel.org;
> linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; John Hubbard
>
On Mon, 1 Mar 2021 at 23:11, Naresh Kamboju wrote:
>
> On stable rc 5.11 the x86_64 build failed due to below errors/warnings.
These build failures were also noticed on stable rc 5.10 for arm64,
arm, x86_64, and i386 architectures.
>
> drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_
On stable rc 5.11 the x86_64 build failed due to below errors/warnings.
drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup':
drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit
declaration of function 'to_rcar_du_device'; did you mean
'to_rtc_device'? [-Werror=im
Hi Noralf,
Peter Stuge wrote:
> I'll prepare a test setup for the RGB-TFT on the weekend.
So implementing a GUD and looking at the protocol from yet another
angle gives more new insights - surprise. :)
Here are some thoughts so far:
* GUD_REQ_SET_VERSION does still rub me wrong; it seems potent
On Mon, Mar 01, 2021 at 11:11:26PM +0530, Naresh Kamboju wrote:
> On stable rc 5.11 the x86_64 build failed due to below errors/warnings.
>
> drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup':
> drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit
> declaration
On 01/03/2021 18:52, Greg Kroah-Hartman wrote:
> On Mon, Mar 01, 2021 at 11:11:26PM +0530, Naresh Kamboju wrote:
>> On stable rc 5.11 the x86_64 build failed due to below errors/warnings.
>>
>> drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup':
>> drivers/gpu/drm/rcar-du/
On Thu, Jan 21, 2021 at 1:50 AM Robert Foss wrote:
> +Sam Ravnborg
>
> I think this patch is ready to get pulled into the drm-misc tree.
>
> On Thu, 17 Dec 2020 at 15:09, Robert Foss wrote:
> >
> > 4k requires two dsi pipes, so don't report MODE_OK when only a
> > single pipe is configured. But r
https://bugzilla.kernel.org/show_bug.cgi?id=209713
--- Comment #20 from Oliver Reeh (oli...@diereehs.de) ---
Still no problem here with the 5.11.x kernels.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
___
Den 01.03.2021 19.31, skrev Peter Stuge:
> Hi Noralf,
>
> Peter Stuge wrote:
>> I'll prepare a test setup for the RGB-TFT on the weekend.
>
> So implementing a GUD and looking at the protocol from yet another
> angle gives more new insights - surprise. :)
>
Yep, my Raspberry Pi Pico implemen
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066]
If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.
This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.
Signed-off-by: Oa
> From: Alistair Popple
> Sent: Thursday, February 25, 2021 11:18 PM
> To: linux...@kvack.org; nouv...@lists.freedesktop.org;
> bske...@redhat.com; a...@linux-foundation.org
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; John Hubbard ; Ralph
> Ca
> From: Alistair Popple
> Sent: Thursday, February 25, 2021 11:19 PM
> To: linux...@kvack.org; nouv...@lists.freedesktop.org;
> bske...@redhat.com; a...@linux-foundation.org
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; John Hubbard ; Ralph
> Ca
1 - 100 of 141 matches
Mail list logo
