As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
its content is being used solely internally to SPI subsystem
(PXA2xx drivers). Hence this refactoring series with the additional
win of getting rid of legacy documentation.
Cc: Arnd Bergmann <[email protected]>
Andy Shevchenko (10):
spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
spi: pxa2xx: Keep PXA*_SSP types together
spi: pxa2xx: Switch to use dev_err_probe()
spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
spi: pxa2xx: Skip SSP initialization if it's done elsewhere
spi: pxa2xx: Allow number of chip select pins to be read from property
spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one
spi: pxa2xx: Remove outdated documentation
spi: pxa2xx: Don't use "proxy" headers
Documentation/spi/pxa2xx.rst | 208 ---------------------------------
arch/arm/mach-pxa/spitz.c | 25 ++--
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-pxa2xx-dma.c | 11 +-
drivers/spi/spi-pxa2xx-pci.c | 10 +-
drivers/spi/spi-pxa2xx.c | 118 +++++++++++--------
drivers/spi/spi-pxa2xx.h | 39 ++++++-
include/linux/pxa2xx_ssp.h | 2 +-
include/linux/spi/pxa2xx_spi.h | 48 --------
9 files changed, 140 insertions(+), 323 deletions(-)
delete mode 100644 Documentation/spi/pxa2xx.rst
delete mode 100644 include/linux/spi/pxa2xx_spi.h
--
2.43.0.rc1.1.gbec44491f096
Refactor pxa2xx_spi_init_pdata() by extracting a new
pxa2xx_spi_init_ssp() helper which makes code less
twisted. It will be easier to continue refactoring for
a new coming modification.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 66 +++++++++++++++++++++++-----------------
1 file changed, 38 insertions(+), 28 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 75d208087748..e7072727c25c 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1314,19 +1314,50 @@ static bool pxa2xx_spi_idma_filter(struct dma_chan *chan, void *param)
return param == chan->device->dev;
}
+static int
+pxa2xx_spi_init_ssp(struct platform_device *pdev, struct ssp_device *ssp, enum pxa_ssp_type type)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ int status;
+ u64 uid;
+
+ ssp->mmio_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+ if (IS_ERR(ssp->mmio_base))
+ return PTR_ERR(ssp->mmio_base);
+
+ ssp->phys_base = res->start;
+
+ ssp->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ssp->clk))
+ return PTR_ERR(ssp->clk);
+
+ ssp->irq = platform_get_irq(pdev, 0);
+ if (ssp->irq < 0)
+ return ssp->irq;
+
+ ssp->type = type;
+ ssp->dev = dev;
+
+ status = acpi_dev_uid_to_integer(ACPI_COMPANION(dev), &uid);
+ if (status)
+ ssp->port_id = -1;
+ else
+ ssp->port_id = uid;
+
+ return 0;
+}
+
static struct pxa2xx_spi_controller *
pxa2xx_spi_init_pdata(struct platform_device *pdev)
{
struct pxa2xx_spi_controller *pdata;
struct device *dev = &pdev->dev;
struct device *parent = dev->parent;
- struct ssp_device *ssp;
- struct resource *res;
enum pxa_ssp_type type = SSP_UNDEFINED;
const void *match;
bool is_lpss_priv;
int status;
- u64 uid;
is_lpss_priv = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpss_priv");
@@ -1351,14 +1382,6 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
if (!pdata)
return ERR_PTR(-ENOMEM);
- ssp = &pdata->ssp;
-
- ssp->mmio_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
- if (IS_ERR(ssp->mmio_base))
- return ERR_CAST(ssp->mmio_base);
-
- ssp->phys_base = res->start;
-
/* Platforms with iDMA 64-bit */
if (is_lpss_priv) {
pdata->tx_param = parent;
@@ -1366,28 +1389,15 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
pdata->dma_filter = pxa2xx_spi_idma_filter;
}
- ssp->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(ssp->clk))
- return ERR_CAST(ssp->clk);
-
- ssp->irq = platform_get_irq(pdev, 0);
- if (ssp->irq < 0)
- return ERR_PTR(ssp->irq);
-
- ssp->type = type;
- ssp->dev = dev;
-
- status = acpi_dev_uid_to_integer(ACPI_COMPANION(dev), &uid);
- if (status)
- ssp->port_id = -1;
- else
- ssp->port_id = uid;
-
pdata->is_target = device_property_read_bool(dev, "spi-slave");
pdata->num_chipselect = 1;
pdata->enable_dma = true;
pdata->dma_burst_size = 1;
+ status = pxa2xx_spi_init_ssp(pdev, &pdata->ssp, type);
+ if (status)
+ return ERR_PTR(status);
+
return pdata;
}
--
2.43.0.rc1.1.gbec44491f096
In some cases the number of the chip select pins might come from
the device property. Allow driver to use it.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index b01a18c89b6b..f4435c39d096 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1358,6 +1358,7 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
struct ssp_device *ssp = NULL;
const void *match;
bool is_lpss_priv;
+ u32 num_cs = 1;
int status;
is_lpss_priv = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpss_priv");
@@ -1394,8 +1395,11 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
pdata->dma_filter = pxa2xx_spi_idma_filter;
}
+ /* Read number of chip select pins, if provided */
+ device_property_read_u32(dev, "num-cs", &num_cs);
+
+ pdata->num_chipselect = num_cs;
pdata->is_target = device_property_read_bool(dev, "spi-slave");
- pdata->num_chipselect = 1;
pdata->enable_dma = true;
pdata->dma_burst_size = 1;
--
2.43.0.rc1.1.gbec44491f096
Since driver can parse num-cs device property, replace platform data
with this new approach.
Signed-off-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-pxa/spitz.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 318402ad685e..3c5f5a3cb480 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -18,10 +18,10 @@
#include <linux/i2c.h>
#include <linux/platform_data/i2c-pxa.h>
#include <linux/platform_data/pca953x.h>
+#include <linux/property.h>
#include <linux/spi/spi.h>
#include <linux/spi/ads7846.h>
#include <linux/spi/corgi_lcd.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/mtd/sharpsl.h>
#include <linux/mtd/physmap.h>
#include <linux/input-event-codes.h>
@@ -569,10 +569,6 @@ static struct spi_board_info spitz_spi_devices[] = {
},
};
-static struct pxa2xx_spi_controller spitz_spi_info = {
- .num_chipselect = 3,
-};
-
static struct gpiod_lookup_table spitz_spi_gpio_table = {
.dev_id = "spi2",
.table = {
@@ -583,10 +579,20 @@ static struct gpiod_lookup_table spitz_spi_gpio_table = {
},
};
+static const struct property_entry spitz_spi_properties[] = {
+ PROPERTY_ENTRY_U32("num-cs", 3),
+ { }
+};
+
+static const struct software_node spitz_spi_node = {
+ .properties = spitz_spi_properties,
+};
+
static void __init spitz_spi_init(void)
{
struct platform_device *pd;
int id = 2;
+ int err;
if (machine_is_akita())
gpiod_add_lookup_table(&akita_lcdcon_gpio_table);
@@ -601,8 +607,13 @@ static void __init spitz_spi_init(void)
if (pd == NULL) {
pr_err("pxa2xx-spi: failed to allocate device id %d\n", id);
} else {
- pd->dev.platform_data = &spitz_spi_info;
- platform_device_add(pd);
+ err = device_add_software_node(&pd->dev, &spitz_spi_node);
+ if (err) {
+ platform_device_put(pd);
+ pr_err("pxa2xx-spi: failed to add software node\n");
+ } else {
+ platform_device_add(pd);
+ }
}
spi_register_board_info(ARRAY_AND_SIZE(spitz_spi_devices));
--
2.43.0.rc1.1.gbec44491f096
There is no user of the linux/spi/pxa2xx_spi.h. Move its contents
to the drivers/spi/spi-pxa2xx.h.
Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx-dma.c | 1 -
drivers/spi/spi-pxa2xx-pci.c | 4 +--
drivers/spi/spi-pxa2xx.c | 1 -
drivers/spi/spi-pxa2xx.h | 36 ++++++++++++++++++++++++-
include/linux/spi/pxa2xx_spi.h | 48 ----------------------------------
5 files changed, 37 insertions(+), 53 deletions(-)
delete mode 100644 include/linux/spi/pxa2xx_spi.h
diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index be563f0dd03a..26416ced6505 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -12,7 +12,6 @@
#include <linux/scatterlist.h>
#include <linux/sizes.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 861b21c63504..e11a613bc340 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -10,11 +10,11 @@
#include <linux/pci.h>
#include <linux/platform_device.h>
-#include <linux/spi/pxa2xx_spi.h>
-
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
+#include "spi-pxa2xx.h"
+
#define PCI_DEVICE_ID_INTEL_QUARK_X1000 0x0935
#define PCI_DEVICE_ID_INTEL_BYT 0x0f0e
#define PCI_DEVICE_ID_INTEL_MRFLD 0x1194
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index f4435c39d096..e22d9d29c7e9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -24,7 +24,6 @@
#include <linux/property.h>
#include <linux/slab.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 45cdbbc71c4b..08296729ea80 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -7,6 +7,7 @@
#ifndef SPI_PXA2XX_H
#define SPI_PXA2XX_H
+#include <linux/dmaengine.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/types.h>
@@ -15,7 +16,40 @@
#include <linux/pxa2xx_ssp.h>
struct gpio_desc;
-struct pxa2xx_spi_controller;
+
+/*
+ * The platform data for SSP controller devices
+ * (resides in device.platform_data).
+ */
+struct pxa2xx_spi_controller {
+ u8 num_chipselect;
+ u8 enable_dma;
+ u8 dma_burst_size;
+ bool is_target;
+
+ /* DMA engine specific config */
+ dma_filter_fn dma_filter;
+ void *tx_param;
+ void *rx_param;
+
+ /* For non-PXA arches */
+ struct ssp_device ssp;
+};
+
+/*
+ * The controller specific data for SPI target devices
+ * (resides in spi_board_info.controller_data),
+ * copied to spi_device.platform_data ... mostly for
+ * DMA tuning.
+ */
+struct pxa2xx_spi_chip {
+ u8 tx_threshold;
+ u8 tx_hi_threshold;
+ u8 rx_threshold;
+ u8 dma_burst_size;
+ u32 timeout;
+};
+
struct spi_controller;
struct spi_device;
struct spi_transfer;
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
deleted file mode 100644
index e5a4a045fb67..000000000000
--- a/include/linux/spi/pxa2xx_spi.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2005 Stephen Street / StreetFire Sound Labs
- */
-#ifndef __LINUX_SPI_PXA2XX_SPI_H
-#define __LINUX_SPI_PXA2XX_SPI_H
-
-#include <linux/dmaengine.h>
-#include <linux/types.h>
-
-#include <linux/pxa2xx_ssp.h>
-
-struct dma_chan;
-
-/*
- * The platform data for SSP controller devices
- * (resides in device.platform_data).
- */
-struct pxa2xx_spi_controller {
- u8 num_chipselect;
- u8 enable_dma;
- u8 dma_burst_size;
- bool is_target;
-
- /* DMA engine specific config */
- dma_filter_fn dma_filter;
- void *tx_param;
- void *rx_param;
-
- /* For non-PXA arches */
- struct ssp_device ssp;
-};
-
-/*
- * The controller specific data for SPI target devices
- * (resides in spi_board_info.controller_data),
- * copied to spi_device.platform_data ... mostly for
- * DMA tuning.
- */
-struct pxa2xx_spi_chip {
- u8 tx_threshold;
- u8 tx_hi_threshold;
- u8 rx_threshold;
- u8 dma_burst_size;
- u32 timeout;
-};
-
-#endif /* __LINUX_SPI_PXA2XX_SPI_H */
--
2.43.0.rc1.1.gbec44491f096
The documentation is referring to the legacy enumeration of the SPI
host controllers and target devices. It has nothing to do with the
modern way, which is the only supported in kernel right now. Hence,
remove outdated documentation file.
Signed-off-by: Andy Shevchenko <[email protected]>
---
Documentation/spi/pxa2xx.rst | 208 -----------------------------------
1 file changed, 208 deletions(-)
delete mode 100644 Documentation/spi/pxa2xx.rst
diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst
deleted file mode 100644
index 33d2ad95901e..000000000000
--- a/Documentation/spi/pxa2xx.rst
+++ /dev/null
@@ -1,208 +0,0 @@
-==============================
-PXA2xx SPI on SSP driver HOWTO
-==============================
-
-This a mini HOWTO on the pxa2xx_spi driver. The driver turns a PXA2xx
-synchronous serial port into an SPI host controller
-(see Documentation/spi/spi-summary.rst). The driver has the following features
-
-- Support for any PXA2xx and compatible SSP.
-- SSP PIO and SSP DMA data transfers.
-- External and Internal (SSPFRM) chip selects.
-- Per peripheral device (chip) configuration.
-- Full suspend, freeze, resume support.
-
-The driver is built around a &struct spi_message FIFO serviced by kernel
-thread. The kernel thread, spi_pump_messages(), drives message FIFO and
-is responsible for queuing SPI transactions and setting up and launching
-the DMA or interrupt driven transfers.
-
-Declaring PXA2xx host controllers
----------------------------------
-Typically, for a legacy platform, an SPI host controller is defined in the
-arch/.../mach-*/board-*.c as a "platform device". The host controller configuration
-is passed to the driver via a table found in include/linux/spi/pxa2xx_spi.h::
-
- struct pxa2xx_spi_controller {
- u8 num_chipselect;
- u8 enable_dma;
- ...
- };
-
-The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of
-peripheral devices (chips) attached to this SPI host controller.
-
-The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should
-be used. This caused the driver to acquire two DMA channels: Rx channel and
-Tx channel. The Rx channel has a higher DMA service priority than the Tx channel.
-See the "PXA2xx Developer Manual" section "DMA Controller".
-
-For the new platforms the description of the controller and peripheral devices
-comes from Device Tree or ACPI.
-
-NSSP HOST SAMPLE
-----------------
-Below is a sample configuration using the PXA255 NSSP for a legacy platform::
-
- static struct resource pxa_spi_nssp_resources[] = {
- [0] = {
- .start = __PREG(SSCR0_P(2)), /* Start address of NSSP */
- .end = __PREG(SSCR0_P(2)) + 0x2c, /* Range of registers */
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_NSSP, /* NSSP IRQ */
- .end = IRQ_NSSP,
- .flags = IORESOURCE_IRQ,
- },
- };
-
- static struct pxa2xx_spi_controller pxa_nssp_controller_info = {
- .num_chipselect = 1, /* Matches the number of chips attached to NSSP */
- .enable_dma = 1, /* Enables NSSP DMA */
- };
-
- static struct platform_device pxa_spi_nssp = {
- .name = "pxa2xx-spi", /* MUST BE THIS VALUE, so device match driver */
- .id = 2, /* Bus number, MUST MATCH SSP number 1..n */
- .resource = pxa_spi_nssp_resources,
- .num_resources = ARRAY_SIZE(pxa_spi_nssp_resources),
- .dev = {
- .platform_data = &pxa_nssp_controller_info, /* Passed to driver */
- },
- };
-
- static struct platform_device *devices[] __initdata = {
- &pxa_spi_nssp,
- };
-
- static void __init board_init(void)
- {
- (void)platform_add_device(devices, ARRAY_SIZE(devices));
- }
-
-Declaring peripheral devices
-----------------------------
-Typically, for a legacy platform, each SPI peripheral device (chip) is defined in the
-arch/.../mach-*/board-*.c using the "spi_board_info" structure found in
-"linux/spi/spi.h". See "Documentation/spi/spi-summary.rst" for additional
-information.
-
-Each peripheral device (chip) attached to the PXA2xx must provide specific chip configuration
-information via the structure "pxa2xx_spi_chip" found in
-"include/linux/spi/pxa2xx_spi.h". The PXA2xx host controller driver will use
-the configuration whenever the driver communicates with the peripheral
-device. All fields are optional.
-
-::
-
- struct pxa2xx_spi_chip {
- u8 tx_threshold;
- u8 rx_threshold;
- u8 dma_burst_size;
- u32 timeout;
- };
-
-The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are
-used to configure the SSP hardware FIFO. These fields are critical to the
-performance of pxa2xx_spi driver and misconfiguration will result in rx
-FIFO overruns (especially in PIO mode transfers). Good default values are::
-
- .tx_threshold = 8,
- .rx_threshold = 8,
-
-The range is 1 to 16 where zero indicates "use default".
-
-The "pxa2xx_spi_chip.dma_burst_size" field is used to configure PXA2xx DMA
-engine and is related the "spi_device.bits_per_word" field. Read and understand
-the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers
-to determine the correct value. An SSP configured for byte-wide transfers would
-use a value of 8. The driver will determine a reasonable default if
-dma_burst_size == 0.
-
-The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle
-trailing bytes in the SSP receiver FIFO. The correct value for this field is
-dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific
-peripheral device. Please note that the PXA2xx SSP 1 does not support trailing byte
-timeouts and must busy-wait any trailing bytes.
-
-NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the
-chipselect is dropped after each spi_transfer. Most devices need chip select
-asserted around the complete message. Use SSPFRM as a GPIO (through a descriptor)
-to accommodate these chips.
-
-
-NSSP PERIPHERAL SAMPLE
-----------------------
-For a legacy platform or in some other cases, the pxa2xx_spi_chip structure
-is passed to the pxa2xx_spi driver in the "spi_board_info.controller_data"
-field. Below is a sample configuration using the PXA255 NSSP.
-
-::
-
- static struct pxa2xx_spi_chip cs8415a_chip_info = {
- .tx_threshold = 8, /* SSP hardware FIFO threshold */
- .rx_threshold = 8, /* SSP hardware FIFO threshold */
- .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */
- .timeout = 235, /* See Intel documentation */
- };
-
- static struct pxa2xx_spi_chip cs8405a_chip_info = {
- .tx_threshold = 8, /* SSP hardware FIFO threshold */
- .rx_threshold = 8, /* SSP hardware FIFO threshold */
- .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */
- .timeout = 235, /* See Intel documentation */
- };
-
- static struct spi_board_info streetracer_spi_board_info[] __initdata = {
- {
- .modalias = "cs8415a", /* Name of spi_driver for this device */
- .max_speed_hz = 3686400, /* Run SSP as fast a possible */
- .bus_num = 2, /* Framework bus number */
- .chip_select = 0, /* Framework chip select */
- .platform_data = NULL; /* No spi_driver specific config */
- .controller_data = &cs8415a_chip_info, /* Host controller config */
- .irq = STREETRACER_APCI_IRQ, /* Peripheral device interrupt */
- },
- {
- .modalias = "cs8405a", /* Name of spi_driver for this device */
- .max_speed_hz = 3686400, /* Run SSP as fast a possible */
- .bus_num = 2, /* Framework bus number */
- .chip_select = 1, /* Framework chip select */
- .controller_data = &cs8405a_chip_info, /* Host controller config */
- .irq = STREETRACER_APCI_IRQ, /* Peripheral device interrupt */
- },
- };
-
- static void __init streetracer_init(void)
- {
- spi_register_board_info(streetracer_spi_board_info,
- ARRAY_SIZE(streetracer_spi_board_info));
- }
-
-
-DMA and PIO I/O Support
------------------------
-The pxa2xx_spi driver supports both DMA and interrupt driven PIO message
-transfers. The driver defaults to PIO mode and DMA transfers must be enabled
-by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure.
-For the newer platforms, that are known to support DMA, the driver will enable
-it automatically and try it first with a possible fallback to PIO. The DMA
-mode supports both coherent and stream based DMA mappings.
-
-The following logic is used to determine the type of I/O to be used on
-a per "spi_transfer" basis::
-
- if spi_message.len > 65536 then
- print "rate limited" warning
- use PIO transfers
-
- if enable_dma and the size is in the range [DMA burst size..65536] then
- use streaming DMA mode
-
- otherwise
- use PIO transfer
-
-THANKS TO
----------
-David Brownell and others for mentoring the development of this driver.
--
2.43.0.rc1.1.gbec44491f096
On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
> Since driver can parse num-cs device property, replace platform data
> with this new approach.
But why?
> -static struct pxa2xx_spi_controller spitz_spi_info = {
> - .num_chipselect = 3,
> -};
> +static const struct property_entry spitz_spi_properties[] = {
> + PROPERTY_ENTRY_U32("num-cs", 3),
> + { }
> +};
This is just platform data with less validation AFAICT.
On Tue, Mar 26, 2024 at 06:21:48PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
>
> > Since driver can parse num-cs device property, replace platform data
> > with this new approach.
>
> But why?
To be able to hide the header's contents from public.
Should I update the commit message?
..
> > +static const struct property_entry spitz_spi_properties[] = {
> > + PROPERTY_ENTRY_U32("num-cs", 3),
> > + { }
> > +};
>
> This is just platform data with less validation AFAICT.
I'm not sure what validation you are expecting here. It should be done via
DT schema ideally when the platform gets converted to DT. This change is
an interim to that (at least it makes kernel side better). After the platform
code may be gone completely or converted. If the latter happens, we got
the validation back.
In any case it's not worse than plain DT property handling in the kernel.
The validation in that case is done elsewhere. Since the property is defined
in board files the assumed validation is done during development/review
stages. But OTOH for the legacy code we need not to touch the property
provider more than once. We are _not_ expecting this to be spread.
--
With Best Regards,
Andy Shevchenko
Switch to use dev_err_probe() to simplify the error path and
unify a message template.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 2c39d3ff498e..75d208087748 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1434,20 +1434,16 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
platform_info = dev_get_platdata(dev);
if (!platform_info) {
platform_info = pxa2xx_spi_init_pdata(pdev);
- if (IS_ERR(platform_info)) {
- dev_err(&pdev->dev, "missing platform data\n");
- return PTR_ERR(platform_info);
- }
+ if (IS_ERR(platform_info))
+ return dev_err_probe(dev, PTR_ERR(platform_info), "missing platform data\n");
}
ssp = pxa_ssp_request(pdev->id, pdev->name);
if (!ssp)
ssp = &platform_info->ssp;
- if (!ssp->mmio_base) {
- dev_err(&pdev->dev, "failed to get SSP\n");
- return -ENODEV;
- }
+ if (!ssp->mmio_base)
+ return dev_err_probe(dev, -ENODEV, "failed to get SSP\n");
if (platform_info->is_target)
controller = devm_spi_alloc_target(dev, sizeof(*drv_data));
@@ -1455,8 +1451,7 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
controller = devm_spi_alloc_host(dev, sizeof(*drv_data));
if (!controller) {
- dev_err(&pdev->dev, "cannot alloc spi_controller\n");
- status = -ENOMEM;
+ status = dev_err_probe(dev, -ENOMEM, "cannot alloc spi_controller\n");
goto out_error_controller_alloc;
}
drv_data = spi_controller_get_devdata(controller);
@@ -1510,7 +1505,7 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
status = request_irq(ssp->irq, ssp_int, IRQF_SHARED, dev_name(dev),
drv_data);
if (status < 0) {
- dev_err(&pdev->dev, "cannot get IRQ %d\n", ssp->irq);
+ dev_err_probe(dev, status, "cannot get IRQ %d\n", ssp->irq);
goto out_error_controller_alloc;
}
@@ -1626,7 +1621,7 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, drv_data);
status = spi_register_controller(controller);
if (status) {
- dev_err(&pdev->dev, "problem registering SPI controller\n");
+ dev_err_probe(dev, status, "problem registering SPI controller\n");
goto out_error_pm_runtime_enabled;
}
--
2.43.0.rc1.1.gbec44491f096
On Tue, Mar 26, 2024 at 08:50:04PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 06:21:48PM +0000, Mark Brown wrote:
> > On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
> > > Since driver can parse num-cs device property, replace platform data
> > > with this new approach.
> > But why?
> To be able to hide the header's contents from public.
> Should I update the commit message?
That would definitely help, but it's hard to see what the actual benefit
is here. It's removing platform data without doing the more difficult
bit where the platform gets converted to DT.
> > > +static const struct property_entry spitz_spi_properties[] = {
> > > + PROPERTY_ENTRY_U32("num-cs", 3),
> > > + { }
> > > +};
> > This is just platform data with less validation AFAICT.
> I'm not sure what validation you are expecting here. It should be done via
Well, the problem with swnode is that there's no validation to expect -
it's an inherent problem with swnode.
> DT schema ideally when the platform gets converted to DT. This change is
> an interim to that (at least it makes kernel side better). After the platform
> code may be gone completely or converted. If the latter happens, we got
> the validation back.
It is not clear to me that this makes the kernel side better, it just
seems to be rewriting the platform data for the sake of it. If it was
converting to DT there'd be some stuff from it being DT but this keeps
everything as in kernel as board files, just in a more complex form.
> In any case it's not worse than plain DT property handling in the kernel.
> The validation in that case is done elsewhere. Since the property is defined
> in board files the assumed validation is done during development/review
> stages. But OTOH for the legacy code we need not to touch the property
> provider more than once. We are _not_ expecting this to be spread.
I'm guessing you're just checking this by inspection though...
On Tue, Mar 26, 2024 at 10:12:12PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 08:02:57PM +0000, Mark Brown wrote:
> > It is not clear to me that this makes the kernel side better, it just
> > seems to be rewriting the platform data for the sake of it. If it was
> > converting to DT there'd be some stuff from it being DT but this keeps
> > everything as in kernel as board files, just in a more complex form.
> Not really. The benefits with swnode conversion are the following:
> - reducing custom APIs / data types between _shared_ (in a sense of
> supporting zillion different platforms) driver and a certain board
> file
> - as an effect of the above, reducing kernel code base, and as the result
> make maintenance easier and bug-free for that parts
I'm more worried about the possibility of breaking things with swnode
support than I am for board files - with board files you've got a good
chance of failing to compile if things get messed up, with swnode you
can typo a property or whatever and silently fail.
> - preparing a driver to be ready for any old board file conversion to DT
> as it reduces that churn (you won't need to touch the driver code)
The driver appears to already have DT support (there's a compatible for
MMP2 in there)?
Update header inclusions to follow IWYU (Include What You Use)
principle.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx-dma.c | 10 ++++++++--
drivers/spi/spi-pxa2xx-pci.c | 6 ++++++
drivers/spi/spi-pxa2xx.c | 10 +++++++---
drivers/spi/spi-pxa2xx.h | 3 +--
4 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 26416ced6505..751cb0f77b62 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -6,16 +6,22 @@
* Author: Mika Westerberg <[email protected]>
*/
-#include <linux/device.h>
+#include <linux/atomic.h>
+#include <linux/dev_printk.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
+#include <linux/errno.h>
+#include <linux/irqreturn.h>
#include <linux/scatterlist.h>
-#include <linux/sizes.h>
+#include <linux/string.h>
+#include <linux/types.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
+struct device;
+
static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
bool error)
{
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index e11a613bc340..6d2efdb0e95f 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -6,9 +6,15 @@
* Copyright (C) 2016, 2021 Intel Corporation
*/
#include <linux/clk-provider.h>
+#include <linux/device.h>
+#include <linux/err.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/sprintf.h>
+#include <linux/string.h>
+#include <linux/types.h>
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index e22d9d29c7e9..86d0f1064a45 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -5,24 +5,28 @@
*/
#include <linux/acpi.h>
+#include <linux/atomic.h>
#include <linux/bitops.h>
+#include <linux/bug.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/dmaengine.h>
#include <linux/err.h>
-#include <linux/errno.h>
#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/io.h>
#include <linux/ioport.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/math64.h>
+#include <linux/minmax.h>
#include <linux/mod_devicetable.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/property.h>
#include <linux/slab.h>
+#include <linux/types.h>
#include <linux/spi/spi.h>
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 08296729ea80..f1097c96c50f 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -8,8 +8,7 @@
#define SPI_PXA2XX_H
#include <linux/dmaengine.h>
-#include <linux/interrupt.h>
-#include <linux/io.h>
+#include <linux/irqreturn.h>
#include <linux/types.h>
#include <linux/sizes.h>
--
2.43.0.rc1.1.gbec44491f096
On Tue, Mar 26, 2024 at 08:26:11PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 10:12:12PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 08:02:57PM +0000, Mark Brown wrote:
>
> > > It is not clear to me that this makes the kernel side better, it just
> > > seems to be rewriting the platform data for the sake of it. If it was
> > > converting to DT there'd be some stuff from it being DT but this keeps
> > > everything as in kernel as board files, just in a more complex form.
>
> > Not really. The benefits with swnode conversion are the following:
>
> > - reducing custom APIs / data types between _shared_ (in a sense of
> > supporting zillion different platforms) driver and a certain board
> > file
>
> > - as an effect of the above, reducing kernel code base, and as the result
> > make maintenance easier and bug-free for that parts
>
> I'm more worried about the possibility of breaking things with swnode
> support than I am for board files - with board files you've got a good
> chance of failing to compile if things get messed up, with swnode you
> can typo a property or whatever and silently fail.
I understand that, but here it's consolidated in a single series
and not supposed to be modified in the future, only dropping or
properly converting.
Btw, you may say the same about the all patches that converts to
GPIO lookup tables (one typo in the not-so-often used GPIO line
device ID name), but I don't remember that kind of conversions
got much of objection.
> > - preparing a driver to be ready for any old board file conversion to DT
> > as it reduces that churn (you won't need to touch the driver code)
>
> The driver appears to already have DT support (there's a compatible for
> MMP2 in there)?
The MMP2 is using default number of chip select pins.
Also note that my reply is generic (I used 'a driver' form).
--
With Best Regards,
Andy Shevchenko
On Tue, 26 Mar 2024 20:07:50 +0200, Andy Shevchenko wrote:
> As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> its content is being used solely internally to SPI subsystem
> (PXA2xx drivers). Hence this refactoring series with the additional
> win of getting rid of legacy documentation.
>
> Cc: Arnd Bergmann <[email protected]>
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[02/10] spi: pxa2xx: Keep PXA*_SSP types together
commit: dad983d8812975b53db83f02ae6b0ad15f018a9e
[03/10] spi: pxa2xx: Switch to use dev_err_probe()
commit: d5449432f794e75cd4f5e46bc33bfe6ce20b657d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Keep the PXA*_SSP types together in enum pxa_ssp_type
for better maintenance.
Signed-off-by: Andy Shevchenko <[email protected]>
---
include/linux/pxa2xx_ssp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index cd1973e6ac4b..844a2743ca94 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -217,9 +217,9 @@ enum pxa_ssp_type {
PXA27x_SSP,
PXA3xx_SSP,
PXA168_SSP,
- MMP2_SSP,
PXA910_SSP,
CE4100_SSP,
+ MMP2_SSP,
MRFLD_SSP,
QUARK_X1000_SSP,
/* Keep LPSS types sorted with lpss_platforms[] */
--
2.43.0.rc1.1.gbec44491f096
On Tue, Mar 26, 2024 at 08:02:57PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:50:04PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 06:21:48PM +0000, Mark Brown wrote:
> > > On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
>
> > > > Since driver can parse num-cs device property, replace platform data
> > > > with this new approach.
>
> > > But why?
>
> > To be able to hide the header's contents from public.
> > Should I update the commit message?
>
> That would definitely help, but it's hard to see what the actual benefit
> is here. It's removing platform data without doing the more difficult
> bit where the platform gets converted to DT.
Will do in v2.
> > > > +static const struct property_entry spitz_spi_properties[] = {
> > > > + PROPERTY_ENTRY_U32("num-cs", 3),
> > > > + { }
> > > > +};
>
> > > This is just platform data with less validation AFAICT.
>
> > I'm not sure what validation you are expecting here. It should be done via
>
> Well, the problem with swnode is that there's no validation to expect -
> it's an inherent problem with swnode.
I do not object this.
> > DT schema ideally when the platform gets converted to DT. This change is
> > an interim to that (at least it makes kernel side better). After the platform
> > code may be gone completely or converted. If the latter happens, we got
> > the validation back.
>
> It is not clear to me that this makes the kernel side better, it just
> seems to be rewriting the platform data for the sake of it. If it was
> converting to DT there'd be some stuff from it being DT but this keeps
> everything as in kernel as board files, just in a more complex form.
Not really. The benefits with swnode conversion are the following:
- reducing custom APIs / data types between _shared_ (in a sense of
supporting zillion different platforms) driver and a certain board
file
- as an effect of the above, reducing kernel code base, and as the result
make maintenance easier and bug-free for that parts
- preparing a driver to be ready for any old board file conversion to DT
as it reduces that churn (you won't need to touch the driver code)
- ...anything else I forgot to mention...
> > In any case it's not worse than plain DT property handling in the kernel.
> > The validation in that case is done elsewhere. Since the property is defined
> > in board files the assumed validation is done during development/review
> > stages. But OTOH for the legacy code we need not to touch the property
> > provider more than once. We are _not_ expecting this to be spread.
>
> I'm guessing you're just checking this by inspection though...
Yes, we seems do not have any tool to perform a such against software nodes.
--
With Best Regards,
Andy Shevchenko
If SSP has been enumerated elsewhere, skip its initialization
in pxa2xx_spi_init_pdata().
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index e7072727c25c..b01a18c89b6b 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1355,6 +1355,7 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device *parent = dev->parent;
enum pxa_ssp_type type = SSP_UNDEFINED;
+ struct ssp_device *ssp = NULL;
const void *match;
bool is_lpss_priv;
int status;
@@ -1372,6 +1373,10 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
return ERR_PTR(status);
type = (enum pxa_ssp_type)value;
+ } else {
+ ssp = pxa_ssp_request(pdev->id, pdev->name);
+ if (ssp)
+ type = ssp->type;
}
/* Validate the SSP type correctness */
@@ -1394,6 +1399,10 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
pdata->enable_dma = true;
pdata->dma_burst_size = 1;
+ /* If SSP has been already enumerated, use it */
+ if (ssp)
+ return pdata;
+
status = pxa2xx_spi_init_ssp(pdev, &pdata->ssp, type);
if (status)
return ERR_PTR(status);
--
2.43.0.rc1.1.gbec44491f096