Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755274AbbF0R42 (ORCPT ); Sat, 27 Jun 2015 13:56:28 -0400 Received: from mail-oi0-f52.google.com ([209.85.218.52]:34658 "EHLO mail-oi0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751931AbbF0R4U (ORCPT ); Sat, 27 Jun 2015 13:56:20 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56c9:0:22cf:30ff:fe4c:37d6] In-Reply-To: <20150627141237.GE26543@pd.tnic> References: <1435305314-14337-1-git-send-email-rui.y.wang@intel.com> <3908561D78D1C84285E8C5FCA982C28F32AA062A@ORSMSX114.amr.corp.intel.com> <20150627141237.GE26543@pd.tnic> Date: Sat, 27 Jun 2015 19:56:19 +0200 Message-ID: Subject: Re: drm/mgag200: doesn't work in panic context From: Daniel Vetter To: Borislav Petkov Cc: "Luck, Tony" , "Wang, Rui Y" , Dave Airlie , "Clark, Rob" , "Roper, Matthew D" , "Chen, Gong" , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2771 Lines: 54 On Sat, Jun 27, 2015 at 4:12 PM, Borislav Petkov wrote: > On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote: >> Hm, what do you mean by fixing this in the allocator? I've made some >> rough sketch of the problem space in >> http://www.x.org/wiki/DRMJanitors/ under "Make panic handling work". >> Problem is that the folks which know what to do (drm hackers) have >> zero incentive to fix it (since if you blow up a drm driver any kind >> of fbcon panic handling is hopeless anyway). > > Ok, silly question: switching the GPU output to the simplest, > supported-by-all-GPUs mode before panicking is not that easy too, right? Anything that resembles doing a modeset (and the precise mode is totally irrelevant) will be almost impossible: There's clocks to tune, various links to train, a bunch of sidebind communication and all that takes time, needs to happen in a very precise order and also needs lots of mutexes (crossing subsystems sometimes even) to avoid trampling on maybe the thread that just died and caused the panic. In short you need specially-written codepaths for panic, which means only the most minimal thing has a chance to even work. fbdev/fbcon and the current drm panic handler are anything but that. Doing a full modeset isn't it either. Heck even the just updating the displayed buffer might need massive reconfiguration of the memory fetch watermarks if e.g. the screen is display high bpc yuv and you want to display the rgb fbcon buffer. And if you'd just try to take what's currently being displayed there's the annoying problem that often providing a cpu-contiguous view of that needs a vmalloc area, if not first moving the buffer around a bit in vram with the copy engine. That all involves lots of really complex code. > Or does that mean, one needs to reinit GPU in order to even show > something... If the gpu is runtime suspended, then yes you'd get to even init the entire thing first before you can display anything. fbdev panic handling was designed for a world where you'd bash a few values into a few registers and never wait for the CRTC to reach stable timings and output a useful signal. Which could all happen very much after the kernel made it's dying sigh. Display hw has long stopped being this simple and display drivers also. The only vestige is that we still call the display pipeline object in drm CRTC for cathode ray tube controller ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/