This patch concerns the use of a "non-jedec" m25p80 device in a x86 machine.
For an x86 machine a m25p80 device has to be declared inside a BIOS ACPI table
(for example inside the SSDT or the DSDT table).
No matching problems for the jedec compatible devices, since we have the list:
static const struct of_device_id m25p_of_table[] = {
{ .compatible = "jedec,spi-nor" },
{}
};
But for the "non-jedec" devices there are no possible matches, even if we try to
use, the SPI modalias, as:
spi:mr25h40
So it is necessary filling the m25p_of_table with all the m25p80 device names
used in the driver. This solution works both for the ACPI-style (x86) and
the DT-style declarations (ARM).
I checked this patch with:
1) x68 board using both an SSDT and DSDT tables
2) i.MX6DL custom board using a Device Tree
This is an example of working SSDT table for x86:
DefinitionBlock ("mr25h40.aml", "SSDT", 5, "ASEMsp", "MR25H40", 1)
{
External (_SB.SPI1, DeviceObj)
Scope (\_SB.SPI1)
{
Device (NVR0)
{
Name (_HID, "PRP0001")
Name (_DDN, "Everspin MR25H40 MRAM")
Name (_CRS, ResourceTemplate () {
SpiSerialBus (
1, // Chip select
PolarityLow, // Chip select is active low
FourWireMode, // Full duplex
8, // Bits per word is 8 (byte)
ControllerInitiated, // Don't care
10000000, // 10 MHz
ClockPolarityLow, // SPI mode 0 ClockPolarityLow
ClockPhaseFirst, // SPI mode 0 ClockPhaseFirst
"\\_SB.SPI1", // SPI host controller
0, // Must be 0
ResourceConsumer,
,
)
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "mr25h40"},
}
})
}
}
}
Flavio Suligoi (1):
mtd: devices: add ACPI support for non-jedec m25p80
drivers/mtd/devices/m25p80.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
--
2.7.4
For the x86 machines a m25p80-compatible device have to be declared using
an ACPI table (which can be directly a part of the BIOS ACPI tables).
In this case it is necessary to add the device in the "of_device_id" structure
list, to permit the device name matching by the ACPI kernel functions.
This is an example of a SSDT table for the Everspin mr25h40:
DefinitionBlock ("mr25h40.aml", "SSDT", 5, "ASEMsp", "MR25H40", 1)
{
External (_SB.SPI1, DeviceObj)
Scope (\_SB.SPI1)
{
Device (NVR0)
{
Name (_HID, "PRP0001")
Name (_DDN, "Everspin MR25H40 MRAM")
Name (_CRS, ResourceTemplate () {
SpiSerialBus (
1, // Chip select
PolarityLow, // Chip select is active low
FourWireMode, // Full duplex
8, // Bits per word is 8 (byte)
ControllerInitiated, // Don't care
10000000, // 10 MHz
ClockPolarityLow, // SPI mode 0 ClockPolarityLow
ClockPhaseFirst, // SPI mode 0 ClockPhaseFirst
"\\_SB.SPI1", // SPI host controller
0, // Must be 0
ResourceConsumer,
,
)
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "mr25h40"},
}
})
}
}
}
Signed-off-by: Flavio Suligoi <[email protected]>
---
v1: - first patch version
drivers/mtd/devices/m25p80.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index c4a1d04..b5c7db8 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -312,9 +312,64 @@ MODULE_DEVICE_TABLE(spi, m25p_ids);
static const struct of_device_id m25p_of_table[] = {
/*
* Generic compatibility for SPI NOR that can be identified by the
- * JEDEC READ ID opcode (0x9F). Use this, if possible.
+ * JEDEC READ ID opcode (0x9F). Use this (jedec,spi-nor), if possible.
+ *
+ * The list of all flash devices is instead necessary in x86 machines,
+ * to use a "non-jedec device" inside the ACPI BIOS tables.
*/
{ .compatible = "jedec,spi-nor" },
+ { .compatible = "s25sl064a" },
+ { .compatible = "w25x16" },
+ { .compatible = "m25p10" },
+ { .compatible = "m25px64" },
+ { .compatible = "at25df321a" },
+ { .compatible = "at25df641" },
+ { .compatible = "at26df081a" },
+ { .compatible = "mx25l4005a" },
+ { .compatible = "mx25l1606e" },
+ { .compatible = "mx25l6405d" },
+ { .compatible = "mx25l12805d" },
+ { .compatible = "mx25l25635e" },
+ { .compatible = "mx66l51235l" },
+ { .compatible = "n25q064" },
+ { .compatible = "n25q128a11" },
+ { .compatible = "n25q128a13" },
+ { .compatible = "n25q512a" },
+ { .compatible = "s25fl256s1" },
+ { .compatible = "s25fl512s" },
+ { .compatible = "s25sl12801" },
+ { .compatible = "s25fl008k" },
+ { .compatible = "s25fl064k" },
+ { .compatible = "sst25vf040b" },
+ { .compatible = "sst25vf016b" },
+ { .compatible = "sst25vf032b" },
+ { .compatible = "sst25wf040" },
+ { .compatible = "m25p40" },
+ { .compatible = "m25p80" },
+ { .compatible = "m25p16" },
+ { .compatible = "m25p32" },
+ { .compatible = "m25p64" },
+ { .compatible = "m25p128" },
+ { .compatible = "w25x80" },
+ { .compatible = "w25x32" },
+ { .compatible = "w25q32" },
+ { .compatible = "w25q32dw" },
+ { .compatible = "w25q80bl" },
+ { .compatible = "w25q128" },
+ { .compatible = "w25q256" },
+ { .compatible = "m25p05-nonjedec" },
+ { .compatible = "m25p10-nonjedec" },
+ { .compatible = "m25p20-nonjedec" },
+ { .compatible = "m25p40-nonjedec" },
+ { .compatible = "m25p80-nonjedec" },
+ { .compatible = "m25p16-nonjedec" },
+ { .compatible = "m25p32-nonjedec" },
+ { .compatible = "m25p64-nonjedec" },
+ { .compatible = "m25p128-nonjedec" },
+ { .compatible = "mr25h128" },
+ { .compatible = "mr25h256" },
+ { .compatible = "mr25h10" },
+ { .compatible = "mr25h40" },
{}
};
MODULE_DEVICE_TABLE(of, m25p_of_table);
--
2.7.4
On Tue, 2019-02-26 at 11:48 +0100, Flavio Suligoi wrote:
> For the x86 machines a m25p80-compatible device have to be declared using
> an ACPI table (which can be directly a part of the BIOS ACPI tables).
>
> In this case it is necessary to add the device in the "of_device_id" structure
> list, to permit the device name matching by the ACPI kernel functions.
>
> This is an example of a SSDT table for the Everspin mr25h40:
>
> DefinitionBlock ("mr25h40.aml", "SSDT", 5, "ASEMsp", "MR25H40", 1)
> {
> External (_SB.SPI1, DeviceObj)
>
> Scope (\_SB.SPI1)
> {
> Device (NVR0)
> {
> Name (_HID, "PRP0001")
> Name (_DDN, "Everspin MR25H40 MRAM")
> Name (_CRS, ResourceTemplate () {
> SpiSerialBus (
> 1, // Chip select
> PolarityLow, // Chip select is active low
> FourWireMode, // Full duplex
> 8, // Bits per word is 8 (byte)
> ControllerInitiated, // Don't care
> 10000000, // 10 MHz
> ClockPolarityLow, // SPI mode 0 ClockPolarityLow
> ClockPhaseFirst, // SPI mode 0 ClockPhaseFirst
> "\\_SB.SPI1", // SPI host controller
> 0, // Must be 0
> ResourceConsumer,
> ,
> )
> })
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", "mr25h40"},
> }
> })
> }
> }
> }
>
> Signed-off-by: Flavio Suligoi <[email protected]>
Why use the specific chip name in the "compatible" property? Why isn't
it using "jedec,spi-nor"?
Does this still actually get passed through to spi_nor_scan()... and is
it *necessary*? Can't the chips be probed?
> ---
>
> v1: - first patch version
>
> drivers/mtd/devices/m25p80.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index c4a1d04..b5c7db8 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -312,9 +312,64 @@ MODULE_DEVICE_TABLE(spi, m25p_ids);
> static const struct of_device_id m25p_of_table[] = {
> /*
> * Generic compatibility for SPI NOR that can be identified by the
> - * JEDEC READ ID opcode (0x9F). Use this, if possible.
> + * JEDEC READ ID opcode (0x9F). Use this (jedec,spi-nor), if possible.
> + *
> + * The list of all flash devices is instead necessary in x86 machines,
> + * to use a "non-jedec device" inside the ACPI BIOS tables.
> */
> { .compatible = "jedec,spi-nor" },
> + { .compatible = "s25sl064a" },
> + { .compatible = "w25x16" },
> + { .compatible = "m25p10" },
> + { .compatible = "m25px64" },
> + { .compatible = "at25df321a" },
> + { .compatible = "at25df641" },
> + { .compatible = "at26df081a" },
> + { .compatible = "mx25l4005a" },
> + { .compatible = "mx25l1606e" },
> + { .compatible = "mx25l6405d" },
> + { .compatible = "mx25l12805d" },
> + { .compatible = "mx25l25635e" },
> + { .compatible = "mx66l51235l" },
> + { .compatible = "n25q064" },
> + { .compatible = "n25q128a11" },
> + { .compatible = "n25q128a13" },
> + { .compatible = "n25q512a" },
> + { .compatible = "s25fl256s1" },
> + { .compatible = "s25fl512s" },
> + { .compatible = "s25sl12801" },
> + { .compatible = "s25fl008k" },
> + { .compatible = "s25fl064k" },
> + { .compatible = "sst25vf040b" },
> + { .compatible = "sst25vf016b" },
> + { .compatible = "sst25vf032b" },
> + { .compatible = "sst25wf040" },
> + { .compatible = "m25p40" },
> + { .compatible = "m25p80" },
> + { .compatible = "m25p16" },
> + { .compatible = "m25p32" },
> + { .compatible = "m25p64" },
> + { .compatible = "m25p128" },
> + { .compatible = "w25x80" },
> + { .compatible = "w25x32" },
> + { .compatible = "w25q32" },
> + { .compatible = "w25q32dw" },
> + { .compatible = "w25q80bl" },
> + { .compatible = "w25q128" },
> + { .compatible = "w25q256" },
> + { .compatible = "m25p05-nonjedec" },
> + { .compatible = "m25p10-nonjedec" },
> + { .compatible = "m25p20-nonjedec" },
> + { .compatible = "m25p40-nonjedec" },
> + { .compatible = "m25p80-nonjedec" },
> + { .compatible = "m25p16-nonjedec" },
> + { .compatible = "m25p32-nonjedec" },
> + { .compatible = "m25p64-nonjedec" },
> + { .compatible = "m25p128-nonjedec" },
> + { .compatible = "mr25h128" },
> + { .compatible = "mr25h256" },
> + { .compatible = "mr25h10" },
> + { .compatible = "mr25h40" },
> {}
> };
> MODULE_DEVICE_TABLE(of, m25p_of_table);
> --
> 2.7.4
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> -----Original Message-----
> From: David Woodhouse <[email protected]>
> Sent: giovedì 7 marzo 2019 18:40
> To: Flavio Suligoi <[email protected]>; Brian Norris
> <[email protected]>; Boris Brezillon <[email protected]>;
> Marek Vasut <[email protected]>; Richard Weinberger <[email protected]>;
> Mark Brown <[email protected]>; Frieder Schrempf
> <[email protected]>; Yogesh Gaur <[email protected]>;
> [email protected]; [email protected]
> Subject: Re: [PATCH v1 1/1] mtd: devices: add ACPI support for non-jedec
> m25p80
>
> On Tue, 2019-02-26 at 11:48 +0100, Flavio Suligoi wrote:
> > For the x86 machines a m25p80-compatible device have to be declared
> using
> > an ACPI table (which can be directly a part of the BIOS ACPI tables).
> >
> > In this case it is necessary to add the device in the "of_device_id"
> structure
> > list, to permit the device name matching by the ACPI kernel functions.
> >
> > This is an example of a SSDT table for the Everspin mr25h40:
> >
> > DefinitionBlock ("mr25h40.aml", "SSDT", 5, "ASEMsp", "MR25H40", 1)
> > {
> > External (_SB.SPI1, DeviceObj)
> >
> > Scope (\_SB.SPI1)
> > {
> > Device (NVR0)
> > {
> > Name (_HID, "PRP0001")
> > Name (_DDN, "Everspin MR25H40 MRAM")
> > Name (_CRS, ResourceTemplate () {
> > SpiSerialBus (
> > 1, // Chip select
> > PolarityLow, // Chip select is active
> low
> > FourWireMode, // Full duplex
> > 8, // Bits per word is 8
> (byte)
> > ControllerInitiated, // Don't care
> > 10000000, // 10 MHz
> > ClockPolarityLow, // SPI mode 0
> ClockPolarityLow
> > ClockPhaseFirst, // SPI mode 0
> ClockPhaseFirst
> > "\\_SB.SPI1", // SPI host controller
> > 0, // Must be 0
> > ResourceConsumer,
> > ,
> > )
> > })
> >
> > Name (_DSD, Package () {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package () {
> > Package () {"compatible", "mr25h40"},
> > }
> > })
> > }
> > }
> > }
> >
> > Signed-off-by: Flavio Suligoi <[email protected]>
>
> Why use the specific chip name in the "compatible" property? Why isn't
> it using "jedec,spi-nor"?
>
> Does this still actually get passed through to spi_nor_scan()... and is
> it *necessary*? Can't the chips be probed?
>
Hi David,
exactly, the mr25h40 is not Jedec compatible, so it can't be probed,
so it is necessary to identify it explicitly.
Flavio