From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Fuzzey Subject: Re: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT. Date: Sat, 6 Apr 2013 19:51:55 +0200 Message-ID: References: <20130319170933.28337.50448.stgit@localhost> <6581638.FPkNsv6peb@flatron> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6581638.FPkNsv6peb@flatron> 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: Tomasz Figa Cc: Martin Fuzzey , Mike Turquette , Sascha Hauer , Fabio Estevam , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On Sat, Apr 6, 2013 at 3:21 PM, Tomasz Figa wrote: > Hi, > > [RANT] > > I tend to disagree about this whole hype about device tree usage for other > things than pure hardware description. I don't think device tree should be > a way to force some kind of new world order, but rather a more convenient > and more maintainable (than board files) way of support hardware platforms > in Linux kernel. > Totally agree > On Friday 05 of April 2013 20:07:09 Matt Sealey wrote: >> >> The device tree concept is NOT a place to dump configuration items for >> your board as hardcoded values to try and force something you could >> have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you >> at least have to run through the Boot ROM and supply a DCD table or >> plugins first. This is where you figure things like this out. > You're suggesting setting the frequencies, parents etc in the DCD table?? Why? IMHO that's horribly unreadable. > But you can't always have control over the bootloader. What's wrong in > letting the kernel configure the board itself? It must configure most of > the hardware anyway, based on platform data (either located in board files > or parsed from device tree). > > Why not to make the kernel independent from the bootloader at all? Then > the bootloader could just do some minimal initialization needed to load a > kernel image from flash memory and launch it (+ some code to allow > flashing of new images). > Yes that's my opinion too. I think the bootloader should really do as little as possible since: * It's generally harder and/or riskier to update the bootloader than the kernel (althugh somewhat less true these days with boot from SD) * There are multiple bootloaders (u-boot, barebox, ...) but only one kernel * It makes it easier to do product families where you have a common bootloader and kernel image with different DTBs per variant. You can then put all the DTBs in the boot partition and use a bootloader variable to chose the right one. >> I am totally against this (sorry Sascha..). Let's put some effort into >> fixing the bootloaders rather than trying to use the device tree to >> enforce the ridiculous assumption that "Linux kernel does not trust >> the bootloader". Why is this "rediculous" IMHO the kernel shouldn't trust the bootloader, beyond having setting up the hardware sufficiently to reliably and safely execute code. >> Once the bindings and trees are out of the kernel >> source, you're going to HAVE to trust what the bootloader passes, be >> it pregenerated compiled blob (which needs to be written to match the >> hardware state the bootloader finishes up at) or dynamically generated >> at runtime during the boot process (which can describe to the bit what >> the hardware is doing). You have to trust the DTB yes but that is not the same as trusting the bootloader to have setup the hardware. I fail to see what difference it makes if the DTS is inside or outside the kernel source. Even today you can compile a DTB from out of tree DTS and pass it to a mainline kernel. Regards, Martin From mboxrd@z Thu Jan 1 00:00:00 1970 From: mfuzzey@gmail.com (Martin Fuzzey) Date: Sat, 6 Apr 2013 19:51:55 +0200 Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT. In-Reply-To: <6581638.FPkNsv6peb@flatron> References: <20130319170933.28337.50448.stgit@localhost> <6581638.FPkNsv6peb@flatron> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sat, Apr 6, 2013 at 3:21 PM, Tomasz Figa wrote: > Hi, > > [RANT] > > I tend to disagree about this whole hype about device tree usage for other > things than pure hardware description. I don't think device tree should be > a way to force some kind of new world order, but rather a more convenient > and more maintainable (than board files) way of support hardware platforms > in Linux kernel. > Totally agree > On Friday 05 of April 2013 20:07:09 Matt Sealey wrote: >> >> The device tree concept is NOT a place to dump configuration items for >> your board as hardcoded values to try and force something you could >> have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you >> at least have to run through the Boot ROM and supply a DCD table or >> plugins first. This is where you figure things like this out. > You're suggesting setting the frequencies, parents etc in the DCD table?? Why? IMHO that's horribly unreadable. > But you can't always have control over the bootloader. What's wrong in > letting the kernel configure the board itself? It must configure most of > the hardware anyway, based on platform data (either located in board files > or parsed from device tree). > > Why not to make the kernel independent from the bootloader at all? Then > the bootloader could just do some minimal initialization needed to load a > kernel image from flash memory and launch it (+ some code to allow > flashing of new images). > Yes that's my opinion too. I think the bootloader should really do as little as possible since: * It's generally harder and/or riskier to update the bootloader than the kernel (althugh somewhat less true these days with boot from SD) * There are multiple bootloaders (u-boot, barebox, ...) but only one kernel * It makes it easier to do product families where you have a common bootloader and kernel image with different DTBs per variant. You can then put all the DTBs in the boot partition and use a bootloader variable to chose the right one. >> I am totally against this (sorry Sascha..). Let's put some effort into >> fixing the bootloaders rather than trying to use the device tree to >> enforce the ridiculous assumption that "Linux kernel does not trust >> the bootloader". Why is this "rediculous" IMHO the kernel shouldn't trust the bootloader, beyond having setting up the hardware sufficiently to reliably and safely execute code. >> Once the bindings and trees are out of the kernel >> source, you're going to HAVE to trust what the bootloader passes, be >> it pregenerated compiled blob (which needs to be written to match the >> hardware state the bootloader finishes up at) or dynamically generated >> at runtime during the boot process (which can describe to the bit what >> the hardware is doing). You have to trust the DTB yes but that is not the same as trusting the bootloader to have setup the hardware. I fail to see what difference it makes if the DTS is inside or outside the kernel source. Even today you can compile a DTB from out of tree DTS and pass it to a mainline kernel. Regards, Martin