* [PATCH] arm: spin one more cycle in timer-based delays
From: Mason @ 2016-11-18 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118120630.GJ13470@arm.com>
On 18/11/2016 13:06, Will Deacon wrote:
> On Tue, Nov 15, 2016 at 02:36:33PM +0100, Mason wrote:
>
>> When polling a tick counter in a busy loop, one might sample the
>> counter just *before* it is updated, and then again just *after*
>> it is updated. In that case, while mathematically v2-v1 equals 1,
>> only epsilon has really passed.
>>
>> So, if a caller requests an N-cycle delay, we spin until v2-v1
>> is strictly greater than N to avoid these random corner cases.
>>
>> Signed-off-by: Mason <slash.tmp@free.fr>
>> ---
>> arch/arm/lib/delay.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
>> index 69aad80a3af4..3f1cd15ca102 100644
>> --- a/arch/arm/lib/delay.c
>> +++ b/arch/arm/lib/delay.c
>> @@ -60,7 +60,7 @@ static void __timer_delay(unsigned long cycles)
>> {
>> cycles_t start = get_cycles();
>>
>> - while ((get_cycles() - start) < cycles)
>> + while ((get_cycles() - start) <= cycles)
>> cpu_relax();
>> }
>
> I thought a bit about this last night. It is well known that the delay
> routines are not guaranteed to be accurate, and I don't *think* that's
> limited to over-spinning, so arguably this isn't a bug. However, taking
> the approach that "drivers should figure it out" is also unhelpful,
> because the frequency of the underlying counter isn't generally known
> and so drivers can't simply adjust the delay parameter.
>
> If you want to go ahead with this change, I do think that you should fix
> the other architectures for consistency (particularly arm64, which is
> likely to share drivers with arch/arm/). However, given that I don't
> think you've seen a failure in practice, it might be a hard sell to get
> the patches picked up, especially given the deliberately vague guarantees
> offered by the delay loop.
Hello Will,
Thanks for the in-depth analysis.
This is, conceptually, the first patch in a 2-patch series, and perhaps
the intent would have been clearer had I posted the series, along with
full rationale in the cover letter. I'll do that next week, so everyone
can judge with all the information in hand.
Regards.
^ permalink raw reply
* [PATCH v4] arm64: dts: qcom: Add msm8916 CoreSight components
From: Georgi Djakov @ 2016-11-18 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117185918.GA7884@linaro.org>
On 11/17/2016 08:59 PM, Mathieu Poirier wrote:
> On Thu, Nov 17, 2016 at 05:35:22PM +0200, Georgi Djakov wrote:
>> From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
>>
>> Add initial set of CoreSight components found on Qualcomm's 8x16 chipset.
>
> Hello Georgi,
>
> Could you add a better desccription for the SoC? To me "8x16" doesn't
> say much.
Ok, will do it. Thanks!
>
> With that change:
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
^ permalink raw reply
* [PATCH] ARM: dts: qcom: Add apq8064 CoreSight components
From: Georgi Djakov @ 2016-11-18 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d466f591-baac-c734-a49b-8aab763c1876@codeaurora.org>
On 11/18/2016 12:16 AM, Stephen Boyd wrote:
> On 11/17/2016 07:36 AM, Georgi Djakov wrote:
>> From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
>>
>> Add initial set of CoreSight components found on Qualcomm's
>> 8064 chipset.
>>
>> Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>> arch/arm/boot/dts/qcom-apq8064-coresight.dtsi | 196 ++++++++++++++++++++++++++
>
> Why not put this inside the soc file? This would be the first time we
> add a new file for something that's inside the SoC node that probably
> won't change thereafter. At least for pins I slightly agree with having
> a different file, we're adding more and more things there so it's nice
> to have a consolidated place of all possible configurations to choose
> from. But here it's mostly a static device description so what's the gain?
Ok, after thinking more about this and looking at other soc dtsi files i
agree with you. Will update!
Thanks!
Georgi
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Mason @ 2016-11-18 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFd313x6MJeO90_+rxditdPn762g7TqZc0_D6ojGTKmtGJKjPA@mail.gmail.com>
On 18/11/2016 11:49, Rameshwar Sahu wrote:
> Mason wrote:
>
>> Suman/APM added "arasan,sdhci-4.9a" in 308f3f8d8112
>> @Suman, @Rameshwar: what specific IP block does your SoC embed?
>> What does 4.9a refer to? The documentation revision number?
>
> We have Arasan SD3.0/ SDIO3.0/ eMMC4.41 AHB Host Controller IP
> embedded in our SoC and 4.9a is documentation revision number which
> was given by Arasan.
> FYI this documentation date was May, 2012.
Hello Ram,
Thanks for the information.
Xilinx is using "SD2.0/SDIO2.0/MMC3.31 AHB Host Controller"
APM is using "SD3.0/SDIO3.0/eMMC4.41 AHB Host Controller"
Sigma is using "SD3.0/SDIO3.0/eMMC4.4 AHB Host Controller"
Rockchip is using ? (Shawn could you specify exactly which IP you use?)
And it looks like Arasan is using different revision numbers for
every documentation they have.
The "SD3.0/SDIO3.0/eMMC4.4 AHB Host Controller" doc I have is
at rev number 6.0, dated 2010-02-19.
Regards.
^ permalink raw reply
* [GIT PULL 1/2] arm64: dts: exynos: Topic dts arm64 for v4.10
From: Krzysztof Kozlowski @ 2016-11-18 12:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Topic branch with a GIC interrupt fix and cleanup. No conflicts expected.
No dependencies.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-gic-flags-4.10
for you to fetch changes up to 86bb573d0b2a8e876a12d1348bd0b6e377c1043e:
arm64: dts: exynos: Use human-friendly symbols for interrupt properties in exynos7 (2016-11-03 22:40:39 +0200)
----------------------------------------------------------------
Topic branch with DT arm64 changes for v4.10.
Fix invalid GIC interrupt flags - type IRQ_TYPE_NONE is not allowed for GIC
interrupts. Although this was working but with error messages like:
genirq: Setting trigger mode 0 for irq 16 failed
Use level high interrupt instead of type none. The choice of level high was
rather an arbitrary decision hoping it will work on each platform. Tests shown
no issues so far.
----------------------------------------------------------------
Krzysztof Kozlowski (2):
arm64: dts: exynos: Fix invalid GIC interrupt flags in exynos7
arm64: dts: exynos: Use human-friendly symbols for interrupt properties in exynos7
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 20 +++++--
arch/arm64/boot/dts/exynos/exynos7.dtsi | 69 +++++++++++++------------
2 files changed, 51 insertions(+), 38 deletions(-)
^ permalink raw reply
* [GIT PULL 2/2] ARM: dts: exynos: Topic dts for v4.10
From: Krzysztof Kozlowski @ 2016-11-18 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479473075-9787-1-git-send-email-krzk@kernel.org>
Hi,
Topic branch with a GIC interrupt fixes and cleanup (human-friendly symbols).
Possible rather trivial conflicts:
diff --cc arch/arm/boot/dts/exynos4x12.dtsi
index 0074f566cd3b,505f047e81c6..85a7122658f1
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@@ -147,9 -147,10 +147,10 @@@
};
fimc_is: fimc-is at 12000000 {
- compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+ compatible = "samsung,exynos4212-fimc-is";
reg = <0x12000000 0x260000>;
- interrupts = <0 90 0>, <0 95 0>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&pd_isp>;
clocks = <&clock CLK_FIMC_LITE0>,
<&clock CLK_FIMC_LITE1>, <&clock CLK_PPMUISPX>,
diff --cc arch/arm/boot/dts/exynos5410.dtsi
index 9a91685d8890,2501249d97aa..bb90bbdbe2d9
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@@ -190,58 -181,8 +190,58 @@@
pinctrl_3: pinctrl at 03860000 {
compatible = "samsung,exynos5410-pinctrl";
reg = <0x03860000 0x1000>;
- interrupts = <0 47 0>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ amba {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-gic-flags-4.10
for you to fetch changes up to 04a886727ca7e841afa2fbc5d87aff81ae256dbf:
ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos5440 (2016-11-03 22:44:56 +0200)
----------------------------------------------------------------
Topic branch with DT changes for v4.10.
Fix invalid GIC interrupt flags - type IRQ_TYPE_NONE is not allowed for GIC
interrupts. Although this was working but with error messages like:
genirq: Setting trigger mode 0 for irq 16 failed
Use level high interrupt instead of type none. The choice of level high was
rather an arbitrary decision hoping it will work on each platform. Tests shown
no issues so far.
----------------------------------------------------------------
Krzysztof Kozlowski (14):
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4210
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4x12
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos3250
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5250
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5410/exynos542x
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5260
ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5440
ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos3250
ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos4
ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos5
ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos5260
ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos5440
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos3250.dtsi | 97 ++++++++++++++++++-------------
arch/arm/boot/dts/exynos4.dtsi | 95 ++++++++++++++++--------------
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos4210.dtsi | 36 ++++++++----
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 20 +++++--
arch/arm/boot/dts/exynos4x12.dtsi | 48 ++++++++++-----
arch/arm/boot/dts/exynos5.dtsi | 64 ++++++++++++++------
arch/arm/boot/dts/exynos5250.dtsi | 80 ++++++++++++-------------
arch/arm/boot/dts/exynos5260.dtsi | 43 +++++++++-----
arch/arm/boot/dts/exynos5410.dtsi | 26 ++++-----
arch/arm/boot/dts/exynos5420.dtsi | 78 ++++++++++++-------------
arch/arm/boot/dts/exynos5440.dtsi | 70 +++++++++++++---------
arch/arm/boot/dts/exynos54xx.dtsi | 34 +++++------
14 files changed, 437 insertions(+), 294 deletions(-)
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Russell King - ARM Linux @ 2016-11-18 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9481995.AMBiYg893F@wuerfel>
On Fri, Nov 18, 2016 at 01:14:35PM +0100, Arnd Bergmann wrote:
> @@ -41,6 +43,9 @@ void scu_enable(void __iomem *scu_base)
> {
> u32 scu_ctrl;
>
> + if (scu_base)
> + scu_base = scu_base_addr;
> +
This looks to me like nonsense.
> #ifdef CONFIG_ARM_ERRATA_764369
> /* Cortex-A9 only */
> if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
> @@ -85,6 +90,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> unsigned int val;
> int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
>
> + if (scu_base)
> + scu_base = scu_base_addr;
> +
Ditto.
Rather than doing this, I'd much prefer to always store the SCU base in
the SCU code, and remove the "void __iomem *scu_base" argment from all
these functions.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-18 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2822893.F0LqNAm9bT@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 18 November 2016 12:24
> To: Gabriele Paoloni
> Cc: liviu.dudau at arm.com; linux-arm-kernel at lists.infradead.org;
> Yuanzhichang; mark.rutland at arm.com; devicetree at vger.kernel.org;
> lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
> benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> catalin.marinas at arm.com; olof at lixom.net; bhelgaas at go og le.com;
> zhichang.yuan02 at gmail.com; Jason Gunthorpe; Thomas Petazzoni
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > On Monday, November 14, 2016 11:26:25 AM CET liviu.dudau at arm.com
> wrote:
> > > > On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> > > > > > Nope, that is not what it means. It means that PCI devices
> can
> > > see I/O
> > > > > > addresses
> > > > > > on the bus that start from 0. There never was any usage for
> non-
> > > PCI
> > > > > > controllers
> > > > >
> > > > > So I am a bit confused...
> > > > > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> > > > > It seems that ISA buses operate on cpu I/O address range [0,
> > > 0xFFF].
> > > > > I thought that was the reason why for most architectures we
> have
> > > > > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA
> controllers
> > > > > usually use [0, PCIBIOS_MIN_IO - 1] )
> > > >
> > > > First of all, cpu I/O addresses is an x86-ism. ARM architectures
> and
> > > others
> > > > have no separate address space for I/O, it is all merged into
> one
> > > unified
> > > > address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0
> could
> > > mean
> > > > that we don't care about ISA I/O because the platform does not
> > > support having
> > > > an ISA bus (e.g.).
> > >
> > > I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that
> you
> > > cannot
> > > have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is
> > > different
> > > from having an LPC master outside of PCI, as that lives in its own
> > > domain
> > > and has a separately addressable I/O space.
> >
> > Yes correct so if we go for the single domain solution arch that
> > have PCIBIOS_MIN_IO=0 cannot support special devices such as LPC
> > unless we also redefine PCIBIOS_MIN_IO, right?
>
> This is what I was referring to below as the difference between
> a) and b): Setting PCIBIOS_MIN_IO=0 means you cannot have LPC
> behind PCI, but it shouldn't stop you from having a separate
> LPC bridge.
>
> > > The PCIBIOS_MIN_DIRECT_IO name still suggests having something
> related
> > > to
> > > PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple
> > > concepts here that are not the same but that are somewhat related:
> > >
> > > a) keeping PCI devices from allocating low I/O ports on the PCI bus
> > > that would conflict with ISA devices behind a bridge of the
> > > same bus.
> > >
> > > b) reserving the low 0x0-0xfff range of the Linux-internal I/O
> > > space abstraction to a particular LPC or PCI domain to make
> > > legacy device drivers work that hardcode a particular port
> > > number.
> > >
> > > c) Redirecting inb/outb to call a domain-specific accessor function
> > > rather than doing the normal MMIO window for an LPC master or
> > > more generally any arbitrary LPC or PCI domain that has a
> > > nonstandard I/O space.
> > > [side note: actually if we generalized this, we could avoid
> > > assigning an MMIO range for the I/O space on the pci-mvebu
> > > driver, and that would help free up some other remapping
> > > windows]
> > >
> > > I think there is no need to change a) here, we have PCIBIOS_MIN_IO
> > > today and even if we don't need it, there is no obvious downside.
> > > I would also argue that we can ignore b) for the discussion of
> > > the HiSilicon LPC driver, we just need to assign some range
> > > of logical addresses to each domain.
> > >
> > > That means solving c) is the important problem here, and it
> > > shouldn't be so hard. We can do this either with a single
> > > special domain as in the v5 patch series, or by generalizing it
> > > so that any I/O space mapping gets looked up through the device
> > > pointer of the bus master.
> >
> > I am not very on the "generalized" multi-domain solution...
> > Currently the IO accessors prototypes have an unsigned long addr
> > as input parameter. If we live in a multi-domain IO system
> > how can we distinguish inside the accessor which domain addr
> > belongs to?
>
> The easiest change compared to the v5 code would be to walk
> a linked list of 'struct extio_ops' structures rather than
> assuming there is only ever one of them. I think one of the
> earlier versions actually did this.
Right but if my understanding is correct if we live in a multi-
domain I/O space world when you have an input addr in the I/O
accessors this addr can be duplicated (for example for the standard
PCI IO domain and for our special LPC domain).
So effectively even if you walk a linked list there is a problem
of disambiguation...am I right?
>
> Another option the IA64 approach mentioned in another subthread
> today, looking up the operations based on an index from the
> upper bits of the port number. If we do this, we probably
> want to do that for all PIO access and replace the entire
> virtual address remapping logic with that. I think Bjorn
> in the past argued in favor of such an approach, while I
> advocated the current scheme for simplicity based on how
> every I/O space these days is just memory mapped (which now
> turned out to be false, both on powerpc and arm64).
This seems really complex...I am a bit worried that possibly
we end up in having the maintainers saying that it is not worth
to re-invent the world just for this special LPC device...
To be honest with you I would keep things simple for this
LPC and introduce more complex reworks later if more devices
need to be introduced.
What if we stick on a single domain now where we introduce a
reserved threshold for the IO space (say INDIRECT_MAX_IO).
We define INDIRECT_MAX_IO as 0 in "include/linux/extio.h" and
we define INDIRECT_MAX_IO as 0x1000 in "arch/arm64/include/asm/io.h"
So effectively this threshold can change according to the
architecture and so far we only define it for ARM64 as we need
it for ARM64...
Thoughts?
Thanks again
Gab
>
> Arnd
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Russell King - ARM Linux @ 2016-11-18 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118120630.GJ13470@arm.com>
On Fri, Nov 18, 2016 at 12:06:30PM +0000, Will Deacon wrote:
> On Tue, Nov 15, 2016 at 02:36:33PM +0100, Mason wrote:
> > When polling a tick counter in a busy loop, one might sample the
> > counter just *before* it is updated, and then again just *after*
> > it is updated. In that case, while mathematically v2-v1 equals 1,
> > only epsilon has really passed.
> >
> > So, if a caller requests an N-cycle delay, we spin until v2-v1
> > is strictly greater than N to avoid these random corner cases.
> >
> > Signed-off-by: Mason <slash.tmp@free.fr>
> > ---
> > arch/arm/lib/delay.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> > index 69aad80a3af4..3f1cd15ca102 100644
> > --- a/arch/arm/lib/delay.c
> > +++ b/arch/arm/lib/delay.c
> > @@ -60,7 +60,7 @@ static void __timer_delay(unsigned long cycles)
> > {
> > cycles_t start = get_cycles();
> >
> > - while ((get_cycles() - start) < cycles)
> > + while ((get_cycles() - start) <= cycles)
> > cpu_relax();
> > }
>
> I thought a bit about this last night. It is well known that the delay
> routines are not guaranteed to be accurate, and I don't *think* that's
> limited to over-spinning, so arguably this isn't a bug. However, taking
> the approach that "drivers should figure it out" is also unhelpful,
> because the frequency of the underlying counter isn't generally known
> and so drivers can't simply adjust the delay parameter.
I don't think this change makes any sense whatsoever. udelay() is
inaccurate, period. It _will_ give delays shorter than requested
for many reasons, many of which can't be fixed.
Having a super-accurate version just encourages people to write broken
drivers which assume (eg) that udelay(10) will give _at least_ a 10us
delay. However, there is no such guarantee.
So, having udelay() for timers return slightly short is actually a good
thing - it causes people not to make the mistake to be soo accurate
with their delay specifications.
So, NAK on this change. udelay is not super-accurate.
Reference (and this is the most important one):
http://lists.openwall.net/linux-kernel/2011/01/12/372
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFT] ARM: dts: exynos: Fix invalid GIC interrupt flags in audio block of Exynos5410
From: Krzysztof Kozlowski @ 2016-11-18 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Recently added audio block of Exynos5410 missed global fixup of GIC
interrupt flags. Interrupt of type IRQ_TYPE_NONE is not allowed for GIC
interrupts so use level high.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos5410.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index bb90bbdbe2d9..2b6adafe18e2 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -203,7 +203,7 @@
pdma0: pdma at 12680000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
- interrupts = <GIC_SPI 34 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
@@ -214,7 +214,7 @@
pdma1: pdma at 12690000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
- interrupts = <GIC_SPI 35 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH] kirkwood: fix spelling mistake
From: Gregory CLEMENT @ 2016-11-18 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <trinity-6911950b-e19a-4b44-aeed-adaccbc33164-1479414587776@3capp-gmx-bs50>
Hi Paul,
On jeu., nov. 17 2016, p.wassi at gmx.at wrote:
> From: Paul Wassi <p.wassi@gmx.at>
>
> Fix a spelling mistake in arch/arm/boot/dts/kirkwood-topkick.dts
>
> Signed-off-by: Paul Wassi <p.wassi@gmx.at>
Applied on mvebu/dt.
I fix the title, as for patcj modifying the dts, the title should start
by "ARM: dts: ". I also added the comment from the email which add more
inforamtion that the original commit log.
Thanks,
Gregory
> ---
> The manufacturer's name is Univer*s*al Scientific Industrial...
> Compare with footer of page here:
> http://www.usish.com/english/products_topkick1281p2.php
>
> arch/arm/boot/dts/kirkwood-topkick.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -rupN a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
> --- a/arch/arm/boot/dts/kirkwood-topkick.dts
> +++ b/arch/arm/boot/dts/kirkwood-topkick.dts
> @@ -4,7 +4,7 @@
> #include "kirkwood-6282.dtsi"
>
> / {
> - model = "Univeral Scientific Industrial Co. Topkick-1281P2";
> + model = "Universal Scientific Industrial Co. Topkick-1281P2";
> compatible = "usi,topkick-1281P2", "usi,topkick", "marvell,kirkwood-88f6282", "marvell,kirkwood";
>
> memory {
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] kirkwood: fix spelling mistake
From: Gregory CLEMENT @ 2016-11-18 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <trinity-8590509b-8acc-44c0-86dc-8cf16ea8ad8a-1479448964051@3capp-gmx-bs34>
Hi Paul,
On ven., nov. 18 2016, p.wassi at gmx.at wrote:
> Hi Andrew,
>
>> You should also send the patch to the Marvell MVEBU
>> maintainers.
>
> how do I find Marvell mvebu maintainers?
> The list in
> https://www.kernel.org/doc/linux/MAINTAINERS
> (line 1429) references mvebu/kirkwood and gave me the
> mailing list's address. Should the other two maintainers
> be addressed directly?
About putting the maintainer in Cc. Using ./scripts/get_maintainer.pl
coudl help you to find the people to put in CC. For example for your
patch:
Jason Cooper <jason@lakedaemon.net> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Andrew Lunn <andrew@lunn.ch> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Gregory Clement <gregory.clement@free-electrons.com> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
So indeed you should put the 4 co-maintainers in Cc.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Thomas Gleixner @ 2016-11-18 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118120453.GI13470@arm.com>
On Fri, 18 Nov 2016, Will Deacon wrote:
> On Thu, Nov 17, 2016 at 07:35:36PM +0100, Sebastian Andrzej Siewior wrote:
> > Install the callbacks via the state machine and let the core invoke
> > the callbacks on the already online CPUs.
> >
> > smp_call_function_single() has been removed because the function is already
> > invoked on the target CPU.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > arch/arm/kernel/hw_breakpoint.c | 44 ++++++++++++++++++-----------------------
> > 1 file changed, 19 insertions(+), 25 deletions(-)
>
> [...]
>
> > static int __init arch_hw_breakpoint_init(void)
> > {
> > + int ret;
> > +
> > debug_arch = get_debug_arch();
> >
> > if (!debug_arch_supported()) {
> > @@ -1072,8 +1069,6 @@ static int __init arch_hw_breakpoint_init(void)
> > core_num_brps = get_num_brps();
> > core_num_wrps = get_num_wrps();
> >
> > - cpu_notifier_register_begin();
> > -
> > /*
> > * We need to tread carefully here because DBGSWENABLE may be
> > * driven low on this core and there isn't an architected way to
> > @@ -1082,15 +1077,18 @@ static int __init arch_hw_breakpoint_init(void)
> > register_undef_hook(&debug_reg_hook);
> >
> > /*
> > - * Reset the breakpoint resources. We assume that a halting
> > - * debugger will leave the world in a nice state for us.
> > + * Register CPU notifier which resets the breakpoint resources. We
> > + * assume that a halting debugger will leave the world in a nice state
> > + * for us.
> > */
> > - on_each_cpu(reset_ctrl_regs, NULL, 1);
> > + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm/hw_breakpoint:online",
> > + dbg_reset_online, NULL);
>
> I'm slightly unsure about this. The dbg_reset_online callback can execute
> undefined instructions (unfortunately, there's no way to probe the presence
> of some of the debug registers), so it absolutely has to run within the
> register_undef_hook/unregister_undef_hook calls that are in this function.
>
> With this patch, I worry that the callback can be postponed to ONLINE time
> for other CPUs, and then the kernel will panic.
No. The flow is the following:
register_undef_hook(&debug_reg_hook);
ret = cpuhp_setup_state(.., dbg_reset_online, NULL);
{
for_each_online_cpu(cpu) {
ret = call_on_cpu(cpu, dbg_reset_online);
if (ret)
return ret:
}
}
unregister_undef_hook(&debug_reg_hook);
The only difference to the current code is that the call is not invoked via
a smp function call (on_each_cpu), it's pushed to the hotplug thread
context of each cpu and executed there.
But it's guaranteed that cpuhp_setup_state() will not return before the
callback has been invoked on each online cpu.
If cpus are not yet online when that code is invoked, then it's the same
behaviour as before. It will be invoked when the cpu comes online.
Thanks,
tglx
^ permalink raw reply
* [RESEND PATCH] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Bruno Herrera @ 2016-11-18 13:13 UTC (permalink / raw)
To: linux-arm-kernel
Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
case boot-loader does not configure/initialize the pins.
This patch adds USART3 pin configuration on PB10/PA11 pins
for STM32F469I-DISCO board.
Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 35df462..1d94eba 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -284,6 +284,19 @@
};
};
+ usart3_pins_a: usart3 at 0 {
+ pins1 {
+ pinmux =
<STM32F429_PB10_FUNC_USART3_TX>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux =
<STM32F429_PB11_FUNC_USART3_RX>;
+ bias-disable;
+ };
+ };
+
usbotg_hs_pins_a: usbotg_hs at 0 {
pins {
pinmux =
<STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
b/arch/arm/boot/dts/stm32f469-disco.dts
index e911af8..eb3e638 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -71,5 +71,7 @@
};
&usart3 {
+ pinctrl-0 = <&usart3_pins_a>;
+ pinctrl-names = "default";
status = "okay";
};
--
2.7.4 (Apple Git-66)
^ permalink raw reply related
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Lee Jones @ 2016-11-18 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479453418-25314-1-git-send-email-krzk@kernel.org>
On Fri, 18 Nov 2016, Krzysztof Kozlowski wrote:
> All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
> 200 Hz. Unfortunately in case of multiplatform image this affects also
> other platforms when Exynos is enabled.
>
> This looks like an very old legacy code, dating back to initial
> upstreaming of S3C24xx. Probably it was required for s3c24xx timer
> driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
> unused plat-samsung/time.c").
>
> Since then, this fixed 200 Hz spread everywhere, including out-of-tree
> Samsung kernels (SoC vendor's and Tizen's). I believe this choice
> was rather an effect of coincidence instead of conscious choice.
>
> Exynos uses its own MCT or arch timer and can work with all HZ values.
> Older platforms use newer Samsung PWM timer driver which should handle
> down to 100 Hz.
>
> Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
> A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
> other values.
>
> Reported-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
> [Dropping 200_HZ from S3C/S5P suggested by Arnd]
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Tested on Exynos5422 and Exynos5800 (by Javier). It would be
> appreciated if anyone could test it on S3C24xx or S5PV210.
>
> Changes since v1:
> 1. Add Javier's tested-by.
> 2. Drop HZ_FIXED also from ARCH_S5PV210 and ARCH_S3C24XX after Arnd
> suggestions and analysis.
> ---
> arch/arm/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5d529fdffab..ced2e08a9d08 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1496,8 +1496,7 @@ source kernel/Kconfig.preempt
>
> config HZ_FIXED
> int
> - default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
> - ARCH_S5PV210 || ARCH_EXYNOS4
> + default 200 if ARCH_EBSA110
> default 128 if SOC_AT91RM9200
> default 0
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] clk: sunxi-ng: enable so-said LDOs for A33 SoC's pll-mipi clock
From: Chen-Yu Tsai @ 2016-11-18 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117164954.62658-1-icenowy@aosc.xyz>
On Fri, Nov 18, 2016 at 12:49 AM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> In the user manual of A33 SoC, the bit 22 and 23 of pll-mipi control
> register is called "LDO{1,2}_EN", and according to the BSP source code
> from Allwinner [1], the LDOs are enabled during the clock's enabling
> process.
>
> The clock failed to generate output if the two LDOs are not enabled.
>
> Add the two bits to the clock's gate bits, so that the LDOs are enabled
> when the PLL is enabled.
>
> [1] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c#L429
>
> Fixes: d05c748bd730 ("clk: sunxi-ng: Add A33 CCU support")
>
You don't need the extra line.
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Dear Chen-Yu:
> As you said, the two bits are also present in the CCU of A23 and A31.
> Could you please check whether the PLL works on the two SoCs?
> I remembered you mentioned you failed to make TCON enabled on A23.
> On A31, you may hack the parent of tcon-ch0 to force the tcon clock to
> use pll-mipi as parent, in order to check whether the pll works.
>
> However, I didn't found the code that enables the LDOs in the BSP A23/31
> sources, so you must test them to ensure whether the code is needed for
> these SoCs.
I tested out this for both the A31 and the A23. It fixes issues I've
had with DRM. I'll send patches for them.
ChenYu
> Regards,
> Icenowy
> drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
> index 96b40ca..9bd1f78 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
> @@ -131,7 +131,7 @@ static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_mipi_clk, "pll-mipi",
> 8, 4, /* N */
> 4, 2, /* K */
> 0, 4, /* M */
> - BIT(31), /* gate */
> + BIT(31) | BIT(23) | BIT(22), /* gate */
> BIT(28), /* lock */
> CLK_SET_RATE_UNGATE);
>
> --
> 2.10.1
>
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Michal Simek @ 2016-11-18 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582EF744.8090307@free.fr>
On 18.11.2016 13:42, Mason wrote:
> On 18/11/2016 11:49, Rameshwar Sahu wrote:
>
>> Mason wrote:
>>
>>> Suman/APM added "arasan,sdhci-4.9a" in 308f3f8d8112
>>> @Suman, @Rameshwar: what specific IP block does your SoC embed?
>>> What does 4.9a refer to? The documentation revision number?
>>
>> We have Arasan SD3.0/ SDIO3.0/ eMMC4.41 AHB Host Controller IP
>> embedded in our SoC and 4.9a is documentation revision number which
>> was given by Arasan.
>> FYI this documentation date was May, 2012.
>
> Hello Ram,
>
> Thanks for the information.
>
> Xilinx is using "SD2.0/SDIO2.0/MMC3.31 AHB Host Controller"
in Xilinx Zynq device
and
Xilinx ZynqMP device is using
"SD3.0/SDIO3.0/eMMC4.51 AHB Host Controller"
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: add support for Turris Omnia
From: Gregory CLEMENT @ 2016-11-18 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110135721.13098-2-uwe@kleine-koenig.org>
Hi Uwe, Andrew,
On jeu., nov. 10 2016, Uwe Kleine-K?nig <uwe@kleine-koenig.org> wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
What is the status for this patch?
I see that there is still email about the RFC version.
Thanks,
Gregory
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
> Compared to the (implict) v1, the following was changed:
>
> - disable rtc
> - change compatible to cznic,turris-omnia
>
> The following components are working:
>
> - WAN port
> - eMMC
> - UART0
> - USB
> - mSATA
>
> Wireless fails to probe, didn't debug this up to now.
> I already see the DSA devices (with an additional change not included here),
> but sending and receiving doesn't work yet.
>
> SFP is missing as I cannot test it. UART1 is untested, but I'd be
> surprised if it didn't work.
>
> IMHO it makes sense to add the current state and fix the remaining stuff
> incrementally.
>
> Best regards
> Uwe
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-385-turris-omnia.dts | 257 ++++++++++++++++++++++++++
> 2 files changed, 258 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd2619902..f1d3b9ff257e 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
> armada-385-db-ap.dtb \
> armada-385-linksys-caiman.dtb \
> armada-385-linksys-cobra.dtb \
> + armada-385-turris-omnia.dtb \
> armada-388-clearfog.dtb \
> armada-388-db.dtb \
> armada-388-gp.dtb \
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 000000000000..28e45d816120
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,257 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
> + *
> + * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "armada-385.dtsi"
> +
> +/ {
> + model = "Turris Omnia";
> + compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
> +
> + chosen {
> + stdout-path = &uart0;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>; /* 1024 MB */
> + };
> +
> + soc {
> + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> + MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> +
> + internal-regs {
> +
> + /* USB part of the eSATA/USB 2.0 port */
> + usb at 58000 {
> + status = "okay";
> + };
> +
> + rtc at a3800 {
> + /*
> + * There are several errata for this device
> + * still unimplemented. Without some love it only reports
> + * 2016-12-19 22:00:24. So disable for now.
> + */
> + status = "disabled";
> + };
> +
> + sata at a8000 {
> + status = "okay";
> + };
> +
> + sdhci at d8000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdhci_pins>;
> + status = "okay";
> +
> + bus-width = <8>;
> + no-1-8-v;
> + non-removable;
> + };
> +
> + usb3 at f0000 {
> + status = "okay";
> + };
> +
> + usb3 at f8000 {
> + status = "okay";
> + };
> + };
> +
> + pcie-controller {
> + status = "okay";
> +
> + pcie at 1,0 {
> + /* Port 0, Lane 0 */
> + status = "okay";
> + };
> +
> + pcie at 2,0 {
> + /* Port 2, Lane 0 */
> + status = "okay";
> + };
> +
> + pcie at 3,0 {
> + /* Port 3, Lane 0 */
> + status = "okay";
> + };
> + };
> + };
> +};
> +
> +ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge0_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +ð1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge1_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +/* WAN port */
> +ð2 {
> + status = "okay";
> + phy-mode = "sgmii";
> + phy = <&phy1>;
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> + status = "okay";
> +
> + i2cmux at 70 {
> + compatible = "nxp,pca9547";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> + status = "okay";
> +
> + i2c at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + status = "okay";
> +
> + /* STM32F0 at address 0x2a */
> + /* leds device at address 0x2b */
> +
> + eeprom at 54 {
> + /* holds configuration about RAM, evaluated by bootloader */
> + compatible = "at,24c64";
> + reg = <0x54>;
> + };
> + };
> +
> + i2c at 5 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <5>;
> +
> + /* ATSHA204A at address 0x64 */
> + };
> +
> + i2c at 6 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <6>;
> +
> + /* exposed on pin header */
> + };
> + };
> +};
> +
> +&mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio_pins>;
> + status = "okay";
> +
> + phy1: phy at 1 {
> + status = "okay";
> + compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +
> + /* There is a Switch (MV88E7176) at address 0x10 */
> +};
> +
> +&pinctrl {
> + spi0cs1_pins: spi0-pins-0cs1 {
> + marvell,pins = "mpp26";
> + marvell,function = "spi0";
> + };
> +};
> +
> +&spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
> + status = "okay";
> +
> + spi-nor at 0 {
> + compatible = "spansion,s25fl164k", "jedec,spi-nor";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0>;
> + spi-max-frequency = <40000000>;
> +
> + partition at 0 {
> + reg = <0x0 0x00100000>;
> + label = "U-Boot";
> + };
> +
> + partition at 1 {
> + reg = <0x00100000 0x00700000>;
> + label = "Rescue system";
> + };
> + };
> +
> + /* @1 is on pin header */
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins>;
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins>;
> + status = "okay";
> +};
> --
> 2.10.2
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Will Deacon @ 2016-11-18 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611181401180.3615@nanos>
On Fri, Nov 18, 2016 at 02:11:58PM +0100, Thomas Gleixner wrote:
> On Fri, 18 Nov 2016, Will Deacon wrote:
> > On Thu, Nov 17, 2016 at 07:35:36PM +0100, Sebastian Andrzej Siewior wrote:
> > > @@ -1082,15 +1077,18 @@ static int __init arch_hw_breakpoint_init(void)
> > > register_undef_hook(&debug_reg_hook);
> > >
> > > /*
> > > - * Reset the breakpoint resources. We assume that a halting
> > > - * debugger will leave the world in a nice state for us.
> > > + * Register CPU notifier which resets the breakpoint resources. We
> > > + * assume that a halting debugger will leave the world in a nice state
> > > + * for us.
> > > */
> > > - on_each_cpu(reset_ctrl_regs, NULL, 1);
> > > + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm/hw_breakpoint:online",
> > > + dbg_reset_online, NULL);
> >
> > I'm slightly unsure about this. The dbg_reset_online callback can execute
> > undefined instructions (unfortunately, there's no way to probe the presence
> > of some of the debug registers), so it absolutely has to run within the
> > register_undef_hook/unregister_undef_hook calls that are in this function.
> >
> > With this patch, I worry that the callback can be postponed to ONLINE time
> > for other CPUs, and then the kernel will panic.
>
> No. The flow is the following:
>
> register_undef_hook(&debug_reg_hook);
>
> ret = cpuhp_setup_state(.., dbg_reset_online, NULL);
> {
> for_each_online_cpu(cpu) {
> ret = call_on_cpu(cpu, dbg_reset_online);
> if (ret)
> return ret:
> }
> }
>
> unregister_undef_hook(&debug_reg_hook);
>
> The only difference to the current code is that the call is not invoked via
> a smp function call (on_each_cpu), it's pushed to the hotplug thread
> context of each cpu and executed there.
>
> But it's guaranteed that cpuhp_setup_state() will not return before the
> callback has been invoked on each online cpu.
Ok, that's good.
> If cpus are not yet online when that code is invoked, then it's the same
> behaviour as before. It will be invoked when the cpu comes online.
Just to check, but what stops a CPU from coming online between the call
to cpuhp_setup_state and the call to cpuhp_remove_state_nocalls in the
case of failure (debug_err_mask isn't empty)?
Will
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Arnd Bergmann @ 2016-11-18 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118124805.GJ1041@n2100.armlinux.org.uk>
On Friday, November 18, 2016 12:48:07 PM CET Russell King - ARM Linux wrote:
> On Fri, Nov 18, 2016 at 01:14:35PM +0100, Arnd Bergmann wrote:
> > @@ -41,6 +43,9 @@ void scu_enable(void __iomem *scu_base)
> > {
> > u32 scu_ctrl;
> >
> > + if (scu_base)
> > + scu_base = scu_base_addr;
> > +
>
> This looks to me like nonsense.
>
> > #ifdef CONFIG_ARM_ERRATA_764369
> > /* Cortex-A9 only */
> > if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
> > @@ -85,6 +90,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> > unsigned int val;
> > int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
> >
> > + if (scu_base)
> > + scu_base = scu_base_addr;
> > +
>
> Ditto.
>
> Rather than doing this, I'd much prefer to always store the SCU base in
> the SCU code, and remove the "void __iomem *scu_base" argment from all
> these functions.
Ok, then we just need one scu_probe_*() variant for each of the
four methods of initializing it (iotable, of_iomap,
ioremap(scu_a9_get_base) and hardcoded.
The intention of doing the fallback for the NULL argument was
to avoid having to add lots of new API while also allowing
the change to be done one platform at a time.
If we remove the argument from the other functions, they either
need to get a new name, or we change them all to the new prototype
at once. Either way works fine, do you have a preference between
them?
Arnd
^ permalink raw reply
* [RFC 1/6] drm/etnaviv: add binding for the gc320 found in ti socs
From: Lucas Stach @ 2016-11-18 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118121340.GC23750@n2100.armlinux.org.uk>
Am Freitag, den 18.11.2016, 12:13 +0000 schrieb Russell King - ARM
Linux:
> On Thu, Nov 17, 2016 at 08:53:38PM -0600, Nishanth Menon wrote:
> > >diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > >index a6799b0..ce51270 100644
> > >--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > >+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > >@@ -653,6 +653,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
> > > static const struct of_device_id dt_match[] = {
> > > { .compatible = "fsl,imx-gpu-subsystem" },
> > > { .compatible = "marvell,dove-gpu-subsystem" },
> > >+ { .compatible = "ti,gc320-gpu-subsystem" },
>
> We need to get away from this ever-increasing set of compatible
> strings here, as this is not long-term maintainable.
>
> What we should have is a common compatible which describes that
> the node is compatible with this driver, and then use SoC specific
> compatible strings later if we need to (eg, because of some GPU
> subsystem SoC specifics.)
>
> So, I'd suggest that we update the documentation and add:
>
> "vivante,gc-gpu-subsystem"
>
> as a common compatible now, and if necessary move on to more specific
> compatibles if we need to later.
>
> Also, I'd strongly suggest that no compatibles should contain the ID
> number of the GPU core for exactly the same reason - Vivante GPU cores
> vary according to features, and we don't want to end up with a long
> list of specific compatibles (eg)
> "ti,gc2000-and-gc320-and-gc355-gpu-subsystem" because TI
> decides to integrate a 3d, 2d and VG core.
>
All of the above sounds sensible and I would prefer if the patches are
reworked to take those things into account.
Regards,
Lucas
^ permalink raw reply
* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Thomas Petazzoni @ 2016-11-18 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737ipat6u.fsf@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 13:06:17 +0100, Gregory CLEMENT wrote:
> > But do we really want this comment above each node? Couldn't we instead
> > add this explanation in the mvebu-mbus.txt DT binding?
>
> We could but I fear that nobody will read it.
>
> Indeed if you know that in order to understand the unit address, you will
> have to have a look an the binding of the mvebu-mbus, then it means that
> you already are an expert and actually you barely need to read it!
Well, you anyway need to read the DT binding if you want to add more
nodes that use this magic MBUS_ID() thing, so I believe it makes sense
to have this comment in the binding documentation.
> In order to have less change we could at least put it near the MBUS_ID
> macro and if the mvebu-mbus.txt DT binding too.
Fine with that.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877f81b013.fsf@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 10:38:32 +0100, Gregory CLEMENT wrote:
> >> > unit address? It doesn't have a 'reg' property if I remember
> >> > correctly.
> >>
> >> But it has a range property.
> >
> > And? There are multiple ranges, and you randomly took the first one for
> > the unit address of the soc node?
>
> Not randomly I followed the same rules that for the regs mentioned in
> the ePAPR paragraph 2.2.1.1:
>
> "The unit-address should match the first address specified in the reg
> property of the node."
But it doesn't say anything about the ranges property. Isn't the dtc
warning in fact over-zealous? The ePAPR says that the unit address
should be the first address of the reg property, but doesn't say
anything about the ranges property.
What I dislike is that there absolutely nothing that forces the ranges
to be written in this order. In another board, it can be written in a
completely different order, which means that the unit address would be
different, which is really silly.
I continue to believe this rule doesn't make sense, and the soc node
shouldn't have a unit address. Maybe Rob or Mark (who is not in Cc, for
some reason?) should say a word about this?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Thomas Gleixner @ 2016-11-18 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118132912.GM13470@arm.com>
On Fri, 18 Nov 2016, Will Deacon wrote:
> On Fri, Nov 18, 2016 at 02:11:58PM +0100, Thomas Gleixner wrote:
> > But it's guaranteed that cpuhp_setup_state() will not return before the
> > callback has been invoked on each online cpu.
>
> Ok, that's good.
>
> > If cpus are not yet online when that code is invoked, then it's the same
> > behaviour as before. It will be invoked when the cpu comes online.
>
> Just to check, but what stops a CPU from coming online between the call
> to cpuhp_setup_state and the call to cpuhp_remove_state_nocalls in the
> case of failure (debug_err_mask isn't empty)?
Indeed! I missed that part. So we still need a get/put_online_cpus()
protection around all of this.
Just for curiosity sake. Wouldn't it be simpler and less error prone to
make the ARM_DBG_READ/WRITE macros use the exception table and handle that
in the undefined instruction handler to avoid this hook dance?
Thanks,
tglx
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-18 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F921283@lhreml507-mbx>
On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni wrote:
> > > > I think there is no need to change a) here, we have PCIBIOS_MIN_IO
> > > > today and even if we don't need it, there is no obvious downside.
> > > > I would also argue that we can ignore b) for the discussion of
> > > > the HiSilicon LPC driver, we just need to assign some range
> > > > of logical addresses to each domain.
> > > >
> > > > That means solving c) is the important problem here, and it
> > > > shouldn't be so hard. We can do this either with a single
> > > > special domain as in the v5 patch series, or by generalizing it
> > > > so that any I/O space mapping gets looked up through the device
> > > > pointer of the bus master.
> > >
> > > I am not very on the "generalized" multi-domain solution...
> > > Currently the IO accessors prototypes have an unsigned long addr
> > > as input parameter. If we live in a multi-domain IO system
> > > how can we distinguish inside the accessor which domain addr
> > > belongs to?
> >
> > The easiest change compared to the v5 code would be to walk
> > a linked list of 'struct extio_ops' structures rather than
> > assuming there is only ever one of them. I think one of the
> > earlier versions actually did this.
>
> Right but if my understanding is correct if we live in a multi-
> domain I/O space world when you have an input addr in the I/O
> accessors this addr can be duplicated (for example for the standard
> PCI IO domain and for our special LPC domain).
> So effectively even if you walk a linked list there is a problem
> of disambiguation...am I right?
No, unlike the PCI memory space, the PIO addresses are not
usually distinct, i.e. every PCI bus has its own 64K I/O
addresses starting at zero. We linearize them into the
Linux I/O space using the per-domain io_offset value.
For the ISA/LPC spaces there are only 4k of addresses, they
the bus addresses always overlap, but we can trivially
figure out the bus address from Linux I/O port number
by subtracting the start of the range.
> > Another option the IA64 approach mentioned in another subthread
> > today, looking up the operations based on an index from the
> > upper bits of the port number. If we do this, we probably
> > want to do that for all PIO access and replace the entire
> > virtual address remapping logic with that. I think Bjorn
> > in the past argued in favor of such an approach, while I
> > advocated the current scheme for simplicity based on how
> > every I/O space these days is just memory mapped (which now
> > turned out to be false, both on powerpc and arm64).
>
> This seems really complex...I am a bit worried that possibly
> we end up in having the maintainers saying that it is not worth
> to re-invent the world just for this special LPC device...
It would clearly be a rather invasive change, but the
end-result isn't necessarily more complex than what we
have today, as we'd kill off the crazy pci_pio_to_address()
and pci_address_to_pio() hacks in address translation.
> To be honest with you I would keep things simple for this
> LPC and introduce more complex reworks later if more devices
> need to be introduced.
>
> What if we stick on a single domain now where we introduce a
> reserved threshold for the IO space (say INDIRECT_MAX_IO).
I said having a single domain is fine, but I still don't
like the idea of reserving low port numbers for this hack,
it would mean that the numbers change for everyone else.
> We define INDIRECT_MAX_IO as 0 in "include/linux/extio.h" and
> we define INDIRECT_MAX_IO as 0x1000 in "arch/arm64/include/asm/io.h"
>
> So effectively this threshold can change according to the
> architecture and so far we only define it for ARM64 as we need
> it for ARM64...
I liked the idea of having it done in asm-generic/io.h (in an ifdef)
and lib/*.c under an as someone suggested earlier. There is nothing
ARM64 specific in the implementation.
Arnd
^ 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