From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Fri, 05 Jul 2013 11:19:38 +0000 Subject: Re: [PATCH v3] ARM: shmobile: lager: Add DT reference Message-Id: <1631144.is6NKUrafF@avalon> List-Id: References: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au> <1438555.HIWtKGAp3v@avalon> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org Hi Magnus, On Friday 05 July 2013 01:25:18 Magnus Damm wrote: > On Fri, Jul 5, 2013 at 12:02 AM, Laurent Pinchart wrote: > > On Wednesday 03 July 2013 16:57:31 Simon Horman wrote: > >> This is sufficient to allow boot of the Lager board with a console > >> without boards-lager.c compiled into the kernel. This is an example of a > >> minimal but still useful initialisation of the board using DT as much as > >> possible. > >> > >> As such it is the same as the boot of Lager that can be achieved without > >> a board file. The intention of adding this file is to facilitate further > >> work to allow board specific devices to be initialised via DT. > > > > At some (hopefully not too distant) point we should stop adding both > > traditional and DT board files. DT is supposed to lower the number of > > board files, not multiply it by two. > > Well, mr-multiply-by-two: While I dislike code duplication I can't recall > when the number of files actually decreased with DT. > > I realize that when we can use DT fully to describe a board then a single > DTS file is enough to describe board specific hardware together with per-SoC > C code. I can't however see how that would reduce the number of files, but > whatever. I always thought the goal was to reduce the memory footprint of > the kernel and that the source would not come with that many limitations, > but it seems that I got that all wrong... I meant board files, sorry. The total number of files hasn't decreased much, if at all. > Anyway, the current split on mach-shmobile is intentional: > > 1) The C version of board support (board-xxx.c) > > This is where platform devices are used (with power domains in some cases) > and where out-of-tree people can experiment with things. This code is using > legacy SH clock code and is not targeted for multiplatform. These should go > away, the sooner the better. > > 2) The DT reference support (board-xxx-reference.c) > > This file contains whatever bits of C code needed to get the DT support > going. All the board specific devices should be described via DT. The DT > reference board support is where we build incremental support to catch up > with 1) board-xxx.c. Ideally we wouldn't need the board-xxx-reference.c file > and instead only go with .dts, but in some cases we need some extra glue and > until pinctrl DT is done we also need those written in C. The DT reference > support will use common clocks as soon as they are available. > > 3) SoC DT support (setup-xxx.c) > > This is what will be used when 2) is caught up with 1). Common clocks and > multiplatform, one SoC at a time. Thanks for the clarification. > > Work is still needed in order to achieve this, as we lack DT bindings for > > core (and non core) devices. That's something we need to work on. As a > > first step, do we have a roadmap with a list of devices that lack DT > > support ? At the very least I see more work needed on > > > > - Common clock framework > > Yes, I agree. Please see below for more about that. > > > - SCI > > Indeed, someone needs to continue earlier efforts for the SCIF driver. It shouldn't be too difficult, Bastian has already layed out a plan, but the dependency on DT clock bindings has prevented the patches from going upstream. > Fortunately, with EMEV2 our UART driver already supports DT, so we can > implement DT-only multiplatform support on EMEV2 regardless of the state of > SCIF. > > > - Timers > > We can use DT-only with Arch timer, but unfortunately another clock evenit > is needed unconditionally for high resolution timer support, search for > clock event and the C3STOP flag if you want to see me moan about that. > > Regardless I believe someone took a couple of first steps towards DT support > for our timers some time ago. But as we discussed face to face about a month > ago, it makes sense to describe the hardware via DT but in case of timers > and clock event / clock sources it does not make sense to associate 87 timer > channels for operating system time keeping. So we need some user space > configuration interface to associate different kind of timer applications > (operating system timer, PWM, clock generation, etc) to different channels. I agree that we need an API for this. It might make sense to restrict the API to in-kernel usage to start with, but we need an API nonetheless. Has this topic been discussed with clocks/timers people ? It might be worth bringing it up for LPC or KS. > Since you mention it: =) > - PINCTRL DT and GPIO DT > > I'd like to start picking up the remaining PINCTRL and GPIO bits for > v3.12 merge. Can you please rebase and resend on top of the latest > renesas-next tag? Patches for v3.12 have been sent yesterday :-) > > We shouldn't delay CCF much longer, v3.12 seems an achievable target to > > me. Who will work on that ? > > So I am currently preparing EMEV2 for multiplatform, will most likely have > patches posted for that next week. And yes, I intend to send a new DT > reference board support file. > > In parallel Kuribayashi-san is taking a stab at moving to common clocks for > EMEV2 as a first step. That's great news. I'm looking forward to reviewing the patches :-) > I expect the above to be in order for v3.12, but not much more that that. That sounds like a reasonable time frame to me. -- Cheers, Laurent Pinchart