From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic Date: Fri, 30 Apr 2010 14:16:22 -0700 Message-ID: <874oisiqu1.fsf@deeprootsystems.com> References: <20100126200646.15382.52167.stgit@baageli.muru.com> <20100126201239.15382.34792.stgit@baageli.muru.com> <1272640022.3051.1534.camel@localhost> <4BDB0353.5090800@ti.com> <20100430171802.GB1639@n2100.arm.linux.org.uk> <20100430184712.GF29604@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-iw0-f202.google.com ([209.85.223.202]:58915 "EHLO mail-iw0-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757489Ab0D3VQ0 (ORCPT ); Fri, 30 Apr 2010 17:16:26 -0400 Received: by iwn40 with SMTP id 40so779307iwn.1 for ; Fri, 30 Apr 2010 14:16:25 -0700 (PDT) In-Reply-To: <20100430184712.GF29604@atomide.com> (Tony Lindgren's message of "Fri\, 30 Apr 2010 11\:47\:12 -0700") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Russell King - ARM Linux , Cyril Chemparathy , DaVinci list , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Tony Lindgren writes: > * Russell King - ARM Linux [100430 10:13]: >> On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote: >> > Hi, >> > >> > [...] >> > > To fix both problems, maybe we should just use a fixed memory location >> > > to pass this temporary data from uncompress to the kernel. We've had a >> > > similar problem on DaVinci recently and a proposal has been made (and >> > > tested) to use memory just below the page tables[3].) >> > >> > Essentially both of these approaches (internal scratch register and >> > fixed address) implement a weird back-channel communication scheme >> > between the decompresser and the debug macros. >> > >> > A more elegant solution may be as follows: >> > - pass machine_arch_type as an argument into addruart. >> >> Unfortunately, that breaks addruart. Firstly, addruart is used from >> assembly code where very limited registers are available (the fewer >> registers it clobbers the less likely debug is going to cause stuff >> to break.) > > Right, this would be tricky. > >> Secondly, the places that addruart may be called from, the location >> of the machine type number is indeterminent. Remember that this >> macro can be called when the MMU is on or off, and can be called >> before the machine_arch_type has been initialized. > > Another good point here. > >> > - move the uart base lookup logic to addruart using macros similar >> > to DEBUG_LL_*, except that these expand to assembly code this >> > time. >> > - reuse these debug-macros in uncompress.h and implement putc() and >> > flush() using addruart(), senduart(), etc. >> >> Given what I've said above about the debug macros, this is definitely the >> wrong solution. >> >> Having the decompressor macros work whatever the machine type is >> reasonable, and the machine_is_xxx() macros already work at that point, >> so there shouldn't be much of an issue there. > > Just to bring it up, there's one issue to consider here though. > When the bootloader passes a wrong machine id, chances are things > break with no debug output. > >> As far as the debug macros go, I think we're at the point where it's >> basically just far easier to leave these macros as a developer debugging >> tool and we'll just have to put up with it being something that an OMAP >> developer has to edit according to his platform to make work. >> >> After all, _NO_ production kernel what so ever should be using this >> debug support. > > Things work now for mach-omap2, but we assume the first uart is always > in the same location. If this changes, then using some fixed memory > location for storing the debug configuration is probably the best way > to go considering the issues Russell mentioned. I agree, using a fixed memory location seems the best way to keep this working across new devices with different UART1 base. Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@deeprootsystems.com (Kevin Hilman) Date: Fri, 30 Apr 2010 14:16:22 -0700 Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic In-Reply-To: <20100430184712.GF29604@atomide.com> (Tony Lindgren's message of "Fri\, 30 Apr 2010 11\:47\:12 -0700") References: <20100126200646.15382.52167.stgit@baageli.muru.com> <20100126201239.15382.34792.stgit@baageli.muru.com> <1272640022.3051.1534.camel@localhost> <4BDB0353.5090800@ti.com> <20100430171802.GB1639@n2100.arm.linux.org.uk> <20100430184712.GF29604@atomide.com> Message-ID: <874oisiqu1.fsf@deeprootsystems.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Tony Lindgren writes: > * Russell King - ARM Linux [100430 10:13]: >> On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote: >> > Hi, >> > >> > [...] >> > > To fix both problems, maybe we should just use a fixed memory location >> > > to pass this temporary data from uncompress to the kernel. We've had a >> > > similar problem on DaVinci recently and a proposal has been made (and >> > > tested) to use memory just below the page tables[3].) >> > >> > Essentially both of these approaches (internal scratch register and >> > fixed address) implement a weird back-channel communication scheme >> > between the decompresser and the debug macros. >> > >> > A more elegant solution may be as follows: >> > - pass machine_arch_type as an argument into addruart. >> >> Unfortunately, that breaks addruart. Firstly, addruart is used from >> assembly code where very limited registers are available (the fewer >> registers it clobbers the less likely debug is going to cause stuff >> to break.) > > Right, this would be tricky. > >> Secondly, the places that addruart may be called from, the location >> of the machine type number is indeterminent. Remember that this >> macro can be called when the MMU is on or off, and can be called >> before the machine_arch_type has been initialized. > > Another good point here. > >> > - move the uart base lookup logic to addruart using macros similar >> > to DEBUG_LL_*, except that these expand to assembly code this >> > time. >> > - reuse these debug-macros in uncompress.h and implement putc() and >> > flush() using addruart(), senduart(), etc. >> >> Given what I've said above about the debug macros, this is definitely the >> wrong solution. >> >> Having the decompressor macros work whatever the machine type is >> reasonable, and the machine_is_xxx() macros already work at that point, >> so there shouldn't be much of an issue there. > > Just to bring it up, there's one issue to consider here though. > When the bootloader passes a wrong machine id, chances are things > break with no debug output. > >> As far as the debug macros go, I think we're at the point where it's >> basically just far easier to leave these macros as a developer debugging >> tool and we'll just have to put up with it being something that an OMAP >> developer has to edit according to his platform to make work. >> >> After all, _NO_ production kernel what so ever should be using this >> debug support. > > Things work now for mach-omap2, but we assume the first uart is always > in the same location. If this changes, then using some fixed memory > location for storing the debug configuration is probably the best way > to go considering the issues Russell mentioned. I agree, using a fixed memory location seems the best way to keep this working across new devices with different UART1 base. Kevin