On Thu, Feb 5, 2015 at 8:21 PM, Brent Wang [off-list ref] wrote:

Hello Olof and Tyler,

2015-02-06 7:52 GMT+08:00 Tyler Baker [off-list ref]:

quoted

On 5 February 2015 at 11:02, Olof Johansson [off-list ref] wrote:

quoted

On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker [off-list ref]
wrote:

quoted

Hi Bintian,

On 5 February 2015 at 01:24, Bintian Wang [off-list ref]
wrote:

quoted

Hello,

Hi6220 is one mobile solution of Hisilicon, this patchset contains
initial support for Hi6220 SoC and HiKey development board, which
is based on ARM Cortex A53 architecture. Initial support is minimal
and includes just the arch configuration, clock driver, device tree
configuration.

Many peripheral drivers will be submitted later.

Any comments will be appreciated!

Thanks,

Bintian Wang (3):
  arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
  clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
  arm64: dts: Add dts files for Hisilicon Hi6220 SoC

Thanks for posting these! I've applied this series on top of
next-20150204, however there was some fuzz that needed to be cleaned
up on 3/3 [1]. I've confirmed the platform is booting to a basic user
space without issue.

From ramdisk only, right?

Correct, ramdisk only.

quoted

Given the timing of the posting of this
patch set, I'm not going to merge it for 3.20. Hopefully for 3.21
there will be some more peripheral support as well -- at least some
sort of storage device.

Seem fair to me. I also hope to see more patches posted shortly.

Yes, the mmc and sd drivers will be submitted soon, should they be included
in this patchset?  I have thought submitting this patch first for review, if
there
is no problem for this patchset and then submit other drivers, you know,
other
drivers will depend on this patchset.

The drivers should ideally not depend on the SoC patchset -- the
driver can go in independently. The DTS updates to specify the
hardware should go in through arm-soc even if the driver itself (and
the binding document update) should go in through the driver subsystem
instead.


So, you can choose if you want to post everything as a long series,
and cc different maintainers on the various parts of the series -- or
you can post each driver or subsystem as a patchset on its own and let
that get merged through respective maintainer. The latter is most
common these days.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html