On Fri, 19 Apr 2024 09:39:09 +0200,
Harshit Mogalapalli wrote:
>
> Hi Takashi,
>
> On 19/04/24 12:14, Takashi Iwai wrote:
> > On Thu, 18 Apr 2024 21:29:57 +0200,
> > Helge Deller wrote:
> >>
> >> On 4/18/24 16:26, Takashi Iwai wrote:
> >>> O
On Thu, 18 Apr 2024 21:29:57 +0200,
Helge Deller wrote:
>
> On 4/18/24 16:26, Takashi Iwai wrote:
> > On Thu, 18 Apr 2024 16:06:52 +0200,
> > Nam Cao wrote:
> >>
> >> On 2024-04-18 Harshit Mogalapalli wrote:
> >>> While fuzzing 5.15.y kernel with S
On Thu, 18 Apr 2024 16:06:52 +0200,
Nam Cao wrote:
>
> On 2024-04-18 Harshit Mogalapalli wrote:
> > While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> > bug in fb_deferred_io_work()
>
> Which framebuffer device are you using exactly? It is possible that
> the problem is
On Fri, 25 Aug 2023 08:27:11 +0200,
Sui Jingfeng wrote:
>
> From: Sui Jingfeng
>
> Should be no functional change
>
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Fred Oh
> Cc: Pierre-Louis Bossart
> Cc: Kai Vehmanen
> Cc: Bjorn Helgaas
> Signed-off-
On Wed, 16 Aug 2023 12:14:24 +0200,
Borislav Petkov wrote:
>
> On Wed, Aug 16, 2023 at 12:11:57PM +0200, Borislav Petkov wrote:
> > Does that help?
>
> Btw, note that this is *plain* -rc5, without your patch.
The UAF looks very same as I had and that's the bug Karol's patch
should address. So
On Mon, 14 Aug 2023 17:06:02 +0200,
Takashi Iwai wrote:
>
> On Mon, 14 Aug 2023 16:51:08 +0200,
> Karol Herbst wrote:
> >
> > I've sent a patch out to address this memory corruption
> > https://patchwork.freedesktop.org/patch/552642/
> >
> > It
On Mon, 14 Aug 2023 16:51:08 +0200,
Karol Herbst wrote:
>
> I've sent a patch out to address this memory corruption
> https://patchwork.freedesktop.org/patch/552642/
>
> It might or might not fix regressions from the original I2C fix, so
> please test and report if there are remaining issues.
On Mon, 14 Aug 2023 15:19:11 +0200,
Karol Herbst wrote:
>
> On Mon, Aug 14, 2023 at 2:56 PM Karol Herbst wrote:
> >
> > On Mon, Aug 14, 2023 at 2:48 PM Takashi Iwai wrote:
> > >
> > > On Mon, 14 Aug 2023 14:38:18 +0200,
> > > Karol Herbst wrote:
&
On Mon, 14 Aug 2023 14:38:18 +0200,
Karol Herbst wrote:
>
> On Wed, Aug 9, 2023 at 6:16 PM Takashi Iwai wrote:
> >
> > On Wed, 09 Aug 2023 16:46:38 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 09 Aug 2023 15:13:23 +0200,
> > > Takashi Iw
On Wed, 09 Aug 2023 16:46:38 +0200,
Takashi Iwai wrote:
>
> On Wed, 09 Aug 2023 15:13:23 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 09 Aug 2023 14:19:23 +0200,
> > Karol Herbst wrote:
> > >
> > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote:
On Wed, 09 Aug 2023 15:13:23 +0200,
Takashi Iwai wrote:
>
> On Wed, 09 Aug 2023 14:19:23 +0200,
> Karol Herbst wrote:
> >
> > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote:
> > >
> > > On Wed, 09 Aug 2023 13:42:09 +0200,
> > > Karol Herbst wro
On Wed, 09 Aug 2023 14:19:23 +0200,
Karol Herbst wrote:
>
> On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote:
> >
> > On Wed, 09 Aug 2023 13:42:09 +0200,
> > Karol Herbst wrote:
> > >
> > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai wrote:
> >
On Wed, 09 Aug 2023 13:42:09 +0200,
Karol Herbst wrote:
>
> On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai wrote:
> >
> > On Tue, 08 Aug 2023 12:39:32 +0200,
> > Karol Herbst wrote:
> > >
> > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov wrote:
>
On Tue, 08 Aug 2023 12:39:32 +0200,
Karol Herbst wrote:
>
> On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov wrote:
> >
> > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote:
> > > in what way does it stop? Just not progressing? That would be kinda
> > > concerning. Mind tracing with
On Wed, 05 Jul 2023 14:17:20 +0200,
Alex Deucher wrote:
>
> On Wed, Jul 5, 2023 at 2:26 AM Takashi Iwai wrote:
> >
> > Hi Dave, Alex,
> >
> > it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
> > due to the missing signed tag:
> >
Hi Dave, Alex,
it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
due to the missing signed tag:
https://lore.kernel.org/lkml/CAHk-=wiOCgiwzVPOwORHPML9eBphnbtM2DhRcv+v=-tnrrg...@mail.gmail.com/
And more importantly, this series isn't seen on linux-next, either; so
the whole
tely, it's just harmless dead code which can be removed. It's
> left over from commit c5c354a3a472 ("drm/udl: Fix inconsistent urbs.count
> value during udl_free_urb_list()").
>
> Reported-by: kernel test robot
> Signed-off-by: Dan Carpenter
Reviewed-by: Takashi Iwai
thanks,
Takashi
On Sat, 18 Mar 2023 17:49:28 +0100,
Hans de Goede wrote:
>
> Hi Takashi,
>
> On 3/17/23 11:04, Takashi Iwai wrote:
> > Hi,
> >
> > we've received a regression report on openSUSE Bugzilla about the
> > missing backlight control of nouveau device:
> >
Hi,
we've received a regression report on openSUSE Bugzilla about the
missing backlight control of nouveau device:
https://bugzilla.opensuse.org/show_bug.cgi?id=1209296
On 6.1, with acpi_video=native option, the system provided
/sys/class/backlight/nv_backlight entry.
On 6.2, with
ed.
Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O
devices")
Cc:
Signed-off-by: Takashi Iwai
---
v1->v2:
* Rename to fb_deferred_io_lastclose()
* Rename the new field from opens to open_count
* Removed unused variable
* More comments about fb_info
On Wed, 08 Mar 2023 10:08:24 +0100,
Patrik Jakobsson wrote:
>
> On Wed, Mar 8, 2023 at 7:36 AM Takashi Iwai wrote:
> >
> > The recent fix for the deferred I/O by the commit
> > 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O
> > dev
iple opens.
This patch adds a refcount for the opens of the device, and applies
the cleanup only when all files get closed.
Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O
devices")
Cc:
Signed-off-by: Takashi Iwai
---
drivers/video/fbdev/
On Mon, 30 Jan 2023 09:52:43 +0100,
Takashi Iwai wrote:
>
> > There's a call to cancel_delayed_work_sync() in the new helper
> > fb_deferred_io_release(). Is this the right function? Maybe
> > flush_delayed_work() is a better choice.
>
> I thought of that, but took
On Mon, 30 Jan 2023 10:28:16 +0100,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.01.23 um 09:52 schrieb Takashi Iwai:
> > On Mon, 30 Jan 2023 09:28:36 +0100,
> > Thomas Zimmermann wrote:
> >>
> >> Hi
> >>
> >> Am 29.01.23 um 09:28 schrie
On Mon, 30 Jan 2023 09:28:36 +0100,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 29.01.23 um 09:28 schrieb Takashi Iwai:
> > When a fbdev with deferred I/O is once opened and closed, the dirty
> > pages still remain queued in the pageref list, and eventually later
&g
up the
pageref list at closing the device for addressing the bug. A part of
the cleanup code is factored out as a new helper function that is
called from the common fb_release().
Reviewed-by: Patrik Jakobsson
Cc:
Signed-off-by: Takashi Iwai
---
v1->v2: Fix build error with
On Sat, 28 Jan 2023 03:17:15 +0100,
Danilo Krummrich wrote:
>
> On Fri, Jan 27, 2023 at 01:10:46PM +0100, Takashi Iwai wrote:
> > On Tue, 03 Jan 2023 15:07:55 +0100,
> > Takashi Iwai wrote:
> > >
> > > On Fri, 30 Dec 2022 08:27:58 +0100,
> >
up the
pageref list at closing the device for addressing the bug. A part of
the cleanup code is factored out as a new helper function that is
called from the common fb_release().
Cc:
Signed-off-by: Takashi Iwai
---
drivers/video/fbdev/core/fb_defio.c | 10 +-
drivers/video/fbdev/core
On Tue, 03 Jan 2023 15:07:55 +0100,
Takashi Iwai wrote:
>
> On Fri, 30 Dec 2022 08:27:58 +0100,
> Zheng Wang wrote:
> >
> > Here is a function call chain.
> > nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> > If nvkm_vma_
On Fri, 13 Jan 2023 07:23:21 +0100,
Christoph Hellwig wrote:
>
> Now that arch/sh is removed these drivers are dead code.
>
> Signed-off-by: Christoph Hellwig
Supposed you take in your tree:
Acked-by: Takashi Iwai
thanks,
Takashi
> ---
> sound/Kconfig | 2 -
On Fri, 30 Dec 2022 08:27:58 +0100,
Zheng Wang wrote:
>
> Here is a function call chain.
> nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> will free
/-/issues/2236
Signed-off-by: Takashi Iwai
---
Note: this is the additional fix on top of the previously submitted
audio component support for radeon.
drivers/gpu/drm/radeon/radeon_audio.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon
that protects just the bind/unbind
and the notify calls and replaces the drm_modeset_lock with it.
Fixes: 34d84636e5e0 ("drm/radeon: Add HD-audio component notifier support (v4)")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1569
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/radeo
lied on older kernels.
v4: revive drm_modeset_lock*() again, add the missing
device_link_remove() call at unbinding ]
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1569
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/radeon/radeon.h
On Mon, 12 Sep 2022 09:06:47 +0200,
Thomas Zimmermann wrote:
>
> Hi,
>
> I've meanwhile merged the patchset, including the one updated patch
> and the missing r-b.
Great, thanks!
Takashi
On Thu, 08 Sep 2022 14:47:52 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 08.09.22 um 11:51 schrieb Takashi Iwai:
> > Just for some code simplification.
> >
> > Suggested-by: Thomas Zimmermann
> > Signed-off-by: Takashi Iwai
>
> With my comment
-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 28 +
drivers/gpu/drm/udl/udl_transfer.c | 40 --
2 files changed, 1 insertion(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers
a problem.
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 8 +++-
drivers/gpu/drm/udl/udl_drv.h | 2 +-
drivers/gpu/drm/udl/udl_main.c| 6 ++
drivers/gpu/drm/udl/udl_modeset.c | 2 --
4 files changed, 10 insertions(+), 8 deletions
The driver may receive -EPROTO at the URB completion when the device
gets disconnected, and it's a normal situation. Suppress the error
print for that, too.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl
Just for some code simplification.
Suggested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
at extracting a URB from the list in
udl_free_url_list().
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 8 +--
drivers/gpu/drm/udl/udl_main.c | 42 +++---
2 files changed, 30 insertions(+), 20 deletions(-)
diff --git
udl_alloc_urb_list() retires the allocation if there is no enough room
left, and it reinitializes the stuff unnecessarily such as the linked
list head and the waitqueue, which could be harmful. Those should be
outside the retry loop.
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
A couple of error handlings forgot to process the URB completion.
Those are both with WARN_ON() so should be visible, but we must fix
them in anyway.
Fixes: 7350b2a3fbc6 ("drm/udl: Replace BUG_ON() with WARN_ON()")
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/g
From: Thomas Zimmermann
Call drm_plane_enable_fb_damage_clips() and give userspace a chance
of minimizing the updated display area.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
It seems that the current size (4) for the URB list is too small on
some devices, and it resulted in the occasional stalls. Increase the
default URB list size to 20 for working around it.
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 2 +-
1 file
eck entirely instead, per Daniel's
suggestion ]
Fixes: 997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable
functions")
Cc:
Signed-off-by: Thomas Zimmermann
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Takashi Iwai
---
driver
This reverts the recent fix commit
e25d5954264d ("drm/udl: Kill pending URBs at suspend and disconnect")
as it turned out to lead to potential hangup at a disconnection, and
it doesn't help much for suspend/resume problem, either.
Acked-by: Thomas Zimmermann
Signed-off-by: Ta
From: Thomas Zimmermann
Implement the reset_resume callback of struct usb_driver. Set the
standard channel when called.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 11 +++
drivers/gpu/drm/udl/udl_drv.h
Thomas
- Drop numurbs parameter patch
- Clean up / simplify clipping patch
- Code cleanup and changes for urb management patch
- Put Acks on some given patches
===
Takashi Iwai (10):
drm/udl: Restore display mode on resume
Revert "drm/udl: Kill pending URBs at suspend and disconnect
On Wed, 07 Sep 2022 09:29:37 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 06.09.22 um 09:39 schrieb Takashi Iwai:
> > The alignment of damaged area was needed for the original udlfb driver
> > that tried to trim the superfluous copies between front and backend
>
On Tue, 06 Sep 2022 22:06:55 +0200,
Daniel Vetter wrote:
>
> On Tue, Aug 16, 2022 at 05:36:44PM +0200, Takashi Iwai wrote:
> > From: Thomas Zimmermann
> >
> > Restore the display mode whne resuming from suspend. Currently, the
> > display remains dark.
> >
A couple of error handlings forgot to process the URB completion.
Those are both with WARN_ON() so should be visible, but we must fix
them in anyway.
Fixes: 7350b2a3fbc6 ("drm/udl: Replace BUG_ON() with WARN_ON()")
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/g
The driver may receive -EPROTO at the URB completion when the device
gets disconnected, and it's a normal situation. Suppress the error
print for that, too.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl
at extracting a URB from the list in
udl_free_url_list().
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 8 +--
drivers/gpu/drm/udl/udl_main.c | 44 +++---
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b
-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 28 +
drivers/gpu/drm/udl/udl_transfer.c | 40 --
2 files changed, 1 insertion(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index
udl_alloc_urb_list() retires the allocation if there is no enough room
left, and it reinitializes the stuff unnecessarily such as the linked
list head and the waitqueue, which could be harmful. Those should be
outside the retry loop.
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
It seems that the current size (4) for the URB list is too small on
some devices, and it resulted in the occasional stalls. Increase the
default URB list size to 20 for working around it.
Acked-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 2 +-
1 file
a problem.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 8 +++-
drivers/gpu/drm/udl/udl_drv.h | 2 +-
drivers/gpu/drm/udl/udl_main.c| 6 ++
drivers/gpu/drm/udl/udl_modeset.c | 2 --
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm
From: Thomas Zimmermann
Call drm_plane_enable_fb_damage_clips() and give userspace a chance
of minimizing the updated display area.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
This reverts the recent fix commit
e25d5954264d ("drm/udl: Kill pending URBs at suspend and disconnect")
as it turned out to lead to potential hangup at a disconnection, and
it doesn't help much for suspend/resume problem, either.
Acked-by: Thomas Zimmermann
Signed-off-by: Ta
tch
- Clean up / simplify clipping patch
- Code cleanup and changes for urb management patch
- Put Acks on some given patches
===
Takashi Iwai (8):
Revert "drm/udl: Kill pending URBs at suspend and disconnect"
drm/udl: Suppress error print for -EPROTO at URB completion
drm/udl: Increas
From: Thomas Zimmermann
Implement the reset_resume callback of struct usb_driver. Set the
standard channel when called.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 11 +++
drivers/gpu/drm/udl/udl_drv.h | 1 +
drivers/gpu/drm/udl
is reproducable by using Gnome with udl and observing the
adapter's suspend/resume behavior.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b
On Mon, 05 Sep 2022 10:44:25 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 16.08.22 um 17:36 schrieb Takashi Iwai:
> > It's better to perform the sync at the very last of the suspend
> > instead of the pipe-disable function, so that we can catch all pending
> >
On Mon, 05 Sep 2022 10:32:55 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 16.08.22 um 17:36 schrieb Takashi Iwai:
> > In the current design, udl_get_urb() may be called asynchronously
> > during the driver freeing its URL list via udl_free_urb_list().
> >
On Mon, 05 Sep 2022 10:40:58 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 16.08.22 um 17:36 schrieb Takashi Iwai:
> > The alignment of damaged area was needed for the original udlfb driver
> > that tried to trim the superfluous copies between front and backend
>
This reverts the recent fix commit
e25d5954264d ("drm/udl: Kill pending URBs at suspend and disconnect")
as it turned out to lead to potential hangup at a disconnection, and
it doesn't help much for suspend/resume problem, either.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl
o: https://syzkaller.appspot.com/x/repro.syz?x=1273186708
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=165b64f308
>
> The issue was bisected to:
>
> commit e25d5954264d1871ab2792c7ca2298b811462500
> Author: Takashi Iwai
> Date: Thu Aug 4 07:58:
a problem.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 8 +++-
drivers/gpu/drm/udl/udl_drv.h | 2 +-
drivers/gpu/drm/udl/udl_main.c| 6 ++
drivers/gpu/drm/udl/udl_modeset.c | 2 --
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm
From: Thomas Zimmermann
For further debugging and optimization purpose, allow users to adjust
the number of URBs via a new module parameter, numurbs.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 9 -
1 file changed, 8 insertions
A couple of error handlings forgot to process the URB completion.
Those are both with WARN_ON() so should be visible, but we must fix
them in anyway.
Fixes: 7350b2a3fbc6 ("drm/udl: Replace BUG_ON() with WARN_ON()")
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main
-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 34 ++---
drivers/gpu/drm/udl/udl_transfer.c | 40 --
2 files changed, 8 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
It seems that the current size (4) for the URB list is too small on
some devices, and it resulted in the occasional stalls. Increase the
default URB list size to 20 for working around it.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 2 +-
1 file changed, 1 insertion(+), 1
The driver may receive -EPROTO at the URB completion when the device
gets disconnected, and it's a normal situation. Suppress the error
print for that, too.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl
at extracting a URB from the list in
udl_free_url_list().
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 8 +---
drivers/gpu/drm/udl/udl_main.c | 37 --
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b
udl_alloc_urb_list() retires the allocation if there is no enough room
left, and it reinitializes the stuff unnecessarily such as the linked
list head and the waitqueue, which could be harmful. Those should be
outside the retry loop.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl
is reproducable by using Gnome with udl and observing the
adapter's suspend/resume behavior.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b
From: Thomas Zimmermann
Call drm_plane_enable_fb_damage_clips() and give userspace a chance
of minimizing the updated display area.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
From: Thomas Zimmermann
Implement the reset_resume callback of struct usb_driver. Set the
standard channel when called.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 11 +++
drivers/gpu/drm/udl/udl_drv.h | 1 +
drivers/gpu/drm/udl
/20220804075826.27036-1-ti...@suse.de
===
Takashi Iwai (8):
Revert "drm/udl: Kill pending URBs at suspend and disconnect"
drm/udl: Suppress error print for -EPROTO at URB completion
drm/udl: Increase the default URB list size to 20
drm/udl: Drop unneeded alignment
drm/udl: Fix potential URB leaks
On Tue, 16 Aug 2022 16:01:34 +0200,
Thomas Zimmermann wrote:
>
> Hi Takashi
>
> Am 16.08.22 um 15:55 schrieb Takashi Iwai:
> > On Tue, 09 Aug 2022 11:19:30 +0200,
> > Takashi Iwai wrote:
> >>
> >> On Tue, 09 Aug 2022 11:13:46 +0200,
> >> Thoma
On Tue, 09 Aug 2022 11:19:30 +0200,
Takashi Iwai wrote:
>
> On Tue, 09 Aug 2022 11:13:46 +0200,
> Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 09.08.22 um 11:03 schrieb Takashi Iwai:
> > > On Tue, 09 Aug 2022 09:41:19 +0200,
> > > Thomas Zi
On Tue, 09 Aug 2022 11:13:46 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.08.22 um 11:03 schrieb Takashi Iwai:
> > On Tue, 09 Aug 2022 09:41:19 +0200,
> > Thomas Zimmermann wrote:
> >>
> >> Hi
> >>
> >> Am 09.08.22 um 09:15 sc
On Tue, 09 Aug 2022 09:41:19 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.08.22 um 09:15 schrieb Takashi Iwai:
> > On Tue, 09 Aug 2022 09:13:16 +0200,
> > Thomas Zimmermann wrote:
> >>
> >> Hi
> >>
> >> Am 04.08.22 um 09:58 sc
On Tue, 09 Aug 2022 09:13:16 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.08.22 um 09:58 schrieb Takashi Iwai:
> > At both suspend and disconnect, we should rather cancel the pending
> > URBs immediately. For the suspend case, the display will be turned
>
BUG_ON() is a tasteless choice as a sanity check for a driver like UDL
that isn't really a core code. Replace with WARN_ON() and proper
error handling instead.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 3 ++-
drivers/gpu/drm/udl
We need to wait for finishing to process the all URBs after disabling
the pipe; otherwise pending URBs may stray at suspend/resume, leading
to a possible memory corruption in a worst case.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 1
for delayed semaphore down,
too.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 11 +++--
drivers/gpu/drm/udl/udl_main.c | 84 ++
2 files changed, 31 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/udl
Hi,
this is a series of fixes for UDL driver to address the leftover URBs
at suspend/resume. It begins with the simplification of FIFO control
code with the standard wait queue, followed by the handling of pending
URBs, and replace BUG_ON() with WARN_ON() as a cleanup.
Takashi
===
Takashi
.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 2 ++
drivers/gpu/drm/udl/udl_main.c| 25 ++---
drivers/gpu/drm/udl/udl_modeset.c | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl
On Wed, 27 Jul 2022 09:41:52 +0200,
Matthieu CHARETTE wrote:
>
> Loading an EDID using drm.edid_firmware parameter makes resume to fail
> after firmware cache is being cleaned. This is because edid_load() use a
> temporary device to request the firmware. This cause the EDID firmware
> not to be
te to the game (just back from vacation), but FWIW:
Reviewed-by: Takashi Iwai
thanks,
Takashi
On Thu, 24 Feb 2022 17:34:54 +0100,
Kai Vehmanen wrote:
>
> Hi,
>
> On Thu, 24 Feb 2022, Ramalingam C wrote:
>
> > Split the wait for component binding from i915 in multiples of
> > sysctl_hung_task_timeout_secs. This helps to avoid the possible kworker
> > thread hung detection given below.
>
oslav Kysela
> Cc: Takashi Iwai
> Cc: Kai Vehmanen
> Cc: Daniel Vetter
> Cc: "Rafael J. Wysocki"
> Cc: Rob Clark
> Cc: Russell King
> Cc: Saravana Kannan
> Signed-off-by: Stephen Boyd
The patch looks good, but just a minor concern:
> +static struct ag
On Wed, 22 Sep 2021 10:54:32 +0200,
Kai Vehmanen wrote:
(snip)
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -246,7 +246,7 @@ static int try_to_bring_up_master(struct master *master,
> return 0;
> }
>
> - if (!devres_open_group(master->parent,
On Mon, 31 May 2021 11:42:13 +0200,
Maxime Ripard wrote:
>
> Hi Mark, Takashi,
>
> On Wed, May 26, 2021 at 11:39:21AM +0100, Mark Brown wrote:
> > On Tue, May 25, 2021 at 03:23:47PM +0200, Maxime Ripard wrote:
> > > The IEC958 status bit is usually set by the userspace after hw_params
> > > has
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Takashi Iwai
thanks,
Takashi
> ---
> include/sound/pcm_iec958.h | 8 ++
> sound/core/pcm_iec958.c| 176 -
> 2 files changed, 141 insertions(+), 43 deletions(-)
>
> diff --git a/includ
t; separate ifaces, and it looks like the drivers that currently expose
> those controls use any combination of the mixer and PCM ifaces.
>
> Let's try to clarify the situation a bit, and encourage to at least have
> the controls on the same iface.
>
> Signed-off-by: Maxime Ripard
On Tue, 25 May 2021 11:23:53 +0200,
Maxime Ripard wrote:
>
> Hi Takashi,
>
> On Tue, May 25, 2021 at 10:35:14AM +0200, Takashi Iwai wrote:
> > On Mon, 24 May 2021 15:39:04 +0200,
> > Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > O
On Mon, 24 May 2021 15:39:04 +0200,
Maxime Ripard wrote:
>
> Hi,
>
> On Fri, May 07, 2021 at 04:03:23PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > hdmi-codec allows to have a lot of HDMI-audio related infrastructure in
> > place,
> > it's missing a few controls to be able to provide HBR
1 - 100 of 610 matches
Mail list logo
