From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [regression] HDMI breakage just before poweroff Date: Sat, 16 Jun 2018 11:35:06 +0100 Message-ID: <8636xn81et.wl-marc.zyngier@arm.com> References: <5AEA873A.7080701@rock-chips.com> <0284fa4f-abd6-26f6-31e2-1a6d24777733@arm.com> <5B1F4375.7000000@rock-chips.com> <77e4c6e1-015f-5fac-66b6-c942bb2dc9d8@arm.com> <5B1F9FF7.5070203@rock-chips.com> <86efhc8dyg.wl-marc.zyngier@arm.com> <5B20F5F0.9090101@rock-chips.com> <7ce78e65-51b6-9204-5bb4-e515e36576d4@arm.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Vicente Bergas Cc: Heiko =?UTF-8?B?U3TDvGJu?= =?UTF-8?B?ZXI=?= , JeffyChen , Sandy Huang , Tomasz Figa , "open list:ARM/Rockchip SoC..." , Klaus Goger , Sean Paul , Robin Murphy , Jakob Unterwurzacher List-Id: linux-rockchip.vger.kernel.org On Fri, 15 Jun 2018 19:46:50 +0100, Vicente Bergas wrote: > > On Fri, Jun 15, 2018 at 6:51 PM, Marc Zyngier wrote: > > On 15/06/18 17:39, Vicente Bergas wrote: > >> On Wed, Jun 13, 2018 at 12:46 PM, JeffyChen wrote: > >>> Hi Marc & Vicente, > >>> > >>> On 06/13/2018 06:26 PM, Marc Zyngier wrote: [...] > >> I can confirm that rockchip_drm_platform_shutdown works as fine as > >> rockchip_drm_platform_remove. > >> Just a note: The first time I noticed this error was because it > >> appeared on display, now that the display is off, are we sure the > >> error is fixed? > >> Also, could there be other peripherals that need to be powered off > >> before the iommu? > >> For curiosity: why is the iommu disabled before kexec instead of > >> resetting it after kexec? > > > > Because by the time you're in the new kernel, you've corrupted the page > > tables, accessed peripheral address space, and set the system on fire. > > > > In general, having a DMA master active across something like kexec is a > > pretty fatal issue. And when your boot loader is a Linux kernel using > > kexec, you're really insisting that kexec works correctly. > > Is it feasible to place the display memory at a virtual address that > matches the physical address? That depends on the addressing capability of the end-point, and on the kernel ability to allocate a large, contiguous range of physical memory. I'm not sure it is worth the hassle just to get the display working all the way through shutdown (knowing that the most likely event after that is a power off). M. -- Jazz is not dead, it just smell funny.