* Re: [PATCH] cpuidle: psci: Fixup execution order when entering a domain idle state
From: Rafael J. Wysocki @ 2020-05-15 16:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Lorenzo Pieralisi, Benjamin Gaignard, Linux PM, Stephen Boyd,
Daniel Lezcano, Rafael J . Wysocki, Lina Iyer, Bjorn Andersson,
Sudeep Holla, Linux ARM
In-Reply-To: <CAPDyKFrsfLExZHvNrJgqsJj8TTzj9jg5v=jEowBTdi26uyjZXg@mail.gmail.com>
On Fri, May 15, 2020 at 1:30 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 15 May 2020 at 12:23, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Thu, May 14, 2020 at 09:11:50PM +0200, Ulf Hansson wrote:
> > >
> > > No worries, thanks for reviewing.
> > >
> >
> > You are welcome.
> >
> > > That said, are you fine with Rafel queuing this then?
> > >
> >
> > I am fine with that. However I told if you need fixes tags as there are
> > no users of the notification yet in the kernel. Though this is trivial,
> > but do we need this backported to stable kernel. I don't have strong
> > opinion and leave it to you and Rafael.
>
> I wanted to add the fixes tag, to make it obvious that there is an
> error being fixed.
>
> On the other hand, no need to tag this for stable, nor to need to send
> it as fix for 5.7,
>
> >
> > Acked-by: Sudeep Holla <sudeep.holla@arm.com>
>
> Thanks!
So applied as 5.8 material, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ACPI: GED: add support for _Exx / _Lxx handler methods
From: Rafael J. Wysocki @ 2020-05-15 16:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Stable,
ACPI Devel Maling List, Linux ARM, Len Brown
In-Reply-To: <20200515093613.18691-1-ardb@kernel.org>
On Fri, May 15, 2020 at 11:37 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Per the ACPI spec, interrupts in the range [0, 255] may be handled
> in AML using individual methods whose naming is based on the format
> _Exx or _Lxx, where xx is the hex representation of the interrupt
> index.
>
> Add support for this missing feature to our ACPI GED driver.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> Cc: linux-acpi@vger.kernel.org
> Cc: <stable@vger.kernel.org> # v4.9+
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> drivers/acpi/evged.c | 22 +++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
> index aba0d0027586..6d7a522952bf 100644
> --- a/drivers/acpi/evged.c
> +++ b/drivers/acpi/evged.c
> @@ -79,6 +79,8 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
> struct resource r;
> struct acpi_resource_irq *p = &ares->data.irq;
> struct acpi_resource_extended_irq *pext = &ares->data.extended_irq;
> + char ev_name[5];
> + u8 trigger;
>
> if (ares->type == ACPI_RESOURCE_TYPE_END_TAG)
> return AE_OK;
> @@ -87,14 +89,28 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
> dev_err(dev, "unable to parse IRQ resource\n");
> return AE_ERROR;
> }
> - if (ares->type == ACPI_RESOURCE_TYPE_IRQ)
> + if (ares->type == ACPI_RESOURCE_TYPE_IRQ) {
> gsi = p->interrupts[0];
> - else
> + trigger = p->triggering;
> + } else {
> gsi = pext->interrupts[0];
> + trigger = p->triggering;
> + }
>
> irq = r.start;
>
> - if (ACPI_FAILURE(acpi_get_handle(handle, "_EVT", &evt_handle))) {
> + switch (gsi) {
> + case 0 ... 255:
> + sprintf(ev_name, "_%c%02hhX",
> + trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
> +
> + if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle)))
> + break;
> + /* fall through */
> + default:
> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_EVT", &evt_handle)))
> + break;
> +
> dev_err(dev, "cannot locate _EVT method\n");
> return AE_ERROR;
> }
> --
Applied as 5.8 material, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/14] arm64: dts: sparx5: Add basic cpu support
From: Marc Zyngier @ 2020-05-15 16:31 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, Stephen Boyd,
Linus Walleij, linux-kernel, linux-clk, linux-gpio, SoC Team,
Michael Turquette, Olof Johansson, Microchip Linux Driver Support,
Steen Hegelund, linux-arm-kernel
In-Reply-To: <871rnlp740.fsf@soft-dev15.microsemi.net>
[using the correct email address this time]
On 2020-05-15 16:09, Lars Povlsen wrote:
> Marc Zyngier writes:
>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> On 2020-05-13 13:55, Lars Povlsen wrote:
>>> This adds the basic DT structure for the Microchip Sparx5 SoC, and
>>> the
>>> reference boards, pcb125, pcb134 and pcb135. The two latter have a
>>> NAND vs a eMMC centric variant (as a mount option),
>>>
>>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>>> ---
>>> MAINTAINERS | 1 +
>>> arch/arm64/boot/dts/Makefile | 1 +
>>> arch/arm64/boot/dts/microchip/Makefile | 4 +
>>> arch/arm64/boot/dts/microchip/sparx5.dtsi | 135
>>> ++++++++++++++++++
>>> .../boot/dts/microchip/sparx5_pcb125.dts | 17 +++
>>> .../boot/dts/microchip/sparx5_pcb134.dts | 17 +++
>>> .../dts/microchip/sparx5_pcb134_board.dtsi | 15 ++
>>> .../boot/dts/microchip/sparx5_pcb134_emmc.dts | 17 +++
>>> .../boot/dts/microchip/sparx5_pcb135.dts | 17 +++
>>> .../dts/microchip/sparx5_pcb135_board.dtsi | 15 ++
>>> .../boot/dts/microchip/sparx5_pcb135_emmc.dts | 17 +++
>>> .../boot/dts/microchip/sparx5_pcb_common.dtsi | 15 ++
>>> 12 files changed, 271 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/microchip/Makefile
>>> create mode 100644 arch/arm64/boot/dts/microchip/sparx5.dtsi
>>> create mode 100644 arch/arm64/boot/dts/microchip/sparx5_pcb125.dts
>>> create mode 100644 arch/arm64/boot/dts/microchip/sparx5_pcb134.dts
>>> create mode 100644
>>> arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
>>> create mode 100644
>>> arch/arm64/boot/dts/microchip/sparx5_pcb134_emmc.dts
>>> create mode 100644 arch/arm64/boot/dts/microchip/sparx5_pcb135.dts
>>> create mode 100644
>>> arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
>>> create mode 100644
>>> arch/arm64/boot/dts/microchip/sparx5_pcb135_emmc.dts
>>> create mode 100644
>>> arch/arm64/boot/dts/microchip/sparx5_pcb_common.dtsi
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 1b5a18d3dbb9f..5aa28d6e39d4f 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2084,6 +2084,7 @@ M: Lars Povlsen
>>> <lars.povlsen@microchip.com>
>>> M: Steen Hegelund <Steen.Hegelund@microchip.com>
>>> M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
>>> L: linux-arm-kernel@lists.infradead.org (moderated for
>>> non-subscribers)
>>> +F: arch/arm64/boot/dts/microchip/
>>> N: sparx5
>>> S: Supported
>>>
>>> diff --git a/arch/arm64/boot/dts/Makefile
>>> b/arch/arm64/boot/dts/Makefile
>>> index f19b762c008d8..9680a7f20c307 100644
>>> --- a/arch/arm64/boot/dts/Makefile
>>> +++ b/arch/arm64/boot/dts/Makefile
>>> @@ -17,6 +17,7 @@ subdir-y += intel
>>> subdir-y += lg
>>> subdir-y += marvell
>>> subdir-y += mediatek
>>> +subdir-y += microchip
>>> subdir-y += nvidia
>>> subdir-y += qcom
>>> subdir-y += realtek
>>> diff --git a/arch/arm64/boot/dts/microchip/Makefile
>>> b/arch/arm64/boot/dts/microchip/Makefile
>>> new file mode 100644
>>> index 0000000000000..c6e0313eea0f9
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/microchip/Makefile
>>> @@ -0,0 +1,4 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb125.dtb
>>> +dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb134.dtb
>>> sparx5_pcb134_emmc.dtb
>>> +dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb135.dtb
>>> sparx5_pcb135_emmc.dtb
>>> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
>>> b/arch/arm64/boot/dts/microchip/sparx5.dtsi
>>> new file mode 100644
>>> index 0000000000000..3136b4369f507
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
>>> @@ -0,0 +1,135 @@
>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> +/*
>>> + * Copyright (c) 2020 Microchip Technology Inc. and its
>>> subsidiaries.
>>> + */
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +
>>> +/ {
>>> + compatible = "microchip,sparx5";
>>> + interrupt-parent = <&gic>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + serial1 = &uart1;
>>> + };
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + cpus {
>>> + #address-cells = <2>;
>>> + #size-cells = <0>;
>>> + cpu-map {
>>> + cluster0 {
>>> + core0 {
>>> + cpu = <&cpu0>;
>>> + };
>>> + core1 {
>>> + cpu = <&cpu1>;
>>> + };
>>> + };
>>> + };
>>> + cpu0: cpu@0 {
>>> + compatible = "arm,cortex-a53", "arm,armv8";
>>> + device_type = "cpu";
>>> + reg = <0x0 0x0>;
>>> + enable-method = "spin-table";
>>
>> Really? This is 2020, not 2012 any more. Surely a new platform
>> boots using PSCI, and not *this*.
>>
>
> We don't currently support PSCI. The platform does not have TrustZone,
> hence we don't use ATF.
It does have EL3, as you cannot remove EL3 from A53. Hence it can run
a secure payload, and thus PSCI. TrustZone really is something else,
not directly related to ATF (which will run fine on this HW).
> We use U-Boot as the (only) bootloader, providing the spintable. I
> looked
> at adding PSCI (in U-Boot) initially, but as most other platforms were
> using ATF the PSCI support was buggy and caused me to go for spintable.
It should be absolutely trivial to fix, and I'd suggest you do that
rather than add this cruft. Even porting ATF to your platform should be
pretty easy.
> Is spintable being deprecated?
It was only ever there to support systems that cannot rely on a more
privileged exception level to power-on the CPUs. There is exactly *one*
CPU of this kind in the wild (Applied Micro's X-Gene). Everything else
should be using PSCI.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] coresight: etm4x: Add support to disable trace unit power up
From: Sai Prakash Ranjan @ 2020-05-15 16:25 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, Tingwei Zhang, Leo Yan,
linux-arm-kernel, Mike Leach
In-Reply-To: <89be7790b7fdd4b0268919e060198926@codeaurora.org>
On 2020-05-15 21:28, Sai Prakash Ranjan wrote:
> Hi Mathieu,
>
> On 2020-05-15 21:21, Mathieu Poirier wrote:
>> On Fri, May 15, 2020 at 08:37:13PM +0530, Sai Prakash Ranjan wrote:
>>> Hi Mathieu,
>>>
>>> On 2020-05-15 20:22, Mathieu Poirier wrote:
>>> > On Thu, 14 May 2020 at 12:39, Sai Prakash Ranjan
>>> > <saiprakash.ranjan@codeaurora.org> wrote:
>>> > >
>>> > > Hi Mathieu,
>>> > >
>>> > > On 2020-05-14 23:30, Mathieu Poirier wrote:
>>> > > > Good morning Sai,
>>> > > >
>>> > > > On Thu, May 14, 2020 at 04:29:15PM +0530, Sai Prakash Ranjan wrote:
>>> > > >> From: Tingwei Zhang <tingwei@codeaurora.org>
>>> > > >>
>>> > > >> On some Qualcomm Technologies Inc. SoCs like SC7180, there
>>> > > >> exists a hardware errata where the APSS (Application Processor
>>> > > >> SubSystem)/CPU watchdog counter is stopped when ETM register
>>> > > >> TRCPDCR.PU=1.
>>> > > >
>>> > > > Fun stuff...
>>> > > >
>>> > >
>>> > > Yes :)
>>> > >
>>> > > >> Since the ETMs share the same power domain as
>>> > > >> that of respective CPU cores, they are powered on when the
>>> > > >> CPU core is powered on. So we can disable powering up of the
>>> > > >> trace unit after checking for this errata via new property
>>> > > >> called "qcom,tupwr-disable".
>>> > > >>
>>> > > >> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>>> > > >> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>>> > > >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>>> > > >
>>> > > > Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>>> > > > Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>>> > > >
>>> > >
>>> > > Tingwei is the author, so if I understand correctly, his signed-off-by
>>> > > should appear first, am I wrong?
>>> >
>>> > It's a gray area and depends on who's code is more prevalent in the
>>> > patch. If Tingwei wrote the most of the code then his name is in the
>>> > "from:" section, yours as co-developer and he signs off on it (as I
>>> > suggested). If you did most of the work then it is the opposite.
>>> > Adding a Co-developed and a signed-off with the same name doesn't make
>>> > sense.
>>> >
>>>
>>> I did check the documentation for submitting patches:
>>> Documentation/process/submitting-patches.rst. And it clearly states
>>> that "Co-developed-by must be followed by Signed-off by the co-author
>>> and the last Signed-off-by: must always be that of the developer
>>> submitting the patch".
>>>
>>> Quoting below from the doc:
>>>
>>> Co-developed-by: <snip> ...Since
>>> Co-developed-by: denotes authorship, every Co-developed-by: must be
>>> immediately
>>> followed by a Signed-off-by: of the associated co-author. Standard
>>> sign-off
>>> procedure applies, i.e. the ordering of Signed-off-by: tags should
>>> reflect
>>> the
>>> chronological history of the patch insofar as possible, regardless of
>>> whether
>>> the author is attributed via From: or Co-developed-by:. Notably, the
>>> last
>>> Signed-off-by: must always be that of the developer submitting the
>>> patch.
>>
>> Ah yes, glad to see that got clarified. You can ignore my
>> recommendation on
>> that snippet.
>>
>>>
>>> > >
>>> > > >> ---
>>> > > >> .../devicetree/bindings/arm/coresight.txt | 6 ++++
>>> > > >> drivers/hwtracing/coresight/coresight-etm4x.c | 29
>>> > > >> ++++++++++++-------
>>> > > >
>>> > > > Please split in two patches.
>>> > > >
>>> > >
>>> > > Sure, I will split the dt-binding into separate patch, checkpatch did
>>> > > warn.
>>> >
>>> > And you still sent me the patch... I usually run checkpatch before
>>> > all the submissions I review and flatly ignore patches that return
>>> > errors. You got lucky...
>>> >
>>>
>>> I did not mean to ignore it or else I wouldn't have run checkpatch
>>> itself.
>>> I checked other cases like "arm,scatter-gather" where the binding and
>>> the
>>> driver change was in a single patch, hence I thought it's not a very
>>> strict
>>> rule.
>>
>> The patch has another warning for a line over 80 characters, that
>> should have
>> been fixed before sending. Putting DT changes in a separate patch is
>> always
>> better for the DT people. They review tons of patches and making
>> their life
>> easier is always a good thing.
>>
>
> Ok, I will fix this and resend. I did not want to change it in case if
> it affects
> readability since most maintainers prefer to ignore this 80 characters
> warning if
> it affects readability. I will keep this in mind for future patches as
> well.
>
Now fixed all checkpatch warnings and addressed other review comments.
Posted v3 - https://lore.kernel.org/patchwork/cover/1242572/
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Call debug_traps_init() from trap_init() to help early kgdb
From: Will Deacon @ 2020-05-15 16:23 UTC (permalink / raw)
To: Douglas Anderson
Cc: Mark Rutland, sumit.garg, Daniel Thompson, linux-arm-kernel,
Paul E. McKenney, Greg Kroah-Hartman, Enrico Weigelt,
kgdb-bugreport, jinho lim, Jason Wessel, linux-kernel,
Alexios Zavras, James Morse, Eric W. Biederman, Catalin Marinas,
Zenghui Yu, Thomas Gleixner, liwei391, Dave Martin,
Allison Randal, Masami Hiramatsu
In-Reply-To: <20200513160501.1.I0b5edf030cc6ebef6ab4829f8867cdaea42485d8@changeid>
On Wed, May 13, 2020 at 04:06:37PM -0700, Douglas Anderson wrote:
> A new kgdb feature will soon land (kgdb_earlycon) that lets us run
> kgdb much earlier. In order for everything to work properly it's
> important that the break hook is setup by the time we process
> "kgdbwait".
>
> Right now the break hook is setup in debug_traps_init() and that's
> called from arch_initcall(). That's a bit too late since
> kgdb_earlycon really needs things to be setup by the time the system
> calls dbg_late_init().
>
> We could fix this by adding call_break_hook() into early_brk64() and
> that works fine. However, it's a little ugly. Instead, let's just
> add a call to debug_traps_init() straight from trap_init(). There's
> already a documented dependency between trap_init() and
> debug_traps_init() and this makes the dependency more obvious rather
> than just relying on a comment.
>
> NOTE: this solution isn't early enough to let us select the
> "ARCH_HAS_EARLY_DEBUG" KConfig option that is introduced by the
> kgdb_earlycon patch series. That would only be set if we could do
> breakpoints when early params are parsed. This patch only enables
> "late early" breakpoints, AKA breakpoints when dbg_late_init() is
> called. It's expected that this should be fine for most people.
>
> It should also be noted that if you crash you can still end up in kgdb
> earlier than debug_traps_init(). Since you don't need breakpoints to
> debug a crash that's fine.
>
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> This replaces the patch ("arm64: Add call_break_hook() to
> early_brk64() for early kgdb") in my recent kgdb series [1]. If I end
> up re-posting that series again I'll include this patch as a
> replacement, but I'm sending it separately to avoid spamming a pile of
> people another time with a 12-patch series.
>
> Note that, because it doesn't select the "ARCH_HAS_EARLY_DEBUG"
> KConfig option it could be landed standalone. However, it's still
> probably better to land together with that patch series.
>
> If the kgdb_earlycon patch series lands without this patch then
> kgdbwait + kgdb_earlycon won't work well on arm64, but there would be
> no other bad side effects.
>
> If this patch lands without the kgdb_earlycon patch series then there
> will be no known problems.
>
> [1] https://lore.kernel.org/r/20200507130644.v4.5.I22067ad43e77ddfd4b64c2d49030628480f9e8d9@changeid
>
> arch/arm64/include/asm/debug-monitors.h | 2 ++
> arch/arm64/kernel/debug-monitors.c | 4 +---
> arch/arm64/kernel/traps.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
[...]
Acked-by: Will Deacon <will@kernel.org>
I would prefer to take this via arm64, if possible, since we have quite lot
going in for 5.8, although I don't think this conflicts at the moment.
Daniel -- what do you want to do?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv3 2/2] dt-bindings: arm: coresight: Add support to skip trace unit power up
From: Sai Prakash Ranjan @ 2020-05-15 16:22 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel
In-Reply-To: <cover.1589558615.git.saiprakash.ranjan@codeaurora.org>
From: Tingwei Zhang <tingwei@codeaurora.org>
Add "qcom,skip-power-up" property to identify systems which can
skip powering up of trace unit since they share the same power
domain as their CPU core. This is required to identify such
systems with hardware errata which stops the CPU watchdog counter
when the power up bit is set (TRCPDCR.PU).
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
Documentation/devicetree/bindings/arm/coresight.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 846f6daae71b..e4b2eda0b53b 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -108,6 +108,13 @@ its hardware characteristcs.
* arm,cp14: must be present if the system accesses ETM/PTM management
registers via co-processor 14.
+ * qcom,skip-power-up: boolean. Indicates that an implementation can
+ skip powering up the trace unit. TRCPDCR.PU does not have to be set
+ on Qualcomm Technologies Inc. systems since ETMs are in the same power
+ domain as their CPU cores. This property is required to identify such
+ systems with hardware errata where the CPU watchdog counter is stopped
+ when TRCPDCR.PU is set.
+
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 1/2] coresight: etm4x: Add support to skip trace unit power up
From: Sai Prakash Ranjan @ 2020-05-15 16:22 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel
In-Reply-To: <cover.1589558615.git.saiprakash.ranjan@codeaurora.org>
From: Tingwei Zhang <tingwei@codeaurora.org>
On some Qualcomm Technologies Inc. SoCs like SC7180, there
exists a hardware errata where the APSS (Application Processor
SubSystem)/CPU watchdog counter is stopped when the trace unit
power up ETM register is set (TRCPDCR.PU = 1). Since the ETMs
share the same power domain as that of respective CPU cores,
they are powered on when the CPU core is powered on. So we can
skip powering up of trace unit after checking for this errata
via new property called "qcom,skip-power-up".
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++++++++++++-------
drivers/hwtracing/coresight/coresight-etm4x.h | 3 +++
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index fb0f5f4f3a91..c16532e1e968 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -196,12 +196,14 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
writel_relaxed(config->vmid_mask0, drvdata->base + TRCVMIDCCTLR0);
writel_relaxed(config->vmid_mask1, drvdata->base + TRCVMIDCCTLR1);
- /*
- * Request to keep the trace unit powered and also
- * emulation of powerdown
- */
- writel_relaxed(readl_relaxed(drvdata->base + TRCPDCR) | TRCPDCR_PU,
- drvdata->base + TRCPDCR);
+ if (!drvdata->skip_power_up) {
+ /*
+ * Request to keep the trace unit powered and also
+ * emulation of powerdown
+ */
+ writel_relaxed(readl_relaxed(drvdata->base + TRCPDCR) |
+ TRCPDCR_PU, drvdata->base + TRCPDCR);
+ }
/* Enable the trace unit */
writel_relaxed(1, drvdata->base + TRCPRGCTLR);
@@ -476,10 +478,12 @@ static void etm4_disable_hw(void *info)
CS_UNLOCK(drvdata->base);
- /* power can be removed from the trace unit now */
- control = readl_relaxed(drvdata->base + TRCPDCR);
- control &= ~TRCPDCR_PU;
- writel_relaxed(control, drvdata->base + TRCPDCR);
+ if (!drvdata->skip_power_up) {
+ /* power can be removed from the trace unit now */
+ control = readl_relaxed(drvdata->base + TRCPDCR);
+ control &= ~TRCPDCR_PU;
+ writel_relaxed(control, drvdata->base + TRCPDCR);
+ }
control = readl_relaxed(drvdata->base + TRCPRGCTLR);
@@ -1429,6 +1433,9 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
return -ENOMEM;
}
+ if (fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up"))
+ drvdata->skip_power_up = true;
+
/* Validity for the resource is already checked by the AMBA core */
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 4a695bf90582..72c9a55e67df 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -407,6 +407,8 @@ struct etmv4_save_state {
* @config: structure holding configuration parameters.
* @save_state: State to be preserved across power loss
* @state_needs_restore: True when there is context to restore after PM exit
+ * @skip_power_up: Indicates if an implementation can skip powering up
+ * the trace unit.
*/
struct etmv4_drvdata {
void __iomem *base;
@@ -454,6 +456,7 @@ struct etmv4_drvdata {
struct etmv4_config config;
struct etmv4_save_state *save_state;
bool state_needs_restore;
+ bool skip_power_up;
};
/* Address comparator access types */
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 0/2] coresight: etm4x: Add support to skip trace unit power up
From: Sai Prakash Ranjan @ 2020-05-15 16:22 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel
This series adds support to skip powering up of trace unit on systems
with an errata which stops CPU watchdog counter when power up bit is
set (TRCPDCR.PU = 1). Setting this bit is not required on Qualcomm
Technologies Inc. chipsets where this errata exists since the ETMs
are in the same power domain as their respective CPU cores.
Changes since v2:
* Fix checkpatch warning for 80 characters.
Changes since v1:
* Use qcom,skip-power-up for naming as suggested by Mathieu.
* Have check for DT property in initialization as per Mathieu.
* Reword description for property as per Mathieu.
* Split up dt-binding patch as checkpatch complains.
Tingwei Zhang (2):
coresight: etm4x: Add support to skip trace unit power up
dt-bindings: arm: coresight: Add support to skip trace unit power up
.../devicetree/bindings/arm/coresight.txt | 7 +++++
drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++++++++++++-------
drivers/hwtracing/coresight/coresight-etm4x.h | 3 +++
3 files changed, 27 insertions(+), 10 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: vdso: Fix CFI info in sigreturn.
From: dankis01 @ 2020-05-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel, Vincenzo.Frascino, mark.rutland
Cc: Tamas Zsoldos, Daniel Kiss
When the signal handler is called the registers set up as the return address
points to the __kernel_rt_sigreturn. The NOP here is the placeholder of the
branch and link instruction that "calls" the signal handler. In case of a
return address the unwinder identifies the location of the caller because
in some cases the return address might not exist. Since the .cfi_startproc
is after the NOP, it won't be associated with any location and the
unwinder will stop walking.
This change corrects the generated EHFrames only.
Signed-off-by: Daniel Kiss <daniel.kiss@arm.com>
Signed-off-by: Tamas Zsoldos <tamas.zsoldos@arm.com>
---
arch/arm64/kernel/vdso/sigreturn.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/vdso/sigreturn.S b/arch/arm64/kernel/vdso/sigreturn.S
index 12324863d5c2..5d50ee92faa4 100644
--- a/arch/arm64/kernel/vdso/sigreturn.S
+++ b/arch/arm64/kernel/vdso/sigreturn.S
@@ -13,13 +13,13 @@
.text
- nop
-SYM_FUNC_START(__kernel_rt_sigreturn)
.cfi_startproc
.cfi_signal_frame
.cfi_def_cfa x29, 0
.cfi_offset x29, 0 * 8
.cfi_offset x30, 1 * 8
+ nop /* placeholder for bl signalhandler */
+SYM_FUNC_START(__kernel_rt_sigreturn)
mov x8, #__NR_rt_sigreturn
svc #0
.cfi_endproc
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v8 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Yingjoe Chen @ 2020-05-15 16:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Marco Felsch, linux-kernel, linux-mediatek,
Fengping Yu, linux-arm-kernel
In-Reply-To: <20200515114044.GR185537@smile.fi.intel.com>
On Fri, 2020-05-15 at 14:40 +0300, Andy Shevchenko wrote:
> On Fri, May 15, 2020 at 11:30:16AM +0200, Marco Felsch wrote:
> > On 20-05-15 14:20, Fengping Yu wrote:
>
> ...
>
> > > + depends on OF && HAVE_CLK
> >
> > Please drop those deps and instead use:
>
> +1
>
> > depends on ARCH_MEDIATEK && ARM64
>
> I would go even further
> depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
Please drop ARM64. This works for 32bits SoC as well.
Joe.C
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] irqchip/gic-v3-its: Balance LPI affinity across CPUs
From: John Garry @ 2020-05-15 16:15 UTC (permalink / raw)
To: Marc Zyngier
Cc: Jason Cooper, chenxiang (M), Will Deacon, luojiaxing,
linux-kernel, Ming Lei, Wangzhou (B), Thomas Gleixner,
Robin Murphy, linux-arm-kernel
In-Reply-To: <c37d8b15f09c6c933e39b81f39fcb827@kernel.org>
On 15/05/2020 16:37, Marc Zyngier wrote:
Hi Marc,
>>>
>>
>> It's not just userspace. Some drivers call irq_set_affinity{_hint}}()
>> also, with a non-overlapping affinity mask.
>>
>> We could just error these requests, but some drivers rely on this
>> behavior. Consider the uncore driver I mentioned above, which WARNs
>> when the affinity setting fails. So it tries to set the affinity with
>> the cpumask of the cluster associated with the device, but with D06's
>> ITS config, below, there may be no overlap.
>
> Does this PMU use the ITS? That's a pretty odd setup.
>
Yes, I think so. Our old friend, mbigen...
> So this is a case where the device has an implicit affinity that
> isn't that of the ITS. Huhu...
>
>>>
>>> What you are advocating for is a strict adherence to the provided
>>> mask, and it doesn't seem to be what other architectures are providing.
>>> I consider the userspace-provided affinity as a hint more that anything
>>> else, as in this case the kernel does know better (routing the interrupt
>>> to a foreign node might be costly, or even impossible, see the TX1
>>> erratum).
>>
>> Right
>>
>>>
>>> From what I remember of the earlier discussion, you saw an issue on
>>> a system with two sockets and a single ITS, with the node mask limited
>>> to the first socket. Is that correct?
>>
>> A bit more complicated: 2 sockets, 2 NUMA nodes per socket, and ITS
>> config as follows:
>> D06ES 1x ITS with proximity node #0
>>
>> root@(none)$ dmesg | grep ITS
>> [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
>>
>>
>> D06CS
>> 2x ITS with proximity node #0, #2
>>
>> estuary:/$ dmesg | grep ITS
>> [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
>> [ 0.000000] SRAT: PXM 2 -> ITS 1 -> Node 2
>>
>> It complicates things.
>>
>> We could add extra intelligence to record if an node has an ITS
>> associated. In the case of that not being true, we would fallback on
>> the requested affin only (for case of no overlap). It gets a bit more
>> messy then.
>
> It looks like part of the problem is that we can't reliably describe
> an ITS affine to multiple NUMA nodes... If we could describe that, then
> the above situation wouldn't occur (we'd say that ITS-0 covers both
> nodes 0 and 1). But I can't find a way to express this with SRAT and
> _PXM. Also, SRAT describes the affinity of the ITS with memory, and not
> with the CPUs... It is all a bit fsck'd. :-(
Yeah.
We could try to deal with those excluded CPUs, not within an ITS node
cpumask, by trying to find the "closest" ITS, and expanding the cpumask
of that ITS to cover those. Not sure if it's worth it.
But this sort of problem has always cropped up, with no clear way to
describe our topology exactly.
>
> I guess I'll apply your change for now with a comment explaining the
> situation.
>
Cheers,
John
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] coresight: etm4x: Add support to disable trace unit power up
From: Sai Prakash Ranjan @ 2020-05-15 15:58 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, Tingwei Zhang, Leo Yan,
linux-arm-kernel, Mike Leach
In-Reply-To: <20200515155144.GA7085@xps15>
Hi Mathieu,
On 2020-05-15 21:21, Mathieu Poirier wrote:
> On Fri, May 15, 2020 at 08:37:13PM +0530, Sai Prakash Ranjan wrote:
>> Hi Mathieu,
>>
>> On 2020-05-15 20:22, Mathieu Poirier wrote:
>> > On Thu, 14 May 2020 at 12:39, Sai Prakash Ranjan
>> > <saiprakash.ranjan@codeaurora.org> wrote:
>> > >
>> > > Hi Mathieu,
>> > >
>> > > On 2020-05-14 23:30, Mathieu Poirier wrote:
>> > > > Good morning Sai,
>> > > >
>> > > > On Thu, May 14, 2020 at 04:29:15PM +0530, Sai Prakash Ranjan wrote:
>> > > >> From: Tingwei Zhang <tingwei@codeaurora.org>
>> > > >>
>> > > >> On some Qualcomm Technologies Inc. SoCs like SC7180, there
>> > > >> exists a hardware errata where the APSS (Application Processor
>> > > >> SubSystem)/CPU watchdog counter is stopped when ETM register
>> > > >> TRCPDCR.PU=1.
>> > > >
>> > > > Fun stuff...
>> > > >
>> > >
>> > > Yes :)
>> > >
>> > > >> Since the ETMs share the same power domain as
>> > > >> that of respective CPU cores, they are powered on when the
>> > > >> CPU core is powered on. So we can disable powering up of the
>> > > >> trace unit after checking for this errata via new property
>> > > >> called "qcom,tupwr-disable".
>> > > >>
>> > > >> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>> > > >> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> > > >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> > > >
>> > > > Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> > > > Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>> > > >
>> > >
>> > > Tingwei is the author, so if I understand correctly, his signed-off-by
>> > > should appear first, am I wrong?
>> >
>> > It's a gray area and depends on who's code is more prevalent in the
>> > patch. If Tingwei wrote the most of the code then his name is in the
>> > "from:" section, yours as co-developer and he signs off on it (as I
>> > suggested). If you did most of the work then it is the opposite.
>> > Adding a Co-developed and a signed-off with the same name doesn't make
>> > sense.
>> >
>>
>> I did check the documentation for submitting patches:
>> Documentation/process/submitting-patches.rst. And it clearly states
>> that "Co-developed-by must be followed by Signed-off by the co-author
>> and the last Signed-off-by: must always be that of the developer
>> submitting the patch".
>>
>> Quoting below from the doc:
>>
>> Co-developed-by: <snip> ...Since
>> Co-developed-by: denotes authorship, every Co-developed-by: must be
>> immediately
>> followed by a Signed-off-by: of the associated co-author. Standard
>> sign-off
>> procedure applies, i.e. the ordering of Signed-off-by: tags should
>> reflect
>> the
>> chronological history of the patch insofar as possible, regardless of
>> whether
>> the author is attributed via From: or Co-developed-by:. Notably, the
>> last
>> Signed-off-by: must always be that of the developer submitting the
>> patch.
>
> Ah yes, glad to see that got clarified. You can ignore my
> recommendation on
> that snippet.
>
>>
>> > >
>> > > >> ---
>> > > >> .../devicetree/bindings/arm/coresight.txt | 6 ++++
>> > > >> drivers/hwtracing/coresight/coresight-etm4x.c | 29
>> > > >> ++++++++++++-------
>> > > >
>> > > > Please split in two patches.
>> > > >
>> > >
>> > > Sure, I will split the dt-binding into separate patch, checkpatch did
>> > > warn.
>> >
>> > And you still sent me the patch... I usually run checkpatch before
>> > all the submissions I review and flatly ignore patches that return
>> > errors. You got lucky...
>> >
>>
>> I did not mean to ignore it or else I wouldn't have run checkpatch
>> itself.
>> I checked other cases like "arm,scatter-gather" where the binding and
>> the
>> driver change was in a single patch, hence I thought it's not a very
>> strict
>> rule.
>
> The patch has another warning for a line over 80 characters, that
> should have
> been fixed before sending. Putting DT changes in a separate patch is
> always
> better for the DT people. They review tons of patches and making their
> life
> easier is always a good thing.
>
Ok, I will fix this and resend. I did not want to change it in case if
it affects
readability since most maintainers prefer to ignore this 80 characters
warning if
it affects readability. I will keep this in mind for future patches as
well.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 5/9] dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
From: André Przywara @ 2020-05-15 15:54 UTC (permalink / raw)
To: Amit Singh Tomar, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-6-git-send-email-amittomer25@gmail.com>
On 14/05/2020 17:10, Amit Singh Tomar wrote:
Hi,
> Converts the device tree bindings for the Actions Semi Owl SoCs DMA
> Controller over to YAML schemas.
>
> It also adds new compatible string "actions,s700-dma" to match
> the driver.
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> New patch, was not there in RFC.
> ---
> Documentation/devicetree/bindings/dma/owl-dma.txt | 47 ------------
> Documentation/devicetree/bindings/dma/owl-dma.yaml | 84 ++++++++++++++++++++++
> 2 files changed, 84 insertions(+), 47 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
> create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt
> deleted file mode 100644
> index 03e9bb12b75f..000000000000
> --- a/Documentation/devicetree/bindings/dma/owl-dma.txt
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -* Actions Semi Owl SoCs DMA controller
> -
> -This binding follows the generic DMA bindings defined in dma.txt.
> -
> -Required properties:
> -- compatible: Should be "actions,s900-dma".
> -- reg: Should contain DMA registers location and length.
> -- interrupts: Should contain 4 interrupts shared by all channel.
> -- #dma-cells: Must be <1>. Used to represent the number of integer
> - cells in the dmas property of client device.
> -- dma-channels: Physical channels supported.
> -- dma-requests: Number of DMA request signals supported by the controller.
> - Refer to Documentation/devicetree/bindings/dma/dma.txt
> -- clocks: Phandle and Specifier of the clock feeding the DMA controller.
> -
> -Example:
> -
> -Controller:
> - dma: dma-controller@e0260000 {
> - compatible = "actions,s900-dma";
> - reg = <0x0 0xe0260000 0x0 0x1000>;
> - interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> - #dma-cells = <1>;
> - dma-channels = <12>;
> - dma-requests = <46>;
> - clocks = <&clock CLK_DMAC>;
> - };
> -
> -Client:
> -
> -DMA clients connected to the Actions Semi Owl SoCs DMA controller must
> -use the format described in the dma.txt file, using a two-cell specifier
> -for each channel.
> -
> -The two cells in order are:
> -1. A phandle pointing to the DMA controller.
> -2. The channel id.
> -
> -uart5: serial@e012a000 {
> - ...
> - dma-names = "tx", "rx";
> - dmas = <&dma 26>, <&dma 27>;
> - ...
> -};
> diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
> new file mode 100644
> index 000000000000..12e68c0ece67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Actions Semi Owl SoCs DMA controller
> +
> +description: |
> + The OWL DMA is a general-purpose direct memory access controller capable of
> + supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
> + respectively.
From here on the description is pretty much how DMA controller
references work in general, so I don't see the point of including this
in the description here.
> + DMA clients connected to the Actions Semi Owl SoCs DMA controller must
> + use the format described in the owl-dma.yaml file, using a two-cell specifier
> + for each channel.
> +
> + The two cells in order are:
> + 1. A phandle pointing to the DMA controller.
> + 2. The channel id.
> +
> + uart5: serial@e012a000 {
> + ...
> + dma-names = "tx", "rx";
> + dmas = <&dma 26>, <&dma 27>;
> + ...
> + };
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +allOf:
> + - $ref: "dma-controller.yaml#"
> +
> +properties:
> + compatible:
> + enum:
> + - actions,s900-dma
> + - actions,s700-dma
> +
> + reg:
> + maxItems: 1
Could you replace those "maxItems: 1" here and below with:
- description: ...., copying in the explanation from the .txt binding?
That should serve the same purpose as "maxItems: 1", but is more
descriptive.
> +
> + interrupts:
> + maxItems: 4
Please mention that the controller supports 4 interrupts, which are
freely assignable to the interrupt channels.
(The kernel chose to use only one, but that's nothing the binding is
concerned about).
> +
> + "#dma-cells":
> + const: 1
> +
> + dma-channels:
> + maxItems: 1
> +
> + dma-requests:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - "#dma-cells"
> + - dma-channels
> + - dma-requests
> + - clocks
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/actions,s700-cmu.h>
I would drop this line and replace CLK_DMAC with some number below, to
keep this *example* as independent as possible.
Cheers,
Andre
> + dma: dma-controller@e0260000 {
> + compatible = "actions,s900-dma";
> + reg = <0x0 0xe0260000 0x0 0x1000>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> + #dma-cells = <1>;
> + dma-channels = <12>;
> + dma-requests = <46>;
> + clocks = <&clock CLK_DMAC>;
> + };
> +
> +...
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/14] pinctrl: ocelot: Add Sparx5 SoC support
From: Lars Povlsen @ 2020-05-15 15:52 UTC (permalink / raw)
To: kbuild test robot
Cc: devicetree, kbuild-all, Arnd Bergmann, linux-gpio, Stephen Boyd,
Linus Walleij, linux-clk, Microchip Linux Driver Support,
Michael Turquette, SoC Team, linux-arm-kernel, Olof Johansson,
Steen Hegelund, Lars Povlsen
In-Reply-To: <202005150200.wnjISCrm%lkp@intel.com>
kbuild test robot writes:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi Lars,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on robh/for-next]
> [also build test WARNING on pinctrl/devel clk/clk-next linus/master v5.7-rc5 next-20200512]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url: https://github.com/0day-ci/linux/commits/Lars-Povlsen/Adding-support-for-Microchip-Sparx5-SoC/20200514-163536
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: powerpc-allyesconfig (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 9.3.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>
>>> drivers/pinctrl/pinctrl-ocelot.c:28: warning: "clrsetbits" redefined
> 28 | #define clrsetbits(addr, clear, set) |
> In file included from include/linux/io.h:13,
> from include/linux/irq.h:20,
> from include/linux/gpio/driver.h:7,
> from drivers/pinctrl/pinctrl-ocelot.c:10:
> arch/powerpc/include/asm/io.h:849: note: this is the location of the previous definition
> 849 | #define clrsetbits(type, addr, clear, set) |
>
> vim +/clrsetbits +28 drivers/pinctrl/pinctrl-ocelot.c
>
> 27
> > 28 #define clrsetbits(addr, clear, set) \
> 29 writel((readl(addr) & ~(clear)) | (set), (addr))
> 30
>
I'll change the code to avoid the name clash.
Thanks,
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] coresight: etm4x: Add support to disable trace unit power up
From: Mathieu Poirier @ 2020-05-15 15:51 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, Tingwei Zhang, Leo Yan,
linux-arm-kernel, Mike Leach
In-Reply-To: <a0f8f01f28506e10001885e387d3cb4f@codeaurora.org>
On Fri, May 15, 2020 at 08:37:13PM +0530, Sai Prakash Ranjan wrote:
> Hi Mathieu,
>
> On 2020-05-15 20:22, Mathieu Poirier wrote:
> > On Thu, 14 May 2020 at 12:39, Sai Prakash Ranjan
> > <saiprakash.ranjan@codeaurora.org> wrote:
> > >
> > > Hi Mathieu,
> > >
> > > On 2020-05-14 23:30, Mathieu Poirier wrote:
> > > > Good morning Sai,
> > > >
> > > > On Thu, May 14, 2020 at 04:29:15PM +0530, Sai Prakash Ranjan wrote:
> > > >> From: Tingwei Zhang <tingwei@codeaurora.org>
> > > >>
> > > >> On some Qualcomm Technologies Inc. SoCs like SC7180, there
> > > >> exists a hardware errata where the APSS (Application Processor
> > > >> SubSystem)/CPU watchdog counter is stopped when ETM register
> > > >> TRCPDCR.PU=1.
> > > >
> > > > Fun stuff...
> > > >
> > >
> > > Yes :)
> > >
> > > >> Since the ETMs share the same power domain as
> > > >> that of respective CPU cores, they are powered on when the
> > > >> CPU core is powered on. So we can disable powering up of the
> > > >> trace unit after checking for this errata via new property
> > > >> called "qcom,tupwr-disable".
> > > >>
> > > >> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
> > > >> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> > > >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> > > >
> > > > Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> > > > Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
> > > >
> > >
> > > Tingwei is the author, so if I understand correctly, his signed-off-by
> > > should appear first, am I wrong?
> >
> > It's a gray area and depends on who's code is more prevalent in the
> > patch. If Tingwei wrote the most of the code then his name is in the
> > "from:" section, yours as co-developer and he signs off on it (as I
> > suggested). If you did most of the work then it is the opposite.
> > Adding a Co-developed and a signed-off with the same name doesn't make
> > sense.
> >
>
> I did check the documentation for submitting patches:
> Documentation/process/submitting-patches.rst. And it clearly states
> that "Co-developed-by must be followed by Signed-off by the co-author
> and the last Signed-off-by: must always be that of the developer
> submitting the patch".
>
> Quoting below from the doc:
>
> Co-developed-by: <snip> ...Since
> Co-developed-by: denotes authorship, every Co-developed-by: must be
> immediately
> followed by a Signed-off-by: of the associated co-author. Standard sign-off
> procedure applies, i.e. the ordering of Signed-off-by: tags should reflect
> the
> chronological history of the patch insofar as possible, regardless of
> whether
> the author is attributed via From: or Co-developed-by:. Notably, the last
> Signed-off-by: must always be that of the developer submitting the patch.
Ah yes, glad to see that got clarified. You can ignore my recommendation on
that snippet.
>
> > >
> > > >> ---
> > > >> .../devicetree/bindings/arm/coresight.txt | 6 ++++
> > > >> drivers/hwtracing/coresight/coresight-etm4x.c | 29
> > > >> ++++++++++++-------
> > > >
> > > > Please split in two patches.
> > > >
> > >
> > > Sure, I will split the dt-binding into separate patch, checkpatch did
> > > warn.
> >
> > And you still sent me the patch... I usually run checkpatch before
> > all the submissions I review and flatly ignore patches that return
> > errors. You got lucky...
> >
>
> I did not mean to ignore it or else I wouldn't have run checkpatch itself.
> I checked other cases like "arm,scatter-gather" where the binding and the
> driver change was in a single patch, hence I thought it's not a very strict
> rule.
The patch has another warning for a line over 80 characters, that should have
been fixed before sending. Putting DT changes in a separate patch is always
better for the DT people. They review tons of patches and making their life
easier is always a good thing.
Regards,
Mathieu
>
> Thanks,
> Sai
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mmc: Add Sparx5 SDHCI controller bindings
From: Lars Povlsen @ 2020-05-15 15:50 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Ulf Hansson, Adrian Hunter, linux-mmc,
Alexandre Belloni, linux-kernel, SoC Team, Rob Herring,
Lars Povlsen, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200514130351.GA17797@bogus>
Rob Herring writes:
> On Wed, 13 May 2020 15:31:20 +0200, Lars Povlsen wrote:
>> The Sparx5 SDHCI controller is based on the Designware controller IP.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>> .../mmc/microchip,dw-sparx5-sdhci.yaml | 57 +++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
>>
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dts:20:18: fatal error: dt-bindings/clock/microchip,sparx5.h: No such file or directory
> #include <dt-bindings/clock/microchip,sparx5.h>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml' failed
> make[1]: *** [Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml] Error 1
> make[1]: *** Waiting for unfinished jobs....
> Makefile:1300: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
>
> See https://patchwork.ozlabs.org/patch/1289290
>
Rob,
The header file is added with the "parent" SoC series for Sparx5, which
was submitted separately to the SoC list.
Should I rewrite the example to avoid using the (normal) header file, or
can you add the header file?
I have verified the YAML pass dt_binding_check with the header file.
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure dt-schema is up to date:
>
> pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
>
> Please check and re-submit.
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/7] usb: gadget: udc: atmel: use of_find_matching_node_and_match
From: Felipe Balbi @ 2020-05-15 15:47 UTC (permalink / raw)
To: cristian.birsan, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Claudiu Beznea
In-Reply-To: <20200515111631.31210-2-cristian.birsan@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 506 bytes --]
<cristian.birsan@microchip.com> writes:
> From: Claudiu Beznea <claudiu.beznea@microchip.com>
>
> Instead of trying to match every possible compatible use
> of_find_matching_node_and_match() and pass the compatible array.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
please rebase on my testing/next
checking file drivers/usb/gadget/udc/atmel_usba_udc.c
Hunk #1 succeeded at 2098 (offset 46 lines).
Hunk #2 FAILED at 2074.
1 out of 2 hunks FAILED
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement
From: Christoph Hellwig @ 2020-05-15 15:43 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: ashok.raj, linux-pci, joro, alex.williamson, iommu, bhelgaas,
baolu.lu, will, dwmw2, linux-arm-kernel, robin.murphy
In-Reply-To: <20200515104359.1178606-1-jean-philippe@linaro.org>
Can you please lift the untrusted flag into struct device? It really
isn't a PCI specific concept, and we should not have code poking into
pci_dev all over the iommu code.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ARM: static kernel in vmalloc space
From: Arnd Bergmann @ 2020-05-15 15:41 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: afzal mohammed, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <20200514234013.GQ1551@shell.armlinux.org.uk>
On Fri, May 15, 2020 at 1:40 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Thu, May 14, 2020 at 11:12:01PM +0200, Arnd Bergmann wrote:
> > On Thu, May 14, 2020 at 6:25 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> > I expected the non-aliasing VIPT caches to work the same as PIPT, can
> > you clarify if there is something to be aware of for those? I see that some
> > ARMv8 chips and most ARMv6 chips (not OMAP2 and Realview) are
> > of that kind, and at we clearly don't want to break running on ARMv8 at
> > least.
>
> There are some aliasing VIPT implementations on ARMv6, but I don't
> remember how common.
I thought it was only realview-pb and omap2, but it seems there
are more, at least ast2500 is an important example.
I could not find information about integrator-cp and picoxcell.
For reference, this is a list of the arm11 chips we currently support,
with the aliasing dcache ones marked '*':
* ast2500: armv6k, arm1176, ??KB aliasing VIPT
bcm2835: armv6k, arm1176, 16KB non-aliasing VIPT
cns3xxx: armv6k, arm11mpcore, 32kb PIPT
imx3: armv6, arm1136r0, 16kb non-aliasing VIPT
integrator CM1136JF-S core module: arm1136r?, 16kb non-aliasing VIPT
? integrator CTB36 core tile: arm1136r?, ???
ox820: armv6k, arm11mpcore, ??KB PIPT
* omap2: armv6, arm1136r0, 32kb aliasing VIPT
? picoxcell: armv6k, arm11??
* realview-pb1176: armv6k, arm1176, 32kb aliasing VIPT
realview-eb with 1176 core tile: armv6k, 16kb non-aliasing VIPT
realview-eb with 11mpcore core tile: armv6k, 32kb PIPT
s3c64xx: armv6k, arm1176, 16kb non-aliasing VIPT
wm8750: armv6k, arm1176: 16kb non-aliasing VIPT
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: Configure SCL gpio of i2c2 node as open drain
From: Alexandre Belloni @ 2020-05-15 15:39 UTC (permalink / raw)
To: Codrin Ciubotariu
Cc: sboyd, mturquette, linux-kernel, ludovic.desroches, eugen.hristev,
linux-clk, linux-arm-kernel
In-Reply-To: <20200515153239.323944-1-codrin.ciubotariu@microchip.com>
On 15/05/2020 18:32:39+0300, Codrin Ciubotariu wrote:
> The SCL gpio pin of i2c2 node used for recovery needs to be configured as
> open drain.
>
> Fixes: 455fec938bbb ("ARM: dts: at91: sama5d2: add i2c gpio pinctrl")
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Squashed in the previous one, thanks.
> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> index 5846720fc9dc..851b8587068b 100644
> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> @@ -344,7 +344,7 @@ i2c2: i2c@600 {
> pinctrl-0 = <&pinctrl_flx0_default>;
> pinctrl-1 = <&pinctrl_i2c2_gpio>;
> sda-gpios = <&pioA PIN_PB28 GPIO_ACTIVE_HIGH>;
> - scl-gpios = <&pioA PIN_PB29 GPIO_ACTIVE_HIGH>;
> + scl-gpios = <&pioA PIN_PB29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> i2c-sda-hold-time-ns = <350>;
> i2c-analog-filter;
> i2c-digital-filter;
> --
> 2.25.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] irqchip/gic-v3-its: Balance LPI affinity across CPUs
From: Marc Zyngier @ 2020-05-15 15:37 UTC (permalink / raw)
To: John Garry
Cc: Jason Cooper, chenxiang (M), Will Deacon, luojiaxing,
linux-kernel, Ming Lei, Wangzhou (B), Thomas Gleixner,
Robin Murphy, linux-arm-kernel
In-Reply-To: <a22aaa72-4f5f-40d4-33e0-0aff8b65fdc2@huawei.com>
On 2020-05-15 12:50, John Garry wrote:
> Hi Marc,
>
>> Absolutely. Life has got in the way, so let me page it back in...
>
> Great
>
>>>
>>> [PATCH 2/2] irqchip/gic-v3-its: Handle no overlap of non-managed irq
>>> affinity mask
>>>
>>> In selecting the target CPU for a non-managed interrupt, we may
>>> select
>>> a
>>> target CPU outside the requested affinity mask.
>>>
>>> This is because there may be no overlap of the ITS node mask and the
>>> requested CPU affinity mask. The requested affinity mask may be
>>> coming
>>> from userspace or some drivers which try to set irq affinity, see
>>> [0].
>>>
>>> In this case, just ignore the ITS node cpumask. This is a deviation
>>> from
>>> what Thomas described. Having said that, I am not sure if the
>>> interrupt is ever bound to a node for us.
>>>
>>> [0]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/perf/hisilicon/hisi_uncore_pmu.c#n417
>>>
>>> ---
>>> drivers/irqchip/irq-gic-v3-its.c | 4 ----
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c
>>> b/drivers/irqchip/irq-gic-v3-its.c
>>> index 2b18feb..12d5d4b4 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>> @@ -1584,10 +1584,6 @@ static int its_select_cpu(struct irq_data *d,
>>> cpumask_and(tmpmask, cpumask_of_node(node), aff_mask);
>>> cpumask_and(tmpmask, tmpmask, cpu_online_mask);
>>>
>>> - /* If that doesn't work, try the nodemask itself */
>>> - if (cpumask_empty(tmpmask))
>>> - cpumask_and(tmpmask, cpumask_of_node(node), cpu_online_mask);
>>> -
>>> cpu = cpumask_pick_least_loaded(d, tmpmask);
>>> if (cpu < nr_cpu_ids)
>>> goto out;
>>
>> I'm really not sure. Shouldn't we then drop the wider search on
>> cpu_inline_mask, because userspace could have given us something
>> that we cannot deal with?
>
> It's not just userspace. Some drivers call irq_set_affinity{_hint}}()
> also, with a non-overlapping affinity mask.
>
> We could just error these requests, but some drivers rely on this
> behavior. Consider the uncore driver I mentioned above, which WARNs
> when the affinity setting fails. So it tries to set the affinity with
> the cpumask of the cluster associated with the device, but with D06's
> ITS config, below, there may be no overlap.
Does this PMU use the ITS? That's a pretty odd setup.
So this is a case where the device has an implicit affinity that
isn't that of the ITS. Huhu...
>>
>> What you are advocating for is a strict adherence to the provided
>> mask, and it doesn't seem to be what other architectures are
>> providing.
>> I consider the userspace-provided affinity as a hint more that
>> anything
>> else, as in this case the kernel does know better (routing the
>> interrupt
>> to a foreign node might be costly, or even impossible, see the TX1
>> erratum).
>
> Right
>
>>
>> From what I remember of the earlier discussion, you saw an issue on
>> a system with two sockets and a single ITS, with the node mask limited
>> to the first socket. Is that correct?
>
> A bit more complicated: 2 sockets, 2 NUMA nodes per socket, and ITS
> config as follows:
> D06ES 1x ITS with proximity node #0
>
> root@(none)$ dmesg | grep ITS
> [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
>
>
> D06CS
> 2x ITS with proximity node #0, #2
>
> estuary:/$ dmesg | grep ITS
> [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
> [ 0.000000] SRAT: PXM 2 -> ITS 1 -> Node 2
>
> It complicates things.
>
> We could add extra intelligence to record if an node has an ITS
> associated. In the case of that not being true, we would fallback on
> the requested affin only (for case of no overlap). It gets a bit more
> messy then.
It looks like part of the problem is that we can't reliably describe
an ITS affine to multiple NUMA nodes... If we could describe that, then
the above situation wouldn't occur (we'd say that ITS-0 covers both
nodes 0 and 1). But I can't find a way to express this with SRAT and
_PXM. Also, SRAT describes the affinity of the ITS with memory, and not
with the CPUs... It is all a bit fsck'd. :-(
I guess I'll apply your change for now with a comment explaining the
situation.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: at91: Configure SCL gpio of i2c2 node as open drain
From: Codrin Ciubotariu @ 2020-05-15 15:32 UTC (permalink / raw)
To: linux-clk, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, sboyd, mturquette, ludovic.desroches,
eugen.hristev, Codrin Ciubotariu
The SCL gpio pin of i2c2 node used for recovery needs to be configured as
open drain.
Fixes: 455fec938bbb ("ARM: dts: at91: sama5d2: add i2c gpio pinctrl")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 5846720fc9dc..851b8587068b 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -344,7 +344,7 @@ i2c2: i2c@600 {
pinctrl-0 = <&pinctrl_flx0_default>;
pinctrl-1 = <&pinctrl_i2c2_gpio>;
sda-gpios = <&pioA PIN_PB28 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PB29 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PB29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
i2c-sda-hold-time-ns = <350>;
i2c-analog-filter;
i2c-digital-filter;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] [RESEND] arm64: dts: mt8173: fix cooling device range
From: Matthias Brugger @ 2020-05-15 15:33 UTC (permalink / raw)
To: Michael Kao, Zhang Rui, Eduardo Valentin, Daniel Lezcano,
Rob Herring, Mark Rutland, hsinyi, linux-pm, srv_heupstream
Cc: devicetree, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20200424082340.4127-1-michael.kao@mediatek.com>
On 24/04/2020 10:23, Michael Kao wrote:
> When thermal reaches target temperature,it would be pinned to state 0
> (max frequency and power).
> Fix the throttling range to no limit.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
applied to v5.7-next/dts64
Thanks!
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index ccb8e88a60c5..cae2cec46cdc 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -19,6 +19,7 @@
> #include <dt-bindings/power/mt8173-power.h>
> #include <dt-bindings/reset/mt8173-resets.h>
> #include <dt-bindings/gce/mt8173-gce.h>
> +#include <dt-bindings/thermal/thermal.h>
> #include "mt8173-pinfunc.h"
>
> / {
> @@ -294,14 +295,18 @@
> cooling-maps {
> map@0 {
> trip = <&target>;
> - cooling-device = <&cpu0 0 0>,
> - <&cpu1 0 0>;
> + cooling-device = <&cpu0 THERMAL_NO_LIMIT
> + THERMAL_NO_LIMIT>,
> + <&cpu1 THERMAL_NO_LIMIT
> + THERMAL_NO_LIMIT>;
> contribution = <3072>;
> };
> map@1 {
> trip = <&target>;
> - cooling-device = <&cpu2 0 0>,
> - <&cpu3 0 0>;
> + cooling-device = <&cpu2 THERMAL_NO_LIMIT
> + THERMAL_NO_LIMIT>,
> + <&cpu3 THERMAL_NO_LIMIT
> + THERMAL_NO_LIMIT>;
> contribution = <1024>;
> };
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/7] usb: gadget: udc: atmel: add usb device support for SAM9x60 SoC
From: Cristian.Birsan @ 2020-05-15 15:32 UTC (permalink / raw)
To: alexandre.belloni
Cc: mark.rutland, balbi, devicetree, gregkh, linux-usb, linux-kernel,
Ludovic.Desroches, robh+dt, linux-arm-kernel
In-Reply-To: <20200515150228.GW34497@piout.net>
On 5/15/20 6:02 PM, Alexandre Belloni wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi,
>
> On 15/05/2020 14:16:24+0300, cristian.birsan@microchip.com wrote:
>> From: Cristian Birsan <cristian.birsan@microchip.com>
>>
>> This patch set adds usb device support for SAM9x60 SoC.
>> The DPRAM memory for the USB High Speed Device Port (UDPHS) hardware
>> block was increased and the allocation method is changed. This patch
>> series simplifies the endpoint allocation scheme to acomodate this SoC
>> and the old ones.
>>
>> Changes in v2:
>> - drop the patch that adds reference to pmc for sam9x60
>> - use dt-bindings: usb prefix
>> - enable usb device in device tree
>>
>> Claudiu Beznea (1):
>> usb: gadget: udc: atmel: use of_find_matching_node_and_match
>>
>> Cristian Birsan (6):
>> dt-bindings: usb: atmel: Update DT bindings documentation for sam9x60
>> usb: gadget: udc: atmel: simplify endpoint allocation
>> usb: gadget: udc: atmel: use 1 bank endpoints for control transfers
>> usb: gadget: udc: atmel: rename errata into caps
>> usb: gadget: udc: atmel: update endpoint allocation for sam9x60
>> ARM: dts: at91: sam9x60ek: enable usb device
>
> This should probably be rebased on top of
> https://lore.kernel.org/linux-arm-kernel/20200507155651.1094142-1-gregory.clement@bootlin.com/
> so we avoid having to define the endpoints in the device tree in the
> first place.
I know the patch series and I Ack-ed it some time ago. On the other hand, it was not applied yet,
so to be consistent I created this series based on what is already available on usb-next.
Depending on which one gets applied first, the other will need to rebase. I have no problem with that.
The end goal is to have both of them.
Cristian
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/14] arm64: dts: sparx5: Add basic cpu support
From: Robin Murphy @ 2020-05-15 15:30 UTC (permalink / raw)
To: Lars Povlsen, Marc Zyngier
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, Stephen Boyd,
Linus Walleij, linux-kernel, Microchip Linux Driver Support,
linux-gpio, SoC Team, Michael Turquette, Olof Johansson,
Steen Hegelund, linux-clk, linux-arm-kernel
In-Reply-To: <871rnlp740.fsf@soft-dev15.microsemi.net>
On 2020-05-15 16:09, Lars Povlsen wrote:
[...]
>>> + cpu0: cpu@0 {
>>> + compatible = "arm,cortex-a53", "arm,armv8";
Side note: only one compatible string for the real CPU please, running a
DT bindings check should complain about that.
>>> + device_type = "cpu";
>>> + reg = <0x0 0x0>;
>>> + enable-method = "spin-table";
>>
>> Really? This is 2020, not 2012 any more. Surely a new platform
>> boots using PSCI, and not *this*.
>>
>
> We don't currently support PSCI. The platform does not have TrustZone,
> hence we don't use ATF.
AIUI, part of the purpose of ATF is to provide a nice standardised
platform interface regardless of whether you care about Secure software
or not. It shouldn't take much to knock up a trivial ATF port that just
uses an internal spin-table for its PSCI backend - in fact I suspect
that's probably just a copy-paste from the RPi3 port ;)
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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