Re: Request review of device tree documentation

From: Mitch Bradley <wmb@firmworks.com>
To: Mike Rapoport <mike@compulab.co.il>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	microblaze-uclinux@itee.uq.edu.au,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	Jamie Lokier <jamie@shareable.org>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>,
	Dan Malek <ppc6dev@digitaldans.com>,
	Jeremy Kerr <jeremy.kerr@canonical.com>,
	linux-arm-kernel@lists.infradead.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: Request review of device tree documentation
Date: Tue, 15 Jun 2010 20:32:51 -1000	[thread overview]
Message-ID: <4C187013.5000400@firmworks.com> (raw)
In-Reply-To: <4C186C72.2020506@compulab.co.il>

Mike Rapoport wrote:
> Mitch Bradley wrote:
>> Mike Rapoport wrote:
>>> Mitch Bradley wrote:
>>>
>>>> The second topic is the hypothetical use of OFW as a HAL. That will 
>>>> not happen for several reasons.  The opposition to the idea is 
>>>> widespread and deeply held, and there are good arguments to support 
>>>> that opposition.   Furthermore, the economic conditions necessary 
>>>> for the creation of such a HAL do not exist in the ARM world, nor 
>>>> indeed in the Linux world in general.  (The necessary condition is 
>>>> the ability for one company to impose a substantial change by fiat 
>>>> - essentially a monopoly position.)
>>>>
>>>> Shall we agree, then, that any further discussion of the HAL issue 
>>>> is "just for fun", and that nobody needs to feel threatened that it 
>>>> would actually happen?
>>>
>>> I've recently worked with vendor versions of U-Boot for advanced ARM 
>>> SoCs. There is already *huge* chunk of HAL code in those versions. 
>>> And if there would be possibility to have callbacks into the 
>>> firmware these chunks would only grow, IMHO.
>>
>> How can there be HAL code in U-Boot unless there is already the 
>> possibility to have callbacks into the firmware?
>
> Currently it aims to abstract hardware from U-Boot and reuse the same 
> HW access code across operating systems and bootloaders. If this code 
> would have callbacks I afraid the things would became worse.

The only way I can understand what you said is if I assume that by 
"callback", you mean the following sequence:

a) U-boot loads and executes the OS, providing to the OS the address of 
some HW access routines that it can use
b) The OS calls one of those HW access routines
c) During the execution of that HW access routine, that routine calls 
"back" into the OS, before returning.  So a call into the OS is nested 
inside a call into U-boot resident code.

If that is what you are worried about, it is not what we were 
discussing.  We were discussing - and many people were against - step (b).

Are you saying that step (b) - the OS calling into routines provided by 
U-Boot - is already the status quo?

>
>> It is not HAL if it can't be called.
>>
>>>
>>>
>>>> The potential for "vendors breaking out of the debugging use case 
>>>> and turning it into a HAL" is miniscule, because
>>>>
>>>> a) The callback is disabled by default
>>>> b) The technical challenges of the callback interface limit its 
>>>> applicability to specific "wizard user" scenarios
>>>> c) OFW is unlikely to achieve sufficient market penetration for the 
>>>> HAL thing to be worth doing
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>
>