On Thu, Jul 30, 2020 at 03:46:26AM +0200, Paul Cercueil wrote:
> Instead of keeping the IPU clock enabled constantly, enable and disable
> it on demand, when the IPU plane is used.
This explains what the patch does - but fails to mention why.
Could you please add the why part too.
With the
On Thu, Jul 30, 2020 at 03:46:25AM +0200, Paul Cercueil wrote:
> When configuring the IPU for packed YUV 4:2:2, depending on the scaling
> ratios given by the source and destination resolutions, it is possible
> to crash the IPU block beyond repair, to the point where a software
> reset of the IP
On Thu, Jul 30, 2020 at 03:46:24AM +0200, Paul Cercueil wrote:
> On older SoCs, it is necessary to restart manually the IPU when a frame
> is done processing. Doing so on newer SoCs (JZ4760/70) kinds of work
> too, until the input or output resolutions or the framerate are too
> high.
>
> Make it
https://bugzilla.kernel.org/show_bug.cgi?id=208743
--- Comment #4 from arju...@gmail.com ---
Created attachment 290693
--> https://bugzilla.kernel.org/attachment.cgi?id=290693=edit
cmdline
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208743
--- Comment #3 from arju...@gmail.com ---
Created attachment 290691
--> https://bugzilla.kernel.org/attachment.cgi?id=290691=edit
modules
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208743
--- Comment #2 from arju...@gmail.com ---
Created attachment 290689
--> https://bugzilla.kernel.org/attachment.cgi?id=290689=edit
lscpi
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208743
Bug ID: 208743
Summary: suspend and hibernate periodically fail. suspend
significantly more often than hibernate.
Product: Drivers
Version: 2.5
Kernel Version: 4.19.0-9,5.4.31
https://bugzilla.kernel.org/show_bug.cgi?id=208743
--- Comment #1 from arju...@gmail.com ---
Created attachment 290687
--> https://bugzilla.kernel.org/attachment.cgi?id=290687=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Dave, Daniel,
A few fixes for 5.8. It would be nice to get these in for 5.8 final, but if
it's too late, they can go back via stable from 5.9.
The following changes since commit a4a2739beb8933a19281bca077fdb852598803ed:
Merge tag 'drm-misc-fixes-2020-07-28' of
Use switch - case to downshift from the current link rate. It's a small
loop now, so fine to be replaced with switch - case. With a loop, it is
confusing and hard to follow as reported below.
The patch d76271d22694: "drm: xlnx: DRM/KMS driver for Xilinx ZynqMP
DisplayPort Subsystem" from Jul 7,
Hi Daniel,
Thanks for the review.
On Wed, Jul 29, 2020 at 02:34:16PM -0700, Daniel Vetter wrote:
> On Wed, Jul 29, 2020 at 8:21 PM Hyun Kwon wrote:
> >
> > The loop should exit at the lowest link rate, so break the loop
> > at the lowest link rate without check. The check is always true
> >
Applied. Thanks!
Alex
On Tue, Jul 28, 2020 at 2:56 AM Christian König
wrote:
>
> Am 27.07.20 um 23:30 schrieb Daniel Vetter:
> > Trying to grab dma_resv_lock while in commit_tail before we've done
> > all the code that leads to the eventual signalling of the vblank event
> > (which can be a
Applied. Thanks!
Alex
On Wed, Jul 29, 2020 at 9:11 AM Li Heng wrote:
>
> Remove casting the values returned by memory allocation function.
>
> Coccinelle emits WARNING:
>
> ./drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c:893:37-46:
> WARNING: casting value returned by memory
Applied. Thanks!
Alex
On Wed, Jul 29, 2020 at 4:11 AM Christian König
wrote:
>
> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> > Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> > amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> > when `size` is
On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen wrote:
>
> Melissa Wen
>
> On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote:
> >
> > On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen wrote:
> > >
> > > On 07/25, Daniel Vetter wrote:
> > > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang wrote:
> > > > >
The pull request you sent on Wed, 29 Jul 2020 14:44:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-29
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c2f3850df7f95537e79c561f7be49df2e4ad8060
Thank you!
--
Deet-doot-dot, I am a bot.
Signed-off-by: Lyude Paul
Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events
too early")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.19+
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2
Again, we don't have any need to suspend the device synchronously here,
and doing so could in theory lead to a deadlock (although it's unlikely
since we've called pm_runtime_mark_last_busy() before-hand).
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file
No functional changes here, just a drive-by cleanup.
Signed-off-by: Lyude Paul
[cc'd to stable since the next fix needs this patch to apply]
Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events
too early")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc:
This isn't an error, this just means there's multiple asynchronous
resume requests going at the same time. Treat it like a success.
Signed-off-by: Lyude Paul
Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events
too early")
Cc: sta...@vger.kernel.org
Cc: Karol Herbst
Looks like that we forgot to handle -EINPROGRESS being returned by
pm_runtime_get(), which can happen if multiple callers try to
asynchronously resume the GPU before it wakes up. This is perfectly
normal and OK, so fix this by treating -EINPROGRESS as success.
Signed-off-by: Lyude Paul
Fixes:
We want to update the last busy timer for our device and use
pm_runtime_put_autosuspend() here instead so that our GPU can
autosuspend when we're done.
Signed-off-by: Lyude Paul
Fixes: f231976c2e89 ("drm/nouveau/fbcon: take runpm reference when userspace
has an open fd")
Cc: Ben Skeggs
Cc:
While I don't know of any problems this has caused, it's definitely not
a great idea for us to potentially block in
nouveau_fbcon_set_suspend_work(). We don't really need to anyway, and
want to simply trigger the autosuspend timer instead.
Signed-off-by: Lyude Paul
---
Noticed two problems here:
* We're not dropping our runtime PM refs after getting an error
* We're not backing off when pm_runtime_get() indicates that there's
already a resume in progress (-EINPROGRESS) (after which any delayed
fbcon events will get handled anyway)
So, let's fix those.
Found another one, we forget to drop the runtime PM reference we grab
here in the event of a failure. So, do that.
Signed-off-by: Lyude Paul
Fixes: 3e1a12754d4d ("drm/nouveau: Fix deadlocks in nouveau_connector_detect()")
Cc: sta...@vger.kernel.org
Cc: Ben Skeggs
Cc:
On Wed, Jul 29, 2020 at 8:21 PM Hyun Kwon wrote:
>
> The loop should exit at the lowest link rate, so break the loop
> at the lowest link rate without check. The check is always true
> because lowest link rate is smaller than current one and maximum
> of current display. Otherwise, it may be seen
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #111 from mn...@protonmail.com ---
Yeah, no noticeable performance impact on my end either. I don't really
see why it would cause a performance impact either. I could run a benchmark
to compare but I don't really know what to
https://bugzilla.kernel.org/show_bug.cgi?id=208587
d...@rodler-keller.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Melissa Wen
On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote:
>
> On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen wrote:
> >
> > On 07/25, Daniel Vetter wrote:
> > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang wrote:
> > > >
> > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
On Tue, Jul 28, 2020 at 9:44 PM Dave Airlie wrote:
>
> If you feel this is too much I'm happy to respin with the
> core/drm_fb_helper and nouveau fixes. we have one outstanding nouveau
> regression fix, that I'll follow this up with in the next day or so
> once Ben and James get it reviewed.
Hi Wei,
Thanks for the patch.
On Tue, Jul 28, 2020 at 03:33:49PM -0700, Laurent Pinchart wrote:
> Hi Wei,
>
> Thank you for the patch.
>
> On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> > Fix typo in parameter description.
> >
> > Fixes: d76271d22694 ("drm: xlnx: DRM/KMS
Hi Colin,
Thanks for the patch.
On Tue, Jul 28, 2020 at 03:37:39PM -0700, Laurent Pinchart wrote:
> Hi Colin,
>
> Thank you for the patch.
>
> On Fri, Jul 24, 2020 at 12:12:58PM +0100, Colin King wrote:
> > From: Colin Ian King
> >
> > There is a spelling mistake in a dev_dbg messages. Fix
Hi Dan,
Thanks for sharing.
On Mon, Jul 27, 2020 at 04:18:25AM -0700, dan.carpen...@oracle.com wrote:
> Hello Hyun Kwon,
>
> The patch d76271d22694: "drm: xlnx: DRM/KMS driver for Xilinx ZynqMP
> DisplayPort Subsystem" from Jul 7, 2018, leads to the following
> static checker warning:
>
>
The loop should exit at the lowest link rate, so break the loop
at the lowest link rate without check. The check is always true
because lowest link rate is smaller than current one and maximum
of current display. Otherwise, it may be seen as the loop can
potentially result in negative array
Hi Paul,
Thank you for the patch.
On Mon, Jul 27, 2020 at 06:46:08PM +0200, Paul Cercueil wrote:
> Add documentation for the Device Tree node for LCD panels based on the
> NewVision NV3052C controller.
>
> Signed-off-by: Paul Cercueil
> ---
> .../display/panel/newvision,nv3052c.yaml | 69
Hi Marek.
On Wed, Jul 29, 2020 at 07:02:51PM +0200, Marek Vasut wrote:
> On 7/29/20 6:56 PM, Sam Ravnborg wrote:
> [...]
> >> +static int tc358762_probe(struct mipi_dsi_device *dsi)
> >> +{
> >> + struct device *dev = >dev;
> >> + struct tc358762 *ctx;
> >> + int ret;
> >> +
> >> + ctx =
Hi Marek.
On Wed, Jul 29, 2020 at 06:45:53PM +0200, Marek Vasut wrote:
> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob
Hi Marek.
On Wed, Jul 29, 2020 at 06:45:54PM +0200, Marek Vasut wrote:
> Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived
> from tc358764 driver and panel-raspberrypi-touchscreen. This driver is
> meant to replace the panel-raspberrypi-touchscreen too, as the bridge
>
Hi Sam,
On Wed, Jul 29, 2020 at 06:43:26PM +0200, Sam Ravnborg wrote:
> On Wed, Jul 29, 2020 at 07:29:08PM +0300, Laurent Pinchart wrote:
> > Enabling a whole subsystem from a single driver 'select' is frowned
> > upon and won't be accepted in new drivers, that need to use 'depends on'
> >
On 2020-07-28 5:08 a.m., dan...@ffwll.ch wrote:
On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote:
On 2020-07-27 5:32 p.m., Daniel Vetter wrote:
On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
On Mon, Jul 27,
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #110 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
That's inline with the expectations I think.
That patch shouldn't cause any performance or stuttering impacts and it should
resolve the protection fault.
If there were
Hi Laurent.
On Wed, Jul 29, 2020 at 07:29:08PM +0300, Laurent Pinchart wrote:
> Enabling a whole subsystem from a single driver 'select' is frowned
> upon and won't be accepted in new drivers, that need to use 'depends on'
> instead. Existing selection of DMAENGINES will then cause circular
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #109 from zzyx...@gmail.com ---
I've been testing mnrzk's patch for about 12 hours as well, so far so good. No
obvious performance degradation has appeared, at least that I can discern just
by "feel". My testing has been interrupted a
Hi Daniel.
On Wed, Jul 29, 2020 at 03:53:28PM +0200, dan...@ffwll.ch wrote:
> On Wed, Jul 29, 2020 at 03:41:45PM +0200, Thomas Zimmermann wrote:
> > DRM fb helpers require read and write functions for framebuffer
> > memory. Export the existing code from fbdev.
> >
> > Signed-off-by: Thomas
Enabling a whole subsystem from a single driver 'select' is frowned
upon and won't be accepted in new drivers, that need to use 'depends on'
instead. Existing selection of DMAENGINES will then cause circular
dependencies. Replace them with a dependency.
Signed-off-by: Laurent Pinchart
Acked-by:
Enabling a whole subsystem from a single driver 'select' is frowned
upon and won't be accepted in new drivers, that need to use 'depends on'
instead. Existing selection of DMAENGINES will then cause circular
dependencies. Replace them with a dependency.
Signed-off-by: Laurent Pinchart
Acked-by:
The dpsub driver uses the DMA engine API, and thus selects DMA_ENGINE to
provide that API. DMA_ENGINE depends on DMADEVICES, which can be
deselected by the user, creating a possibly unmet indirect dependency:
WARNING: unmet direct dependencies detected for DMA_ENGINE
Depends on [n]: DMADEVICES
Hello,
This small series fixes a Kconfig dependency issue with the recently
merged Xilixn DPSUB DRM/KMS driver. The fix is in patch 3/3, but
requires a separate fixes in patches 1/3 and 2/3 to avoid circular
dependencies:
drivers/i2c/Kconfig:8:error: recursive dependency detected!
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #108 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Paul Menzel from comment #107)
> Everyone seeing this, it’d be great, if you tested
>
> [PATCH] drm/amd/display: Clear dm_state for fast updates
I've been testing it
Hi Maxime,
Am 29.07.20 um 16:42 schrieb Maxime Ripard:
> Hi,
>
> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote:
>> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>>> In order to avoid pixels getting stuck in the (unflushable) FIFO between
>>> the HVS and the PV, we need to
Hi,
On Sat, Jul 18, 2020 at 07:42:15PM +0200, Ondřej Jirman wrote:
> Hello,
>
> On Sat, Jul 18, 2020 at 07:31:24PM +0200, Guido Günther wrote:
> > Hi,
> > On Thu, Jul 16, 2020 at 04:32:09PM +0200, Ondřej Jirman wrote:
> > > Hi Guido,
> > >
> > > On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido
Sure.
Christian.
Am 29.07.2020 17:30 schrieb "Deucher, Alexander" :
[AMD Public Use]
Christian, Can you cc stable when you apply it to drm-misc?
Alex
From: Kuehling, Felix
Sent: Wednesday, July 29, 2020 10:15 AM
To: Koenig, Christian ;
[AMD Public Use]
Christian, Can you cc stable when you apply it to drm-misc?
Alex
From: Kuehling, Felix
Sent: Wednesday, July 29, 2020 10:15 AM
To: Koenig, Christian ;
dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Deucher,
Alexander
Cc:
This patch modifies function call sequence in commit tail. This is for
the problem that raised when kms_cursor_crc test is tested repeatedly.
In second test, there is an bug that crtc commit doesn't start vblank events.
Because there is some error about vblank's refcount. in commit_flush() that
> -Original Message-
> From: Chris Wilson
> Sent: Tuesday, July 28, 2020 9:28 AM
> To: Daniel Vetter ; Dave Airlie
> Cc: intel-gfx ; stable
> ; Gustavo Padovan
> ; Tang, CQ ; dri-
> devel ; Vetter, Daniel
>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
>
Hi,
On Wed, Jul 29, 2020 at 05:16:47PM +0300, Laurentiu Palcu wrote:
> Hi Guido,
>
> On Wed, Jul 29, 2020 at 03:59:48PM +0200, Guido Günther wrote:
> > Hi,
> > On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote:
> > > From: Laurentiu Palcu
> > >
> > > Hi,
> > >
> > > This patchset
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> The vc4 atomic commit loop has an handrolled loop that is basically
> identical to for_each_new_crtc_state, let's convert it to that helper.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 9 -
>
Hi Dave,
This time around:
* A bunch more a650/a640 (sm8150/sm8250) display and GPU enablement
and fixes
* Enable dpu dither block for 6bpc panels
* dpu suspend fixes
* dpu fix for cursor on 2nd display
* dsi/mdp5 enablement for sdm630/sdm636/sdm660
* gpu opp/bw scaling for a6xx
For the last
On Wed, Jul 29, 2020 at 01:40:13PM +1000, Ben Skeggs wrote:
> On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote:
> >
> > On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
> > >
> > > On 7/23/20 9:06 PM, Ben Skeggs wrote:
> > > > On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
> > > >>
> > > >>
On Wed, 29 Jul 2020 at 15:42, Maxime Ripard wrote:
>
> Hi,
>
> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote:
> > On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
> > >
> > > In order to avoid pixels getting stuck in the (unflushable) FIFO between
> > > the HVS and the PV, we
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Since most of the HVS channel is setup in the init function, let's move the
> gamma setup there too. As this makes the HVS mode_set function empty, let's
> remove it in the process.
>
> Signed-off-by: Maxime Ripard
Reviewed-by:
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output
> being connected to a pixelvalve, and some muxing between the FIFOs and
> outputs.
>
> Any output cannot feed from any FIFO though, and they all have a bunch
On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote:
>
> On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > I started using devm_kcalloc() but at least two reviewers convinced me
> > to just use kcalloc(). In addition, when I was using devm_kcalloc()
> > it was awkward because
On Wed, Jul 29, 2020 at 03:27:30PM +0200, Guido Günther wrote:
> Hi,
> On Fri, Jul 24, 2020 at 12:07:34PM +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu
> >
> > Add bindings for iMX8MQ Display Controller Subsystem.
> >
> > Signed-off-by: Laurentiu Palcu
> > Reviewed-by: Rob Herring
>
Hi Guido,
On Wed, Jul 29, 2020 at 03:59:48PM +0200, Guido Günther wrote:
> Hi,
> On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu
> >
> > Hi,
> >
> > This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> > includes only graphics
Am 2020-07-29 um 4:08 a.m. schrieb Christian König:
> Am 28.07.20 um 20:27 schrieb Felix Kuehling:
>> VMAs with a pg_offs that's offset from the start of the vma_node need
>> to adjust the offset within the BO accordingly. This matches the
>> offset calculation in ttm_bo_vm_fault_reserved.
>>
>>
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In order to avoid pixels getting stuck in the (unflushable) FIFO between
> the HVS and the PV, we need to add some delay after disabling the PV output
> and before disabling the HDMI controller. 20ms seems to be good enough so
>
Hi,
On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> Hi,
>
> This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> includes only graphics plane support (no video planes), no HDR10 capabilities,
> no graphics decompression (only
On Wed, Jul 29, 2020 at 03:41:46PM +0200, Thomas Zimmermann wrote:
> Most platforms allow for accessing framebuffer I/O memory with regular
> load and store operations. Some platforms, such as sparc64, require
> the use of special instructions instead.
>
> This patch adds vmap_iomem to struct
On Wed, Jul 29, 2020 at 03:41:45PM +0200, Thomas Zimmermann wrote:
> DRM fb helpers require read and write functions for framebuffer
> memory. Export the existing code from fbdev.
>
> Signed-off-by: Thomas Zimmermann
Hm I'm not super sure whether we want to actually reuse this stuff ... We
On Wed, Jul 29, 2020 at 4:11 AM Christian König
wrote:
>
> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> > Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> > amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> > when `size` is greater than 356.
> >
> > In
On Wed, Jul 29, 2020 at 03:41:44PM +0200, Thomas Zimmermann wrote:
> Removes trailing whitespaces in several places.
>
> Signed-off-by: Thomas Zimmermann
checkpatch patch for fbdev, I'm blown :-)
Acked-by: Daniel Vetter
> ---
> drivers/video/fbdev/core/fbmem.c | 10 +-
>
At least sparc64 requires I/O-specific access to framebuffers. This
patch prepares the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions test for the type of memory and call the rsp fb_sys_ of fb_cfb_
functions. For drivers that employ a
Removes trailing whitespaces in several places.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbmem.c | 10 +-
include/linux/fb.h | 18 +-
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term sulotion tothe problem.
This patchset adds a GEM object function that returns
DRM fb helpers require read and write functions for framebuffer
memory. Export the existing code from fbdev.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbmem.c | 53 ++--
include/linux/fb.h | 5 +++
2 files changed, 41 insertions(+),
The vmap_iomem function in struct drm_gem_object_funcs returns the
memory of the buffer if located in I/O memory, or NULL if it isn't.
The patch also updates the semantics of the vmap function to return
NULL if the buffer is not in system memory.
The main user is the fb-helper's console, which is
Most platforms allow for accessing framebuffer I/O memory with regular
load and store operations. Some platforms, such as sparc64, require
the use of special instructions instead.
This patch adds vmap_iomem to struct drm_gem_object_funcs. The new
interface drm_client_buffer_vmap_iomem() gives DRM
Hi Jiri,
On 7/29/20 9:02 AM, Jiri Slaby wrote:
> The current vgacon's scroll up implementation uses a circural buffer
> in vgacon_scrollback_cur. It always advances tail to prepare it for the
> next write and caps it to zero if the next ->vc_size_row bytes won't fit.
>
> But when we change the
Hi Guido,
On Wed, Jul 29, 2020 at 03:11:21PM +0200, Guido Günther wrote:
> Hi Laurentiu,
> On Fri, Jul 24, 2020 at 12:07:31PM +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu
> >
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities
Hi,
On Fri, Jul 24, 2020 at 12:07:34PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> Add bindings for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu
> Reviewed-by: Rob Herring
> ---
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
Hi Laurentiu,
On Fri, Jul 24, 2020 at 12:07:31PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> Some of its capabilities include:
> * 4K@60fps;
> * HDR10;
> * one graphics and 2 video pipelines;
> *
Am 29.07.20 um 02:08 schrieb Dave Airlie:
[SNIP]
Landed this in drm-next as well.
By the way there is another design bug in TTM which only affects
Nouveau. See ttm_mem_io_reserve_vm() and ttm_mem_io_free_vm().
What happens is that as soon as you have an userspace VM mapping the BO
ends up
On 29. 07. 20, 10:19, 张云海 wrote:
> On 2020/7/29 16:11, Jiri Slaby wrote:
>> But the loop checks for the overflow:
>> if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
>> vgacon_scrollback_cur->tail = 0;
>>
>> So the first 2 iterations would write to the end of the buffer
Am 28.07.20 um 21:11 schrieb Dave Airlie:
From: Dave Airlie
Drop the WARN_ON and consolidate the two paths into one.
Use the consolidate slowpath in the execbuf utils code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
On Wed, Jul 29, 2020 at 11:09:15AM +0200, Linus Walleij wrote:
> Revamp the way that the flow of data to the display is
> defined.
>
> I realized that the hardware supports something like
> 5 different modes of flow: oneshot, command with TE IRQ,
> command with BTA (bus turn around) and TE IRQ,
Am 29.07.20 um 08:23 schrieb Dave Airlie:
On Wed, 29 Jul 2020 at 16:21, Dave Airlie wrote:
On Fri, 24 Jul 2020 at 16:43, Thomas Zimmermann wrote:
Am 23.07.20 um 17:17 schrieb Christian König:
Instead of repeating that in each driver.
Signed-off-by: Christian König
Reviewed-by: Thomas
cHi,
On 7/29/20 10:23 AM, Andy Shevchenko wrote:
On Mon, Jul 27, 2020 at 09:41:20AM +0200, Thierry Reding wrote:
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
I've applied patches 3 through 12 to the PWM tree. I thought it was a
bit odd that only a handful of these patches
The function mcde_display_send_one_frame() has a historical
name that stems from being implemented when the driver
only supported single frame updates.
Rename it mcde_start_flow() so that it reflects the current
usage.
Reviewed-by: Stephan Gerhold
Signed-off-by: Linus Walleij
---
ChangeLog
Revamp the way that the flow of data to the display is
defined.
I realized that the hardware supports something like
5 different modes of flow: oneshot, command with TE IRQ,
command with BTA (bus turn around) and TE IRQ, video
with TE IRQ and video without TE IRQ instead synchronizing
to the
On Wed, Jul 29, 2020 at 10:11 AM Christian König
wrote:
>
> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> > Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> > amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> > when `size` is greater than 356.
> >
> > In
On Tue, Jul 28, 2020 at 11:43:19PM +0200, Linus Walleij wrote:
> Revamp the way that the flow of data to the display is
> defined.
>
> I realized that the hardware supports something like
> 5 different modes of flow: oneshot, command with TE IRQ,
> command with BTA (bus turn around) and TE IRQ,
Am 28.07.20 um 14:55 schrieb Tian Tao:
> fixed the following warning:
> hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable.
> hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable.
>
> v2:
> using the pci_dev.msi_enabled instead of priv->msi_enabled.
>
> v3:
>
On Tue, Jul 28, 2020 at 11:43:18PM +0200, Linus Walleij wrote:
> The function mcde_display_send_one_frame() has a historical
> name that stems from being implemented when the driver
> only supported single frame updates.
>
> Rename it mcde_start_flow() so that it reflects the current
> usage.
>
On Wed, Jul 29, 2020 at 8:58 AM Tetsuo Handa
wrote:
>
> syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy()
> based on outdated old_{rows,row_size} values, for resize_screen() can
> recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates
>
Am 28.07.20 um 21:29 schrieb Peilin Ye:
Compiler leaves a 4-byte hole near the end of `dev_info`, causing
amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
when `size` is greater than 356.
In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
Hi,
On 29. 07. 20, 9:53, 张云海 wrote:
> This patch dosen't fix the issue, the check should be in the loop.
>
> The change of the VT sze is before vgacon_scrollback_update, not in the
> meantime.
>
> Let's consider the following situation:
> suppose:
>
Am 28.07.20 um 20:27 schrieb Felix Kuehling:
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
Tested-by: Laurent Morichetti
On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote:
>
> On async flips, there needs to be some clarity/guideline on the behaviour and
> event expectation from the
> driver by user space.
> Here are few assumptions that we have,
> 1. Our understanding is that the user space doesn’t expect the
On Wed, Jul 29, 2020 at 2:33 AM Hyun Kwon wrote:
>
> Hello,
>
> On Tue, Jul 28, 2020 at 03:35:43PM -0700, Laurent Pinchart wrote:
> > On Wed, Jul 29, 2020 at 12:02:05AM +0200, dan...@ffwll.ch wrote:
> > > Hi Hyun Kwon,
> > >
> > > Are you all sorted with drm-misc commit rights so you can push the
1 - 100 of 120 matches
Mail list logo
