From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Wed, 05 Jun 2013 16:54:23 -0600 Subject: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1)) In-Reply-To: <1370469574.18839.33.camel@localhost> References: <51AFA6DD.3000202@wwwdotorg.org> <1370469574.18839.33.camel@localhost> Message-ID: <51AFC19F.9040601@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/05/2013 03:59 PM, Henrik Nordstr?m wrote: > ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton: ... >> so the point is: if anyone wishes me to propose to allwinner that >> they convert over to devicetree, or any other proposal which involves >> significant low-level changes to their working practices that could >> potentially have a massive knock-on effect onto their >> multi-million-dollar clients, it had better be a damn good story. > > Calm down. It isn't really a significant difference to them outside of > the kernel. They do not need to change any of their configuraiton > methods, only a small toolchain change in how the resultig images are > built to have a corresponding device tree built. If U-Boot needs to be parametrized, there are in theory a few options open: 1) Put all the parameters in the U-Boot configuration header. This is normal. 2) Read some data structure at run-time. This data structure could in theory be some SoC-specific blob format (e.g. the packed version of information that some tool extracts from FEX/DT), a whole FEX blob, or device tree. The U-Boot maintainers have already indicated that they won't accept the first two options; run-time configuration has to be via DT, and not via some SoC-specific mechanism. (As I found out to my detriment when I attempted to make U-Boot on Tegra determine which UART to use for debug at run-time by reading the configuration header that our boot ROM uses). Now of course, boot0/boot1 could always transform whatever data structure they wish into a DTB before passing that to U-Boot... From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1)) Date: Wed, 05 Jun 2013 16:54:23 -0600 Message-ID: <51AFC19F.9040601@wwwdotorg.org> References: <51AFA6DD.3000202@wwwdotorg.org> <1370469574.18839.33.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1370469574.18839.33.camel@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: =?UTF-8?B?SGVucmlrIE5vcmRzdHLDtm0=?= Cc: devicetree-discuss , Linux Kernel Mailing List , debian-arm-0aAXYlwwYIJuHlm7Suoebg@public.gmane.org, "jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , Linux on small ARM machines , ARM Linux Mailing List , debian-kernel-0aAXYlwwYIJuHlm7Suoebg@public.gmane.org List-Id: devicetree@vger.kernel.org T24gMDYvMDUvMjAxMyAwMzo1OSBQTSwgSGVucmlrIE5vcmRzdHLDtm0gd3JvdGU6Cj4gb25zIDIw MTMtMDYtMDUga2xvY2thbiAyMjoyNCArMDEwMCBza3JldiBMdWtlIEtlbm5ldGggQ2Fzc29uIExl aWdodG9uOgouLi4KPj4gIHNvIHRoZSBwb2ludCBpczogaWYgYW55b25lIHdpc2hlcyBtZSB0byBw cm9wb3NlIHRvIGFsbHdpbm5lciB0aGF0Cj4+IHRoZXkgY29udmVydCBvdmVyIHRvIGRldmljZXRy ZWUsIG9yIGFueSBvdGhlciBwcm9wb3NhbCB3aGljaCBpbnZvbHZlcwo+PiBzaWduaWZpY2FudCBs b3ctbGV2ZWwgY2hhbmdlcyB0byB0aGVpciB3b3JraW5nIHByYWN0aWNlcyB0aGF0IGNvdWxkCj4+ IHBvdGVudGlhbGx5IGhhdmUgYSBtYXNzaXZlIGtub2NrLW9uIGVmZmVjdCBvbnRvIHRoZWlyCj4+ IG11bHRpLW1pbGxpb24tZG9sbGFyIGNsaWVudHMsIGl0IGhhZCBiZXR0ZXIgYmUgYSBkYW1uIGdv b2Qgc3RvcnkuCj4gCj4gQ2FsbSBkb3duLiBJdCBpc24ndCByZWFsbHkgYSBzaWduaWZpY2FudCBk aWZmZXJlbmNlIHRvIHRoZW0gb3V0c2lkZSBvZgo+IHRoZSBrZXJuZWwuIFRoZXkgZG8gbm90IG5l ZWQgdG8gY2hhbmdlIGFueSBvZiB0aGVpciBjb25maWd1cmFpdG9uCj4gbWV0aG9kcywgb25seSBh IHNtYWxsIHRvb2xjaGFpbiBjaGFuZ2UgaW4gaG93IHRoZSByZXN1bHRpZyBpbWFnZXMgYXJlCj4g YnVpbHQgdG8gaGF2ZSBhIGNvcnJlc3BvbmRpbmcgZGV2aWNlIHRyZWUgYnVpbHQuCgpJZiBVLUJv b3QgbmVlZHMgdG8gYmUgcGFyYW1ldHJpemVkLCB0aGVyZSBhcmUgaW4gdGhlb3J5IGEgZmV3IG9w dGlvbnMgb3BlbjoKCjEpIFB1dCBhbGwgdGhlIHBhcmFtZXRlcnMgaW4gdGhlIFUtQm9vdCBjb25m aWd1cmF0aW9uIGhlYWRlci4gVGhpcyBpcwpub3JtYWwuCgoyKSBSZWFkIHNvbWUgZGF0YSBzdHJ1 Y3R1cmUgYXQgcnVuLXRpbWUuIFRoaXMgZGF0YSBzdHJ1Y3R1cmUgY291bGQgaW4KdGhlb3J5IGJl IHNvbWUgU29DLXNwZWNpZmljIGJsb2IgZm9ybWF0IChlLmcuIHRoZSBwYWNrZWQgdmVyc2lvbiBv ZgppbmZvcm1hdGlvbiB0aGF0IHNvbWUgdG9vbCBleHRyYWN0cyBmcm9tIEZFWC9EVCksIGEgd2hv bGUgRkVYIGJsb2IsIG9yCmRldmljZSB0cmVlLiBUaGUgVS1Cb290IG1haW50YWluZXJzIGhhdmUg YWxyZWFkeSBpbmRpY2F0ZWQgdGhhdCB0aGV5Cndvbid0IGFjY2VwdCB0aGUgZmlyc3QgdHdvIG9w dGlvbnM7IHJ1bi10aW1lIGNvbmZpZ3VyYXRpb24gaGFzIHRvIGJlIHZpYQpEVCwgYW5kIG5vdCB2 aWEgc29tZSBTb0Mtc3BlY2lmaWMgbWVjaGFuaXNtLiAoQXMgSSBmb3VuZCBvdXQgdG8gbXkKZGV0 cmltZW50IHdoZW4gSSBhdHRlbXB0ZWQgdG8gbWFrZSBVLUJvb3Qgb24gVGVncmEgZGV0ZXJtaW5l IHdoaWNoIFVBUlQKdG8gdXNlIGZvciBkZWJ1ZyBhdCBydW4tdGltZSBieSByZWFkaW5nIHRoZSBj b25maWd1cmF0aW9uIGhlYWRlciB0aGF0Cm91ciBib290IFJPTSB1c2VzKS4gTm93IG9mIGNvdXJz ZSwgYm9vdDAvYm9vdDEgY291bGQgYWx3YXlzIHRyYW5zZm9ybQp3aGF0ZXZlciBkYXRhIHN0cnVj dHVyZSB0aGV5IHdpc2ggaW50byBhIERUQiBiZWZvcmUgcGFzc2luZyB0aGF0IHRvClUtQm9vdC4u LgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkZXZpY2V0 cmVlLWRpc2N1c3MgbWFpbGluZyBsaXN0CmRldmljZXRyZWUtZGlzY3Vzc0BsaXN0cy5vemxhYnMu b3JnCmh0dHBzOi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9kZXZpY2V0cmVlLWRpc2N1c3MK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758123Ab3FEWy3 (ORCPT ); Wed, 5 Jun 2013 18:54:29 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:51183 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757956Ab3FEWy1 (ORCPT ); Wed, 5 Jun 2013 18:54:27 -0400 Message-ID: <51AFC19F.9040601@wwwdotorg.org> Date: Wed, 05 Jun 2013 16:54:23 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?SGVucmlrIE5vcmRzdHLDtm0=?= CC: Linux on small ARM machines , devicetree-discuss , Linux Kernel Mailing List , debian-arm@lists.debian.org, "jonsmirl@gmail.com" , ARM Linux Mailing List , debian-kernel@lists.debian.org Subject: Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1)) References: <51AFA6DD.3000202@wwwdotorg.org> <1370469574.18839.33.camel@localhost> In-Reply-To: <1370469574.18839.33.camel@localhost> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/2013 03:59 PM, Henrik Nordström wrote: > ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton: ... >> so the point is: if anyone wishes me to propose to allwinner that >> they convert over to devicetree, or any other proposal which involves >> significant low-level changes to their working practices that could >> potentially have a massive knock-on effect onto their >> multi-million-dollar clients, it had better be a damn good story. > > Calm down. It isn't really a significant difference to them outside of > the kernel. They do not need to change any of their configuraiton > methods, only a small toolchain change in how the resultig images are > built to have a corresponding device tree built. If U-Boot needs to be parametrized, there are in theory a few options open: 1) Put all the parameters in the U-Boot configuration header. This is normal. 2) Read some data structure at run-time. This data structure could in theory be some SoC-specific blob format (e.g. the packed version of information that some tool extracts from FEX/DT), a whole FEX blob, or device tree. The U-Boot maintainers have already indicated that they won't accept the first two options; run-time configuration has to be via DT, and not via some SoC-specific mechanism. (As I found out to my detriment when I attempted to make U-Boot on Tegra determine which UART to use for debug at run-time by reading the configuration header that our boot ROM uses). Now of course, boot0/boot1 could always transform whatever data structure they wish into a DTB before passing that to U-Boot...