* Re: [PATCH] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-06 12:46 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Martin Blumenstingl, netdev,
linux-kernel@vger.kernel.org, linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+efvvb1UK-Nas0G5XefLWwN7ebnqoevi+W=jj4r3E2dg@mail.gmail.com>
On 06/08/2019 00:09, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 6:26 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Now that we have the DT validation in place, let's convert the device tree
>> bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> Rob,
>>
>> I keep getting :
>> .../devicetree/bindings/net/amlogic,meson-dwmac.example.dt.yaml: ethernet@c9410000: reg: [[3376480256, 65536], [3364046144, 8]] is too long
>
> Because snps,dwmac.yaml has:
>
> reg:
> maxItems: 1
>
> The schemas are applied separately and all have to be valid. You'll
> need to change snps,dwmac.yaml to:
>
> reg:
> minItems: 1
> maxItems: 2
>
>
> The schema error messages leave something to be desired. I wish the
> error messages said which schema is throwing the error.
Indeed, it fixed it
>
>> for the example DT
>>
>> and for the board DT :
>> ../amlogic/meson-gxl-s905x-libretech-cc.dt.yaml: ethernet@c9410000: reg: [[0, 3376480256, 0, 65536, 0, 3364046144, 0, 4]] is too short
>> ../amlogic/meson-gxl-s905x-nexbox-a95x.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too long
>>
>> and I don't know how to get rid of it.
>
> The first issue is the same as the above. The 2nd issue is the use of
> <> in dts files becomes stricter with the schema. Each entry in an
> array needs to be bracketed:
>
> reg = <0x0 0xc9410000 0x0 0x10000>,
> <0x0 0xc8834540 0x0 0x4>;
I did it but somehow it was overrided (with the same content) in another .dtsi
included file...
Sorry for the noise !
Neil
>
> Rob
>
_______________________________________________
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/2] ARM: zynq: support smp in thumb mode
From: Luis Araneda @ 2019-08-06 12:40 UTC (permalink / raw)
To: Michal Simek; +Cc: Russell King, linux-arm-kernel, linux-kernel
In-Reply-To: <17a45e21-8362-e888-d222-812c879a38a8@xilinx.com>
Hi,
On Tue, Aug 6, 2019 at 2:39 AM Michal Simek <michal.simek@xilinx.com> wrote:
>
> On 06. 08. 19 5:07, Luis Araneda wrote:
> > Add .arm directive to headsmp.S to ensure that the
> > CPU starts in 32-bit ARM mode and the correct code
> > size is copied on smp bring-up
> >
> > Additionally, start secondary CPUs on secondary_startup_arm
> > to automatically switch from ARM to thumb on a thumb kernel
[...]
>
> It is really a question if this should go to stable tree. It is pretty
> much new feature.
> Will be good to also add link to similar patch for example this one
> 5616f36713ea77f57ae908bf2fef641364403c9f.
Ok, I'm dropping stable from CC. From the previous comments, I thought
that the two patches were part of the same fix, but now I realized
this is a feature rather than a fix.
Michal, do you want a new version with the link to the similar patch
or would you take it in its current form?
Thanks,
Luis Araneda.
_______________________________________________
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] mt7601u: null check the allocation
From: Kalle Valo @ 2019-08-06 12:35 UTC (permalink / raw)
To: Navid Emamdoost
Cc: secalert, Jakub Kicinski, linux-wireless, kjlu, linux-kernel,
emamd001, linux-mediatek, smccaman, Matthias Brugger, netdev,
David S. Miller, linux-arm-kernel, Navid Emamdoost
In-Reply-To: <20190724141736.29994-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> devm_kzalloc may fail and return NULL. So the null check is needed.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>
Patch applied to wireless-drivers-next.git, thanks.
b95c732234fa mt7601u: null check the allocation
--
https://patchwork.kernel.org/patch/11057013/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
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: mm: print hexadecimal EC value in mem_abort_decode()
From: Mark Rutland @ 2019-08-06 12:34 UTC (permalink / raw)
To: Miles Chen
Cc: wsd_upstream, Anshuman Khandual, Catalin Marinas, Will Deacon,
linux-kernel, linux-mediatek, James Morse, linux-arm-kernel
In-Reply-To: <20190806112948.4357-1-miles.chen@mediatek.com>
On Tue, Aug 06, 2019 at 07:29:48PM +0800, Miles Chen wrote:
> This change prints the hexadecimal EC value in mem_abort_decode(),
> which makes it easier to lookup the corresponding EC in
> the ARM Architecture Reference Manual.
>
> The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> faults") prints useful information when memory abort occurs. It would
> be easier to lookup "0x25" instead of "DABT" in the document. Then we
> can check the corresponding ISS.
>
> For example:
> Current info Document
> EC Exception class
> "CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
> "ASIMD" 0x7 "Access to SIMD or floating-point..."
> "DABT (current EL)" 0x25 "Data Abort taken without..."
> ...
>
> Before:
> Unable to handle kernel paging request at virtual address 000000000000c000
> Mem abort info:
> ESR = 0x96000046
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000046
> CM = 0, WnR = 1
>
> After:
> Unable to handle kernel paging request at virtual address 000000000000c000
> Mem abort info:
> ESR = 0x96000046
> EC = 0x25, Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000046
> CM = 0, WnR = 1
>
> Cc: Mark Rutland <Mark.rutland@arm.com>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Signed-off-by: Miles Chen <miles.chen@mediatek.com>
> ---
> arch/arm64/mm/fault.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index cfd65b63f36f..afb6041e25e6 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -86,8 +86,8 @@ static void mem_abort_decode(unsigned int esr)
> pr_alert("Mem abort info:\n");
>
> pr_alert(" ESR = 0x%08x\n", esr);
> - pr_alert(" Exception class = %s, IL = %u bits\n",
> - esr_get_class_string(esr),
> + pr_alert(" EC = 0x%lx, Exception class = %s, IL = %u bits\n",
> + ESR_ELx_EC(esr), esr_get_class_string(esr),
Could we make this:
pr_alert(" EC = 0x%02lx: %s, IL = %u bits\n",
ESR_ELx_EC(esr), esr_get_class_string(esr));
We don't need to spell out "Exception Class" if we say "EC", and we
should print the EC hex value with a consistent width as we do for the
ISS.
With that:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 5.2: arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
From: Andreas Schwab @ 2019-08-06 12:33 UTC (permalink / raw)
To: Robin Murphy; +Cc: linux-arm-kernel
In-Reply-To: <5036fcb8-131e-9ffe-4bfe-dc8cbae71bc4@arm.com>
On Aug 06 2019, Robin Murphy <robin.murphy@arm.com> wrote:
> I take it you have firmware still using the old "mmu-masters" DT binding
> on that machine?
Yes.
> The way the legacy binding is handled turns out to interact badly with the
> disable_bypass option, so CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is
> presumably now tripping you up. The immediate workaround would be to turn
> that off and/or boot with "arm-smmu.disable_bypass=0" to ensure it's
> overridden.
I will try the command line parameter.
> If you can update the firmware to something newer using either
> the generic "iommus" binding or ACPI (I believe Seattle is supported in
> EDK2 these days) that would remove the problem entirely.
AMD won't be releasing any new firmware for their seattle platform.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
_______________________________________________
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 v4.4 V2 24/43] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: Mark Rutland @ 2019-08-06 12:18 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190801052011.2hrei36v4zntyfn5@vireshk-i7>
On Thu, Aug 01, 2019 at 10:50:11AM +0530, Viresh Kumar wrote:
> On 31-07-19, 17:45, Mark Rutland wrote:
> > On Fri, Jul 12, 2019 at 10:58:12AM +0530, Viresh Kumar wrote:
> > > From: Will Deacon <will.deacon@arm.com>
> > >
> > > commit 0f15adbb2861ce6f75ccfc5a92b19eae0ef327d0 upstream.
> > >
> > > Aliasing attacks against CPU branch predictors can allow an attacker to
> > > redirect speculative control flow on some CPUs and potentially divulge
> > > information from one context to another.
> > >
> > > This patch adds initial skeleton code behind a new Kconfig option to
> > > enable implementation-specific mitigations against these attacks for
> > > CPUs that are affected.
> > >
> > > Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > [ v4.4: Changes made according to 4.4 codebase ]
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > [...]
> >
> > > /* id_aa64pfr0 */
> > > +#define ID_AA64PFR0_CSV2_SHIFT 56
> >
> > Note: CSV3 is bits 63-60,
> >
> > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > > index 474b34243521..040a42d79990 100644
> > > --- a/arch/arm64/kernel/cpufeature.c
> > > +++ b/arch/arm64/kernel/cpufeature.c
> > > @@ -83,7 +83,8 @@ static struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> > > };
> > >
> > > static struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> > > - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 32, 0),
> > > + ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV2_SHIFT, 4, 0),
> > > + ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 28, 0),
> >
> > This line should be:
> >
> > ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 24, 0),
> >
> > ... as it was in the v4.9 backbort, making it cover bits 55:32. As in
> > this patch, it covers 59:32, overlapping with CSV2.
>
> Fixed thanks.
>
> > We also need to cater for bits 63:60. In the v4.9 backport, the meltdown
> > bits were applied first, so nothing special was necessary.
> >
> > What's the plan w.r.t. meltdown mitigations and v4.4?
>
> I haven't started looking at meltdown patches yet and so that will be
> done at a later point of time, if at all done by me. I have been asked
> to backport both Spectre and Meltdown though to 4.4.
Upstream and in v4.9, the meltdown patches came before the spectre
patches, and doing this in the opposite order causes context problems
like the above.
Given that, I think it would be less surprising to do the meltdown
backport first, though I apprecaite that's more work to get these
patches in. :/
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: 5.2: arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
From: Robin Murphy @ 2019-08-06 12:17 UTC (permalink / raw)
To: Andreas Schwab, linux-arm-kernel
In-Reply-To: <mvmlfw6354j.fsf@suse.de>
On 06/08/2019 12:28, Andreas Schwab wrote:
> When trying to boot 5.2 on a seattle platform, I'm getting these errors:
>
> [ 5056.934028] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
> [ 5056.953895] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
> [ 5056.961452] arm_smmu_global_fault: 2959 callbacks suppressed
> [ 5056.961456] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5056.977276] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
> [ 5056.984838] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.007296] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.017475] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.039919] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.050098] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.072592] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.082766] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.105167] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5057.115342] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
> [ 5061.847674] arm_smmu_global_fault: 2964 callbacks suppressed
>
> The errors start as soon as the network interface is being brought up,
> and causes networking to fail to work.
Urgh, it finally happened... :(
I take it you have firmware still using the old "mmu-masters" DT binding
on that machine? I was really hoping that that might have died out in
the wild by now.
The way the legacy binding is handled turns out to interact badly with
the disable_bypass option, so CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
is presumably now tripping you up. The immediate workaround would be to
turn that off and/or boot with "arm-smmu.disable_bypass=0" to ensure
it's overridden. If you can update the firmware to something newer using
either the generic "iommus" binding or ACPI (I believe Seattle is
supported in EDK2 these days) that would remove the problem entirely.
In principle it should be possible to make the kernel driver support
disable_bypass with old firmware, but it's non-trivial and thus I chose
not to pursue it unless a worthwhile justification came along.
Alternatively I guess we could write off the old binding as "not
security-focused" and just force the option back off if we detect both
together - that's less than ideal, but would at least be simple to do.
Robin.
_______________________________________________
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/cache: fix -Woverride-init compiler warnings
From: Mark Rutland @ 2019-08-06 12:07 UTC (permalink / raw)
To: Qian Cai; +Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel
In-Reply-To: <06613F4A-3DA7-4FF9-8616-52CB4BB58C48@lca.pw>
On Mon, Aug 05, 2019 at 11:50:03PM -0400, Qian Cai wrote:
>
>
> > On Aug 5, 2019, at 10:01 AM, Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Aug 05, 2019 at 07:47:37AM -0400, Qian Cai wrote:
> >>
> >>
> >>> On Aug 5, 2019, at 5:52 AM, Will Deacon <will@kernel.org> wrote:
> >>>
> >>> On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
> >>>> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> >>>> VIVT I-caches") introduced some compiation warnings from GCC,
> >>>>
> >>>> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> >>>> overwritten [-Woverride-init]
> >>>> [ICACHE_POLICY_VIPT] = "VIPT",
> >>>> ^~~~~~
> >>>> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> >>>> 'icache_policy_str[2]')
> >>>> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> >>>> overwritten [-Woverride-init]
> >>>> [ICACHE_POLICY_PIPT] = "PIPT",
> >>>> ^~~~~~
> >>>> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> >>>> 'icache_policy_str[3]')
> >>>> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> >>>> overwritten [-Woverride-init]
> >>>> [ICACHE_POLICY_VPIPT] = "VPIPT",
> >>>> ^~~~~~~
> >>>> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> >>>> 'icache_policy_str[0]')
> >>>>
> >>>> because it initializes icache_policy_str[0 ... 3] twice.
> >>>>
> >>>> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> >>>> Signed-off-by: Qian Cai <cai@lca.pw>
> >>>> ---
> >>>> arch/arm64/kernel/cpuinfo.c | 4 ++--
> >>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> >>>> index 876055e37352..193b38da8d96 100644
> >>>> --- a/arch/arm64/kernel/cpuinfo.c
> >>>> +++ b/arch/arm64/kernel/cpuinfo.c
> >>>> @@ -34,10 +34,10 @@
> >>>> static struct cpuinfo_arm64 boot_cpu_data;
> >>>>
> >>>> static char *icache_policy_str[] = {
> >>>> - [0 ... ICACHE_POLICY_PIPT] = "RESERVED/UNKNOWN",
> >>>> + [ICACHE_POLICY_VPIPT] = "VPIPT",
> >>>> + [ICACHE_POLICY_VPIPT + 1] = "RESERVED/UNKNOWN",
> >>>> [ICACHE_POLICY_VIPT] = "VIPT",
> >>>> [ICACHE_POLICY_PIPT] = "PIPT",
> >>>> - [ICACHE_POLICY_VPIPT] = "VPIPT",
> >>>
> >>> I really don't like this patch. Using "[0 ... MAXIDX] = <default>" is a
> >>> useful idiom and I think the code is more error-prone the way you have
> >>> restructured it.
> >>>
> >>> Why are you passing -Woverride-init to the compiler anyway? There's only
> >>> one Makefile that references that option, and it's specific to a pinctrl
> >>> driver.
> >>
> >> Those extra warnings can be enabled by “make W=1”. “-Woverride-init “ seems to be useful
> >> to catch potential developer mistakes with unintented double-initializations. It is normal to
> >> start to fix the most of false-positives first before globally enabling the flag by default just like
> >> “-Wimplicit-fallthrough” mentioned in,
> >>
> >> https://lwn.net/Articles/794944/
> >
> > I think this case is completely different to the implicit fallthrough stuff.
> > The solution there was simply to add a comment without restructuring the
> > surrounding code. What your patch does here is actively make the code harder
> > to understand.
> >
> > Initialising a static array with a non-zero pattern is a useful idiom and I
> > don't think we should throw that away just to appease a silly compiler
> > warning that appears only with non-default build options. Have a look at
> > the way we use PERF_MAP_ALL_UNSUPPORTED in the Arm PMU code, for example.
>
> Well, both GCC and Clang would generate warnings for those. Clang even enable this by
> default,
>
> https://releases.llvm.org/8.0.0/tools/clang/docs/DiagnosticsReference.html#winitializer-overrides
>
> Assume compiler people are sane, I probably not call those are “silly”.
We're not disputing the sanity of compiler folk; Will did not say
anything about that.
The warning is unhelpful in the case of the [0 ... MAXIDX] = <default>
idiom, and the modification you suggest:
* Makes the code harder to read.
* Increases the necessary context. e.g. I must know the specific values
of the enum to know that ICACHE_POLICY_VPIPT + 1 is the unallocated
slot.
* Less robust. If the enum gets re-ordered, we must update the array.
If the enum is expanded, new elements must be added to the array to
initialize entries to the default value, which also makes the code
more verbose and painful to read. IIUC if we don't explicitly
initialize an element, we won't get a warning, which would be harmful.
If there's some way to mark the default initialization as overridable,
I think that would be fine, e.g.
struct foo *array[] = {
[0 ... MAXIDX] __default = <default>,
[SOMEIDX] = <someval>,
[OTHERIDX] = <otherval>,
}
We have a number of cases where the [0 ... MAXIDX] = <default> idiom are
used, and I don't think that any of them should be changed in the manner
suggested by this patch.
Thanks,
Mark.
_______________________________________________
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 v4 10/10] rtc: Add support for the MediaTek MT6358 RTC
From: Ran Bi @ 2019-08-06 11:41 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, srv_heupstream, devicetree,
Kate Stewart, Sean Wang, Liam Girdwood, Rob Herring, linux-kernel,
Richard Fontana, Mark Brown, linux-mediatek, Allison Randal,
linux-rtc, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Hsin-Hsiung Wang, linux-arm-kernel
In-Reply-To: <20190805072338.GB3600@piout.net>
Hi Belloni,
On Mon, 2019-08-05 at 09:23 +0200, Alexandre Belloni wrote:
> Hi,
>
> The subject should be:
>
> "rtc: mt6397: Add support for the MediaTek MT6358 RTC"
Will be changed at next patch.
> > +struct mtk_rtc_compatible {
>
> I would name that struct mtk_rtc_data
>
> > + u32 wrtgr_addr;
>
> and this member should be wrtgr_offset or simply wrtgr.
>
Will be changed at next patch.
> >
> > + of_id = of_match_device(mt6397_rtc_of_match, &pdev->dev);
> > + if (!of_id) {
> > + dev_err(&pdev->dev, "Failed to probe of_node\n");
> > + return -EINVAL;
>
> This will never happen because probe would not be called if there is no
> match. You could also use of_device_get_match_data to avoid having to
> move the of_device_id table.
>
Will use of_device_get_match_data() function instead of
of_match_device() function.
_______________________________________________
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/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-06 11:38 UTC (permalink / raw)
To: Christoph Hellwig, Rob Clark, dri-devel, Rob Clark,
Catalin Marinas, Will Deacon, Maarten Lankhorst, Maxime Ripard,
Sean Paul, David Airlie, Allison Randal, Greg Kroah-Hartman,
Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <20190806093816.GY7444@phenom.ffwll.local>
On Tue, Aug 06, 2019 at 11:38:16AM +0200, Daniel Vetter wrote:
> I just read through all the arch_sync_dma_for_device/cpu functions and
> none seem to use the struct *dev argument. Iirc you've said that's on the
> way out?
Not actively on the way out yet, but now that we support all
architectures it becomes pretty clear we don't need it. So yes, we
could eventually remove it. But..
> That dev parameter is another holdup for the places where we do not yet
> know what the new device will be (e.g. generic dma-buf exporters like
> vgem). And sprinkling a fake dev or passing NULL is a bit silly.
This is where it becomes interesting. Because while we don't need the
dev argument for the low-level arch API, we do need it at the driver
API level, given that in some systems both dma coherent and non-coherent
devices exist, and we need to decide based on that.
> Add a HAVE_ARCH_SYNC_DMA and the above refactor (assuming it's ok to roll
> out everywhere) and we should indeed be able to use this. We still need to
> have all the others for x86 and all that. Plus I guess we should roll out
> the split into invalidate and flush.
Well, we'll still need a defined API for buffer ownership vs device.
Just exporting arch_sync_dma_for_{device,cpu} is not the right
abstraction level. Note that these two functions are always present,
just stubbed out for architectures that do not support non-cache
coherent devices (plus the arm false negative that is easily fixable).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND][PATCH] usb: musb: sunxi: propagate devicetree node to glue pdev
From: Mans Rullgard @ 2019-08-06 11:34 UTC (permalink / raw)
To: Bin Liu, Maxime Ripard
Cc: Greg Kroah-Hartman, Chen-Yu Tsai, linux-usb, linux-kernel,
linux-arm-kernel
In order for devicetree nodes to be correctly associated with attached
devices, the controller node needs to be propagated to the glue device.
Signed-off-by: Mans Rullgard <mans@mansr.com>
---
drivers/usb/musb/sunxi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 832a41f9ee7d..a72665fbf111 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -781,6 +781,8 @@ static int sunxi_musb_probe(struct platform_device *pdev)
pinfo.name = "musb-hdrc";
pinfo.id = PLATFORM_DEVID_AUTO;
pinfo.parent = &pdev->dev;
+ pinfo.fwnode = of_fwnode_handle(pdev->dev.of_node);
+ pinfo.of_node_reused = true;
pinfo.res = pdev->resource;
pinfo.num_res = pdev->num_resources;
pinfo.data = &pdata;
--
2.22.0
_______________________________________________
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 V4 06/11] arm64: mm: Introduce VA_BITS_ACTUAL
From: Steve Capper @ 2019-08-06 11:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, maz@kernel.org,
bhsharma@redhat.com, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190805172643.GM4175@arrakis.emea.arm.com>
Hi Catalin,
On Mon, Aug 05, 2019 at 06:26:43PM +0100, Catalin Marinas wrote:
> On Mon, Jul 29, 2019 at 05:21:12PM +0100, Steve Capper wrote:
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index a8a91a573bff..93341f4fe840 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -37,8 +37,6 @@
> > * VA_START - the first kernel virtual address.
> > */
> > #define VA_BITS (CONFIG_ARM64_VA_BITS)
> > -#define VA_START (UL(0xffffffffffffffff) - \
> > - (UL(1) << (VA_BITS - 1)) + 1)
> > #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> > (UL(1) << VA_BITS) + 1)
> > #define KIMAGE_VADDR (MODULES_END)
> > @@ -166,10 +164,14 @@
> > #endif
> >
> > #ifndef __ASSEMBLY__
> > +extern u64 vabits_actual;
> > +#define VA_BITS_ACTUAL ({vabits_actual;})
>
> Why not use the variable vabits_actual directly instead of defining a
> macro?
>
I thought that it would look better to have an uppercase name for the
actual VA bits to match the existing code style for VA_BITS.
I can just rename vabits_actual => VA_BITS_ACTUAL and get rid of the
macro?
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index ac58c69993ec..6dc7349868d9 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -321,6 +321,11 @@ __create_page_tables:
> > dmb sy
> > dc ivac, x6 // Invalidate potentially stale cache line
> >
> > + adr_l x6, vabits_actual
> > + str x5, [x6]
> > + dmb sy
> > + dc ivac, x6 // Invalidate potentially stale cache line
>
> Can we not replace vabits_user with vabits_actual and have a single
> write? Maybe not in this patch but once the series is applied, they are
> practically the same. It could be an additional patch (or define a
> vabits_user macro as vabits_actual).
>
Thanks, I think it may be better to consolidate these in an extra patch (just
before the documentation patch). I'll add this to the series.
Cheers,
--
Steve
_______________________________________________
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: mm: print hexadecimal EC value in mem_abort_decode()
From: Miles Chen @ 2019-08-06 11:29 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, wsd_upstream, Anshuman Khandual, linux-kernel,
Miles Chen, linux-mediatek, James Morse, linux-arm-kernel
This change prints the hexadecimal EC value in mem_abort_decode(),
which makes it easier to lookup the corresponding EC in
the ARM Architecture Reference Manual.
The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
faults") prints useful information when memory abort occurs. It would
be easier to lookup "0x25" instead of "DABT" in the document. Then we
can check the corresponding ISS.
For example:
Current info Document
EC Exception class
"CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
"ASIMD" 0x7 "Access to SIMD or floating-point..."
"DABT (current EL)" 0x25 "Data Abort taken without..."
...
Before:
Unable to handle kernel paging request at virtual address 000000000000c000
Mem abort info:
ESR = 0x96000046
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000046
CM = 0, WnR = 1
After:
Unable to handle kernel paging request at virtual address 000000000000c000
Mem abort info:
ESR = 0x96000046
EC = 0x25, Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000046
CM = 0, WnR = 1
Cc: Mark Rutland <Mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
---
arch/arm64/mm/fault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index cfd65b63f36f..afb6041e25e6 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -86,8 +86,8 @@ static void mem_abort_decode(unsigned int esr)
pr_alert("Mem abort info:\n");
pr_alert(" ESR = 0x%08x\n", esr);
- pr_alert(" Exception class = %s, IL = %u bits\n",
- esr_get_class_string(esr),
+ pr_alert(" EC = 0x%lx, Exception class = %s, IL = %u bits\n",
+ ESR_ELx_EC(esr), esr_get_class_string(esr),
(esr & ESR_ELx_IL) ? 32 : 16);
pr_alert(" SET = %lu, FnV = %lu\n",
(esr & ESR_ELx_SET_MASK) >> ESR_ELx_SET_SHIFT,
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* 5.2: arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
From: Andreas Schwab @ 2019-08-06 11:28 UTC (permalink / raw)
To: linux-arm-kernel
When trying to boot 5.2 on a seattle platform, I'm getting these errors:
[ 5056.934028] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
[ 5056.953895] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
[ 5056.961452] arm_smmu_global_fault: 2959 callbacks suppressed
[ 5056.961456] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5056.977276] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
[ 5056.984838] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.007296] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.017475] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.039919] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.050098] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.072592] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.082766] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.105167] arm-smmu e0600000.smmu: GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5057.115342] arm-smmu e0600000.smmu: GFSR 0x80000000, GFSYNR0 0x00000000, GFSYNR1 0x00000001, GFSYNR2 0x00000000
[ 5061.847674] arm_smmu_global_fault: 2964 callbacks suppressed
The errors start as soon as the network interface is being brought up,
and causes networking to fail to work.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
_______________________________________________
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] drm/amdgpu: fix compile error about readq/writeq on arm ARCH
From: Christian König @ 2019-08-06 11:26 UTC (permalink / raw)
To: Tao Zhou, amd-gfx, alexander.deucher, hawking.zhang, dennis.li,
broonie
Cc: linux-next, linux-arm-kernel, kernel-build-reports
In-Reply-To: <20190806103156.3778-1-tao.zhou1@amd.com>
Am 06.08.19 um 12:31 schrieb Tao Zhou:
> readq/writeq can't be found on arm architecture, implement them
> with 32 bits operations
Mhm, wasn't the whole point about using readq/writeq that we needed
64bit atomic operations?
Christian.
>
> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index f62d4f30e810..aaf7f31cf8df 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -29,6 +29,7 @@
> #include <linux/kthread.h>
> #include <linux/console.h>
> #include <linux/slab.h>
> +#include <linux/io-64-nonatomic-lo-hi.h>
> #include <drm/drmP.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_probe_helper.h>
_______________________________________________
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 10/12] irqchip/gic-v3: Warn about inconsistent implementations of extended ranges
From: Marc Zyngier @ 2019-08-06 11:15 UTC (permalink / raw)
To: Vladimir Murzin, Thomas Gleixner, Jason Cooper, Julien Thierry,
Rob Herring
Cc: Lokesh Vutla, John Garry, linux-kernel, Shameerali Kolothum Thodi,
linux-arm-kernel
In-Reply-To: <e5512fcc-e24e-c29a-8a57-011d194e3c41@arm.com>
Hi Vladimir,
On 06/08/2019 11:15, Vladimir Murzin wrote:
> Hi Marc,
>
> On 8/6/19 11:01 AM, Marc Zyngier wrote:
>> As is it usual for the GIC, it isn't disallowed to put together a system
>> that is majorly inconsistent, with a distributor supporting the
>> extended ranges while some of the CPUs don't.
>>
>> Kindly tell the user that things are sailing isn't going to be smooth.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>> drivers/irqchip/irq-gic-v3.c | 5 +++++
>> include/linux/irqchip/arm-gic-v3.h | 1 +
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>> index f53e58d398ba..334a10d9dbfb 100644
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
>> @@ -1014,6 +1014,11 @@ static void gic_cpu_init(void)
>>
>> gic_enable_redist(true);
>>
>> + WARN((gic_data.ppi_nr > 16 || GIC_ESPI_NR != 0) &&
>> + !(gic_read_ctlr() & ICC_CTLR_EL1_ExtRange),
>> + "Distributor has extended ranges, but CPU%d doesn't\n",
>> + smp_processor_id());
>> +
>
> Should such setup be tainted?
I'm not completely sure. The system isn't really dead, but a whole range
of interrupts will not be able to make it to the CPU. It won't be less
reliable though.
I expect this to be more for system integration purposes (simulation
setup, for example), where something hasn't been setup correctly. Or to
spot implementation creativity, such as in the last patch.
I'm happy either way, TBH.
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: tmc-etr: Fix updating buffer in not-snapshot mode.
From: Suzuki K Poulose @ 2019-08-06 11:15 UTC (permalink / raw)
To: yabinc, mathieu.poirier, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190805233738.136357-1-yabinc@google.com>
Hi Yabin
On 06/08/2019 00:37, Yabin Cui wrote:
> TMC etr always copies all available data to perf aux buffer, which
> may exceed the available space in perf aux buffer. It isn't suitable
> for not-snapshot mode, because:
> 1) It may overwrite previously written data.
> 2) It may make the perf_event_mmap_page->aux_head report having more
> or less data than the reality.
Thanks for debugging and the fix.
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 17006705287a..697e68d492af 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1410,9 +1410,10 @@ static void tmc_free_etr_buffer(void *config)
> * tmc_etr_sync_perf_buffer: Copy the actual trace data from the hardware
> * buffer to the perf ring buffer.
> */
> -static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf)
> +static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
> + unsigned long to_copy)
> {
> - long bytes, to_copy;
> + long bytes;
> long pg_idx, pg_offset, src_offset;
> unsigned long head = etr_perf->head;
> char **dst_pages, *src_buf;
> @@ -1423,7 +1424,6 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf)
> pg_offset = head & (PAGE_SIZE - 1);
> dst_pages = (char **)etr_perf->pages;
> src_offset = etr_buf->offset;
> - to_copy = etr_buf->len;
>
> while (to_copy > 0) {
> /*
> @@ -1501,7 +1501,11 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> size = etr_buf->len;
> - tmc_etr_sync_perf_buffer(etr_perf);
> + if (!etr_perf->snapshot && size > handle->size) {
> + size = handle->size;
> + lost = true;
> + }
> + tmc_etr_sync_perf_buffer(etr_perf, size);
The patch as such looks good to me.
I was thinking if we should limit the ETR buffer to the perf ring buffer,
in case the perf buffer is smaller than the ETR configured size.
Irrespective of snapshot mode or not, we can't save more than what the ring
buffer offers us with. Even though for the cpu-wide trace, we could have "n"
such ring buffers, we end up using only one ring buffer(the last one scheduled
out). May be we could explore if we could improve the handling of large buffer
into multiple ring buffers (which may require perf core changes).
Anyways, for this patch:
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.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 v2 12/12] irqchip/gic-v3: Add quirks for HIP06/07 invalid GICD_TYPER erratum 161010803
From: John Garry @ 2019-08-06 11:07 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner, Jason Cooper, Julien Thierry,
Rob Herring
Cc: Lokesh Vutla, linux-kernel, Shameerali Kolothum Thodi,
linux-arm-kernel
In-Reply-To: <20190806100121.240767-13-maz@kernel.org>
On 06/08/2019 11:01, Marc Zyngier wrote:
> It looks like the HIP06/07 SoCs have extra bits in their GICD_TYPER
> registers, which confuse the GICv3.1 code (these systems appear to
> expose ESPIs while they actually don't).
>
> Detect these systems as early as possible and wipe the fields that
> should be RES0 in the register.
>
thanks,
Tested-by: John Garry <john.garry@huawei.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> Documentation/arm64/silicon-errata.rst | 2 +
> drivers/irqchip/irq-gic-v3.c | 54 +++++++++++++++++++++-----
> 2 files changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
> index 3e57d09246e6..17ea3fecddaa 100644
> --- a/Documentation/arm64/silicon-errata.rst
> +++ b/Documentation/arm64/silicon-errata.rst
> @@ -115,6 +115,8 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | Hisilicon | Hip0{6,7} | #161010701 | N/A |
> +----------------+-----------------+-----------------+-----------------------------+
> +| Hisilicon | Hip0{6,7} | #161010803 | N/A |
> ++----------------+-----------------+-----------------+-----------------------------+
> | Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
> +----------------+-----------------+-----------------+-----------------------------+
> | Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 334a10d9dbfb..bee141613b67 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -1441,6 +1441,46 @@ static bool gic_enable_quirk_msm8996(void *data)
> return true;
> }
>
> +static bool gic_enable_quirk_hip06_07(void *data)
> +{
> + struct gic_chip_data *d = data;
> +
> + /*
> + * HIP06 GICD_IIDR clashes with GIC-600 product number (despite
> + * not being an actual ARM implementation). The saving grace is
> + * that GIC-600 doesn't have ESPI, so nothing to do in that case.
> + * HIP07 doesn't even have a proper IIDR, and still pretends to
> + * have ESPI. In both cases, put them right.
> + */
> + if (d->rdists.gicd_typer & GICD_TYPER_ESPI) {
> + /* Zero both ESPI and the RES0 field next to it... */
> + d->rdists.gicd_typer &= ~GENMASK(9, 8);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static const struct gic_quirk gic_quirks[] = {
> + {
> + .desc = "GICv3: Qualcomm MSM8996 broken firmware",
> + .compatible = "qcom,msm8996-gic-v3",
> + .init = gic_enable_quirk_msm8996,
> + },
> + {
> + .desc = "GICv3: HIP06 erratum 161010803",
> + .iidr = 0x0204043b,
> + .init = gic_enable_quirk_hip06_07,
> + },
> + {
> + .desc = "GICv3: HIP07 erratum 161010803",
> + .iidr = 0x00000000,
> + .init = gic_enable_quirk_hip06_07,
> + },
> + {
> + }
> +};
> +
> static void gic_enable_nmi_support(void)
> {
> int i;
> @@ -1494,6 +1534,10 @@ static int __init gic_init_bases(void __iomem *dist_base,
> */
> typer = readl_relaxed(gic_data.dist_base + GICD_TYPER);
> gic_data.rdists.gicd_typer = typer;
> +
> + gic_enable_quirks(readl_relaxed(gic_data.dist_base + GICD_IIDR),
> + gic_quirks, &gic_data);
> +
> pr_info("%d SPIs implemented\n", GIC_LINE_NR - 32);
> pr_info("%d Extended SPIs implemented\n", GIC_ESPI_NR);
> gic_data.domain = irq_domain_create_tree(handle, &gic_irq_domain_ops,
> @@ -1676,16 +1720,6 @@ static void __init gic_of_setup_kvm_info(struct device_node *node)
> gic_set_kvm_info(&gic_v3_kvm_info);
> }
>
> -static const struct gic_quirk gic_quirks[] = {
> - {
> - .desc = "GICv3: Qualcomm MSM8996 broken firmware",
> - .compatible = "qcom,msm8996-gic-v3",
> - .init = gic_enable_quirk_msm8996,
> - },
> - {
> - }
> -};
> -
> static int __init gic_of_init(struct device_node *node, struct device_node *parent)
> {
> void __iomem *dist_base;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFCv3 2/3] interconnect: Add imx core driver
From: Leonard Crestez @ 2019-08-06 10:55 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Artur Świgoń,
Alexandre Bailon, Viresh Kumar
Cc: Mark Rutland, Dong Aisheng, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Michael Turquette, linux-pm,
Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-imx, kernel, Fabio Estevam, Shawn Guo, devicetree,
linux-arm-kernel
In-Reply-To: <cover.1565088423.git.leonard.crestez@nxp.com>
This adds support for i.MX SoC family to interconnect framework.
Platform drivers can describe their interconnect graph and
several adjustment knobs where an icc node bandwith converted to a
clk_min_rate request.
All adjustable nodes are assumed to be independent.
Based on an earlier work by Alexandre Bailon but greatly reduced to drop
"platform opp" support.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
drivers/interconnect/Kconfig | 1 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/imx/Kconfig | 5 +
drivers/interconnect/imx/Makefile | 1 +
drivers/interconnect/imx/imx.c | 258 ++++++++++++++++++++++++++++++
drivers/interconnect/imx/imx.h | 62 +++++++
6 files changed, 328 insertions(+)
create mode 100644 drivers/interconnect/imx/Kconfig
create mode 100644 drivers/interconnect/imx/Makefile
create mode 100644 drivers/interconnect/imx/imx.c
create mode 100644 drivers/interconnect/imx/imx.h
diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index bfa4ca3ab7a9..e61802230f90 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -10,7 +10,8 @@ menuconfig INTERCONNECT
If unsure, say no.
if INTERCONNECT
source "drivers/interconnect/qcom/Kconfig"
+source "drivers/interconnect/imx/Kconfig"
endif
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 28f2ab0824d5..20a13b7eb37f 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -2,5 +2,6 @@
icc-core-objs := core.o
obj-$(CONFIG_INTERCONNECT) += icc-core.o
obj-$(CONFIG_INTERCONNECT_QCOM) += qcom/
+obj-$(CONFIG_INTERCONNECT_IMX) += imx/
diff --git a/drivers/interconnect/imx/Kconfig b/drivers/interconnect/imx/Kconfig
new file mode 100644
index 000000000000..45fbae7007af
--- /dev/null
+++ b/drivers/interconnect/imx/Kconfig
@@ -0,0 +1,5 @@
+config INTERCONNECT_IMX
+ bool "i.MX interconnect drivers"
+ depends on ARCH_MXC || ARCH_MXC_ARM64 || COMPILE_TEST
+ help
+ Generic interconnect driver for i.MX SOCs
diff --git a/drivers/interconnect/imx/Makefile b/drivers/interconnect/imx/Makefile
new file mode 100644
index 000000000000..bb92fd9fe4a5
--- /dev/null
+++ b/drivers/interconnect/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_INTERCONNECT_IMX) += imx.o
diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
new file mode 100644
index 000000000000..cc838e40419e
--- /dev/null
+++ b/drivers/interconnect/imx/imx.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Interconnect framework driver for i.MX SoC
+ *
+ * Copyright (c) 2019, BayLibre
+ * Copyright (c) 2019, NXP
+ * Author: Alexandre Bailon <abailon@baylibre.com>
+ * Author: Leonard Crestez <leonard.crestez@nxp.com>
+ */
+
+#include <linux/device.h>
+#include <linux/interconnect-provider.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_qos.h>
+#include <linux/devfreq.h>
+#include <linux/of.h>
+
+#include "imx.h"
+
+/* private icc_provider data */
+struct imx_icc_provider {
+ struct device *dev;
+};
+
+/* private icc_node data */
+struct imx_icc_node {
+ const struct imx_icc_node_desc *desc;
+ struct devfreq *devfreq;
+ struct dev_pm_qos_request qos_req;
+};
+
+static int imx_icc_aggregate(struct icc_node *node, u32 avg_bw,
+ u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
+{
+ *agg_avg += avg_bw;
+ *agg_peak = max(*agg_peak, peak_bw);
+
+ return 0;
+}
+
+static struct icc_node* imx_icc_xlate(struct of_phandle_args *spec, void *data)
+{
+ struct imx_icc_provider *desc = data;
+ struct icc_provider *provider = dev_get_drvdata(desc->dev);
+ unsigned int id = spec->args[0];
+ struct icc_node *node;
+
+ list_for_each_entry (node, &provider->nodes, node_list)
+ if (node->id == id)
+ return node;
+
+ return ERR_PTR(-EINVAL);
+}
+
+static int imx_icc_node_set(struct icc_node *node)
+{
+ struct device *dev = node->provider->dev;
+ struct imx_icc_node *node_data = node->data;
+ unsigned long freq;
+
+ if (!node_data->devfreq)
+ return 0;
+
+ freq = (node->avg_bw + node->peak_bw) * node_data->desc->adj->bw_mul;
+ do_div(freq, node_data->desc->adj->bw_div);
+ if (freq > INT_MAX) {
+ dev_err(dev, "%s can't request more INT_MAX freq\n",
+ node->name);
+ return -ERANGE;
+ }
+
+ dev_dbg(dev, "%s avg_bw %u peak_bw %u min_freq %lu\n",
+ node->name, node->avg_bw, node->peak_bw, freq);
+
+ dev_pm_qos_update_request(&node_data->qos_req, freq);
+
+ return 0;
+}
+
+static int imx_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ return imx_icc_node_set(dst);
+}
+
+static int imx_icc_node_init_devfreq(struct device *dev,
+ struct icc_node *node)
+{
+ struct imx_icc_node *node_data = node->data;
+ const struct imx_icc_node_desc *node_desc = node_data->desc;
+ int index;
+ int ret;
+
+ index = of_property_match_string(dev->of_node,
+ "devfreq-names", node_desc->adj->devfreq_name);
+ if (index < 0) {
+ dev_err(dev, "failed to match devfreq-names %s: %d\n",
+ node_desc->adj->devfreq_name, index);
+ return index;
+ }
+
+ node_data->devfreq = devfreq_get_devfreq_by_phandle(dev, index);
+ if (IS_ERR(node_data->devfreq)) {
+ ret = PTR_ERR(node_data->devfreq);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "failed to fetch devfreq %d %s: %d\n",
+ index, node_desc->adj->devfreq_name, ret);
+ return ret;
+ }
+
+ return dev_pm_qos_add_request(node_data->devfreq->dev.parent,
+ &node_data->qos_req,
+ DEV_PM_QOS_MIN_FREQUENCY, 0);
+}
+
+static struct icc_node *imx_icc_node_add(struct icc_provider *provider,
+ const struct imx_icc_node_desc *node_desc)
+{
+ struct imx_icc_provider *provider_data = provider->data;
+ struct device *dev = provider_data->dev;
+ struct imx_icc_node *node_data;
+ struct icc_node *node;
+ int ret;
+
+ node = icc_node_create(node_desc->id);
+ if (IS_ERR(node)) {
+ dev_err(dev, "failed to create node %d\n", node_desc->id);
+ return node;
+ }
+
+ if (node->data) {
+ dev_err(dev, "already created node %s id=%d\n",
+ node_desc->name, node_desc->id);
+ return ERR_PTR(-EEXIST);
+ }
+
+ node_data = devm_kzalloc(dev, sizeof(*node_data), GFP_KERNEL);
+ if (!node_data) {
+ icc_node_destroy(node->id);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ node->name = node_desc->name;
+ node->data = node_data;
+ node_data->desc = node_desc;
+ if (node_desc->adj) {
+ ret = imx_icc_node_init_devfreq(dev, node);
+ if (ret < 0) {
+ icc_node_destroy(node->id);
+ return ERR_PTR(ret);
+ }
+ }
+
+ icc_node_add(node, provider);
+
+ return node;
+}
+
+static void imx_icc_unregister_nodes(struct icc_provider *provider)
+{
+ struct icc_node *node, *tmp;
+
+ list_for_each_entry_safe(node, tmp, &provider->nodes, node_list) {
+ struct imx_icc_node *node_data = node->data;
+
+ icc_node_del(node);
+ icc_node_destroy(node->id);
+ if (dev_pm_qos_request_active(&node_data->qos_req))
+ dev_pm_qos_remove_request(&node_data->qos_req);
+ }
+}
+
+static int imx_icc_register_nodes(struct icc_provider *provider,
+ const struct imx_icc_node_desc *descs,
+ int count)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < count; i++) {
+ struct icc_node *node;
+ const struct imx_icc_node_desc *node_desc = &descs[i];
+ size_t j;
+
+ node = imx_icc_node_add(provider, node_desc);
+ if (IS_ERR(node)) {
+ ret = PTR_ERR(node);
+ if (ret != -EPROBE_DEFER)
+ dev_err(provider->dev, "failed to add %s: %d\n",
+ node_desc->name, ret);
+ goto err;
+ }
+
+ for (j = 0; j < node_desc->num_links; j++)
+ icc_link_create(node, node_desc->links[j]);
+ }
+
+ return 0;
+
+err:
+ imx_icc_unregister_nodes(provider);
+
+ return ret;
+}
+
+int imx_icc_register(struct platform_device *pdev,
+ struct imx_icc_node_desc *nodes, int nodes_count)
+{
+ struct device *dev = &pdev->dev;
+ struct imx_icc_provider *desc;
+ struct icc_provider *provider;
+ int ret;
+
+ desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+ if (!desc)
+ return -ENOMEM;
+ desc->dev = dev;
+
+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
+ if (!provider)
+ return -ENOMEM;
+ provider->set = imx_icc_set;
+ provider->aggregate = imx_icc_aggregate;
+ provider->xlate = imx_icc_xlate;
+ provider->data = desc;
+ provider->dev = dev;
+ platform_set_drvdata(pdev, provider);
+
+ ret = icc_provider_add(provider);
+ if (ret) {
+ dev_err(dev, "error adding interconnect provider\n");
+ return ret;
+ }
+
+ ret = imx_icc_register_nodes(provider, nodes, nodes_count);
+ if (ret) {
+ dev_err(dev, "error adding interconnect nodes\n");
+ goto provider_del;
+ }
+
+ return 0;
+
+provider_del:
+ icc_provider_del(provider);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(imx_icc_register);
+
+int imx_icc_unregister(struct platform_device *pdev)
+{
+ struct icc_provider *provider = platform_get_drvdata(pdev);
+
+ icc_provider_del(provider);
+ imx_icc_unregister_nodes(provider);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(imx_icc_unregister);
diff --git a/drivers/interconnect/imx/imx.h b/drivers/interconnect/imx/imx.h
new file mode 100644
index 000000000000..ab191eb89616
--- /dev/null
+++ b/drivers/interconnect/imx/imx.h
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Interconnect framework driver for i.MX SoC
+ *
+ * Copyright (c) 2019, BayLibre
+ * Copyright (c) 2019, NXP
+ * Author: Alexandre Bailon <abailon@baylibre.com>
+ * Author: Leonard Crestez <leonard.crestez@nxp.com>
+ */
+#ifndef __BUSFREQ_H
+#define __BUSFREQ_H
+
+#include <linux/kernel.h>
+
+#define IMX_ICC_MAX_LINKS 32
+#define IMX_ICC_UNDEFINED_BW 0xffffffff
+
+/*
+ * struct imx_icc_node_adj - Describe an dynamic adjustment knob
+ */
+struct imx_icc_node_adj_desc {
+ const char *devfreq_name;
+ unsigned int bw_mul, bw_div;
+};
+
+/*
+ * struct imx_icc_node - Describe an interconnect node
+ * @name: name of the node
+ * @id: an unique id to identify the node
+ * @links: an array of slaves' node id
+ * @num_links: number of id defined in links
+ */
+struct imx_icc_node_desc {
+ const char *name;
+ u16 id;
+ u16 links[IMX_ICC_MAX_LINKS];
+ u16 num_links;
+
+ const struct imx_icc_node_adj_desc *adj;
+};
+
+#define DEFINE_BUS_INTERCONNECT(_name, _id, _adj, _numlinks, ...) \
+ { \
+ .id = _id, \
+ .name = _name, \
+ .adj = _adj, \
+ .num_links = _numlinks, \
+ .links = { __VA_ARGS__ }, \
+ }
+
+#define DEFINE_BUS_MASTER(_name, _id, _dest_id) \
+ DEFINE_BUS_INTERCONNECT(_name, _id, NULL, 1, _dest_id)
+
+#define DEFINE_BUS_SLAVE(_name, _id, _adj) \
+ DEFINE_BUS_INTERCONNECT(_name, _id, _adj, 0)
+
+int imx_icc_register(struct platform_device *pdev,
+ struct imx_icc_node_desc *nodes,
+ int nodes_count);
+int imx_icc_unregister(struct platform_device *pdev);
+
+#endif /* __BUSFREQ_H */
--
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
* [RFCv3 3/3] interconnect: imx: Add platform driver for imx8mm
From: Leonard Crestez @ 2019-08-06 10:55 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Artur Świgoń,
Alexandre Bailon, Viresh Kumar
Cc: Mark Rutland, Dong Aisheng, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Michael Turquette, linux-pm,
Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-imx, kernel, Fabio Estevam, Shawn Guo, devicetree,
linux-arm-kernel
In-Reply-To: <cover.1565088423.git.leonard.crestez@nxp.com>
This adds a platform driver for the i.MX8MM SoC.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
drivers/interconnect/imx/Kconfig | 4 +
drivers/interconnect/imx/Makefile | 1 +
drivers/interconnect/imx/imx8mm.c | 114 ++++++++++++++++++++++
include/dt-bindings/interconnect/imx8mm.h | 49 ++++++++++
4 files changed, 168 insertions(+)
create mode 100644 drivers/interconnect/imx/imx8mm.c
create mode 100644 include/dt-bindings/interconnect/imx8mm.h
diff --git a/drivers/interconnect/imx/Kconfig b/drivers/interconnect/imx/Kconfig
index 45fbae7007af..2f06cb1f81c3 100644
--- a/drivers/interconnect/imx/Kconfig
+++ b/drivers/interconnect/imx/Kconfig
@@ -1,5 +1,9 @@
config INTERCONNECT_IMX
bool "i.MX interconnect drivers"
depends on ARCH_MXC || ARCH_MXC_ARM64 || COMPILE_TEST
help
Generic interconnect driver for i.MX SOCs
+
+config INTERCONNECT_IMX8MM
+ def_bool y
+ depends on INTERCONNECT_IMX
diff --git a/drivers/interconnect/imx/Makefile b/drivers/interconnect/imx/Makefile
index bb92fd9fe4a5..5f658c1608a6 100644
--- a/drivers/interconnect/imx/Makefile
+++ b/drivers/interconnect/imx/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_INTERCONNECT_IMX) += imx.o
+obj-$(CONFIG_INTERCONNECT_IMX8MM) += imx8mm.o
diff --git a/drivers/interconnect/imx/imx8mm.c b/drivers/interconnect/imx/imx8mm.c
new file mode 100644
index 000000000000..5bed7babff96
--- /dev/null
+++ b/drivers/interconnect/imx/imx8mm.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Interconnect framework driver for i.MX SoC
+ *
+ * Copyright (c) 2019, BayLibre
+ * Copyright (c) 2019, NXP
+ * Author: Alexandre Bailon <abailon@baylibre.com>
+ * Author: Leonard Crestez <leonard.crestez@nxp.com>
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/interconnect/imx8mm.h>
+
+#include "imx.h"
+
+static const struct imx_icc_node_adj_desc imx8mm_dram_adj = {
+ .devfreq_name = "dram",
+ .bw_mul = 1,
+ .bw_div = 16,
+};
+
+static const struct imx_icc_node_adj_desc imx8mm_noc_adj = {
+ .devfreq_name = "noc",
+ .bw_mul = 1,
+ .bw_div = 16,
+};
+
+/*
+ * Describe bus masters, slaves and connections between them
+ *
+ * This is a simplified subset of the bus diagram, there are several other
+ * PL301 nics which are skipped/merged into PL301_MAIN
+ */
+static struct imx_icc_node_desc nodes[] = {
+ DEFINE_BUS_INTERCONNECT("NOC", IMX8MM_ICN_NOC, &imx8mm_noc_adj,
+ 2, IMX8MM_ICS_DRAM, IMX8MM_ICN_MAIN),
+
+ DEFINE_BUS_SLAVE("DRAM", IMX8MM_ICS_DRAM, &imx8mm_dram_adj),
+ DEFINE_BUS_SLAVE("OCRAM", IMX8MM_ICS_OCRAM, NULL),
+ DEFINE_BUS_MASTER("A53", IMX8MM_ICM_A53, IMX8MM_ICN_NOC),
+
+ /* VPUMIX */
+ DEFINE_BUS_MASTER("VPU H1", IMX8MM_ICM_VPU_H1, IMX8MM_ICN_VIDEO),
+ DEFINE_BUS_MASTER("VPU G1", IMX8MM_ICM_VPU_G1, IMX8MM_ICN_VIDEO),
+ DEFINE_BUS_MASTER("VPU G2", IMX8MM_ICM_VPU_G2, IMX8MM_ICN_VIDEO),
+ DEFINE_BUS_INTERCONNECT("PL301_VIDEO", IMX8MM_ICN_VIDEO, NULL, 1, IMX8MM_ICN_NOC),
+
+ /* GPUMIX */
+ DEFINE_BUS_MASTER("GPU 2D", IMX8MM_ICM_GPU2D, IMX8MM_ICN_GPU),
+ DEFINE_BUS_MASTER("GPU 3D", IMX8MM_ICM_GPU3D, IMX8MM_ICN_GPU),
+ DEFINE_BUS_INTERCONNECT("PL301_GPU", IMX8MM_ICN_GPU, NULL, 1, IMX8MM_ICN_NOC),
+
+ /* DISPLAYMIX */
+ DEFINE_BUS_MASTER("CSI", IMX8MM_ICM_CSI, IMX8MM_ICN_MIPI),
+ DEFINE_BUS_MASTER("LCDIF", IMX8MM_ICM_LCDIF, IMX8MM_ICN_MIPI),
+ DEFINE_BUS_INTERCONNECT("PL301_MIPI", IMX8MM_ICN_MIPI, NULL, 1, IMX8MM_ICN_NOC),
+
+ /* HSIO */
+ DEFINE_BUS_MASTER("USB1", IMX8MM_ICM_USB1, IMX8MM_ICN_HSIO),
+ DEFINE_BUS_MASTER("USB2", IMX8MM_ICM_USB2, IMX8MM_ICN_HSIO),
+ DEFINE_BUS_MASTER("PCIE", IMX8MM_ICM_PCIE, IMX8MM_ICN_HSIO),
+ DEFINE_BUS_INTERCONNECT("PL301_HSIO", IMX8MM_ICN_HSIO, NULL, 1, IMX8MM_ICN_NOC),
+
+ /* Audio */
+ DEFINE_BUS_MASTER("SDMA2", IMX8MM_ICM_SDMA2, IMX8MM_ICN_AUDIO),
+ DEFINE_BUS_MASTER("SDMA3", IMX8MM_ICM_SDMA3, IMX8MM_ICN_AUDIO),
+ DEFINE_BUS_INTERCONNECT("PL301_AUDIO", IMX8MM_ICN_AUDIO, NULL, 1, IMX8MM_ICN_MAIN),
+
+ /* Ethernet */
+ DEFINE_BUS_MASTER("ENET", IMX8MM_ICM_ENET, IMX8MM_ICN_ENET),
+ DEFINE_BUS_INTERCONNECT("PL301_ENET", IMX8MM_ICN_ENET, NULL, 1, IMX8MM_ICN_MAIN),
+
+ /* Other */
+ DEFINE_BUS_MASTER("SDMA1", IMX8MM_ICM_SDMA1, IMX8MM_ICN_MAIN),
+ DEFINE_BUS_MASTER("NAND", IMX8MM_ICM_NAND, IMX8MM_ICN_MAIN),
+ DEFINE_BUS_MASTER("USDHC1", IMX8MM_ICM_USDHC1, IMX8MM_ICN_MAIN),
+ DEFINE_BUS_MASTER("USDHC2", IMX8MM_ICM_USDHC2, IMX8MM_ICN_MAIN),
+ DEFINE_BUS_MASTER("USDHC3", IMX8MM_ICM_USDHC3, IMX8MM_ICN_MAIN),
+ DEFINE_BUS_INTERCONNECT("PL301_MAIN", IMX8MM_ICN_MAIN, NULL,
+ 2, IMX8MM_ICN_NOC, IMX8MM_ICS_OCRAM),
+};
+
+static int imx8mm_icc_probe(struct platform_device *pdev)
+{
+ return imx_icc_register(pdev, nodes, ARRAY_SIZE(nodes));
+}
+
+static int imx8mm_icc_remove(struct platform_device *pdev)
+{
+ return imx_icc_unregister(pdev);
+}
+
+static const struct of_device_id imx_icc_of_match[] = {
+ { .compatible = "fsl,imx8mm-interconnect" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, imx_icc_of_match);
+
+static struct platform_driver imx8mm_icc_driver = {
+ .probe = imx8mm_icc_probe,
+ .remove = imx8mm_icc_remove,
+ .driver = {
+ .name = "imx8mm-interconnect",
+ .of_match_table = imx_icc_of_match,
+ },
+};
+
+builtin_platform_driver(imx8mm_icc_driver);
+MODULE_AUTHOR("Alexandre Bailon <abailon@baylibre.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/dt-bindings/interconnect/imx8mm.h b/include/dt-bindings/interconnect/imx8mm.h
new file mode 100644
index 000000000000..5404f2af15c3
--- /dev/null
+++ b/include/dt-bindings/interconnect/imx8mm.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Interconnect framework driver for i.MX SoC
+ *
+ * Copyright (c) 2019, BayLibre
+ * Author: Alexandre Bailon <abailon@baylibre.com>
+ */
+
+#ifndef __IMX8MM_ICM_INTERCONNECT_IDS_H
+#define __IMX8MM_ICM_INTERCONNECT_IDS_H
+
+#define IMX8MM_ICN_NOC 1
+#define IMX8MM_ICS_DRAM 2
+#define IMX8MM_ICS_OCRAM 3
+#define IMX8MM_ICM_A53 4
+
+#define IMX8MM_ICM_VPU_H1 5
+#define IMX8MM_ICM_VPU_G1 6
+#define IMX8MM_ICM_VPU_G2 7
+#define IMX8MM_ICN_VIDEO 8
+
+#define IMX8MM_ICM_GPU2D 9
+#define IMX8MM_ICM_GPU3D 10
+#define IMX8MM_ICN_GPU 11
+
+#define IMX8MM_ICM_CSI 12
+#define IMX8MM_ICM_LCDIF 13
+#define IMX8MM_ICN_MIPI 14
+
+#define IMX8MM_ICM_USB1 15
+#define IMX8MM_ICM_USB2 16
+#define IMX8MM_ICM_PCIE 17
+#define IMX8MM_ICN_HSIO 18
+
+#define IMX8MM_ICM_SDMA2 19
+#define IMX8MM_ICM_SDMA3 20
+#define IMX8MM_ICN_AUDIO 21
+
+#define IMX8MM_ICN_ENET 22
+#define IMX8MM_ICM_ENET 23
+
+#define IMX8MM_ICN_MAIN 24
+#define IMX8MM_ICM_NAND 25
+#define IMX8MM_ICM_SDMA1 26
+#define IMX8MM_ICM_USDHC1 27
+#define IMX8MM_ICM_USDHC2 28
+#define IMX8MM_ICM_USDHC3 29
+
+#endif /* __IMX8MM_ICM_INTERCONNECT_IDS_H */
--
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
* [RFCv3 1/3] dt-bindings: interconnect: Add bindings for imx
From: Leonard Crestez @ 2019-08-06 10:55 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Artur Świgoń,
Alexandre Bailon, Viresh Kumar
Cc: Mark Rutland, Dong Aisheng, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Michael Turquette, linux-pm,
Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-imx, kernel, Fabio Estevam, Shawn Guo, devicetree,
linux-arm-kernel
In-Reply-To: <cover.1565088423.git.leonard.crestez@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
.../devicetree/bindings/interconnect/imx.yaml | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/imx.yaml
diff --git a/Documentation/devicetree/bindings/interconnect/imx.yaml b/Documentation/devicetree/bindings/interconnect/imx.yaml
new file mode 100644
index 000000000000..c6f173b38f4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/imx.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/imx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic i.MX interconnect device
+
+maintainers:
+ - Leonard Crestez <leonard.crestez@nxp.com>
+
+properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mm-interconnect
+ "#interconnect-cells":
+ const: 1
+ devfreq-names:
+ description: Names of devfreq instances for adjustable nodes
+ devfreq:
+ description: List of phandle pointing to devfreq instances
+
+required:
+ - compatible
+ - "#interconnect-cells"
+ - "devfreq-names"
+ - "devfreq"
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/imx8mm.h>
+ icc: interconnect {
+ compatible = "fsl,imx8mm-interconnect";
+ #interconnect-cells = <1>;
+ devfreq-names = "dram", "noc", "axi";
+ devfreq = <&ddrc>, <&noc>, <&pl301_main>;
+ };
--
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
* [RFCv3 0/3] interconnect: Add imx support via devfreq
From: Leonard Crestez @ 2019-08-06 10:55 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Artur Świgoń,
Alexandre Bailon, Viresh Kumar
Cc: Mark Rutland, Dong Aisheng, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Michael Turquette, linux-pm,
Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-imx, kernel, Fabio Estevam, Shawn Guo, devicetree,
linux-arm-kernel
This series add imx support for interconnect via devfreq: the ICC
framework is used to aggregate requests from devices and then those are
converted to "min_freq" requests to devfreq.
The dev_pm_qos API is used to request min frequencies from devfreq, it
relies on this patch: https://patchwork.kernel.org/patch/11078475/
This is greatly reduced compared to previous submissions:
* Relying on devfreq and dev_pm_qos instead of CLK allows a wider range
of implementations for scaling individual nodes. In particular it's no
longer required to force DDR scaling into CLK.
* No more "platform opp" stuff: forcing everything to scale together
loses many of the benefits of ICC. The devfreq "passive" governor can
still be used to tie some pieces of the fabric together.
* No more suspend/resume handling: devfreq uses OPP framework which
already supports "suspend-opp".
* Replace all mentions of "busfreq" with "interconnect"
Link to v2: https://patchwork.kernel.org/patch/11056789/
The per-soc platform drivers still need to defined the interconnect
graph and links to devfreq (by name) as well as bus widths. For example
some of the 128-bit buses on imx8m mini are 64-bit on imx8m nano.
There was another recent series tying icc and devfreq, for exynos:
* https://lkml.org/lkml/2019/7/23/394
That series defines the interconnect graph/tree entirely inside
devicetree but that seems limiting. I'd rather keep the graph in a SOC
driver and #define ids for all bus masters/slaves. This way if USB1 and
USB2 are on the same bus they can still be treated differently.
One interesting idea from there is to turn devfreq nodes into
interconnect providers, this can avoid the need for a "virtual" ICC node
in devicetree. I expect devicetree folks will object to that?
Leonard Crestez (3):
dt-bindings: interconnect: Add bindings for imx
interconnect: Add imx core driver
interconnect: imx: Add platform driver for imx8mm
.../devicetree/bindings/interconnect/imx.yaml | 38 +++
drivers/interconnect/Kconfig | 1 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/imx/Kconfig | 9 +
drivers/interconnect/imx/Makefile | 2 +
drivers/interconnect/imx/imx.c | 258 ++++++++++++++++++
drivers/interconnect/imx/imx.h | 62 +++++
drivers/interconnect/imx/imx8mm.c | 114 ++++++++
include/dt-bindings/interconnect/imx8mm.h | 49 ++++
9 files changed, 534 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/imx.yaml
create mode 100644 drivers/interconnect/imx/Kconfig
create mode 100644 drivers/interconnect/imx/Makefile
create mode 100644 drivers/interconnect/imx/imx.c
create mode 100644 drivers/interconnect/imx/imx.h
create mode 100644 drivers/interconnect/imx/imx8mm.c
create mode 100644 include/dt-bindings/interconnect/imx8mm.h
--
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
* [PATCH] drm/amdgpu: fix compile error about readq/writeq on arm ARCH
From: Tao Zhou @ 2019-08-06 10:31 UTC (permalink / raw)
To: amd-gfx, alexander.deucher, hawking.zhang, dennis.li, broonie
Cc: Tao Zhou, linux-next, linux-arm-kernel, kernel-build-reports
readq/writeq can't be found on arm architecture, implement them
with 32 bits operations
Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f62d4f30e810..aaf7f31cf8df 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -29,6 +29,7 @@
#include <linux/kthread.h>
#include <linux/console.h>
#include <linux/slab.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
#include <drm/drmP.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_probe_helper.h>
--
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 V5 1/5] clocksource: imx-sysctr: Add internal clock divider handle
From: Daniel Lezcano @ 2019-08-06 10:27 UTC (permalink / raw)
To: Anson Huang, catalin.marinas@arm.com, will@kernel.org,
robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
dl-linux-imx, tglx@linutronix.de, Leonard Crestez, Aisheng Dong,
Daniel Baluta, Jacky Bai, l.stach@pengutronix.de, Abel Vesa,
andrew.smirnov@gmail.com, ccaione@baylibre.com, angus@akkea.ca,
agx@sigxcpu.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <DB3PR0402MB3916B06E8907604A71169063F5D50@DB3PR0402MB3916.eurprd04.prod.outlook.com>
On 06/08/2019 03:55, Anson Huang wrote:
> Gentle ping...
Coming back from vacation. It is in the pipe ... :)
>> From: Anson Huang <Anson.Huang@nxp.com>
>>
>> The system counter block guide states that the base clock is internally divided
>> by 3 before use, that means the clock input of system counter defined in DT
>> should be base clock which is normally from OSC, and then internally divided
>> by 3 before use.
>>
>> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>> ---
>> Changes since V4:
>> - to solve the clock driver probed after system counter driver issue,
>> now we can easily switch to
>> use fixed clock defined in DT and get its rate, then divided by 3 to
>> get real clock rate for
>> system counter driver, no need to add "clock-frequency" property in
>> DT.
>> ---
>> drivers/clocksource/timer-imx-sysctr.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/clocksource/timer-imx-sysctr.c
>> b/drivers/clocksource/timer-imx-sysctr.c
>> index fd7d680..b7c80a3 100644
>> --- a/drivers/clocksource/timer-imx-sysctr.c
>> +++ b/drivers/clocksource/timer-imx-sysctr.c
>> @@ -20,6 +20,8 @@
>> #define SYS_CTR_EN 0x1
>> #define SYS_CTR_IRQ_MASK 0x2
>>
>> +#define SYS_CTR_CLK_DIV 0x3
>> +
>> static void __iomem *sys_ctr_base;
>> static u32 cmpcr;
>>
>> @@ -134,6 +136,9 @@ static int __init sysctr_timer_init(struct device_node
>> *np)
>> if (ret)
>> return ret;
>>
>> + /* system counter clock is divided by 3 internally */
>> + to_sysctr.of_clk.rate /= SYS_CTR_CLK_DIV;
>> +
>> sys_ctr_base = timer_of_base(&to_sysctr);
>> cmpcr = readl(sys_ctr_base + CMPCR);
>> cmpcr &= ~SYS_CTR_EN;
>> --
>> 2.7.4
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
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 10/12] irqchip/gic-v3: Warn about inconsistent implementations of extended ranges
From: Vladimir Murzin @ 2019-08-06 10:15 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner, Jason Cooper, Julien Thierry,
Rob Herring
Cc: Lokesh Vutla, John Garry, linux-kernel, Shameerali Kolothum Thodi,
linux-arm-kernel
In-Reply-To: <20190806100121.240767-11-maz@kernel.org>
Hi Marc,
On 8/6/19 11:01 AM, Marc Zyngier wrote:
> As is it usual for the GIC, it isn't disallowed to put together a system
> that is majorly inconsistent, with a distributor supporting the
> extended ranges while some of the CPUs don't.
>
> Kindly tell the user that things are sailing isn't going to be smooth.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/irqchip/irq-gic-v3.c | 5 +++++
> include/linux/irqchip/arm-gic-v3.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index f53e58d398ba..334a10d9dbfb 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -1014,6 +1014,11 @@ static void gic_cpu_init(void)
>
> gic_enable_redist(true);
>
> + WARN((gic_data.ppi_nr > 16 || GIC_ESPI_NR != 0) &&
> + !(gic_read_ctlr() & ICC_CTLR_EL1_ExtRange),
> + "Distributor has extended ranges, but CPU%d doesn't\n",
> + smp_processor_id());
> +
Should such setup be tainted?
Cheers
Vladimir
> rbase = gic_data_rdist_sgi_base();
>
> /* Configure SGIs/PPIs as non-secure Group-1 */
> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> index 9ec3349dee04..5cc10cf7cb3e 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -496,6 +496,7 @@
> #define ICC_CTLR_EL1_A3V_SHIFT 15
> #define ICC_CTLR_EL1_A3V_MASK (0x1 << ICC_CTLR_EL1_A3V_SHIFT)
> #define ICC_CTLR_EL1_RSS (0x1 << 18)
> +#define ICC_CTLR_EL1_ExtRange (0x1 << 19)
> #define ICC_PMR_EL1_SHIFT 0
> #define ICC_PMR_EL1_MASK (0xff << ICC_PMR_EL1_SHIFT)
> #define ICC_BPR0_EL1_SHIFT 0
>
_______________________________________________
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