Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?] - Russell King

From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Arend van Spriel <arend@broadcom.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Olof Johansson <olof@lixom.net>, Mark Brown <broonie@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"ksummit-2013-discuss@lists.linuxfoundation.org" 
	<ksummit-2013-discuss@lists.linuxfoundation.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Pawel Moll <Pawel.Moll@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Domenico Andreoli <cavokz@gmail.com>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Dave P Martin <Dave.Martin@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
Date: Sat, 27 Jul 2013 12:09:20 +0100	[thread overview]
Message-ID: <20130727110920.GE24642@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <51F3A238.3020505@broadcom.com>

On Sat, Jul 27, 2013 at 12:34:32PM +0200, Arend van Spriel wrote:
> Oh, and the reason for my tinkering on dts is here:
>
> http://mid.gmane.org/51E7AA24.6080600@broadcom.com
>
> Happily using Pandaboard for my driver testing and than *kaboom*.  
> board-omap4panda.c is gone although the device tree does not provide the  
> same functionality. Of course, this is not about DT bindings.

Similar happened to the 4430SDP board - and I took it out of the build
system for over a month because of that.  I knew it would be _painful_
to get DT and running on the board, and I was right, not only because of
the different build process, but also trying to find which kernel config
options need to be added to a previously working configuration for what
is essentially a black box board.

The MMC device for the rootfs magically changed too - which meant finding
out how to tell the kernel which device to use as the rootfs without
giving it an explicit device.  (Using UUIDs, which aren't real UUIDs and
aren't related to the filesystem UUID either - I've still no idea where
this magic number comes from or how to identify it from a running system.)

It's also made a total mess of the boot log.  I've no idea if all the
devices were successfully probed because there's now soo much noise from
the deferred probing that it's like trying to work out if there's any
serious warnings in a kernel build where every file spits out a warning.
It's almost a pen and paper job to work it out.  There's just too much
noise in the kernel boot now that I'm just not going to bother reading
the boot log anymore unless there's something which has noticably failed.

On the plus side, the DT description for the SDP board _may_ have helped
to solve a problem I've had for over two years: that is why the LCDs don't
seem to work on the board.  It seems I need the TWL PWM driver.  I don't
yet know if this has solved the problem or not, because I've not seen the
board boot with that driver in it.  However, it's not clear to me from the
DT description whether that covers both of the LCDs or just one though.