* [GIT PULL] STM32 SOC changes for v4.12 #1
From: Olof Johansson @ 2017-04-19 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7b21384-ec29-c39f-97a8-579ca8d16bc2@st.com>
On Mon, Apr 03, 2017 at 07:23:33PM +0200, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this first round of STM32 SOC updates for v4.12:
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/stm32-soc-for-v4.12-1
>
> for you to fetch changes up to c6ed0f31ce3e1c5729d1c8f81a2a94ab881506a6:
>
> ARM: stm32: Add a new SOC - STM32H743 (2017-03-24 11:37:24 +0100)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] STM32 defconfig changes for v4.12 #1
From: Olof Johansson @ 2017-04-19 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <76224fca-01aa-1aa4-3d84-36cfaaa21567@st.com>
On Mon, Apr 03, 2017 at 07:25:40PM +0200, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this first round of STM32 defconfig updates for v4.12:
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/stm32-defconfig-for-v4.12-1
>
> for you to fetch changes up to a1365c4081ac21d2a51fcde3a9956e0e41cc2b74:
>
> ARM: configs: Add new config fragment to change RAM start point
> (2017-03-31 14:19:40 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 1/4] DaVinci driver updates for v4.12
From: Olof Johansson @ 2017-04-19 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092547.32480-1-nsekhar@ti.com>
On Tue, Apr 04, 2017 at 02:55:44PM +0530, Sekhar Nori wrote:
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.12/drivers
>
> for you to fetch changes up to 396ff64d44dbcbd4e6c06c005c4e931bd4b35e4d:
>
> pata_bk3710: clear status bits of BMISP on chipset initialization (2017-03-30 16:13:04 +0530)
>
> ----------------------------------------------------------------
> This adds a new driver for PalmChip
> PATA controller found on DM6446 and
> DM6467 SoCs. This should eventually
> replace the driver in IDE subsystem.
>
> The patches have been acked by ATA
> maintainer.
Are you using a 40-column terminal or something? :)
Anyway, merged.
-Olof
^ permalink raw reply
* [GIT PULL 2/4] DaVinci SoC support updates for v4.12 (part 2)
From: Olof Johansson @ 2017-04-19 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092547.32480-2-nsekhar@ti.com>
On Tue, Apr 04, 2017 at 02:55:45PM +0530, Sekhar Nori wrote:
> The following changes since commit 99228481331cdd75981767b23b83ef0ca7aa11da:
>
> ARM: davinci: add pdata-quirks for da850-evm vpif display (2017-03-07 16:43:19 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.12/soc-2
>
> for you to fetch changes up to 28d4d1d0e49b4ac4d12861a64f45101f36fbfab8:
>
> ARM: davinci: add pata_bk3710 libata driver support (2017-03-30 16:15:29 +0530)
>
> ----------------------------------------------------------------
> Add platform support needed for the
> newly introduced PalmChip PATA driver.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/4] DaVinci DT updates for v4.12 (part 2)
From: Olof Johansson @ 2017-04-19 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092547.32480-3-nsekhar@ti.com>
On Tue, Apr 04, 2017 at 02:55:46PM +0530, Sekhar Nori wrote:
> The following changes since commit f8914131f7da23ab604efd8d1b95a416e5d8fc44:
>
> ARM: dts: da850-evm: add the output port to the vpif node (2017-03-07 16:46:56 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.12/dt-2
>
> for you to fetch changes up to 96f24474a82635810be6943f1bd3fb9c1b70d9d0:
>
> ARM: dts: da850: move spi0_cs3_pin pinconf node (2017-03-30 16:17:47 +0530)
>
> ----------------------------------------------------------------
> A clean-up device-tree patch to ensure
> pinmux entry reuse.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 4/4] DaVinci defconfig updates for v4.12 (part 2)
From: Olof Johansson @ 2017-04-19 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170404092547.32480-4-nsekhar@ti.com>
On Tue, Apr 04, 2017 at 02:55:47PM +0530, Sekhar Nori wrote:
> The following changes since commit 507c318d5ee7d05da6d94041dd42abe0cfdd62cf:
>
> ARM: davinci_all_defconfig: Enable TI ADS7950 (2017-03-07 15:48:21 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.12/defconfig-2
>
> for you to fetch changes up to 2e5d77ef042a22fa1aa393a294999d28f7136d27:
>
> ARM: davinci_all_defconfig: convert to use libata PATA (2017-03-30 16:16:17 +0530)
>
> ----------------------------------------------------------------
> Shift to the newly introduced PalmChip
> PATA driver for DaVinci.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.12 (redo)
From: Olof Johansson @ 2017-04-19 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m24ly37kzk.fsf@baylibre.com>
On Tue, Apr 04, 2017 at 05:31:59PM -0700, Kevin Hilman wrote:
> Hi Arnd, Olof,
>
> Here's a redo of the Amlogic 64-bit DT updates for v4.12.
>
> This DT branch includes all our DT updates, plus merges in a clock
> branch that includes only clock header and binding updates which are
> dependencies. This shared branch/tag is immutable and shared with the
> clock tree.
>
> I hope this iteration passes muster,
>
> Kevin
>
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-redo
>
> for you to fetch changes up to b2121170143bf4708c657461740c922ce24bc94e:
>
> Merge tag 'amlogic-clk-headers' into v4.12/dt64 (2017-04-04 16:16:52 -0700)
>
> ----------------------------------------------------------------
> Amlogic 64-bit DT updates for v4.12
> - pinctrl: new pins for audio
> - clocks: more clocks exposed for GFX, audio
> - new board: Khadas Vim (S905X)
> - new board: HwaCom AmazeTV (S905X)
> - ethernet phy: add GPIO resets
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Reset controller changes for v4.12, part 2
From: Olof Johansson @ 2017-04-19 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491387844.2381.77.camel@pengutronix.de>
On Wed, Apr 05, 2017 at 12:24:04PM +0200, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> please consider merging this tag for v4.12, which just adds a few reset
> lines for the NAND and eMMC controllers on Uniphier LD11/LD20 SoCs.
>
> regards
> Philipp
>
> The following changes since commit 11282a49b735ad7f4cea187de2b8dc5489343e4b:
>
> reset: sunxi: fix for 64-bit compilation (2017-03-15 12:19:12 +0100)
>
> are available in the git repository at:
>
> git://git.pengutronix.de/git/pza/linux.git tags/reset-for-4.12-2
>
> for you to fetch changes up to 23ade398c7c2809d031fe1d83ada11b3c08d73b4:
>
> reset: uniphier: add NAND and eMMC reset control (2017-03-28 18:45:35 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA DTS updates for v4.12
From: Olof Johansson @ 2017-04-19 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491404489-10411-1-git-send-email-dinguyen@kernel.org>
On Wed, Apr 05, 2017 at 10:01:28AM -0500, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in these DTS updates for v4.12.
>
> Thanks,
> Dinh
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.12
>
> for you to fetch changes up to 7fed0cbffe1db3383ae1900fffc8f4e14d2735c8:
>
> ARM: dts: socfpga: Add Devkit A10-SR Reset Controller (2017-03-16 07:57:16 -0500)
>
> ----------------------------------------------------------------
> SoCFPGA DTS updates for v4.12
> - Clean-up:
> - Add clock/memory nodes
> - Add labels for CPU nodes
> - Remove unused unit names and reg
> - Remove unused skeleton.dtsi
> - Add support for PMU
> - Add QSPI for sodia board
> - Add Reset controller for Arria10
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA defconfig update for v4.12
From: Olof Johansson @ 2017-04-19 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491404489-10411-2-git-send-email-dinguyen@kernel.org>
On Wed, Apr 05, 2017 at 10:01:29AM -0500, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in this defconfig update for v4.12.
>
> Thanks,
> Dinh
>
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_defconfig_updates_for_v4.12
>
> for you to fetch changes up to b685b264636b4f3f3eaa0b62fee674a45f2b1679:
>
> ARM: socfpga: updates for socfpga_defconfig (2017-03-16 08:05:46 -0500)
>
> ----------------------------------------------------------------
> SoCFPGA defconfig updates for v4.12
> - enables TSE(Triple-Speed-Ethernet) support
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner arm64 config changes for 4.12
From: Olof Johansson @ 2017-04-19 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406081904.ctvamxa2u4mcavkf@lukather>
On Thu, Apr 06, 2017 at 10:19:04AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Please pull the following changes for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-config64-for-4.12
>
> for you to fetch changes up to 565fbac18efef447a6a97325664c77ddcbe82936:
>
> arm64: defconfig: add Allwinner USB PHY (2017-03-24 16:43:02 +0100)
>
> ----------------------------------------------------------------
> Allwinner arm64 config changes for 4.12
>
> Two patches to change our Kconfig option and add new options in the
> defconfig.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner core changes for 4.12
From: Olof Johansson @ 2017-04-19 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406083311.be3gu26bk5y2glxd@lukather>
On Thu, Apr 06, 2017 at 10:33:11AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here are some patches for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.12
>
> for you to fetch changes up to 87c586a6a0e166e0403533c2f67a3ae74d26fc14:
>
> MAINTAINERS: Update the Allwinner sunXi entry (2017-04-04 17:50:59 +0200)
>
> ----------------------------------------------------------------
> Allwinner core changes for 4.12
>
> A change to our MAINTAINERS entry to reflect the new git tree, and a select
> in our KConfig option to enable the device frequency scaling.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner defconfig changes for 4.12
From: Olof Johansson @ 2017-04-19 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406083539.qhowtju6helnxm7v@lukather>
On Thu, Apr 06, 2017 at 10:35:39AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here are some defconfig changes for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-defconfig-for-4.12
>
> for you to fetch changes up to 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1:
>
> ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in (2017-03-06 07:38:15 +0100)
>
> ----------------------------------------------------------------
> Allwinner defconfig changes for 4.12
>
> Some patches to enable new modules in the defconfig.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.12
From: Olof Johansson @ 2017-04-19 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406085810.lhizqmi65h2jats3@lukather>
On Thu, Apr 06, 2017 at 10:58:10AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Please pull the following DT changes for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-4.12
>
> for you to fetch changes up to 367d2b0cb15dfbfa7243b200957c3c6b86276b54:
>
> ARM: sun8i: sina33: add highest OPP of CPUs (2017-04-05 14:11:36 +0200)
>
> ----------------------------------------------------------------
> Allwinner DT changes for 4.12
>
> As usual a number of changes, among which:
> - All the sun5i DTSI has been reworked based on the new documentation and
> the IPs that are actually found in all those SoCs. Part of that rework
> also brought the GR8 DTSI to include sun5i.dtsi
> - Mali devfreq and thermal throttling support on the A33
> - AC power supplies for the AXP209 and AXP22X PMIC
> - CAN support for the A20
> - CPUFreq-based thermal throttling for the A33
> - New board: NanoPi NEO Air
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner arm64 DT changes for 4.12
From: Olof Johansson @ 2017-04-19 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406090606.uc5aucn5ixinkdiu@lukather>
On Thu, Apr 06, 2017 at 11:06:06AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Please pull the following changes for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt64-for-4.12
>
> for you to fetch changes up to ec4279053a6434f685246e022be95d2a62f8c608:
>
> arm64: allwinner: a64: add R_PIO pinctrl node (2017-04-04 17:45:09 +0200)
Merged, thanks!
-Olof
^ permalink raw reply
* [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list
From: Laurent Pinchart @ 2017-04-19 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419083655.egqgf34dxdwpyomx@phenom.ffwll.local>
Hi Daniel,
On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> > Most of the items have been taken care of by a clean up series. Remove
> > the completed items and add a few new ones.
> >
> > Signed-off-by: Laura Abbott <labbott@redhat.com>
> > ---
> >
> > drivers/staging/android/TODO | 21 ++++-----------------
> > 1 file changed, 4 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..5f14247 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> >
> > @@ -7,23 +7,10 @@ TODO:
> > ion/
> >
> > - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel
> > internal - interface on top of dma-buf. flush_for_device needs to be
> > added to dma-buf - first.
> > - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in
> > some - vendor trees. Should be replaced with an ioctl on the dma-buf to
> > expose the - begin/end_cpu_access hooks to userspace.
> > - - Clarify the tricks ion plays with explicitly managing coherency behind
> > the - dma api's back (this is absolutely needed for high-perf gpu
> > drivers): Add an - explicit coherency management mode to
> > flush_for_device to be used by drivers - which want to manage caches
> > themselves and which indicates whether cpu caches - need flushing.
> > - - With those removed there's probably no use for ION_IOC_IMPORT anymore
> > either - since ion would just be the central allocator for shared
> > buffers. - - Add dt-binding to expose cma regions as ion heaps, with the
> > rule that any - such cma regions must already be used by some device
> > for dma. I.e. ion only - exposes existing cma regions and doesn't
> > reserve unecessarily memory when - booting a system which doesn't use
> > ion.
> > + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This
> > would + involve putting appropriate bindings in a memory node for Ion
> > to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> > + - Better test framework (integration with VGEM was suggested)
>
> Found another one: Integrate the ion kernel-doc into
> Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.
If ion is a generic-purpose allocator, should its documentation really reside
in Documentation/gpu/ ?
> There's a lot of api and overview stuff already around, would be great to
> make this more accessible.
>
> But I wouldn't put this as a de-staging blocker, just an idea.
>
> On the series: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> No full review since a bunch of stuff I'm not too familiar with, but I
> like where this is going.
> -Daniel
>
> > Please send patches to Greg Kroah-Hartman <greg@kroah.com> and Cc:
> > Arve Hj?nnev?g <arve@android.com> and Riley Andrews
> > <riandrews@android.com>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL] Allwinner H5 DT changes for 4.12
From: Olof Johansson @ 2017-04-19 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406093748.7xybeycxnqj5frow@lukather>
On Thu, Apr 06, 2017 at 11:37:48AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here is a serie of patches a bit unusual for the next merge window.
>
> Allwinner released a new SoC, the H5, that is basically an H3 with
> arm64 CPU cores (A53 instead of A7).
>
> In order to support it properly, we've created a common DTSI, and
> built on top. Since that DTSI is spread across arm and arm64, it took
> a bit of rework (all the patches in that PR until commit da89e1d5cbaf
> ("ARM: sunxi: h3/h5: add usb_otg and OHCI/EHCI for usbc0 on H3/H5"))
> that is shared with the PR I just sent with the H3-only patches.
>
> The patches on top of that commit are H5-specific commits (new boards,
> new features) and should be merged through your arm64 DT branch.
>
> Thanks,
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-h5-for-4.12
>
> for you to fetch changes up to d7bb5b966174fee6e4b0085124b75787a5d81b8a:
>
> ARM: sunxi: h3/h5: switch apb0-related clocks to r_ccu (2017-04-04 17:45:24 +0200)
>
> ----------------------------------------------------------------
> Allwinner H5 DT changes for 4.12
>
> H5 patches for 4.12, which are mostly related to reworking the H3 DTSI to
> be usable on the arm64 H5 DTSI, that shares almost everything with the H3
> but the CPU cores.
>
> We then have patches to support the H5 boards on top.
>
> ----------------------------------------------------------------
> Andre Przywara (3):
> arm: sun8i: h3: split Allwinner H3 .dtsi
> arm64: allwinner: h5: add Allwinner H5 .dtsi
> arm64: allwinner: h5: add support for the Orange Pi PC 2 board
>
> Icenowy Zheng (6):
> arm: sun8i: h3: drop skeleton.dtsi inclusion in H3 DTSI
> arm: sun8i: h3: drop pinctrl-a10.h inclusion for H3 DTSI
> arm: sun8i: h3: correct the GIC compatible in H3 to gic-400
> ARM: sunxi: h3/h5: add usb_otg and OHCI/EHCI for usbc0 on H3/H5
> arm64: allwinner: h5: enable USB OTG on Orange Pi PC 2 board
> ARM: sunxi: h3/h5: switch apb0-related clocks to r_ccu
>
> arch/arm/boot/dts/sun8i-h3.dtsi | 602 ++-------------------
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 601 ++++++++++++++++++++
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 188 +++++++
> arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 124 +++++
> arch/arm64/boot/dts/allwinner/sunxi-h3-h5.dtsi | 1 +
> 6 files changed, 955 insertions(+), 562 deletions(-)
> create mode 100644 arch/arm/boot/dts/sunxi-h3-h5.dtsi
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> create mode 120000 arch/arm64/boot/dts/allwinner/sunxi-h3-h5.dtsi
So, I really don't like these symlinks. We had some discussions here:
https://marc.info/?m=147547436324674&w=2
Given my lack of attention on this, it's obviously way late in the release
cycle to ask you to respin so I'll merge this branch as-is right now.
What I'll do though, is that I'll apply that patch that sets up those
symlinks here, and may I ask that you revisit right after -rc1 with
a pull request that moves over to that model? I.e. the arm64 dts
would then include <arm/sunxi-h3-h5.dtsi> instead.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner H3 DT changes for 4.12
From: Olof Johansson @ 2017-04-19 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406093106.hcjthwt5vemw4xnw@lukather>
On Thu, Apr 06, 2017 at 11:31:06AM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here is a serie of patches a bit unusual for the next merge window.
>
> Allwinner released a new SoC, the H5, that is basically an H3 with
> arm64 CPU cores (A53 instead of A7).
>
> In order to support it properly, we've created a common DTSI, and
> built on top. Since that DTSI is spread across arm and arm64, it took
> a bit of rework (all the patches in that PR until commit da89e1d5cbaf
> ("ARM: sunxi: h3/h5: add usb_otg and OHCI/EHCI for usbc0 on H3/H5"))
> that is shared with the next PR I'm about to send with the H5-only patches.
>
> The patches on top of that commit are H3-specific commits and should
> be merged through your arm DT branch.
>
> Let me know if you have any questions,
> Maxime
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-h3-for-4.12
>
> for you to fetch changes up to 72897fa31fcf6222a11c6ebb0bcca25628bb1f7c:
>
> ARM: sun8i: h2+: enable USB OTG for Orange Pi Zero board (2017-03-27 13:45:32 +0200)
>
> ----------------------------------------------------------------
> Allwinner H3 DT changes for 4.12
>
> H3 patches for 4.12, which are mostly related to reworking the H3 DTSI to
> be usable on the arm64 H5 DTSI, that shares almost everything with the H3
> but the CPU cores.
>
> We also have some new device addition (USB, mostly) that would conflict
> otherwise.
Merged into next/dt. Thanks.
-Olof
^ permalink raw reply
* LDM/STM alignment fixups on arm64
From: Srinivas Ramana @ 2017-04-19 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419095830.GK17774@n2100.armlinux.org.uk>
On 04/19/2017 03:28 PM, Russell King - ARM Linux wrote:
> On Wed, Apr 19, 2017 at 12:03:58PM +0530, Srinivas Ramana wrote:
>> Hi,
>>
>> While understanding how the alignment are handled on arm and arm64, we came
>> across the fixups for LDM/LDRD/STM on arm where as these fixups are not
>> present on arm64.
>>
>> There may be some specific reason why these fixups are not ported to arm64.
>> Can you please help us understand this?
>>
>> With this difference in how kernel handles 32-bit apps on arm and arm64,
>> there can be apps which are working without abort on arm, but fail on arm64
>> (SIGBUS). We have tried to get some history on web, but not successful.
>>
>> If this is indeed missing on arm64, do you see any issue if its ported (does
>> it fail any guidance)?
>
> Do you have an application that fails because of this? Your email makes
> it sound very theoretical.
>
I don't have any application with me right now. But i just tried passing
an intentional misaligned address in a test program. When i say
intentional, please note this code is buggy and should be fixed.
So, my question is when arm has such fixups to handle such cases and do
gracefully, is there any reason why those fixups are not ported to
arm64? Again, I do agree that apps has to fix these instances, but we do
have fixups in arch/arm.
I do see that the compiler can detect (if its not intentionally induced)
such cases and avoiding to generate LDM/STM and generates multiple
LDR/STR. So, I just want to know if it is safe to assume that the
compiler would take care of all such misaligned addresses passed to LDM/STM?
------------------------>8---------------------------------------
struct locat {
int a;
int b;
int c;
int d;
};
int test_func()
{
struct locat *int_pool1;
struct locat int_pool2;
struct locat *int_pool3;
char *ptr;
int_pool1 = malloc(sizeof(struct locat) + 16);
ptr = (char *)int_pool1;
int_pool3 = (struct locat *)(ptr+1);
printf("pool1 addr: 0x%08x pool3 addr: 0x%08x \n", &int_pool1,
int_pool3);
int_pool2 = *int_pool3;
}
------------------------8<---------------------------------------
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
From: Olof Johansson @ 2017-04-19 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529949.5djtX72aeJ@phil>
Hi,
On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Hi Olof,
>
> Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
>> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
>> > From: Douglas Anderson <dianders@chromium.org>
>> >
>> > We'd like to be able to use the cros-ec-keyboard.dtsi and
>> > cros-ec-sbs.dtsi snippets for arm64 devices. Currently those files live
>> > in the arm/boot/dts directory.
>> >
>> > Let's follow the convention set by commit 8ee57b8182c4 ("ARM64: dts:
>> > vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm") and use
>> > a symlink. Note that in this case we put the files in a new
>> > "include/common" directory since these snippets may need to be
>> > referenced by dts files in many different subdirectories.
>>
>> I'd rather have something like this:
>>
>> https://marc.info/?m=147547436324674&w=2
>>
>> Instead of having everybody move things over. I.e. make it easy to
>> refer to the arm version from arm64 instead of creating a "common"
>> layer inbetween.
>
> just so it gets noticed, I've done and tested [0], which hopefully should
> implement your suggestions above.
>
> If that looks ok, how do you want that picked up? Should I just include
> them in my regular rockchip branches or do you to pick them into some
> immutable branch, if other surprise-users turn up in time for 4.12?
Sigh. I completely dropped the ball on this, and I didn't see it
included in any of your pull requests for 4.12 since I never actually
acked that approach.
I've applied the patches onto a dt/include-paths stable branch, but
we're late for merging dependent code on top of it for 4.12.
-Olof
^ permalink raw reply
* [PATCH v2] ARM: dts: at91: sama5d2: add m_can nodes
From: Quentin Schulz @ 2017-04-19 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419084606.27543-1-wenyou.yang@atmel.com>
Hi,
On 19/04/2017 10:46, Wenyou Yang wrote:
> Add nodes to support the Controller Area Network(M_CAN) on SAMA5D2.
> The version of M_CAN IP core is 3.1.0 (CREL = 0x31040730).
>
> As said in SAMA5D2 datasheet, the CAN clock is recommended to use
> frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
> PMC GCLK3 must select the UPLLCK(480 MHz) as source clock and
> divide by 24, 12, or 6. So, the "assigned-clock-rates" property
> has three options: 20000000, 40000000, and 80000000.
> The "assigned-clock-parents" property should be referred to utmi
> fixedly.
>
> The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are
> default configured in 0x00200000. To avoid conflict with SRAM map
> for PM, change them to 0x00210000 in the AT91Bootstrap via setting
> the CAN Memories Address-based Register(SFR_CAN) of SFR.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
> The patch is tested on SAMA5D2 Xplained and based on the patch set,
> 1. [PATCH v4 1/7] can: m_can: Disabled Interrupt Line 1
> http://marc.info/?l=linux-can&m=149165343604033&w=2
>
> Changes in v2:
> - Configures 10 TX Event FIFO elements and 10 TX Buffers/FIFO slots,
> because the TXE FIFO is needed to be configured.
> - Configure the offset of Message RAM for CAN1 followed from CAN0's.
>
I've tested with the v4 patch series of Mario H?ttel on a SAMA5D2
Xplained and did the following:
# ip link set can0 down
# ip link set can0 up type can bitrate 125000
# cansend can0 500#1E.10.10
Last line at least 10 times, every message is received on my computer.
Same with can1. Tested with candump can0 as well, everything looks fine.
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Thanks,
Quentin
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 24 +++++++++++++
> arch/arm/boot/dts/sama5d2.dtsi | 56 +++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> index 9f7f8a7d8ff9..2f19b08dc226 100644
> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> @@ -257,6 +257,12 @@
> status = "okay";
> };
>
> + can0: can at f8054000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_can0_default>;
> + status = "okay";
> + };
> +
> uart3: serial at fc008000 {
> atmel,use-dma-rx;
> atmel,use-dma-tx;
> @@ -321,6 +327,18 @@
> bias-disable;
> };
>
> + pinctrl_can0_default: can0_default {
> + pinmux = <PIN_PC10__CANTX0>,
> + <PIN_PC11__CANRX0>;
> + bias-disable;
> + };
> +
> + pinctrl_can1_default: can1_default {
> + pinmux = <PIN_PC26__CANTX1>,
> + <PIN_PC27__CANRX1>;
> + bias-disable;
> + };
> +
> pinctrl_charger_chglev: charger_chglev {
> pinmux = <PIN_PA12__GPIO>;
> bias-disable;
> @@ -468,6 +486,12 @@
> };
>
> };
> +
> + can1: can at fc050000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_can1_default>;
> + status = "okay";
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index 22332be72140..383ca9307edf 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -762,6 +762,18 @@
> atmel,clk-output-range = <0 83000000>;
> };
>
> + can0_clk: can0_clk {
> + #clock-cells = <0>;
> + reg = <56>;
> + atmel,clk-output-range = <0 83000000>;
> + };
> +
> + can1_clk: can1_clk {
> + #clock-cells = <0>;
> + reg = <57>;
> + atmel,clk-output-range = <0 83000000>;
> + };
> +
> classd_clk: classd_clk {
> #clock-cells = <0>;
> reg = <59>;
> @@ -890,6 +902,18 @@
> #clock-cells = <0>;
> reg = <55>;
> };
> +
> + can0_gclk: can0_gclk {
> + #clock-cells = <0>;
> + reg = <56>;
> + atmel,clk-output-range = <0 80000000>;
> + };
> +
> + can1_gclk: can1_gclk {
> + #clock-cells = <0>;
> + reg = <57>;
> + atmel,clk-output-range = <0 80000000>;
> + };
> };
> };
>
> @@ -1144,6 +1168,22 @@
> clocks = <&clk32k>;
> };
>
> + can0: can at f8054000 {
> + compatible = "bosch,m_can";
> + reg = <0xf8054000 0x4000>, <0x210000 0x4000>;
> + reg-names = "m_can", "message_ram";
> + interrupts = <56 IRQ_TYPE_LEVEL_HIGH 7>,
> + <64 IRQ_TYPE_LEVEL_HIGH 7>;
> + interrupt-names = "int0", "int1";
> + clocks = <&can0_clk>, <&can0_gclk>;
> + clock-names = "hclk", "cclk";
> + assigned-clocks = <&can0_gclk>;
> + assigned-clock-parents = <&utmi>;
> + assigned-clock-rates = <40000000>;
> + bosch,mram-cfg = <0x0 0 0 32 0 0 10 10>;
> + status = "disabled";
> + };
> +
> spi1: spi at fc000000 {
> compatible = "atmel,at91rm9200-spi";
> reg = <0xfc000000 0x100>;
> @@ -1305,6 +1345,22 @@
> status = "okay";
> };
>
> + can1: can at fc050000 {
> + compatible = "bosch,m_can";
> + reg = <0xfc050000 0x4000>, <0x210000 0x4000>;
> + reg-names = "m_can", "message_ram";
> + interrupts = <57 IRQ_TYPE_LEVEL_HIGH 7>,
> + <65 IRQ_TYPE_LEVEL_HIGH 7>;
> + interrupt-names = "int0", "int1";
> + clocks = <&can1_clk>, <&can1_gclk>;
> + clock-names = "hclk", "cclk";
> + assigned-clocks = <&can1_gclk>;
> + assigned-clock-parents = <&utmi>;
> + assigned-clock-rates = <40000000>;
> + bosch,mram-cfg = <0x1100 0 0 32 0 0 10 10>;
> + status = "disabled";
> + };
> +
> chipid at fc069000 {
> compatible = "atmel,sama5d2-chipid";
> reg = <0xfc069000 0x8>;
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL 1/4] dt-bindings: Updates for v4.12-rc1
From: Olof Johansson @ 2017-04-19 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406231020.32048-1-thierry.reding@gmail.com>
On Fri, Apr 07, 2017 at 01:10:17AM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.12-dt-bindings
>
> for you to fetch changes up to bf594a896cdbae4a581eb80a2bdbda8df6997d75:
>
> dt-bindings: Add documentation for GP10B GPU (2017-04-04 16:08:18 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> dt-bindings: Updates for v4.12-rc1
>
> This contains an update for the flow controller device tree binding as
> well as the addition of the binding for the GP10B GPU found on the new
> Tegra186 (Parker) SoC.
Hm, usually we bundle bindings updates with the driver update that makes use of
the new/amended binding.
Anyway, merged this into next/dt. Thanks!
-Olof
^ permalink raw reply
* [PATCH] Revert "arm64: Increase the max granular size"
From: Sunil Kovvuri @ 2017-04-19 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419120114.GB3238@e104818-lin.cambridge.arm.com>
On Wed, Apr 19, 2017 at 5:31 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote:
>> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>> > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote:
>> >> >> >> Do you have an explanation on the performance variation when
>> >> >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network stack
>> >> >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
>> >> >> >> non-coherent DMA?).
>> >> >> >
>> >> >> > network stack use SKB_DATA_ALIGN to align.
>> >> >> > ---
>> >> >> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
>> >> >> > ~(SMP_CACHE_BYTES - 1))
>> >> >> >
>> >> >> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
>> >> >> > ---
>> >> >> > I think this is the reason of performance regression.
>> >> >> >
>> >> >>
>> >> >> Yes this is the reason for performance regression. Due to increases L1 cache alignment the
>> >> >> object is coming from next kmalloc slab and skb->truesize is changing from 2304 bytes to
>> >> >> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of less send buffers.
>> >>
>> >> With what traffic did you check 'skb->truesize' ? Increase from
>> >> 2304 to 4352 bytes doesn't seem to be real. I checked with ICMP
>> >> pkts with maximum size possible with 1500byte MTU and I don't see
>> >> such a bump. If the bump is observed with Iperf sending TCP packets
>> >> then I suggest to check if TSO is playing a part over here.
>> >
>> > I haven't checked truesize but I added some printks to __alloc_skb() (on
>> > a Juno platform) and the size argument to this function is 1720 on many
>> > occasions. With sizeof(struct skb_shared_info) of 320, the actual data
>> > allocation is exactly 2048 when using 64 byte L1_CACHE_SIZE. With a
>> > 128 byte cache size, it goes slightly over 2K, hence the 4K slab
>> > allocation.
>>
>> Understood but still in my opinion this '4K slab allocation' cannot be
>> considered as an issue with cache line size, there are many network
>> drivers out there which do receive buffer or page recycling to
>> minimize (sometimes almost to zero) the cost of buffer allocation.
>
> The slab allocation shouldn't make much difference (unless you are
> running on a memory constrained system) but I don't understand how
> skb->truesize (which is almost half unused) affects the sk_wmem_alloc
> and its interaction with other bits in the network stack (e.g.
> tcp_limit_output_bytes).
>
> However, I do think it's worth investigating further to fully understand
> the issue.
Absolutely.
>
>> >The 1720 figure surprised me a bit as well since I was
>> > expecting something close to 1500.
>> >
>> > The thing that worries me is that skb->data may be used as a buffer to
>> > DMA into. If that's the case, skb_shared_info is wrongly aligned based
>> > on SMP_CACHE_BYTES only and can lead to corruption on a non-DMA-coherent
>> > platform. It should really be ARCH_DMA_MINALIGN.
>>
>> I didn't get this, if you see __alloc_skb()
>>
>> 229 size = SKB_DATA_ALIGN(size);
>> 230 size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>>
>> both DMA buffer and skb_shared_info are aligned to a cacheline separately,
>> considering 128byte alignment guarantees 64byte alignment as well, how
>> will this lead to corruption ?
>
> It's the other way around: you align only to 64 byte while running on a
> platform with 128 byte cache lines and non-coherent DMA.
Okay, I mistook your statement. This is indeed a valid statement.
>> And if platform is non-DMA-coherent then again it's the driver which
>> should take of coherency by using appropriate map/unmap APIs and
>> should avoid any cacheline sharing btw DMA buffer and skb_shared_info.
>
> The problem is that the streaming DMA API can only work correctly on
> cacheline-aligned buffers (because of the cache invalidation it performs
> for DMA ops; even with clean&invalidate, the operation isn't always safe
> if a cacheline is shared between DMA and CPU buffers). In the skb case,
> we could have the data potentially sharing the last addresses of a DMA
> buffer with struct skb_shared_info.
>
> We may be able to get away with SKB_DATA_ALIGN not using
> ARCH_DMA_MINALIGN *if* skb_shared_info is *not* written before or during
> an inbound DMA transfer (though such tricks are arch specific).
>
>> > IIUC, the Cavium platform has coherent DMA, so it shouldn't be an issue
>> > if we go back to 64 byte cache lines.
>>
>> Yes, Cavium platform is DMA coherent and there is no issue with reverting back
>> to 64byte cachelines. But do we want to do this because some platform has a
>> performance issue and this is an easy way to solve it. IMHO there seems
>> to be many ways to solve performance degradation within the driver itself, and
>> if those doesn't work then probably it makes sense to revert this.
>
> My initial thought was to revert the change because it was causing a
> significant performance regression on certain SoC. But given that it
> took over a year for people to follow up, it doesn't seem too urgent, so
> we should rather try to understand the issue and potential side effects
> of moving back to a 64 byte cache line.
Yes.
Thanks,
Sunil.
>
> --
> Catalin
^ permalink raw reply
* [GIT PULL 2/4] ARM: tegra: Maintainer changes for v4.12-rc1
From: Olof Johansson @ 2017-04-19 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406231020.32048-2-thierry.reding@gmail.com>
On Fri, Apr 07, 2017 at 01:10:18AM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.12-misc
>
> for you to fetch changes up to 89d39a63b2c25c8da1a038fdb208bfed041c889c:
>
> MAINTAINERS: tegra: Remove self as maintainer (2017-03-08 14:54:14 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Maintainer changes for v4.12-rc1
>
> Stephen has been focussing on other areas of the open source community
> within NVIDIA, but Jon has been helping out with the kernel development
> for a while now. Replace Stephen's entry with one from Jon.
Welcome onboard as a maintainer, Jon!
> Secondly, Alex has unfortunately left the company and therefore won't
> be serving as a Tegra maintainer any longer.
Sad, but best of luck to Alex in new adventures.
Merged branch into next/fixes-non-critical.
-Olof
^ permalink raw reply
* [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Chunyan Zhang @ 2017-04-19 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490599960-27330-1-git-send-email-chunyan.zhang@spreadtrum.com>
Hi Arnd, Olof
Could you please take this patch through arm-soc git if there are no
further comments? (The three other patches in this series have been
taken by Greg.)
Thanks,
Chunyan
On 27 March 2017 at 15:32, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote:
> From: Orson Zhai <orson.zhai@spreadtrum.com>
>
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
>
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> and sp9860g dts is for the board level.
>
> Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> arch/arm64/boot/dts/sprd/Makefile | 3 +-
> arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++
> arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++
> 4 files changed, 698 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
> create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
>
> diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile
> index b658c5e..f0535e6 100644
> --- a/arch/arm64/boot/dts/sprd/Makefile
> +++ b/arch/arm64/boot/dts/sprd/Makefile
> @@ -1,4 +1,5 @@
> -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
> +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
> + sp9860g-1h10.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> new file mode 100644
> index 0000000..7b7d8ce
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -0,0 +1,569 @@
> +/*
> + * Spreadtrum SC9860 SoC
> + *
> + * Copyright (C) 2016, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include "whale2.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&CPU0>;
> + };
> + core1 {
> + cpu = <&CPU1>;
> + };
> + core2 {
> + cpu = <&CPU2>;
> + };
> + core3 {
> + cpu = <&CPU3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&CPU4>;
> + };
> + core1 {
> + cpu = <&CPU5>;
> + };
> + core2 {
> + cpu = <&CPU6>;
> + };
> + core3 {
> + cpu = <&CPU7>;
> + };
> + };
> + };
> +
> + CPU0: cpu at 530000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530000>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU1: cpu at 530001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530001>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU2: cpu at 530002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530002>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU3: cpu at 530003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530003>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU4: cpu at 530100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU5: cpu at 530101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530101>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU6: cpu at 530102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530102>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU7: cpu at 530103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530103>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> + };
> +
> + idle-states{
> + entry-method = "arm,psci";
> +
> + CORE_PD: core_pd {
> + compatible = "arm,idle-state";
> + entry-latency-us = <1000>;
> + exit-latency-us = <700>;
> + min-residency-us = <2500>;
> + local-timer-stop;
> + arm,psci-suspend-param = <0x00010002>;
> + };
> +
> + CLUSTER_PD: cluster_pd {
> + compatible = "arm,idle-state";
> + entry-latency-us = <1000>;
> + exit-latency-us = <1000>;
> + min-residency-us = <3000>;
> + local-timer-stop;
> + arm,psci-suspend-param = <0x01010003>;
> + };
> + };
> +
> + gic: interrupt-controller at 12001000 {
> + compatible = "arm,gic-400";
> + reg = <0 0x12001000 0 0x1000>,
> + <0 0x12002000 0 0x2000>,
> + <0 0x12004000 0 0x2000>,
> + <0 0x12006000 0 0x2000>;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>;
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
> + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&CPU0>,
> + <&CPU1>,
> + <&CPU2>,
> + <&CPU3>,
> + <&CPU4>,
> + <&CPU5>,
> + <&CPU6>,
> + <&CPU7>;
> + };
> +
> + soc {
> + funnel at 10001000 { /* SoC Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x10001000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + soc_funnel_out_port: endpoint {
> + remote-endpoint = <&etb_in>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0>;
> + soc_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&main_funnel_out_port>;
> + };
> + };
> +
> + port at 2 {
> + reg = <4>;
> + soc_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpioint =
> + <&stm_out_port>;
> + };
> + };
> + };
> + };
> +
> + etb at 10003000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x10003000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + port {
> + etb_in: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&soc_funnel_out_port>;
> + };
> + };
> + };
> +
> + stm at 10006000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0 0x10006000 0 0x1000>,
> + <0 0x01000000 0 0x180000>;
> + reg-names = "stm-base", "stm-stimulus-base";
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + port {
> + stm_out_port: endpoint {
> + remote-endpoint =
> + <&soc_funnel_in_port1>;
> + };
> + };
> + };
> +
> + funnel at 11001000 { /* Cluster0 Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x11001000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + cluster0_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&cluster0_etf_in>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0>;
> + cluster0_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm0_out>;
> + };
> + };
> +
> + port at 2 {
> + reg = <1>;
> + cluster0_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm1_out>;
> + };
> + };
> +
> + port at 3 {
> + reg = <2>;
> + cluster0_funnel_in_port2: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm2_out>;
> + };
> + };
> +
> + port at 4 {
> + reg = <4>;
> + cluster0_funnel_in_port3: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm3_out>;
> + };
> + };
> + };
> + };
> +
> + funnel at 11002000 { /* Cluster1 Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x11002000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + cluster1_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&cluster1_etf_in>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0>;
> + cluster1_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm4_out>;
> + };
> + };
> +
> + port at 2 {
> + reg = <1>;
> + cluster1_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm5_out>;
> + };
> + };
> +
> + port at 3 {
> + reg = <2>;
> + cluster1_funnel_in_port2: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm6_out>;
> + };
> + };
> +
> + port at 4 {
> + reg = <3>;
> + cluster1_funnel_in_port3: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm7_out>;
> + };
> + };
> + };
> + };
> +
> + etf at 11003000 { /* ETF on Cluster0 */
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x11003000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + cluster0_etf_out: endpoint {
> + remote-endpoint =
> + <&main_funnel_in_port0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0>;
> + cluster0_etf_in: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster0_funnel_out_port>;
> + };
> + };
> + };
> + };
> +
> + etf at 11004000 { /* ETF on Cluster1 */
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x11004000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + cluster1_etf_out: endpoint {
> + remote-endpoint =
> + <&main_funnel_in_port1>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0>;
> + cluster1_etf_in: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster1_funnel_out_port>;
> + };
> + };
> + };
> + };
> +
> + funnel at 11005000 { /* Main Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x11005000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + main_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&soc_funnel_in_port0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0>;
> + main_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster0_etf_out>;
> + };
> + };
> +
> + port at 2 {
> + reg = <1>;
> + main_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster1_etf_out>;
> + };
> + };
> + };
> + };
> +
> + etm at 11440000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11440000 0 0x1000>;
> + cpu = <&CPU0>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm0_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port0>;
> + };
> + };
> + };
> +
> + etm at 11540000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11540000 0 0x1000>;
> + cpu = <&CPU1>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm1_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port1>;
> + };
> + };
> + };
> +
> + etm at 11640000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11640000 0 0x1000>;
> + cpu = <&CPU2>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm2_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port2>;
> + };
> + };
> + };
> +
> + etm at 11740000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11740000 0 0x1000>;
> + cpu = <&CPU3>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm3_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port3>;
> + };
> + };
> + };
> +
> + etm at 11840000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11840000 0 0x1000>;
> + cpu = <&CPU4>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm4_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port0>;
> + };
> + };
> + };
> +
> + etm at 11940000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11940000 0 0x1000>;
> + cpu = <&CPU5>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm5_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port1>;
> + };
> + };
> + };
> +
> + etm at 11a40000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11a40000 0 0x1000>;
> + cpu = <&CPU6>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm6_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port2>;
> + };
> + };
> + };
> +
> + etm at 11b40000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11b40000 0 0x1000>;
> + cpu = <&CPU7>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm7_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port3>;
> + };
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> new file mode 100644
> index 0000000..ae0b28c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> @@ -0,0 +1,56 @@
> +/*
> + * Spreadtrum SP9860g board
> + *
> + * Copyright (C) 2017, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +/dts-v1/;
> +
> +#include "sc9860.dtsi"
> +
> +/ {
> + model = "Spreadtrum SP9860G 3GFHD Board";
> +
> + compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
> +
> + aliases {
> + serial0 = &uart0; /* for Bluetooth */
> + serial1 = &uart1; /* UART console */
> + serial2 = &uart2; /* Reserved */
> + serial3 = &uart3; /* for GPS */
> + };
> +
> + memory{
> + device_type = "memory";
> + reg = <0x0 0x80000000 0 0x60000000>,
> + <0x1 0x80000000 0 0x60000000>;
> + };
> +
> + chosen {
> + stdout-path = "serial1:115200n8";
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi b/arch/arm64/boot/dts/sprd/whale2.dtsi
> new file mode 100644
> index 0000000..7c217c5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
> @@ -0,0 +1,71 @@
> +/*
> + * Spreadtrum Whale2 platform peripherals
> + *
> + * Copyright (C) 2016, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + ap-apb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x70000000 0x10000000>;
> +
> + uart0: serial at 0 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x0 0x100>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> +
> + uart1: serial at 100000 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x100000 0x100>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> +
> + uart2: serial at 200000 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x200000 0x100>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> +
> + uart3: serial at 300000 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x300000 0x100>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> + };
> +
> + };
> +
> + ext_26m: ext-26m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <26000000>;
> + clock-output-names = "ext_26m";
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox