From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from compulab.co.il (compulab.co.il [67.18.134.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 844CFB7D83 for ; Wed, 16 Jun 2010 16:18:38 +1000 (EST) Message-ID: <4C186C72.2020506@compulab.co.il> Date: Wed, 16 Jun 2010 09:17:22 +0300 From: Mike Rapoport MIME-Version: 1.0 To: Mitch Bradley 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> <20100614124438.GF9323@yookeroo> <20100614160201.GD9550@shareable.org> <4C165FD1.6080505@firmworks.com> <4C186AA8.4040709@compulab.co.il> <4C186B7B.1060308@firmworks.com> In-Reply-To: <4C186B7B.1060308@firmworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Nicolas Pitre , microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , Jamie Lokier , linuxppc-dev , Dan Malek , Jeremy Kerr , linux-arm-kernel@lists.infradead.org, David Gibson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. > 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 >> >> -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mike@compulab.co.il (Mike Rapoport) Date: Wed, 16 Jun 2010 09:17:22 +0300 Subject: Request review of device tree documentation In-Reply-To: <4C186B7B.1060308@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> <20100614124438.GF9323@yookeroo> <20100614160201.GD9550@shareable.org> <4C165FD1.6080505@firmworks.com> <4C186AA8.4040709@compulab.co.il> <4C186B7B.1060308@firmworks.com> Message-ID: <4C186C72.2020506@compulab.co.il> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. > 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 at lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >> -- Sincerely yours, Mike.