Re: [PATCH 6/6] mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that are newer than 5.4
On Fri, Sep 4, 2020 at 1:25 AM Douglas Anderson wrote:
> This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous
> probe") but applied to a whole pile of drivers. This batch converts
> the drivers that appeared to have been added after kernel 5.4.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/mmc/host/meson-mx-sdhc-mmc.c | 1 +
> drivers/mmc/host/owl-mmc.c | 1 +
> drivers/mmc/host/sdhci-esdhc-mcf.c | 1 +
> drivers/mmc/host/sdhci-milbeaut.c| 1 +
> drivers/mmc/host/sdhci-of-sparx5.c | 1 +
> 5 files changed, 5 insertions(+)
[snip]
>
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-mcf.c
> b/drivers/mmc/host/sdhci-esdhc-mcf.c
> index 71bf086a9812..ca7a1690b2a8 100644
> --- a/drivers/mmc/host/sdhci-esdhc-mcf.c
> +++ b/drivers/mmc/host/sdhci-esdhc-mcf.c
> @@ -509,6 +509,7 @@ static int sdhci_esdhc_mcf_remove(struct platform_device
> *pdev)
> static struct platform_driver sdhci_esdhc_mcf_driver = {
> .driver = {
> .name = "sdhci-esdhc-mcf",
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> },
> .probe = sdhci_esdhc_mcf_probe,
> .remove = sdhci_esdhc_mcf_remove,
>
Acked-by: Angelo Dureghello
Re: [PATCH v1] dmaengine: fsl-edma-common: correct DSIZE_32BYTE
Hi Robin,
29.06.2020, 10:53, "Robin Gong" :
> Correct EDMA_TCD_ATTR_DSIZE_32BYTE define since it's broken by the below:
> '0x0005 --> BIT(3) | BIT(0))'
>
> Fixes: 4d6d3a90e4ac ("dmaengine: fsl-edma: fix macros")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Robin Gong
> ---
> drivers/dma/fsl-edma-common.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/fsl-edma-common.h b/drivers/dma/fsl-edma-common.h
> index 67e4225..ec11697 100644
> --- a/drivers/dma/fsl-edma-common.h
> +++ b/drivers/dma/fsl-edma-common.h
> @@ -33,7 +33,7 @@
> #define EDMA_TCD_ATTR_DSIZE_16BIT BIT(0)
> #define EDMA_TCD_ATTR_DSIZE_32BIT BIT(1)
> #define EDMA_TCD_ATTR_DSIZE_64BIT (BIT(0) | BIT(1))
> -#define EDMA_TCD_ATTR_DSIZE_32BYTE (BIT(3) | BIT(0))
> +#define EDMA_TCD_ATTR_DSIZE_32BYTE (BIT(2) | BIT(0))
looks like i need some glasses. Thanks a lot for the fix.
I probably missed it since not using 16bytes transfers.
Tested-by: Angelo Dureghello
Regards,
angelo
> #define EDMA_TCD_ATTR_SSIZE_8BIT 0
> #define EDMA_TCD_ATTR_SSIZE_16BIT (EDMA_TCD_ATTR_DSIZE_16BIT << 8)
> #define EDMA_TCD_ATTR_SSIZE_32BIT (EDMA_TCD_ATTR_DSIZE_32BIT << 8)
> --
> 2.7.4
[PATCH] w1: ds2430: fix eeprom size in driver description
Non functional fix, set Kb to b, to avoid any misundertanding.
Signed-off-by: Angelo Dureghello
---
drivers/w1/slaves/w1_ds2430.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/w1/slaves/w1_ds2430.c b/drivers/w1/slaves/w1_ds2430.c
index 6fb0563fb2ae..75bb8a88620b 100644
--- a/drivers/w1/slaves/w1_ds2430.c
+++ b/drivers/w1/slaves/w1_ds2430.c
@@ -290,6 +290,6 @@ static struct w1_family w1_family_14 = {
module_w1_family(w1_family_14);
MODULE_AUTHOR("Angelo Dureghello ");
-MODULE_DESCRIPTION("w1 family 14 driver for DS2430, 256kb EEPROM");
+MODULE_DESCRIPTION("w1 family 14 driver for DS2430, 256b EEPROM");
MODULE_LICENSE("GPL");
MODULE_ALIAS("w1-family-" __stringify(W1_EEPROM_DS2430));
--
2.26.2
[PATCH v2] w1: new driver. DS2430 chip
add support for ds2430, 1 page, 256bit (32bytes) eeprom
(family 0x14).
Tests done:
32 bytes dump:
x@y:~# hexdump -C -n 32 /sys/bus/w1/devices/14-0158556e/eeprom
39 39 0a 00 00 36 0a ff ff ff ff ff ff ff ff ff
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0020
34 bytes dump: 32 only displayed
x@y:~# hexdump -C -n 34 /sys/bus/w1/devices/14-0158556e/eeprom
39 39 0a 00 00 36 0a ff ff ff ff ff ff ff ff ff
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0020
pattern write:
x@y:~# echo 123456789 > /sys/bus/w1/devices/14-0158556e/eeprom
x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-0158556e/eeprom
31 32 33 34 35 36 37 38 39 0a ff ff ff ff ff ff
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0020
specific address 1-byte write
x@y:~# dd if=/dev/zero of=/sys/bus/w1/devices/14-0158556e/eeprom \
count=1 bs=1 seek=4
1+0 records in
1+0 records out
x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-0158556e/eeprom
31 32 33 34 00 36 37 38 39 0a ff ff ff ff ff ff
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0020
writing binary block
x@y:~# cat dump-128bytes.bin > /sys/bus/w1/devices/14-0158556e/eeprom
cat: write error: File too large
x@y:~# cat dump-32bytes.bin > /sys/bus/w1/devices/14-0158556e/eeprom
x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-0158556e/eeprom
10 0b 5b ff ff ff ff ff ff ff ff ff ff ff ff ff
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 40
0020
Signed-off-by: Angelo Dureghello
---
drivers/w1/slaves/Kconfig | 8 +
drivers/w1/slaves/Makefile| 1 +
drivers/w1/slaves/w1_ds2430.c | 295 ++
3 files changed, 304 insertions(+)
create mode 100644 drivers/w1/slaves/w1_ds2430.c
diff --git a/drivers/w1/slaves/Kconfig b/drivers/w1/slaves/Kconfig
index b7847636501d..687753889c34 100644
--- a/drivers/w1/slaves/Kconfig
+++ b/drivers/w1/slaves/Kconfig
@@ -74,6 +74,14 @@ config W1_SLAVE_DS2805
organized as 7 pages of 16 bytes each with 64bit
unique number. Requires OverDrive Speed to talk to.
+config W1_SLAVE_DS2430
+ tristate "256b EEPROM family support (DS2430)"
+ help
+ Say Y here if you want to use a 1-wire 256bit EEPROM
+ family device (DS2430).
+ This EEPROM is organized as one page of 32 bytes for random
+ access.
+
config W1_SLAVE_DS2431
tristate "1kb EEPROM family support (DS2431)"
help
diff --git a/drivers/w1/slaves/Makefile b/drivers/w1/slaves/Makefile
index 8e9655eaa478..278bcf2a9bfd 100644
--- a/drivers/w1/slaves/Makefile
+++ b/drivers/w1/slaves/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_W1_SLAVE_DS2408) += w1_ds2408.o
obj-$(CONFIG_W1_SLAVE_DS2413) += w1_ds2413.o
obj-$(CONFIG_W1_SLAVE_DS2406) += w1_ds2406.o
obj-$(CONFIG_W1_SLAVE_DS2423) += w1_ds2423.o
+obj-$(CONFIG_W1_SLAVE_DS2430) += w1_ds2430.o
obj-$(CONFIG_W1_SLAVE_DS2431) += w1_ds2431.o
obj-$(CONFIG_W1_SLAVE_DS2805) += w1_ds2805.o
obj-$(CONFIG_W1_SLAVE_DS2433) += w1_ds2433.o
diff --git a/drivers/w1/slaves/w1_ds2430.c b/drivers/w1/slaves/w1_ds2430.c
new file mode 100644
index ..6fb0563fb2ae
--- /dev/null
+++ b/drivers/w1/slaves/w1_ds2430.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * w1_ds2430.c - w1 family 14 (DS2430) driver
+ **
+ * Copyright (c) 2019 Angelo Dureghello
+ *
+ * Cloned and modified from ds2431
+ * Copyright (c) 2008 Bernhard Weirich
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define W1_EEPROM_DS2430 0x14
+
+#define W1_F14_EEPROM_SIZE 32
+#define W1_F14_PAGE_COUNT 1
+#define W1_F14_PAGE_BITS 5
+#define W1_F14_PAGE_SIZE (1 << W1_F14_PAGE_BITS)
+#define W1_F14_PAGE_MASK 0x1F
+
+#define W1_F14_SCRATCH_BITS5
+#define W1_F14_SCRATCH_SIZE(1 << W1_F14_SCRATCH_BITS)
+#define W1_F14_SCRATCH_MASK(W1_F14_SCRATCH_SIZE-1)
+
+#define W1_F14_READ_EEPROM 0xF0
+#define W1_F14_WRITE_SCRATCH 0x0F
+#define W1_F14_READ_SCRATCH0xAA
+#define W1_F14_COPY_SCRATCH0x55
+#define W1_F14_VALIDATION_KEY 0xa5
+
+#define W1_F14_TPROG_MS11
+#define W1_F14_READ_RETRIES10
+#define W1_F14_READ_MAXLEN W1_F14_SCRATCH_SIZE
+
+/*
+ * Check the file size bounds and adjusts count as needed.
+ * This would not be needed if the file size didn't reset to 0 after a write.
+ */
+static inline size_t w1_f14_fix_count(loff_t off, size_t count, size_t size)
+{
+ if (off > size)
+ return 0;
+
+ if ((off + count) > size)
+ return size - off;
+
+ return count;
+}
+
+/*
+ * Read a block from W1 ROM two times and compares the results.
+ * If they are equal they are returned, otherwise the read
+ * is repeated W1_F14_READ_RETRIES times.
+ *
+ * count must not exceed W1_F14_READ_MAXLEN.
+ */
+stat
[PATCH] w1: new driver. DS2430 chip
boot log
...
Driver for 1-wire Dallas network protocol.
w1_master_driver w1_bus_master1:
Attaching one wire slave 14.0158556e crc f7
11 22 33 ff ff ff ff ff ff ff ff ff ff ff ff ff
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0020
Signed-off-by: Angelo Dureghello
---
drivers/w1/slaves/Kconfig | 8 +
drivers/w1/slaves/Makefile| 1 +
drivers/w1/slaves/w1_ds2430.c | 294 ++
3 files changed, 303 insertions(+)
create mode 100644 drivers/w1/slaves/w1_ds2430.c
diff --git a/drivers/w1/slaves/Kconfig b/drivers/w1/slaves/Kconfig
index ebed495b9e69..e395f5698c43 100644
--- a/drivers/w1/slaves/Kconfig
+++ b/drivers/w1/slaves/Kconfig
@@ -74,6 +74,14 @@ config W1_SLAVE_DS2805
organized as 7 pages of 16 bytes each with 64bit
unique number. Requires OverDrive Speed to talk to.
+config W1_SLAVE_DS2430
+ tristate "256b EEPROM family support (DS2430)"
+ help
+ Say Y here if you want to use a 1-wire 256bit EEPROM
+ family device (DS2430).
+ This EEPROM is organized as one page of 32 bytes for random
+ access.
+
config W1_SLAVE_DS2431
tristate "1kb EEPROM family support (DS2431)"
help
diff --git a/drivers/w1/slaves/Makefile b/drivers/w1/slaves/Makefile
index 8e9655eaa478..278bcf2a9bfd 100644
--- a/drivers/w1/slaves/Makefile
+++ b/drivers/w1/slaves/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_W1_SLAVE_DS2408) += w1_ds2408.o
obj-$(CONFIG_W1_SLAVE_DS2413) += w1_ds2413.o
obj-$(CONFIG_W1_SLAVE_DS2406) += w1_ds2406.o
obj-$(CONFIG_W1_SLAVE_DS2423) += w1_ds2423.o
+obj-$(CONFIG_W1_SLAVE_DS2430) += w1_ds2430.o
obj-$(CONFIG_W1_SLAVE_DS2431) += w1_ds2431.o
obj-$(CONFIG_W1_SLAVE_DS2805) += w1_ds2805.o
obj-$(CONFIG_W1_SLAVE_DS2433) += w1_ds2433.o
diff --git a/drivers/w1/slaves/w1_ds2430.c b/drivers/w1/slaves/w1_ds2430.c
new file mode 100644
index ..4586dc7effac
--- /dev/null
+++ b/drivers/w1/slaves/w1_ds2430.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * w1_ds2430.c - w1 family 14 (DS2430) driver
+ **
+ * Copyright (c) 2019 Angelo Dureghello
+ *
+ * Cloned and modified from ds2431
+ * Copyright (c) 2008 Bernhard Weirich
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define W1_EEPROM_DS2430 0x14
+
+#define W1_F14_EEPROM_SIZE 128
+#define W1_F14_PAGE_COUNT 1
+#define W1_F14_PAGE_BITS 5
+#define W1_F14_PAGE_SIZE (1 << W1_F14_PAGE_BITS)
+#define W1_F14_PAGE_MASK 0x1F
+
+#define W1_F14_SCRATCH_BITS3
+#define W1_F14_SCRATCH_SIZE(1 << W1_F14_SCRATCH_BITS)
+#define W1_F14_SCRATCH_MASK(W1_F14_SCRATCH_SIZE-1)
+
+#define W1_F14_READ_EEPROM 0xF0
+#define W1_F14_WRITE_SCRATCH 0x0F
+#define W1_F14_READ_SCRATCH0xAA
+#define W1_F14_COPY_SCRATCH0x55
+
+#define W1_F14_TPROG_MS11
+#define W1_F14_READ_RETRIES10
+#define W1_F14_READ_MAXLEN 8
+
+/*
+ * Check the file size bounds and adjusts count as needed.
+ * This would not be needed if the file size didn't reset to 0 after a write.
+ */
+static inline size_t w1_f14_fix_count(loff_t off, size_t count, size_t size)
+{
+ if (off > size)
+ return 0;
+
+ if ((off + count) > size)
+ return size - off;
+
+ return count;
+}
+
+/*
+ * Read a block from W1 ROM two times and compares the results.
+ * If they are equal they are returned, otherwise the read
+ * is repeated W1_F14_READ_RETRIES times.
+ *
+ * count must not exceed W1_F14_READ_MAXLEN.
+ */
+static int w1_f14_readblock(struct w1_slave *sl, int off, int count, char *buf)
+{
+ u8 wrbuf[3];
+ u8 cmp[W1_F14_READ_MAXLEN];
+ int tries = W1_F14_READ_RETRIES;
+
+ do {
+ wrbuf[0] = W1_F14_READ_EEPROM;
+ wrbuf[1] = off & 0xff;
+ wrbuf[2] = off >> 8;
+
+ if (w1_reset_select_slave(sl))
+ return -1;
+
+ w1_write_block(sl->master, wrbuf, 3);
+ w1_read_block(sl->master, buf, count);
+
+ if (w1_reset_select_slave(sl))
+ return -1;
+
+ w1_write_block(sl->master, wrbuf, 3);
+ w1_read_block(sl->master, cmp, count);
+
+ if (!memcmp(cmp, buf, count))
+ return 0;
+ } while (--tries);
+
+ dev_err(&sl->dev, "proof reading failed %d times\n",
+ W1_F14_READ_RETRIES);
+
+ return -1;
+}
+
+static ssize_t eeprom_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf,
+ loff_t off, size_t count)
+{
+ struct w1_slave *sl = kobj_to_w1_slave(kobj);
+ int todo = count;
+
+ count = w1_f14_fix_count(off, count, W1_F14_EEPROM_SIZE);
+ if (count == 0)
+
Re: [PATCH v5 0/6] add edma2 for i.mx7ulp
Hi Robin, On Tue, Jun 25, 2019 at 05:43:18PM +0800, yibin.g...@nxp.com wrote: > From: Robin Gong > > This patch set add new version of edma for i.mx7ulp, the main changes > are as belows: > 1. only one dmamux. > 2. another clock dma_clk except dmamux clk. > 3. 16 independent interrupts instead of only one interrupt for > all channels > For the first change, need modify fsl-edma-common.c and mcf-edma, > so create the first two patches to prepare without any function impact. > > For the third change, need request single irq for every channel with > the legacy handler. But actually 2 dma channels share one interrupt(16 > channel interrupts, but 32 channels.),ch0/ch16,ch1/ch17... For now, just > simply request irq without IRQF_SHARED flag, since 16 channels are enough > on i.mx7ulp whose M4 domain own some peripherals. > > change from v1: > 1. check .data of 'of_device_id' in probe instead of compatible name. > > change from v2: > 1. move the difference between edma and edma2 into driver data so that > no need version checking in fsl-edma.c. > > change from v3: > 1. remove duplicated 'version' and 'dmamux_nr' in 'struct fsl_edma_engine' > since they are included in drvdata already. > 2. downgrade print log level. > 3. address some minor indent issues raised by Vinod. > > change from v4: > 1. correct typo. > > Robin Gong (6): > dmaengine: fsl-edma: add drvdata for fsl-edma > dmaengine: fsl-edma-common: move dmamux register to another single > function > dmaengine: fsl-edma-common: version check for v2 instead > dt-bindings: dma: fsl-edma: add new i.mx7ulp-edma > dmaengine: fsl-edma: add i.mx7ulp edma2 version support > ARM: dts: imx7ulp: add edma device node > > Documentation/devicetree/bindings/dma/fsl-edma.txt | 44 - > arch/arm/boot/dts/imx7ulp.dtsi | 28 ++ > drivers/dma/fsl-edma-common.c | 83 ++-- > drivers/dma/fsl-edma-common.h | 14 ++- > drivers/dma/fsl-edma.c | 109 > ++--- > drivers/dma/mcf-edma.c | 11 ++- > 6 files changed, 239 insertions(+), 50 deletions(-) > I tested the patch-set on ColdFire mcf5441x (stmark2 board), all works fine. Tested-by: Angelo Dureghello Regards, Angelo > -- > 2.7.4 >
Re: [PATCH] m68k: io: Fix io{read,write}{16,32}be() for Coldfire peripherals
Hi Greg (and all),
couldn't seen any follow up on this patch. I tested it and at least
for mcf5441x it works properly and solves all issues.
Do you think it may be accepted as an initial fix ?
Regards,
Angelo
On Mon, Apr 29, 2019 at 10:19:37AM +0200, Geert Uytterhoeven wrote:
> The generic definitions of mmio_{read,write}{16,32}be() in lib/iomap.c
> assume that the {read,write}[wl]() I/O accessors always use little
> endian accesses, and swap the result.
>
> However, the Coldfire versions of the {read,write}[wl]() I/O accessors are
> special, in that they use native big endian instead of little endian for
> accesses to the on-SoC peripheral block, thus violating the assumption.
>
> Fix this by providing our own variants, using the raw accessors,
> reinstating the old behavior. This is fine on m68k, as no special
> barriers are needed, and also avoids swapping data twice.
>
> Reported-by: Angelo Dureghello
> Fixes: aecc787c06f4300f ("iomap: Use non-raw io functions for
> io{read|write}XXbe")
> Signed-off-by: Geert Uytterhoeven
> ---
> This can be reverted later, after this oddity of the Coldfire I/O
> support has been fixed, and drivers have been updated.
> ---
> arch/m68k/include/asm/io.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> index aabe6420ead2a599..d47e7384681ab1cd 100644
> --- a/arch/m68k/include/asm/io.h
> +++ b/arch/m68k/include/asm/io.h
> @@ -8,6 +8,12 @@
> #include
> #endif
>
> +#define mmio_read16be(addr) __raw_readw(addr)
> +#define mmio_read32be(addr) __raw_readl(addr)
> +
> +#define mmio_write16be(val, port)__raw_writew((val), (port))
> +#define mmio_write32be(val, port)__raw_writel((val), (port))
> +
> #include
>
> #endif /* _M68K_IO_H */
> --
> 2.17.1
>
mcf5441x, mmu boot not working anymore
Hi all, just rebased to master right now, so @ > 5.1.1, nommu boot works, mmu boot hangs without any message. Before rebase i was near 5.1-rc1 but lost the log, unfortunately. I start to investigate on this. Please let me know if you may have any idea about where the issue could come from. Regards, Angelo
Re: [PATCH] m68k: io: Fix io{read,write}{16,32}be() for Coldfire peripherals
Hi,
On Mon, Apr 29, 2019 at 02:39:47PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 29, 2019 at 10:19 AM Geert Uytterhoeven
> wrote:
> >
> > The generic definitions of mmio_{read,write}{16,32}be() in lib/iomap.c
> > assume that the {read,write}[wl]() I/O accessors always use little
> > endian accesses, and swap the result.
> >
> > However, the Coldfire versions of the {read,write}[wl]() I/O accessors are
> > special, in that they use native big endian instead of little endian for
> > accesses to the on-SoC peripheral block, thus violating the assumption.
> >
> > Fix this by providing our own variants, using the raw accessors,
> > reinstating the old behavior. This is fine on m68k, as no special
> > barriers are needed, and also avoids swapping data twice.
> >
> > Reported-by: Angelo Dureghello
> > Fixes: aecc787c06f4300f ("iomap: Use non-raw io functions for
> > io{read|write}XXbe")
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > This can be reverted later, after this oddity of the Coldfire I/O
> > support has been fixed, and drivers have been updated.
> > ---
> > arch/m68k/include/asm/io.h | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> > index aabe6420ead2a599..d47e7384681ab1cd 100644
> > --- a/arch/m68k/include/asm/io.h
> > +++ b/arch/m68k/include/asm/io.h
> > @@ -8,6 +8,12 @@
> > #include
> > #endif
> >
> > +#define mmio_read16be(addr)__raw_readw(addr)
> > +#define mmio_read32be(addr)__raw_readl(addr)
> > +
> > +#define mmio_write16be(val, port) __raw_writew((val), (port))
> > +#define mmio_write32be(val, port) __raw_writel((val), (port))
> > +
> > #include
>
> This looks correct to me, but there are two points that stick out to me:
>
> - why do you only do this for mmio and not for pio?
> - why do you even use the generic_iomap wrappers rather than
> the trivial asm-generic versions of those functions?
>
>Arnd
At least i applied it and it works properly, dspi / dma drivers are
back working.
Thanks,
Regards
Angelo
Re: [PATCH] dmaengine: fsl-edma: dma map slave device address
fsl_desc)
> return NULL;
> @@ -468,11 +525,11 @@ struct dma_async_tx_descriptor *fsl_edma_prep_slave_sg(
>
> if (direction == DMA_MEM_TO_DEV) {
> src_addr = sg_dma_address(sg);
> - dst_addr = fsl_chan->cfg.dst_addr;
> + dst_addr = fsl_chan->dma_dev_addr;
> soff = fsl_chan->cfg.dst_addr_width;
> doff = 0;
> } else {
> - src_addr = fsl_chan->cfg.src_addr;
> + src_addr = fsl_chan->dma_dev_addr;
> dst_addr = sg_dma_address(sg);
> soff = 0;
> doff = fsl_chan->cfg.src_addr_width;
> @@ -555,6 +612,7 @@ void fsl_edma_free_chan_resources(struct dma_chan *chan)
> fsl_edma_chan_mux(fsl_chan, 0, false);
> fsl_chan->edesc = NULL;
> vchan_get_all_descriptors(&fsl_chan->vchan, &head);
> + fsl_edma_unprep_slave_dma(fsl_chan);
> spin_unlock_irqrestore(&fsl_chan->vchan.lock, flags);
>
> vchan_dma_desc_free_list(&fsl_chan->vchan, &head);
> diff --git a/drivers/dma/fsl-edma-common.h b/drivers/dma/fsl-edma-common.h
> index 8917e8865959..b435d8e1e3a1 100644
> --- a/drivers/dma/fsl-edma-common.h
> +++ b/drivers/dma/fsl-edma-common.h
> @@ -6,6 +6,7 @@
> #ifndef _FSL_EDMA_COMMON_H_
> #define _FSL_EDMA_COMMON_H_
>
> +#include
> #include "virt-dma.h"
>
> #define EDMA_CR_EDBG BIT(1)
> @@ -120,6 +121,9 @@ struct fsl_edma_chan {
> struct dma_slave_config cfg;
> u32 attr;
> struct dma_pool *tcd_pool;
> + dma_addr_t dma_dev_addr;
> + u32 dma_dev_size;
> + enum dma_data_direction dma_dir;
> };
>
> struct fsl_edma_desc {
> diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c
> index 34d70112fcc9..75e8a7ba3a22 100644
> --- a/drivers/dma/fsl-edma.c
> +++ b/drivers/dma/fsl-edma.c
> @@ -254,6 +254,7 @@ static int fsl_edma_probe(struct platform_device *pdev)
> fsl_chan->pm_state = RUNNING;
> fsl_chan->slave_id = 0;
> fsl_chan->idle = true;
> + fsl_chan->dma_dir = DMA_NONE;
> fsl_chan->vchan.desc_free = fsl_edma_free_desc;
> vchan_init(&fsl_chan->vchan, &fsl_edma->dma_dev);
>
> diff --git a/drivers/dma/mcf-edma.c b/drivers/dma/mcf-edma.c
> index 5de1b07eddff..7de54b2fafdb 100644
> --- a/drivers/dma/mcf-edma.c
> +++ b/drivers/dma/mcf-edma.c
> @@ -214,6 +214,7 @@ static int mcf_edma_probe(struct platform_device *pdev)
> mcf_chan->edma = mcf_edma;
> mcf_chan->slave_id = i;
> mcf_chan->idle = true;
> + mcf_chan->dma_dir = DMA_NONE;
> mcf_chan->vchan.desc_free = fsl_edma_free_desc;
> vchan_init(&mcf_chan->vchan, &mcf_edma->dma_dev);
> iowrite32(0x0, ®s->tcd[i].csr);
> --
> 2.17.1
>
I tested this patch on:
- Vybrid VF50N (Toradex Colibri VF50)
- ColdFire mcf54415 (Sysam stmark2 board)
and dma still works properly.
Tested-by: Angelo Dureghello
Re: [PATCH] dmaengine: fsl-edma: use struct_size() in kzalloc()
On Fri, Jan 04, 2019 at 03:25:45PM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/dma/fsl-edma-common.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
> index 8876c4c1bb2c..fe529100674f 100644
> --- a/drivers/dma/fsl-edma-common.c
> +++ b/drivers/dma/fsl-edma-common.c
> @@ -339,9 +339,7 @@ static struct fsl_edma_desc *fsl_edma_alloc_desc(struct
> fsl_edma_chan *fsl_chan,
> struct fsl_edma_desc *fsl_desc;
> int i;
>
> - fsl_desc = kzalloc(sizeof(*fsl_desc) +
> -sizeof(struct fsl_edma_sw_tcd) *
> -sg_len, GFP_NOWAIT);
> + fsl_desc = kzalloc(struct_size(fsl_desc, tcd, sg_len), GFP_NOWAIT);
> if (!fsl_desc)
> return NULL;
>
Tested-by: Angelo Dureghello
> --
> 2.20.1
>
Re: linux-next: build warning after merge of the slave-dma tree
Hi,
sorry, there was no build-test robot warning anymore about it.
Will fix it in a patch in short.
On Thu, Sep 13, 2018 at 12:22:18PM +1000, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/dma/mcf-edma.c: In function 'mcf_edma_filter_fn':
> drivers/dma/mcf-edma.c:296:33: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
>return (mcf_chan->slave_id == (u32)param);
> ^
>
> Introduced by commit
>
> e7a3ff92eaf1 ("dmaengine: fsl-edma: add ColdFire mcf5441x edma support")
>
Regards,
Angelo
> --
> Cheers,
> Stephen Rothwell
Re: [BUG] Serial/dma stall/failure after "dmaengine: fsl-edma: extract common fsl-edma code (no changes in behavior intended)"
Hi,
On Fri, Jul 06, 2018 at 08:16:29AM +0200, Krzysztof Kozlowski wrote:
> On 6 July 2018 at 08:05, Vinod wrote:
> > On 05-07-18, 18:23, Angelo Dureghello wrote:
> >> Hi Stafan,
> >>
> >> On Thu, Jul 05, 2018 at 05:55:31PM +0200, Stefan Agner wrote:
> >> > Hi Vinod, Hi Angelo,
> >> >
> >> > On 05.07.2018 14:45, Angelo Dureghello wrote:
> >> > > Hi Vinod,
> >> > >
> >> > > On Thu, Jul 05, 2018 at 10:12:53AM +0200, Angelo Dureghello wrote:
> >> > >> Hi Vinod,
> >> > >>
> >> > >> On Thu, Jul 05, 2018 at 01:05:52PM +0530, Vinod wrote:
> >> > >> > On 04-07-18, 10:54, Krzysztof Kozlowski wrote:
> >> > >> > > Hi,
> >> > >> > >
> >> > >> > > The commit 6ad069123f03bebe4315dea13d44845854ca6043 ("dmaengine:
> >> > >> > > fsl-edma: extract common fsl-edma code (no changes in behavior
> >> > >> > > intended)"), even though marked as no changes in behavior
> >> > >> > > intended...
> >> > >> > > make serial console with DMA broken after boot. The console just
> >> > >> > > hangs
> >> > >> > > - is not responsive even to SysRq. Usually after finishing boot -
> >> > >> > > before or after login prompt. Sometimes login is allowed and then
> >> > >> > > it
> >> > >> > > hangs during printing dmesg.
> >> > >> > >
> >> > >> > > Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial
> >> > >> > > configured
> >> > >> > > with DMA) on Iris Carrier.
> >> > >> >
> >> > >> > Angelo ?
> >> > >> >
> >> > >> sorry for this. As said i couldn't test it in any of those arm boards
> >> > >> but i take a look.
> >> > >>
> >> > >> The only code part that changes is the initial setting up of the
> >> > >> registers.
> >> > >> I am checking that.
> >> > >>
> >> > >> Regards,
> >> > >> Angelo
> >> > >>
> >> > >
> >> > > I cannot find anything obviously wrong.
> >> > > And i cannot test on Vybrid.
> >> > > I will try to get a Vybrid V50 board to test this issue. It would
> >> > > require some days and also i wil be 3 weeks off on July.
> >> > >
> >> > > So please revert my patch.
> >> >
> >> > I did not found the issue quickly. But I must say that I gave up pretty
> >> > quickly. There are too many changes in a single patch which makes it
> >> > hard to figure out what could be wrong. I'd rather prefer if we could
> >> > drop that patch again and go through another review phase.
> >> >
> >> > Angelo, as far as I can see the patch has not been sent to LKML or the
> >> > ARM mailing list. Especially since you do not have such a device it
> >> > would have been nice to also send it to the ARM mailing list...
> >> >
> >> > Can you resend your last revision with CC to me/ARM mailing list?
> >> >
> >>
> >> Thanks for looking into it.
> >>
> >> I have spent a lot of time on this patch and really would have
> >> dma for Coldfire available. So, have ordered a Colibri / v50 board.
> >>
> >> Should receive it in few days and should be able to debug this issue,
> >> but as said, i will be off for some weeks so looks like it is probably
> >> better to revert the patch.
> >>
> >> My initial submit was a separate driver, to avoid such issues where
> >> i cannot test, but it resulted in too much duplicated code.
> >>
> >> Sure, i can send the full patch to you/arm with all the fixes included
> >> until now.
> >
> > Okay dropped now from -next. I still keeping topic/fsl around and
> > collect other fixes for you guys to check.
> >
> > One way would be to split to common patch into multiple patch and check
> > regression. That should help quickly identify the issue.
>
> Even with show -C20% -M20% I gave up when trying to spot possible
> differences in the commit. I understand that logically it is one
> change and it makes sense... but it touches, moves and adds too much
> making review extremely difficult. I think the splitting into smaller
> chunks would be beneficial anyway.
>
> Today's next boots fine.
>
Good, will resend the patch once splitted in more commits, and
tested on V50 Vybrid.
Regards,
Angelo
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Serial/dma stall/failure after "dmaengine: fsl-edma: extract common fsl-edma code (no changes in behavior intended)"
Hi Stafan,
On Thu, Jul 05, 2018 at 05:55:31PM +0200, Stefan Agner wrote:
> Hi Vinod, Hi Angelo,
>
> On 05.07.2018 14:45, Angelo Dureghello wrote:
> > Hi Vinod,
> >
> > On Thu, Jul 05, 2018 at 10:12:53AM +0200, Angelo Dureghello wrote:
> >> Hi Vinod,
> >>
> >> On Thu, Jul 05, 2018 at 01:05:52PM +0530, Vinod wrote:
> >> > On 04-07-18, 10:54, Krzysztof Kozlowski wrote:
> >> > > Hi,
> >> > >
> >> > > The commit 6ad069123f03bebe4315dea13d44845854ca6043 ("dmaengine:
> >> > > fsl-edma: extract common fsl-edma code (no changes in behavior
> >> > > intended)"), even though marked as no changes in behavior intended...
> >> > > make serial console with DMA broken after boot. The console just hangs
> >> > > - is not responsive even to SysRq. Usually after finishing boot -
> >> > > before or after login prompt. Sometimes login is allowed and then it
> >> > > hangs during printing dmesg.
> >> > >
> >> > > Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial configured
> >> > > with DMA) on Iris Carrier.
> >> >
> >> > Angelo ?
> >> >
> >> sorry for this. As said i couldn't test it in any of those arm boards
> >> but i take a look.
> >>
> >> The only code part that changes is the initial setting up of the registers.
> >> I am checking that.
> >>
> >> Regards,
> >> Angelo
> >>
> >
> > I cannot find anything obviously wrong.
> > And i cannot test on Vybrid.
> > I will try to get a Vybrid V50 board to test this issue. It would
> > require some days and also i wil be 3 weeks off on July.
> >
> > So please revert my patch.
>
> I did not found the issue quickly. But I must say that I gave up pretty
> quickly. There are too many changes in a single patch which makes it
> hard to figure out what could be wrong. I'd rather prefer if we could
> drop that patch again and go through another review phase.
>
> Angelo, as far as I can see the patch has not been sent to LKML or the
> ARM mailing list. Especially since you do not have such a device it
> would have been nice to also send it to the ARM mailing list...
>
> Can you resend your last revision with CC to me/ARM mailing list?
>
Thanks for looking into it.
I have spent a lot of time on this patch and really would have
dma for Coldfire available. So, have ordered a Colibri / v50 board.
Should receive it in few days and should be able to debug this issue,
but as said, i will be off for some weeks so looks like it is probably
better to revert the patch.
My initial submit was a separate driver, to avoid such issues where
i cannot test, but it resulted in too much duplicated code.
Sure, i can send the full patch to you/arm with all the fixes included
until now.
Best regards,
Angelo
> --
> Stefan
>
> >
> > Regards,
> > Angelo
> >
> >> > >
> >> > > Commit found with bisect:
> >> > > git bisect start
> >> > > # bad: [bce40927669338cc4a361fc97d46bf650573ce5c] Add linux-next
> >> > > specific files for 20180704
> >> > > git bisect bad bce40927669338cc4a361fc97d46bf650573ce5c
> >> > > # good: [410da1e12ffed61129d61df5b7adce4d08c7f17c] net/smc: fix up
> >> > > merge error with poll changes
> >> > > git bisect good 410da1e12ffed61129d61df5b7adce4d08c7f17c
> >> > > # good: [decd57900d6fd743f7ddc1329400f4bd9cf54284] Merge
> >> > > remote-tracking branch 'crypto/master'
> >> > > git bisect good decd57900d6fd743f7ddc1329400f4bd9cf54284
> >> > > # good: [e9484bb660753ca8a35d219db000fff967b70a2c] Merge
> >> > > remote-tracking branch 'tip/auto-latest'
> >> > > git bisect good e9484bb660753ca8a35d219db000fff967b70a2c
> >> > > # bad: [20adee487b5f252d3f38197d43487c004273d3d0] Merge
> >> > > remote-tracking branch 'slave-dma/next'
> >> > > git bisect bad 20adee487b5f252d3f38197d43487c004273d3d0
> >> > > # good: [2df2577dce1d5fd98cac342fe857677a0556421b] Merge
> >> > > remote-tracking branch 'tty/tty-next'
> >> > > git bisect good 2df2577dce1d5fd98cac342fe857677a0556421b
> >> > > # good: [03b17ed8410a61f4f337c7bcfded1f744182edd5] spi: spi-fsl-dspi:
> >> > > Fix imprecise abort on VF500 during probe
> >> > > git bisect good 03b17ed8410a61f4f337c7bcfded1f744182edd5
> >> > > # good
Re: [BUG] Serial/dma stall/failure after "dmaengine: fsl-edma: extract common fsl-edma code (no changes in behavior intended)"
Hi Vinod,
On Thu, Jul 05, 2018 at 10:12:53AM +0200, Angelo Dureghello wrote:
> Hi Vinod,
>
> On Thu, Jul 05, 2018 at 01:05:52PM +0530, Vinod wrote:
> > On 04-07-18, 10:54, Krzysztof Kozlowski wrote:
> > > Hi,
> > >
> > > The commit 6ad069123f03bebe4315dea13d44845854ca6043 ("dmaengine:
> > > fsl-edma: extract common fsl-edma code (no changes in behavior
> > > intended)"), even though marked as no changes in behavior intended...
> > > make serial console with DMA broken after boot. The console just hangs
> > > - is not responsive even to SysRq. Usually after finishing boot -
> > > before or after login prompt. Sometimes login is allowed and then it
> > > hangs during printing dmesg.
> > >
> > > Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial configured
> > > with DMA) on Iris Carrier.
> >
> > Angelo ?
> >
> sorry for this. As said i couldn't test it in any of those arm boards
> but i take a look.
>
> The only code part that changes is the initial setting up of the registers.
> I am checking that.
>
> Regards,
> Angelo
>
I cannot find anything obviously wrong.
And i cannot test on Vybrid.
I will try to get a Vybrid V50 board to test this issue. It would
require some days and also i wil be 3 weeks off on July.
So please revert my patch.
Regards,
Angelo
> > >
> > > Commit found with bisect:
> > > git bisect start
> > > # bad: [bce40927669338cc4a361fc97d46bf650573ce5c] Add linux-next
> > > specific files for 20180704
> > > git bisect bad bce40927669338cc4a361fc97d46bf650573ce5c
> > > # good: [410da1e12ffed61129d61df5b7adce4d08c7f17c] net/smc: fix up
> > > merge error with poll changes
> > > git bisect good 410da1e12ffed61129d61df5b7adce4d08c7f17c
> > > # good: [decd57900d6fd743f7ddc1329400f4bd9cf54284] Merge
> > > remote-tracking branch 'crypto/master'
> > > git bisect good decd57900d6fd743f7ddc1329400f4bd9cf54284
> > > # good: [e9484bb660753ca8a35d219db000fff967b70a2c] Merge
> > > remote-tracking branch 'tip/auto-latest'
> > > git bisect good e9484bb660753ca8a35d219db000fff967b70a2c
> > > # bad: [20adee487b5f252d3f38197d43487c004273d3d0] Merge
> > > remote-tracking branch 'slave-dma/next'
> > > git bisect bad 20adee487b5f252d3f38197d43487c004273d3d0
> > > # good: [2df2577dce1d5fd98cac342fe857677a0556421b] Merge
> > > remote-tracking branch 'tty/tty-next'
> > > git bisect good 2df2577dce1d5fd98cac342fe857677a0556421b
> > > # good: [03b17ed8410a61f4f337c7bcfded1f744182edd5] spi: spi-fsl-dspi:
> > > Fix imprecise abort on VF500 during probe
> > > git bisect good 03b17ed8410a61f4f337c7bcfded1f744182edd5
> > > # good: [85e1d42663a0c163002961d2685be952067b0dc2] staging:
> > > mt7621-eth: Fix memory leak in mtk_add_mac() error path
> > > git bisect good 85e1d42663a0c163002961d2685be952067b0dc2
> > > # good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
> > > remove blank lines
> > > git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
> > > # good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
> > > remove blank lines
> > > git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
> > > # good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
> > > remove blank lines
> > > git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
> > > # good: [6c796f514b7f8d0fef4733b971a5ded9e9a74490] Merge
> > > remote-tracking branch 'staging/staging-next'
> > > git bisect good 6c796f514b7f8d0fef4733b971a5ded9e9a74490
> > > # good: [14dfa379ffd3ffd73729a72c289e9db6780a60ab] Merge branch
> > > 'topic/ste' into next
> > > git bisect good 14dfa379ffd3ffd73729a72c289e9db6780a60ab
> > > # good: [c1199875d327a9b3bbb3fb1cca0d467d3e625fbb] dmaengine:
> > > imx-sdma: Use GFP_NOWAIT for dma allocations
> > > git bisect good c1199875d327a9b3bbb3fb1cca0d467d3e625fbb
> > > # bad: [15efb0b488596a929bc00ce23aeb746ee6a7c14d] dmaengine: fsl-edma:
> > > fix trailing whitespace
> > > git bisect bad 15efb0b488596a929bc00ce23aeb746ee6a7c14d
> > > # bad: [5c1355ad87a2c138049bfafa753b44046492aebc] dmaengine: fsl-edma:
> > > add ColdFire mcf5441x edma support
> > > git bisect bad 5c1355ad87a2c138049bfafa753b44046492aebc
> > > # bad: [6ad069123f03bebe4315dea13d44845854ca6043] dmaengine: fsl-edma:
> > > extract common fsl-edma code (no changes in behavior intended)
>
Re: [BUG] Serial/dma stall/failure after "dmaengine: fsl-edma: extract common fsl-edma code (no changes in behavior intended)"
Hi Vinod,
On Thu, Jul 05, 2018 at 01:05:52PM +0530, Vinod wrote:
> On 04-07-18, 10:54, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > The commit 6ad069123f03bebe4315dea13d44845854ca6043 ("dmaengine:
> > fsl-edma: extract common fsl-edma code (no changes in behavior
> > intended)"), even though marked as no changes in behavior intended...
> > make serial console with DMA broken after boot. The console just hangs
> > - is not responsive even to SysRq. Usually after finishing boot -
> > before or after login prompt. Sometimes login is allowed and then it
> > hangs during printing dmesg.
> >
> > Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial configured
> > with DMA) on Iris Carrier.
>
> Angelo ?
>
sorry for this. As said i couldn't test it in any of those arm boards
but i take a look.
The only code part that changes is the initial setting up of the registers.
I am checking that.
Regards,
Angelo
> >
> > Commit found with bisect:
> > git bisect start
> > # bad: [bce40927669338cc4a361fc97d46bf650573ce5c] Add linux-next
> > specific files for 20180704
> > git bisect bad bce40927669338cc4a361fc97d46bf650573ce5c
> > # good: [410da1e12ffed61129d61df5b7adce4d08c7f17c] net/smc: fix up
> > merge error with poll changes
> > git bisect good 410da1e12ffed61129d61df5b7adce4d08c7f17c
> > # good: [decd57900d6fd743f7ddc1329400f4bd9cf54284] Merge
> > remote-tracking branch 'crypto/master'
> > git bisect good decd57900d6fd743f7ddc1329400f4bd9cf54284
> > # good: [e9484bb660753ca8a35d219db000fff967b70a2c] Merge
> > remote-tracking branch 'tip/auto-latest'
> > git bisect good e9484bb660753ca8a35d219db000fff967b70a2c
> > # bad: [20adee487b5f252d3f38197d43487c004273d3d0] Merge
> > remote-tracking branch 'slave-dma/next'
> > git bisect bad 20adee487b5f252d3f38197d43487c004273d3d0
> > # good: [2df2577dce1d5fd98cac342fe857677a0556421b] Merge
> > remote-tracking branch 'tty/tty-next'
> > git bisect good 2df2577dce1d5fd98cac342fe857677a0556421b
> > # good: [03b17ed8410a61f4f337c7bcfded1f744182edd5] spi: spi-fsl-dspi:
> > Fix imprecise abort on VF500 during probe
> > git bisect good 03b17ed8410a61f4f337c7bcfded1f744182edd5
> > # good: [85e1d42663a0c163002961d2685be952067b0dc2] staging:
> > mt7621-eth: Fix memory leak in mtk_add_mac() error path
> > git bisect good 85e1d42663a0c163002961d2685be952067b0dc2
> > # good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
> > remove blank lines
> > git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
> > # good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
> > remove blank lines
> > git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
> > # good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
> > remove blank lines
> > git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
> > # good: [6c796f514b7f8d0fef4733b971a5ded9e9a74490] Merge
> > remote-tracking branch 'staging/staging-next'
> > git bisect good 6c796f514b7f8d0fef4733b971a5ded9e9a74490
> > # good: [14dfa379ffd3ffd73729a72c289e9db6780a60ab] Merge branch
> > 'topic/ste' into next
> > git bisect good 14dfa379ffd3ffd73729a72c289e9db6780a60ab
> > # good: [c1199875d327a9b3bbb3fb1cca0d467d3e625fbb] dmaengine:
> > imx-sdma: Use GFP_NOWAIT for dma allocations
> > git bisect good c1199875d327a9b3bbb3fb1cca0d467d3e625fbb
> > # bad: [15efb0b488596a929bc00ce23aeb746ee6a7c14d] dmaengine: fsl-edma:
> > fix trailing whitespace
> > git bisect bad 15efb0b488596a929bc00ce23aeb746ee6a7c14d
> > # bad: [5c1355ad87a2c138049bfafa753b44046492aebc] dmaengine: fsl-edma:
> > add ColdFire mcf5441x edma support
> > git bisect bad 5c1355ad87a2c138049bfafa753b44046492aebc
> > # bad: [6ad069123f03bebe4315dea13d44845854ca6043] dmaengine: fsl-edma:
> > extract common fsl-edma code (no changes in behavior intended)
> > git bisect bad 6ad069123f03bebe4315dea13d44845854ca6043
> > # first bad commit: [6ad069123f03bebe4315dea13d44845854ca6043]
> > dmaengine: fsl-edma: extract common fsl-edma code (no changes in
> > behavior intended)
> >
> > Defconfig and boot log attached. I could not find any obvious error in boot
> > log.
> >
> > Let me know if you need more data.
> >
> > Best regards,
> > Krzysztof
>
>
> > [0.00] Memory policy: Data cache writeback
> > [0.00] cma: Reserved 16 MiB at 0x8700
> > [0.00] CPU: All CPU(s) started in SVC mode.
> > [0.00] random: get_random_bytes called from start_kernel+0xa0/0x3fc
> > with crng_init=0
> > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 32512
> > [0.00] Kernel command line: ip=:eth0: root=/dev/nfs
> > console=tty1 console=ttyLP0,115200n8 consoleblank=0
> > [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536
> > bytes)
> > [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> > [0.00] Memory: 103836K/131072K available (6144K kernel code, 192K
> > rwdata, 1604K rodata, 1024K init, 142K bss, 10852K reserved, 16384K
> > cma-reserved)
>
Re: [PATCH] m68knommu: remove dead code
Hi,
just to inform you that i have in mind to add spi(soon, at least seems
just a matter con Kconfig changes) and usdhc(later)
drivers/support for stmark2 mcf5441x based board.
But no problem, in case i'll re-add the this code as needed.
On 24/08/2017 16:34, Alexandre Belloni wrote:
As CONFIG_RTC_DRV_M5441x doesn't exist because the driver never made it
upstream, there is no device to register. Remove code that is never
compiled and init_BSP() as it doesn't do anything.
Signed-off-by: Alexandre Belloni
---
arch/m68k/coldfire/m5441x.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index dc589b039b62..04fd7fde9fb3 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -222,40 +222,3 @@ void __init config_BSP(char *commandp, int size)
m5441x_uarts_init();
m5441x_fec_init();
}
-
-
-#if IS_ENABLED(CONFIG_RTC_DRV_M5441x)
-static struct resource m5441x_rtc_resources[] = {
- {
- .start = MCFRTC_BASE,
- .end= MCFRTC_BASE + MCFRTC_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = MCF_IRQ_RTC,
- .end= MCF_IRQ_RTC,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device m5441x_rtc = {
- .name = "mcfrtc",
- .id = 0,
- .resource = m5441x_rtc_resources,
- .num_resources = ARRAY_SIZE(m5441x_rtc_resources),
-};
-#endif
-
-static struct platform_device *m5441x_devices[] __initdata = {
-#if IS_ENABLED(CONFIG_RTC_DRV_M5441x)
- &m5441x_rtc,
-#endif
-};
-
-static int __init init_BSP(void)
-{
- platform_add_devices(m5441x_devices, ARRAY_SIZE(m5441x_devices));
- return 0;
-}
-
-arch_initcall(init_BSP);
Regards,
Angelo
[no subject]
subscribe linux-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
issues on last 32 bit m68k toolchain
Dear all, i was using the public x86 32bit toolchain from kernel.org: https://www.kernel.org/pub/tools/crosstool/files/bin/i686/4.6.3/i686-gcc-4.6.3-nolibc_m68k-linux.tar.gz Unfortunately, for ColdFire arch, there is a bug in gas/binutils for this toolchain: https://sourceware.org/bugzilla/show_bug.cgi?id=17877 Produced binaries are not working on the target. Is it possible to have available another m68k toolchain (including older or newer binutils/as than the bugged 2.22) ? Thanks, Best regards, Angelo Dureghello -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
