* Re: [PATCH v1 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count
From: Geert Uytterhoeven @ 2019-09-17 12:52 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Rowand, Joerg Roedel, Linux Kernel Mailing List,
Linux-Renesas, Wolfram Sang, Linux IOMMU,
linux-mediatek@lists.infradead.org, Linux I2C, Sascha Hauer,
Matthias Brugger, Will Deacon, Peter Rosin, Linux ARM,
Robin Murphy
In-Reply-To: <20190917122530.3xy7sut3xdvzlomj@pengutronix.de>
Hi Uwe,
On Tue, Sep 17, 2019 at 2:25 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Tue, Sep 17, 2019 at 11:25:46AM +0000, Peter Rosin wrote:
> > On 2019-09-17 12:13, Uwe Kleine-König wrote:
> > > On Tue, Sep 17, 2019 at 11:40:25AM +0200, Geert Uytterhoeven wrote:
> > >> On Fri, Sep 13, 2019 at 11:58 PM Rob Herring <robh@kernel.org> wrote:
> > >>> On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= wrote:
> > >>>> Referencing device tree nodes from a property allows to pass arguments.
> > >>>> This is for example used for referencing gpios. This looks as follows:
> > >>>>
> > >>>> gpio_ctrl: gpio-controller {
> > >>>> #gpio-cells = <2>
> > >>>> ...
> > >>>> }
> > >>>>
> > >>>> someothernode {
> > >>>> gpios = <&gpio_ctrl 5 0 &gpio_ctrl 3 0>;
> > >>>> ...
> > >>>> }
> > >>>>
> > >>>> To know the number of arguments this must be either fixed, or the
> > >>>> referenced node is checked for a $cells_name (here: "#gpio-cells")
> > >>>> property and with this information the start of the second reference can
> > >>>> be determined.
> > >>>>
> > >>>> Currently regulators are referenced with no additional arguments. To
> > >>>> allow some optional arguments without having to change all referenced
> > >>>> nodes this change introduces a way to specify a default cell_count. So
> > >>>> when a phandle is parsed we check for the $cells_name property and use
> > >>>> it as before if present. If it is not present we fall back to
> > >>>> cells_count if non-negative and only fail if cells_count is smaller than
> > >>>> zero.
> > >>>>
> > >>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > >>
> > >> This is now commit e42ee61017f58cd9 ("of: Let of_for_each_phandle fallback
> > >> to non-negative cell_count") in robh/for-next, which causes a lock-up when
> > >> booting a shmobile_defconfig kernel on r8a7791/koelsch:
> > >>
> > >> rcu: INFO: rcu_sched self-detected stall on CPU
> Oh yeah, you're right. I'm a bit disappointed that I didn't spot this
> myself :-|
>
> Untested patch to fix this problem:
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 2f25d2dfecfa..26f7a21d7187 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1284,6 +1284,13 @@ int of_phandle_iterator_init(struct of_phandle_iterator *it,
> const __be32 *list;
> int size;
>
> + /*
> + * one of cell_count or cells_name must be provided to determine the
> + * argument length.
> + */
> + if (cell_count < 0 && !cells_name)
> + return -EINVAL;
> +
> memset(it, 0, sizeof(*it));
>
> list = of_get_property(np, list_name, &size);
> @@ -1765,6 +1772,18 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
> struct of_phandle_iterator it;
> int rc, cur_index = 0;
>
> + /* If cells_name is NULL we assume an cell_count of 0 */
a cell count
> + if (cells_name == NULL) {
> + const __be32 *list;
> + int size;
> +
> + list = of_get_property(np, list_name, &size);
> + if (!list)
> + return -ENOENT;
> +
> + return size / sizeof(*list);
> + }
> +
> rc = of_phandle_iterator_init(&it, np, list_name, cells_name, -1);
> if (rc)
> return rc;
Thanks, that fixes the boot for me!
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Andrew Lunn @ 2019-09-17 12:54 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Baruch Siach, Fabio Estevam, Sascha Hauer, Russell King,
open list, Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
Shawn Guo, linux-arm-kernel
In-Reply-To: <20190917124101.GA1200564@arch-dsk-01>
On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > Tinywrkb confirmed to me in private communication that revert of
> > > 5502b218e001 fixes Ethernet for him on effected system.
> > >
> > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > AR8035 PHY that supports 1Gb.
> > >
> > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > the moment.
> >
> > Could somebody with an affected device show us the output of ethtool
> > with and without 5502b218e001. Does one show 1G has been negotiated,
> > and the other 100Mbps? If this is true, how does it get 100Mbps
> > without that patch? We are missing a piece of the puzzle.
> >
> > Andrew
>
> linux-test-5.1rc1-a2703de70942-without_bad_commit
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
So this means the local device says it can do 1000Mbps.
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
The link peer can also do 1000Mbps.
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 100Mb/s
Yet they have decided to do 100Mbps.
We need to understand Why? The generic PHY driver would not do this on
its own. So i'm thinking something has poked a PHY register with some
value, and this patch is causing it to be over written.
Please can you use mii-tool -v -v to dump the PHY registers in each
case.
Thanks
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Robin Murphy @ 2019-09-17 13:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Adrian Hunter, Will Deacon
Cc: linux-mmc, Linux ARM
In-Reply-To: <20190917123326.GN25745@shell.armlinux.org.uk>
On 17/09/2019 13:33, Russell King - ARM Linux admin wrote:
[...]
> Further debug shows:
>
> coherent=0 - sdhci device is not cache coherent
> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
> [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
> pmd=000000237fffb003, pte=00e800236d62270f
>
> The mapping for the ADMA table seems to be using MAIR index 3, which is
> MT_MEMORY_NC, so should be non-cacheable.
>
> vmallocinfo:
> 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
> user
>
> So this memory has been remapped. Could there be an alias that has
> cache lines still in the cache for the physical address, and could we
> be hitting those cache lines while accessing through a non-cacheable
> mapping? (On 32-bit ARM, this is "unpredictable" and this problem
> definitely _feels_ like it has unpredictable attributes!)
>
> Also, given that this memory is mapped NC, then surely
> __dma_flush_area() should have no effect? However, it _does_ have the
> effect of reliably solving the problem, which to me implies that there
> _are_ cache lines in this NC mapping.
The non-cacheable mapping of the descriptor table will still have its
cacheable linear map alias, so it's quite likely that the invalidate
aspect of __dma_flush_area(), rather than the clean, is what's making
the difference - if using __dma_clean_area() instead doesn't help, it
would more or less confirm that.
One possibility in that case is that you might actually have the rare
backwards coherency problem - if the device *is* actually snooping the
cache, then it could hit lines which were speculatively prefetched via
the cacheable alias before the descriptors were fully written, rather
than the up-to-date data which went straight to RAM via the NC mapping.
I'd try declaring the device as "dma-coherent" to see if that's actually
true (and it should become pretty obvious if it isn't).
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 0/6] ARM, arm64: Remove arm_pm_restart()
From: Guenter Roeck @ 2019-09-17 13:06 UTC (permalink / raw)
To: Arnd Bergmann, Thierry Reding; +Cc: linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <CAK8P3a2y9OYL-pm38rcGvgzvjgErCUC1ckjVXhd3mb=YEXiD_g@mail.gmail.com>
On 9/17/19 12:01 AM, Arnd Bergmann wrote:
> On Mon, Sep 16, 2019 at 10:28 PM Thierry Reding
> <thierry.reding@gmail.com> wrote:
>>
>> All of the patches beyond the 6 in this set rely on the system reset and
>> power "framework". I don't think there was broad concensus on that idea
>> yet.
>
> Ok, I see.
>
>> If you think it's worth another try I'm happy to send the patches
>> out again.
>
> Maybe do that after we pull the first set into arm-soc then. If
> we can reach consensus, I can merge them as a follow-up,
> either through the soc tree as a new subsystem or through
> the asm-generic tree as cross-architecture work.
>
I'd suggest to keep the two patch sets separate, though, and apply
the 6 system reset patches either way.
Thanks,
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 13:07 UTC (permalink / raw)
To: Adrian Hunter, Will Deacon, Nicolin Chen, dann frazier,
Christoph Hellwig
Cc: linux-mmc, Linux ARM
In-Reply-To: <20190917123326.GN25745@shell.armlinux.org.uk>
On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
> > > On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
> > > > On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
> > > > > On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
> > > > > > On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
> > > > > >
> > > > > > > The platform has an iommu, which is in pass-through mode, via
> > > > > > > arm_smmu.disable_bypass=0.
> > > > > >
> > > > > > Could be 954a03be033c7cef80ddc232e7cbdb17df735663
> > > > > > "iommu/arm-smmu: Break insecure users by disabling bypass by default"
> > > > > >
> > > > > > Although it had already landed in v5.2
> > > > >
> > > > > It is not - and the two lines that you quoted above are sufficient
> > > > > to negate that as a cause. (Please read the help for the option that
> > > > > the commit referrs to.)
> > > > >
> > > > > In fact, with bypass disabled, the SoC fails due to other masters.
> > > > > That's already been discussed privately between myself and Will
> > > > > Deacon.
> > > > >
> > > > > arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
> > > > > the default setting in the Kconfig.
> > > >
> > > > Adding some further debugging, and fixing the existing ADMA debugging
> > > > shows:
> > > >
> > > > mmc0: ADMA error: 0x02000000
> > > >
> > > > So this is an ADMA error without the transfer having completed.
> > > >
> > > > mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> > > >
> > > > The block size is 8, with one block.
> > > >
> > > > mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
> > > >
> > > > The ADMA error is a descriptor error at address 0x000000236df1d20c.
> > > > The descriptor table contains (including the following entry):
> > > >
> > > > mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
> > > > mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
> > > >
> > > > The descriptor table contains one descriptor of 8 bytes, is marked
> > > > as the last (END bit set) and is at DMA address 0x236df1d200. The
> > > > following descriptor is empty, with VALID=0.
> > > >
> > > > One may be tempted to blame it on the following descriptor, but having
> > > > had another example on eMMC while userspace was booting (rootfs on
> > > > eMMC):
> > > >
> > > > mmc1: ADMA error: 0x02000000
> > > > mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
> > > > mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
> > > > mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
> > > > mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
> > > > mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
> > > >
> > > > ... which is interesting for several reasons:
> > > > - The ADMA error register indicates a length mismatch error. The
> > > > transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
> > > > Summing the ADMA lengths up to the last descriptor (length=0 is
> > > > 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
> > > > bytes than the requested transfer.
> > > >
> > > > - The ADMA error register indicates ST_CADR, which is described as
> > > > "This state is never set because do not generate ADMA error in this
> > > > state."
> > > >
> > > > - The error descriptor is again after the descriptor with END=1, but
> > > > this time has VALID=1.
> > > >
> > > > This _feels_ like a coherency issue, where the SDHCI engine is not
> > > > correctly seeing the descriptor table, but then I would have expected
> > > > userspace (which is basically debian stable) to fail to boot every
> > > > time given that its rootfs is on eMMC.
> > > >
> > > > The other weird thing is if I wind the core MMC code back via:
> > > >
> > > > $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
> > > >
> > > > and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
> > > > completely stable, but way better than plain v5.3. I don't see
> > > > much in that diff which would be responsible for this - although it
> > > > does seem that hch's DMA changes do make the problem more likely.
> > > > (going from 1 in 3 boots with a problem to being not able to boot.)
> > > >
> > > > Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
> > > > bypass mode on the IOMMU (but then I saw global smmu errors right
> > > > from when the IOMMU had bypass disabled before MMC was probed - the
> > > > reason being is the SoC is not currently setup to have the MMU
> > > > bypass mode disabled.)
> > >
> > > This looks like an ARM64 coherency issue.
> > >
> > > I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
> > > which had no effect. I then tried adding:
> > >
> > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > + dma_wmb();
> > >
> > > and so far I haven't had any further ADMA errors. Adding Will Deacon
> > > to the thread.
> >
> > These are the changes to sdhci that I'm currently running. I think
> > some of the debugging related changes are probably worth adding to
> > the driver, particularly printing the intmask on ADMA error (which
> > is not printed by the register dump, as the value is lost) and printing
> > the DMA addresses of the descriptor table entries which can be tied
> > up with the DMA address error register. Also, maybe printing the
> > DMA descriptor table with the register dump, rather than having to
> > resort to enabling debug would be a good idea?
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index a5dc5aae973e..884dcaa9cad5 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
> > /* Add a terminating entry - nop, end, valid */
> > __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
> > }
> > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > + dma_wmb();
> > }
> >
> > static void sdhci_adma_table_post(struct sdhci_host *host,
> > @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
> > static void sdhci_adma_show_error(struct sdhci_host *host)
> > {
> > void *desc = host->adma_table;
> > + dma_addr_t dma = host->adma_addr;
> > + bool end = false;
> >
> > sdhci_dumpregs(host);
> >
> > @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
> > struct sdhci_adma2_64_desc *dma_desc = desc;
> >
> > if (host->flags & SDHCI_USE_64_BIT_DMA)
> > - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > - desc, le32_to_cpu(dma_desc->addr_hi),
> > + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > + (unsigned long long)dma,
> > + le32_to_cpu(dma_desc->addr_hi),
> > le32_to_cpu(dma_desc->addr_lo),
> > le16_to_cpu(dma_desc->len),
> > le16_to_cpu(dma_desc->cmd));
> > else
> > - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > - desc, le32_to_cpu(dma_desc->addr_lo),
> > + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > + (unsigned long long)dma,
> > + le32_to_cpu(dma_desc->addr_lo),
> > le16_to_cpu(dma_desc->len),
> > le16_to_cpu(dma_desc->cmd));
> >
> > + if (end) break;
> > +
> > desc += host->desc_sz;
> > + dma += host->desc_sz;
> >
> > if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
> > - break;
> > + end = true;
> > }
> > }
> >
> > @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
> > != MMC_BUS_TEST_R)
> > host->data->error = -EILSEQ;
> > else if (intmask & SDHCI_INT_ADMA_ERROR) {
> > - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
> > + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
> > sdhci_adma_show_error(host);
> > host->data->error = -EIO;
> > if (host->ops->adma_workaround)
>
> Further debug shows:
>
> coherent=0 - sdhci device is not cache coherent
> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
> [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
> pmd=000000237fffb003, pte=00e800236d62270f
>
> The mapping for the ADMA table seems to be using MAIR index 3, which is
> MT_MEMORY_NC, so should be non-cacheable.
>
> vmallocinfo:
> 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
> user
>
> So this memory has been remapped. Could there be an alias that has
> cache lines still in the cache for the physical address, and could we
> be hitting those cache lines while accessing through a non-cacheable
> mapping? (On 32-bit ARM, this is "unpredictable" and this problem
> definitely _feels_ like it has unpredictable attributes!)
>
> Also, given that this memory is mapped NC, then surely
> __dma_flush_area() should have no effect? However, it _does_ have the
> effect of reliably solving the problem, which to me implies that there
> _are_ cache lines in this NC mapping.
Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
alloc_pages for single pages") which has been implicated in the same
problem here:
https://www.spinics.net/lists/arm-kernel/msg750623.html
Although reverting the commit is not clean, this also fixes the issue
for me.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/4] arm64: defconfig: enable R8A774B1 SoC
From: Biju Das @ 2019-09-17 13:05 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Fabrizio Castro, linux-renesas-soc, Chris Paterson, Anson Huang,
Arnd Bergmann, Maxime Ripard, Biju Das, Marcin Juszkiewicz,
Dinh Nguyen, Simon Horman, Bjorn Andersson, Jagan Teki,
Olof Johansson, Geert Uytterhoeven, Leonard Crestez, Shawn Guo,
linux-arm-kernel
In-Reply-To: <1568725530-55241-1-git-send-email-biju.das@bp.renesas.com>
Enable the Renesas RZ/G2N (R8A774B1) SoC in the ARM64 defconfig.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef0..6433d33 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -721,6 +721,7 @@ CONFIG_QCOM_SMD_RPM=y
CONFIG_QCOM_SMP2P=y
CONFIG_QCOM_SMSM=y
CONFIG_ARCH_R8A774A1=y
+CONFIG_ARCH_R8A774B1=y
CONFIG_ARCH_R8A774C0=y
CONFIG_ARCH_R8A7795=y
CONFIG_ARCH_R8A7796=y
--
2.7.4
_______________________________________________
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] KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put
From: Marc Zyngier @ 2019-09-17 13:14 UTC (permalink / raw)
To: Zenghui Yu, linux-arm-kernel, kvmarm, kvm; +Cc: Andre Przywara
In-Reply-To: <3b2d4a15-5658-f50f-0214-1da708cd4923@huawei.com>
On 17/09/2019 11:17, Zenghui Yu wrote:
> Hi Marc,
>
> On 2019/9/17 17:31, Zenghui Yu wrote:
>>
>> But this time I got the following WARNING:
>
> Please ignore it. I think this is mostly caused by my local buggy
> patch... Sorry for the noise.
Right. I couldn't quite figure out how this could happen with the
current state of the code...
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: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Fabio Estevam @ 2019-09-17 13:24 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <20190917130759.GO25745@shell.armlinux.org.uk>
Hi Russell,
On Tue, Sep 17, 2019 at 10:10 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
> alloc_pages for single pages") which has been implicated in the same
> problem here:
>
> https://www.spinics.net/lists/arm-kernel/msg750623.html
It seems that the final fix was:
https://lore.kernel.org/patchwork/patch/1121600/
Does it work for you if we follow the same idea?
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1105,6 +1105,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
esdhc_init(pdev, host);
+ sdhci_enable_v4_mode(host);
sdhci_get_of_property(pdev);
pltfm_host = sdhci_priv(host);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 13:28 UTC (permalink / raw)
To: Robin Murphy; +Cc: linux-mmc, Will Deacon, Adrian Hunter, Linux ARM
In-Reply-To: <1406d22f-fd2e-f101-3efb-63cc52e9ac5f@arm.com>
On Tue, Sep 17, 2019 at 02:03:04PM +0100, Robin Murphy wrote:
> On 17/09/2019 13:33, Russell King - ARM Linux admin wrote:
> [...]
> > Further debug shows:
> >
> > coherent=0 - sdhci device is not cache coherent
> > swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
> > [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
> > pmd=000000237fffb003, pte=00e800236d62270f
> >
> > The mapping for the ADMA table seems to be using MAIR index 3, which is
> > MT_MEMORY_NC, so should be non-cacheable.
> >
> > vmallocinfo:
> > 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
> > user
> >
> > So this memory has been remapped. Could there be an alias that has
> > cache lines still in the cache for the physical address, and could we
> > be hitting those cache lines while accessing through a non-cacheable
> > mapping? (On 32-bit ARM, this is "unpredictable" and this problem
> > definitely _feels_ like it has unpredictable attributes!)
> >
> > Also, given that this memory is mapped NC, then surely
> > __dma_flush_area() should have no effect? However, it _does_ have the
> > effect of reliably solving the problem, which to me implies that there
> > _are_ cache lines in this NC mapping.
>
> The non-cacheable mapping of the descriptor table will still have its
> cacheable linear map alias, so it's quite likely that the invalidate aspect
> of __dma_flush_area(), rather than the clean, is what's making the
> difference - if using __dma_clean_area() instead doesn't help, it would more
> or less confirm that.
>
> One possibility in that case is that you might actually have the rare
> backwards coherency problem - if the device *is* actually snooping the
> cache, then it could hit lines which were speculatively prefetched via the
> cacheable alias before the descriptors were fully written, rather than the
> up-to-date data which went straight to RAM via the NC mapping. I'd try
> declaring the device as "dma-coherent" to see if that's actually true (and
> it should become pretty obvious if it isn't).
As just mentioned in my previous reply, there's a commit to the
dma-contiguous which changes where the CMA memory comes from.
[ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
pmd=000000237fffb003, pte=00e800236d62270f
vs
[ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
pmd=000000237fffb003, pte=00e80000f9c9a70f
Former is with the patch applied, latter is with it reverted.
This makes me question whether the cache handling for a page that is
remapped is being performed. If there's cache lines present for a
page that is being remapped as non-cacheable, what prevents those
cache lines from being dirty and possibly being written-back at some
point after the non-cacheable mapping as been started to be used?
And yes, it looks like adding "dma-coherent" to the SDHCI controller
with the SD card in resolves the issue, so your hypothesis may be
true. On the other hand, I haven't added "dma-coherent" to the eMMC
side, and that's also working fine over several reboots without the
offending commit reverted _nor_ with my __dma_flush_area() hack in
place.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: tinywrkb @ 2019-09-17 13:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Baruch Siach, Fabio Estevam, Sascha Hauer, Russell King,
open list, Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
Shawn Guo, linux-arm-kernel
In-Reply-To: <20190917125434.GH20778@lunn.ch>
On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > Tinywrkb confirmed to me in private communication that revert of
> > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > >
> > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > AR8035 PHY that supports 1Gb.
> > > >
> > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > the moment.
> > >
> > > Could somebody with an affected device show us the output of ethtool
> > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > without that patch? We are missing a piece of the puzzle.
> > >
> > > Andrew
> >
> > linux-test-5.1rc1-a2703de70942-without_bad_commit
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
>
> So this means the local device says it can do 1000Mbps.
>
>
> > Supported pause frame use: Symmetric
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
>
> The link peer can also do 1000Mbps.
>
>
> > Advertised pause frame use: Symmetric
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 100Mb/s
>
> Yet they have decided to do 100Mbps.
>
> We need to understand Why? The generic PHY driver would not do this on
> its own. So i'm thinking something has poked a PHY register with some
> value, and this patch is causing it to be over written.
>
> Please can you use mii-tool -v -v to dump the PHY registers in each
> case.
>
> Thanks
> Andrew
Here's the output of # mii-tool -v -v eth0
* linux-test-5.1rc1-a2703de70942-without_bad_commit
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c5e1 000f 0000
0000 0000 0800 0000 0000 0000 0000 a000
0000 0000 0000 f420 082c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
* linux-test-5.1rc1-5502b218e001-with_bad_commit
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c5e1 000d 0000
0000 0000 0800 0000 0000 0000 0000 a000
0000 0000 0000 0000 082c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Thanks for helping Andrew.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 13:33 UTC (permalink / raw)
To: Fabio Estevam
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <CAOMZO5DXv8g5qTGdvobDdLWim+tW=vK4+K=P-VqJK23KERMhJw@mail.gmail.com>
On Tue, Sep 17, 2019 at 10:24:57AM -0300, Fabio Estevam wrote:
> Hi Russell,
>
> On Tue, Sep 17, 2019 at 10:10 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
>
> > Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
> > alloc_pages for single pages") which has been implicated in the same
> > problem here:
> >
> > https://www.spinics.net/lists/arm-kernel/msg750623.html
>
> It seems that the final fix was:
> https://lore.kernel.org/patchwork/patch/1121600/
>
> Does it work for you if we follow the same idea?
>
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1105,6 +1105,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
>
> esdhc_init(pdev, host);
>
> + sdhci_enable_v4_mode(host);
> sdhci_get_of_property(pdev);
>
> pltfm_host = sdhci_priv(host);
That attempts to set bit 12 of the host control register 2 (0x3e).
The LX2160A documentation states that bit 28 of 0x3c (they're 32-bit
wide registers there) is "reserved".
So, you're asking for a documented reserved bit to be set...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Robin Murphy @ 2019-09-17 13:38 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Adrian Hunter, Will Deacon,
Nicolin Chen, dann frazier, Christoph Hellwig
Cc: linux-mmc, Linux ARM
In-Reply-To: <20190917130759.GO25745@shell.armlinux.org.uk>
On 17/09/2019 14:07, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
>> On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
>>> On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
>>>> On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
>>>>> On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
>>>>>> On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
>>>>>>> On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
>>>>>>>
>>>>>>>> The platform has an iommu, which is in pass-through mode, via
>>>>>>>> arm_smmu.disable_bypass=0.
>>>>>>>
>>>>>>> Could be 954a03be033c7cef80ddc232e7cbdb17df735663
>>>>>>> "iommu/arm-smmu: Break insecure users by disabling bypass by default"
>>>>>>>
>>>>>>> Although it had already landed in v5.2
>>>>>>
>>>>>> It is not - and the two lines that you quoted above are sufficient
>>>>>> to negate that as a cause. (Please read the help for the option that
>>>>>> the commit referrs to.)
>>>>>>
>>>>>> In fact, with bypass disabled, the SoC fails due to other masters.
>>>>>> That's already been discussed privately between myself and Will
>>>>>> Deacon.
>>>>>>
>>>>>> arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
>>>>>> the default setting in the Kconfig.
>>>>>
>>>>> Adding some further debugging, and fixing the existing ADMA debugging
>>>>> shows:
>>>>>
>>>>> mmc0: ADMA error: 0x02000000
>>>>>
>>>>> So this is an ADMA error without the transfer having completed.
>>>>>
>>>>> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
>>>>>
>>>>> The block size is 8, with one block.
>>>>>
>>>>> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
>>>>>
>>>>> The ADMA error is a descriptor error at address 0x000000236df1d20c.
>>>>> The descriptor table contains (including the following entry):
>>>>>
>>>>> mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
>>>>> mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
>>>>>
>>>>> The descriptor table contains one descriptor of 8 bytes, is marked
>>>>> as the last (END bit set) and is at DMA address 0x236df1d200. The
>>>>> following descriptor is empty, with VALID=0.
>>>>>
>>>>> One may be tempted to blame it on the following descriptor, but having
>>>>> had another example on eMMC while userspace was booting (rootfs on
>>>>> eMMC):
>>>>>
>>>>> mmc1: ADMA error: 0x02000000
>>>>> mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
>>>>> mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
>>>>> mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
>>>>> mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
>>>>> mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
>>>>>
>>>>> ... which is interesting for several reasons:
>>>>> - The ADMA error register indicates a length mismatch error. The
>>>>> transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
>>>>> Summing the ADMA lengths up to the last descriptor (length=0 is
>>>>> 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
>>>>> bytes than the requested transfer.
>>>>>
>>>>> - The ADMA error register indicates ST_CADR, which is described as
>>>>> "This state is never set because do not generate ADMA error in this
>>>>> state."
>>>>>
>>>>> - The error descriptor is again after the descriptor with END=1, but
>>>>> this time has VALID=1.
>>>>>
>>>>> This _feels_ like a coherency issue, where the SDHCI engine is not
>>>>> correctly seeing the descriptor table, but then I would have expected
>>>>> userspace (which is basically debian stable) to fail to boot every
>>>>> time given that its rootfs is on eMMC.
>>>>>
>>>>> The other weird thing is if I wind the core MMC code back via:
>>>>>
>>>>> $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
>>>>>
>>>>> and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
>>>>> completely stable, but way better than plain v5.3. I don't see
>>>>> much in that diff which would be responsible for this - although it
>>>>> does seem that hch's DMA changes do make the problem more likely.
>>>>> (going from 1 in 3 boots with a problem to being not able to boot.)
>>>>>
>>>>> Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
>>>>> bypass mode on the IOMMU (but then I saw global smmu errors right
>>>>> from when the IOMMU had bypass disabled before MMC was probed - the
>>>>> reason being is the SoC is not currently setup to have the MMU
>>>>> bypass mode disabled.)
>>>>
>>>> This looks like an ARM64 coherency issue.
>>>>
>>>> I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
>>>> which had no effect. I then tried adding:
>>>>
>>>> + __dma_flush_area(host->adma_table, desc - host->adma_table);
>>>> + dma_wmb();
>>>>
>>>> and so far I haven't had any further ADMA errors. Adding Will Deacon
>>>> to the thread.
>>>
>>> These are the changes to sdhci that I'm currently running. I think
>>> some of the debugging related changes are probably worth adding to
>>> the driver, particularly printing the intmask on ADMA error (which
>>> is not printed by the register dump, as the value is lost) and printing
>>> the DMA addresses of the descriptor table entries which can be tied
>>> up with the DMA address error register. Also, maybe printing the
>>> DMA descriptor table with the register dump, rather than having to
>>> resort to enabling debug would be a good idea?
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index a5dc5aae973e..884dcaa9cad5 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
>>> /* Add a terminating entry - nop, end, valid */
>>> __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
>>> }
>>> + __dma_flush_area(host->adma_table, desc - host->adma_table);
>>> + dma_wmb();
>>> }
>>>
>>> static void sdhci_adma_table_post(struct sdhci_host *host,
>>> @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
>>> static void sdhci_adma_show_error(struct sdhci_host *host)
>>> {
>>> void *desc = host->adma_table;
>>> + dma_addr_t dma = host->adma_addr;
>>> + bool end = false;
>>>
>>> sdhci_dumpregs(host);
>>>
>>> @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
>>> struct sdhci_adma2_64_desc *dma_desc = desc;
>>>
>>> if (host->flags & SDHCI_USE_64_BIT_DMA)
>>> - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>> - desc, le32_to_cpu(dma_desc->addr_hi),
>>> + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>> + (unsigned long long)dma,
>>> + le32_to_cpu(dma_desc->addr_hi),
>>> le32_to_cpu(dma_desc->addr_lo),
>>> le16_to_cpu(dma_desc->len),
>>> le16_to_cpu(dma_desc->cmd));
>>> else
>>> - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>> - desc, le32_to_cpu(dma_desc->addr_lo),
>>> + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>> + (unsigned long long)dma,
>>> + le32_to_cpu(dma_desc->addr_lo),
>>> le16_to_cpu(dma_desc->len),
>>> le16_to_cpu(dma_desc->cmd));
>>>
>>> + if (end) break;
>>> +
>>> desc += host->desc_sz;
>>> + dma += host->desc_sz;
>>>
>>> if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
>>> - break;
>>> + end = true;
>>> }
>>> }
>>>
>>> @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
>>> != MMC_BUS_TEST_R)
>>> host->data->error = -EILSEQ;
>>> else if (intmask & SDHCI_INT_ADMA_ERROR) {
>>> - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
>>> + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
>>> sdhci_adma_show_error(host);
>>> host->data->error = -EIO;
>>> if (host->ops->adma_workaround)
>>
>> Further debug shows:
>>
>> coherent=0 - sdhci device is not cache coherent
>> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
>> [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
>> pmd=000000237fffb003, pte=00e800236d62270f
>>
>> The mapping for the ADMA table seems to be using MAIR index 3, which is
>> MT_MEMORY_NC, so should be non-cacheable.
>>
>> vmallocinfo:
>> 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
>> user
>>
>> So this memory has been remapped. Could there be an alias that has
>> cache lines still in the cache for the physical address, and could we
>> be hitting those cache lines while accessing through a non-cacheable
>> mapping? (On 32-bit ARM, this is "unpredictable" and this problem
>> definitely _feels_ like it has unpredictable attributes!)
>>
>> Also, given that this memory is mapped NC, then surely
>> __dma_flush_area() should have no effect? However, it _does_ have the
>> effect of reliably solving the problem, which to me implies that there
>> _are_ cache lines in this NC mapping.
>
> Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
> alloc_pages for single pages") which has been implicated in the same
> problem here:
>
> https://www.spinics.net/lists/arm-kernel/msg750623.html
>
> Although reverting the commit is not clean, this also fixes the issue
> for me.
Note that that one turned out to be something totally different, namely
that the single-page allocations, in difference to CMA, came from
physical addresses that the controller needed additional configuration
to be able to access[1] - no amount of cache maintenance would affect that.
However, the other difference between getting a single page directly
from the page allocator vs. the CMA area is that accesses to the linear
mapping of the CMA area are probably pretty rare, whereas for the
single-page case it's much more likely that kernel tasks using adjacent
pages could lead to prefetching of the descriptor page's cacheable
alias. That could certainly explain how reverting that commit manages to
hide an apparent coherency issue.
Robin.
[1] https://lore.kernel.org/patchwork/patch/1121600/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Russell King - ARM Linux admin @ 2019-09-17 13:39 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland, Andrew Lunn, Baruch Siach,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Fabio Estevam, Sascha Hauer, open list, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Shawn Guo,
linux-arm-kernel
In-Reply-To: <20190917133253.GA1210141@arch-dsk-01>
On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > >
> > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > AR8035 PHY that supports 1Gb.
> > > > >
> > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > the moment.
> > > >
> > > > Could somebody with an affected device show us the output of ethtool
> > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > without that patch? We are missing a piece of the puzzle.
> > > >
> > > > Andrew
> > >
> > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Settings for eth0:
> > > Supported ports: [ TP MII ]
> > > Supported link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> >
> > So this means the local device says it can do 1000Mbps.
> >
> >
> > > Supported pause frame use: Symmetric
> > > Supports auto-negotiation: Yes
> > > Supported FEC modes: Not reported
> > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> >
> > The link peer can also do 1000Mbps.
> >
> >
> > > Advertised pause frame use: Symmetric
> > > Advertised auto-negotiation: Yes
> > > Advertised FEC modes: Not reported
> > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> > > Link partner advertised pause frame use: Symmetric
> > > Link partner advertised auto-negotiation: Yes
> > > Link partner advertised FEC modes: Not reported
> > > Speed: 100Mb/s
> >
> > Yet they have decided to do 100Mbps.
> >
> > We need to understand Why? The generic PHY driver would not do this on
> > its own. So i'm thinking something has poked a PHY register with some
> > value, and this patch is causing it to be over written.
> >
> > Please can you use mii-tool -v -v to dump the PHY registers in each
> > case.
> >
> > Thanks
> > Andrew
>
> Here's the output of # mii-tool -v -v eth0
>
> * linux-test-5.1rc1-a2703de70942-without_bad_commit
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c5e1 000f 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> 0000 0000 0000 f420 082c 0000 04e8 0000
> 3200 3000 0000 063d 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
This is *not* advertising 1000baseT modes (register 9).
>
>
> * linux-test-5.1rc1-5502b218e001-with_bad_commit
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c5e1 000d 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> 0000 0000 0000 0000 082c 0000 04e8 0000
> 3200 3000 0000 063d 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Neither is this.
However, the kernel and phylib _thinks_ that it is. My guess is
something has rewritten the PHY registers from userspace, rather
than using ethtool to change the advertisment. The MAC is still
trying to operate at 1000Mbps (since that is what phylib resolved)
yet the link might be actually operating at 100Mbps - but for that
to happen, we should've seen the link go down and up again.
Odd.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] arm64: ARMv8.4 Activity Monitors support
From: Ionela Voinescu @ 2019-09-17 13:42 UTC (permalink / raw)
To: catalin.marinas, will, maz, corbet
Cc: Ionela Voinescu, linux-kernel, linux-arm-kernel, linux-doc
These patches introduce support for the Activity Monitors Unit (AMU)
CPU extension, an optional extension in ARMv8.4 CPUs. This provides
performance counters intended for system management use.
With the CONFIG_ARM64_AMU_EXTN enabled the kernel is able to safely
run a mix of CPUs with and without support for the AMU extension.
The AMU capability is unconditionally enabled in the kernel as to
allow any late CPU to use the feature: the cpu_enable function will
be called for all CPUs that match the criteria, including secondary
and hotplugged CPUs, marking this feature as present on that
respective CPU (through a per-cpu variable).
To be noted that firmware must implement AMU support when running on
CPUs that present the activity monitors extension: allow access to
the registers from lower exception levels, enable the counters,
implement save and restore functionality. More details can be found
in the documentation.
Given that the activity counters inform on activity on the CPUs, and
that not all CPUs might implement the extension, for functional and
security reasons, it's best to disable access to the AMU registers
from userspace (EL0) and KVM guests.
The current series is based on linux-next 20190916.
Testing:
- Build tested for multiple architectures and defconfigs.
- AMU feature detection, EL0 and KVM guest access to AMU registers,
feature support in firmware (version 1.5 and later of the ARM
Trusted Firmware) was tested on an Armv8-A Base Platform FVP:
Architecture Envelope Model [1] (supports version 8.0 to 8.5),
with the following configurations:
cluster0.has_arm_v8-4=1
cluster1.has_arm_v8-4=1
cluster0.has_amu=1
cluster1.has_amu=1
[1] https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
Ionela Voinescu (4):
arm64: add support for the AMU extension v1
arm64: trap to EL1 accesses to AMU counters from EL0
arm64/kvm: disable access to AMU registers from kvm guests
Documentation: arm64: document support for the AMU extension
Documentation/arm64/amu.rst | 107 ++++++++++++++++++
Documentation/arm64/booting.rst | 14 +++
Documentation/arm64/cpu-feature-registers.rst | 2 +
Documentation/arm64/index.rst | 1 +
arch/arm64/Kconfig | 27 +++++
arch/arm64/include/asm/assembler.h | 10 ++
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/kvm_arm.h | 7 +-
arch/arm64/include/asm/sysreg.h | 44 +++++++
arch/arm64/kernel/cpufeature.c | 71 +++++++++++-
arch/arm64/kvm/hyp/switch.c | 13 ++-
arch/arm64/kvm/sys_regs.c | 95 +++++++++++++++-
arch/arm64/mm/proc.S | 3 +
13 files changed, 386 insertions(+), 11 deletions(-)
create mode 100644 Documentation/arm64/amu.rst
--
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 1/4] arm64: add support for the AMU extension v1
From: Ionela Voinescu @ 2019-09-17 13:42 UTC (permalink / raw)
To: catalin.marinas, will, maz, corbet
Cc: Mark Rutland, Suzuki K Poulose, linux-doc, linux-kernel,
Ionela Voinescu, linux-arm-kernel
In-Reply-To: <20190917134228.5369-1-ionela.voinescu@arm.com>
The activity monitors extension is an optional extension introduced
by the ARMv8.4 CPU architecture. This implements basic support for
version 1 of the activity monitors architecture, AMUv1.
This support includes:
- Extension detection on each CPU (boot, secondary, hotplugged)
- Register interface for AMU aarch64 registers
- (while here) create defines for ID_PFR0_EL1 fields when adding
the AMU field information.
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/Kconfig | 27 ++++++++++++
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/sysreg.h | 44 ++++++++++++++++++++
arch/arm64/kernel/cpufeature.c | 71 ++++++++++++++++++++++++++++++--
4 files changed, 140 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6b6362b83004..3bf7972d43c7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1410,6 +1410,33 @@ config ARM64_PTR_AUTH
endmenu
+menu "ARMv8.4 architectural features"
+
+config ARM64_AMU_EXTN
+ bool "Enable support for the Activity Monitors Unit CPU extension"
+ default y
+ help
+ The activity monitors extension is an optional extension introduced
+ by the ARMv8.4 CPU architecture. This enables support for version 1
+ of the activity monitors architecture, AMUv1.
+
+ To enable the use of this extension on CPUs that implement it, say Y.
+
+ Note that for architectural reasons, firmware _must_ implement AMU
+ support when running on CPUs that present the activity monitors
+ extension. The required support is present in:
+ * Version 1.5 and later of the ARM Trusted Firmware
+
+ For kernels that have this configuration enabled but boot with broken
+ firmware, you may need to say N here until the firmware is fixed.
+ Otherwise you may experience firmware panics or lockups when
+ accessing the counter registers. Even if you are not observing these
+ symptoms, the values returned by the register reads might not
+ correctly reflect reality. Most commonly, the value read will be 0,
+ indicating that the counter is not enabled.
+
+endmenu
+
config ARM64_SVE
bool "ARM Scalable Vector Extension support"
default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index f19fe4b9acc4..7f12ad4f69ad 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -52,7 +52,8 @@
#define ARM64_HAS_IRQ_PRIO_MASKING 42
#define ARM64_HAS_DCPODP 43
#define ARM64_WORKAROUND_1463225 44
+#define ARM64_HAS_AMU_EXTN 45
-#define ARM64_NCAPS 45
+#define ARM64_NCAPS 46
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 972d196c7714..f090a86a376d 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -382,6 +382,42 @@
#define SYS_TPIDR_EL0 sys_reg(3, 3, 13, 0, 2)
#define SYS_TPIDRRO_EL0 sys_reg(3, 3, 13, 0, 3)
+/* Definitions for system register interface to AMU for ARMv8.4 onwards */
+#define SYS_AM_EL0(crm, op2) sys_reg(3, 3, 13, crm, op2)
+#define SYS_AMCR_EL0 SYS_AM_EL0(2, 0)
+#define SYS_AMCFGR_EL0 SYS_AM_EL0(2, 1)
+#define SYS_AMCGCR_EL0 SYS_AM_EL0(2, 2)
+#define SYS_AMUSERENR_EL0 SYS_AM_EL0(2, 3)
+#define SYS_AMCNTENCLR0_EL0 SYS_AM_EL0(2, 4)
+#define SYS_AMCNTENSET0_EL0 SYS_AM_EL0(2, 5)
+#define SYS_AMCNTENCLR1_EL0 SYS_AM_EL0(3, 0)
+#define SYS_AMCNTENSET1_EL0 SYS_AM_EL0(3, 1)
+
+/*
+ * Group 0 of activity monitors (architected):
+ * op0 CRn op1 op2 CRm
+ * Counter: 11 1101 011 n<2:0> 010:n<3>
+ * Type: 11 1101 011 n<2:0> 011:n<3>
+ * n: 0-3
+ *
+ * Group 1 of activity monitors (auxiliary):
+ * op0 CRn op1 op2 CRm
+ * Counter: 11 1101 011 n<2:0> 110:n<3>
+ * Type: 11 1101 011 n<2:0> 111:n<3>
+ * n: 0-15
+ */
+
+#define SYS_AMEVCNTR0_EL0(n) SYS_AM_EL0(4 + ((n) >> 3), (n) & 0x7)
+#define SYS_AMEVTYPE0_EL0(n) SYS_AM_EL0(6 + ((n) >> 3), (n) & 0x7)
+#define SYS_AMEVCNTR1_EL0(n) SYS_AM_EL0(12 + ((n) >> 3), (n) & 0x7)
+#define SYS_AMEVTYPE1_EL0(n) SYS_AM_EL0(14 + ((n) >> 3), (n) & 0x7)
+
+/* V1: Fixed (architecturally defined) activity monitors */
+#define SYS_AMEVCNTR0_CORE_EL0 SYS_AMEVCNTR0_EL0(0)
+#define SYS_AMEVCNTR0_CONST_EL0 SYS_AMEVCNTR0_EL0(1)
+#define SYS_AMEVCNTR0_INST_RET_EL0 SYS_AMEVCNTR0_EL0(2)
+#define SYS_AMEVCNTR0_MEM_STALL SYS_AMEVCNTR0_EL0(3)
+
#define SYS_CNTFRQ_EL0 sys_reg(3, 3, 14, 0, 0)
#define SYS_CNTP_TVAL_EL0 sys_reg(3, 3, 14, 2, 0)
@@ -577,6 +613,7 @@
#define ID_AA64PFR0_CSV3_SHIFT 60
#define ID_AA64PFR0_CSV2_SHIFT 56
#define ID_AA64PFR0_DIT_SHIFT 48
+#define ID_AA64PFR0_AMU_SHIFT 44
#define ID_AA64PFR0_SVE_SHIFT 32
#define ID_AA64PFR0_RAS_SHIFT 28
#define ID_AA64PFR0_GIC_SHIFT 24
@@ -587,6 +624,7 @@
#define ID_AA64PFR0_EL1_SHIFT 4
#define ID_AA64PFR0_EL0_SHIFT 0
+#define ID_AA64PFR0_AMU 0x1
#define ID_AA64PFR0_SVE 0x1
#define ID_AA64PFR0_RAS_V1 0x1
#define ID_AA64PFR0_FP_NI 0xf
@@ -709,6 +747,12 @@
#define ID_AA64MMFR0_TGRAN16_NI 0x0
#define ID_AA64MMFR0_TGRAN16_SUPPORTED 0x1
+#define ID_PFR0_AMU_SHIFT 20
+#define ID_PFR0_STATE3_SHIFT 12
+#define ID_PFR0_STATE2_SHIFT 8
+#define ID_PFR0_STATE1_SHIFT 4
+#define ID_PFR0_STATE0_SHIFT 0
+
#if defined(CONFIG_ARM64_4K_PAGES)
#define ID_AA64MMFR0_TGRAN_SHIFT ID_AA64MMFR0_TGRAN4_SHIFT
#define ID_AA64MMFR0_TGRAN_SUPPORTED ID_AA64MMFR0_TGRAN4_SUPPORTED
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9323bcc40a58..cce86c6a5d00 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -155,6 +155,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV2_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_DIT_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_AMU_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_RAS_SHIFT, 4, 0),
@@ -308,10 +309,11 @@ static const struct arm64_ftr_bits ftr_id_mmfr4[] = {
};
static const struct arm64_ftr_bits ftr_id_pfr0[] = {
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0), /* State3 */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0), /* State2 */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0), /* State1 */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* State0 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_AMU_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE3_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE2_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE1_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE0_SHIFT, 4, 0),
ARM64_FTR_END,
};
@@ -1143,6 +1145,49 @@ static bool has_hw_dbm(const struct arm64_cpu_capabilities *cap,
#endif
+#ifdef CONFIG_ARM64_AMU_EXTN
+
+/*
+ * This per cpu variable only signals that the CPU implementation supports the
+ * AMU but does not provide information regarding all the events that it
+ * supports.
+ * When this amu_feat per CPU variable is true, the user of this feature can
+ * only rely on the presence of the 4 fixed counters. But this does not
+ * guarantee that the counters are enabled or access to these counters is
+ * provided by code executed at higher exception levels.
+ */
+DEFINE_PER_CPU(bool, amu_feat) = false;
+
+static void cpu_amu_enable(struct arm64_cpu_capabilities const *cap)
+{
+ if (has_cpuid_feature(cap, SCOPE_LOCAL_CPU)) {
+ pr_info("detected CPU%d: Activity Monitors extension\n",
+ smp_processor_id());
+ this_cpu_write(amu_feat, true);
+ }
+}
+
+static bool has_amu(const struct arm64_cpu_capabilities *cap,
+ int __unused)
+{
+ /*
+ * The AMU extension is a non-conflicting feature: the kernel can
+ * safely run a mix of CPUs with and without support for the
+ * activity monitors extension.
+ * Therefore, unconditionally enable the capability to allow
+ * any late CPU to use the feature.
+ *
+ * With this feature unconditionally enabled, the cpu_enable
+ * function will be called for all CPUs that match the criteria,
+ * including secondary and hotplugged, marking this feature as
+ * present on that respective CPU. The enable function will also
+ * print a detection message.
+ */
+
+ return true;
+}
+#endif
+
#ifdef CONFIG_ARM64_VHE
static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused)
{
@@ -1412,6 +1457,24 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.cpu_enable = cpu_clear_disr,
},
#endif /* CONFIG_ARM64_RAS_EXTN */
+#ifdef CONFIG_ARM64_AMU_EXTN
+ {
+ /*
+ * The feature is enabled by default if CONFIG_ARM64_AMU_EXTN=y.
+ * Therefore, don't provide .desc as we don't want the detection
+ * message to be shown until at least one CPU is detected to
+ * support the feature.
+ */
+ .capability = ARM64_HAS_AMU_EXTN,
+ .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
+ .matches = has_amu,
+ .sys_reg = SYS_ID_AA64PFR0_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64PFR0_AMU_SHIFT,
+ .min_field_value = ID_AA64PFR0_AMU,
+ .cpu_enable = cpu_amu_enable,
+ },
+#endif /* CONFIG_ARM64_AMU_EXTN */
{
.desc = "Data cache clean to the PoU not required for I/D coherence",
.capability = ARM64_HAS_CACHE_IDC,
--
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
* [PATCH 2/4] arm64: trap to EL1 accesses to AMU counters from EL0
From: Ionela Voinescu @ 2019-09-17 13:42 UTC (permalink / raw)
To: catalin.marinas, will, maz, corbet
Cc: Mark Rutland, Steve Capper, linux-doc, linux-kernel,
Ionela Voinescu, linux-arm-kernel
In-Reply-To: <20190917134228.5369-1-ionela.voinescu@arm.com>
The activity monitors extension is an optional extension introduced
by the ARMv8.4 CPU architecture. In order to access the activity
monitors counters safely, if desired, the kernel should detect the
presence of the extension through the feature register, and mediate
the access.
Therefore, disable direct accesses to activity monitors counters
from EL0 (userspace) and trap them to EL1 (kernel).
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
---
arch/arm64/include/asm/assembler.h | 10 ++++++++++
arch/arm64/mm/proc.S | 3 +++
2 files changed, 13 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index b8cf7c85ffa2..894fc8bf8102 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -443,6 +443,16 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU
9000:
.endm
+/*
+ * reset_amuserenr_el0 - reset AMUSERENR_EL0 if AMUv1 present
+ */
+ .macro reset_amuserenr_el0, tmpreg
+ mrs \tmpreg, id_aa64pfr0_el1 // Check ID_AA64PFR0_EL1
+ ubfx \tmpreg, \tmpreg, #ID_AA64PFR0_AMU_SHIFT, #4
+ cbz \tmpreg, 9000f // Skip if no AMU present
+ msr_s SYS_AMUSERENR_EL0, xzr // Disable AMU access from EL0
+9000:
+ .endm
/*
* copy_page - copy src to dest using temp registers t1-t8
*/
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index a1e0592d1fbc..d8aae1152c08 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -124,6 +124,7 @@ alternative_endif
ubfx x11, x11, #1, #1
msr oslar_el1, x11
reset_pmuserenr_el0 x0 // Disable PMU access from EL0
+ reset_amuserenr_el0 x0 // Disable AMU access from EL0
alternative_if ARM64_HAS_RAS_EXTN
msr_s SYS_DISR_EL1, xzr
@@ -415,6 +416,8 @@ ENTRY(__cpu_setup)
isb // Unmask debug exceptions now,
enable_dbg // since this is per-cpu
reset_pmuserenr_el0 x0 // Disable PMU access from EL0
+ reset_amuserenr_el0 x0 // Disable AMU access from EL0
+
/*
* Memory region attributes for LPAE:
*
--
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
* [PATCH 3/4] arm64/kvm: disable access to AMU registers from kvm guests
From: Ionela Voinescu @ 2019-09-17 13:42 UTC (permalink / raw)
To: catalin.marinas, will, maz, corbet
Cc: linux-doc, Suzuki K Poulose, linux-kernel, James Morse,
linux-arm-kernel, Ionela Voinescu, Julien Thierry
In-Reply-To: <20190917134228.5369-1-ionela.voinescu@arm.com>
Access to the AMU counters should be disabled by default in kvm guests,
as information from the counters might reveal activity in other guests
or activity on the host.
Therefore, disable access to AMU registers from EL0 and EL1 in kvm
guests by:
- Hiding the presence of the extension in the feature register
(SYS_ID_AA64PFR0_EL1 and SYS_ID_PFR0_EL1) on the VCPU.
- Disabling access to the AMU registers before switching to the guest.
- Trapping accesses and injecting an undefined instruction into the
guest.
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/kvm_arm.h | 7 ++-
arch/arm64/kvm/hyp/switch.c | 13 ++++-
arch/arm64/kvm/sys_regs.c | 95 +++++++++++++++++++++++++++++++-
3 files changed, 109 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index ddf9d762ac62..df957156d55e 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -267,10 +267,11 @@
#define CPTR_EL2_TFP_SHIFT 10
/* Hyp Coprocessor Trap Register */
-#define CPTR_EL2_TCPAC (1 << 31)
-#define CPTR_EL2_TTA (1 << 20)
-#define CPTR_EL2_TFP (1 << CPTR_EL2_TFP_SHIFT)
#define CPTR_EL2_TZ (1 << 8)
+#define CPTR_EL2_TFP (1 << CPTR_EL2_TFP_SHIFT)
+#define CPTR_EL2_TTA (1 << 20)
+#define CPTR_EL2_TAM (1 << 30)
+#define CPTR_EL2_TCPAC (1 << 31)
#define CPTR_EL2_RES1 0x000032ff /* known RES1 bits in CPTR_EL2 */
#define CPTR_EL2_DEFAULT CPTR_EL2_RES1
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 3d3815020e36..6cb37721eb94 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -90,6 +90,17 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
val = read_sysreg(cpacr_el1);
val |= CPACR_EL1_TTA;
val &= ~CPACR_EL1_ZEN;
+
+ /*
+ * With VHE enabled, we have HCR_EL2.{E2H,TGE} = {1,1}. Note that in
+ * this case CPACR_EL1 has the same bit layout as CPTR_EL2, and
+ * CPACR_EL1 accessing instructions are redefined to access CPTR_EL2.
+ * Therefore use CPTR_EL2.TAM bit reference to activate AMU register
+ * traps.
+ */
+
+ val |= CPTR_EL2_TAM;
+
if (update_fp_enabled(vcpu)) {
if (vcpu_has_sve(vcpu))
val |= CPACR_EL1_ZEN;
@@ -111,7 +122,7 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu)
__activate_traps_common(vcpu);
val = CPTR_EL2_DEFAULT;
- val |= CPTR_EL2_TTA | CPTR_EL2_TZ;
+ val |= CPTR_EL2_TTA | CPTR_EL2_TZ | CPTR_EL2_TAM;
if (!update_fp_enabled(vcpu)) {
val |= CPTR_EL2_TFP;
__activate_traps_fpsimd32(vcpu);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2071260a275b..1029cd1bc8cc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -999,6 +999,20 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ SYS_DESC(SYS_PMEVTYPERn_EL0(n)), \
access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+static bool access_amu(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ kvm_inject_undefined(vcpu);
+
+ return false;
+}
+
+/* Macro to expand the AMU counter and type registers*/
+#define AMU_AMEVCNTR0_EL0(n) { SYS_DESC(SYS_AMEVCNTR0_EL0(n)), access_amu }
+#define AMU_AMEVTYPE0_EL0(n) { SYS_DESC(SYS_AMEVTYPE0_EL0(n)), access_amu }
+#define AMU_AMEVCNTR1_EL0(n) { SYS_DESC(SYS_AMEVCNTR1_EL0(n)), access_amu }
+#define AMU_AMEVTYPE1_EL0(n) { SYS_DESC(SYS_AMEVTYPE1_EL0(n)), access_amu }
+
static bool trap_ptrauth(struct kvm_vcpu *vcpu,
struct sys_reg_params *p,
const struct sys_reg_desc *rd)
@@ -1074,8 +1088,12 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
(u32)r->CRn, (u32)r->CRm, (u32)r->Op2);
u64 val = raz ? 0 : read_sanitised_ftr_reg(id);
- if (id == SYS_ID_AA64PFR0_EL1 && !vcpu_has_sve(vcpu)) {
- val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
+ if (id == SYS_ID_AA64PFR0_EL1) {
+ if (!vcpu_has_sve(vcpu))
+ val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
+ val &= ~(0xfUL << ID_AA64PFR0_AMU_SHIFT);
+ } else if (id == SYS_ID_PFR0_EL1) {
+ val &= ~(0xfUL << ID_PFR0_AMU_SHIFT);
} else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
(0xfUL << ID_AA64ISAR1_API_SHIFT) |
@@ -1561,6 +1579,79 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_TPIDR_EL0), NULL, reset_unknown, TPIDR_EL0 },
{ SYS_DESC(SYS_TPIDRRO_EL0), NULL, reset_unknown, TPIDRRO_EL0 },
+ { SYS_DESC(SYS_AMCR_EL0), access_amu },
+ { SYS_DESC(SYS_AMCFGR_EL0), access_amu },
+ { SYS_DESC(SYS_AMCGCR_EL0), access_amu },
+ { SYS_DESC(SYS_AMUSERENR_EL0), access_amu },
+ { SYS_DESC(SYS_AMCNTENCLR0_EL0), access_amu },
+ { SYS_DESC(SYS_AMCNTENSET0_EL0), access_amu },
+ { SYS_DESC(SYS_AMCNTENCLR1_EL0), access_amu },
+ { SYS_DESC(SYS_AMCNTENSET1_EL0), access_amu },
+ AMU_AMEVCNTR0_EL0(0),
+ AMU_AMEVCNTR0_EL0(1),
+ AMU_AMEVCNTR0_EL0(2),
+ AMU_AMEVCNTR0_EL0(3),
+ AMU_AMEVCNTR0_EL0(4),
+ AMU_AMEVCNTR0_EL0(5),
+ AMU_AMEVCNTR0_EL0(6),
+ AMU_AMEVCNTR0_EL0(7),
+ AMU_AMEVCNTR0_EL0(8),
+ AMU_AMEVCNTR0_EL0(9),
+ AMU_AMEVCNTR0_EL0(10),
+ AMU_AMEVCNTR0_EL0(11),
+ AMU_AMEVCNTR0_EL0(12),
+ AMU_AMEVCNTR0_EL0(13),
+ AMU_AMEVCNTR0_EL0(14),
+ AMU_AMEVCNTR0_EL0(15),
+ AMU_AMEVTYPE0_EL0(0),
+ AMU_AMEVTYPE0_EL0(1),
+ AMU_AMEVTYPE0_EL0(2),
+ AMU_AMEVTYPE0_EL0(3),
+ AMU_AMEVTYPE0_EL0(4),
+ AMU_AMEVTYPE0_EL0(5),
+ AMU_AMEVTYPE0_EL0(6),
+ AMU_AMEVTYPE0_EL0(7),
+ AMU_AMEVTYPE0_EL0(8),
+ AMU_AMEVTYPE0_EL0(9),
+ AMU_AMEVTYPE0_EL0(10),
+ AMU_AMEVTYPE0_EL0(11),
+ AMU_AMEVTYPE0_EL0(12),
+ AMU_AMEVTYPE0_EL0(13),
+ AMU_AMEVTYPE0_EL0(14),
+ AMU_AMEVTYPE0_EL0(15),
+ AMU_AMEVCNTR1_EL0(0),
+ AMU_AMEVCNTR1_EL0(1),
+ AMU_AMEVCNTR1_EL0(2),
+ AMU_AMEVCNTR1_EL0(3),
+ AMU_AMEVCNTR1_EL0(4),
+ AMU_AMEVCNTR1_EL0(5),
+ AMU_AMEVCNTR1_EL0(6),
+ AMU_AMEVCNTR1_EL0(7),
+ AMU_AMEVCNTR1_EL0(8),
+ AMU_AMEVCNTR1_EL0(9),
+ AMU_AMEVCNTR1_EL0(10),
+ AMU_AMEVCNTR1_EL0(11),
+ AMU_AMEVCNTR1_EL0(12),
+ AMU_AMEVCNTR1_EL0(13),
+ AMU_AMEVCNTR1_EL0(14),
+ AMU_AMEVCNTR1_EL0(15),
+ AMU_AMEVTYPE1_EL0(0),
+ AMU_AMEVTYPE1_EL0(1),
+ AMU_AMEVTYPE1_EL0(2),
+ AMU_AMEVTYPE1_EL0(3),
+ AMU_AMEVTYPE1_EL0(4),
+ AMU_AMEVTYPE1_EL0(5),
+ AMU_AMEVTYPE1_EL0(6),
+ AMU_AMEVTYPE1_EL0(7),
+ AMU_AMEVTYPE1_EL0(8),
+ AMU_AMEVTYPE1_EL0(9),
+ AMU_AMEVTYPE1_EL0(10),
+ AMU_AMEVTYPE1_EL0(11),
+ AMU_AMEVTYPE1_EL0(12),
+ AMU_AMEVTYPE1_EL0(13),
+ AMU_AMEVTYPE1_EL0(14),
+ AMU_AMEVTYPE1_EL0(15),
+
{ SYS_DESC(SYS_CNTP_TVAL_EL0), access_arch_timer },
{ SYS_DESC(SYS_CNTP_CTL_EL0), access_arch_timer },
{ SYS_DESC(SYS_CNTP_CVAL_EL0), access_arch_timer },
--
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: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Fabio Estevam @ 2019-09-17 13:43 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <20190917133317.GQ25745@shell.armlinux.org.uk>
On Tue, Sep 17, 2019 at 10:33 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> That attempts to set bit 12 of the host control register 2 (0x3e).
> The LX2160A documentation states that bit 28 of 0x3c (they're 32-bit
> wide registers there) is "reserved".
>
> So, you're asking for a documented reserved bit to be set...
Correct, v4 is not supported here indeed.
From the LX2160 doc:
"Conforms to the SD Host Controller Standard Specification version 3.0"
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] Documentation: arm64: document support for the AMU extension
From: Ionela Voinescu @ 2019-09-17 13:42 UTC (permalink / raw)
To: catalin.marinas, will, maz, corbet
Cc: Ionela Voinescu, linux-kernel, linux-arm-kernel, linux-doc
In-Reply-To: <20190917134228.5369-1-ionela.voinescu@arm.com>
The activity monitors extension is an optional extension introduced
by the ARMv8.4 CPU architecture.
Add initial documentation for the AMUv1 extension:
- arm64/amu.txt: AMUv1 documentation
- arm64/booting.txt: system registers initialisation
- arm64/cpu-feature-registers.txt: visibility to userspace
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
---
Documentation/arm64/amu.rst | 107 ++++++++++++++++++
Documentation/arm64/booting.rst | 14 +++
Documentation/arm64/cpu-feature-registers.rst | 2 +
Documentation/arm64/index.rst | 1 +
4 files changed, 124 insertions(+)
create mode 100644 Documentation/arm64/amu.rst
diff --git a/Documentation/arm64/amu.rst b/Documentation/arm64/amu.rst
new file mode 100644
index 000000000000..62a6635522e1
--- /dev/null
+++ b/Documentation/arm64/amu.rst
@@ -0,0 +1,107 @@
+=======================================================
+Activity Monitors Unit (AMU) extension in AArch64 Linux
+=======================================================
+
+Author: Ionela Voinescu <ionela.voinescu@arm.com>
+
+Date: 2019-09-10
+
+This document briefly describes the provision of Activity Monitors Unit
+support in AArch64 Linux.
+
+
+Architecture overview
+---------------------
+
+The activity monitors extension is an optional extension introduced by the
+ARMv8.4 CPU architecture.
+
+The activity monitors unit, implemented in each CPU, provides performance
+counters intended for system management use. The AMU extension provides a
+system register interface to the counter registers and also supports an
+optional external memory-mapped interface.
+
+Version 1 of the Activity Monitors architecture implements a counter group
+of four fixed and architecturally defined 64-bit event counters.
+ - CPU cycle counter: increments at the frequency of the CPU.
+ - Constant counter: increments at the fixed frequency of the system
+ clock.
+ - Instructions retired: increments with every architecturally executed
+ instruction.
+ - Memory stall cycles: counts instruction dispatch stall cycles caused by
+ misses in the last level cache within the clock domain.
+
+When in WFI or WFE these counters do not increment.
+
+The Activity Monitors architecture provides space for up to 16 architected
+event counters. Future versions of the architecture may use this space to
+implement additional architected event counters.
+
+Additionally, version 1 implements a counter group of up to 16 auxiliary
+64-bit event counters.
+
+On cold reset all counters reset to 0.
+
+
+Basic support
+-------------
+
+The kernel can safely run a mix of CPUs with and without support for the
+activity monitors extension. Therefore, when CONFIG_ARM64_AMU_EXTN is
+selected we unconditionally enable the capability to allow any late CPU
+(secondary or hotplugged) to detect and use the feature.
+
+When the feature is detected on a CPU, a per-CPU variable (amu_feat) is
+set, but this does not guarantee the correct functionality of the
+counters, only the presence of the extension.
+
+Firmware (code running at higher exception levels, e.g. arm-tf) support is
+needed to:
+ - Enable access for lower exception levels (EL2 and EL1) to the AMU
+ registers.
+ - Enable the counters. If not enabled these will read as 0.
+ - Save/restore the counters before/after the CPU is being put/brought up
+ from the 'off' power state.
+
+When using kernels that have this configuration enabled but boot with
+broken firmware the user may experience panics or lockups when accessing
+the counter registers. Even if these symptoms are not observed, the
+values returned by the register reads might not correctly reflect reality.
+Most commonly, the counters will read as 0, indicating that they are not
+enabled. If proper support is not provided in firmware it's best to disable
+CONFIG_ARM64_AMU_EXTN.
+
+The fixed counters of AMUv1 are accessible though the following system
+register definitions:
+ - SYS_AMEVCNTR0_CORE_EL0
+ - SYS_AMEVCNTR0_CONST_EL0
+ - SYS_AMEVCNTR0_INST_RET_EL0
+ - SYS_AMEVCNTR0_MEM_STALL_EL0
+
+Auxiliary platform specific counters can be accessed using
+SYS_AMEVCNTR1_EL0(n), where n is a value between 0 and 15.
+
+Details can be found in: arch/arm64/include/asm/sysreg.h.
+
+
+Userspace access
+----------------
+
+Currently, access from userspace to the AMU registers is disabled due to:
+ - Security reasons: they might expose information about code executed in
+ secure mode.
+ - Purpose: AMU counters are intended for system management use.
+
+Also, the presence of the feature is not visible to userspace.
+
+
+Virtualization
+--------------
+
+Currently, access from userspace (EL0) and kernelspace (EL1) on the KVM
+guest side is disabled due to:
+ - Security reasons: they might expose information about code executed
+ by other guests or the host.
+
+Any attempt to access the AMU registers will result in an UNDEFINED
+exception being injected into the guest.
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index d3f3a60fbf25..a17f427990d6 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -245,6 +245,20 @@ Before jumping into the kernel, the following conditions must be met:
- HCR_EL2.APK (bit 40) must be initialised to 0b1
- HCR_EL2.API (bit 41) must be initialised to 0b1
+ For CPUs with Activity Monitors Unit v1 (AMUv1) extension present:
+ - If EL3 is present:
+ CPTR_EL3.TAM (bit 30) must be initialised to 0b0
+ CPTR_EL2.TAM (bit 30) must be initialised to 0b0
+ AMCNTENSET0_EL0 must be initialised to 0b1111
+ AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+ - If the kernel is entered at EL1:
+ AMCNTENSET0_EL0 must be initialised to 0b1111
+ AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level.
diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst
index 2955287e9acc..c0effe36e54c 100644
--- a/Documentation/arm64/cpu-feature-registers.rst
+++ b/Documentation/arm64/cpu-feature-registers.rst
@@ -150,6 +150,8 @@ infrastructure:
+------------------------------+---------+---------+
| DIT | [51-48] | y |
+------------------------------+---------+---------+
+ | AMU | [47-44] | n |
+ +------------------------------+---------+---------+
| SVE | [35-32] | y |
+------------------------------+---------+---------+
| GIC | [27-24] | n |
diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst
index 5c0c69dc58aa..09cbb4ed2237 100644
--- a/Documentation/arm64/index.rst
+++ b/Documentation/arm64/index.rst
@@ -6,6 +6,7 @@ ARM64 Architecture
:maxdepth: 1
acpi_object_usage
+ amu
arm-acpi
booting
cpu-feature-registers
--
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: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 13:49 UTC (permalink / raw)
To: Robin Murphy
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <c12e21c3-6bef-38ed-3693-b958be17d555@arm.com>
On Tue, Sep 17, 2019 at 02:38:00PM +0100, Robin Murphy wrote:
> On 17/09/2019 14:07, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
> > > On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
> > > > On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
> > > > > On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
> > > > > > On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
> > > > > > > On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
> > > > > > > > On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
> > > > > > > >
> > > > > > > > > The platform has an iommu, which is in pass-through mode, via
> > > > > > > > > arm_smmu.disable_bypass=0.
> > > > > > > >
> > > > > > > > Could be 954a03be033c7cef80ddc232e7cbdb17df735663
> > > > > > > > "iommu/arm-smmu: Break insecure users by disabling bypass by default"
> > > > > > > >
> > > > > > > > Although it had already landed in v5.2
> > > > > > >
> > > > > > > It is not - and the two lines that you quoted above are sufficient
> > > > > > > to negate that as a cause. (Please read the help for the option that
> > > > > > > the commit referrs to.)
> > > > > > >
> > > > > > > In fact, with bypass disabled, the SoC fails due to other masters.
> > > > > > > That's already been discussed privately between myself and Will
> > > > > > > Deacon.
> > > > > > >
> > > > > > > arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
> > > > > > > the default setting in the Kconfig.
> > > > > >
> > > > > > Adding some further debugging, and fixing the existing ADMA debugging
> > > > > > shows:
> > > > > >
> > > > > > mmc0: ADMA error: 0x02000000
> > > > > >
> > > > > > So this is an ADMA error without the transfer having completed.
> > > > > >
> > > > > > mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> > > > > >
> > > > > > The block size is 8, with one block.
> > > > > >
> > > > > > mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
> > > > > >
> > > > > > The ADMA error is a descriptor error at address 0x000000236df1d20c.
> > > > > > The descriptor table contains (including the following entry):
> > > > > >
> > > > > > mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
> > > > > > mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
> > > > > >
> > > > > > The descriptor table contains one descriptor of 8 bytes, is marked
> > > > > > as the last (END bit set) and is at DMA address 0x236df1d200. The
> > > > > > following descriptor is empty, with VALID=0.
> > > > > >
> > > > > > One may be tempted to blame it on the following descriptor, but having
> > > > > > had another example on eMMC while userspace was booting (rootfs on
> > > > > > eMMC):
> > > > > >
> > > > > > mmc1: ADMA error: 0x02000000
> > > > > > mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
> > > > > > mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
> > > > > > mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
> > > > > > mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
> > > > > >
> > > > > > ... which is interesting for several reasons:
> > > > > > - The ADMA error register indicates a length mismatch error. The
> > > > > > transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
> > > > > > Summing the ADMA lengths up to the last descriptor (length=0 is
> > > > > > 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
> > > > > > bytes than the requested transfer.
> > > > > >
> > > > > > - The ADMA error register indicates ST_CADR, which is described as
> > > > > > "This state is never set because do not generate ADMA error in this
> > > > > > state."
> > > > > >
> > > > > > - The error descriptor is again after the descriptor with END=1, but
> > > > > > this time has VALID=1.
> > > > > >
> > > > > > This _feels_ like a coherency issue, where the SDHCI engine is not
> > > > > > correctly seeing the descriptor table, but then I would have expected
> > > > > > userspace (which is basically debian stable) to fail to boot every
> > > > > > time given that its rootfs is on eMMC.
> > > > > >
> > > > > > The other weird thing is if I wind the core MMC code back via:
> > > > > >
> > > > > > $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
> > > > > >
> > > > > > and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
> > > > > > completely stable, but way better than plain v5.3. I don't see
> > > > > > much in that diff which would be responsible for this - although it
> > > > > > does seem that hch's DMA changes do make the problem more likely.
> > > > > > (going from 1 in 3 boots with a problem to being not able to boot.)
> > > > > >
> > > > > > Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
> > > > > > bypass mode on the IOMMU (but then I saw global smmu errors right
> > > > > > from when the IOMMU had bypass disabled before MMC was probed - the
> > > > > > reason being is the SoC is not currently setup to have the MMU
> > > > > > bypass mode disabled.)
> > > > >
> > > > > This looks like an ARM64 coherency issue.
> > > > >
> > > > > I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
> > > > > which had no effect. I then tried adding:
> > > > >
> > > > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > > > + dma_wmb();
> > > > >
> > > > > and so far I haven't had any further ADMA errors. Adding Will Deacon
> > > > > to the thread.
> > > >
> > > > These are the changes to sdhci that I'm currently running. I think
> > > > some of the debugging related changes are probably worth adding to
> > > > the driver, particularly printing the intmask on ADMA error (which
> > > > is not printed by the register dump, as the value is lost) and printing
> > > > the DMA addresses of the descriptor table entries which can be tied
> > > > up with the DMA address error register. Also, maybe printing the
> > > > DMA descriptor table with the register dump, rather than having to
> > > > resort to enabling debug would be a good idea?
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > > index a5dc5aae973e..884dcaa9cad5 100644
> > > > --- a/drivers/mmc/host/sdhci.c
> > > > +++ b/drivers/mmc/host/sdhci.c
> > > > @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
> > > > /* Add a terminating entry - nop, end, valid */
> > > > __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
> > > > }
> > > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > > + dma_wmb();
> > > > }
> > > > static void sdhci_adma_table_post(struct sdhci_host *host,
> > > > @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
> > > > static void sdhci_adma_show_error(struct sdhci_host *host)
> > > > {
> > > > void *desc = host->adma_table;
> > > > + dma_addr_t dma = host->adma_addr;
> > > > + bool end = false;
> > > > sdhci_dumpregs(host);
> > > > @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
> > > > struct sdhci_adma2_64_desc *dma_desc = desc;
> > > > if (host->flags & SDHCI_USE_64_BIT_DMA)
> > > > - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > - desc, le32_to_cpu(dma_desc->addr_hi),
> > > > + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > + (unsigned long long)dma,
> > > > + le32_to_cpu(dma_desc->addr_hi),
> > > > le32_to_cpu(dma_desc->addr_lo),
> > > > le16_to_cpu(dma_desc->len),
> > > > le16_to_cpu(dma_desc->cmd));
> > > > else
> > > > - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > - desc, le32_to_cpu(dma_desc->addr_lo),
> > > > + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > + (unsigned long long)dma,
> > > > + le32_to_cpu(dma_desc->addr_lo),
> > > > le16_to_cpu(dma_desc->len),
> > > > le16_to_cpu(dma_desc->cmd));
> > > > + if (end) break;
> > > > +
> > > > desc += host->desc_sz;
> > > > + dma += host->desc_sz;
> > > > if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
> > > > - break;
> > > > + end = true;
> > > > }
> > > > }
> > > > @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
> > > > != MMC_BUS_TEST_R)
> > > > host->data->error = -EILSEQ;
> > > > else if (intmask & SDHCI_INT_ADMA_ERROR) {
> > > > - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
> > > > + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
> > > > sdhci_adma_show_error(host);
> > > > host->data->error = -EIO;
> > > > if (host->ops->adma_workaround)
> > >
> > > Further debug shows:
> > >
> > > coherent=0 - sdhci device is not cache coherent
> > > swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
> > > [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
> > > pmd=000000237fffb003, pte=00e800236d62270f
> > >
> > > The mapping for the ADMA table seems to be using MAIR index 3, which is
> > > MT_MEMORY_NC, so should be non-cacheable.
> > >
> > > vmallocinfo:
> > > 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
> > > user
> > >
> > > So this memory has been remapped. Could there be an alias that has
> > > cache lines still in the cache for the physical address, and could we
> > > be hitting those cache lines while accessing through a non-cacheable
> > > mapping? (On 32-bit ARM, this is "unpredictable" and this problem
> > > definitely _feels_ like it has unpredictable attributes!)
> > >
> > > Also, given that this memory is mapped NC, then surely
> > > __dma_flush_area() should have no effect? However, it _does_ have the
> > > effect of reliably solving the problem, which to me implies that there
> > > _are_ cache lines in this NC mapping.
> >
> > Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
> > alloc_pages for single pages") which has been implicated in the same
> > problem here:
> >
> > https://www.spinics.net/lists/arm-kernel/msg750623.html
> >
> > Although reverting the commit is not clean, this also fixes the issue
> > for me.
>
> Note that that one turned out to be something totally different, namely that
> the single-page allocations, in difference to CMA, came from physical
> addresses that the controller needed additional configuration to be able to
> access[1] - no amount of cache maintenance would affect that.
As already replied, v4 mode is not documented as being available on
the LX2160A - the bit in the control register is marked as "reserved".
This is as expected as it is documented that it is using a v3.00 of
the SDHCI standard, rather than v4.00.
So, sorry, enabling "v4 mode" isn't a workaround in this scenario.
Given that v4 mode is not mandatory, this shouldn't be a work-around.
Given that it _does_ work some of the time with the table >4GB, then
this is not an addressing limitation.
> However, the other difference between getting a single page directly from
> the page allocator vs. the CMA area is that accesses to the linear mapping
> of the CMA area are probably pretty rare, whereas for the single-page case
> it's much more likely that kernel tasks using adjacent pages could lead to
> prefetching of the descriptor page's cacheable alias. That could certainly
> explain how reverting that commit manages to hide an apparent coherency
> issue.
Right, so how do we fix this?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Will Deacon @ 2019-09-17 13:50 UTC (permalink / raw)
To: Robin Murphy
Cc: dann frazier, Will Deacon, Russell King - ARM Linux admin,
Adrian Hunter, Nicolin Chen, linux-mmc, Christoph Hellwig,
Linux ARM
In-Reply-To: <c12e21c3-6bef-38ed-3693-b958be17d555@arm.com>
On Tue, Sep 17, 2019 at 02:38:00PM +0100, Robin Murphy wrote:
> On 17/09/2019 14:07, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
> > > On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
> > > > On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
> > > > > On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
> > > > > > On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
> > > > > > > On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
> > > > > > > > On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
> > > > > > > >
> > > > > > > > > The platform has an iommu, which is in pass-through mode, via
> > > > > > > > > arm_smmu.disable_bypass=0.
> > > > > > > >
> > > > > > > > Could be 954a03be033c7cef80ddc232e7cbdb17df735663
> > > > > > > > "iommu/arm-smmu: Break insecure users by disabling bypass by default"
> > > > > > > >
> > > > > > > > Although it had already landed in v5.2
> > > > > > >
> > > > > > > It is not - and the two lines that you quoted above are sufficient
> > > > > > > to negate that as a cause. (Please read the help for the option that
> > > > > > > the commit referrs to.)
> > > > > > >
> > > > > > > In fact, with bypass disabled, the SoC fails due to other masters.
> > > > > > > That's already been discussed privately between myself and Will
> > > > > > > Deacon.
> > > > > > >
> > > > > > > arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
> > > > > > > the default setting in the Kconfig.
> > > > > >
> > > > > > Adding some further debugging, and fixing the existing ADMA debugging
> > > > > > shows:
> > > > > >
> > > > > > mmc0: ADMA error: 0x02000000
> > > > > >
> > > > > > So this is an ADMA error without the transfer having completed.
> > > > > >
> > > > > > mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> > > > > >
> > > > > > The block size is 8, with one block.
> > > > > >
> > > > > > mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
> > > > > >
> > > > > > The ADMA error is a descriptor error at address 0x000000236df1d20c.
> > > > > > The descriptor table contains (including the following entry):
> > > > > >
> > > > > > mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
> > > > > > mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
> > > > > >
> > > > > > The descriptor table contains one descriptor of 8 bytes, is marked
> > > > > > as the last (END bit set) and is at DMA address 0x236df1d200. The
> > > > > > following descriptor is empty, with VALID=0.
> > > > > >
> > > > > > One may be tempted to blame it on the following descriptor, but having
> > > > > > had another example on eMMC while userspace was booting (rootfs on
> > > > > > eMMC):
> > > > > >
> > > > > > mmc1: ADMA error: 0x02000000
> > > > > > mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
> > > > > > mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
> > > > > > mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
> > > > > > mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
> > > > > > mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
> > > > > >
> > > > > > ... which is interesting for several reasons:
> > > > > > - The ADMA error register indicates a length mismatch error. The
> > > > > > transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
> > > > > > Summing the ADMA lengths up to the last descriptor (length=0 is
> > > > > > 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
> > > > > > bytes than the requested transfer.
> > > > > >
> > > > > > - The ADMA error register indicates ST_CADR, which is described as
> > > > > > "This state is never set because do not generate ADMA error in this
> > > > > > state."
> > > > > >
> > > > > > - The error descriptor is again after the descriptor with END=1, but
> > > > > > this time has VALID=1.
> > > > > >
> > > > > > This _feels_ like a coherency issue, where the SDHCI engine is not
> > > > > > correctly seeing the descriptor table, but then I would have expected
> > > > > > userspace (which is basically debian stable) to fail to boot every
> > > > > > time given that its rootfs is on eMMC.
> > > > > >
> > > > > > The other weird thing is if I wind the core MMC code back via:
> > > > > >
> > > > > > $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
> > > > > >
> > > > > > and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
> > > > > > completely stable, but way better than plain v5.3. I don't see
> > > > > > much in that diff which would be responsible for this - although it
> > > > > > does seem that hch's DMA changes do make the problem more likely.
> > > > > > (going from 1 in 3 boots with a problem to being not able to boot.)
> > > > > >
> > > > > > Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
> > > > > > bypass mode on the IOMMU (but then I saw global smmu errors right
> > > > > > from when the IOMMU had bypass disabled before MMC was probed - the
> > > > > > reason being is the SoC is not currently setup to have the MMU
> > > > > > bypass mode disabled.)
> > > > >
> > > > > This looks like an ARM64 coherency issue.
> > > > >
> > > > > I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
> > > > > which had no effect. I then tried adding:
> > > > >
> > > > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > > > + dma_wmb();
> > > > >
> > > > > and so far I haven't had any further ADMA errors. Adding Will Deacon
> > > > > to the thread.
> > > >
> > > > These are the changes to sdhci that I'm currently running. I think
> > > > some of the debugging related changes are probably worth adding to
> > > > the driver, particularly printing the intmask on ADMA error (which
> > > > is not printed by the register dump, as the value is lost) and printing
> > > > the DMA addresses of the descriptor table entries which can be tied
> > > > up with the DMA address error register. Also, maybe printing the
> > > > DMA descriptor table with the register dump, rather than having to
> > > > resort to enabling debug would be a good idea?
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > > index a5dc5aae973e..884dcaa9cad5 100644
> > > > --- a/drivers/mmc/host/sdhci.c
> > > > +++ b/drivers/mmc/host/sdhci.c
> > > > @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
> > > > /* Add a terminating entry - nop, end, valid */
> > > > __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
> > > > }
> > > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > > + dma_wmb();
> > > > }
> > > > static void sdhci_adma_table_post(struct sdhci_host *host,
> > > > @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
> > > > static void sdhci_adma_show_error(struct sdhci_host *host)
> > > > {
> > > > void *desc = host->adma_table;
> > > > + dma_addr_t dma = host->adma_addr;
> > > > + bool end = false;
> > > > sdhci_dumpregs(host);
> > > > @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
> > > > struct sdhci_adma2_64_desc *dma_desc = desc;
> > > > if (host->flags & SDHCI_USE_64_BIT_DMA)
> > > > - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > - desc, le32_to_cpu(dma_desc->addr_hi),
> > > > + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > + (unsigned long long)dma,
> > > > + le32_to_cpu(dma_desc->addr_hi),
> > > > le32_to_cpu(dma_desc->addr_lo),
> > > > le16_to_cpu(dma_desc->len),
> > > > le16_to_cpu(dma_desc->cmd));
> > > > else
> > > > - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > - desc, le32_to_cpu(dma_desc->addr_lo),
> > > > + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > + (unsigned long long)dma,
> > > > + le32_to_cpu(dma_desc->addr_lo),
> > > > le16_to_cpu(dma_desc->len),
> > > > le16_to_cpu(dma_desc->cmd));
> > > > + if (end) break;
> > > > +
> > > > desc += host->desc_sz;
> > > > + dma += host->desc_sz;
> > > > if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
> > > > - break;
> > > > + end = true;
> > > > }
> > > > }
> > > > @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
> > > > != MMC_BUS_TEST_R)
> > > > host->data->error = -EILSEQ;
> > > > else if (intmask & SDHCI_INT_ADMA_ERROR) {
> > > > - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
> > > > + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
> > > > sdhci_adma_show_error(host);
> > > > host->data->error = -EIO;
> > > > if (host->ops->adma_workaround)
> > >
> > > Further debug shows:
> > >
> > > coherent=0 - sdhci device is not cache coherent
> > > swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
> > > [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
> > > pmd=000000237fffb003, pte=00e800236d62270f
> > >
> > > The mapping for the ADMA table seems to be using MAIR index 3, which is
> > > MT_MEMORY_NC, so should be non-cacheable.
> > >
> > > vmallocinfo:
> > > 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
> > > user
> > >
> > > So this memory has been remapped. Could there be an alias that has
> > > cache lines still in the cache for the physical address, and could we
> > > be hitting those cache lines while accessing through a non-cacheable
> > > mapping? (On 32-bit ARM, this is "unpredictable" and this problem
> > > definitely _feels_ like it has unpredictable attributes!)
> > >
> > > Also, given that this memory is mapped NC, then surely
> > > __dma_flush_area() should have no effect? However, it _does_ have the
> > > effect of reliably solving the problem, which to me implies that there
> > > _are_ cache lines in this NC mapping.
> >
> > Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
> > alloc_pages for single pages") which has been implicated in the same
> > problem here:
> >
> > https://www.spinics.net/lists/arm-kernel/msg750623.html
> >
> > Although reverting the commit is not clean, this also fixes the issue
> > for me.
>
> Note that that one turned out to be something totally different, namely that
> the single-page allocations, in difference to CMA, came from physical
> addresses that the controller needed additional configuration to be able to
> access[1] - no amount of cache maintenance would affect that.
To be honest, the conclusion in that other thread wasn't exactly satisfying.
The reporter says "Probably, my device is not 64-bit capable." and the fix
changes the buffer allocation enough that I wouldn't rule out the same
coherency issue as being the root cause. I don't think we ever tried adding
cache flushing to see if it helped.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 13:51 UTC (permalink / raw)
To: Fabio Estevam
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <CAOMZO5DS_1Uc9TMc29e+8tCg-srvMjf3uth_9P3cnro6det+7A@mail.gmail.com>
On Tue, Sep 17, 2019 at 10:43:35AM -0300, Fabio Estevam wrote:
> On Tue, Sep 17, 2019 at 10:33 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
>
> > That attempts to set bit 12 of the host control register 2 (0x3e).
> > The LX2160A documentation states that bit 28 of 0x3c (they're 32-bit
> > wide registers there) is "reserved".
> >
> > So, you're asking for a documented reserved bit to be set...
>
> Correct, v4 is not supported here indeed.
>
> From the LX2160 doc:
> "Conforms to the SD Host Controller Standard Specification version 3.0"
The pressing question seems to be this:
Are the eSDHC on the LX2160A DMA coherent or are they not?
Any chances of finding out internally what the true answer to that,
rather than me poking about trying stuff experimentally? Having a
definitive answer for a potentially data-corrupting change would
be really good...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pwm: stm32-lp: add check in case requested period cannot be achieved
From: Fabrice Gasnier @ 2019-09-17 13:51 UTC (permalink / raw)
To: thierry.reding
Cc: linux-pwm, alexandre.torgue, linux-kernel, mcoquelin.stm32,
fabrice.gasnier, linux-arm-kernel
LPTimer can use a 32KHz clock for counting. It depends on clock tree
configuration. In such a case, PWM output frequency range is limited.
Although unlikely, nothing prevents user from requesting a PWM frequency
above counting clock (32KHz for instance):
- This causes (prd - 1) = 0xffff to be written in ARR register later in
the apply() routine.
This results in badly configured PWM period (and also duty_cycle).
Add a check to report an error is such a case.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
drivers/pwm/pwm-stm32-lp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 2211a64..5c2c728 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -59,6 +59,12 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
/* Calculate the period and prescaler value */
div = (unsigned long long)clk_get_rate(priv->clk) * state->period;
do_div(div, NSEC_PER_SEC);
+ if (!div) {
+ /* Fall here in case source clock < period */
+ dev_err(priv->chip.dev, "Can't reach expected period\n");
+ return -EINVAL;
+ }
+
prd = div;
while (div > STM32_LPTIM_MAX_ARR) {
presc++;
--
2.7.4
_______________________________________________
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: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Robin Murphy @ 2019-09-17 13:55 UTC (permalink / raw)
To: Will Deacon
Cc: dann frazier, Will Deacon, Russell King - ARM Linux admin,
Adrian Hunter, Nicolin Chen, linux-mmc, Christoph Hellwig,
Linux ARM
In-Reply-To: <20190917135002.5rolyvlgmnyepk2c@willie-the-truck>
On 17/09/2019 14:50, Will Deacon wrote:
> On Tue, Sep 17, 2019 at 02:38:00PM +0100, Robin Murphy wrote:
>> On 17/09/2019 14:07, Russell King - ARM Linux admin wrote:
>>> On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
>>>> On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
>>>>> On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
>>>>>> On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
>>>>>>> On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
>>>>>>>> On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
>>>>>>>>> On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
>>>>>>>>>
>>>>>>>>>> The platform has an iommu, which is in pass-through mode, via
>>>>>>>>>> arm_smmu.disable_bypass=0.
>>>>>>>>>
>>>>>>>>> Could be 954a03be033c7cef80ddc232e7cbdb17df735663
>>>>>>>>> "iommu/arm-smmu: Break insecure users by disabling bypass by default"
>>>>>>>>>
>>>>>>>>> Although it had already landed in v5.2
>>>>>>>>
>>>>>>>> It is not - and the two lines that you quoted above are sufficient
>>>>>>>> to negate that as a cause. (Please read the help for the option that
>>>>>>>> the commit referrs to.)
>>>>>>>>
>>>>>>>> In fact, with bypass disabled, the SoC fails due to other masters.
>>>>>>>> That's already been discussed privately between myself and Will
>>>>>>>> Deacon.
>>>>>>>>
>>>>>>>> arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
>>>>>>>> the default setting in the Kconfig.
>>>>>>>
>>>>>>> Adding some further debugging, and fixing the existing ADMA debugging
>>>>>>> shows:
>>>>>>>
>>>>>>> mmc0: ADMA error: 0x02000000
>>>>>>>
>>>>>>> So this is an ADMA error without the transfer having completed.
>>>>>>>
>>>>>>> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
>>>>>>>
>>>>>>> The block size is 8, with one block.
>>>>>>>
>>>>>>> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
>>>>>>>
>>>>>>> The ADMA error is a descriptor error at address 0x000000236df1d20c.
>>>>>>> The descriptor table contains (including the following entry):
>>>>>>>
>>>>>>> mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
>>>>>>> mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
>>>>>>>
>>>>>>> The descriptor table contains one descriptor of 8 bytes, is marked
>>>>>>> as the last (END bit set) and is at DMA address 0x236df1d200. The
>>>>>>> following descriptor is empty, with VALID=0.
>>>>>>>
>>>>>>> One may be tempted to blame it on the following descriptor, but having
>>>>>>> had another example on eMMC while userspace was booting (rootfs on
>>>>>>> eMMC):
>>>>>>>
>>>>>>> mmc1: ADMA error: 0x02000000
>>>>>>> mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
>>>>>>> mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
>>>>>>> mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
>>>>>>> mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
>>>>>>>
>>>>>>> ... which is interesting for several reasons:
>>>>>>> - The ADMA error register indicates a length mismatch error. The
>>>>>>> transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
>>>>>>> Summing the ADMA lengths up to the last descriptor (length=0 is
>>>>>>> 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
>>>>>>> bytes than the requested transfer.
>>>>>>>
>>>>>>> - The ADMA error register indicates ST_CADR, which is described as
>>>>>>> "This state is never set because do not generate ADMA error in this
>>>>>>> state."
>>>>>>>
>>>>>>> - The error descriptor is again after the descriptor with END=1, but
>>>>>>> this time has VALID=1.
>>>>>>>
>>>>>>> This _feels_ like a coherency issue, where the SDHCI engine is not
>>>>>>> correctly seeing the descriptor table, but then I would have expected
>>>>>>> userspace (which is basically debian stable) to fail to boot every
>>>>>>> time given that its rootfs is on eMMC.
>>>>>>>
>>>>>>> The other weird thing is if I wind the core MMC code back via:
>>>>>>>
>>>>>>> $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
>>>>>>>
>>>>>>> and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
>>>>>>> completely stable, but way better than plain v5.3. I don't see
>>>>>>> much in that diff which would be responsible for this - although it
>>>>>>> does seem that hch's DMA changes do make the problem more likely.
>>>>>>> (going from 1 in 3 boots with a problem to being not able to boot.)
>>>>>>>
>>>>>>> Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
>>>>>>> bypass mode on the IOMMU (but then I saw global smmu errors right
>>>>>>> from when the IOMMU had bypass disabled before MMC was probed - the
>>>>>>> reason being is the SoC is not currently setup to have the MMU
>>>>>>> bypass mode disabled.)
>>>>>>
>>>>>> This looks like an ARM64 coherency issue.
>>>>>>
>>>>>> I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
>>>>>> which had no effect. I then tried adding:
>>>>>>
>>>>>> + __dma_flush_area(host->adma_table, desc - host->adma_table);
>>>>>> + dma_wmb();
>>>>>>
>>>>>> and so far I haven't had any further ADMA errors. Adding Will Deacon
>>>>>> to the thread.
>>>>>
>>>>> These are the changes to sdhci that I'm currently running. I think
>>>>> some of the debugging related changes are probably worth adding to
>>>>> the driver, particularly printing the intmask on ADMA error (which
>>>>> is not printed by the register dump, as the value is lost) and printing
>>>>> the DMA addresses of the descriptor table entries which can be tied
>>>>> up with the DMA address error register. Also, maybe printing the
>>>>> DMA descriptor table with the register dump, rather than having to
>>>>> resort to enabling debug would be a good idea?
>>>>>
>>>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>>>> index a5dc5aae973e..884dcaa9cad5 100644
>>>>> --- a/drivers/mmc/host/sdhci.c
>>>>> +++ b/drivers/mmc/host/sdhci.c
>>>>> @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
>>>>> /* Add a terminating entry - nop, end, valid */
>>>>> __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
>>>>> }
>>>>> + __dma_flush_area(host->adma_table, desc - host->adma_table);
>>>>> + dma_wmb();
>>>>> }
>>>>> static void sdhci_adma_table_post(struct sdhci_host *host,
>>>>> @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
>>>>> static void sdhci_adma_show_error(struct sdhci_host *host)
>>>>> {
>>>>> void *desc = host->adma_table;
>>>>> + dma_addr_t dma = host->adma_addr;
>>>>> + bool end = false;
>>>>> sdhci_dumpregs(host);
>>>>> @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
>>>>> struct sdhci_adma2_64_desc *dma_desc = desc;
>>>>> if (host->flags & SDHCI_USE_64_BIT_DMA)
>>>>> - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> - desc, le32_to_cpu(dma_desc->addr_hi),
>>>>> + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> + (unsigned long long)dma,
>>>>> + le32_to_cpu(dma_desc->addr_hi),
>>>>> le32_to_cpu(dma_desc->addr_lo),
>>>>> le16_to_cpu(dma_desc->len),
>>>>> le16_to_cpu(dma_desc->cmd));
>>>>> else
>>>>> - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> - desc, le32_to_cpu(dma_desc->addr_lo),
>>>>> + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> + (unsigned long long)dma,
>>>>> + le32_to_cpu(dma_desc->addr_lo),
>>>>> le16_to_cpu(dma_desc->len),
>>>>> le16_to_cpu(dma_desc->cmd));
>>>>> + if (end) break;
>>>>> +
>>>>> desc += host->desc_sz;
>>>>> + dma += host->desc_sz;
>>>>> if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
>>>>> - break;
>>>>> + end = true;
>>>>> }
>>>>> }
>>>>> @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
>>>>> != MMC_BUS_TEST_R)
>>>>> host->data->error = -EILSEQ;
>>>>> else if (intmask & SDHCI_INT_ADMA_ERROR) {
>>>>> - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
>>>>> + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
>>>>> sdhci_adma_show_error(host);
>>>>> host->data->error = -EIO;
>>>>> if (host->ops->adma_workaround)
>>>>
>>>> Further debug shows:
>>>>
>>>> coherent=0 - sdhci device is not cache coherent
>>>> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
>>>> [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
>>>> pmd=000000237fffb003, pte=00e800236d62270f
>>>>
>>>> The mapping for the ADMA table seems to be using MAIR index 3, which is
>>>> MT_MEMORY_NC, so should be non-cacheable.
>>>>
>>>> vmallocinfo:
>>>> 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
>>>> user
>>>>
>>>> So this memory has been remapped. Could there be an alias that has
>>>> cache lines still in the cache for the physical address, and could we
>>>> be hitting those cache lines while accessing through a non-cacheable
>>>> mapping? (On 32-bit ARM, this is "unpredictable" and this problem
>>>> definitely _feels_ like it has unpredictable attributes!)
>>>>
>>>> Also, given that this memory is mapped NC, then surely
>>>> __dma_flush_area() should have no effect? However, it _does_ have the
>>>> effect of reliably solving the problem, which to me implies that there
>>>> _are_ cache lines in this NC mapping.
>>>
>>> Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
>>> alloc_pages for single pages") which has been implicated in the same
>>> problem here:
>>>
>>> https://www.spinics.net/lists/arm-kernel/msg750623.html
>>>
>>> Although reverting the commit is not clean, this also fixes the issue
>>> for me.
>>
>> Note that that one turned out to be something totally different, namely that
>> the single-page allocations, in difference to CMA, came from physical
>> addresses that the controller needed additional configuration to be able to
>> access[1] - no amount of cache maintenance would affect that.
>
> To be honest, the conclusion in that other thread wasn't exactly satisfying.
> The reporter says "Probably, my device is not 64-bit capable." and the fix
> changes the buffer allocation enough that I wouldn't rule out the same
> coherency issue as being the root cause. I don't think we ever tried adding
> cache flushing to see if it helped.
Huh? The conclusion of that thread seemed pretty clear to me:
https://lore.kernel.org/linux-arm-kernel/CAK7LNASs2qkpGY_BkL--hvmKm3FJ9sEK4+v5VVYc1_CrowAB4w@mail.gmail.com/
which is where I linked that patch from :/
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: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Fabio Estevam @ 2019-09-17 13:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Li Yang
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <20190917135157.GT25745@shell.armlinux.org.uk>
[Adding Li Yang]
On Tue, Sep 17, 2019 at 10:52 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> The pressing question seems to be this:
>
> Are the eSDHC on the LX2160A DMA coherent or are they not?
>
> Any chances of finding out internally what the true answer to that,
> rather than me poking about trying stuff experimentally? Having a
> definitive answer for a potentially data-corrupting change would
> be really good...
Li Yang,
Could you please help to confirm Russell's question?
_______________________________________________
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