similar to: [Bug 71824] [HSW mobile Regression]System booting with Call Trace

https://bugs.freedesktop.org/show_bug.cgi?id=71824 Daniel Vetter <daniel at ffwll.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|intel-gfx-bugs at lists.freede |nouveau at lists.freedesktop.o |sktop.org |rg QA

https://bugs.freedesktop.org/show_bug.cgi?id=71824 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[HSW mobile |[NVE6] NULL deref on boot |Regression]System booting |when there is nothing in

On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote: > On 2017-07-05 08:08, Daniel Vetter wrote: > > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: > >> Hi! > >> > >> While trying to get CLUT support for the atmel_hlcdc driver, and > >> specifically for the emulated fbdev interface, I received some > >> push-back that my

On 2017-07-05 08:08, Daniel Vetter wrote: > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: >> Hi! >> >> While trying to get CLUT support for the atmel_hlcdc driver, and >> specifically for the emulated fbdev interface, I received some >> push-back that my feeble in-driver attempts should be solved >> by the core. This is my attempt to do it

On 2017-07-05 08:08, Daniel Vetter wrote: > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: >> Hi! >> >> While trying to get CLUT support for the atmel_hlcdc driver, and >> specifically for the emulated fbdev interface, I received some >> push-back that my feeble in-driver attempts should be solved >> by the core. This is my attempt to do it

On 2017-07-05 08:08, Daniel Vetter wrote: > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: >> Hi! >> >> While trying to get CLUT support for the atmel_hlcdc driver, and >> specifically for the emulated fbdev interface, I received some >> push-back that my feeble in-driver attempts should be solved >> by the core. This is my attempt to do it

On Wed, 30 Sep 2020 at 19:37, Daniel Vetter <daniel at ffwll.ch> wrote: > > On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote: > > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > > > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > > > > > >

On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote: > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > > > > Ben, did you have a chance to look at this? > > > > Ping > > -Daniel > > > > >

On Thu, Sep 13, 2018 at 11:02 PM, Lyude Paul <lyude at redhat.com> wrote: > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on > the driver supporting atomic, maybe it would be good to make it so that we set > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending > on the nouveau_atomic setting + hw support. That way we can

On Wed, 30 Sep 2020 at 00:52, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > > > Ben, did you have a chance to look at this? > > Ping > -Daniel > > > On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst > > <maarten.lankhorst at linux.intel.com> wrote:

On Thu, Dec 22, 2016 at 10:36:01AM +0200, Ander Conselvan De Oliveira wrote: > On Wed, 2016-12-21 at 12:12 -0800, Dhinakaran Pandiyan wrote: > > This check is useful for drivers that do not have DRIVER_ATOMIC set but > > have atomic modesetting internally implemented. Wrap the check into a > > function since this is used in many places and as a bonus, the function > >

On Fri, Oct 26, 2018 at 04:35:48PM -0400, Lyude Paul wrote: > It occurred to me that we never actually check this! So let's start > doing that. > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> One thought on testing all this: I think long term some unti

On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > Ben, did you have a chance to look at this? Ping -Daniel > On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst > <maarten.lankhorst at linux.intel.com> wrote: > > > > Op 02-08-2020 om 20:18 schreef Daniel Vetter: > > > Purely conjecture, but I think the original locking

Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on the driver supporting atomic, maybe it would be good to make it so that we set DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending on the nouveau_atomic setting + hw support. That way we can always have the state debugfs file while maintaining nouveau's current behavior with exposing

On Thu, Jan 30, 2014 at 3:33 AM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jan 30, 2014 at 1:53 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup >> ourselves"), drm_device->irq_enabled remained unset. This is needed in >> order to properly wait for a vblank event in the

On Sun, May 26, 2013 at 5:38 PM, Gard Spreemann <gspreemann at gmail.com> wrote: > Hi, > > If I should contact a list instead of you directly, I sincerely apologize! You should have cc'ed relevant lists at least ;-) Fixed up. > After a recent kernel upgrade, I found that my system (using Nouveau) would > stutter whenever eDP-1 was turned off. That display being turned

On Wed, Oct 16, 2019 at 12:19:02PM +0900, Tomasz Figa wrote: > On Wed, Oct 9, 2019 at 12:04 AM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote: > > > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > > > > > On Sat, Oct 05, 2019 at 02:41:54PM

From: Ville Syrjälä <ville.syrjala at linux.intel.com> We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: nouveau at lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

On Thu, Nov 29, 2018 at 3:45 PM Linus Walleij <linus.walleij at linaro.org> wrote: > > On Mon, Nov 26, 2018 at 3:12 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > On Sat, Nov 24, 2018 at 10:17:13PM +0100, Linus Walleij wrote: > > > > It was especially scary. > > > > > > But I think I managed to apply the patches and push the > > >

On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On 08/22/2018 10:54 AM, Daniel Vetter wrote: > > This was only added for the drm's fbdev emulation support, so that it > > would try harder to show the Oops. > > > > Unfortunately this never really worked reliably, and in practice ended > > up pushing the real Oops off the