* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Linus Walleij @ 2017-12-21 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1MF-ezKyHhzqW0eGDa_2sCEyGZ62Qcxh2itpwHiLHxaA@mail.gmail.com>
On Thu, Dec 21, 2017 at 6:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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
> +
Yes this work! The kernel and userspace comes up.
With this folded in:
Tested-by: Linus Walleij <linus.walleij@linaro.org> for FA526
I will try to test it on SA110 (NetWinder) tomorrow.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 2/3] arm64: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPfKXWAmWUb86YW3zP3iniCU_hnZuacW4HONvYbmi0uoag@mail.gmail.com>
On Thu, Dec 21, 2017 at 8:31 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 21, 2017 at 5:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The Nexell series are similar to Exynos but this is different company
> so probably they would end up in different sub-arch. Only some IP
> blocks are similar to Exynos even though the datasheet has Samsung
> marks. I saw patches for U-Boot (I do not remember the author) so
> maybe soon something will happen on LKML.
Ok. When I looked at an old 32-bit 3.4 kernel tree, I could see no similarity
to Exynos, but it seems that there is now an active development tree for
a 64-bit 4.x kernel for the Samsung Artik board series, just no patches.
Arnd
^ permalink raw reply
* [PATCH 1/2] clk: rename clk_core_get_boundaries() to clk_hw_get_boundaries() and expose
From: Stephen Boyd @ 2017-12-21 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513872282-5370-2-git-send-email-al.kochet@gmail.com>
On 12/21, Alexander Kochetkov wrote:
> In order to provide a way to know clock limits to clock providers.
>
> The patch is needed for fixing commit 5d890c2df900 ("clk: rockchip:
> add special approximation to fix up fractional clk's jitter").
> Custom approximation function introduced by the patch, can
> select frequency rate larger than one configured using
> clk_set_max_rate().
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
Can you convert to the determine_rate op instead of round_rate?
That function should tell you the min/max limits so that you
don't need to query that information from the core.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL 1/2] Rockchip dts32 changes for 4.16
From: Arnd Bergmann @ 2017-12-21 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2013174.TmhWXT9G0E@phil>
On Thu, Dec 21, 2017 at 7:30 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> 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)
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/2] Rockchip dts64 changes for 4.16
From: Arnd Bergmann @ 2017-12-21 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2062410.Qz0JYku65n@phil>
On Thu, Dec 21, 2017 at 7:31 PM, Heiko Stuebner <heiko@sntech.de> 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:
>
> 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.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Arnd Bergmann @ 2017-12-21 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4093a02c-3216-d668-a6d8-1ce76046b554@st.com>
On Thu, Dec 21, 2017 at 5:39 PM, Ludovic BARRE <ludovic.barre@st.com> wrote:
>>>
>> Currently "restart" is not functional on stm32 MCU (at least for
>> stm32f746, I will check on others MCU). My fear is if Ludovic made some
>> patches to make "armv7m_restart" the default ".restart" function for all
>> armv7-m platform, he will not be able to test it on stm32 MCU (as it is not
>> currently working). I propose to do it in 2 steps:
>>
>> 1-Keep as you suggest only one board-dt.c file for both (MCU and MPU) and
>> remove ".restart" function.
>>
>> 2-Investigate and send patches around ".restart" for both in an other
>> series.
>
>
> I resend
Yes, that seems fine.
Arnd
^ permalink raw reply
* [GIT PULL 1/3] ARM: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 21:29 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:
> Krzysztof Kozlowski (2):
> ARM: dts: exynos: Add missing interrupt-controller properties to Exynos5410 PMU
I just looked through the remaining warnings in 4.15 and noticed that
you had sent this
only for 4.16, not as a bug fix.
Looking closer, it seems incorrect:
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420. However, when the RTC DT node got added in commit
e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410"), it was
a straight copy of the Exynos5420 node, which now causes the warning from dtc,
and now you add the "interrupt-controller" property to the device node, but
the code still doesn't handle it at all.
Can you have another look here?
Arnd
^ permalink raw reply
* linux-next: manual merge of the aspeed tree with the arm-soc tree
From: Stephen Rothwell @ 2017-12-21 21:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Joel,
Today's linux-next merge of the aspeed tree got conflicts in:
arch/arm/boot/dts/Makefile
arch/arm/boot/dts/aspeed-g4.dtsi
between commits:
d2271826e58b ("ARM: dts: aspeed-g4: Correct VUART IRQ number")
ea04d6b456b2 ("ARM: make ARCH_S3C24XX select USE_OF and clean-up boot/dts/Makefile")
from the arm-soc tree and commits:
bb8155ada490 ("ARM: dts: aspeed: Add proper clock references")
8b42ae23ee0a ("ARM: dts: aspeed: Sort ASPEED entries in makefile")
2e3de60a1034 ("ARM: dts: aspeed: Add Witherspoon BMC machine")
46d83989fde3 ("ARM: dts: aspeed: Add Ingrasys Zaius BMC machine")
f88bc8e15f1c ("ARM: dts: aspeed: Add Qanta Q71L BMC machine")
from the aspeed tree.
I fixed it up (see below (the dtsi file has a common patch part between
d2271826e58b and bb8155ada490) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/Makefile
index 032138d9c60b,5ab5d9169511..000000000000
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -1102,6 -1101,11 +1102,10 @@@ dtb-$(CONFIG_ARCH_MEDIATEK) +=
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
- dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \
+ dtb-$(CONFIG_ARCH_ASPEED) += \
+ aspeed-ast2500-evb.dtb \
+ aspeed-bmc-opp-palmetto.dtb \
aspeed-bmc-opp-romulus.dtb \
- aspeed-ast2500-evb.dtb
+ aspeed-bmc-opp-witherspoon.dtb \
+ aspeed-bmc-opp-zaius.dtb \
+ aspeed-bmc-quanta-q71l.dtb
-endif
^ permalink raw reply
* [PATCH] ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Arnd Bergmann @ 2017-12-21 21:30 UTC (permalink / raw)
To: linux-arm-kernel
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420.
However, when the RTC DT node got added, it was a straight copy of
the Exynos5420 node, which now causes a warning from dtc.
This removes the incorrect interrupt-parent, which should get the
interrupt working and avoid the warning.
Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/exynos5410.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 06713ec86f0d..d2174727df9a 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -333,7 +333,6 @@
&rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
- interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Arnd Bergmann @ 2017-12-21 21:31 UTC (permalink / raw)
To: linux-arm-kernel
We get a dtc warning about the CLCD interrupt being invalid:
arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd at 10008000
According to the datasheet I found and the old board file, this
line is not connected, so I'm removing the respective properties here.
Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
index 7b8d90b7aeea..e45548ca229a 100644
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -151,8 +151,9 @@
};
&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ /* CLCD is not connected here */
+ /delete-property/interrupt-parent;
+ /delete-property/interrupts;
};
&serial0 {
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann @ 2017-12-21 21:44 UTC (permalink / raw)
To: linux-arm-kernel
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c at 2180000/mux at 77/i2c at 4/sgtl5000 at 2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller at 1400000 or bad phandle (referred from /soc/i2c at 2180000/mux at 77/i2c at 4/sgtl5000 at 2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c at 2190000/sgtl5000 at a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller at 1400000 or bad phandle (referred from /soc/i2c at 2190000/sgtl5000 at a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 940875316d0f..67b4de0e3439 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index a8b148ad1dd2..44715c8ef756 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -187,7 +187,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: dts: tango4: remove bogus interrupt-controller property
From: Arnd Bergmann @ 2017-12-21 21:48 UTC (permalink / raw)
To: linux-arm-kernel
dtc points out that the parent node of the interrupt controllers is not
actually an interrupt controller itself, and lacks an #interrupt-cells
property:
arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller at 6e000
This removes the annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/tango4-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
index 0ec1b0a317b4..ff72a8efb73d 100644
--- a/arch/arm/boot/dts/tango4-common.dtsi
+++ b/arch/arm/boot/dts/tango4-common.dtsi
@@ -156,7 +156,6 @@
reg = <0x6e000 0x400>;
ranges = <0 0x6e000 0x400>;
interrupt-parent = <&gic>;
- interrupt-controller;
#address-cells = <1>;
#size-cells = <1>;
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Linus Walleij @ 2017-12-21 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221213146.3146805-1-arnd@arndb.de>
On Thu, Dec 21, 2017 at 10:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> We get a dtc warning about the CLCD interrupt being invalid:
>
> arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd at 10008000
>
> According to the datasheet I found and the old board file, this
> line is not connected, so I'm removing the respective properties here.
>
> Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There is some confusion here. There is CLCD "Color LCD"
which is just a code name for PrimeCell PL111 and there is the actual
character LCD which is a hardware thin to talk to a character LCD with
some characters on.
> diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
So this DTS is for the ARM 11 MP core tile which is described in
DUI0318F. It doesn't even list an IRQ for the character LCD.
> &charlcd {
> - interrupt-parent = <&intc>;
> - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
This was probably me thinking to go back and fill in the right
IRQ and forgetting to actually do it. Sorry :(
> + /* CLCD is not connected here */
Call it character LCD instead to avoid confusion please.
> + /delete-property/interrupt-parent;
> + /delete-property/interrupts;
I don't understand this delete-property business (first time
I see it, but the top level
DTSI (arm-realview-eb.dtsi) does not define any interrupt
so can't you just delete this whole &charlcd?
I do think the reference design has a character LCD, and I
do think it has an interrupt, it's just undocumented so
someone with this board would have to test it manually
to figure out which line it is. Whoever uses this design
will get to it if ever.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Linus Walleij @ 2017-12-21 22:30 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.
Strange, where do you see this problem?
I just applied the patch on top of Wolfram's for-next
branch and it worked like a charm. It has the PM Runtime patch
underneath and all.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Linus Walleij @ 2017-12-21 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221173235.GK10595@n2100.armlinux.org.uk>
On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> 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.
> ;)
Hm that would be annoying. But when I look at it I think it would
actually work. Did you try just assigning the same pin control
state to all the PHY's and see what happens?
Just set
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mv88e1545>;
on all of them?
I don't think DTC would complain at least.
When I look at the driver subsystem, I don't see anything really
stopping you from doing that and even have three devices selecting
the same "default" pin control state. It seems it will just wind up
three times in pinctrl_select_state() and the first time it calls the pin
control driver to actually set it and the three other times it finds the
state is already correct and returns success.
So the way I read it actually several devices can reference the
same pin control state.
That is, unless there is something I missed. Which I often do...
If it happens to work we should probably put a blurb in the
DT binding that this is expected behaviour though.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net 1/2] dt-bindings: net: mediatek: add condition to property mediatek,pctl
From: Rob Herring @ 2017-12-21 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e366efc29985d3292c8a1afb1389b5eac57c9037.1513762066.git.sean.wang@mediatek.com>
On Wed, Dec 20, 2017 at 05:47:05PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> The property "mediatek,pctl" is only required for SoCs such as MT2701 and
> MT7623, so adding a few words for stating the condition.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> Documentation/devicetree/bindings/net/mediatek-net.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Rob Herring @ 2017-12-21 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220134710.64479-2-jan.tuerk@emtrion.com>
On Wed, Dec 20, 2017 at 02:47:01PM +0100, jan.tuerk at emtrion.com wrote:
> From: Jan Tuerk <jan.tuerk@emtrion.com>
>
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.
As I asked on v1, why not document the panels together in a single doc?
>
> Signed-off-by: Jan Tuerk <jan.tuerk@emtrion.com>
> ---
> .../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 +++++++++
> drivers/gpu/drm/panel/panel-simple.c | 15 +++++++++++++++
> 2 files changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
^ permalink raw reply
* [PATCH V7 01/12] drivers: move clock common macros out from vendor directories
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-2-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> header file which every clock drivers can access to.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 02/12] clk: sprd: Add common infrastructure
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-3-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Added Spreadtrum's clock driver framework together with common
> structures and interface functions.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 03/12] clk: sprd: add gate clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-4-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Some clocks on the Spreadtrum's SoCs are just simple gates. Add
> support for those clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 04/12] clk: sprd: add mux clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-5-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch adds clock multiplexor support for Spreadtrum platforms,
> the mux clocks also can be found in sprd composite clocks, so
> provides two helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 05/12] clk: sprd: add divider clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-6-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This is a feature that can also be found in sprd composite clocks,
> provide a bunch of helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 06/12] clk: sprd: add composite clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-7-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch introduced composite driver for Spreadtrum's SoCs. The
> functions of this composite clock simply consist of divider and
> mux clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 07/12] clk: sprd: add adjustable pll support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-8-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Introduced a common adjustable pll clock driver for Spreadtrum SoCs.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 08/12] dt-bindings: Add Spreadtrum clock binding documentation
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-9-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Introduce a new binding with its documentation for Spreadtrum clock
> sub-framework.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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