On Wed, Nov 18, 2020 at 05:08:05PM -0800, Gurchetan Singh wrote:
> From: Anthoine Bourgeois
>
> For coherency, all ioctls are suffixed
>
> Signed-off-by: Anthoine Bourgeois
All pushed to drm-misc-next.
thanks,
Gerd
___
dri-devel mailing list
This patch fixes the following kernel-doc warnings:
/home/simon/src/linux/Documentation/gpu/drm-kms:466:
./drivers/gpu/drm/drm_crtc.c:236: WARNING: Unexpected indentation.
/home/simon/src/linux/Documentation/gpu/drm-kms:466:
./drivers/gpu/drm/drm_crtc.c:237: WARNING: Block quote ends
https://bugzilla.kernel.org/show_bug.cgi?id=208373
--- Comment #6 from Michel Dänzer (mic...@daenzer.net) ---
The original report here is about the vmwgfx driver; issues with amdgpu should
be tracked elsewhere.
sander44, are you seeing any problem other than the messages?
--
You are receiving
On Fri, Nov 20, 2020 at 10:39:45AM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter
> wrote:
> >
> > On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter
> > > wrote:
> > > >
> > > > On Thu, Nov 19, 2020
On 20/11/2020 09:42, Marc Zyngier wrote:
> Instead of moving meson_dw_hdmi_init() around which breaks existing
> platform, let's enable the clock meson_dw_hdmi_init() depends on.
> This means we don't have to worry about this clock being enabled or
> not, depending on the boot-loader features.
>
On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil wrote:
>
> On 20/11/2020 10:18, Daniel Vetter wrote:
> > On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
> >>
> >> On 20/11/2020 09:06, Hans Verkuil wrote:
> >>> On 19/11/2020 15:41, Daniel Vetter wrote:
> The media model assumes that
On 20/11/2020 10:18, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
>>
>> On 20/11/2020 09:06, Hans Verkuil wrote:
>>> On 19/11/2020 15:41, Daniel Vetter wrote:
The media model assumes that buffers are all preallocated, so that
when a media pipeline is
https://bugzilla.kernel.org/show_bug.cgi?id=210123
--- Comment #4 from Stefan Mayr (stefan+ker...@mayr-stefan.de) ---
I had another look at bug 208373: the inital reporter also uses vmwgfx and
amdgpu is only mentioned in bug 208373, comment 2
--
You are receiving this mail because:
You are
Flushing the shadow framebuffer and invoking the dirty callback are two
separate operations, so do them seprately. The flush operation is paired
with calls to vmap and vunmap. They are not needed for the dirty callback,
which performs its own invocations if necessary.
Signed-off-by: Thomas
The fbdev helper's generic probe function establishes a mapping for
framebuffers without shadow buffer. The clean-up function did not unmap
the buffer object. Add the unmap operation.
As fbdev devices are usally released during system shutdown, this has
not been a problem in practice.
Introduce a separate function for the blit code and its vmap setup. Done
in preparation of additional changes. No functional changes are made.
v2:
* print a single warning if damage blitter fails
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 27
The dirty worker handles all damage updates, instead of just calling
the framebuffer's dirty callback. Rename it to damage worker. Also
rename related variables accordingly. No functional changes are made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 65
Copy the vmap()'ed instance of struct dma_buf_map before modifying it,
in case the implementation of vunmap() depends on the exact address.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
If the damage handling fails, restore the damage area. The next invocation
of the damage worker will then perform the update.
v2:
* print a single warning if dirty callback fails (Daniel, Sebastian)
* update comment
Signed-off-by: Thomas Zimmermann
---
Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which
in turn requires pinning the BO. While being pinned, the BO cannot be moved
into VRAM for scanout. Consequently, a concurrent modeset operation that
involves the fbdev framebuffer would likely fail.
Resolve this problem be
Returning early in the dirty worker if no update is required makes the
code more readable. No functional changes are made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git
DRM client's vmap/vunmap functions don't allow for multiple vmap
operations. Calling drm_client_buffer_vmap() twice returns the same
mapping, then calling drm_client_buffer_vunmap() twice already unmaps
on the first call. This leads to unbalanced vmap refcounts. Fix this
by calling drm_gem_vmap()
Here's a number of fb-helper patches that have been piling up recently.
Patches 1 to 3 fix bugs that I spotted while going through the code.
Because of the way the fbdev code works, they have been avoided so far.
Patches 4 to 10 cleanup damage handling for fbdev's shadow buffer and
fix a few
If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
the update might not make it to the screen.
v2:
* mark virtual screen as dirty (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory")
Cc: Thomas Zimmermann
https://bugzilla.kernel.org/show_bug.cgi?id=210123
--- Comment #3 from Stefan Mayr (stefan+ker...@mayr-stefan.de) ---
Did some more test with Kernel versions provided by SUSE:
Kernel 5.0.13 - 6 days without issues
Kernel 5.2.14 - 2 days until we got the error message
Today I installed 5.1.16
Hi
Am 20.11.20 um 10:52 schrieb David Laight:
Hi David
Am 18.11.20 um 23:01 schrieb David Laight:
...
Did you try Daniel's suggestion of testing with the direct parent commit?
(I was on holiday yesterday and didn't want to spend a sunny
afternoon doing bisects.)
Makes sense :)
I've
On Fri, Nov 20, 2020 at 10:46 AM Simon Ser wrote:
>
> This allows `struct drm_mode_modeinfo` references to be linkified.
>
> Some descriptions are borrowed from struct drm_display_mode.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> ---
> include/uapi/drm/drm_mode.h | 18 ++
Am 20.11.20 um 11:05 schrieb Daniel Vetter:
On Fri, Nov 20, 2020 at 11:04 AM Christian König
wrote:
Am 20.11.20 um 10:54 schrieb Daniel Vetter:
Random observation while trying to review Christian's patch series to
stop looking at struct page for dma-buf imports.
This was originally added in
On Fri, Nov 20, 2020 at 11:04 AM Christian König
wrote:
>
> Am 20.11.20 um 10:54 schrieb Daniel Vetter:
> > Random observation while trying to review Christian's patch series to
> > stop looking at struct page for dma-buf imports.
> >
> > This was originally added in
> >
> > commit
Am 20.11.20 um 10:54 schrieb Daniel Vetter:
Random observation while trying to review Christian's patch series to
stop looking at struct page for dma-buf imports.
This was originally added in
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23
On 2020-11-20 09:26, Neil Armstrong wrote:
On 19/11/2020 19:35, Marc Zyngier wrote:
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7f8eea494147..52af8ba94311 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++
Random observation while trying to review Christian's patch series to
stop looking at struct page for dma-buf imports.
This was originally added in
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page
Since I butchered this I figured better to make sure we have testcases
for this now. Since we only have a locking context for __GFP_FS that's
the only thing we're testing right now.
Cc: linux-fsde...@vger.kernel.org
Cc: Dave Chinner
Cc: Qian Cai
Cc: linux-...@vger.kernel.org
Cc: Thomas
Extracted from slab.h, which seems to have the most complete version
including the correct might_sleep() check. Roll it out to slob.c.
Motivated by a discussion with Paul about possibly changing call_rcu
behaviour to allocate memory, but only roughly every 500th call.
There are a lot fewer
fs_reclaim_acquire/release nicely catch recursion issues when
allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
to use to keep the excessive caches in check). For mmu notifier
recursions we do have lockdep annotations since 23b68395c7c7
("mm/mmu_notifiers: add a lockdep map
Hi all,
I've finally gotten around to polish of my lockdep anntotation patches
from a while ago:
https://lore.kernel.org/dri-devel/20200610194101.1668038-1-daniel.vet...@ffwll.ch/
That patch has been in -mm for a few days already, but it immediately hit
some issues with xfs.
Changes since v2:
This allows `struct drm_mode_modeinfo` references to be linkified.
Some descriptions are borrowed from struct drm_display_mode.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
include/uapi/drm/drm_mode.h | 18 ++
1 file changed, 18 insertions(+)
diff --git
Instead of moving meson_dw_hdmi_init() around which breaks existing
platform, let's enable the clock meson_dw_hdmi_init() depends on.
This means we don't have to worry about this clock being enabled or
not, depending on the boot-loader features.
Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure
The HDMI driver request clocks early, but never disable them, leaving
the clocks on even when the driver is removed.
Fix it by slightly refactoring the clock code, and register a devm
action that will eventually disable/unprepare the enabled clocks.
Signed-off-by: Marc Zyngier
---
Guillaume reported that my earlier fixes for the meson HDMI driver
broke another set of machines which are now exploding (clock not
enabled).
I have thus reconsidered the approach and came up with an alternative
fix (enable a missing clock), which Guillaume confirmed to be working.
Jerome pointed
On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter wrote:
>
> On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter
> > wrote:
> > >
> > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote:
> > > > Hi,
> > > >
> > > > On 10/27/20
On Fri, Nov 20, 2020 at 7:32 AM Sumit Semwal wrote:
>
> Hi Daniel,
>
>
> On Wed, 18 Nov 2020 at 13:16, Daniel Vetter wrote:
> >
> > On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote:
> > > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote:
> > > > On Thu, Nov 12, 2020 at 08:11:02PM -0800,
On Fri, Nov 20, 2020 at 9:39 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 19.11.20 um 16:32 schrieb Daniel Vetter:
> > On Thu, Nov 19, 2020 at 10:59:42AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 13.11.20 um 16:29 schrieb Maxime Ripard:
> >>> Private objects storing a state shared across
On 19/11/2020 19:35, Marc Zyngier wrote:
> On 2020-11-19 18:13, Jerome Brunet wrote:
>> On Thu 19 Nov 2020 at 19:04, Guillaume Tucker
>> wrote:
>>
>>> Hi Marc,
>>>
>>> On 19/11/2020 11:58, Marc Zyngier wrote:
On 2020-11-19 10:26, Neil Armstrong wrote:
> On 19/11/2020 11:20, Marc Zyngier
On Wed, Nov 18, 2020 at 05:08:09PM -0800, Gurchetan Singh wrote:
To be clearer about our intentions to associate sequence numbers
and fence IDs, let's rename these variables.
Signed-off-by: Gurchetan Singh
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4
On Wed, Nov 18, 2020 at 05:08:08PM -0800, Gurchetan Singh wrote:
Currently, the fence ID, which can be used to identify a
virtgpu fence, is the same as the fence sequence number.
Let's use the fence_id name to clearly signal this.
Signed-off-by: Gurchetan Singh
Reviewed-by: Anthoine
Hi
Am 20.11.20 um 09:23 schrieb Xu Wang:
Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/goldfishfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/goldfishfb.c
On Fri, Nov 20, 2020 at 9:46 AM Simon Ser wrote:
>
> On Thursday, November 19, 2020 4:06 PM, Daniel Vetter wrote:
>
> > > + /**
> > > +* @connection: Status of the connector.
> > > +*
> > > +* See enum drm_connector_status.
> >
> > Please add & so it becomes a link
On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
>
> On 20/11/2020 09:06, Hans Verkuil wrote:
> > On 19/11/2020 15:41, Daniel Vetter wrote:
> >> The media model assumes that buffers are all preallocated, so that
> >> when a media pipeline is running we never miss a deadline because the
> >>
Document how to perform a GETCONNECTOR ioctl. Document the various
struct fields. Also document how to perform a forced probe, and when
should user-space do it.
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm_mode.h | 78
On Thursday, November 19, 2020 4:06 PM, Daniel Vetter wrote:
> > + /**
> > +* @connection: Status of the connector.
> > +*
> > +* See enum drm_connector_status.
>
> Please add & so it becomes a link in the generated docs (and pls check
> the link goes to the right
18.11.2020 07:21, Viresh Kumar пишет:
...
+ /* legacy device-trees don't have OPP table and must be updated */
+ if (!device_property_present(>dev, "operating-points-v2")) {
+ dev_err(>dev,
+ "OPP table not found, please update your device
Hello,
syzbot found the following issue on:
HEAD commit:03430750 Add linux-next specific files for 20201116
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=123c946a50
kernel config: https://syzkaller.appspot.com/x/.config?x=a1c4c3f27041fdb8
dashboard
On Fri, 2020-11-20 at 07:42 +0800, Chun-Kuang Hu wrote:
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年11月18日 週三 下午4:21寫道：
> >
> > Convert HDMI PHY binding to YAML schema mediatek,hdmi-phy.yaml
> >
> > Cc: Chun-Kuang Hu
> > Signed-off-by: Chunfeng Yun
> > Reviewed-by: Rob Herring
> > ---
> > v3: add
fixed the following warnings
drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
---
On Fri, 2020-11-20 at 07:38 +0800, Chun-Kuang Hu wrote:
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年11月18日 週三 下午4:21寫道：
> >
> > Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
> >
> > Cc: Chun-Kuang Hu
> > Signed-off-by: Chunfeng Yun
> > ---
> > v3: new patch
> > ---
> >
Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/goldfishfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 9c83ec3f8e1f..c2f386b35617 100644
Hi CK,
On Fri, 20 Nov 2020 07:23:35 +0800
Chun-Kuang Hu wrote:
> From: CK Hu
>
> In the patch to be fixed, horizontal_backporch_byte become to large
> for some panel, so roll back that patch. For small hfp or hbp panel,
> using vm->hfront_porch + vm->hback_porch to calculate
>
On Mon, 2020-11-09 at 18:21:50 UTC, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter
> or member 'np' not described in 'hisi_spi_nor_register'
> drivers/mtd/spi-nor/controllers/hisi-sfc.c:328:
Signed-off-by: Kai-Chuan Hsieh
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index deeed73f4ed6..6789e30a3cba 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++
Hi
Am 19.11.20 um 16:32 schrieb Daniel Vetter:
On Thu, Nov 19, 2020 at 10:59:42AM +0100, Thomas Zimmermann wrote:
Hi
Am 13.11.20 um 16:29 schrieb Maxime Ripard:
Private objects storing a state shared across all CRTCs need to be
carefully handled to avoid a use-after-free issue.
The proper
On Thu, Nov 19, 2020 at 04:10:57PM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2020 at 9:33 AM Peilin Ye wrote:
> > setfont seems to work fine, I tried Georgian-Fixed16 (256 chars) and
> > Uni2-VGA16 (512 chars) under /usr/share/consolefonts/ in my Ubuntu box,
> > including setting all consoles
Hi
Am 20.11.20 um 09:21 schrieb Sam Ravnborg:
Hi Anitha.
On Fri, Nov 20, 2020 at 01:19:06AM +, Chrisanthus, Anitha wrote:
Looks good to me.
Can we get either an "Acked-by:" or "Reviewed-by:"?
Then we can use this while applying.
Any news on gettting commit access yourself?
If not, then
On Fri, Nov 20, 2020 at 5:28 PM Hans Verkuil wrote:
>
> On 20/11/2020 09:06, Hans Verkuil wrote:
> > On 19/11/2020 15:41, Daniel Vetter wrote:
> >> The media model assumes that buffers are all preallocated, so that
> >> when a media pipeline is running we never miss a deadline because the
> >>
On 20/11/2020 09:06, Hans Verkuil wrote:
> On 19/11/2020 15:41, Daniel Vetter wrote:
>> The media model assumes that buffers are all preallocated, so that
>> when a media pipeline is running we never miss a deadline because the
>> buffers aren't allocated or available.
>>
>> This means we cannot
Hi Anitha.
On Fri, Nov 20, 2020 at 01:19:06AM +, Chrisanthus, Anitha wrote:
> Looks good to me.
Can we get either an "Acked-by:" or "Reviewed-by:"?
Then we can use this while applying.
Any news on gettting commit access yourself?
If not, then try to ping on the open ticket.
Sam
On 19/11/2020 15:41, Daniel Vetter wrote:
> It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
> symbol from all over the tree (well just one place, somehow omap media
> driver still had this in its Kconfig, despite not using it).
>
> Reviewed-by: John Hubbard
> Acked-by:
On 19/11/2020 15:41, Daniel Vetter wrote:
> The media model assumes that buffers are all preallocated, so that
> when a media pipeline is running we never miss a deadline because the
> buffers aren't allocated or available.
>
> This means we cannot fix the v4l follow_pfn usage through
>
If kmb_dsi_init() fails the "kmb->kmb_dsi" variable is an error pointer.
The kernel will Oops when we pass it to kmb_dsi_host_unregister().
Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
Signed-off-by: Dan Carpenter
---
v2: write a better commit message
On Fri, Nov 20, 2020 at 01:29:45AM +, Chrisanthus, Anitha wrote:
> Hi Dan,
>
> > -Original Message-
> > From: Dan Carpenter
> > Sent: Monday, November 16, 2020 11:21 PM
> > To: Chrisanthus, Anitha
> > Cc: Dea, Edmund J ; David Airlie ;
> > Daniel Vetter ; Sam Ravnborg ; dri-
> >
Hi David
Am 18.11.20 um 23:01 schrieb David Laight:
From: Thomas Zimmermann
Sent: 18 November 2020 19:37
Hi
Am 18.11.20 um 19:10 schrieb Linus Torvalds:
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
I've got the 'splat' below during boot.
This is an 8-core C2758 Atom cpu using the
Am 20.11.20 um 07:49 schrieb Tian Tao:
fixed the following warnings
drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ‘dev’
set but not used
101 - 167 of 167 matches
Mail list logo
