* [PATCH v6 0/2] Documentation and driver of logicoreIP
From: Dhaval Shah @ 2017-12-21 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0z6HF8Rg08HUj7_T+7ZxxnHoReiu68bNzF6CnEooQSdA@mail.gmail.com>
1st patch provide Device Tree binding document for logicoreIP
2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes
and Makefile changes for the driver.
Dhaval Shah (2):
dt-bindings: misc: Add DT bindings to xlnx_vcu driver
misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
.../devicetree/bindings/soc/xilinx/xlnx,vcu.txt | 31 +
drivers/soc/xilinx/Kconfig | 15 +
drivers/soc/xilinx/Makefile | 1 +
drivers/soc/xilinx/xlnx_vcu.c | 630 +++++++++++++++++++++
4 files changed, 677 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
create mode 100644 drivers/soc/xilinx/xlnx_vcu.c
--
2.7.4
^ permalink raw reply
* [PATCH V2 02/10] clk: reparent orphans after critical clocks enabled
From: Stephen Boyd @ 2017-12-21 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220143322.GC30461@b29396-OptiPlex-7040>
On 12/20, Dong Aisheng wrote:
> On Thu, Nov 02, 2017 at 12:36:09AM -0700, Stephen Boyd wrote:
> > On 07/13, Dong Aisheng wrote:
> > > The orphan clocks reparent operation should be moved after the critical
> > > clocks enabled, otherwise it may get a chance to disable a newly
> > > registered critical clock which triggers the following warning.
> > >
> > > Assuming we have two clocks: A and B, B is the parent of A.
> > > Clock A has flag: CLK_OPS_PARENT_ENABLE
> > > Clock B has flag: CLK_IS_CRITICAL
> > >
> > > Step 1:
> > > Clock A is registered, then it becomes orphan.
> > >
> > > Step 2:
> > > Clock B is registered. Before clock B reach the critical clock enable
> > > operation, orphan A will find the newly registered parent B and do
> > > reparent operation, then parent B will be finally disabled in
> > > __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's
> > > still no users of B which will then trigger the following warning.
> > >
> > > [ 0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0
> > > [ 0.000000] Modules linked in:
> > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373
> > > [ 0.000000] Hardware name: Generic DT based system
> > > [ 0.000000] Backtrace:
> > > [ 0.000000] [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c)
> > > [ 0.000000] r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000
> > > [ 0.000000] [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8)
> > > [ 0.000000] [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104)
> > > [ 0.000000] r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000
> > > [ 0.000000] r4:00000000 r3:c0e01d34
> > > [ 0.000000] [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30)
> > > [ 0.000000] r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80
> > > [ 0.000000] [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0)
> > > [ 0.000000] [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c)
> > > [ 0.000000] r4:000000d3 r3:c0e0af00
> > > [ 0.000000] [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28)
> > > [ 0.000000] r5:00000000 r4:ef00bf80
> > > [ 0.000000] [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54)
> > > [ 0.000000] r4:ef00bd80 r3:000010a0
> > > [ 0.000000] [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648)
> > > [ 0.000000] r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4
> > > [ 0.000000] [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c)
> > > [ 0.000000] r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500
> > > [ 0.000000] [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120)
> > > [ 0.000000] [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54)
> > > [ 0.000000] r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001
> > > [ 0.000000] r4:f0810030
> > > [ 0.000000] [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98)
> > > [ 0.000000] r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808
> > > [ 0.000000] [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0)
> > > [ 0.000000] r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0
> > > [ 0.000000] r4:00000006
> > > [ 0.000000] [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38)
> > > [ 0.000000] r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000
> > > [ 0.000000] r4:00000000
> > > [ 0.000000] [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394)
> > > [ 0.000000] [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c)
> > > [ 0.000000] r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918
> > > [ 0.000000] r4:c0e78294
> > > [ 0.000000] ---[ end trace 0000000000000000 ]---
> >
> > Please remove timestamps from logs unless they're important.
> >
>
> Got it.
>
> > >
> > > Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> > > Cc: Stephen Boyd <sboyd@codeaurora.org>
> > > Cc: Michael Turquette <mturquette@baylibre.com>
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > >
> > > ---
> > > ChangeLog:
> > > v1->v2:
> > > * add more detailed commit messages
> >
> > Thanks for that. We shouldn't be touching the hardware during clk
> > registration though, so something is wrong there. It seems that
> > adding the flag to enable clks when touching their registers has
> > exposed that we should just be doing the toggle of the bookeeping
> > stuff underneath the enable lock here.
> >
> > We know that the clk isn't enabled with any sort of prepare_count
> > here so we don't need to enable anything to prevent a race. And
> > we're holding the prepare mutex so set_rate/set_parent can't race
> > here either.
> >
>
> Well, it looks like a good suggestion and it does make sense.
>
> > Can you try this patch instead?
> >
> > ---8<----
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index c8d83acda006..416d44cc772c 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2476,14 +2476,17 @@ static int __clk_core_init(struct clk_core *core)
> > */
> > hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) {
> > struct clk_core *parent = __clk_init_parent(orphan);
> > + unsigned long flags;
> >
> > /*
> > * we could call __clk_set_parent, but that would result in a
> > * redundant call to the .set_rate op, if it exists
> > */
> > if (parent) {
> > - __clk_set_parent_before(orphan, parent);
> > - __clk_set_parent_after(orphan, parent, NULL);
> > + /* update the clk tree topology */
> > + flags = clk_enable_lock();
> > + clk_reparent(orphan, parent);
> > + clk_enable_unlock(flags);
> > __clk_recalc_accuracies(orphan);
> > __clk_recalc_rates(orphan, 0);
> > }
>
>
> I tested this change worked well.
> I could resent the patch with this new method later.
>
Ok. Great. I'm going to apply this patch now into clk-next to
look for regressions on other platforms. If this was the only
questionable thing about this series then I think I can apply the
rest of it without you needing to resend. I'll check today.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL 2/2] Rockchip dts64 changes for 4.16
From: Heiko Stuebner @ 2017-12-21 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2013174.TmhWXT9G0E@phil>
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.16-rockchip-dts64-1
for you to fetch changes up to 13bc2c0a6a14f430abaa6a859792418644b7febd:
arm64: dts: rockchip: Add efuse device node for RK3328 SoC (2017-12-20 13:12:13 +0100)
----------------------------------------------------------------
General RK3399 gets Mipi nodes, fixes for usb3 support and better support
for the type-c phys. The Kevin Chromebooks based on rk3399 now can use their
internal edp displays. RK3328 gets its efuse node and Mali450 gpu node,
which actually produces already some nice results with the WIP Lima driver.
----------------------------------------------------------------
Brian Norris (1):
arm64: dts: rockchip: add rk3399 DSI0 reset
Enric Balletbo i Serra (5):
arm64: dts: rockchip: add pd_usb3 power-domain node for rk3399
arm64: dts: rockchip: add the aclk_usb3 clocks for USB3 on rk3399
arm64: dts: rockchip: add reset property for dwc3 controllers on rk3399
arm64: dts: rockchip: add usb3-phy otg-port support for rk3399
arm64: dts: rockchip: add extcon nodes and enable tcphy rk3399-gru
Finley Xiao (1):
arm64: dts: rockchip: Add efuse device node for RK3328 SoC
Heiko Stuebner (2):
dt-bindings: gpu: mali-utgard: add rockchip,rk3328-mali compatible
arm64: dts: rockchip: add rk3328 mali gpu node
Jeffy Chen (1):
arm64: dts: rockchip: Enable edp disaplay on kevin
Nickey Yang (2):
arm64: dts: rockchip: add mipi_dsi1 support for rk3399
arm64: dts: rockchip: update mipi cells for RK3399
.../devicetree/bindings/gpu/arm,mali-utgard.txt | 1 +
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 47 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 ++++++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 42 +++++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 85 +++++++++++++++++++---
5 files changed, 195 insertions(+), 9 deletions(-)
^ permalink raw reply
* [GIT PULL 1/2] Rockchip dts32 changes for 4.16
From: Heiko Stuebner @ 2017-12-21 18:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof,
please find below and in the next mail Rockchip changes for 4.16.
The volume especially on 32bit is quite low this time, possibly due
to the holiday season. So if nothing looks bad, please pull
Thanks and merry xmas
Heiko
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.16-rockchip-dts32-1
for you to fetch changes up to fe8fd85a23a746bd7f0a14e5dcd55c9bc517a055:
ARM: dts: rockchip: add reset property for rk3066a-rayeager emac phy (2017-12-16 21:09:37 +0100)
----------------------------------------------------------------
Just the reset property for the rk3066a-rayeager emac phy
----------------------------------------------------------------
Chris Zhong (1):
ARM: dts: rockchip: add reset property for rk3066a-rayeager emac phy
arch/arm/boot/dts/rk3066a-rayeager.dts | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Emmanuel Vadot @ 2017-12-21 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221152630.2vf57x5o2yi5sv3n@flea.lan>
Hi Maxime,
On Thu, 21 Dec 2017 16:26:30 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > Hi Kyle,
> > >
> > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> > >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> > >> thermal calibration data, add node to describe it.
> > >>
> > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> > >> supported in an external driver for FreeBSD.
> > >>
> > >> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> > >
> > > The patch looks fine in itself, but we've had a number of issues with
> > > the register layout (and access patterns) in the past, so I'd rather
> > > have something that works in Linux too if possible.
> >
> > I have a patch that I think should make it work fine on Linux [1], but
> > I'm afraid I have little to no capability to test it myself and so I
> > did not add it as well.
> >
> > I do know that the rootkey is offset 0x200 into the given space [2],
> > as is the case with the H3, and that the readout quirk is not needed.
> > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> > H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> > this space.
>
> Then maybe we should leave it aside until someone takes some time on
> the A83t.
Take some time on the Linux driver and do not apply this patch for
now you mean ?
Cheers,
> The good news is that the binding itself looks fine, so as
> far as FreeBSD goes, there shouldn't be anything preventing you from
> using it I guess.
>
> Chen-Yu, what do you think?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Emmanuel Vadot <manu@bidouilliste.com>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King - ARM Linux @ 2017-12-21 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221134058.GA15416@lunn.ch>
On Thu, Dec 21, 2017 at 02:40:58PM +0100, Andrew Lunn wrote:
> On Thu, Dec 21, 2017 at 01:32:21PM +0100, Linus Walleij wrote:
> > On Thu, Dec 21, 2017 at 12:12 AM, Russell King
> > <rmk+kernel@armlinux.org.uk> wrote:
> >
> > > The 88e1545 PHY has its interrupts wired to the VF610, so we might as
> > > well use them.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > > This is certainly not correct, as all PHYs on this device share the
> > > same interrupt line, but we can't specify the pinmux settings
> > > individually on each PHY. How should this be handled?
> >
> > I do not know the details of the Marvell switch.
>
> Hi Linus
>
> The 88e1545 is a discreet quad PHY. It is connected to the switch, but
> not integrated into the switch. All its interrupt handling is done
> with a GPIO onto the Freescale processor, via a GPIO. There is nothing
> DSA related here at all with respect to the interrupt. It is just a
> normal GPIO interrupt. What is a bit odd is that it one shared
> interrupt for all four PHYs.
>
> What you described with an irqchip inside the switch is what we
> actually do for the internal PHYs on Marvell devices. And it is what i
> recommend for all DSA drivers. Expose standard IRQs, and let phylib
> use them in its normal way.
... and it has to be said that model doesn't work in this case,
because, although there is the possibility to demux the interrupt
any of the PHYs, you already need to be driving one of the PHYs.
It's not an interrupt controller itself (there's no possibility to
enable/disable individual interrupts from a PHY) so it doesn't make
sense.
What we have here is _really_ a shared interrupt between four
separate devices, and we need a way to sanely describe resources
shared between several device instances to pinmux. Unfortunately,
it seems pinmux is designed around one device having exclusive use
of a resource, which makes it hard to describe shared interrupts in
DT.
Given that DT should be a description of the hardware, and should be
independent of the OS implementation, I'd say this is a pinmux bug,
because pinmux gets in the way of describing the hardware correctly.
;)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [GIT PULL v2] arm: Updates for soc driver for v4.15-next
From: Arnd Bergmann @ 2017-12-21 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e11ef1f-fe9d-61c6-abe4-44ba4c99e060@gmail.com>
On Thu, Dec 21, 2017 at 12:48 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
> ----------------------------------------------------------------
> - change kconfig entry for armv7 SoCs to be more generic
> - add support for mt2701 scpsys driver
> binding documentation
> extend driver to allow the bus protection to overwrite the register
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2] arm64: Updates of aarch64 DTS for v4.15-next
From: Arnd Bergmann @ 2017-12-21 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9bcf1c0b-b60a-fff1-d259-02d791bf561b@gmail.com>
On Thu, Dec 21, 2017 at 12:47 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
>
> arm64: dts: Add power controller device node of MT2712 (2017-12-21 11:35:18 +0100)
>
> ----------------------------------------------------------------
> - mt8173 add cpufreq related nodes
> supply nodes
> frequency/voltage operation table
>
> - mt2712 add cpufreq related nodes
> fixed regulator
> supply nodes
> frequency/voltage operation table
> - mt2712 add clock contoller nodes
> - mt2712 add scpsys node
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2] arm: Updates of armv7 DTS for v4.15-next
From: Arnd Bergmann @ 2017-12-21 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <938d913c-02c2-e44c-1c03-e620276ce35e@gmail.com>
On Thu, Dec 21, 2017 at 12:45 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
> tags/v4.15-next-dts32
>
> for you to fetch changes up to a227cf4dfd74a873857c9cc017100168d01539ed:
>
> dt-bindings: ARM: Mediatek: Fix ethsys documentation (2017-12-20 18:10:12 +0100)
>
> ----------------------------------------------------------------
> - add reset cells mt2701 and mt7623 ethsys
> - update mmc nodes for mt7623
> - mt7623 change mmc card detection pin to active low
> - mt7623 set unit address to lower case
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 3/5] memory: tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-3-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> memory: tegra: Changes for v4.16-rc1
>
> The Tegra memory controller driver will now instruct the SMMU driver to
> create groups, which will make it easier for device drivers to share an
> IOMMU domain between multiple devices.
>
> Initial Tegra186 support is also added in a separate driver.
Pulled into next/drivers.
Arnd
^ permalink raw reply
* [GIT PULL v2 2/5] soc/tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221161252.12920-1-thierry.reding@gmail.com>
On Thu, Dec 21, 2017 at 5:12 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver (2017-12-21 17:04:12 +0100)
>
> This includes two additional patches that have been sitting in patchwork
> for a long time and that I had forgotten to include. Please ignore the
> first pull request and pull this instead.
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> soc/tegra: Changes for v4.16-rc1
>
> Fuse and chip ID support for Tegra186 is added in this set of changes,
> followed by some unification work for the PMC driver in order to avoid
> code duplication between Tegra186 and prior chips.
>
> This also contains a couple of fixes for reading fuses on Tegra20.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Arnd Bergmann @ 2017-12-21 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkday7Z8NM9_tapSHUNVdNbdZcup-kagg65p+sEzwNXqp5g@mail.gmail.com>
On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>> meaning that this is expected to be removed at some point in the future,
>> with gcc-8.0 as the earliest.
>>
>> When building the kernel, the difference between ARMv4 and ARMv4T
>> is relatively small because the kernel never runs THUMB instructions
>> on ARMv4T and does not need any support for interworking.
>>
>> For any future compiler that does not support -march=armv4, we now
>> fall back to -march=armv4t as the architecture level selection,
>> but keep using -march=armv4 by default as long as that is supported
>> by the compiler.
>>
>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>> will go away at the same time as -march=armv4, so this adds a check
>> to see if the compiler supports them, falling back to no -mtune
>> option otherwise.
>>
>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>> instructions instead of 'mov pc,reg'. This is not supported on
>> ARMv4 based CPUs, but the linker can work around this by rewriting
>> those instructions to the ARMv4 version if we pass --fix-v4bx
>> to the linker. This should work with binutils-2.15 (released
>> May 2004) or higher, and we can probably assume that anyone using
>> gcc-7.x will have a much more recent binutils version as well.
>>
>> However, in order to still allow users of old toolchains to link
>> the kernel, we only pass the option to linkers that support it,
>> based on a $(ld-option ...) call. I'm intentionally passing the
>> flag to all linker versions here regardless of whether it's needed
>> or not, so we can more easily spot any regressions if something
>> goes wrong.
>>
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Please test by making the -march=armv4t switch unconditional
>> and see if that results in a working kernel
>
> I did this:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 66e46aec0cd0..3944ecd6cd31 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -81,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K)
> =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
> endif
> arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call
> cc-option,-march=armv5te,-march=armv4t)
> arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
> -arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call
> cc-option,-march=armv4,-march=armv4t)
> +arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
> arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
>
> Built and booted on the Gemini platform.
>
> It crashes immediately and goes into the boot loader
> on thos FA-526 based platform.
Hmm, maybe the decompressor needs the fixup separately. Can you try
something like this completely untested patch on top?
Arnd
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index f0548b6948f1..0e141b2cae98 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -134,6 +134,11 @@ endif
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux += --be8
endif
+
+ifdef CONFIG_CPU_32v4
+LDFLAGS_vmlinux += --fix-v4bx
+endif
+
# ?
LDFLAGS_vmlinux += -p
# Report unresolved symbol references
^ permalink raw reply related
* [PATCH 03/10] arm64: handle 52-bit addresses in TTBR
From: Marc Zyngier @ 2017-12-21 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221164851.edxq536yobjuagwe@armageddon.cambridge.arm.com>
On 21/12/17 16:48, Catalin Marinas wrote:
> On Thu, Dec 14, 2017 at 06:50:05PM +0000, Marc Zyngier wrote:
>> On 13/12/17 17:07, Kristina Martsenko wrote:
>>> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
>>> index eb0c2bd90de9..2b3104af79d0 100644
>>> --- a/arch/arm64/include/asm/pgtable-hwdef.h
>>> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
>>> @@ -16,6 +16,8 @@
>>> #ifndef __ASM_PGTABLE_HWDEF_H
>>> #define __ASM_PGTABLE_HWDEF_H
>>>
>>> +#include <asm/memory.h>
>>> +
>>> /*
>>> * Number of page-table levels required to address 'va_bits' wide
>>> * address, without section mapping. We resolve the top (va_bits - PAGE_SHIFT)
>>> @@ -277,4 +279,11 @@
>>> #define TCR_HA (UL(1) << 39)
>>> #define TCR_HD (UL(1) << 40)
>>>
>>> +/*
>>> + * TTBR
>>> + */
>>> +#ifdef CONFIG_ARM64_PA_BITS_52
>>> +#define TTBR_BADDR_MASK_52 (((UL(1) << 46) - 1) << 2)
>>
>> This really hurts by brain. How about
>>
>> #define TTBR_BADDR_MASK_52 GENMASK_UL(47, 2)
>
> This file is included in assembly code and GENMASK_ULL has a C-only
> version (include/linux/bitops.h). I'll leave Kristina's original code in
> place.
Ah, that's a shame. I really liked it! ;-)
>
>> instead, together with a comment saying that TTBR[1] is RES0.
>
> I can add the comment.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Arnd Bergmann @ 2017-12-21 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY73GCcT24RsL3AGpGJDrwScHni1dYzSGm8rphZ8x0nZw@mail.gmail.com>
On Thu, Dec 21, 2017 at 5:48 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> Alter the DaVinci GPIO recovery fetch to use descriptors
>>> all the way down into the board files.
>>>
>>> Cc: arm at kernel.org
>>> Cc: Kevin Hilman <khilman@kernel.org>
>>> Cc: Keerthy <j-keerthy@ti.com>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> ChangeLog v1->v2:
>>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>>
>> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
>> rebase on top of v4.15-rc and resend.
>
> Since it is dependent on changes in the I2C tree and the
> current patch is based on linux-next I guess something
> got applied ahead of me, I guess I should just rebase
> on Wolfram's tree.
If it helps, you could merge the patch through his tree with my
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Linus Walleij @ 2017-12-21 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220130016.3156090-1-arnd@arndb.de>
On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4 and ARMv4T
> is relatively small because the kernel never runs THUMB instructions
> on ARMv4T and does not need any support for interworking.
>
> For any future compiler that does not support -march=armv4, we now
> fall back to -march=armv4t as the architecture level selection,
> but keep using -march=armv4 by default as long as that is supported
> by the compiler.
>
> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
> will go away at the same time as -march=armv4, so this adds a check
> to see if the compiler supports them, falling back to no -mtune
> option otherwise.
>
> Compiling with -march=armv4t leads the compiler to using 'bx reg'
> instructions instead of 'mov pc,reg'. This is not supported on
> ARMv4 based CPUs, but the linker can work around this by rewriting
> those instructions to the ARMv4 version if we pass --fix-v4bx
> to the linker. This should work with binutils-2.15 (released
> May 2004) or higher, and we can probably assume that anyone using
> gcc-7.x will have a much more recent binutils version as well.
>
> However, in order to still allow users of old toolchains to link
> the kernel, we only pass the option to linkers that support it,
> based on a $(ld-option ...) call. I'm intentionally passing the
> flag to all linker versions here regardless of whether it's needed
> or not, so we can more easily spot any regressions if something
> goes wrong.
>
> For consistency, I'm passing the --fix-v4bx flag for both the
> vmlinux final link and the individual loadable modules.
> The module loader code already interprets the R_ARM_V4BX relocations
> in loadable modules and converts bx instructions into mov even
> when running on ARMv4T or ARMv5 processors. This is now redundant
> when we pass --fix-v4bx to the linker for building modules, but
> I see no harm in leaving the current implementation and doing both.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Please test by making the -march=armv4t switch unconditional
> and see if that results in a working kernel
I did this:
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 66e46aec0cd0..3944ecd6cd31 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -81,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K)
=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
endif
arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call
cc-option,-march=armv5te,-march=armv4t)
arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
-arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call
cc-option,-march=armv4,-march=armv4t)
+arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
Built and booted on the Gemini platform.
It crashes immediately and goes into the boot loader
on thos FA-526 based platform.
Yours,
Linus Walleij
^ permalink raw reply related
* [GIT PULL 5/5] arm64: tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-5-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:19 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> arm64: tegra: Changes for v4.16-rc1
>
> This set of patches enables a bunch of new features on Jetson TX2 that
> were finally unblocked by the GPIO driver getting merged for v4.15.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 4/5] ARM: tegra: Device tree changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-4-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v4.16-rc1
>
> These changes enable the video decoder engine found on Tegra20 SoCs.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/5] dt-bindings: Updates for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-1-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> dt-bindings: Updates for v4.16-rc1
>
> This contains a set of patches that extend existing bindings with support
> for Tegra186.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v3 4/5] ARM: davinci: convert to common clock framework
From: David Lechner @ 2017-12-21 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8833055-51ad-a71f-f326-22719cfc1770@ti.com>
On 12/21/2017 06:34 AM, Sekhar Nori wrote:
>
> All I can say is that issue has been noted within TI and I believe
> (hope) that help is on the way!
>
> If we do go the completely separate clock driver route, I think even
> migrating outside of mach-davinci should not be that tough.
>
Based on your responses, I think we have a pretty clear path forward
now. I'm sold on the all at once approach.
If you can pick up the first 3 patches from this series, I have one or
two more I can send that depend on those changes that are not
intermediate steps.
If TI is able to spend some time on this, it would be nice if they could
look at fixing up the reset framework since that is something I haven't
attempted yet.
And I can work on fixing up the PLL and PSC drivers I already have in
drivers/clk/davinci.
^ permalink raw reply
* [GIT PULL 3/3] ARM: defconfig: exynos: config for v4.16
From: Arnd Bergmann @ 2017-12-21 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-2-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.16
>
> for you to fetch changes up to 6b732dfb698991b5f518be1ddf329c1c2eb3d7cb:
>
> ARM: exynos_defconfig: Enable CONFIG_EXYNOS_IOMMU (2017-12-14 18:57:38 +0100)
>
> ----------------------------------------------------------------
> Samsung defconfig changes for v4.16
>
> 1. Enable missing drivers for supported Exynos boards (PMU, CEC, MHL
> bridge, ASoC for Odroid XU3/XU4).
> 2. Enable Exynos IOMMU driver on exynos_defconfig.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/3] arm64: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-4-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Samsung DTS ARM64 changes for v4.16
>
> 1. Add CPU perf counters to Exynos5433.
> 2. Add missing power domains to Exynos5433.
> 3. Add NFC chip to Exynos5433 TM2/TM2E.
> 4. Fix obscure bugs on I2C transfers to MHL chip on TM2/TM2E.
Pulled into next/dt, thanks!
One question: do you know if anyone is working on support for the newer
Exynos chips, or the Nexell S5P6818 series? It seems odd that none of
the chips from the past three years are supported yet.
Arnd
^ permalink raw reply
* [PATCH 03/10] arm64: handle 52-bit addresses in TTBR
From: Catalin Marinas @ 2017-12-21 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e887ef9f-8d68-8f1f-8bc5-ea5ad4cb2b51@arm.com>
On Thu, Dec 14, 2017 at 06:50:05PM +0000, Marc Zyngier wrote:
> On 13/12/17 17:07, Kristina Martsenko wrote:
> > diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> > index eb0c2bd90de9..2b3104af79d0 100644
> > --- a/arch/arm64/include/asm/pgtable-hwdef.h
> > +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> > @@ -16,6 +16,8 @@
> > #ifndef __ASM_PGTABLE_HWDEF_H
> > #define __ASM_PGTABLE_HWDEF_H
> >
> > +#include <asm/memory.h>
> > +
> > /*
> > * Number of page-table levels required to address 'va_bits' wide
> > * address, without section mapping. We resolve the top (va_bits - PAGE_SHIFT)
> > @@ -277,4 +279,11 @@
> > #define TCR_HA (UL(1) << 39)
> > #define TCR_HD (UL(1) << 40)
> >
> > +/*
> > + * TTBR
> > + */
> > +#ifdef CONFIG_ARM64_PA_BITS_52
> > +#define TTBR_BADDR_MASK_52 (((UL(1) << 46) - 1) << 2)
>
> This really hurts by brain. How about
>
> #define TTBR_BADDR_MASK_52 GENMASK_UL(47, 2)
This file is included in assembly code and GENMASK_ULL has a C-only
version (include/linux/bitops.h). I'll leave Kristina's original code in
place.
> instead, together with a comment saying that TTBR[1] is RES0.
I can add the comment.
--
Catalin
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Linus Walleij @ 2017-12-21 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2+oa+yzAcpmB+YMuCYMxtFdYknETUtKShZX56G6m76Gg@mail.gmail.com>
On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Alter the DaVinci GPIO recovery fetch to use descriptors
>> all the way down into the board files.
>>
>> Cc: arm at kernel.org
>> Cc: Kevin Hilman <khilman@kernel.org>
>> Cc: Keerthy <j-keerthy@ti.com>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>
> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
> rebase on top of v4.15-rc and resend.
Since it is dependent on changes in the I2C tree and the
current patch is based on linux-next I guess something
got applied ahead of me, I guess I should just rebase
on Wolfram's tree.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 1/3] ARM: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-3-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> ----------------------------------------------------------------
> Samsung DTS ARM changes for 4.16
>
> 1. Add sound support to Odroid XU4 (and adjustments to Odroid XU3).
> 2. Enable WiFi on Trats2.
> 3. Add CPU perf counters to Exynos54xx.
> 4. Add power domains to certain chipsets.
> 5. Add Exynos4412 ISP clock controller which finally solves freezes when
> accessing ISP clocks while having the ISP power domain turned off.
> 6. Add Pseudo and True RNG to Exynos5.
> 7. Minor fixes for Trats2, Odroid XU3/XU4, Exynos5410.
> 8. Cleanup of some of DTC warnings
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Gemini DTS updates for v4.16 take one
From: Arnd Bergmann @ 2017-12-21 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYDy202SZ5kOGU5vVsTAgH4kAAMWzaQ1O9jR3d9zGAPPw@mail.gmail.com>
On Sat, Dec 16, 2017 at 8:37 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hi ARM SoC folks,
>
> I was hoping to send more DTS updates but the drivers are
> waiting for review, so might as well get the DTS updates that
> are finished upstream for linux-next.
>
> Please pull this to some gemini DTS branch, I'll build more
> patches on top of this if need be.
Pulled into next/dt, thanks!
Arnd
^ 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