* [GIT PULL] Allwinner clock changes for 4.10
From: Maxime Ripard @ 2016-11-15 21:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike, Stephen,
Please pull the following patches for the next merge window.
Thanks!
Maxime
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git sunxi-clk-for-4.10
for you to fetch changes up to 0f6f9302b819ca352cfd4f42c18ec08d521f9cae:
clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks (2016-11-11 21:47:41 +0100)
----------------------------------------------------------------
Allwinner clock changes for 4.10
The usual patches from us, but most notably the introduction of the A64
clocks unit.
----------------------------------------------------------------
Chen-Yu Tsai (2):
clk: sunxi-ng: sun8i-a23: Set CLK_SET_RATE_PARENT for audio module clocks
clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks
Julia Lawall (1):
clk: sunxi: mod0: improve function-level documentation
Maxime Ripard (6):
clk: sunxi-ng: Rename the internal structures
clk: sunxi-ng: Remove the use of rational computations
clk: sunxi-ng: Finish to convert to structures for arguments
clk: sunxi-ng: Add minimums for all the relevant structures and clocks
clk: sunxi-ng: Implement minimum for multipliers
clk: sunxi-ng: Add A64 clocks
.../devicetree/bindings/clock/sunxi-ccu.txt | 1 +
drivers/clk/sunxi-ng/Kconfig | 14 +-
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 915 +++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun50i-a64.h | 72 ++
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 6 +-
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +-
drivers/clk/sunxi-ng/ccu_div.h | 6 +-
drivers/clk/sunxi-ng/ccu_frac.c | 12 +-
drivers/clk/sunxi-ng/ccu_frac.h | 14 +-
drivers/clk/sunxi-ng/ccu_mp.h | 4 +-
drivers/clk/sunxi-ng/ccu_mult.c | 33 +-
drivers/clk/sunxi-ng/ccu_mult.h | 17 +-
drivers/clk/sunxi-ng/ccu_nk.c | 43 +-
drivers/clk/sunxi-ng/ccu_nk.h | 4 +-
drivers/clk/sunxi-ng/ccu_nkm.c | 45 +-
drivers/clk/sunxi-ng/ccu_nkm.h | 6 +-
drivers/clk/sunxi-ng/ccu_nkmp.c | 55 +-
drivers/clk/sunxi-ng/ccu_nkmp.h | 8 +-
drivers/clk/sunxi-ng/ccu_nm.c | 58 +-
drivers/clk/sunxi-ng/ccu_nm.h | 6 +-
drivers/clk/sunxi/clk-mod0.c | 2 +-
include/dt-bindings/clock/sun50i-a64-ccu.h | 134 +++
include/dt-bindings/reset/sun50i-a64-ccu.h | 98 +++
24 files changed, 1434 insertions(+), 130 deletions(-)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/2e76f92b/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Michael Zoran @ 2016-11-15 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115095520.GA18059@kroah.com>
On Tue, 2016-11-15 at 10:55 +0100, Greg KH wrote:
> On Thu, Nov 10, 2016 at 10:15:31PM -0800, Michael Zoran wrote:
> > VCHIQ/vc04_services has a userland device interface
> > that includes ioctls. The current ioctl implementation
> > is a single monolithic function over 1,000+ lines
> > that handles 17 different ioctls through a complex
> > maze of switch and if statements.
> >
> > The change reimplements that code path by breaking
> > up the code into smaller, easier to maintain functions
> > and uses a dispatch table to invoke the correct function.
> >
> > Testing:
> >
> > 1. vchiq_test -f 10 and vchiq_test -p 1 were run from a native
> > 64-bit OS(debian sid).
> >
> > 2. vchiq_test -f 10 and vchiq_test -p 1 where run from a 32-bit
> > chroot install from the same OS.
> >
> > Both test cases pass.
> >
> > This is V2 of this patch.??Changes include:
> >
> > 1. More code has been moved to the dispatch routine.
> > The dispatch routine is now responsible for copying the top-level
> > data into and out of kernel space by using the data encoded in
> > the ioctl command number.
> >
> > 2. The number of parameters have been reduced for the handling
> > functions by giving a different prototype to ioctls that pass
> > no arguments.
> >
> > 3. Macros in linux/compat.h are now used for compatibility data
> > structures.
> >
> > Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> > ---
> > ?.../vc04_services/interface/vchiq_arm/vchiq_arm.c??| 1733
> > +++++++++++++-------
> > ?.../interface/vchiq_arm/vchiq_ioctl.h??????????????|???96 ++
> > ?2 files changed, 1200 insertions(+), 629 deletions(-)
>
> This is a rough patch to review, can you break this up into a patch
> series that moves each ioctl to a separate function as needed?
>
> thanks,
>
> greg k-h
I'll see what I can do, but since this is getting closer to the
holidays I'm planing to spend less time on this. Perhaps someone else
may be interested in cleaning up the ioctl path?
Since the old code uses obsolete kernel features, it's going to take
some work to fix without adding any checkpatch.pl warnings.
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-15 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU38XQBHt709S_z6Quvce6wcqLzRHFuN_bVZ_0eARa3=fw@mail.gmail.com>
On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > So, someone merged a patch which makes mmcblk devices follow the
> > host controller numbering.
> >
> > Now my cubox-i fails to boot correctly because the SD card in the
> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
> >
> > USDHC1 is wired to the on-microsom WiFi, and never has anything
> > remotely near a SD card or eMMC present. So, this change is
> > confusing on these platforms.
> >
> > Moreover, this is _going_ to break SolidRun distros if people upgrade
> > their kernels.
> >
> > It may be appropriate for eMMC, but it's not appropriate everywhere.
> >
> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
> > please revert whatever change caused this, and next time limit it
> > to only eMMC.
> >
> > Thanks.
>
> I see the same thing on newer kernels, which is why I asked the
> question. I didn't expect (or even want honestly) a non mmcblk0 boot
> device and was looking for a way to control that via dt. Now I'm
> understanding that to avoid this kind of bootloader/kernel dependence
> issue I should be using UUID's to identify the boot device.
>
> >From my testing it looks like the change your looking for occurred
> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
> regression specifically.
That depends how you look at it. Yes, there's a change in 4.5 to 4.6
which ties the block device number to the host device index, but that's
really only part of the story here.
4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
of behaviour - there can be no argument about that.
Now, digging further into this today, it appears that:
v4.8: usdhc2 was probed first, and is given mmc0.
usdhc1 is probed second, and is given mmc1.
v4.9-rc: usdhc1 is probed first, and is given mmc0.
usdhc2 is probed second, and is given mmc1.
I haven't yet been able to figure out why there's been this change
of probe order. There's no change that I can see in the iMX6 DT
files that would account for this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Default atomic_pool_size value & changing it
From: Russell King - ARM Linux @ 2016-11-15 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6ryHrkhxF-HKDB-+if=7XC9D=89oTEVyR9PJWpYAWnoVzw@mail.gmail.com>
On Tue, Nov 15, 2016 at 10:15:51PM +0100, Rafa? Mi?ecki wrote:
> I've hit problem with allocating enough coherent DMA memory. Obviously
> there is a limit of this memory as pointed by:
> [ 0.283667] DMA: preallocated 256 KiB pool for atomic coherent allocations
This is for _atomic_ coherent allocations, not for normal coherent
allocations. Normal coherent allocations come from the CMA memory.
Make sure you have CMA enabled, and you have enough of it.
Boot with cma=xxxMB with xxx set appropriately.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Tim Harvey @ 2016-11-15 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115213510.GY1041@n2100.armlinux.org.uk>
On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
>> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > So, someone merged a patch which makes mmcblk devices follow the
>> > host controller numbering.
>> >
>> > Now my cubox-i fails to boot correctly because the SD card in the
>> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
>> >
>> > USDHC1 is wired to the on-microsom WiFi, and never has anything
>> > remotely near a SD card or eMMC present. So, this change is
>> > confusing on these platforms.
>> >
>> > Moreover, this is _going_ to break SolidRun distros if people upgrade
>> > their kernels.
>> >
>> > It may be appropriate for eMMC, but it's not appropriate everywhere.
>> >
>> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
>> > please revert whatever change caused this, and next time limit it
>> > to only eMMC.
>> >
>> > Thanks.
>>
>> I see the same thing on newer kernels, which is why I asked the
>> question. I didn't expect (or even want honestly) a non mmcblk0 boot
>> device and was looking for a way to control that via dt. Now I'm
>> understanding that to avoid this kind of bootloader/kernel dependence
>> issue I should be using UUID's to identify the boot device.
>>
>> >From my testing it looks like the change your looking for occurred
>> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
>> regression specifically.
>
> That depends how you look at it. Yes, there's a change in 4.5 to 4.6
> which ties the block device number to the host device index, but that's
> really only part of the story here.
>
> 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
> 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
> of behaviour - there can be no argument about that.
>
> Now, digging further into this today, it appears that:
>
> v4.8: usdhc2 was probed first, and is given mmc0.
> usdhc1 is probed second, and is given mmc1.
>
> v4.9-rc: usdhc1 is probed first, and is given mmc0.
> usdhc2 is probed second, and is given mmc1.
>
> I haven't yet been able to figure out why there's been this change
> of probe order. There's no change that I can see in the iMX6 DT
> files that would account for this.
>
I bisected it and the commit your looking for is
9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
Tim
^ permalink raw reply
* Default atomic_pool_size value & changing it
From: Rafał Miłecki @ 2016-11-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115213706.GZ1041@n2100.armlinux.org.uk>
On 15 November 2016 at 22:37, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 15, 2016 at 10:15:51PM +0100, Rafa? Mi?ecki wrote:
>> I've hit problem with allocating enough coherent DMA memory. Obviously
>> there is a limit of this memory as pointed by:
>> [ 0.283667] DMA: preallocated 256 KiB pool for atomic coherent allocations
>
> This is for _atomic_ coherent allocations, not for normal coherent
> allocations. Normal coherent allocations come from the CMA memory.
> Make sure you have CMA enabled, and you have enough of it.
>
> Boot with cma=xxxMB with xxx set appropriately.
Oh, that definitely sounds like worth trying
# CONFIG_CMA is not set
thanks for pointing it to me!
--
Rafa?
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-15 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2t5f=HQ94_GW-cry7DV3FsR9Vx-ck_E-eNuDk5vd-eaw@mail.gmail.com>
On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
> On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
> >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
> >> <linux@armlinux.org.uk> wrote:
> >> > So, someone merged a patch which makes mmcblk devices follow the
> >> > host controller numbering.
> >> >
> >> > Now my cubox-i fails to boot correctly because the SD card in the
> >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
> >> >
> >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
> >> > remotely near a SD card or eMMC present. So, this change is
> >> > confusing on these platforms.
> >> >
> >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
> >> > their kernels.
> >> >
> >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
> >> >
> >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
> >> > please revert whatever change caused this, and next time limit it
> >> > to only eMMC.
> >> >
> >> > Thanks.
> >>
> >> I see the same thing on newer kernels, which is why I asked the
> >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
> >> device and was looking for a way to control that via dt. Now I'm
> >> understanding that to avoid this kind of bootloader/kernel dependence
> >> issue I should be using UUID's to identify the boot device.
> >>
> >> >From my testing it looks like the change your looking for occurred
> >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
> >> regression specifically.
> >
> > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
> > which ties the block device number to the host device index, but that's
> > really only part of the story here.
> >
> > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
> > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
> > of behaviour - there can be no argument about that.
> >
> > Now, digging further into this today, it appears that:
> >
> > v4.8: usdhc2 was probed first, and is given mmc0.
> > usdhc1 is probed second, and is given mmc1.
> >
> > v4.9-rc: usdhc1 is probed first, and is given mmc0.
> > usdhc2 is probed second, and is given mmc1.
> >
> > I haven't yet been able to figure out why there's been this change
> > of probe order. There's no change that I can see in the iMX6 DT
> > files that would account for this.
> >
>
> I bisected it and the commit your looking for is
> 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
No it's not.
Let me try and put it plainer:
* Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
device number (mmcblkN) to the mmc host interface number (mmcN).
This change happened between 4.5 and 4.6.
* The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
seeing a change of behaviour between 4.5 and 4.6.
* The change I'm seeing changes the order of the physical device
associated with the hosts named mmc0 and mmc1 in the kernel.
* Because physical devices associated with the mmc0 and mmc1 hosts
swap over, the mmcblkN number changes due to the commit you point
out.
* So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
else changing the order in which the two usdhc physical hardware
blocks get probed.
Does this make it clearer?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 01/10] ASoC: sunxi: Add bindings for A23/A33/H3 codec's analog path controls
From: Rob Herring @ 2016-11-15 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-2-wens@csie.org>
On Sat, Nov 12, 2016 at 02:46:39PM +0800, Chen-Yu Tsai wrote:
> The internal codec on A23/A33/H3 is split into 2 parts. The
> analog path controls are routed through an embedded custom register
> bus accessed through the PRCM block.
>
> The SoCs share a common set of inputs, outputs, and audio paths.
> The following table lists the differences.
>
> ----------------------------------------
> | Feature \ SoC | A23 | A33 | H3 |
> ----------------------------------------
> | Headphone | v | v | |
> ----------------------------------------
> | Line Out | | | v |
> ----------------------------------------
> | Phone In/Out | v | v | |
> ----------------------------------------
>
> Add a binding for this hardware.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/sound/sun8i-codec-analog.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 04/10] ASoC: sun4i-codec: Add support for A23 codec
From: Rob Herring @ 2016-11-15 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-5-wens@csie.org>
On Sat, Nov 12, 2016 at 02:46:42PM +0800, Chen-Yu Tsai wrote:
> The codec in the A23 is similar to the one found on the A31. One key
> difference is the analog path controls are routed through the PRCM
> block. This is supported by the sun8i-codec-analog driver, and tied
> into this codec driver with the audio card's aux_dev.
>
> In addition, the A23 does not have LINEOUT, and it does not support
> headset jack detection or buttons.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/sound/sun4i-codec.txt | 11 ++-
Acked-by: Rob Herring <robh@kernel.org>
> sound/soc/sunxi/sun4i-codec.c | 108 +++++++++++++++++++++
> 2 files changed, 117 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 08/10] ASoC: sun4i-codec: Add support for H3 codec
From: Rob Herring @ 2016-11-15 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-9-wens@csie.org>
On Sat, Nov 12, 2016 at 02:46:46PM +0800, Chen-Yu Tsai wrote:
> The codec on the H3 is similar to the one found on the A31. One key
> difference is the analog path controls are routed through the PRCM
> block. This is supported by the sun8i-codec-analog driver, and tied
> into this codec driver with the audio card's aux_dev.
>
> In addition, the H3 has no HP (headphone) and HBIAS support, and no
> MIC3 input. The FIFO related registers are slightly rearranged.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/sound/sun4i-codec.txt | 3 +
Acked-by: Rob Herring <robh@kernel.org>
> sound/soc/sunxi/sun4i-codec.c | 71 ++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
^ permalink raw reply
* [PATCH v2 0/3] Rockchip: generalize GRF setup
From: Heiko Stuebner @ 2016-11-15 22:38 UTC (permalink / raw)
To: linux-arm-kernel
The General register files contain a big bunch of settings for various
components. Things like the automatic sdmmc/jtag switch may even affect
us in a bad way, while that property (and possibly others) are not even
part of the dw_mmc controller itself.
And while the rk3288 could still carry adaptions to these defaults
in its mach files, this is no longer possible on the arm64 socs, while
things like the jtag-switch from above still can affect us there.
changes in v2:
- address comments from Doug Anderson
- drop platform device, as we actual probing may happen at some
unspecified later time during boot
- add reviews / acks received in v1
Heiko Stuebner (3):
dt-bindings: add used but undocumented rockchip grf compatible values
soc: rockchip: add driver handling grf setup
ARM: rockchip: drop rk3288 jtag/mmc switch handling
.../devicetree/bindings/soc/rockchip/grf.txt | 4 +
arch/arm/mach-rockchip/rockchip.c | 12 --
drivers/soc/rockchip/Kconfig | 10 ++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/grf.c | 134 +++++++++++++++++++++
5 files changed, 149 insertions(+), 12 deletions(-)
create mode 100644 drivers/soc/rockchip/grf.c
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: add used but undocumented rockchip grf compatible values
From: Heiko Stuebner @ 2016-11-15 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115223900.30728-1-heiko@sntech.de>
There are some more General Register Files used in devicetree files
already, but as of now undocumented in the binding document, fix that.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/grf.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index 013e71a..c6e62cb 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -5,11 +5,13 @@ is composed of many registers for system control.
From RK3368 SoCs, the GRF is divided into two sections,
- GRF, used for general non-secure system,
+- SGRF, used for general secure system,
- PMUGRF, used for always on system
Required Properties:
- compatible: GRF should be one of the followings
+ - "rockchip,rk3036-grf", "syscon": for rk3036
- "rockchip,rk3066-grf", "syscon": for rk3066
- "rockchip,rk3188-grf", "syscon": for rk3188
- "rockchip,rk3228-grf", "syscon": for rk3228
@@ -19,6 +21,8 @@ Required Properties:
- compatible: PMUGRF should be one of the followings
- "rockchip,rk3368-pmugrf", "syscon": for rk3368
- "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- compatible: SGRF should be one of the following
+ - "rockchip,rk3288-sgrf", "syscon": for rk3288
- reg: physical base address of the controller and length of memory mapped
region.
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Heiko Stuebner @ 2016-11-15 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115223900.30728-1-heiko@sntech.de>
The General Register Files are an area of registers containing a lot
of single-bit settings for numerous components as well full components
like usbphy control. Therefore all used components are accessed
via the syscon provided by the grf nodes or from the sub-devices
created through the simple-mfd created from the grf node.
Some settings are not used by anything but will need to be set up
according to expectations on the kernel side.
Best example is the force_jtag setting, which defaults to on and
results in the soc switching the pin-outputs between jtag and sdmmc
automatically depending on the card-detect status. This conflicts
heavily with how the dw_mmc driver expects to do its work and also
with the clock-controller, which has most likely deactivated the
jtag clock due to it being unused.
So far the handling of this setting was living in the mach-rockchip
code for the arm32-based rk3288 but that of course doesn't work
for arm64 socs and would also look ugly for further arm32 socs.
Also always disabling this setting is quite specific to linux and
its subsystems, other operating systems might prefer other settings,
so that the bootloader cannot really set a sane default for all.
So introduce a top-level driver for the grf that handles these
settings that need to be a certain way but nobody cares about.
Other needed settings might surface in the future and can then
be added here, but only as a last option. Ideally general GRF
settings should be handled in the driver needing them.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/soc/rockchip/Kconfig | 10 ++++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/grf.c | 134 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 145 insertions(+)
create mode 100644 drivers/soc/rockchip/grf.c
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
index 7140ff8..20da55d 100644
--- a/drivers/soc/rockchip/Kconfig
+++ b/drivers/soc/rockchip/Kconfig
@@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
#
# Rockchip Soc drivers
#
+
+config ROCKCHIP_GRF
+ bool
+ default y
+ help
+ The General Register Files are a central component providing
+ special additional settings registers for a lot of soc-components.
+ In a lot of cases there also need to be default settings initialized
+ to make some of them conform to expectations of the kernel.
+
config ROCKCHIP_PM_DOMAINS
bool "Rockchip generic power domain"
depends on PM
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
index 3d73d06..c851fa0 100644
--- a/drivers/soc/rockchip/Makefile
+++ b/drivers/soc/rockchip/Makefile
@@ -1,4 +1,5 @@
#
# Rockchip Soc drivers
#
+obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
new file mode 100644
index 0000000..0c85476a
--- /dev/null
+++ b/drivers/soc/rockchip/grf.c
@@ -0,0 +1,134 @@
+/*
+ * Rockchip Generic Register Files setup
+ *
+ * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define HIWORD_UPDATE(val, mask, shift) \
+ ((val) << (shift) | (mask) << ((shift) + 16))
+
+struct rockchip_grf_value {
+ const char *desc;
+ u32 reg;
+ u32 val;
+};
+
+struct rockchip_grf_info {
+ const struct rockchip_grf_value *values;
+ int num_values;
+};
+
+#define RK3036_GRF_SOC_CON0 0x140
+
+static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
+ /*
+ * Disable auto jtag/sdmmc switching that causes issues with the
+ * clock-framework and the mmc controllers making them unreliable.
+ */
+ { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11) },
+};
+
+static const struct rockchip_grf_info rk3036_grf __initconst = {
+ .values = rk3036_defaults,
+ .num_values = ARRAY_SIZE(rk3036_defaults),
+};
+
+#define RK3288_GRF_SOC_CON0 0x244
+
+static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
+ { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
+};
+
+static const struct rockchip_grf_info rk3288_grf __initconst = {
+ .values = rk3288_defaults,
+ .num_values = ARRAY_SIZE(rk3288_defaults),
+};
+
+#define RK3368_GRF_SOC_CON15 0x43c
+
+static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
+ { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13) },
+};
+
+static const struct rockchip_grf_info rk3368_grf __initconst = {
+ .values = rk3368_defaults,
+ .num_values = ARRAY_SIZE(rk3368_defaults),
+};
+
+#define RK3399_GRF_SOC_CON7 0xe21c
+
+static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
+ { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12) },
+};
+
+static const struct rockchip_grf_info rk3399_grf __initconst = {
+ .values = rk3399_defaults,
+ .num_values = ARRAY_SIZE(rk3399_defaults),
+};
+
+static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
+ {
+ .compatible = "rockchip,rk3036-grf",
+ .data = (void *)&rk3036_grf,
+ }, {
+ .compatible = "rockchip,rk3288-grf",
+ .data = (void *)&rk3288_grf,
+ }, {
+ .compatible = "rockchip,rk3368-grf",
+ .data = (void *)&rk3368_grf,
+ }, {
+ .compatible = "rockchip,rk3399-grf",
+ .data = (void *)&rk3399_grf,
+ },
+ { /* sentinel */ },
+};
+
+static int __init rockchip_grf_init(void)
+{
+ const struct rockchip_grf_info *grf_info;
+ const struct of_device_id *match;
+ struct device_node *np;
+ struct regmap *grf;
+ int ret, i;
+
+ np = of_find_matching_node_and_match(NULL, rockchip_grf_dt_match, &match);
+ if (!np)
+ return -ENODEV;
+ if (!match || !match->data) {
+ pr_err("%s: missing grf data\n", __func__);
+ return -EINVAL;
+ }
+
+ grf_info = match->data;
+
+ grf = syscon_node_to_regmap(np);
+ if (IS_ERR(grf)) {
+ pr_err("%s: could not get grf syscon\n", __func__);
+ return PTR_ERR(grf);
+ }
+
+ for (i = 0; i < grf_info->num_values; i++) {
+ const struct rockchip_grf_value *val = &grf_info->values[i];
+
+ pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
+ val->desc, val->reg, val->val);
+ ret = regmap_write(grf, val->reg, val->val);
+ if (ret < 0)
+ pr_err("%s: write to %#6x failed with %d\n",
+ __func__, val->reg, ret);
+ }
+
+ return 0;
+}
+postcore_initcall(rockchip_grf_init);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/3] ARM: rockchip: drop rk3288 jtag/mmc switch handling
From: Heiko Stuebner @ 2016-11-15 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115223900.30728-1-heiko@sntech.de>
We moved that functionality to a more generic place where it can also
be used for other socs, so drop it from architecture code.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
---
arch/arm/mach-rockchip/rockchip.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c
index e7fdf06..0008783 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -29,13 +29,11 @@
#include "core.h"
#include "pm.h"
-#define RK3288_GRF_SOC_CON0 0x244
#define RK3288_TIMER6_7_PHYS 0xff810000
static void __init rockchip_timer_init(void)
{
if (of_machine_is_compatible("rockchip,rk3288")) {
- struct regmap *grf;
void __iomem *reg_base;
/*
@@ -54,16 +52,6 @@ static void __init rockchip_timer_init(void)
} else {
pr_err("rockchip: could not map timer7 registers\n");
}
-
- /*
- * Disable auto jtag/sdmmc switching that causes issues
- * with the mmc controllers making them unreliable
- */
- grf = syscon_regmap_lookup_by_compatible("rockchip,rk3288-grf");
- if (!IS_ERR(grf))
- regmap_write(grf, RK3288_GRF_SOC_CON0, 0x10000000);
- else
- pr_err("rockchip: could not get grf syscon\n");
}
of_clk_init(NULL);
--
2.10.2
^ permalink raw reply related
* [RFCv2 PATCH 3/5] drm/bridge: dw_hdmi: add HDMI notifier support
From: Pierre-Hugues Husson @ 2016-11-15 23:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479136968-24477-4-git-send-email-hverkuil@xs4all.nl>
Hi Hans,
2016-11-14 16:22 GMT+01:00 Hans Verkuil <hverkuil@xs4all.nl>:
> From: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Add HDMI notifiers to the HDMI bridge driver.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/gpu/drm/bridge/Kconfig | 1 +
> drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++++++++++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 10e12e7..5f4ebe9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -27,6 +27,7 @@ config DRM_DUMB_VGA_DAC
> config DRM_DW_HDMI
> tristate
> select DRM_KMS_HELPER
> + select HDMI_NOTIFIERS
>
> config DRM_DW_HDMI_AHB_AUDIO
> tristate "Synopsis Designware AHB Audio interface"
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
> index ab7023e..bd02da5 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -16,6 +16,7 @@
> #include <linux/err.h>
> #include <linux/clk.h>
> #include <linux/hdmi.h>
> +#include <linux/hdmi-notifier.h>
> #include <linux/mutex.h>
> #include <linux/of_device.h>
> #include <linux/spinlock.h>
> @@ -114,6 +115,7 @@ struct dw_hdmi {
>
> struct hdmi_data_info hdmi_data;
> const struct dw_hdmi_plat_data *plat_data;
> + struct hdmi_notifier *n;
>
> int vic;
>
> @@ -1448,9 +1450,11 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector)
> hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> drm_mode_connector_update_edid_property(connector, edid);
> + hdmi_event_new_edid(hdmi->n, edid, 0);
> ret = drm_add_edid_modes(connector, edid);
> /* Store the ELD */
> drm_edid_to_eld(connector, edid);
> + hdmi_event_new_eld(hdmi->n, connector->eld);
> kfree(edid);
> } else {
> dev_dbg(hdmi->dev, "failed to get edid\n");
> @@ -1579,6 +1583,12 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> dw_hdmi_update_phy_mask(hdmi);
> }
> mutex_unlock(&hdmi->mutex);
> +
> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> + hdmi_event_disconnect(hdmi->n);
> + else if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) ==
> + (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_PHY_HPD))
> + hdmi_event_connect(hdmi->n);
> }
>
> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> @@ -1732,11 +1742,17 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
>
> initialize_hdmi_ih_mutes(hdmi);
>
> + hdmi->n = hdmi_notifier_get(dev);
> + if (!hdmi->n) {
> + ret = -ENOMEM;
> + goto err_iahb;
> + }
> +
> ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
> dw_hdmi_irq, IRQF_SHARED,
> dev_name(dev), hdmi);
> if (ret)
> - goto err_iahb;
> + goto err_hdmi_not;
>
> /*
> * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
> @@ -1788,6 +1804,8 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
>
> return 0;
>
> +err_hdmi_not:
> + hdmi_notifier_put(hdmi->n);
> err_iahb:
> clk_disable_unprepare(hdmi->iahb_clk);
> err_isfr:
> @@ -1804,6 +1822,11 @@ void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
> if (hdmi->audio && !IS_ERR(hdmi->audio))
> platform_device_unregister(hdmi->audio);
>
> + hdmi_notifier_put(hdmi->n);
> +
> + if (!IS_ERR(hdmi->cec))
> + platform_device_unregister(hdmi->cec);
Those two lines should be in your 4/5
> +
> /* Disable all interrupts */
> hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
^ permalink raw reply
* [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions
From: Pierre-Hugues Husson @ 2016-11-15 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479136968-24477-3-git-send-email-hverkuil@xs4all.nl>
Hi,
2016-11-14 16:22 GMT+01:00 Hans Verkuil <hverkuil@xs4all.nl>:
> From: Russell King <rmk+kernel@arm.linux.org.uk>
>
> We don't need the CEC engine register definitions, so let's remove them.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/gpu/drm/bridge/dw-hdmi.h | 45 ----------------------------------------
> 1 file changed, 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
> index fc9a560..26d6845 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -478,51 +478,6 @@
> #define HDMI_A_PRESETUP 0x501A
> #define HDMI_A_SRM_BASE 0x5020
>
> -/* CEC Engine Registers */
> -#define HDMI_CEC_CTRL 0x7D00
> -#define HDMI_CEC_STAT 0x7D01
> -#define HDMI_CEC_MASK 0x7D02
I don't know if this is relevant for a submission, but the build stops
working here because of a missing definition HDMI_CEC_MASK
Perhaps this should be inverted with 3/5 to make bissecting easier?
I was trying to bissect a kernel panic, and I had to fix this by hand
> -#define HDMI_CEC_POLARITY 0x7D03
> -#define HDMI_CEC_INT 0x7D04
> -#define HDMI_CEC_ADDR_L 0x7D05
> -#define HDMI_CEC_ADDR_H 0x7D06
> -#define HDMI_CEC_TX_CNT 0x7D07
> -#define HDMI_CEC_RX_CNT 0x7D08
> -#define HDMI_CEC_TX_DATA0 0x7D10
> -#define HDMI_CEC_TX_DATA1 0x7D11
> -#define HDMI_CEC_TX_DATA2 0x7D12
> -#define HDMI_CEC_TX_DATA3 0x7D13
> -#define HDMI_CEC_TX_DATA4 0x7D14
> -#define HDMI_CEC_TX_DATA5 0x7D15
> -#define HDMI_CEC_TX_DATA6 0x7D16
> -#define HDMI_CEC_TX_DATA7 0x7D17
> -#define HDMI_CEC_TX_DATA8 0x7D18
> -#define HDMI_CEC_TX_DATA9 0x7D19
> -#define HDMI_CEC_TX_DATA10 0x7D1a
> -#define HDMI_CEC_TX_DATA11 0x7D1b
> -#define HDMI_CEC_TX_DATA12 0x7D1c
> -#define HDMI_CEC_TX_DATA13 0x7D1d
> -#define HDMI_CEC_TX_DATA14 0x7D1e
> -#define HDMI_CEC_TX_DATA15 0x7D1f
> -#define HDMI_CEC_RX_DATA0 0x7D20
> -#define HDMI_CEC_RX_DATA1 0x7D21
> -#define HDMI_CEC_RX_DATA2 0x7D22
> -#define HDMI_CEC_RX_DATA3 0x7D23
> -#define HDMI_CEC_RX_DATA4 0x7D24
> -#define HDMI_CEC_RX_DATA5 0x7D25
> -#define HDMI_CEC_RX_DATA6 0x7D26
> -#define HDMI_CEC_RX_DATA7 0x7D27
> -#define HDMI_CEC_RX_DATA8 0x7D28
> -#define HDMI_CEC_RX_DATA9 0x7D29
> -#define HDMI_CEC_RX_DATA10 0x7D2a
> -#define HDMI_CEC_RX_DATA11 0x7D2b
> -#define HDMI_CEC_RX_DATA12 0x7D2c
> -#define HDMI_CEC_RX_DATA13 0x7D2d
> -#define HDMI_CEC_RX_DATA14 0x7D2e
> -#define HDMI_CEC_RX_DATA15 0x7D2f
> -#define HDMI_CEC_LOCK 0x7D30
> -#define HDMI_CEC_WKUPCTRL 0x7D31
> -
> /* I2C Master Registers (E-DDC) */
> #define HDMI_I2CM_SLAVE 0x7E00
> #define HDMI_I2CM_ADDRESS 0x7E01
> --
> 2.8.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions
From: Russell King - ARM Linux @ 2016-11-15 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjS-VVkBuYh0inTGAvJbsKzvEqKYrgoSeG6UBQtW_1BEyQ@mail.gmail.com>
On Wed, Nov 16, 2016 at 12:23:50AM +0100, Pierre-Hugues Husson wrote:
> Hi,
>
>
> 2016-11-14 16:22 GMT+01:00 Hans Verkuil <hverkuil@xs4all.nl>:
> > From: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > We don't need the CEC engine register definitions, so let's remove them.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > drivers/gpu/drm/bridge/dw-hdmi.h | 45 ----------------------------------------
> > 1 file changed, 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
> > index fc9a560..26d6845 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> > @@ -478,51 +478,6 @@
> > #define HDMI_A_PRESETUP 0x501A
> > #define HDMI_A_SRM_BASE 0x5020
> >
> > -/* CEC Engine Registers */
> > -#define HDMI_CEC_CTRL 0x7D00
> > -#define HDMI_CEC_STAT 0x7D01
> > -#define HDMI_CEC_MASK 0x7D02
> I don't know if this is relevant for a submission, but the build stops
> working here because of a missing definition HDMI_CEC_MASK
> Perhaps this should be inverted with 3/5 to make bissecting easier?
> I was trying to bissect a kernel panic, and I had to fix this by hand
Doesn't make sense - patch 3 doesn't reference HDMI_CEC_MASK.
Please show the build error in full.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.10
From: Kevin Hilman @ 2016-11-15 23:28 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here are the arm64 DT changes for Amlogic family SoCs.
Please pull,
Thanks,
Kevin
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
for you to fetch changes up to ab5b24fdd2d551ea729e8e19e47811a646260331:
ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes (2016-11-15 12:05:54 -0800)
----------------------------------------------------------------
Amlogic DT changes for 64-bit platforms for v4.10
Support for new drivers:
- USB
- i2c
- SPI
- mailbox/MHU
- PWM
- ethernet MAC, PHY
- secure monitor
- IR
- watchdog
----------------------------------------------------------------
Andreas F?rber (1):
ARM64: dts: amlogic: Reorder copyrights for meson-gx
Brian Kim (1):
ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes
Carlo Caione (1):
ARM64: dts: amlogic: Add basic support for Amlogic S905X
Kevin Hilman (1):
ARM64: dts: meson-gxbb: add MMC support
Martin Blumenstingl (1):
ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
Neil Armstrong (22):
ARM64: dts: amlogic: Add Meson GX dtsi from GXBB
ARM64: dts: amlogic: Add basic support for Amlogic S905D
devicetree: Add vendor prefix for Nexbox
ARM64: dts: meson-gxbb: Add support for the Nexbox A95X Board
ARM64: dts: meson-gx: Add missing L2 cache node
ARM64: dts: meson-gxbb: Add rmii pinctrl node and rename rgmii node
ARM64: dts: meson-gxbb: Add Wifi 32K clock for p20x boards
ARM64: dts: meson-gxbb: Add P20x Wifi SDIO support
ARM64: dts: meson-gxbb: Add MMC nodes to Nexbox A95x
ARM64: dts: meson-gxbb: Add SRAM node
ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes
ARM64: dts: meson-gxbb: Move common nodes to meson-gx
ARM64: dts: meson-gxl: Add pinctrl nodes
ARM64: dts: meson-gxl: Add clock nodes
ARM64: dts: meson-gxl: Add i2c nodes
ARM64: dts: meson-gxl: Add MMC/SD/SDIO nodes
ARM64: dts: meson-gxl-p23x: Add uart pinctrl
ARM64: dts: meson-gxl-p23x: Add SD/SDIO/MMC and PWM nodes
ARM64: dts: meson-gxl-p23x: Enable IR receiver
ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY
ARM64: dts: meson-gxl-p23x: Enable ethernet
ARM64: dts: meson-gxl-s905x: Enable internal ethernet PHY
Documentation/devicetree/bindings/arm/amlogic.txt | 11 ++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 4 +
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 360 ++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 231 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 119 +++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 129 +++++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 106 ++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 900 +++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------------------
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 76 +++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 57 ++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 188 +++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi | 48 +++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 69 ++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 54 ++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 301 ++++++++++++++++++++++++++++++++++++++++
16 files changed, 2120 insertions(+), 534 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gx.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
^ permalink raw reply
* [GIT PULL] Amlogic defconfig changes for v4.10
From: Kevin Hilman @ 2016-11-15 23:29 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here are some defconfig change for Amlogic family SoCs for 4.10. Please
pull.
Thanks,
Kevin
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-defconfig
for you to fetch changes up to 88c9cb7c109e8867fd6ac3a11e5cead37a6a6f1d:
ARM64: configs: Activate Internal PHY for Meson GXL (2016-11-14 08:40:47 -0800)
----------------------------------------------------------------
Amlogic defconfig updates for v4.10
- enable I2C driver
- enable SPI, watchdog and HW random as modules
----------------------------------------------------------------
Neil Armstrong (3):
ARM64: defconfig: Enable MMC related configs
ARM64: configs: Add Platform MHU in defconfig
ARM64: configs: Activate Internal PHY for Meson GXL
arch/arm64/configs/defconfig | 7 +++++++
1 file changed, 7 insertions(+)
^ permalink raw reply
* [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions
From: Pierre-Hugues Husson @ 2016-11-15 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115232754.GB1041@n2100.armlinux.org.uk>
2016-11-16 0:27 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Wed, Nov 16, 2016 at 12:23:50AM +0100, Pierre-Hugues Husson wrote:
>> Hi,
>>
>>
>> 2016-11-14 16:22 GMT+01:00 Hans Verkuil <hverkuil@xs4all.nl>:
>> > From: Russell King <rmk+kernel@arm.linux.org.uk>
>> >
>> > We don't need the CEC engine register definitions, so let's remove them.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> > ---
>> > drivers/gpu/drm/bridge/dw-hdmi.h | 45 ----------------------------------------
>> > 1 file changed, 45 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
>> > index fc9a560..26d6845 100644
>> > --- a/drivers/gpu/drm/bridge/dw-hdmi.h
>> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
>> > @@ -478,51 +478,6 @@
>> > #define HDMI_A_PRESETUP 0x501A
>> > #define HDMI_A_SRM_BASE 0x5020
>> >
>> > -/* CEC Engine Registers */
>> > -#define HDMI_CEC_CTRL 0x7D00
>> > -#define HDMI_CEC_STAT 0x7D01
>> > -#define HDMI_CEC_MASK 0x7D02
>> I don't know if this is relevant for a submission, but the build stops
>> working here because of a missing definition HDMI_CEC_MASK
>> Perhaps this should be inverted with 3/5 to make bissecting easier?
>> I was trying to bissect a kernel panic, and I had to fix this by hand
>
> Doesn't make sense - patch 3 doesn't reference HDMI_CEC_MASK.
>
> Please show the build error in full.
The build is actually fixed with patch 4.
Building after patch 2 fails with:
drivers/gpu/drm/bridge/dw-hdmi.c: In function ?initialize_hdmi_ih_mutes?:
drivers/gpu/drm/bridge/dw-hdmi.c:1300:26: error: ?HDMI_CEC_MASK?
undeclared (first use in this function)
hdmi_writeb(hdmi, 0xff, HDMI_CEC_MASK);
The point of switching patch 3 and patch 2, is that the build works
with patch 1,3 applied.
Applying patch 2 breaks the build, but doesn't change any active code,
so it's ok.
So with the order 1,3,2,4,5, the build is broken only after 2, while
with 1,2,3,4,5, it is broken after 2 and 3.
I hope this makes my remark more explicit.
If it doesn't, I think it is quite safe to just ignore it
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Stephen Boyd @ 2016-11-15 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9GVNqXwya8hrjmBcK2L0ud-qr7iE54WUPuMNyFtAy80w@mail.gmail.com>
On 11/15, Ard Biesheuvel wrote:
> On 15 November 2016 at 19:18, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 11/15, Ard Biesheuvel wrote:
> >> On 19 October 2016 at 00:42, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >> >
> >> > +static unsigned char ideal_nop4_arm_le[4] = { 0x00, 0x00, 0xa0, 0xe1 }; /* mov r0, r0 */
> >> > +static unsigned char ideal_nop4_arm_be[4] = { 0xe1, 0xa0, 0x00, 0x00 }; /* mov r0, r0 */
> >>
> >> Shouldn't you be taking the difference between BE8 and BE32 into
> >> account here? IIRC, BE8 uses little endian encoding for instructions.
> >
> > I admit I haven't tested on a pre-armv6 CPU so I haven't come
> > across the case of a BE32 CPU. But from what I can tell that
> > doesn't matter.
> >
> > According to scripts/Makefile.build, cmd_record_mcount only runs
> > the recordmcount program if CONFIG_FTRACE_MCOUNT_RECORD=y. That
> > config is defined as:
> >
> > config FTRACE_MCOUNT_RECORD
> > def_bool y
> > depends on DYNAMIC_FTRACE
> > depends on HAVE_FTRACE_MCOUNT_RECORD
> >
> >
> > And in arch/arm/Kconfig we see that DYNAMIC_FTRACE is selected:
> >
> > select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 && MMU
> >
> > which means that FTRACE_MCOUNT_RECORD can't be set when
> > CPU_ENDIAN_BE32 is set.
> >
> > Do you agree that BE32 is not a concern here?
> >
>
> Yes. But that implies then that you should not be using big-endian
> instruction encodings at all, and simply use the _le variants for both
> LE and BE8
Ok. I understand what you're getting at now.
I believe the linker is the one that does the instruction endian
swap to little endian. So everything is built as big-endian data
and instructions in the assembler phase and then when the linker
runs to generate the final vmlinux elf file it does the swaps to
make instructions little endian. recordmcount runs on the object
files and not the vmlinux file.
For example, the do_undefinstr() function in
arch/arm/kernel/traps.c is one place we nop out. On an le host
and an le build without this patch I see:
(This is all ARM, not thumb)
00000000 <do_undefinstr>:
0: e1a0c00d mov ip, sp
4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4
c: e24dd08c sub sp, sp, #140 ; 0x8c
10: e52de004 push {lr} ; (str lr, [sp, #-4]!)
14: ebfffffe bl 0 <__gnu_mcount_nc>
After this patch on an le host and le build I see:
00000000 <do_undefinstr>:
0: e1a0c00d mov ip, sp
4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4
c: e24dd08c sub sp, sp, #140 ; 0x8c
10: e1a00000 nop ; (mov r0, r0)
14: e1a00000 nop ; (mov r0, r0)
So far so good. Similarly, with this patch and an le host and be
build I see:
00000000 <do_undefinstr>:
0: e1a0c00d mov ip, sp
4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4
c: e24dd08c sub sp, sp, #140 ; 0x8c
10: e1a00000 nop ; (mov r0, r0)
14: e1a00000 nop ; (mov r0, r0)
but with *_le instead of *_be used a be build I see:
00000000 <do_undefinstr>:
0: e1a0c00d mov ip, sp
4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4
c: e24dd08c sub sp, sp, #140 ; 0x8c
10: 0000a0e1 andeq sl, r0, r1, ror #1
14: 0000a0e1 andeq sl, r0, r1, ror #1
I confirmed this by looking at the hexdump of the .exception.text
section for the traps.o object file and the .text section of the
vmlinux file. Basically objcopy the .exception.text of traps.o to
get the first few instructions of the do_undefinstr() function:
$ hexdump -C traps.o
00000000 e1 a0 c0 0d e9 2d d9 f0 e2 4c b0 04 e2 4d d0 8c
And then objcopy the .text section in vmlinux and seek to the
same function offset (there are a bunch of zeroes in front of it
for padding):
$ hexdump -C vmlinux
...
00001000 0d c0 a0 e1 f0 d9 2d e9 04 b0 4c e2 8c d0 4d e2
As can be seen everything is swapped from the original object
file in big-endian to be in little endian.
Does that allay your concerns?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-15 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115221002.GA1041@n2100.armlinux.org.uk>
On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
> > >> <linux@armlinux.org.uk> wrote:
> > >> > So, someone merged a patch which makes mmcblk devices follow the
> > >> > host controller numbering.
> > >> >
> > >> > Now my cubox-i fails to boot correctly because the SD card in the
> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
> > >> >
> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
> > >> > remotely near a SD card or eMMC present. So, this change is
> > >> > confusing on these platforms.
> > >> >
> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
> > >> > their kernels.
> > >> >
> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
> > >> >
> > >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
> > >> > please revert whatever change caused this, and next time limit it
> > >> > to only eMMC.
> > >> >
> > >> > Thanks.
> > >>
> > >> I see the same thing on newer kernels, which is why I asked the
> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
> > >> device and was looking for a way to control that via dt. Now I'm
> > >> understanding that to avoid this kind of bootloader/kernel dependence
> > >> issue I should be using UUID's to identify the boot device.
> > >>
> > >> >From my testing it looks like the change your looking for occurred
> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
> > >> regression specifically.
> > >
> > > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
> > > which ties the block device number to the host device index, but that's
> > > really only part of the story here.
> > >
> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
> > > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
> > > of behaviour - there can be no argument about that.
> > >
> > > Now, digging further into this today, it appears that:
> > >
> > > v4.8: usdhc2 was probed first, and is given mmc0.
> > > usdhc1 is probed second, and is given mmc1.
> > >
> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
> > > usdhc2 is probed second, and is given mmc1.
> > >
> > > I haven't yet been able to figure out why there's been this change
> > > of probe order. There's no change that I can see in the iMX6 DT
> > > files that would account for this.
> > >
> >
> > I bisected it and the commit your looking for is
> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>
> No it's not.
>
> Let me try and put it plainer:
>
> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
> device number (mmcblkN) to the mmc host interface number (mmcN).
> This change happened between 4.5 and 4.6.
>
> * The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
> seeing a change of behaviour between 4.5 and 4.6.
>
> * The change I'm seeing changes the order of the physical device
> associated with the hosts named mmc0 and mmc1 in the kernel.
>
> * Because physical devices associated with the mmc0 and mmc1 hosts
> swap over, the mmcblkN number changes due to the commit you point
> out.
>
> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
> by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
> else changing the order in which the two usdhc physical hardware
> blocks get probed.
>
> Does this make it clearer?
It turns out to be this commit:
commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Mon Sep 19 01:16:44 2016 +0900
clk: probe common clock drivers earlier
Several SoCs implement platform drivers for clocks rather than
CLK_OF_DECLARE(). Clocks should come earlier because they are
prerequisites for many of other drivers. It will help to mitigate
EPROBE_DEFER issues.
Also, drop the comment since it does not carry much value.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
which changes the init order. In 4.8, we get:
calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
platform usdhc1_pwrseq: Driver pwrseq_simple requests probe deferral
platform usdhc1_pwrseq: Added to deferred list
initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 737 usecs
which then goes on to cause:
calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
platform 2190000.usdhc: Driver sdhci-esdhc-imx requests probe deferral
platform 2190000.usdhc: Added to deferred list
followed by:
bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 58205 usecs
and eventually:
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new ultra high speed SDR104 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.9 GiB
mmcblk0: p1 p2
In 4.9-rc5, we instead get:
calling gpio_clk_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device sdio-clock with driver gpio-clk
bus: 'platform': really_probe: probing driver gpio-clk with device sdio-clock
driver: 'gpio-clk': driver_bound: bound to device 'sdio-clock'
bus: 'platform': really_probe: bound device sdio-clock to driver gpio-clk
...
calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
driver: 'pwrseq_simple': driver_bound: bound to device 'usdhc1_pwrseq'
bus: 'platform': really_probe: bound device usdhc1_pwrseq to driver pwrseq_simple
initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 876 usecs
...
calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2190000.usdhc'
bus: 'platform': really_probe: bound device 2190000.usdhc to driver sdhci-esdhc-imx
bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 384864 usecs
...
mmc1: host does not support reading read-only switch, assuming write-enable
mmc1: new ultra high speed SDR104 SDHC card at address 0001
mmcblk1: mmc1:0001 00000 14.9 GiB
mmcblk1: p1 p2
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] clk: rockchip: rk3399: fix copy-paste error
From: Jianqun Xu @ 2016-11-16 0:07 UTC (permalink / raw)
To: linux-arm-kernel
Fix RK3368_CLKSEL_CON to RK3399_CLKSEL_CON for rk3399 clock
driver.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 2c7cba7..2bde6cd 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1382,8 +1382,8 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = {
/* clk_test */
/* clk_test_pre is controlled by CRU_MISC_CON[3] */
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
- RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
- RK3368_CLKGATE_CON(13), 11, GFLAGS),
+ RK3399_CLKSEL_CON(58), 0, 5, DFLAGS,
+ RK3399_CLKSEL_CON(13), 11, GFLAGS),
/* ddrc */
GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Rob Herring @ 2016-11-16 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479101215-26954-2-git-send-email-sriram.dash@nxp.com>
On Mon, Nov 14, 2016 at 10:56:54AM +0530, Sriram Dash wrote:
> Adds qoriq usb 3.0 phy driver support for LS1043A platform.
> Describes the qoriq usb 2.0 phy driver binding, currently used
> for LS1043A platform.
>
> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> ---
> .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36 ++++
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-qoriq-usb3.c | 202 +++++++++++++++++++++
> 4 files changed, 247 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> create mode 100644 drivers/phy/phy-qoriq-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> new file mode 100644
> index 0000000..d934c80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> @@ -0,0 +1,36 @@
> +Driver for Freescale USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible : fsl,qoriq-usb3-phy
> +- reg : register mappings for Parameter Configuration Register
> + and Phy base offset.
> +- reg-names : "param_ctrl" and "phy_base"
> +- phy_type : For multi port host USB controllers, should be one of
> + "ulpi", or "serial". For dual role USB controllers,
> + should be one of "ulpi", "utmi", "utmi_wide", or "serial".
Do any of these really apply to a USB3 PHY?
Rob
> +
> +Example:
> + usbphy0: usb3-phy at 084F0000 {
usb-phy at ...
> + compatible = "fsl,qoriq-usb3-phy";
> + reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F0000 0x0 0x5000>;
> + reg-names = "param_ctrl", "phy_base";
> + #phy-cells = <0>;
> + phy_type = "utmi";
> + };
> +
> + usbphy1: usb3-phy at 08500000 {
> + compatible = "fsl,qoriq-usb3-phy";
> + reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x08500000 0x0 0x5000>;
> + reg-names = "param_ctrl", "phy_base";
> + #phy-cells = <0>;
> + phy_type = "utmi";
> + };
> +
> + usbphy2: usb3-phy at 08510000 {
> + compatible = "fsl,qoriq-usb3-phy";
> + reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x08510000 0x0 0x5000>;
> + reg-names = "param_ctrl", "phy_base";
> + #phy-cells = <0>;
> + phy_type = "utmi";
> + };
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-16 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115183508.GJ3096@e104818-lin.cambridge.arm.com>
On 11/15/2016 10:35 AM, Catalin Marinas wrote:
> On Mon, Nov 14, 2016 at 10:41:29AM -0800, Laura Abbott wrote:
>> On 11/14/2016 10:19 AM, Catalin Marinas wrote:
>>> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>>>
>>>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>>>
>>>>>> Nit: s/marco/macro/
>>>>>>
>>>>>> I see there are some other uses of __pa() that look like they could/should be
>>>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>>>
>>>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>>>> that we should not?
>>>>>
>>>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>>>> should eventually be converted for consistency and debugging.
>>>>
>>>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>>>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>>>> for consistency with other architectures.
>>>
>>> At a quick grep, it seems to only be used by mips and x86 and a single
>>> place in mm/memblock.c.
>>>
>>> Since we haven't seen any issues on arm/arm64 without this macro, can we
>>> not just continue to use __pa()?
>>
>> Technically yes but if it's introduced it may be confusing why it's being
>> used some places but not others.
>
> As it currently stands, your patches introduce the first and only use of
> __pa_symbol to arch/arm64. But I don't see the point, unless we replace
> all of the other uses.
>
>> Maybe the bounds in the debug virtual check should just be adjusted so
>> we don't need __pa_symbol along with a nice fat comment explaining
>> why.
>
> I'm fine with __pa_symbol use entirely from under arch/arm64. But if you
> want to use __pa_symbol, I tried to change most (all?) places where
> necessary, together with making virt_to_phys() only deal with the kernel
> linear mapping. Not sure it looks cleaner, especially the
> __va(__pa_symbol()) cases (we could replace the latter with another
> macro and proper comment):
>
I agree everything should be converted over, I was considering doing
that in a separate patch but this covers everything nicely. Are you
okay with me folding this in? (Few comments below)
> -------------8<--------------------------------------
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index a79b969c26fc..fa6c44ebb51f 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -47,7 +47,7 @@
> * If the page is in the bottom half, we have to use the top half. If
> * the page is in the top half, we have to use the bottom half:
> *
> - * T = __virt_to_phys(__hyp_idmap_text_start)
> + * T = __pa_symbol(__hyp_idmap_text_start)
> * if (T & BIT(VA_BITS - 1))
> * HYP_VA_MIN = 0 //idmap in upper half
> * else
> @@ -271,7 +271,7 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)
> kvm_flush_dcache_to_poc(page_address(page), PUD_SIZE);
> }
>
> -#define kvm_virt_to_phys(x) __virt_to_phys((unsigned long)(x))
> +#define kvm_virt_to_phys(x) __pa_symbol((unsigned long)(x))
>
> void kvm_set_way_flush(struct kvm_vcpu *vcpu);
> void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index eac3dbb7e313..e02f45e5ee1b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -169,15 +169,22 @@ extern u64 kimage_voffset;
> */
> #define __virt_to_phys_nodebug(x) ({ \
> phys_addr_t __x = (phys_addr_t)(x); \
> - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
> - (__x - kimage_voffset); })
> + VM_BUG_ON(!(__x & BIT(VA_BITS - 1))); \
> + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
> +})
I do think this is easier to understand vs the ternary operator.
I'll add a comment detailing the use of __pa vs __pa_symbol somewhere
as well.
> +
> +#define __pa_symbol_nodebug(x) ({ \
> + phys_addr_t __x = (phys_addr_t)(x); \
> + VM_BUG_ON(__x & BIT(VA_BITS - 1)); \
> + (__x - kimage_voffset); \
> +})
>
> #ifdef CONFIG_DEBUG_VIRTUAL
> extern unsigned long __virt_to_phys(unsigned long x);
> extern unsigned long __phys_addr_symbol(unsigned long x);
> #else
> #define __virt_to_phys(x) __virt_to_phys_nodebug(x)
> -#define __phys_addr_symbol __pa
> +#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
> #endif
>
> #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
> @@ -210,7 +217,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> * Drivers should NOT use these either.
> */
> #define __pa(x) __virt_to_phys((unsigned long)(x))
> -#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
> +#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
> #define __pa_nodebug(x) __virt_to_phys_nodebug((unsigned long)(x))
> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index a50185375f09..6cf3763c6e11 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -44,7 +44,7 @@ static inline void contextidr_thread_switch(struct task_struct *next)
> */
> static inline void cpu_set_reserved_ttbr0(void)
> {
> - unsigned long ttbr = virt_to_phys(empty_zero_page);
> + unsigned long ttbr = __pa_symbol(empty_zero_page);
>
> write_sysreg(ttbr, ttbr0_el1);
> isb();
> @@ -113,7 +113,7 @@ static inline void cpu_install_idmap(void)
> local_flush_tlb_all();
> cpu_set_idmap_tcr_t0sz();
>
> - cpu_switch_mm(idmap_pg_dir, &init_mm);
> + cpu_switch_mm(__va(__pa_symbol(idmap_pg_dir)), &init_mm);
Yes, the __va(__pa_symbol(..)) idiom needs to be macroized and commented...
> }
>
> /*
> @@ -128,7 +128,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgd)
>
> phys_addr_t pgd_phys = virt_to_phys(pgd);
>
> - replace_phys = (void *)virt_to_phys(idmap_cpu_replace_ttbr1);
> + replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
>
> cpu_install_idmap();
> replace_phys(pgd_phys);
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index ffbb9a520563..c2041a39a3e3 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -52,7 +52,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
> * for zero-mapped memory areas etc..
> */
> extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
> -#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa(empty_zero_page)))
> +#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa_symbol(empty_zero_page)))
>
> #define pte_ERROR(pte) __pte_error(__FILE__, __LINE__, pte_val(pte))
>
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
> index a32b4011d711..df58310660c6 100644
> --- a/arch/arm64/kernel/acpi_parking_protocol.c
> +++ b/arch/arm64/kernel/acpi_parking_protocol.c
> @@ -109,7 +109,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
> * that read this address need to convert this address to the
> * Boot-Loader's endianness before jumping.
> */
> - writeq_relaxed(__pa(secondary_entry), &mailbox->entry_point);
> + writeq_relaxed(__pa_symbol(secondary_entry), &mailbox->entry_point);
> writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
>
> arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c02504ea304b..6ccadf255fba 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -736,7 +736,7 @@ static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused
> static bool hyp_offset_low(const struct arm64_cpu_capabilities *entry,
> int __unused)
> {
> - phys_addr_t idmap_addr = virt_to_phys(__hyp_idmap_text_start);
> + phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
>
> /*
> * Activate the lower HYP offset only if:
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index d55a7b09959b..81c03c74e5fe 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -51,7 +51,7 @@
> extern int in_suspend;
>
> /* Find a symbols alias in the linear map */
> -#define LMADDR(x) phys_to_virt(virt_to_phys(x))
> +#define LMADDR(x) __va(__pa_symbol(x))
...Perhaps just borrowing this macro?
>
> /* Do we need to reset el2? */
> #define el2_reset_needed() (is_hyp_mode_available() && !is_kernel_in_hyp_mode())
> @@ -125,12 +125,12 @@ int arch_hibernation_header_save(void *addr, unsigned int max_size)
> return -EOVERFLOW;
>
> arch_hdr_invariants(&hdr->invariants);
> - hdr->ttbr1_el1 = virt_to_phys(swapper_pg_dir);
> + hdr->ttbr1_el1 = __pa_symbol(swapper_pg_dir);
> hdr->reenter_kernel = _cpu_resume;
>
> /* We can't use __hyp_get_vectors() because kvm may still be loaded */
> if (el2_reset_needed())
> - hdr->__hyp_stub_vectors = virt_to_phys(__hyp_stub_vectors);
> + hdr->__hyp_stub_vectors = __pa_symbol(__hyp_stub_vectors);
> else
> hdr->__hyp_stub_vectors = 0;
>
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index 6f2ac4fc66ca..af8967a0343b 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> @@ -97,7 +97,7 @@ static void __kprobes *patch_map(void *addr, int fixmap)
> if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
> page = vmalloc_to_page(addr);
> else if (!module)
> - page = pfn_to_page(PHYS_PFN(__pa(addr)));
> + page = pfn_to_page(PHYS_PFN(__pa_symbol(addr)));
> else
> return addr;
>
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 42816bebb1e0..f0f2abb72cf9 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -45,7 +45,7 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
>
> static int cpu_psci_cpu_boot(unsigned int cpu)
> {
> - int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa(secondary_entry));
> + int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
> if (err)
> pr_err("failed to boot CPU%d (%d)\n", cpu, err);
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index f534f492a268..e2dbc02f4792 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -199,10 +199,10 @@ static void __init request_standard_resources(void)
> struct memblock_region *region;
> struct resource *res;
>
> - kernel_code.start = virt_to_phys(_text);
> - kernel_code.end = virt_to_phys(__init_begin - 1);
> - kernel_data.start = virt_to_phys(_sdata);
> - kernel_data.end = virt_to_phys(_end - 1);
> + kernel_code.start = __pa_symbol(_text);
> + kernel_code.end = __pa_symbol(__init_begin - 1);
> + kernel_data.start = __pa_symbol(_sdata);
> + kernel_data.end = __pa_symbol(_end - 1);
>
> for_each_memblock(memory, region) {
> res = alloc_bootmem_low(sizeof(*res));
> diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
> index 9a00eee9acc8..25fcccaf79b8 100644
> --- a/arch/arm64/kernel/smp_spin_table.c
> +++ b/arch/arm64/kernel/smp_spin_table.c
> @@ -98,7 +98,7 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
> * boot-loader's endianess before jumping. This is mandated by
> * the boot protocol.
> */
> - writeq_relaxed(__pa(secondary_holding_pen), release_addr);
> + writeq_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
> __flush_dcache_area((__force void *)release_addr,
> sizeof(*release_addr));
>
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index a2c2478e7d78..791e87a99148 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -140,11 +140,11 @@ static int __init vdso_init(void)
> return -ENOMEM;
>
> /* Grab the vDSO data page. */
> - vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa(vdso_data)));
> + vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa_symbol(vdso_data)));
>
> /* Grab the vDSO code pages. */
> for (i = 0; i < vdso_pages; i++)
> - vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) + i);
> + vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa_symbol(&vdso_start)) + i);
>
> vdso_spec[0].pages = &vdso_pagelist[0];
> vdso_spec[1].pages = &vdso_pagelist[1];
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3236eb062444..14f426fea61b 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -225,7 +225,7 @@ void __init arm64_memblock_init(void)
> */
> if (memory_limit != (phys_addr_t)ULLONG_MAX) {
> memblock_mem_limit_remove_map(memory_limit);
> - memblock_add(__pa(_text), (u64)(_end - _text));
> + memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> @@ -278,7 +278,7 @@ void __init arm64_memblock_init(void)
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> */
> - memblock_reserve(__pa(_text), _end - _text);
> + memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> memblock_reserve(initrd_start, initrd_end - initrd_start);
> @@ -483,7 +483,8 @@ void __init mem_init(void)
>
> void free_initmem(void)
> {
> - free_reserved_area(__va(__pa(__init_begin)), __va(__pa(__init_end)),
> + free_reserved_area(__va(__pa_symbol(__init_begin)),
> + __va(__pa_symbol(__init_end)),
> 0, "unused kernel");
> /*
> * Unmap the __init region but leave the VM area in place. This
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 17243e43184e..f7c0a47a8ebd 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -359,8 +359,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
>
> static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
> {
> - unsigned long kernel_start = __pa(_text);
> - unsigned long kernel_end = __pa(__init_begin);
> + unsigned long kernel_start = __pa_symbol(_text);
> + unsigned long kernel_end = __pa_symbol(__init_begin);
>
> /*
> * Take care not to create a writable alias for the
> @@ -427,14 +427,14 @@ void mark_rodata_ro(void)
> unsigned long section_size;
>
> section_size = (unsigned long)_etext - (unsigned long)_text;
> - create_mapping_late(__pa(_text), (unsigned long)_text,
> + create_mapping_late(__pa_symbol(_text), (unsigned long)_text,
> section_size, PAGE_KERNEL_ROX);
> /*
> * mark .rodata as read only. Use __init_begin rather than __end_rodata
> * to cover NOTES and EXCEPTION_TABLE.
> */
> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
> - create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> + create_mapping_late(__pa_symbol(__start_rodata), (unsigned long)__start_rodata,
> section_size, PAGE_KERNEL_RO);
>
> /* flush the TLBs after updating live kernel mappings */
> @@ -446,7 +446,7 @@ void mark_rodata_ro(void)
> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> pgprot_t prot, struct vm_struct *vma)
> {
> - phys_addr_t pa_start = __pa(va_start);
> + phys_addr_t pa_start = __pa_symbol(va_start);
> unsigned long size = va_end - va_start;
>
> BUG_ON(!PAGE_ALIGNED(pa_start));
> @@ -494,7 +494,7 @@ static void __init map_kernel(pgd_t *pgd)
> */
> BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> set_pud(pud_set_fixmap_offset(pgd, FIXADDR_START),
> - __pud(__pa(bm_pmd) | PUD_TYPE_TABLE));
> + __pud(__pa_symbol(bm_pmd) | PUD_TYPE_TABLE));
> pud_clear_fixmap();
> } else {
> BUG();
> @@ -525,7 +525,7 @@ void __init paging_init(void)
> */
> cpu_replace_ttbr1(__va(pgd_phys));
> memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
> - cpu_replace_ttbr1(swapper_pg_dir);
> + cpu_replace_ttbr1(__va(__pa_symbol(swapper_pg_dir)));
>
> pgd_clear_fixmap();
> memblock_free(pgd_phys, PAGE_SIZE);
> @@ -534,7 +534,7 @@ void __init paging_init(void)
> * We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
> * allocated with it.
> */
> - memblock_free(__pa(swapper_pg_dir) + PAGE_SIZE,
> + memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
> SWAPPER_DIR_SIZE - PAGE_SIZE);
> }
>
> @@ -654,7 +654,7 @@ void __init early_fixmap_init(void)
>
> pgd = pgd_offset_k(addr);
> if (CONFIG_PGTABLE_LEVELS > 3 &&
> - !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> + !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
> /*
> * We only end up here if the kernel mapping and the fixmap
> * share the top level pgd entry, which should only happen on
> @@ -663,12 +663,12 @@ void __init early_fixmap_init(void)
> BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> pud = pud_offset_kimg(pgd, addr);
> } else {
> - pgd_populate(&init_mm, pgd, bm_pud);
> + pgd_populate(&init_mm, pgd, __va(__pa_symbol(bm_pud)));
> pud = fixmap_pud(addr);
> }
> - pud_populate(&init_mm, pud, bm_pmd);
> + pud_populate(&init_mm, pud, __va(__pa_symbol(bm_pmd)));
> pmd = fixmap_pmd(addr);
> - pmd_populate_kernel(&init_mm, pmd, bm_pte);
> + pmd_populate_kernel(&init_mm, pmd, __va(__pa_symbol(bm_pte)));
>
> /*
> * The boot-ioremap range spans multiple pmds, for which
> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
> index 874c78201a2b..98dae943e496 100644
> --- a/arch/arm64/mm/physaddr.c
> +++ b/arch/arm64/mm/physaddr.c
> @@ -14,8 +14,8 @@ unsigned long __virt_to_phys(unsigned long x)
> */
> return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
> } else {
> - VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
> - return (__x - kimage_voffset);
> + WARN_ON(1);
Was the deletion of the BUG_ON here intentional? VIRTUAL_BUG_ON
is the check enabled by CONFIG_DEBUG_VIRTUAL vs just CONFIG_DEBUG_VM.
I intentionally kept CONFIG_DEBUG_VIRTUAL separate since the checks
are expensive.
> + return __phys_addr_symbol(x);
> }
> }
> EXPORT_SYMBOL(__virt_to_phys);
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index 8263429e21b8..9defbe243c2f 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -383,7 +383,7 @@ static int psci_suspend_finisher(unsigned long index)
> u32 *state = __this_cpu_read(psci_power_state);
>
> return psci_ops.cpu_suspend(state[index - 1],
> - virt_to_phys(cpu_resume));
> + __pa_symbol(cpu_resume));
> }
>
> int psci_cpu_suspend_enter(unsigned long index)
>
Thanks,
Laura
^ 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