* [PATCH v9 00/12] Support PPTT for ARM64
From: Will Deacon @ 2018-05-29 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <551905a6-eaa8-97df-06ec-1ceedfbc164f@arm.com>
On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>> System supend still works fine on systems with big cores only:
> >>>
> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >>> R-Car M3-N (2xCA57)
> >>>
> >>> Reverting this commit fixes the issue for me.
> >>
> >> I can't find anything that relates to system suspend in these patches
> >> unless they are messing with something during CPU hot plug-in back
> >> during resume.
> >
> > It's only the last patch that introduces the breakage.
> >
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
to the scheduler, although I can't see how this would happen.
Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
do you see anything shouting in dmesg?
Will
--->8
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..e3de033339b4 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON((unsigned)node >= nr_node_ids))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
^ permalink raw reply related
* [PATCH] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-05-29 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AU8PDEErHeU1yb9mwgNLJUvWipTrDsY8csXSHiNro-7w@mail.gmail.com>
Hi Fabio,
> Hi Lukasz,
>
> On Tue, May 29, 2018 at 10:58 AM, Lukasz Majewski <lukma@denx.de>
> wrote:
>
> > Sorry for "small" delay on this.
> >
> > Ok, so I've investigated the issue:
> >
> > 1. The code, which you pasted:
> > http://code.bulix.org/ik01yu-339697
> >
> > works correctly as imx53-qsb-common.dtsi directly includes
> > "imx53.dtsi" in which iomuxc label is defined.
> >
> > In my case though,
> >
> > 2. I do include imx53-tqma53.dtsi [1], in which the iomuxc" label
> > is extended:
> >
> > &iomuxc {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_hog>;
> >
> > imx53-tqma53 {
> > pinctrl_hog: hoggrp {
> >
> > .......
> >
> > };
> >
> > The imx53-tqma53.dtsi then includes imx53.dtsi.
> >
> > Moreover, my file -> imx53-kp.dtsi as it includes [1], it extends
> > further the &iomuxc label:
> >
> > &iomuxc {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_kp_common>;
> >
> > imx53-kp-common {
> > pinctrl_buzzer: buzzergrp {
> > .......
> > };
> >
> > So, when I remove imx53-kp-common I will have mismatch with [1]
> > iomuxc structure.
> >
> > The code works as expected when I do remove imx53-tqma53 in [1].
> >
> > However, I would prefer to not touch this imx53-tqma53.dtsi file.
> > It is also included in: imx53-mba53.dts, which extends iomux in
> > following way:
> >
> > &iomuxc {
> > lvds1 {
> > pinctrl_lvds1_1: lvds1-grp1 {
> >
> >
> > Here I would need to remove lvds1, disp1 and tve to make it working.
> > However, it will not break during build, but at run time.
> >
> > Considering the above, I would prefer to leave the code in [1] as is
> > and use imx53-kp-common as well (as in v2 of this patch).
> >
> > Fabio, what do you think?
>
> Ok, thanks for the clarification. I just wanted to make sure we did
> not have some kind of iomux bug there.
>
> I think your proposed patch is fine then.
Would you be so kind and add your Reviwed-by or Acked-by tag to second
version of this patch?
[PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from
K+P
>
> Thanks
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180529/cea5a333/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Fabio Estevam @ 2018-05-29 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519121506.32344-1-lukma@denx.de>
On Sat, May 19, 2018 at 9:15 AM, Lukasz Majewski <lukma@denx.de> wrote:
> This commit provides support for HSC and DDC boards from
> Kieback&Peter GmbH vendor.
>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-05-29 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3c34fb7-4881-3f49-b43b-1b07a8ab865d@microchip.com>
On Tue, 29 May 2018 18:01:40 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:
> [...]
>
>
> >
> > I think you're missing something here. We use the DMA engine in memcpy
> > mode (SRAM -> DRAM), not in device mode (dev -> DRAM or DRAM -> dev).
> > So there's no dmas prop defined in the DT and there should not be.
> >
> > Regards,
> >
> > Boris
> >
>
> Ok, so the memcpy SRAM <-> DRAM will hog the transfer between DRAM and
> LCD if my understanding is correct. That's the DMA that Peter wants to
> disable with his patch ?
>
> Then we can then try to force NFC SRAM DMA channels to use just DDR port
> 1 or 2 for memcpy ?
You mean the dmaengine? According to "14.1.3 Master to Slave Access"
that's already the case.
Only DMAC0 can access the NFC SRAM and it's done through DMAC0:IF0,
then access to DDR is going through port DDR port 1 (DMAC0:IF1) or 2
(DMAC0:IF0).
>
> I have also received a suggestion to try to increase the porches in
> LCDC_LCDCFG3 .
Yep, Nicolas suggested something similar. Peter, can you try that?
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Eugen Hristev @ 2018-05-29 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529171555.19dd723f@bbrezillon>
On 29.05.2018 18:15, Boris Brezillon wrote:
> On Tue, 29 May 2018 18:01:40 +0300
> Eugen Hristev <eugen.hristev@microchip.com> wrote:
>
>> [...]
>>
>>
>>>
>>> I think you're missing something here. We use the DMA engine in memcpy
>>> mode (SRAM -> DRAM), not in device mode (dev -> DRAM or DRAM -> dev).
>>> So there's no dmas prop defined in the DT and there should not be.
>>>
>>> Regards,
>>>
>>> Boris
>>>
>>
>> Ok, so the memcpy SRAM <-> DRAM will hog the transfer between DRAM and
>> LCD if my understanding is correct. That's the DMA that Peter wants to
>> disable with his patch ?
>>
>> Then we can then try to force NFC SRAM DMA channels to use just DDR port
>> 1 or 2 for memcpy ?
>
> You mean the dmaengine? According to "14.1.3 Master to Slave Access"
> that's already the case.
>
> Only DMAC0 can access the NFC SRAM and it's done through DMAC0:IF0,
> then access to DDR is going through port DDR port 1 (DMAC0:IF1) or 2
> (DMAC0:IF0).
If we can make NFC use port 1 only, then HLCDC could have two ports as
master 8 & 9, maybe a better bandwidth.
>
>>
>> I have also received a suggestion to try to increase the porches in
>> LCDC_LCDCFG3 .
>
> Yep, Nicolas suggested something similar. Peter, can you try that?
>
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Jeremy Linton @ 2018-05-29 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <551905a6-eaa8-97df-06ec-1ceedfbc164f@arm.com>
Hi,
On 05/29/2018 08:18 AM, Sudeep Holla wrote:
>
>
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>>> cacheinfo: rename of_node to fw_token
>>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>>> ACPI: Enable PPTT support on ARM64
>>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>>> arm64: Add support for ACPI based firmware tables
>>>>>> arm64: topology: rename cluster_id
>>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>>> ACPI: Add PPTT to injectable table list
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>>
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>>
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>>
>> Suspend-to-idle, which doesn't offline CPUs, still works.
>>
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
>
>>>> System supend still works fine on systems with big cores only:
>>>>
>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>> R-Car M3-N (2xCA57)
>>>>
>>>> Reverting this commit fixes the issue for me.
>>>
>>> I can't find anything that relates to system suspend in these patches
>>> unless they are messing with something during CPU hot plug-in back
>>> during resume.
>>
>> It's only the last patch that introduces the breakage.
>>
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
>
So, presumably the problem is that the numa mask is smaller than the
normal core_siblings...
I would verify that that there is a behavior change with something like
/proc/schedstat | cut -d ' ' -f-2
There might be something odd happening with whether you have CONFIG_NUMA
set (looking at that right now).
So, a couple quick todo's, see if the schedstat domains are changing
with/without the last patch, and also see if they are changing if you
enable/disable NUMA.
Why any of that matters for suspend isn't clear at the moment.
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Will Deacon @ 2018-05-29 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528154448.2494709-1-arnd@arndb.de>
Hi Arnd, Russell, [+Nico and Robin]
On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> Now that the ARM CCI PMU driver can be built as a loadable module,
> we get a link failure when MCPM is enabled:
>
> ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
>
> The simplest fix is to export that helper function.
>
> Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The patch that caused this is currently part of the arm-perf/for-next/perf
> branch, it would be good to have the fix there as well.
> ---
> arch/arm/common/mcpm_entry.c | 2 ++
> 1 file changed, 2 insertions(+)
I'm happy to take this via the arm perf tree if others are ok with that.
Alternatively, I can revert the offending commit if there are objections
to exporting the symbol.
Russell: do you any preference?
Thanks,
Will
> diff --git a/arch/arm/common/mcpm_entry.c b/arch/arm/common/mcpm_entry.c
> index ed9e87ddbb06..037a4479b8c3 100644
> --- a/arch/arm/common/mcpm_entry.c
> +++ b/arch/arm/common/mcpm_entry.c
> @@ -9,6 +9,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/export.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/irqflags.h>
> @@ -174,6 +175,7 @@ bool mcpm_is_available(void)
> {
> return (platform_ops) ? true : false;
> }
> +EXPORT_SYMBOL_GPL(mcpm_is_available);
>
> /*
> * We can't use regular spinlocks. In the switcher case, it is possible
> --
> 2.9.0
>
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Russell King - ARM Linux @ 2018-05-29 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529153013.GH17159@arm.com>
On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> Hi Arnd, Russell, [+Nico and Robin]
>
> On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > Now that the ARM CCI PMU driver can be built as a loadable module,
> > we get a link failure when MCPM is enabled:
> >
> > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> >
> > The simplest fix is to export that helper function.
> >
> > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > The patch that caused this is currently part of the arm-perf/for-next/perf
> > branch, it would be good to have the fix there as well.
> > ---
> > arch/arm/common/mcpm_entry.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I'm happy to take this via the arm perf tree if others are ok with that.
> Alternatively, I can revert the offending commit if there are objections
> to exporting the symbol.
>
> Russell: do you any preference?
As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
patch. Do we know which tree has this?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] drivers/bus: arm-cci: fix build warnings
From: Robin Murphy @ 2018-05-29 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528154228.2403116-1-arnd@arndb.de>
On 28/05/18 16:41, Arnd Bergmann wrote:
> When the arm-cci driver is enabled, but both CONFIG_ARM_CCI5xx_PMU and
> CONFIG_ARM_CCI400_PMU are not, we get a warning about how parts of
> the driver are never used:
>
> drivers/perf/arm-cci.c:1454:29: error: 'cci_pmu_models' defined but not used [-Werror=unused-variable]
> drivers/perf/arm-cci.c:693:16: error: 'cci_pmu_event_show' defined but not used [-Werror=unused-function]
> drivers/perf/arm-cci.c:685:16: error: 'cci_pmu_format_show' defined but not used [-Werror=unused-function]
>
> Marking all three functions as __maybe_unused avoids the warnings in
> randconfig builds. I'm doing this lacking any ideas for a better fix.
Yeah, it's a bit of a silly configuration to allow building a driver
supporting no PMU types, but I couldn't find a way to enforce "at least
one sub-option enabled" logic without introducing mutually-exclusive
dependencies which kbuild thinks are recursive.
An alternative would be to remove the CCI400/CCI5x0 configurability
altogether - I've not not looked in detail at how much difference that
actually makes.
Otherwise, as an immediate quick-fix:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thanks,
Robin.
> Fixes: 3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/perf/arm-cci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
> index e6fadc8e1178..0d09d8e669cd 100644
> --- a/drivers/perf/arm-cci.c
> +++ b/drivers/perf/arm-cci.c
> @@ -120,9 +120,9 @@ enum cci_models {
>
> static void pmu_write_counters(struct cci_pmu *cci_pmu,
> unsigned long *mask);
> -static ssize_t cci_pmu_format_show(struct device *dev,
> +static ssize_t __maybe_unused cci_pmu_format_show(struct device *dev,
> struct device_attribute *attr, char *buf);
> -static ssize_t cci_pmu_event_show(struct device *dev,
> +static ssize_t __maybe_unused cci_pmu_event_show(struct device *dev,
> struct device_attribute *attr, char *buf);
>
> #define CCI_EXT_ATTR_ENTRY(_name, _func, _config) \
> @@ -1451,7 +1451,7 @@ static int cci_pmu_offline_cpu(unsigned int cpu)
> return 0;
> }
>
> -static struct cci_pmu_model cci_pmu_models[] = {
> +static __maybe_unused struct cci_pmu_model cci_pmu_models[] = {
> #ifdef CONFIG_ARM_CCI400_PMU
> [CCI400_R0] = {
> .name = "CCI_400",
>
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Will Deacon @ 2018-05-29 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529153324.GL17671@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > Hi Arnd, Russell, [+Nico and Robin]
> >
> > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > > Now that the ARM CCI PMU driver can be built as a loadable module,
> > > we get a link failure when MCPM is enabled:
> > >
> > > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> > >
> > > The simplest fix is to export that helper function.
> > >
> > > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > The patch that caused this is currently part of the arm-perf/for-next/perf
> > > branch, it would be good to have the fix there as well.
> > > ---
> > > arch/arm/common/mcpm_entry.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > I'm happy to take this via the arm perf tree if others are ok with that.
> > Alternatively, I can revert the offending commit if there are objections
> > to exporting the symbol.
> >
> > Russell: do you any preference?
>
> As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
> patch. Do we know which tree has this?
Yes, sorry, it's in my for-next/perf branch:
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=8b0c93c20ef78f15d8b760964ff79bda7f68c610
which is now in -next.
I'm happy to take the mcpm patch on top with your ack, but if you have
conflicting changes (or would prefer not to export the symbol to modules)
then I can just revert the patch in my tree for now.
Will
^ permalink raw reply
* [PATCH] ARM: dts: berlin: switch to earlycon
From: Thomas Hebb @ 2018-05-29 15:41 UTC (permalink / raw)
To: linux-arm-kernel
The Synopsys DesignWare 8250 UART in Berlin SoCs is now supported by
8250_early, so we can use earlycon for early console output instead
of earlyprintk, which requires an SoC-specific kernel.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
---
arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 2 +-
arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 2 +-
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
index 1c475796d17f..f98798bb684f 100644
--- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
+++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
@@ -45,7 +45,7 @@
compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
chosen {
- bootargs = "earlyprintk";
+ bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index ca24def0ce13..20f31cdeaf38 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -46,7 +46,7 @@
compatible = "google,chromecast", "marvell,berlin2cd", "marvell,berlin";
chosen {
- bootargs = "earlyprintk";
+ bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index 57aa5f8a7c77..9834e84a0797 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -49,7 +49,7 @@
};
chosen {
- bootargs = "earlyprintk";
+ bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
--
2.17.0
^ permalink raw reply related
* [PATCH] drivers/bus: arm-cci: fix build warnings
From: Will Deacon @ 2018-05-29 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0db1b8cd-b695-6cbf-9b27-f632b76bad11@arm.com>
On Tue, May 29, 2018 at 04:34:01PM +0100, Robin Murphy wrote:
> On 28/05/18 16:41, Arnd Bergmann wrote:
> >When the arm-cci driver is enabled, but both CONFIG_ARM_CCI5xx_PMU and
> >CONFIG_ARM_CCI400_PMU are not, we get a warning about how parts of
> >the driver are never used:
> >
> >drivers/perf/arm-cci.c:1454:29: error: 'cci_pmu_models' defined but not used [-Werror=unused-variable]
> >drivers/perf/arm-cci.c:693:16: error: 'cci_pmu_event_show' defined but not used [-Werror=unused-function]
> >drivers/perf/arm-cci.c:685:16: error: 'cci_pmu_format_show' defined but not used [-Werror=unused-function]
> >
> >Marking all three functions as __maybe_unused avoids the warnings in
> >randconfig builds. I'm doing this lacking any ideas for a better fix.
>
> Yeah, it's a bit of a silly configuration to allow building a driver
> supporting no PMU types, but I couldn't find a way to enforce "at least one
> sub-option enabled" logic without introducing mutually-exclusive
> dependencies which kbuild thinks are recursive.
>
> An alternative would be to remove the CCI400/CCI5x0 configurability
> altogether - I've not not looked in detail at how much difference that
> actually makes.
>
> Otherwise, as an immediate quick-fix:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I'll pick this one up into the arm perf tree.
Will
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Russell King - ARM Linux @ 2018-05-29 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529154120.GI17159@arm.com>
On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote:
> Hi Russell,
>
> On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > > Hi Arnd, Russell, [+Nico and Robin]
> > >
> > > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > > > Now that the ARM CCI PMU driver can be built as a loadable module,
> > > > we get a link failure when MCPM is enabled:
> > > >
> > > > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> > > >
> > > > The simplest fix is to export that helper function.
> > > >
> > > > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > ---
> > > > The patch that caused this is currently part of the arm-perf/for-next/perf
> > > > branch, it would be good to have the fix there as well.
> > > > ---
> > > > arch/arm/common/mcpm_entry.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > >
> > > I'm happy to take this via the arm perf tree if others are ok with that.
> > > Alternatively, I can revert the offending commit if there are objections
> > > to exporting the symbol.
> > >
> > > Russell: do you any preference?
> >
> > As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
> > patch. Do we know which tree has this?
>
> Yes, sorry, it's in my for-next/perf branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=8b0c93c20ef78f15d8b760964ff79bda7f68c610
>
> which is now in -next.
>
> I'm happy to take the mcpm patch on top with your ack, but if you have
> conflicting changes (or would prefer not to export the symbol to modules)
> then I can just revert the patch in my tree for now.
I have no changes to that file, so:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Will Deacon @ 2018-05-29 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529133615.26889-1-nixiaoming@huawei.com>
On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly when
> CONFIG_STRICT_KERNEL_RWX=y,
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
How are you achieving this configuration? In our Kconfig we select this
unconditionally.
Will
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Sergei Shtylyov @ 2018-05-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529131012.ohyqwmiaxiiw6noi@verge.net.au>
Hello!
On 05/29/2018 04:10 PM, Simon Horman wrote:
>> Define the Condor board dependent part of the I2C0 device node.
>>
>> The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
>> and Analog Devices ADV7511W HDMI transmitter (but we're only describing
>> the former chips now).
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 27 ++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
>> ===================================================================
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
>> @@ -80,6 +80,28 @@
>> clock-frequency = <32768>;
>> };
>>
>> +&i2c0 {
>> + pinctrl-0 = <&i2c0_pins>;
>> + pinctrl-names = "default";
>> +
>> + status = "okay";
>> + clock-frequency = <400000>;
>> +
>> + io_expander0: gpio at 20 {
>
> Hi Sergei,
>
> I'm a little confused about where 0x20 and 0x21 are derived from.
> Could you explain a little?
r-carv3h_system_evaluation_board_rev020.pdf, pp. 16-17, lower left corners.
The schematics gives the 8-bit read/write addresses but we use uniform 7-bit
I2C address in DTs.
>> + compatible = "onnn,pca9654";
>> + reg = <0x20>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + io_expander1: gpio at 21 {
>> + compatible = "onnn,pca9654";
>> + reg = <0x21>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +};
>> +
>> &mmc0 {
>> pinctrl-0 = <&mmc_pins>;
>> pinctrl-1 = <&mmc_pins_uhs>;
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-05-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1affd186-7f78-8bb0-050e-da82143c2982@microchip.com>
On Tue, 29 May 2018 18:21:40 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:
> On 29.05.2018 18:15, Boris Brezillon wrote:
> > On Tue, 29 May 2018 18:01:40 +0300
> > Eugen Hristev <eugen.hristev@microchip.com> wrote:
> >
> >> [...]
> >>
> >>
> >>>
> >>> I think you're missing something here. We use the DMA engine in memcpy
> >>> mode (SRAM -> DRAM), not in device mode (dev -> DRAM or DRAM -> dev).
> >>> So there's no dmas prop defined in the DT and there should not be.
> >>>
> >>> Regards,
> >>>
> >>> Boris
> >>>
> >>
> >> Ok, so the memcpy SRAM <-> DRAM will hog the transfer between DRAM and
> >> LCD if my understanding is correct. That's the DMA that Peter wants to
> >> disable with his patch ?
> >>
> >> Then we can then try to force NFC SRAM DMA channels to use just DDR port
> >> 1 or 2 for memcpy ?
> >
> > You mean the dmaengine? According to "14.1.3 Master to Slave Access"
> > that's already the case.
> >
> > Only DMAC0 can access the NFC SRAM and it's done through DMAC0:IF0,
> > then access to DDR is going through port DDR port 1 (DMAC0:IF1) or 2
> > (DMAC0:IF0).
>
> If we can make NFC use port 1 only, then HLCDC could have two ports as
> master 8 & 9, maybe a better bandwidth.
Peter, can you try with the following patch?
--->8---
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index ef3f227ce3e6..2a48e870f292 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -124,8 +124,8 @@
#define ATC_SIF(i) (0x3 & (i)) /* Src tx done via AHB-Lite Interface i */
#define ATC_DIF(i) ((0x3 & (i)) << 4) /* Dst tx done via AHB-Lite Interface i */
/* Specify AHB interfaces */
-#define AT_DMA_MEM_IF 0 /* interface 0 as memory interface */
-#define AT_DMA_PER_IF 1 /* interface 1 as peripheral interface */
+#define AT_DMA_MEM_IF 1 /* interface 0 as memory interface */
+#define AT_DMA_PER_IF 0 /* interface 1 as peripheral interface */
#define ATC_SRC_PIP (0x1 << 8) /* Source Picture-in-Picture enabled */
#define ATC_DST_PIP (0x1 << 12) /* Destination Picture-in-Picture enabled */
^ permalink raw reply related
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Will Deacon @ 2018-05-29 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529154251.GM17671@n2100.armlinux.org.uk>
On Tue, May 29, 2018 at 04:42:51PM +0100, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote:
> > Hi Russell,
> >
> > On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> > > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > > > Hi Arnd, Russell, [+Nico and Robin]
> > > >
> > > > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > > > > Now that the ARM CCI PMU driver can be built as a loadable module,
> > > > > we get a link failure when MCPM is enabled:
> > > > >
> > > > > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> > > > >
> > > > > The simplest fix is to export that helper function.
> > > > >
> > > > > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > > ---
> > > > > The patch that caused this is currently part of the arm-perf/for-next/perf
> > > > > branch, it would be good to have the fix there as well.
> > > > > ---
> > > > > arch/arm/common/mcpm_entry.c | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > >
> > > > I'm happy to take this via the arm perf tree if others are ok with that.
> > > > Alternatively, I can revert the offending commit if there are objections
> > > > to exporting the symbol.
> > > >
> > > > Russell: do you any preference?
> > >
> > > As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
> > > patch. Do we know which tree has this?
> >
> > Yes, sorry, it's in my for-next/perf branch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=8b0c93c20ef78f15d8b760964ff79bda7f68c610
> >
> > which is now in -next.
> >
> > I'm happy to take the mcpm patch on top with your ack, but if you have
> > conflicting changes (or would prefer not to export the symbol to modules)
> > then I can just revert the patch in my tree for now.
>
> I have no changes to that file, so:
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks, I've picked up the fix from Arnd with your Ack and will push out
this evening.
Will
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Geert Uytterhoeven @ 2018-05-29 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <551905a6-eaa8-97df-06ec-1ceedfbc164f@arm.com>
Hi Sudeep,
On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
/sys/devices/system/cpu/cpu0/topology/core_id:0
/sys/devices/system/cpu/cpu0/topology/core_siblings:0f
/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu0/topology/physical_package_id:0
/sys/devices/system/cpu/cpu0/topology/thread_siblings:01
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
/sys/devices/system/cpu/cpu1/topology/core_id:1
/sys/devices/system/cpu/cpu1/topology/core_siblings:0f
/sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu1/topology/physical_package_id:0
/sys/devices/system/cpu/cpu1/topology/thread_siblings:02
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
/sys/devices/system/cpu/cpu2/topology/core_id:2
/sys/devices/system/cpu/cpu2/topology/core_siblings:0f
/sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu2/topology/physical_package_id:0
/sys/devices/system/cpu/cpu2/topology/thread_siblings:04
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
/sys/devices/system/cpu/cpu3/topology/core_id:3
/sys/devices/system/cpu/cpu3/topology/core_siblings:0f
/sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu3/topology/physical_package_id:0
/sys/devices/system/cpu/cpu3/topology/thread_siblings:08
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
/sys/devices/system/cpu/cpu4/topology/core_id:0
/sys/devices/system/cpu/cpu4/topology/core_siblings:f0
/sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu4/topology/physical_package_id:1
/sys/devices/system/cpu/cpu4/topology/thread_siblings:10
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/core_id:1
/sys/devices/system/cpu/cpu5/topology/core_siblings:f0
/sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu5/topology/physical_package_id:1
/sys/devices/system/cpu/cpu5/topology/thread_siblings:20
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/core_id:2
/sys/devices/system/cpu/cpu6/topology/core_siblings:f0
/sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu6/topology/physical_package_id:1
/sys/devices/system/cpu/cpu6/topology/thread_siblings:40
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/core_id:3
/sys/devices/system/cpu/cpu7/topology/core_siblings:f0
/sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu7/topology/physical_package_id:1
/sys/devices/system/cpu/cpu7/topology/thread_siblings:80
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
No change before/after (both match my view of the hardware).
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
No out-of-tree patches.
I'm testing plain 37c3ec2d810f87ea vs. 37c3ec2d810f87ea^.
There are power-domains in DT, but they're not managed by the new
fancy CPU power domain code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Geert Uytterhoeven @ 2018-05-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529150823.GD17159@arm.com>
Hi Will,
On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> >>> System supend still works fine on systems with big cores only:
>> >>>
>> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> >>> R-Car M3-N (2xCA57)
>> >>>
>> >>> Reverting this commit fixes the issue for me.
>> >>
>> >> I can't find anything that relates to system suspend in these patches
>> >> unless they are messing with something during CPU hot plug-in back
>> >> during resume.
>> >
>> > It's only the last patch that introduces the breakage.
>> >
>>
>> As specified in the commit log, it won't change any behavior for DT
>> systems if it's non-NUMA or single node system. So I am still wondering
>> what could trigger this regression.
>
> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> to the scheduler, although I can't see how this would happen.
>
> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> do you see anything shouting in dmesg?
Thanks, but unfortunately it doesn't help.
I added some debug code to print cpumask, but so far I don't see anything
suspicious.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Nicolas Pitre @ 2018-05-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529153013.GH17159@arm.com>
On Tue, 29 May 2018, Will Deacon wrote:
> Hi Arnd, Russell, [+Nico and Robin]
>
> On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > Now that the ARM CCI PMU driver can be built as a loadable module,
> > we get a link failure when MCPM is enabled:
> >
> > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> >
> > The simplest fix is to export that helper function.
> >
> > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > The patch that caused this is currently part of the arm-perf/for-next/perf
> > branch, it would be good to have the fix there as well.
> > ---
> > arch/arm/common/mcpm_entry.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I'm happy to take this via the arm perf tree if others are ok with that.
> Alternatively, I can revert the offending commit if there are objections
> to exporting the symbol.
Looks fine to me.
Acked-by: Nicolas Pitre <nico@linaro.org>
Nicolas
^ permalink raw reply
* [PATCH v4] arm64: allwinner: a64: Add Amarula A64-Relic initial support
From: Maxime Ripard @ 2018-05-29 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524111631.11864-1-jagan@amarulasolutions.com>
On Thu, May 24, 2018 at 04:46:31PM +0530, Jagan Teki wrote:
> Amarula A64-Relic is Allwinner A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - Mali-400MP2 GPU
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - AP6330 Wifi/BLE
> - MIPI-DSI
> - CSI: OV5640 sensor
> - USB OTG
> - 12V DC power supply
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Applied, thanks
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] rtc: sun6i: Fix bit_idx value for clk_register_gate
From: Jagan Teki @ 2018-05-29 16:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Trimarchi <michael@amarulasolutions.com>
clk-gate core will take bit_idx through clk_register_gate
and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i
is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx)
which is wrong and eventually external gate clock is not enabling.
This patch fixed by passing bit index and the original change
introduced from below commit.
"rtc: sun6i: Add support for the external oscillator gate"
(sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b)
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- add suffix _OFFSET with macro name to distinguish b/w
register actual values vs offset.
drivers/rtc/rtc-sun6i.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 2e6fb275acc8..2cd5a7b1a2e3 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -74,7 +74,7 @@
#define SUN6I_ALARM_CONFIG_WAKEUP BIT(0)
#define SUN6I_LOSC_OUT_GATING 0x0060
-#define SUN6I_LOSC_OUT_GATING_EN BIT(0)
+#define SUN6I_LOSC_OUT_GATING_EN_OFFSET 0
/*
* Get date values
@@ -255,7 +255,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
&clkout_name);
rtc->ext_losc = clk_register_gate(NULL, clkout_name, rtc->hw.init->name,
0, rtc->base + SUN6I_LOSC_OUT_GATING,
- SUN6I_LOSC_OUT_GATING_EN, 0,
+ SUN6I_LOSC_OUT_GATING_EN_OFFSET, 0,
&rtc->lock);
if (IS_ERR(rtc->ext_losc)) {
pr_crit("Couldn't register the LOSC external gate\n");
--
2.14.3
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-29 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529130504.lpkpgads7lfomois@verge.net.au>
On 05/29/2018 04:05 PM, Simon Horman wrote:
>> Define the generic R8A77980 parts of the I2C[0-5] device node.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 111 ++++++++++++++++++++++++++++++
>> 1 file changed, 111 insertions(+)
>>
>> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
[...]
>> @@ -135,6 +144,108 @@
[...]
>> + i2c3: i2c at e66d0000 {
>> + compatible = "renesas,i2c-r8a77980",
>> + "renesas,rcar-gen3-i2c";
>> + reg = <0 0xe66d0000 0 0x40>;
>> + interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&cpg CPG_MOD 928>;
>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>> + resets = <&cpg 928>;
>> + dmas = <&dmac1 0x97>, <&dmac1 0x96>,
>> + <&dmac2 0x97>, <&dmac2 0x96>;
>> + dma-names = "tx", "rx", "tx", "rx";
>> + i2c-scl-internal-delay-ns = <6>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>
> DMA for i2c3 and i2c4 seems unclear in v0.80 and v1.00 of the User's Manual.
> Although what is described here does match v0.55E of the User's Manual.
Hm, looking at all these manuals, I'm not even seeing V3H I2C3/4 having DMA
in v0.55E!
> Have you been able to confirm what is correct here?
No. Probably need to drop I2C3/4 DMA altogether...
> Other than that this patch looks fine to me.
TY!
[...]
MBR, Sergei
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Mathieu Poirier @ 2018-05-29 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529002538.GA11317@leoy-ThinkPad-X240s>
On 28 May 2018 at 18:25, Leo Yan <leo.yan@linaro.org> wrote:
> Hi Mathieu,
>
> On Mon, May 28, 2018 at 04:13:47PM -0600, Mathieu Poirier wrote:
>> Leo and/or Robert,
>>
>> On Mon, May 28, 2018 at 04:45:00PM +0800, Leo Yan wrote:
>> > Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
>> > traces") reworks the samples generation flow from CoreSight trace to
>> > match the correct format so Perf report tool can display the samples
>> > properly.
>> >
>> > But the change has side effect for branch packet handling, it only
>> > generate branch samples by checking previous packet flag
>> > 'last_instr_taken_branch' is true, this results in below three kinds
>> > packets are missed to generate branch samples:
>> >
>> > - The start tracing packet at the beginning of tracing data;
>> > - The exception handling packet;
>> > - If one CS_ETM_TRACE_ON packet is inserted, we also miss to handle it
>> > for branch samples. CS_ETM_TRACE_ON packet itself can give the info
>> > that there have a discontinuity in the trace, on the other hand we
>> > also miss to generate proper branch sample for packets before and
>> > after CS_ETM_TRACE_ON packet.
>> >
>> > This patch is to add branch sample handling for up three kinds packets:
>> >
>> > - In function cs_etm__sample(), check if 'prev_packet->sample_type' is
>> > zero and in this case it generates branch sample for the start tracing
>> > packet; furthermore, we also need to handle the condition for
>> > prev_packet::end_addr is zero in the cs_etm__last_executed_instr();
>> >
>> > - In function cs_etm__sample(), check if 'prev_packet->exc' is true and
>> > generate branch sample for exception handling packet;
>> >
>> > - If there has one CS_ETM_TRACE_ON packet is coming, we firstly generate
>> > branch sample in the function cs_etm__flush(), this can save complete
>> > info for the previous CS_ETM_RANGE packet just before CS_ETM_TRACE_ON
>> > packet. We also generate branch sample for the new CS_ETM_RANGE
>> > packet after CS_ETM_TRACE_ON packet, this have two purposes, the
>> > first one purpose is to save the info for the new CS_ETM_RANGE packet,
>> > the second purpose is to save CS_ETM_TRACE_ON packet info so we can
>> > have hint for a discontinuity in the trace.
>> >
>> > For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
>> > 'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
>> > the decoder layer as dummy value. This patch is to convert these
>> > values to zeros for more readable; this is accomplished by functions
>> > cs_etm__last_executed_instr() and cs_etm__first_executed_instr(). The
>> > later one is a new function introduced by this patch.
>> >
>> > Reviewed-by: Robert Walker <robert.walker@arm.com>
>> > Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight traces")
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> > tools/perf/util/cs-etm.c | 93 +++++++++++++++++++++++++++++++++++++-----------
>> > 1 file changed, 73 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>> > index 822ba91..8418173 100644
>> > --- a/tools/perf/util/cs-etm.c
>> > +++ b/tools/perf/util/cs-etm.c
>> > @@ -495,6 +495,20 @@ static inline void cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq)
>> > static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
>> > {
>> > /*
>> > + * The packet is the start tracing packet if the end_addr is zero,
>> > + * returns 0 for this case.
>> > + */
>> > + if (!packet->end_addr)
>> > + return 0;
>>
>> What is considered to be the "start tracing packet"? Right now the only two
>> kind of packets inserted in the decoder packet buffer queue are INST_RANGE and
>> TRACE_ON. How can we hit a condition where packet->end-addr == 0?
>
> When the first CS_ETM_RANGE packet is coming, etmq->prev_packet is
> initialized by the function cs_etm__alloc_queue(), so
> etmq->prev_packet->end_addr is zero:
>
> etmq->prev_packet = zalloc(szp);
>
> As you mentioned, we should only have two kind of packets for
> CS_ETM_RANGE and CS_ETM_TRACE_ON. Currently we skip to handle the
> first CS_ETM_TRACE_ON packet in function cs_etm__flush(), we also can
> refine the function cs_etm__flush() to handle the first coming
> CS_ETM_TRACE_ON packet, after that all packets will be CS_ETM_RANGE
> and CS_ETM_TRACE_ON and have no chance to hit 'packet->end_addr = 0'.
>
> Does this make sense for you?
That is the right way to handle this condition and it gives us a
reliable state machine.
>
> --- Packet dumping when first packet coming ---
> cs_etm__flush: prev_packet: sample_type=0 exc=0 exc_ret=0 cpu=0 start_addr=0x0 end_addr=0x0 last_instr_taken_branch=0
> cs_etm__flush: packet: sample_type=2 exc=0 exc_ret=0 cpu=1 start_addr=0xdeadbeefdeadbeef end_addr=0xdeadbeefdeadbeef last_instr_taken_branch=0
>
>> > +
>> > + /*
>> > + * The packet is the CS_ETM_TRACE_ON packet if the end_addr is
>> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>> > + */
>> > + if (packet->end_addr == 0xdeadbeefdeadbeefUL)
>> > + return 0;
>>
>> As it is with the above, I find triggering on addresses to be brittle and hard
>> to maintain on the long run. Packets all have a sample_type field that should
>> be used in cases like this one. That way we know exactly the condition that is
>> targeted.
>
> Will do this.
>
>> While working on this set, please spin-off another patch that defines
>> CS_ETM_INVAL_ADDR 0xdeadbeefdeadbeefUL and replace all the cases where the
>> numeral is used. That way we stop using the hard coded value.
>
> Will do this.
Much appreciated.
>
> As now this patch is big with more complex logic, so I consider to
> split it into small patches:
>
> - Define CS_ETM_INVAL_ADDR;
> - Fix for CS_ETM_TRACE_ON packet;
> - Fix for exception packet;
>
> Does this make sense for you? I have concern that this patch is a
> fixing patch, so not sure after spliting patches will introduce
> trouble for applying them for other stable kernels ...
Reverse the order:
- Fix for CS_ETM_TRACE_ON packet;
- Fix for exception packet;
- Define CS_ETM_INVAL_ADDR;
But you may not need to - see next comment.
>
>> > +
>> > + /*
>> > * The packet records the execution range with an exclusive end address
>> > *
>> > * A64 instructions are constant size, so the last executed
>> > @@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
>> > return packet->end_addr - A64_INSTR_SIZE;
>> > }
>> >
>> > +static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
>> > +{
>> > + /*
>> > + * The packet is the CS_ETM_TRACE_ON packet if the start_addr is
>> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>> > + */
>> > + if (packet->start_addr == 0xdeadbeefdeadbeefUL)
>> > + return 0;
>>
>> Same comment as above.
>
> Will do this.
>
>> > +
>> > + return packet->start_addr;
>> > +}
>> > +
>> > static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
>> > {
>> > /*
>> > @@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq)
>> >
>> > be = &bs->entries[etmq->last_branch_pos];
>> > be->from = cs_etm__last_executed_instr(etmq->prev_packet);
>> > - be->to = etmq->packet->start_addr;
>> > + be->to = cs_etm__first_executed_instr(etmq->packet);
>> > /* No support for mispredict */
>> > be->flags.mispred = 0;
>> > be->flags.predicted = 1;
>> > @@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq)
>> > sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
>> > sample.pid = etmq->pid;
>> > sample.tid = etmq->tid;
>> > - sample.addr = etmq->packet->start_addr;
>> > + sample.addr = cs_etm__first_executed_instr(etmq->packet);
>> > sample.id = etmq->etm->branches_id;
>> > sample.stream_id = etmq->etm->branches_id;
>> > sample.period = 1;
>> > @@ -897,13 +923,28 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
>> > etmq->period_instructions = instrs_over;
>> > }
>> >
>> > - if (etm->sample_branches &&
>> > - etmq->prev_packet &&
>> > - etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>> > - etmq->prev_packet->last_instr_taken_branch) {
>> > - ret = cs_etm__synth_branch_sample(etmq);
>> > - if (ret)
>> > - return ret;
>> > + if (etm->sample_branches && etmq->prev_packet) {
>> > + bool generate_sample = false;
>> > +
>> > + /* Generate sample for start tracing packet */
>> > + if (etmq->prev_packet->sample_type == 0 ||
>>
>> What kind of packet is sample_type == 0 ?
>
> Just as explained above, sample_type == 0 is the packet which
> initialized in the function cs_etm__alloc_queue().
>
>> > + etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
>> > + generate_sample = true;
>> > +
>> > + /* Generate sample for exception packet */
>> > + if (etmq->prev_packet->exc == true)
>> > + generate_sample = true;
>>
>> Please don't do that. Exception packets have a type of their own and can be
>> added to the decoder packet queue the same way INST_RANGE and TRACE_ON packets
>> are. Moreover exception packet containt an address that, if I'm reading the
>> documenation properly, can be used to keep track of instructions that were
>> executed between the last address of the previous range packet and the address
>> executed just before the exception occurred. Mike and Rob will have to confirm
>> this as the decoder may be doing all that hard work for us.
>
> Sure, will wait for Rob and Mike to confirm for this.
>
> At my side, I dump the packet, the exception packet isn't passed to
> cs-etm.c layer, the decoder layer only sets the flag
> 'packet->exc = true' when exception packet is coming [1].
That's because we didn't need the information. Now that we do a
function that will insert a packet in the decoder packet queue and
deal with the new packet type in the main decoder loop [2]. At that
point your work may not be eligible for stable anymore and I think it
is fine. Robert's work was an enhancement over mine and yours is an
enhancement over his.
[2]. https://elixir.bootlin.com/linux/v4.17-rc7/source/tools/perf/util/cs-etm.c#L999
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c#n364
>
>> > +
>> > + /* Generate sample for normal branch packet */
>> > + if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>> > + etmq->prev_packet->last_instr_taken_branch)
>> > + generate_sample = true;
>> > +
>> > + if (generate_sample) {
>> > + ret = cs_etm__synth_branch_sample(etmq);
>> > + if (ret)
>> > + return ret;
>> > + }
>> > }
>> >
>> > if (etm->sample_branches || etm->synth_opts.last_branch) {
>> > @@ -922,11 +963,16 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
>> > static int cs_etm__flush(struct cs_etm_queue *etmq)
>> > {
>> > int err = 0;
>> > + struct cs_etm_auxtrace *etm = etmq->etm;
>> > struct cs_etm_packet *tmp;
>> >
>> > - if (etmq->etm->synth_opts.last_branch &&
>> > - etmq->prev_packet &&
>> > - etmq->prev_packet->sample_type == CS_ETM_RANGE) {
>> > + if (!etmq->prev_packet)
>> > + return 0;
>> > +
>> > + if (etmq->prev_packet->sample_type != CS_ETM_RANGE)
>> > + return 0;
>> > +
>> > + if (etmq->etm->synth_opts.last_branch) {
>>
>> If you add:
>>
>> if (!etmq->etm->synth_opts.last_branch)
>> return 0;
>>
>> You can avoid indenting the whole block.
>
> No, here we cannot do like this. Except we need to handle the
> condition for 'etmq->etm->synth_opts.last_branch', we also need to
> handle 'etm->sample_branches'. These two conditions are saperate and
> decide by different command parameters from 'perf script'.
Pardon me - I didn't see the addition of the new '}' just below.
>
>> > /*
>> > * Generate a last branch event for the branches left in the
>> > * circular buffer at the end of the trace.
>> > @@ -939,18 +985,25 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
>> > err = cs_etm__synth_instruction_sample(
>> > etmq, addr,
>> > etmq->period_instructions);
>> > + if (err)
>> > + return err;
>> > etmq->period_instructions = 0;
>> > + }
>> >
>> > - /*
>> > - * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
>> > - * the next incoming packet.
>> > - */
>> > - tmp = etmq->packet;
>> > - etmq->packet = etmq->prev_packet;
>> > - etmq->prev_packet = tmp;
>> > + if (etm->sample_branches) {
>> > + err = cs_etm__synth_branch_sample(etmq);
>> > + if (err)
>> > + return err;
>> > }
>> >
>> > - return err;
>> > + /*
>> > + * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
>> > + * the next incoming packet.
>> > + */
>> > + tmp = etmq->packet;
>> > + etmq->packet = etmq->prev_packet;
>> > + etmq->prev_packet = tmp;
>>
>> Robert, I remember noticing that when you first submitted the code but forgot to
>> go back to it. What is the point of swapping the packets? I understand
>>
>> etmq->prev_packet = etmq->packet;
>>
>> But not
>>
>> etmq->packet = tmp;
>>
>> After all etmq->packet will be clobbered as soon as cs_etm_decoder__get_packet()
>> is called, which is alwasy right after either cs_etm__sample() or
>> cs_etm__flush().
>
> Yeah, I have the same question for this :)
>
> Thanks for suggestions and reviewing.
>
>> Thanks,
>> Mathieu
>>
>>
>>
>> > + return 0;
>> > }
>> >
>> > static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
* [PATCH v2] rtc: sun6i: Fix bit_idx value for clk_register_gate
From: Maxime Ripard @ 2018-05-29 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529160425.23697-1-jagan@amarulasolutions.com>
On Tue, May 29, 2018 at 09:34:25PM +0530, Jagan Teki wrote:
> From: Michael Trimarchi <michael@amarulasolutions.com>
>
> clk-gate core will take bit_idx through clk_register_gate
> and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i
> is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx)
> which is wrong and eventually external gate clock is not enabling.
>
> This patch fixed by passing bit index and the original change
> introduced from below commit.
> "rtc: sun6i: Add support for the external oscillator gate"
> (sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b)
>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
I said it in the v1 already, but this should be sent to stable and
have a fixes tag.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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