From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B3EC9100813 for ; Mon, 14 Jun 2010 16:12:01 +1000 (EST) Subject: Re: Request review of device tree documentation From: Benjamin Herrenschmidt To: Grant Likely In-Reply-To: References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <1276408087.1962.552.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Date: Mon, 14 Jun 2010 16:09:32 +1000 Message-ID: <1276495772.2552.22.camel@pasglop> Mime-Version: 1.0 Cc: linuxppc-dev , microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , Nicolas Pitre , Olof Johansson , Mitch Bradley , 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: , On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: > > We use that to suck the device-tree, which we flatten, and then > re-enter > > the kernel with the "common" entry interface. > > I don't think I want to do the same on ARM. I'd rather have the > prom_init stuff in a boot wrapper, or have OFW itself generate the > flat representation before booting the kernel. But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. > I'm trying to constrain the number of things that could go wrong by > defining only one way for getting the device tree data into the > kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) > Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: benh@kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 14 Jun 2010 16:09:32 +1000 Subject: Request review of device tree documentation In-Reply-To: References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <1276408087.1962.552.camel@pasglop> Message-ID: <1276495772.2552.22.camel@pasglop> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: > > We use that to suck the device-tree, which we flatten, and then > re-enter > > the kernel with the "common" entry interface. > > I don't think I want to do the same on ARM. I'd rather have the > prom_init stuff in a boot wrapper, or have OFW itself generate the > flat representation before booting the kernel. But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. > I'm trying to constrain the number of things that could go wrong by > defining only one way for getting the device tree data into the > kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) > Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Request review of device tree documentation Date: Mon, 14 Jun 2010 16:09:32 +1000 Message-ID: <1276495772.2552.22.camel@pasglop> References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <1276408087.1962.552.camel@pasglop> Mime-Version: 1.0 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: 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: Grant Likely Cc: linuxppc-dev , microblaze-uclinux-rVRm/Wmeqae7NGdpmJTKYQ@public.gmane.org, devicetree-discuss , Nicolas Pitre , Dan Malek , Jeremy Kerr , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: > > We use that to suck the device-tree, which we flatten, and then > re-enter > > the kernel with the "common" entry interface. > > I don't think I want to do the same on ARM. I'd rather have the > prom_init stuff in a boot wrapper, or have OFW itself generate the > flat representation before booting the kernel. But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. > I'm trying to constrain the number of things that could go wrong by > defining only one way for getting the device tree data into the > kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) > Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben.