On Sun, Jan 19, 2014 at 11:18:18AM +0800, Shawn Guo wrote:
On Thu, Jan 16, 2014 at 06:22:12PM +0000, Russell King - ARM Linux wrote:
quoted
Now that the Cubox-i has been released, and I have one, I've been able to
update things a little. Out of the following two patches, the first one
I think is critical to be merged before the microsom support hits
mainline, since it drops the flexcan support from the microsom level,
moving it to the Hummingboard level.
I will be out of town for a few days, and won't be online until next
weekend. So please send the patch directly to arm-soc folks, so that
they can send it together with imx-dt-3.14 stuff.
arm-soc folks, please take this as another ping for my imx-dt-3.14 pull
request :)
I'm well aware that the DT branch has not been merged, and that's because
there has been no consensus from DT maintainers on the massive rework
you did as the base of the branch.
Given the timing, it's not looking like it will be resolved in time for
the 3.14 merge window (which might open today).
-Olof
On Sun, Jan 19, 2014 at 10:52:46AM -0800, Olof Johansson wrote:
I'm well aware that the DT branch has not been merged, and that's because
there has been no consensus from DT maintainers on the massive rework
you did as the base of the branch.
I guess the 'massive rework' you're talking about is the patch series
that begins with 'ARM: dts: imx6qdl: make pinctrl nodes board specific'?
If so, I hope you would agree that we're trying to solve a real
problem [1], even though the solution does not look like the best to
you.
So which specific part of the solution are you objecting to? Those
MX6QDL_*_PINGRP macros defined in imx6qdl-pingrp.h? If that's the
case, I can send a follow-up patch to kill the macros by filling in the
pin group definitions directly. The pros is that the pin group
definitions for given board will be more intuitive, and the cons is that
the change set will be even more massive, because the same multi-lines
pin group definitions will be duplicated in multiple board dts files,
which use the same group of pins for given device.
Or any other better idea?
Given the timing, it's not looking like it will be resolved in time for
the 3.14 merge window (which might open today).
That's frustrating and will be surprising a lot of people who expect to
see their board support in 3.14 release.
Shawn
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/275912/