On Tue, Jul 28, 2020 at 05:05:03PM +0200, Andrzej Hajda wrote:
> Hi Greg,
>
> Apparently the patchset has no more comments.
>
> Could you take the patches to your tree? At least 1st and 2nd.
All now queued up, thanks!
greg k-h
___
dri-devel mailing li
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
> While looking into adding atomic-pwm support to the pwm-crc driver I
> noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
> there is a clock-divider which divides this with a value between 1-128,
> and there are 256 du
On Fri, Jul 17, 2020 at 03:37:46PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
> controls a s
On Fri, Jul 17, 2020 at 03:37:47PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this commit m
From 06ba7d3e64e55262bf818084904eec7b7320a2ad Mon Sep 17 00:00:00 2001
From: Marius Iacob
Date: Wed, 29 Jul 2020 16:51:41 +0300
Subject: [PATCH] Added orientation quirk for ASUS tablet model T103HAF
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
Gcc report warning as follows:
drivers/misc/habanalabs/common/command_submission.c:373:6: warning:
variable 'ctx_asid' set but not used [-Wunused-but-set-variable]
373 | int ctx_asid, rc;
| ^~~~
This variable is not used in function cs_timedout(), this commit
remove it to fix t
Hi,
A few more patches to the ingenic-drm IPU driver.
Patch [1/3] fixes the behaviour on newer SoCs at high resolutions /
framerates.
Patch [2/3] drops YUV 4:2:2 support on the JZ4725B SoC because of what I
think is a hardware bug.
Patch [3/3] makes the IPU clock enabled/disabled when needed.
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 work properly on newer SoCs by letting the LCD controller
trigger the IPU f
On 22-07-20, 11:00, Viresh Kumar wrote:
> On 21-07-20, 07:28, Rob Clark wrote:
> > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> > tree and merge it via msm-next -> drm-next -> linus
>
> I wanted to send it via my tree, but its okay. Pick this patch from
> linux-next and a
On 7/29/20 6:59 PM, Sam Ravnborg wrote:
Hi,
[...]
>> + port@0:
>> +type: object
>> +additionalProperties: false
>> +
>> +description: |
>> + Video port for MIPI DSI input
>> +
>> +properties:
>> + reg:
>> +const: 0
>> +
>> +
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 does not fix it. This can happen anytime, in the first
few frames, or af
On Fri, Jul 17, 2020 at 03:37:45PM +0200, Hans de Goede wrote:
> The CRC PWM controller has a clock-divider which divides the clock with
> a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
> defines, this range maps to a register value of 0-127.
>
> So after calculating the clock-div
On Fri, Jul 17, 2020 at 03:37:48PM +0200, Hans de Goede wrote:
> Replace the enable, disable and config pwm_ops with an apply op,
> to support the new atomic PWM API.
I didn't notice any visible issue, so
Reviewed-by: Andy Shevchenko
Perhaps you may consider reusing existing _enable() / _disable
Hi Thomas:
Thank you very much .
Best
-邮件原件-
发件人: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
发送时间: 2020年7月29日 16:35
收件人: tiantao (H) ; airl...@linux.ie; dan...@ffwll.ch;
kra...@redhat.com; alexander.deuc...@amd.com; t...@linutronix.de;
dri-devel@lists.freedesktop.org; xinl
Hi All,
Please Review the patch
On Fri, Jul 10, 2020 at 7:11 PM Vinay Simha BN wrote:
> This driver is tested with two panels individually with Apq8016-IFC6309
> board
>
> https://www.inforcecomputing.com/products/single-board-computers-sbc/qualcomm-snapdragon-410-inforce-6309-micro-sbc
>
> 1.
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
old_{rows,row_size} values which were saved before calling resize_screen().
Dan
On Tue, Jul 28, 2020 at 09:55:22PM +0200, Hans de Goede wrote:
> On 7/28/20 8:57 PM, Andy Shevchenko wrote:
> > On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
...
> > Maybe I'm too picky, but I would go even further and split apply to two
> > versions
> >
> > static int pwm_lpss
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 Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
V2: Fix dt_binding_check
This regulator/backlight driver handles the ATTINY88 present on the
RPi 7" touchscreen panel and exposes the power/backlight interfaces.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Mark Brown
Cc: Sam Ravnborg
---
drivers/regulator/Kconfig
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v5 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.
>
> This series consists o
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 allocation function to (PPTable_t *)
is useless.
Signed-off-by: Li Heng
---
drivers/
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 had been reviewed and there
> were no Tested-bys,
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 and this
> 3rd one should have zeroed ->ta
syzbot is reporting UAF bug in set_origin() from vc_do_resize() [1], for
vc_do_resize() calls kfree(vc->vc_screenbuf) before calling set_origin().
Unfortunately, in set_origin(), vc->vc_sw->con_set_origin() might access
vc->vc_pos when scroll is involved in order to manipulate cursor, but
vc->vc_p
Hi All,
Please Review the patch
On Fri, Jul 10, 2020 at 7:11 PM Vinay Simha BN wrote:
> - license modified to (GPL-2.0-only OR BSD-2-Clause)
> - single-link and dual-link lvds description and
> examples are added
> - proper indentation
> - VESA/JEIDA formats picked from panel-lvds dts
> - dsi
Instead of keeping the IPU clock enabled constantly, enable and disable
it on demand, when the IPU plane is used.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/in
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
connection can be described in DT too.
Signed-off-by: Marek Vasut
To: dri-devel@lists.
On 7/29/20 6:56 PM, Sam Ravnborg wrote:
[...]
>> +static int tc358762_probe(struct mipi_dsi_device *dsi)
>> +{
>> +struct device *dev = &dsi->dev;
>> +struct tc358762 *ctx;
>> +int ret;
>> +
>> +ctx = devm_kzalloc(dev, sizeof(struct tc358762), GFP_KERNEL);
>> +if (!ctx)
>> +
Hi All,
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:
vgacon_scrollback_cur->size is 65440
vgacon_scroll
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 add some delay after disabling the PV output
> > and before d
On Tue, Jul 21, 2020 at 6:17 PM Xin He wrote:
>
> From: Qi Liu
>
> We should put the reference count of the fence after calling
> virtio_gpu_cmd_submit(). So add the missing dma_fence_put().
>
> Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit
> synchronization")
> Co-deve
On 30. 07. 20, 8:46, Jiri Slaby wrote:
> Hi, OTOH, you should have CCed all the (public) lists.
>
> On 30. 07. 20, 4:50, 张云海 wrote:
>> Zhang Xiao points out that the check should use > instead of >=,
>> otherwise the last line will be skip.
>> I agree with that, so I modify the patch.
>> Could you
The vendor driver makes a few retries on read DSI
transactions, something that is needed especially in
case of read (such as reading the panel MTP ID) while
the panel is running in video mode. This happens on
the Samsung s6e63m0 panel on the Golden device.
Retry reads and writes alike two times.
Hi
Am 29.07.20 um 15:57 schrieb dan...@ffwll.ch:
> 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 just initialize the memory type parameters
before calling ttm_bo_init_mm.
v2: keep extra system domain handling
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 20
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 28
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 96 +++--
1 file changed, 43 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/
Instead use a boolean field in the memory manager structure.
Also invert the meaning of the field since the use of a TT
structure is the special case here.
v2: cleanup zero init.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_gem_vram_helper.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --gi
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 -
drivers/gpu/drm/nouveau/nouveau_ttm.c | 61 +--
2 files change
Instead of repeating that in each driver.
v2: keep the caching limitation for VMWGFX for now.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Alex Deucher
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
drivers/gpu/drm/drm_gem_vra
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/qxl/qxl_ttm.c | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/
It is a very strange concept to call a function which just
calls back the caller for the functions parameters.
Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
drivers/gpu/drm/drm_gem_vram_helper
The current one will become inactive after this Friday.
Cc: Petri Latvala
Cc: Lukasz Fiedorowicz
Signed-off-by: Arkadiusz Hiler
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea4e642c..383c327c 100644
--- a/MAINTAINERS
+++ b/
Hi Guido,
On Wed, Jul 29, 2020 at 05:09:52PM +0200, Guido Günther wrote:
> 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, Laurenti
Hi Laurentiu,
On Thu, Jul 30, 2020 at 12:10:55PM +0300, Laurentiu Palcu wrote:
> Hi Guido,
>
> On Wed, Jul 29, 2020 at 05:09:52PM +0200, Guido Günther wrote:
> > 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
Hi
Am 28.07.20 um 20:04 schrieb Sam Ravnborg:
> Hi Thomas.
>
> A few comments related to the code - but not to this patch and
> not to this patch-set.
> But I noticed so here goes.
You're right on these points. But it's worth a separate patchset. I
really just move code around here.
Best regard
Hi
Am 28.07.20 um 11:23 schrieb dan...@ffwll.ch:
> On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
>> Managed releases of the device's I2C adapter simplify the connector's
>> release.
>>
>> Signed-off-by: Thomas Zimmermann
>
> I think this breaks bisect, since at this point th
Hi all,
Today's linux-next merge of the hmm tree got a conflict in:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
between commit:
7763d24f3ba0 ("drm/nouveau/vmm/gp100-: fix mapping 2MB sysmem pages")
from the drm tree and commits:
4725c6b82a48 ("nouveau: fix mapping 2MB sysmem page
Hi
Am 28.07.20 um 20:06 schrieb Sam Ravnborg:
> On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
>> Managed releases of the device's I2C adapter simplify the connector's
>> release.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/ast/ast_mode.c | 21 ++-
On Thu, Jul 30, 2020 at 10:13:06AM +0200, Linus Walleij wrote:
> The vendor driver makes a few retries on read DSI
> transactions, something that is needed especially in
> case of read (such as reading the panel MTP ID) while
> the panel is running in video mode. This happens on
> the Samsung s6e63
On Wed, Jul 29, 2020 at 11:32:28AM +0200, Hans de Goede wrote:
> 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 1
Arkadiusz Hiler writes:
> The current one will become inactive after this Friday.
>
> Cc: Petri Latvala
> Cc: Lukasz Fiedorowicz
> Signed-off-by: Arkadiusz Hiler
Acked-by: Lukasz Fiedorowicz
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTA
On Thu, Jul 30, 2020 at 12:09:11PM +0300, Arkadiusz Hiler wrote:
> The current one will become inactive after this Friday.
>
> Cc: Petri Latvala
> Cc: Lukasz Fiedorowicz
> Signed-off-by: Arkadiusz Hiler
Acked-by: Petri Latvala
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1
On 07/29, Daniel Vetter wrote:
> 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
MGA cards can run in traditional VGA mode or an enhanced MGA mode; with
the latter being required for KMS. So far, MGA mode was enabled during
modesetting. As it's fundamental for device operation, the patch moves
it next to the device register setup.
Signed-off-by: Thomas Zimmermann
Reviewed-by:
So far, PCI option registers were initialized as part of modesetting,
which is late in the process. As these registers control fundamental
operation, they should be set early.
The patch moves the PCI option handling into device register setup,
before even the device MMIO memory is being mapped. No
The modesetting code initialized several memory-related flags in the
MISC register. Move this code to MM initialization.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 6 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +---
2 files chang
The unique revision id is only useful for G200SE devices. Store the
value in model-specific data within struct mga_device. While at it,
the patch also adds an init helper for the value.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 19
SHMEM pages use write-combine caching by default, but can also use the
platform's default page caching. Doing so may improve the performance
of I/O on the framebuffer.
Mgag200's hardware does not access framebuffer pages directly (i.e.,
via DMA), so enabling caching does not have an effect on cons
The mgag200 driver maps registers into the address space. Move the
code into a separate helper function. No functional changes.
One small difference is in the handling of SDRAM/SGRAM. MGA devices
can come with either SDRAM or SGRAM. So far, the driver checked for
SDRAM, which is the common case. T
This patch adds support for G200 desktop cards. We can reuse the whole
memory and modesetting code. A few PCI and DAC register values have to
be updated accordingly.
The most significant change is in the PLL setup. The driver parses the
device's BIOS to retrieve clock limits and reference clocks.
The modesetting code initialized the memory-related register CRTCEXT4.
Move this code to MM initialization.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
2 files changed, 3 insertion
This patchset puts device initialization in the correct order and
adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
The patchset has already been reviewed. In v2 I changed the patch 8
to copy the BIOS ROM to system memory, which simplifies parsing.
The first 7 patches prepare the dri
On 13. 07. 20, 12:57, Yang Yingliang wrote:
> I got a slab-out-of-bounds report when I doing fuzz test.
>
> [ 334.989515]
> ==
> [ 334.989577] BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
> [ 334.989588] Write of si
On Thu, Jul 30, 2020 at 12:47 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
> old_{rows,row_si
On Wed, Jul 29, 2020 at 2: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 Thu, Jul 30, 2020 at 1:27 PM Tetsuo Handa
wrote:
>
> On 2020/07/30 20:16, Daniel Vetter wrote:
> > Patch looks good, except ... does this compile? fbcon_update_vcs is
> > defined in fbcon.h, and that doesn't seem to be included here ...
> > Maybe what we want is an fb_set_var_ioctl in fbmem.c s
On Wed, Jul 29, 2020 at 5:34 PM Koenig, Christian
wrote:
>
> Sure.
Note that drm-misc-next isn't the right branch for cc: stable stuff, see
https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
Just to avoid confusion and needless cherrypicking acr
Am 30.07.20 um 13:40 schrieb Daniel Vetter:
On Wed, Jul 29, 2020 at 5:34 PM Koenig, Christian
wrote:
Sure.
Note that drm-misc-next isn't the right branch for cc: stable stuff, see
https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
So this sh
Am 30.07.20 um 13:50 schrieb Christian König:
Am 30.07.20 um 13:40 schrieb Daniel Vetter:
On Wed, Jul 29, 2020 at 5:34 PM Koenig, Christian
wrote:
Sure.
Note that drm-misc-next isn't the right branch for cc: stable stuff, see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
Am 28.07.20 um 15:58 schrieb Daniel Vetter:
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we a
On 7/28/20 3:58 PM, Daniel Vetter wrote:
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we al
On 09.07.2020 23:04, Rob Herring wrote:
> On Thu, Jul 02, 2020 at 06:37:19PM +0200, Sylwester Nawrocki wrote:
>> Add documentation for new optional properties in the exynos bus nodes:
>> samsung,interconnect-parent, #interconnect-cells, bus-width.
>> These properties allow to specify the SoC interc
On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
wrote:
>
>
> On 7/28/20 3:58 PM, Daniel Vetter wrote:
> > GPU drivers need this in their shrinkers, to be able to throw out
> > mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> > but that loop is resolved by trylocking i
On 30. 07. 20, 15:24, Yang Yingliang wrote:
>
> On 2020/7/30 19:04, Jiri Slaby wrote:
>> On 13. 07. 20, 12:57, Yang Yingliang wrote:
>>> I got a slab-out-of-bounds report when I doing fuzz test.
>>>
>>> [ 334.989515]
>>> ==
>>> [ 33
Hi Pekka,
Thanks for the patch - merged to drm-misc-next.
While applying the patch the following warning popped-up.
-:37: WARNING:SPDX_LICENSE_TAG: Missing or malformed
SPDX-License-Identifier tag in line 1
#37: FILE: Documentation/gpu/drm-uapi.rst:1:
+.. Copyright 2020 DisplayLink (UK) Ltd.
This is the next patchset for converting ast to managed initialization.
For v2 of the series, I moved the I2C patches into a separate patchset.
This resolves a mid-series problem wrt to releasing I2C. The rest of
the patches are unchanged (except for a rebase).
Patches #1 to #6 address modesetting
Only single instances of CRTC and connector are supported per
device. Embed both in ast's structure and remove the individual
memory allocations. DRM's CRTC cleanup helpers replace the rsp.
destroy function in ast.
While at it, also convert to_ast_connector() to a function.
Signed-off-by: Thomas
Putting the DRM driver to the top of the file and the PCI code to the
bottom makes ast_drv.c more readable. While at it, the patch prefixes
file-scope variables with ast_.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_drv.c | 59 +++
Several places in ast use ast->dev, when a dev pointer is already
available within the function. Remove the extra indirection. No
functional changes made.
This is just a small cleanup before embedding the DRM device instance
in struct ast_private.
Signed-off-by: Thomas Zimmermann
Acked-by: Danie
The ast driver keeps a backup copy of the DP501 encoder's firmware. This
patch adds managed release of the allocated memory.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/dri
The ast code still references dev_private in several place when looking
up the ast device structure. Convert the remaining locations to use
to_ast_private().
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_cursor.c | 2 +-
drivers/gpu
Turns struct ast_private into a subclass of struct drm_device by
embedding the latter. This allows for using DRM's managed device
allocation.
The use of struct drm_device.dev_private is deprecated. The patch
converts the last remaining users to to_ast_private().
Signed-off-by: Thomas Zimmermann
The ast driver loads firmware for the DP501 display encoder. The
patch replaces the removal code with a managed release function.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_dp501.c | 23 ++-
drivers/gpu/drm/as
This turns the ast's device cleanup code into a managed release helper
function. Note that the code uses devres helpers. The release function
switches the device back to VGA mode and therefore runs during HW device
cleanup; not at DRM device cleanup.
Signed-off-by: Thomas Zimmermann
Acked-by: Dan
The ast driver's load and unload functions are left-overs from when
struct drm_driver.load/unload was still in use. The PCI probe helper
allocated the DRM device and ran load to initialize it.
This patch replaces this code with device create and destroy. The
main difference is that the device's cr
On Wed, Jul 29, 2020 at 11:36 PM Alex Deucher wrote:
>
> 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.
Ignore this one. The NULL pointer regression fix didn't fully fix the
issue, so I'm go
On Wed, Jul 29, 2020 at 10:10 PM Viresh Kumar wrote:
>
> On 22-07-20, 11:00, Viresh Kumar wrote:
> > On 21-07-20, 07:28, Rob Clark wrote:
> > > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> > > tree and merge it via msm-next -> drm-next -> linus
> >
> > I wanted to send it
On Thu, Jul 30, 2020 at 04:48:30PM +0200, Paul Cercueil wrote:
> Instead of keeping the IPU clock enabled constantly, enable and disable
> it on demand, when the IPU plane is used. That way, we won't use any
> extra power when the IPU is not used.
>
> v2: Explain the reason of this patch
>
> Sign
Hi Paul
On Thu, Jul 30, 2020 at 04:48:29PM +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, to the point where a software reset of the IP
> does n
Hi Dave, Daniel,
A few fixes for 5.8. It would be nice to get these in for 5.8 final. Take
2 just reverts the original fix because the fix for the fix seems to cause
other problems.
The following changes since commit a4a2739beb8933a19281bca077fdb852598803ed:
Merge tag 'drm-misc-fixes-2020-07
Patch looks good to me too.
Reviewed-by: Roland Scheidegger
Seems indeed like we should do some cleanup.
Roland
Am 28.07.20 um 09:37 schrieb Christian König:
> Am 28.07.20 um 05:42 schrieb Dave Airlie:
>> From: Dave Airlie
>>
>> Just drop the argument from this.
>>
>> This does ask the questio
On Thu, Jul 30, 2020 at 8:37 AM Viresh Kumar wrote:
>
> On 30-07-20, 08:27, Rob Clark wrote:
> > Hmm, I've already sent my pull request to Dave, dropping the patch
> > would require force-push and sending a new PR. Which I can do if Dave
> > prefers. OTOH I guess it isn't the end of the world if
Hi Marek
On Wed, Jul 29, 2020 at 11:46:45PM +0200, Marek Vasut wrote:
> This regulator/backlight driver handles the ATTINY88 present on the
> RPi 7" touchscreen panel and exposes the power/backlight interfaces.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anhol
Hi Dave & Daniel,
(Covering for Jani here for drm-intel-next-fixes)
5 new commits over drm-intel-next here.
Fix for KASAN detected race condition and linux-next scheduler
WARNs. Patch to avoid IRQ spinlock and Cc: stable PMU refcount
update.
CI machinery needed some kicking, so results didn't a
On 7/30/20 3:17 PM, Daniel Vetter wrote:
On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
wrote:
On 7/28/20 3:58 PM, Daniel Vetter wrote:
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loo
On Thu, Jul 30, 2020 at 09:18:30AM -0700, Dmitry Torokhov wrote:
> I believe it still has not been answered why this can't be pushed into
> resource providers (clock, regulators, gpio, interrupts, etc),
> especially for devm APIs where we know exactly what device we are
> requesting a resource for
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the fo
On 7/30/20 5:03 AM, Jason Gunthorpe wrote:
On Thu, Jul 30, 2020 at 07:21:10PM +1000, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the hmm tree got a conflict in:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
between commit:
7763d24f3ba0 ("drm/nouveau/vmm/gp100-: f
1 - 100 of 188 matches
Mail list logo
