* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Alexander Sverdlin @ 2017-12-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a22-Q6Ksqh3eeoq-iLcs9PA2kZ12Cjp5ibPUKvU8dhbrw@mail.gmail.com>
Hi!
On Wed Dec 20 13:50:28 2017 Arnd Bergmann <arnd@arndb.de> wrote:
> I'm generally more interested in the multiplatform conversion than
> the DT conversion, and I think converting this one to multiplatform
> isn't actually that hard, and doesn't have a significant risk for
> regressions, the main work is to convert the clock handling.
If it will be still possible to build the binary kernel of the same size after the conversion, I'm in for testing, otherwise it will not fit into Flash any more...
--
Alex.
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Arnd Bergmann @ 2017-12-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
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
arch/arm/Makefile | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e83f5161fdd8..33b7eb4502aa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -19,6 +19,11 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
+ifeq ($(CONFIG_CPU_32v4),y)
+LDFLAGS_vmlinux += $(call ld-option,--fix-v4bx)
+LDFLAGS_MODULE += $(call ld-option,--fix-v4bx)
+endif
+
ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
endif
@@ -76,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 -march=armv4
+arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
# Evaluate arch cc-option calls now
@@ -94,8 +99,8 @@ tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM926T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_FA526) =-mtune=arm9tdmi
-tune-$(CONFIG_CPU_SA110) =-mtune=strongarm110
-tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100
+tune-$(CONFIG_CPU_SA110) =$(call cc-option,-mtune=strongarm110)
+tune-$(CONFIG_CPU_SA1100) =$(call cc-option,-mtune=strongarm1100)
tune-$(CONFIG_CPU_XSCALE) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_XSC3) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_FEROCEON) =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
--
2.9.0
^ permalink raw reply related
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-20 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda8xPuVHpBvX6_Ez+ztn4neVZ+=x=AEWmHJyZgww-1jHg@mail.gmail.com>
On Wed, Dec 20, 2017 at 1:48 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <lukma@denx.de> wrote:
>>>> It would also be helpful
>>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>>> working binaries for you, in that case you could report to the gcc
>>>> developers that the removal of armv4 can continue but that
>>>> the --fix-v4bx option in ld needs to stay around.
>>>
>>> I may ask this issue on OE/Yocto mailing list as well....
>>
>> To clarify, the only affected platforms are those based on either
>> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
>> FootBridge, RPC, SA1100, Moxart and Gemini.
>
> It's a bit unfortunate since there are users and active contributors to
> these architectures, I think the OE community is being missed out
> just because they "are not Debian". :/
IIRC, OE already uses the --fix-v4bx workaround. I had an older patch
to do the same in the kernel, let me resend it now, so you can try it
and see if that works for you.
Arnd
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-20 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaAYLd6ZcBXQP_SfA1dTyyb4kjOpGoW5DUBgH_9pDDtQQ@mail.gmail.com>
On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <lukma@denx.de> wrote:
>
> There is a point where supporting old board files will stand in
> the way and cost a lot in maintenance (like moving drivers our
> of arch/arm, or modernizing misc subsystems). Then moving the
> platform over to device tree should be preferred.
I'm generally more interested in the multiplatform conversion than
the DT conversion, and I think converting this one to multiplatform
isn't actually that hard, and doesn't have a significant risk for
regressions, the main work is to convert the clock handling.
Arnd
^ permalink raw reply
* [PATCH 1/9] ARM: enable secure platform-only erratas
From: Dmitry Osipenko @ 2017-12-20 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219232810.GI10595@n2100.armlinux.org.uk>
On 20.12.2017 02:28, Russell King - ARM Linux wrote:
> On Thu, Oct 05, 2017 at 09:16:12PM +0300, Dmitry Osipenko wrote:
>> On 20.07.2017 03:29, Micha? Miros?aw wrote:
>>> Allow secure-only erratas to be used in multiarch kernel.
>>>
>>> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
>>> ---
>>> arch/arm/Kconfig | 20 ++++++++++++++------
>>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index a208bfe367b5..a1eff866550b 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -696,6 +696,14 @@ config ARCH_MULTI_CPU_AUTO
>>>
>>> endmenu
>>>
>>> +config ARCH_ASSUME_SECURE_PLATFORM
>>> + bool "Enable ERRATAs using secure-only registers"
>>> + default !ARCH_MULTIPLATFORM
>>
>> I think default should always be "Yes" and this option shouldn't affect
>> multiplatform kernels. So a multiplatform kernel wouldn't be an option
>> for your device.
>
> No, that changes the current behaviour.
>
> Current behaviour is for the secure-only errata to be disabled when the
> multi-platform option is enabled, because multi-platform kernels have to
> be able to run in the non-secure world. Defaulting this option to "yes"
> means that these errata become visible.
Indeed, I got it inverted.
> I have to wonder why you need this though - your patches seem to be
> targetting a platform that runs in non-secure world, and enabling these
> errata would make the kernel non-bootable on your platform.
Perhaps because Micha? made the Tegra's CPU reset handler hardcoded to either
secure or to non-secure case based on the kernels configuration. I've showed how
we can get rid of that inflexibility in [0], maybe Micha? could pick up the idea
in the next iteration of the patches.
[0] https://marc.info/?l=linux-tegra&m=151371042522835
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Linus Walleij @ 2017-12-20 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3VJapioU32oBtA2GDmvXiHvz3K=W6BGx+u=Tvb1aDXsg@mail.gmail.com>
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <lukma@denx.de> wrote:
>>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <lukma@denx.de>
>>> wrote:
>>> >> >> We also need to think about upholding support in GCC for
>>> >> >> ARMv4(t) for the foreseeable future if there is a big web of
>>> >> >> random deeply embedded systems out there that will need
>>> >> >> updates.
>>> >> >
>>> >> > But we should definitely preserve at least what we have.
>>> >>
>>> >> Plain ARMv4 (and earlier) support in gcc is already marked
>>> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
>>> >> of last week). ARMv4T is going to be around for a while, and you
>>> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
>>> >> linking with 'ld --fix-v4bx'.
>>> >
>>> > I think that we shall start complaining on the gcc-devel mailing
>>> > list now.
>>> >
>>> > I would be hard to wake up in 2 years time and realise that we don't
>>> > have a modern compiler.
(...)
>>> It would also be helpful
>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>> working binaries for you, in that case you could report to the gcc
>>> developers that the removal of armv4 can continue but that
>>> the --fix-v4bx option in ld needs to stay around.
>>
>> I may ask this issue on OE/Yocto mailing list as well....
>
> To clarify, the only affected platforms are those based on either
> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
> FootBridge, RPC, SA1100, Moxart and Gemini.
It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/
Even NetWinder.org is still up and kicking.
Some of it may be nostalgia and platform-hugging with regards to
SA110 and SA1100 systems, I am certainly aware of such tendencies
in myself. And I understand if GCC drops support for old systems
that only have a bunch of elderly gentlemen running it for the fun of it.
What really worries me is if there are widely deployed SA110,
SA1100, FA526 or similar embedded systems using plain ARMv4
and doing regular kernel builds and userspaces for them, in
items with 20+ years support cycles.
With reports in the media about things like nuclear powerplants running
unsupported versions of Windows NT or 95, I want to make sure
that we're not creating a similar situation somewhere for deeply
embedded Linux. Sadly these users mostly seem to come out
of the shadows after-the-fact.
My own experiments with an upgraded Gemini platform are mostly
related to the fact that home routers using this ARMv4 SoC are still
being sold and deployed, using a v2.6 kernel (contributing to the
world of botnets I suppose). The hardware-accelerated gigabit ethernet
on these routers for the home make them still fully usable despite the
ARMv4 core, but securitywise they are a nightmare.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver
From: Olivier MOYSAN @ 2017-12-20 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093506.GD8563@sirena.org.uk>
Hello Mark,
On 12/19/2017 10:35 AM, Mark Brown wrote:
> On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote:
>
>> You are right. wm8994 allows to select either MCLK for each AIF.
>> From this point of view, the current patch is too limiting.
>> MCLK information in DT allows to enforce MCLK use, but an additionnal
>> information is required to determine AIF MCLK assignment.
>> Available properties in codec DAI node, such as clocks property, cannot
>> help here.
>
>> Maybe a DAPM linked to a control is a better way to select AIF source,
>> When source is not provided by clk_id in wm8994_set_dai_sysclk().
>> In this case, wm8994_set_dai_sysclk() would only have to check
>> if clock source is not already set.
>
>> Please let me know if this option sounds better to you.
>
> What are you trying to accomplish here? You appear to be trying to move
> the system clocking configuration from the machine driver to the CODEC
> which is not how things are supposed to work.
>
As a generic machine, simple or audio graph cards are not able to manage
codec clock muxing.
If we exclude the management of muxing through codec controls,
the remaining solution is to handle it fully through clock framework.
The current patch only supports a limited range of muxing capabilities
of the codec.
To have a full management of the muxing, I think it is necessary to add
a device tree node for each codec interface and to define an aif clock
in these nodes.
Then parent clock assignment of these aif clocks would allow to handle
the muxing.
Please, let me known if is this the right direction for you.
BRs
olivier
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Linus Walleij @ 2017-12-20 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213095257.5cf424fb@jawa>
On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <lukma@denx.de> wrote:
>> On Wed Dec 13 08:34:22 2017 Linus Walleij <linus.walleij@linaro.org>
>> wrote:
>> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <lukma@denx.de>
>> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
>> > industrial control systems. Likewise Hartley is doing similar
>> > business over at Vision Engravings.
>> >
>> > Is the situation such that there is a whole bunch of industrial
>> > systems out there, in active use and needing future upgrades,
>> > that use the EP93xx?
>>
>> That's definitely the case. I'm as well aware of several thousands of
>> industrial devices which are expected to run 24/7 for the next 5
>> years at least. And they are updated from time to time.
>
> I can agree with this statement.
OK I'm coloring this platform with a highlight for ARM32 maintenance.
>> > Arnd has been nudging me to do DT conversion for EP93xx
>> > so if there are many active industrial users of these
>> > I should prioritize it, because these things have 20+ years
>> > support cycles.
>>
>> I'm not sure how important or necessary at all is to change anything
>> in these legacy platforms.
>
> +1
That is an understandable conservative stance.
There is a fine line between "it works, don't touch it" and
"modernize the ARM32 ecosystem".
There is a point where supporting old board files will stand in
the way and cost a lot in maintenance (like moving drivers our
of arch/arm, or modernizing misc subsystems). Then moving the
platform over to device tree should be preferred.
> I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2 works
> with it.
>
> And yes, armv4 support shall be preserved in GCC ....
Yes that is the same toochain I use.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] staging: vchiq_arm: Cleaning up codestyle warnings
From: Mikhail Shvetsov @ 2017-12-20 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8bfad6214b83ee325888705c9f5a194cb6899caf.1513772223.git.lameli67@gmail.com>
This removes checkpatch.pl warnings:
WARNING: line over 80 characters
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 3c9f97d60019..43c89a08bda9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -90,7 +90,8 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
goto failed;
} else if (i > 0) {
vchiq_log_warning(vchiq_core_log_level,
- "%s: videocore initialized after %d retries\n", __func__, i);
+ "%s: videocore initialized after %d retries\n",
+ __func__, i);
}
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] staging: vchiq_arm: Fixing code style of comments
From: Mikhail Shvetsov @ 2017-12-20 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8bfad6214b83ee325888705c9f5a194cb6899caf.1513772223.git.lameli67@gmail.com>
This removes checkpatch.pl warnings:
WARNING: Block comments use a trailing */ on a separate line
WARNING: Block comments should align the * on each line
WARNING: Block comments use * on subsequent lines
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
.../vc04_services/interface/vchiq_arm/vchiq_kern_lib.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 6152596d23ea..3c9f97d60019 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -75,7 +75,9 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);
/* VideoCore may not be ready due to boot up timing.
- It may never be ready if kernel and firmware are mismatched, so don't block forever. */
+ * It may never be ready if kernel and firmware are mismatched,so don't
+ * block forever.
+ */
for (i = 0; i < VCHIQ_INIT_RETRIES; i++) {
state = vchiq_get_state();
if (state)
@@ -379,8 +381,9 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
if ((bulk->data != data) ||
(bulk->size != size)) {
/* This is not a retry of the previous one.
- ** Cancel the signal when the transfer
- ** completes. */
+ * Cancel the signal when the transfer
+ * completes.
+ */
spin_lock(&bulk_waiter_spinlock);
bulk->userdata = NULL;
spin_unlock(&bulk_waiter_spinlock);
@@ -406,7 +409,8 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
if (bulk) {
/* Cancel the signal when the transfer
- ** completes. */
+ * completes.
+ */
spin_lock(&bulk_waiter_spinlock);
bulk->userdata = NULL;
spin_unlock(&bulk_waiter_spinlock);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] staging: vchiq_arm: Remove useless comments.
From: Mikhail Shvetsov @ 2017-12-20 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214205739.GB1856@kroah.com>
This removes useless comments duplicate function names.
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
.../interface/vchiq_arm/vchiq_kern_lib.c | 35 ----------------------
1 file changed, 35 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 34f746db19cd..6152596d23ea 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -64,11 +64,6 @@ static VCHIQ_STATUS_T
vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
unsigned int size, VCHIQ_BULK_DIR_T dir);
-/****************************************************************************
-*
-* vchiq_initialise
-*
-***************************************************************************/
#define VCHIQ_INIT_RETRIES 10
VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
{
@@ -120,12 +115,6 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
}
EXPORT_SYMBOL(vchiq_initialise);
-/****************************************************************************
-*
-* vchiq_shutdown
-*
-***************************************************************************/
-
VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
{
VCHIQ_STATUS_T status;
@@ -168,23 +157,11 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
}
EXPORT_SYMBOL(vchiq_shutdown);
-/****************************************************************************
-*
-* vchiq_is_connected
-*
-***************************************************************************/
-
static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
{
return instance->connected;
}
-/****************************************************************************
-*
-* vchiq_connect
-*
-***************************************************************************/
-
VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
{
VCHIQ_STATUS_T status;
@@ -214,12 +191,6 @@ VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
}
EXPORT_SYMBOL(vchiq_connect);
-/****************************************************************************
-*
-* vchiq_add_service
-*
-***************************************************************************/
-
VCHIQ_STATUS_T vchiq_add_service(
VCHIQ_INSTANCE_T instance,
const VCHIQ_SERVICE_PARAMS_T *params,
@@ -259,12 +230,6 @@ VCHIQ_STATUS_T vchiq_add_service(
}
EXPORT_SYMBOL(vchiq_add_service);
-/****************************************************************************
-*
-* vchiq_open_service
-*
-***************************************************************************/
-
VCHIQ_STATUS_T vchiq_open_service(
VCHIQ_INSTANCE_T instance,
const VCHIQ_SERVICE_PARAMS_T *params,
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a77970: move node which has no reg property out of bus
From: Simon Horman @ 2017-12-20 12:25 UTC (permalink / raw)
To: linux-arm-kernel
Move timer node from soc node to root node. The node that have been moved
do not have any register properties and thus shouldn't be placed on the
bus.
This problem is flagged by the compiler as follows:
$ make W=1
...
DTC arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb
arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index c35a117fc447..566a7f704830 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -92,18 +92,6 @@
resets = <&cpg 408>;
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) |
- IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) |
- IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) |
- IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) |
- IRQ_TYPE_LEVEL_LOW)>;
- };
-
rwdt: watchdog at e6020000 {
compatible = "renesas,r8a77970-wdt",
"renesas,rcar-gen3-wdt";
@@ -442,4 +430,12 @@
#size-cells = <0>;
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a77995: move nodes which have no reg property out of bus
From: Simon Horman @ 2017-12-20 12:24 UTC (permalink / raw)
To: linux-arm-kernel
Move pmu_a53 and timer nodes from soc node to root node. The nodes that
have been moved do not have any register properties and thus shouldn't be
placed on the bus.
This problem is flagged by the compiler as follows:
$ make W=1
...
arch/arm64/boot/dts/renesas/r8a77995-draak.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a77995-draak.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 30 +++++++++++++-----------------
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index cff42cd1a6c8..23f763beab46 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -58,6 +58,11 @@
clock-frequency = <0>;
};
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
scif_clk: scif {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -88,18 +93,6 @@
resets = <&cpg 408>;
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
rwdt: watchdog at e6020000 {
compatible = "renesas,r8a77995-wdt",
"renesas,rcar-gen3-wdt";
@@ -110,11 +103,6 @@
status = "disabled";
};
- pmu_a53 {
- compatible = "arm,cortex-a53-pmu";
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
- };
-
ipmmu_vi0: mmu at febd0000 {
compatible = "renesas,ipmmu-r8a77995";
reg = <0 0xfebd0000 0 0x1000>;
@@ -637,4 +625,12 @@
status = "disabled";
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: Vladimir Murzin @ 2017-12-20 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220120104.GA5724@afzalpc>
Hi,
On 20/12/17 12:01, afzal mohammed wrote:
> Hi Vladimir,
>
> To add, i am not against your patch, just seeing if we can avoid
> having this change, lesser code ... lesser bugs.
Look, I hit that issue and without this change the issue does not
magically disappear for me - the only way to avoid this change is
to propose alternative patch.
I don't want to jump into these "it should not happen" or "nobody"
cares" discussions just because it is not true - it happened to
me and I do care. However, I do open to discuss technical aspects.
Cheers
Vladimir
>
> afzal
>
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: Vladimir Murzin @ 2017-12-20 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220114924.GA5377@afzalpc>
On 20/12/17 11:49, afzal mohammed wrote:
> Hi,
>
> On Wed, Dec 20, 2017 at 09:55:00AM +0000, Vladimir Murzin wrote:
>
>>>> I caught it when was trying to setup VBAR and after code inspection I
>>>> noticed that setting of Hivecs were changed as well.
>>>
>>> Thinking again about this, should the Hivecs setting on secondary
>>> CPU's be done (till a requirement comes) ?
>>>
>>> ARM ARM deprecates using Hivecs setting on ARMv7-R, so this issue
>>> might not be hit in practice for R class. While pre-ARMv7, lack of
>>> Hivecs setting for secondaries, it seems can affect only ARMv6k
>>> (multi-processing support added here ?) and i am making a guess that
>>> even if there are ARMv6k with more than one core available, they might
>>> not yet have run with MMU disabled to hit this case, probably the
>>> reason no one has reported issue for long.
>>
>> I've just reported an issue, no? :)
>
> By reported, i meant whether the lack of this in secondary would cause
> an issue at run time in any of the platform's. You spotted it by code
> inspection rather than hitting any issue in practice is what i
> understood.
>
>>> Perhaps, we can avoid configuring Hivecs for secondaries until some
>>> one needs it ?
>>
>> Well, before ad475117d201, Hivec would be enabled for secondaries via
>>
>> secondary_startup
>> -> __after_proc_init
>>
>> after that commit it is not true, so it is kind of regression.
>
> Something that was done before that commit not being done later
> (though unintentionally) per se doesn't count as regression in my
> opinion. But if any platform really needs to gets this done or
> misbehaves due to my change, then certainly it has to be counted a
> regression, which i believe is not the case here.
>
>>
>> Additionally, patch is not about Hivec only, but VBAR as well and TBH I
>> don't follow what is your proposal...
>
> i was referring to the fact that vector remapping can't be done in
> Cortex-R, as security extension is a requisite for this feature, which
> Cortex-R don't have on ARMv7.
For instance, just think of ARMv7A with 1:1 MMU running in SMP...
Vladimir
>
> afzal
>
^ permalink raw reply
* [PATCH] pinctrl: mvebu: Delete an error message for a failed memory allocation in mvebu_pinctrl_probe()
From: Linus Walleij @ 2017-12-20 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba1158ce-87be-6033-72b6-b08d7babc443@users.sourceforge.net>
On Tue, Dec 19, 2017 at 10:37 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 19 Dec 2017 22:30:36 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v1] mfd: ab8500: introduce DEFINE_SHOW_ATTRIBUTE() macro
From: Linus Walleij @ 2017-12-20 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215105432.pm36mtles7mpvcye@dell>
On Fri, Dec 15, 2017 at 11:54 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Linus,
>
>> This macro deduplicates a lot of similar code in the ab8500-debugfs.c module.
>> Targeting to be moved to seq_file.h eventually.
>>
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Excellent cleanup.
Can't test it right now, if it causes any runtime fallout I will handle it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Linus Walleij @ 2017-12-20 12:17 UTC (permalink / raw)
To: linux-arm-kernel
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.
---
arch/arm/mach-davinci/board-dm355-evm.c | 15 +++++++++++++--
arch/arm/mach-davinci/board-dm644x-evm.c | 15 +++++++++++++--
drivers/i2c/busses/i2c-davinci.c | 21 +++++++++++----------
include/linux/platform_data/i2c-davinci.h | 5 ++---
4 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 62e7bc3018f0..e457f299cd44 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -17,6 +17,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/i2c.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/clk.h>
#include <linux/videodev2.h>
#include <media/i2c/tvp514x.h>
@@ -108,11 +109,20 @@ static struct platform_device davinci_nand_device = {
},
};
+static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
+ .dev_id = "i2c_davinci",
+ .table = {
+ GPIO_LOOKUP("davinci_gpio", 15, "sda",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ GPIO_LOOKUP("davinci_gpio", 14, "scl",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ },
+};
+
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
- .sda_pin = 15,
- .scl_pin = 14,
+ .gpio_recovery = true,
};
static int dm355evm_mmc_gpios = -EINVAL;
@@ -141,6 +151,7 @@ static struct i2c_board_info dm355evm_i2c_info[] = {
static void __init evm_init_i2c(void)
{
+ gpiod_add_lookup_table(&i2c_recovery_gpiod_table);
davinci_init_i2c(&i2c_pdata);
gpio_request(5, "dm355evm_msp");
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index b07c9b18d427..85e6fb33b1ee 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -13,6 +13,7 @@
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/i2c.h>
#include <linux/platform_data/pcf857x.h>
#include <linux/platform_data/at24.h>
@@ -595,18 +596,28 @@ static struct i2c_board_info __initdata i2c_info[] = {
},
};
+static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
+ .dev_id = "i2c_davinci",
+ .table = {
+ GPIO_LOOKUP("davinci_gpio", 44, "sda",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ GPIO_LOOKUP("davinci_gpio", 43, "scl",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ },
+};
+
/* The msp430 uses a slow bitbanged I2C implementation (ergo 20 KHz),
* which requires 100 usec of idle bus after i2c writes sent to it.
*/
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 20 /* kHz */,
.bus_delay = 100 /* usec */,
- .sda_pin = 44,
- .scl_pin = 43,
+ .gpio_recovery = true,
};
static void __init evm_init_i2c(void)
{
+ gpiod_add_lookup_table(&i2c_recovery_gpiod_table);
davinci_init_i2c(&i2c_pdata);
i2c_add_driver(&dm6446evm_msp_driver);
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 2afb12a89eb3..cb24a3ffdfa2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -33,7 +33,7 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/cpufreq.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_device.h>
#include <linux/platform_data/i2c-davinci.h>
#include <linux/pm_runtime.h>
@@ -869,19 +869,20 @@ static int davinci_i2c_probe(struct platform_device *pdev)
if (dev->pdata->has_pfunc)
adap->bus_recovery_info = &davinci_i2c_scl_recovery_info;
- else if (dev->pdata->scl_pin) {
+ else if (dev->pdata->gpio_recovery) {
rinfo = &davinci_i2c_gpio_recovery_info;
adap->bus_recovery_info = rinfo;
- r = gpio_request_one(dev->pdata->scl_pin, GPIOF_OPEN_DRAIN |
- GPIOF_OUT_INIT_HIGH, "i2c-scl");
- if (r)
+ rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl",
+ GPIOD_OUT_HIGH_OPEN_DRAIN);
+ if (IS_ERR(rinfo->scl_gpiod)) {
+ r = PTR_ERR(rinfo->scl_gpiod);
goto err_unuse_clocks;
- rinfo->scl_gpiod = gpio_to_desc(dev->pdata->scl_pin);
-
- r = gpio_request_one(dev->pdata->sda_pin, GPIOF_IN, "i2c-sda");
- if (r)
+ }
+ rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
+ if (IS_ERR(rinfo->sda_gpiod)) {
+ r = PTR_ERR(rinfo->sda_gpiod);
goto err_unuse_clocks;
- rinfo->sda_gpiod = gpio_to_desc(dev->pdata->scl_pin);
+ }
}
adap->nr = pdev->id;
diff --git a/include/linux/platform_data/i2c-davinci.h b/include/linux/platform_data/i2c-davinci.h
index 89fd34727a24..98967df07468 100644
--- a/include/linux/platform_data/i2c-davinci.h
+++ b/include/linux/platform_data/i2c-davinci.h
@@ -16,9 +16,8 @@
struct davinci_i2c_platform_data {
unsigned int bus_freq; /* standard bus frequency (kHz) */
unsigned int bus_delay; /* post-transaction delay (usec) */
- unsigned int sda_pin; /* GPIO pin ID to use for SDA */
- unsigned int scl_pin; /* GPIO pin ID to use for SCL */
- bool has_pfunc; /*chip has a ICPFUNC register */
+ bool gpio_recovery; /* Use GPIO recovery method */
+ bool has_pfunc; /* Chip has a ICPFUNC register */
};
/* for board setup code */
--
2.14.3
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: r8a7793: Reduce size of thermal registers
From: Simon Horman @ 2017-12-20 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220121445.31896-1-horms+renesas@verge.net.au>
Reduce size of thermal registers in DT for r8a7793 (R-Car M3-N) SoC.
According to the "User's Manual: Hardware" v2.00 the registers at base
0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the case
on the r8a73a4 (R-Mobile APE6).
This should not have any runtime affect as mapping granularity is PAGE_SIZE.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 039b22517526..e95f4fb44dc4 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -231,7 +231,7 @@
compatible = "renesas,thermal-r8a7793",
"renesas,rcar-gen2-thermal",
"renesas,rcar-thermal";
- reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
+ reg = <0 0xe61f0000 0 0x10>, <0 0xe61f0100 0 0x38>;
interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 522>;
power-domains = <&sysc R8A7793_PD_ALWAYS_ON>;
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: r8a7791: Reduce size of thermal registers
From: Simon Horman @ 2017-12-20 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220121445.31896-1-horms+renesas@verge.net.au>
Reduce size of thermal registers in DT for r8a7791 (R-Car M3-W) SoC.
According to the "User's Manual: Hardware" v2.00 the registers at base
0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the case
on the r8a73a4 (R-Mobile APE6).
This should not have any runtime affect as mapping granularity is PAGE_SIZE.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 008a260f86a5..8266a9b7cafd 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -240,7 +240,7 @@
compatible = "renesas,thermal-r8a7791",
"renesas,rcar-gen2-thermal",
"renesas,rcar-thermal";
- reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
+ reg = <0 0xe61f0000 0 0x10>, <0 0xe61f0100 0 0x38>;
interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 522>;
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: r8a7790: Reduce size of thermal registers
From: Simon Horman @ 2017-12-20 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220121445.31896-1-horms+renesas@verge.net.au>
Reduce size of thermal registers in DT for r8a7790 (R-Car H2) SoC.
According to the "User's Manual: Hardware" v2.00 the registers at base
0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the case
on the r8a73a4 (R-Mobile APE6).
This should not have any runtime affect as mapping granularity is PAGE_SIZE.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ed9a68538a55..13926fc7abfa 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -294,7 +294,7 @@
compatible = "renesas,thermal-r8a7790",
"renesas,rcar-gen2-thermal",
"renesas,rcar-thermal";
- reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
+ reg = <0 0xe61f0000 0 0x10>, <0 0xe61f0100 0 0x38>;
interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 522>;
power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: renesas: Reduce size of thermal registers
From: Simon Horman @ 2017-12-20 12:14 UTC (permalink / raw)
To: linux-arm-kernel
Reduce size of thermal registers in DT for the following SoCs:
* r8a7790 (R-Car H2)
* r8a7791 (R-Car M3-W)
* r8a7793 (R-Car M3-N)
According to the "User's Manual: Hardware" v2.00 the registers at base
0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the case
on the r8a73a4 (R-Mobile APE6).
This should not have any runtime affect as mapping granularity is PAGE_SIZE.
As pointed out by Geert Uytterhoeven.
Based on renesas-devel-20171220-v4.15-rc4
Simon Horman (3):
ARM: dts: r8a7790: Reduce size of thermal registers
ARM: dts: r8a7791: Reduce size of thermal registers
ARM: dts: r8a7793: Reduce size of thermal registers
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Add efuse device node for RK3328 SoC
From: Heiko Stuebner @ 2017-12-20 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1501817618-65504-3-git-send-email-finley.xiao@rock-chips.com>
Am Freitag, 4. August 2017, 11:33:38 CET schrieb Finley Xiao:
> This patch adds an efuse node in the device tree for rk3228 SoC.
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
applied for 4.16, after the driver change landed now.
Thanks
Heiko
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: afzal mohammed @ 2017-12-20 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220114924.GA5377@afzalpc>
Hi,
On Wed, Dec 20, 2017 at 05:19:24PM +0530, afzal mohammed wrote:
> Cortex-R, as security extension is a requisite for this feature, which
> Cortex-R don't have on ARMv7.
Okay seems even ARMv8-R doesn't have security extensions, only ARMv8-M
has it as compared to ARMv7's.
afzal
^ permalink raw reply
* [PATCH] drivers: gpio: remove duplicate includes
From: Linus Walleij @ 2017-12-20 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513429012-8327-1-git-send-email-pravin.shedge4linux@gmail.com>
On Sat, Dec 16, 2017 at 1:56 PM, Pravin Shedge
<pravin.shedge4linux@gmail.com> wrote:
> These duplicate includes have been found with scripts/checkincludes.pl
> but they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
Patch applied.
Yours,
Linus Walleij
^ 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