From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mitch Bradley Subject: Re: Request review of device tree documentation Date: Sun, 13 Jun 2010 21:45:50 -1000 Message-ID: <4C15DE2E.1050905@firmworks.com> References: <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <1276408773.1962.574.camel@pasglop> <20100614073828.GA6095@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100614073828.GA6095-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Russell King - ARM Linux Cc: Nicolas Pitre , devicetree-discuss , linuxppc-dev , microblaze-uclinux-rVRm/Wmeqae7NGdpmJTKYQ@public.gmane.org, Dan Malek , Jeremy Kerr , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org Russell King - ARM Linux wrote: > On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: > >>>> Or perhaps the MMU and caches can be turned off for the duration of the >>>> callback. >>>> I don't have the details of ARM MMUs and caches reloaded into my head >>>> yet. Maybe next week... >>>> > > We've had these kinds of questions in the past. Doing what you're asking > above is not really an option - it requires: > > 1. disable all IRQs > 2. setup 1:1 MMU mappings for code to turn off MMU > (requires new page table) > 3. disable imprecise exceptions > 4. flush caches and TLBS > 5. jump to 1:1 mapping area for code to disable MMU > 6. disable caches and mmu > 7. call function > 8. flush caches and TLBs > 9. re-enable caches and mmu > 10. re-enable imprecise exceptions > 11. switch back to original MMU mappings > 12. re-enable all IRQs > > This is fine if you don't care at all about interrupt latency. > Unfortunately, most people do care about interrupt latency because > that directly affects interactivity and system performance. The > called function could not enable interrupts or exceptions - as the > CPU vectors are in virtual space, disabling the MMU effectively > makes them disappear. > > Moreover, with the MMU and caches disabled, the CPU performance is > extremely poor, so the called function will run slowly. > > So, disabling the MMU isn't really viable. > None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. > Now, if the external code was fully PIC, we could then run it with > the MMU enabled. However, this wouldn't really help - the external > code could not access any devices without knowledge of how the kernel > setup the V:P translations. > > So you'd need to pass some kind of data structure giving locations of > devices to the called code - but then what if the kernel doesn't have > the device mapped? > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rs35.luxsci.com (rs35.luxsci.com [66.216.127.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9D99D1007FB for ; Mon, 14 Jun 2010 17:47:25 +1000 (EST) Message-ID: <4C15DE2E.1050905@firmworks.com> Date: Sun, 13 Jun 2010 21:45:50 -1000 From: Mitch Bradley MIME-Version: 1.0 To: Russell King - ARM Linux Subject: Re: Request review of device tree documentation References: <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <1276408773.1962.574.camel@pasglop> <20100614073828.GA6095@n2100.arm.linux.org.uk> In-Reply-To: <20100614073828.GA6095@n2100.arm.linux.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Nicolas Pitre , devicetree-discuss , linuxppc-dev , microblaze-uclinux@itee.uq.edu.au, Olof Johansson , Dan Malek , Jeremy Kerr , linux-arm-kernel@lists.infradead.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Russell King - ARM Linux wrote: > On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: > >>>> Or perhaps the MMU and caches can be turned off for the duration of the >>>> callback. >>>> I don't have the details of ARM MMUs and caches reloaded into my head >>>> yet. Maybe next week... >>>> > > We've had these kinds of questions in the past. Doing what you're asking > above is not really an option - it requires: > > 1. disable all IRQs > 2. setup 1:1 MMU mappings for code to turn off MMU > (requires new page table) > 3. disable imprecise exceptions > 4. flush caches and TLBS > 5. jump to 1:1 mapping area for code to disable MMU > 6. disable caches and mmu > 7. call function > 8. flush caches and TLBs > 9. re-enable caches and mmu > 10. re-enable imprecise exceptions > 11. switch back to original MMU mappings > 12. re-enable all IRQs > > This is fine if you don't care at all about interrupt latency. > Unfortunately, most people do care about interrupt latency because > that directly affects interactivity and system performance. The > called function could not enable interrupts or exceptions - as the > CPU vectors are in virtual space, disabling the MMU effectively > makes them disappear. > > Moreover, with the MMU and caches disabled, the CPU performance is > extremely poor, so the called function will run slowly. > > So, disabling the MMU isn't really viable. > None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. > Now, if the external code was fully PIC, we could then run it with > the MMU enabled. However, this wouldn't really help - the external > code could not access any devices without knowledge of how the kernel > setup the V:P translations. > > So you'd need to pass some kind of data structure giving locations of > devices to the called code - but then what if the kernel doesn't have > the device mapped? > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: wmb@firmworks.com (Mitch Bradley) Date: Sun, 13 Jun 2010 21:45:50 -1000 Subject: Request review of device tree documentation In-Reply-To: <20100614073828.GA6095@n2100.arm.linux.org.uk> References: <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <1276408773.1962.574.camel@pasglop> <20100614073828.GA6095@n2100.arm.linux.org.uk> Message-ID: <4C15DE2E.1050905@firmworks.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Russell King - ARM Linux wrote: > On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: > >>>> Or perhaps the MMU and caches can be turned off for the duration of the >>>> callback. >>>> I don't have the details of ARM MMUs and caches reloaded into my head >>>> yet. Maybe next week... >>>> > > We've had these kinds of questions in the past. Doing what you're asking > above is not really an option - it requires: > > 1. disable all IRQs > 2. setup 1:1 MMU mappings for code to turn off MMU > (requires new page table) > 3. disable imprecise exceptions > 4. flush caches and TLBS > 5. jump to 1:1 mapping area for code to disable MMU > 6. disable caches and mmu > 7. call function > 8. flush caches and TLBs > 9. re-enable caches and mmu > 10. re-enable imprecise exceptions > 11. switch back to original MMU mappings > 12. re-enable all IRQs > > This is fine if you don't care at all about interrupt latency. > Unfortunately, most people do care about interrupt latency because > that directly affects interactivity and system performance. The > called function could not enable interrupts or exceptions - as the > CPU vectors are in virtual space, disabling the MMU effectively > makes them disappear. > > Moreover, with the MMU and caches disabled, the CPU performance is > extremely poor, so the called function will run slowly. > > So, disabling the MMU isn't really viable. > None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. > Now, if the external code was fully PIC, we could then run it with > the MMU enabled. However, this wouldn't really help - the external > code could not access any devices without knowledge of how the kernel > setup the V:P translations. > > So you'd need to pass some kind of data structure giving locations of > devices to the called code - but then what if the kernel doesn't have > the device mapped? > >