[PATCH 4/4] spi: s3c64xx: add support for exynos5440 spi
This patch adds support for the exynos5440 spi controller.
The integration of the spi IP in exynos5440 is different from
other SoC's. The I/O pins are no more configured via gpio, they
have dedicated pins.
Signed-off-by: Girish K S
---
drivers/spi/spi-s3c64xx.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f06bbee..bf26abc 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1547,6 +1547,15 @@ static struct s3c64xx_spi_port_config
exynos4_spi_port_config = {
.clk_from_cmu = true,
};
+static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
+ .fifo_lvl_mask = { 0xff },
+ .rx_lvl_offset = 15,
+ .tx_st_done = 25,
+ .high_speed = true,
+ .clk_from_cmu = true,
+ .quirks = S3C64XX_SPI_QUIRK_GPIO | S3C64XX_SPI_QUIRK_POLL,
+};
+
static struct platform_device_id s3c64xx_spi_driver_ids[] = {
{
.name = "s3c2443-spi",
@@ -1575,6 +1584,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] =
{
{ .compatible = "samsung,exynos4210-spi",
.data = (void *)&exynos4_spi_port_config,
},
+ { .compatible = "samsung,exynos5440-spi",
+ .data = (void *)&exynos5440_spi_port_config,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, s3c64xx_spi_dt_match);
--
1.7.10.4
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/4] spi: s3c64xx: added support for polling mode
The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.
Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.
Signed-off-by: Girish K S
---
drivers/spi/spi-s3c64xx.c | 65 +
1 file changed, 30 insertions(+), 35 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index b770f88..90770bd 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -35,6 +35,7 @@
#include
#define MAX_SPI_PORTS 3
+#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
/* Registers and bit-fields */
@@ -126,6 +127,7 @@
#define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
#define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
+#define is_polling(x) (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
#define RXBUSY(1<<2)
#define TXBUSY(1<<3)
@@ -155,6 +157,7 @@ struct s3c64xx_spi_port_config {
int fifo_lvl_mask[MAX_SPI_PORTS];
int rx_lvl_offset;
int tx_st_done;
+ int quirks;
boolhigh_speed;
boolclk_from_cmu;
};
@@ -345,19 +348,7 @@ static void enable_datapath(struct s3c64xx_spi_driver_data
*sdd,
chcfg = readl(regs + S3C64XX_SPI_CH_CFG);
chcfg &= ~S3C64XX_SPI_CH_TXCH_ON;
-
- if (dma_mode) {
chcfg &= ~S3C64XX_SPI_CH_RXCH_ON;
- } else {
- /* Always shift in data in FIFO, even if xfer is Tx only,
-* this helps setting PCKT_CNT value for generating clocks
-* as exactly needed.
-*/
- chcfg |= S3C64XX_SPI_CH_RXCH_ON;
- writel(((xfer->len * 8 / sdd->cur_bpw) & 0x)
- | S3C64XX_SPI_PACKET_CNT_EN,
- regs + S3C64XX_SPI_PACKET_CNT);
- }
if (xfer->tx_buf != NULL) {
sdd->state |= TXBUSY;
@@ -385,6 +376,10 @@ static void enable_datapath(struct s3c64xx_spi_driver_data
*sdd,
if (xfer->rx_buf != NULL) {
sdd->state |= RXBUSY;
+ chcfg |= S3C64XX_SPI_CH_RXCH_ON;
+ writel(((xfer->len * 8 / sdd->cur_bpw) & 0x)
+ | S3C64XX_SPI_PACKET_CNT_EN,
+ regs + S3C64XX_SPI_PACKET_CNT);
if (sdd->port_conf->high_speed && sdd->cur_speed >= 3000UL
&& !(sdd->cur_mode & SPI_CPHA))
@@ -392,10 +387,6 @@ static void enable_datapath(struct s3c64xx_spi_driver_data
*sdd,
if (dma_mode) {
modecfg |= S3C64XX_SPI_MODE_RXDMA_ON;
- chcfg |= S3C64XX_SPI_CH_RXCH_ON;
- writel(((xfer->len * 8 / sdd->cur_bpw) & 0x)
- | S3C64XX_SPI_PACKET_CNT_EN,
- regs + S3C64XX_SPI_PACKET_CNT);
prepare_dma(&sdd->rx_dma, xfer->len, xfer->rx_dma);
}
}
@@ -421,6 +412,9 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data
*sdd,
cs = spi->controller_data;
gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+
+ /* Start the signals */
+ writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
}
static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -445,12 +439,12 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data
*sdd,
} while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
}
- if (!val)
- return -EIO;
-
if (dma_mode) {
u32 status;
+ if (!val)
+ return -EIO;
+
/*
* DmaTx returns after simply writing data in the FIFO,
* w/o waiting for real transmission on the bus to finish.
@@ -480,16 +474,19 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data
*sdd,
switch (sdd->cur_bpw) {
case 32:
- ioread32_rep(regs + S3C64XX_SPI_RX_DATA,
- xfer->rx_buf, xfer->len / 4);
+ for (val = 0; val < (xfer->len / 4); val++)
+ *((u32 *)xfer->rx_buf + val) =
+ ioread32(regs + S3C64XX_SPI_RX_DATA);
break;
case 16:
- ioread16_rep(regs + S3C64XX_SPI_RX_DATA,
- xfer->rx_buf, xfer->len / 2);
+ for (val = 0; val < (xfer->len / 2); val++)
+ *((u16 *)xfer->rx_buf + val) =
+ ioread16(regs + S3C64XX_SPI_RX_DATA);
[PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init
The status of the interrupt is available in the status register,
so reading the clear pending register and writing back the same
value will not actually clear the pending interrupts. This patch
modifies the interrupt handler to read the status register and
clear the corresponding pending bit in the clear pending register.
Modified the hwInit function to clear all the pending interrupts.
Signed-off-by: Girish K S
---
drivers/spi/spi-s3c64xx.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index ad93231..b770f88 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -997,25 +997,30 @@ static irqreturn_t s3c64xx_spi_irq(int irq, void *data)
{
struct s3c64xx_spi_driver_data *sdd = data;
struct spi_master *spi = sdd->master;
- unsigned int val;
+ unsigned int val, clr = 0;
- val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
+ val = readl(sdd->regs + S3C64XX_SPI_STATUS);
- val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
- S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
- S3C64XX_SPI_PND_TX_OVERRUN_CLR |
- S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
-
- writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
-
- if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
+ if (val & S3C64XX_SPI_ST_RX_OVERRUN_ERR) {
+ clr = S3C64XX_SPI_PND_RX_OVERRUN_CLR;
dev_err(&spi->dev, "RX overrun\n");
- if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
+ }
+ if (val & S3C64XX_SPI_ST_RX_UNDERRUN_ERR) {
+ clr |= S3C64XX_SPI_PND_RX_UNDERRUN_CLR;
dev_err(&spi->dev, "RX underrun\n");
- if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
+ }
+ if (val & S3C64XX_SPI_ST_TX_OVERRUN_ERR) {
+ clr |= S3C64XX_SPI_PND_TX_OVERRUN_CLR;
dev_err(&spi->dev, "TX overrun\n");
- if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
+ }
+ if (val & S3C64XX_SPI_ST_TX_UNDERRUN_ERR) {
+ clr |= S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
dev_err(&spi->dev, "TX underrun\n");
+ }
+
+ /* Clear the pending irq by setting and then clearing it */
+ writel(clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
+ writel(clr & ~clr, sdd->regs + S3C64XX_SPI_PENDING_CLR);
return IRQ_HANDLED;
}
@@ -1039,9 +1044,13 @@ static void s3c64xx_spi_hwinit(struct
s3c64xx_spi_driver_data *sdd, int channel)
writel(0, regs + S3C64XX_SPI_MODE_CFG);
writel(0, regs + S3C64XX_SPI_PACKET_CNT);
- /* Clear any irq pending bits */
- writel(readl(regs + S3C64XX_SPI_PENDING_CLR),
- regs + S3C64XX_SPI_PENDING_CLR);
+ /* Clear any irq pending bits, should set and clear the bits */
+ val = S3C64XX_SPI_PND_RX_OVERRUN_CLR |
+ S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
+ S3C64XX_SPI_PND_TX_OVERRUN_CLR |
+ S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
+ writel(val, regs + S3C64XX_SPI_PENDING_CLR);
+ writel(val & ~val, regs + S3C64XX_SPI_PENDING_CLR);
writel(0, regs + S3C64XX_SPI_SWAP_CFG);
--
1.7.10.4
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 0/4] Add polling support for 64xx spi controller
[PATCH 1/4]: fixes the error handling in the interrupt handler [PATCH 2/4]: The existing driver support partial polling mode. This patch modifies the current driver to support only polling mode. [PATCH 3/4]: Adds quirk to support SoC's with dedicated i/o pins [PATCH 4/4]: Adds the support for exynos5440 SoC, this SoC has no support for dma transfer and consists of dedicated i/o pins. Girish K S (4): spi: s3c64xx: modified error interrupt handling and init spi: s3c64xx: added support for polling mode spi: s3c64xx: add gpio quirk for controller spi: s3c64xx: add support for exynos5440 spi drivers/spi/spi-s3c64xx.c | 157 - 1 file changed, 98 insertions(+), 59 deletions(-) -- 1.7.10.4 -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 3/4] spi: s3c64xx: add gpio quirk for controller
This patch adds support for spi controllers with
dedicated clk/miso/mosi/cs pins. It skips the gpio
parsing and initialization for controllers that
have dedicated pins.
Signed-off-by: Girish K S
---
drivers/spi/spi-s3c64xx.c | 39 +++
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 90770bd..f06bbee 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -36,6 +36,7 @@
#define MAX_SPI_PORTS 3
#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
+#define S3C64XX_SPI_QUIRK_GPIO (1 << 1)
/* Registers and bit-fields */
@@ -404,14 +405,16 @@ static inline void enable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
/* Deselect the last toggled device */
cs = sdd->tgl_spi->controller_data;
- gpio_set_value(cs->line,
- spi->mode & SPI_CS_HIGH ? 0 : 1);
+ if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO))
+ gpio_set_value(cs->line,
+ spi->mode & SPI_CS_HIGH ? 0 : 1);
}
sdd->tgl_spi = NULL;
}
cs = spi->controller_data;
- gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+ if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO))
+ gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
/* Start the signals */
writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -503,7 +506,8 @@ static inline void disable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi == spi)
sdd->tgl_spi = NULL;
- gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+ if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO))
+ gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
/* Quiese the signals */
writel(S3C64XX_SPI_SLAVE_SIG_INACT,
@@ -842,7 +846,10 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-ENOMEM);
}
- cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+ /* In case of dedicated cs pin skip the gpio initialization */
+ if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO))
+ cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+
if (!gpio_is_valid(cs->line)) {
dev_err(&spi->dev, "chip select gpio is not specified or "
"invalid\n");
@@ -883,7 +890,7 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
return -ENODEV;
}
- if (!spi_get_ctldata(spi)) {
+ if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO)) {
err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
dev_name(&spi->dev));
if (err) {
@@ -892,9 +899,11 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
cs->line, err);
goto err_gpio_req;
}
- spi_set_ctldata(spi, cs);
}
+ if (!spi_get_ctldata(spi))
+ spi_set_ctldata(spi, cs);
+
sci = sdd->cntrlr_info;
spin_lock_irqsave(&sdd->lock, flags);
@@ -979,8 +988,11 @@ err_gpio_req:
static void s3c64xx_spi_cleanup(struct spi_device *spi)
{
struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
+ struct s3c64xx_spi_driver_data *sdd;
+
+ sdd = spi_master_get_devdata(spi->master);
- if (cs) {
+ if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO) && cs) {
gpio_free(cs->line);
if (spi->dev.of_node)
kfree(cs);
@@ -1107,6 +1119,13 @@ static int s3c64xx_spi_parse_dt_gpio(struct
s3c64xx_spi_driver_data *sdd)
struct device *dev = &sdd->pdev->dev;
int idx, gpio, ret;
+ /*
+* If cs is not controlled by gpio, and
+* the SoC uses internal dedicated pins
+*/
+ if (sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO)
+ return 0;
+
/* find gpios for mosi, miso and clock lines */
for (idx = 0; idx < 3; idx++) {
gpio = of_get_gpio(dev->of_node, idx);
@@ -1133,6 +1152,10 @@ free_gpio:
static void s3c64xx_spi_dt_gpio_free(struct s3c64xx_spi_driver_data *sdd)
{
unsigned int idx;
+
+ if (sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO)
+ return;
+
for (idx = 0; idx < 3; idx++)
gpio_free(sdd->gpios[idx]);
}
--
1.7.10.4
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for f
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tuesday 05 February 2013, Tony Lindgren wrote: > * Felipe Balbi [130204 07:46]: > > > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). > > > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. > > How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? > That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM > using PIO while sorting out the DMA related issues. Sounds ok to me. Someone still needs to do the work to make the non-DMA variants of MUSB coexist in one kernel, but as we discussed erlier, that should be much simpler. Arnd -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/2] arm: mvebu: Add SPI flash on Armada 370 DB board
This patch add support for the SPI flash MX25l25635E which is present
on the Armada 370 DB board. This flash stores the bootloader and its
environment.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-370-db.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..d3ff947 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,16 @@
status = "disabled";
/* No CD or WP GPIOs */
};
+ spi0: spi@d0010600 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mx25l25635e";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <5000>;
+ };
+ };
};
};
--
1.7.9.5
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 1/2] arm: mvebu: Add SPI flash on Armada XP-DB board
This patch add support for the SPI flash M25P64 which is present on
the Armada XP DB board. This flash stores the bootloader and its
environment.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-xp-db.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..e5dfb4f 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = "okay";
/* No CD or WP GPIOs */
};
+
+ spi0: spi@d0010600 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p64";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <2000>;
+ };
+ };
};
};
--
1.7.9.5
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 0/2] Add SPI flash for Aramda 370 and XP dev board
Hi, Following the Ezequiel's patches this patch set add support for SPI data Flash for two other development board from Marvell. This pacthes depend on the SPI serie of Ezequiel [1], and also on the selection of CONFIG_MTD_M25P80=y in the config file. [1] http://thread.gmane.org/gmane.linux.kernel.spi.devel/12568 Gregory CLEMENT (2): arm: mvebu: Add SPI flash on Armada XP-DB board arm: mvebu: Add SPI flash on Armada 370 DB board arch/arm/boot/dts/armada-370-db.dts | 11 +++ arch/arm/boot/dts/armada-xp-db.dts | 12 2 files changed, 23 insertions(+) -- 1.7.9.5 -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
> Hi Ezequiel,
>
> On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
>> This patch adds an SPI master device node for Armada XP-GP board.
>> This master node is an SPI flash controller 'n25q128a13'.
>>
>> Since there is no 'partitions' node declared, one full sized
>> partition named as the device will be created.
>>
>> Cc: Gregory Clement
>> Cc: Thomas Petazzoni
>> Cc: Lior Amsalem
>> Signed-off-by: Ezequiel Garcia
>> ---
>> This patch depends on:
>>
>> 1. Gregory's patch for Armada XP GP board:
>> arm: mvebu: support for the new Armada XP development
>> board(DB-MV784MP-GP)
>>
>> 2. My previous patch for SPI on Armada 370/XP:
>> arm: mvebu: Add support for SPI controller in Armada 370/XP
>>
>> And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y
>>
>> arch/arm/boot/dts/armada-xp-gp.dts | 12
>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
>> b/arch/arm/boot/dts/armada-xp-gp.dts
>> index 3eea531..1c8afe2 100644
>> --- a/arch/arm/boot/dts/armada-xp-gp.dts
>> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
>> @@ -97,5 +97,17 @@
>> phy = <&phy3>;
>> phy-mode = "rgmii-id";
>> };
>> +
>> +spi0: spi@d0010600 {
>> +status = "okay";
>> +
>> +spi-flash@0 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "n25q128a13";
>> +reg = <0>; /* Chip select 0 */
>> +spi-max-frequency = <10800>;
I had a remark about it, according to the datasheet, 108MHz is the
maximum frequency for the all the instructions but the READ
instruction. For the READ the maximum frequency is 54MHz. So I wonder
if we shouldn't use 5400 here.
>> +};
>> +};
>> };
>> };
>>
>
> I applied, compiled and try this patch it worked well, at least
> for reading, I didn't try to write on the flash where my boolader
> is stored. So you can add my:
>
> Tested-by: Gregory Clement
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v2] spi/ath79: add shutdown handler
The SPI controller of the AR7xxx/AR9xxx SoCs
have a special mode which allows the SoC to
directly read data from SPI flash chips. In
this mode, the content of the SPI flash chip
can be accessed via a memory mapped region.
During early init time, the kernel expects
that the flash chip is accessible through
that memory region because it reads board
specific values (e.g. MAC address, WiFi
calibration data) from the flash on various
boards.
This is working if the kernel is loaded
directly by the bootloader because that
leaves the SPI controller in the special
mode. However it is not working in a kexec'd
kernel because the SPI driver does not restore
the special mode during shutdown.
The patch adds a shutdown handler to fix this
issue.
Signed-off-by: Gabor Juhos
---
Changes since v1:
- call ath79_spi_remote(pdev) directly from ath79_spi_shutdown()
---
drivers/spi/spi-ath79.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
index 842acd8..e504b76 100644
--- a/drivers/spi/spi-ath79.c
+++ b/drivers/spi/spi-ath79.c
@@ -308,9 +308,15 @@ static int ath79_spi_remove(struct platform_device *pdev)
return 0;
}
+static void ath79_spi_shutdown(struct platform_device *pdev)
+{
+ ath79_spi_remove(pdev);
+}
+
static struct platform_driver ath79_spi_driver = {
.probe = ath79_spi_probe,
.remove = ath79_spi_remove,
+ .shutdown = ath79_spi_shutdown,
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
--
1.7.10
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 6/6] spi/ath79: add shutdown handler
2013.02.05. 14:02 keltezéssel, Grant Likely írta:
>> -static int ath79_spi_remove(struct platform_device *pdev)
>> +static void __ath79_spi_remove(struct platform_device *pdev)
>> {
>> struct ath79_spi *sp = platform_get_drvdata(pdev);
>>
>> @@ -304,13 +304,23 @@ static int ath79_spi_remove(struct platform_device
>> *pdev)
>> iounmap(sp->base);
>> platform_set_drvdata(pdev, NULL);
>> spi_master_put(sp->bitbang.master);
>> +}
>>
>> +static int ath79_spi_remove(struct platform_device *pdev)
>> +{
>> +__ath79_spi_remove(pdev);
>> return 0;
>> }
>>
>> +static void ath79_spi_shutdown(struct platform_device *pdev)
>> +{
>> +__ath79_spi_remove(pdev);
>> +}
>
> Just call ath79_spi_remote(pdev) directly from ath79_spi_shutdown(). No
> need for the extra hook and __ version of the original function.
Ok, I will send a modified patch.
Thanks,
Gabor
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/6] spi/ath79: add delay between SCK changes
Hi Grant, > On Thu, 27 Dec 2012 10:42:24 +0100, Gabor Juhos wrote: >> The driver uses the "as fast as it can" approach >> to drive the SCK signal. However this does not >> work with certain low speed SPI chips (e.g. the >> PCF2123 RTC chip). >> >> The patch adds per-bit slowdowns in order to be >> able to use the driver with such chips as well. >> >> Signed-off-by: Gabor Juhos > > I've applied this, but please take a second look to make sure you're not > doing something unintended. The ndelay call will spin until it > completes. If the current context is interrupted or scheduled out then > it will still spin when it gets back. You may be wasting more time than > is necessary. It would be better to check the wall time over a loop > iteration. And if the delay required is large, then it should sleep. Thank for the review! Unfortunately, at the moment I don't have access to the board which uses that PCF2123 chip but I will try to improve the code. -Gabor -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On Tue, Feb 05, 2013 at 06:07:05PM +0100, Thomas Petazzoni wrote: > Dear Gregory CLEMENT, > > On Tue, 05 Feb 2013 17:20:02 +0100, Gregory CLEMENT wrote: > > > So that means we should enable the drivers for all the devices present > > on all the boards? > > Yes. For example my mvsdio patch set enables some Wifi driver that > corresponds to a particular SDIO Wifi device that is present in the > Mirabox. But not on other boards. > Okey, I'll add everything needed to access and test the SPI flash, including MTD_CHAR. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On 02/05/2013 01:29 PM, Linus Walleij wrote: > On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown > wrote: >> On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: >> >>> For IRQ mode, use the completion callback to push each cookie >>> to NAPI, and thus let the IRQ drive the traffic. >> >> The whole purpose of NAPI is to avoid taking interrupts for completion >> of transfers. Anything that generates interrupts when NAPI is in >> polling mode is defeating the point. > > So what I was trying to get across is that when you're in polling > mode you do not set DMA_PREP_INTERRUPT on your transfers, > just throw the obtained struct dma_async_tx_descriptor on some > list and then when polling use dma_async_is_tx_complete() > on the channel and the cookie inside the descriptor. > > I was trying to describe that you can move from > IRQ mode to polling mode and back again by selectively > choosing to set/not set the DMA_PREP_INTERRUPT flag. > This does not work. At prep/submit time, the network driver does not know if a particular packet buffer needs an interrupt or not. It queues up a whole bunch of receive buffers upfront. These buffers simply sit on the hardware queue/ring until the NIC receives traffic. The driver throttles the receive processing rate by dynamically switching between interrupt and poll behaviors on the completion side, not on the submission side. > If polling is all you want you never set it. > Another point here is that it is not simply a polling vs. interrupt problem. The system needs to dynamically switch between the two behaviors depending on offered load conditions. This dynamic switching is key to balancing latency (under low load) and throughput (at high rates). It cannot be one or the other, it must be both. Once again, I'm fairly sure that suitably reworking or extending the dma-engine interfaces will allow network DMAs to fit in nicely. However, I'd also appreciate inputs on the alternative approach of using virtio devices as an interface to packet oriented DMA hardware. From my perspective this offers the following advantages, some of which I've already mentioned in earlier postings: 1. The virtqueue interface is nice and clean, it fits very well with networking concepts such as NAPI. In comparison, the dma-engine API will need extensions and/or rework to fit network DMAs. 2. Advantages from leveraging the virtio infrastructure. For example, if a DMA pipe to a remote processor is exposed as a virtio device, something like rpmsg could very naturally fit on top of this without any other added glue. 3. Advantages from leveraging the driver model for binding dma clients to dma hardware, instead of resorting to name lookups and such. Thanks -- Cyril. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 6:14 PM, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote: >> So put them on a wait list? Surely you will have a list of pending >> cookies and pick from the front of the queue if there isn't a hole on >> queue position 0. > > Not quite. The key is the cookie system DMA engine employs to indicate > when a cookie is complete. > > Cookies between the "issued sequence" and "completed sequence" are defined > to be in progress, everything else is defined to be completed. > > This means that if "completed sequence" is 1, and "issued sequence" is 5, > then cookies with values 2, 3, 4, 5 are in progress. You can't mark > sequence 4 as being complete until 2 and 3 have completed. Yes that is true. DMA transfers on a certain channel are defined as progressing linearly per-cookie. I wonder if that is a problem in this case though (actually it seems the reverse, this helps in Cyril's case.) > If we need out-of-order completion, then that's a problem for the DMA > engine API, because you'd need to radically change the way "completion" > is marked. True. I wonder if this usecase is ever going to be applicable however. It could maybe be useful in some instances of memcpy() I could dream up, whereas for device transfers it seems unlikely to me. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown wrote: > On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > >> For IRQ mode, use the completion callback to push each cookie >> to NAPI, and thus let the IRQ drive the traffic. > > The whole purpose of NAPI is to avoid taking interrupts for completion > of transfers. Anything that generates interrupts when NAPI is in > polling mode is defeating the point. So what I was trying to get across is that when you're in polling mode you do not set DMA_PREP_INTERRUPT on your transfers, just throw the obtained struct dma_async_tx_descriptor on some list and then when polling use dma_async_is_tx_complete() on the channel and the cookie inside the descriptor. I was trying to describe that you can move from IRQ mode to polling mode and back again by selectively choosing to set/not set the DMA_PREP_INTERRUPT flag. If polling is all you want you never set it. Then there is the fact that the transfer needs to have been flagged complete and it is indeed something that needs to be set in some bytes somewhere. By something. But it doesn't have to be an interrupt from the DMA controller. In such cases we use dma_async_is_tx_complete() with channel and cookies as parameter. This will call down into the driver chan->device->device_tx_status() and there we can actually poll the hardware to see if the transfer happens to be complete, and if it is flag it complete. Which is likely what we want. No interrupts, only function calls as far as I can see. (I bet Russell will poke a hole in my reasoning, but it's worth a try.) Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
* Felipe Balbi [130204 07:46]: > > Current DMA abstraction is quite poor, for example there's no way to > compile support for multiple DMA engines. Code also makes certain, IMO > unnecessary, assumptions about the underlying DMA engine (abstraction is > poor, as said above but it we could follow MUSB's programming guide when > it comes to programming DMA transfers). > > Considering all of the above, it's far better to use DMA engine and get > rid of all the mess. How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM using PIO while sorting out the DMA related issues. Regards, Tony -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH V2 2/2] spi/bcm63xx: work around inability to keep CS up
On Tue, 5 Feb 2013 16:00:04 +0100, Jonas Gorski wrote: > On Tue, 05 Feb 2013 14:35:30 + > Grant Likely wrote: > > > On Sun, 3 Feb 2013 15:15:13 +0100, Jonas Gorski wrote: > > > This SPI controller does not support keeping CS asserted after sending > > > a transfer. > > > Since messages expected on this SPI controller are rather short, we can > > > work around it for normal use cases by sending all transfers at once in > > > a big full duplex stream. > > > > > > This means that we cannot change the speed between transfers if they > > > require CS to be kept asserted, but these would have been rejected > > > before anyway because of the inability of keeping CS asserted. > > > > > > Signed-off-by: Jonas Gorski > > > > Are you checking the state of transfer->cs_change when merging > > transfers? If cs_change is set, then the transfers cannot be merged. > > Yes, I do; I "flush" on each cs_change and after the last transfer: Okay, applied. Thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 2/2] spi: bitbang: convert to using core message queue
On Thu, 10 Jan 2013 13:04:37 +0100 (CET), Guennadi Liakhovetski wrote: > On Thu, 10 Jan 2013, Linus Walleij wrote: > > > On Wed, Jan 9, 2013 at 3:44 PM, Guennadi Liakhovetski > > wrote: > > > > > [ 79.968000] mmc0: new SD card on SPI > > > [ 79.976000] mmcblk0: mmc0: SU02G 1.84 GiB > > > [ 80.024000] mmcblk0: p1 > > > [ 80.132000] mmcblk0: error -38 sending status command, retrying > > > [ 80.136000] mmcblk0: error -38 sending status command, retrying > > > [ 80.14] mmcblk0: error -38 sending status command, aborting > > > [ 81.028000] mmc0: SPI card removed > > > [ 81.572000] mmc0: error -110 whilst initialising SD card > > > > The queue mechanism has not changed. > > > > This *could* be the card itself. So it doesn't appear before the patch? > > No. It could merely be a result of timing changes by using the core message queue. I'll leave the patch for now until someone can properly investigate. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: Trying to use spidev to send an spi message, result from spidev_test.c "Illegal argument" . (i.mx23, kernel 3.7)
On Sun, 30 Dec 2012 18:14:55 +0900, Juha Lumme wrote: > Hi, > > I am having issues communicating with a micro controller connected to > SPI bus, using spidev. > I would like to send messages to my MSP430 from user land, but so far no > luck. > > At least I know that my SPI bus should be ok, since in the same bus I > have a SPI flash chip that works. > In my DTS I have added my 2 SPI devices as such: It looks to me like the SPI master doesn't know how to drive the CS line for the second device. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: MIPS: lantiq: make use of spi_finalize_current_message
On Wed, 30 Jan 2013 21:33:30 +0100, John Crispin wrote: > Rather than calling m->complete() directly we choose the sane way and call > spi_finalize_current_message instead. > > Signed-off-by: Thomas Langer > Signed-off-by: John Crispin Applied, thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH RESEND] spi: spi-fsl-spi: Make spi-fsl-spi usable in cpu mode outside of FSL SOC environments and add a grlib variant normally running on sparc
On Wed, 30 Jan 2013 13:15:24 +0100, Andreas Larsson wrote:
> This makes the cpu mode of the driver available outside of an FSL SOC
> and even powerpc environment. This is accomplished by putting things
> regarding fsl specific code and to cpm specific code within ifdefs.
>
> Furthermore, this adds support for the mostly register-compatible
> SPICTRL core from the GRLIB VHDL IP core library normally running on
> sparc. A different entry in of_fsl_spi_match matches this core and
> indicates a different hardware type that is used to set up different
> function pointers and special cases. The fetching of irq is changed to
> work under sparc as well.
>
> The GRLIB core operates in cpu mode and from the driver's point of view
> the important differences are that the number of bits per word might be
> limited and that there might be native chipselects selected via the
> added slvsel register. These differences if present are indicated by an
> added capabilities register.
>
> Signed-off-by: Andreas Larsson
> ---
> [Resend to include more recipients]
>
> This patch relies upon parts of the "of, of_gpio, of_spi: Fix and
> improve of_parse_phandle_with_args, of_gpio_named_count and
> of_spi_register_master" patchset - https://lkml.org/lkml/2012/12/27/54
> (v2 at https://lkml.org/lkml/2013/1/29/308).
>
> The grlib type has been tested under sparc, but the fsl type has only
> been compile tested, so it would be great if someone with an fsl board
> could test this out.
>
> One could argue that it would be better to add the grlib variant as a
> mode flag in of_mpc8xxx_spi_probe instead of using a new type field, but
> that would require to add a flag for this core in
> include/linux/fsl_devices.h which does not feel right given that this
> core is not part of an fsl device.
>
> Maybe the different out/in_be32 vs iowrite/read32be in spi-fsl-lib.h is
> over the top, but I'm not sure if there might be subtle differences
> between those on powerpc and I don't have any fsl hardware to try things
> out on.
Changing to ioread/write globally should be fine. I would change it and get
someone with an fsl board to try it out. That will reduce the diffstat a
bit.
As is, this is quite an invasive patch, so I'm not going to be
comfortable merging it without at least one 3rd party tester. (Breaking
things up into discrete patches will make me less nervous and possible
to merge parts while still revising others.
Comments below...
> diff --git a/drivers/spi/spi-fsl-lib.c b/drivers/spi/spi-fsl-lib.c
> index 8ade675..e3ea564 100644
> --- a/drivers/spi/spi-fsl-lib.c
> +++ b/drivers/spi/spi-fsl-lib.c
> @@ -23,7 +23,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_FSL_SOC
> #include
> +#endif
>
> #include "spi-fsl-lib.h"
>
> @@ -208,6 +210,7 @@ int of_mpc8xxx_spi_probe(struct platform_device *ofdev)
> /* Allocate bus num dynamically. */
> pdata->bus_num = -1;
>
> +#ifdef CONFIG_FSL_SOC
> /* SPI controller is either clocked from QE or SoC clock. */
> pdata->sysclk = get_brgfreq();
> if (pdata->sysclk == -1) {
> @@ -217,16 +220,23 @@ int of_mpc8xxx_spi_probe(struct platform_device *ofdev)
> goto err;
> }
> }
> +#else
> + ret = of_property_read_u32(np, "clock-frequency", &pdata->sysclk);
> + if (ret)
> + goto err;
> +#endif
>
> prop = of_get_property(np, "mode", NULL);
> if (prop && !strcmp(prop, "cpu-qe"))
> pdata->flags = SPI_QE_CPU_MODE;
> +#ifdef CONFIG_FSL_SOC
> else if (prop && !strcmp(prop, "qe"))
> pdata->flags = SPI_CPM_MODE | SPI_QE;
> else if (of_device_is_compatible(np, "fsl,cpm2-spi"))
> pdata->flags = SPI_CPM_MODE | SPI_CPM2;
> else if (of_device_is_compatible(np, "fsl,cpm1-spi"))
> pdata->flags = SPI_CPM_MODE | SPI_CPM1;
> +#endif
The ifdefs are ugly and these lines won't affect sparc. Just leave them
in.
>
> return 0;
>
> diff --git a/drivers/spi/spi-fsl-lib.h b/drivers/spi/spi-fsl-lib.h
> index cbe881b..f66f736 100644
> --- a/drivers/spi/spi-fsl-lib.h
> +++ b/drivers/spi/spi-fsl-lib.h
> @@ -34,8 +34,10 @@ struct mpc8xxx_spi {
>
> int subblock;
> struct spi_pram __iomem *pram;
> +#ifdef CONFIG_FSL_SOC
> struct cpm_buf_desc __iomem *tx_bd;
> struct cpm_buf_desc __iomem *rx_bd;
> +#endif
>
> struct spi_transfer *xfer_in_progress;
>
> @@ -67,6 +69,15 @@ struct mpc8xxx_spi {
>
> unsigned int flags;
>
> +#ifdef CONFIG_SPI_FSL_SPI
> + int type;
> + int native_chipselects;
> + u8 max_bits_per_word;
> +
> + void (*set_shifts)(u32 *rx_shift, u32 *tx_shift,
> +int bits_per_word, int msb_first);
> +#endif
> +
> struct workqueue_struct *workqueue;
> struct work_struct work;
>
> @@ -87,12 +98,20 @@ struct spi_mpc8xxx_cs {
>
> static inline void mpc8xxx_spi_write_reg(__be32 __iomem *reg, u32 val)
> {
> +#ifdef CONFIG_FS
Re: [PATCH V2 0/2] spi/bcm63xx: fix multi transfer messages
On Tue, 5 Feb 2013 15:04:41 +, Mark Brown wrote: > On Tue, Feb 05, 2013 at 02:30:40PM +, Grant Likely wrote: > > > Another option is to allow longer transfers if a GPIO is used for the CS > > line. A lot of SPI controllers need to do that. > > > That isn't a critique of this patch because it is essentially a bug fix, > > but rather a way you can work around the limitation. > > Yeah, I did suggest that to them originally but apparently the hardware > is sufficient fail that the pins can't be put into GPIO mode for the > affected boards. Hahaha. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: davinci: use request_threaded_irq() to fix deadlock
On Wed, 2 Jan 2013 10:19:08 -0500, Murali Karicheri wrote: > On 12/22/2012 05:08 AM, Grant Likely wrote: > > On Fri, 21 Dec 2012 15:13:26 -0500, Murali Karicheri > > wrote: > >> With RT pre-empt patch applied to Linux kernel, the irq handler will be > >> force converted to an irq thread. spi driver can get back to back messages > >> from the slave device. In such cases, IRQ thread doesn't get a chance to > >> run to read the slave data. Hence the irq handler must be run in hard irq > >> context to read/write data from slave device. Otherwise, the kernel goes > >> into a deadlock. This patch fixes this issue when PREEMPT_RT_FULL is > >> enabled in the kernel. A dummy thread function is provided to satisfy the > >> request_threaded_irq() API. Passing a NULL for function also causes the > >> irq handler to be executed in the thread context. > >> > >> Signed-off-by: Murali Karicheri > > Thomas, would you mind taking a look at this for me. My gut feel is that > > this is the wrong way to solve the problem that Murali is having and > > that it really just hacks something that works. > Grant, > > Thanks for reviewing this. As per the RT patch, all of the IRQ handlers > will be converted to thread by brute force. This breaks the SPI driver > since the data is overwritten with back to back irq as thread is not > getting a chance to read the word before next irq happens. What my > patch does is to keep the functionality as before by using a new irq > API. So though this is not the best solution, this solves the problem > and give an opportunity for improvement by splitting this into two part > to handle the irq. But I am not convinced if this is really needed. Okay. Applied, thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: Fixing eSPI controller driver: some queries
On Fri, 18 Jan 2013 10:03:28 +0100, Thomas De Schampheleire wrote: > Hi, > > The Freescale eSPI controller driver is broken in several ways. I already > attempted to fix this with a patch many months back. The patch works for > me, but never got feedback from the original author. > (see https://patchwork.kernel.org/patch/988802/) > > The same problems are still present on the current 3.x version of the > driver. I will now re-investigate the problem, and submit a revised patch > later. > > I have some queries though: > - When reading from memory devices, the first bytes received may not yet be > the real contents of memory, but rather to-be-ignored bytes caused by the > full-duplex nature of the transaction while sending the command and address > bytes. > Am I correct in understanding that these to-be-ignored bytes are to be > transparently passed through to the requester of the transaction (i.e. a > protocol driver or a userspace application through spidev) and that it's > the requestor's responsability to know that these bytes are to be ignored? Yes > > - While investigating the various problems of the driver, I am adding print > statements throughout the code, displaying certain variables and buffer > contents. What should I do with these when the problems are fixed? Remove > all such statements, or rather, use a mechanism like dev_dbg (or similar) > and thus keep them in the code? What is your preference? It is common to use dev_dbg(). They are turned off by removing #define DEBUG from the top of the file. As long as they don't impair readability of the code I would keep them in. > - One of the aspects that seems to be broken in the driver is accesses that > do not have either 8-bits-per-word or 16-bits-per-word, e.g. 7 bpw or 12 > bpw. The hardware defaults to sending least-significant-bits first, and the > setting to change this is only allowed for 8 or 16 bpw: > > (datasheet) > Reverse data mode. Determines the receive and transmit character bit order. > 0 lsb of the character sent and received first > 1 msb of the character sent and received first-for 8/16 bits data character > only > --- > > However, the driver sets this bit (CSMODE_REV) by default, except when the > mode SPI_LSB_FIRST is explicitly set. This means that a protocol driver > that requests a 12bpw transaction, will inadvertently cause an illegal mode > setting in the hardware. It doesn't and shouldn't know of this hardware > restriction. Is this analysis correct? Correct. The master driver needs to work around limitations of the hardware, or reject them as unsupported. > What is the correct way of handling this? Clear the bit in case of a sub-8 > or sub-16 bpw transaction, and do the bit swapping in software if > SPI_LSB_FIRST is not explicitly set? Probably > Or force SPI_LSB_FIRST in these cases, leaving the bit swapping to the > protocol driver? No. it should be abstracted > Or disable support for sub-8 and sub-16 bpw transactions? Only if the first option isn't feasable. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] SPI: MIPS: lantiq: set SPI_MASTER_HALF_DUPLEX flag
On Wed, 30 Jan 2013 21:33:31 +0100, John Crispin wrote: > Due to hardware limitations of the spi/flash frontend of the EBU we need to > set > the SPI_MASTER_HALF_DUPLEX flag. > > Signed-off-by: Thomas Langer > Signed-off-by: John Crispin Applied, thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On Tue, Feb 05, 2013 at 06:07:05PM +0100, Thomas Petazzoni wrote: > Of course, it doesn't make sense to have drivers for pluggable devices > like PCIe devices that are not soldered, USB devices and things like > that. But for all the rest, I would say it should be in the defconfig. hmmm, so for the new devboard we should set CONFIG_RAM=n? ;-) thx, Jason. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote: > On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote: > > On 02/04/2013 04:11 PM, Linus Walleij wrote: > > >> Cyril, just stack up the cookies and take a sweep over them to see > >> which ones are baked when the NAPI poll comes in -> problem > >> solved. > > > > You're assuming that cookies complete in order. That is not necessarily > > true. > > So put them on a wait list? Surely you will have a list of pending > cookies and pick from the front of the queue if there isn't a hole on > queue position 0. Not quite. The key is the cookie system DMA engine employs to indicate when a cookie is complete. Cookies between the "issued sequence" and "completed sequence" are defined to be in progress, everything else is defined to be completed. This means that if "completed sequence" is 1, and "issued sequence" is 5, then cookies with values 2, 3, 4, 5 are in progress. You can't mark sequence 4 as being complete until 2 and 3 have completed. If we need out-of-order completion, then that's a problem for the DMA engine API, because you'd need to radically change the way "completion" is marked. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote: > On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > > > For IRQ mode, use the completion callback to push each cookie > > to NAPI, and thus let the IRQ drive the traffic. > > The whole purpose of NAPI is to avoid taking interrupts for completion > of transfers. Anything that generates interrupts when NAPI is in > polling mode is defeating the point. Yes, but you're missing one very important point. If your DMA engine is decoupled from the network device, and the DMA engine relies upon interrupts to queue further transfers to move data into RAM, then you have two options: 1. Receive these interrupts so you can update the DMA engine for further data transfer. 2. Don't receive these interrupts, and cause the network device to error out with a FIFO overrun because its DMA requests have not been serviced. (which may raise an interrupt.) -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
Dear Gregory CLEMENT, On Tue, 05 Feb 2013 17:20:02 +0100, Gregory CLEMENT wrote: > So that means we should enable the drivers for all the devices present > on all the boards? Yes. For example my mvsdio patch set enables some Wifi driver that corresponds to a particular SDIO Wifi device that is present in the Mirabox. But not on other boards. Of course, it doesn't make sense to have drivers for pluggable devices like PCIe devices that are not soldered, USB devices and things like that. But for all the rest, I would say it should be in the defconfig. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
> This patch adds an SPI master device node for Armada XP-GP board.
> This master node is an SPI flash controller 'n25q128a13'.
>
> Since there is no 'partitions' node declared, one full sized
> partition named as the device will be created.
>
> Cc: Gregory Clement
> Cc: Thomas Petazzoni
> Cc: Lior Amsalem
> Signed-off-by: Ezequiel Garcia
> ---
> This patch depends on:
>
> 1. Gregory's patch for Armada XP GP board:
> arm: mvebu: support for the new Armada XP development
> board(DB-MV784MP-GP)
>
> 2. My previous patch for SPI on Armada 370/XP:
> arm: mvebu: Add support for SPI controller in Armada 370/XP
>
> And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y
>
> arch/arm/boot/dts/armada-xp-gp.dts | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
> b/arch/arm/boot/dts/armada-xp-gp.dts
> index 3eea531..1c8afe2 100644
> --- a/arch/arm/boot/dts/armada-xp-gp.dts
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@ -97,5 +97,17 @@
> phy = <&phy3>;
> phy-mode = "rgmii-id";
> };
> +
> + spi0: spi@d0010600 {
> + status = "okay";
> +
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "n25q128a13";
> + reg = <0>; /* Chip select 0 */
> + spi-max-frequency = <10800>;
> + };
> + };
> };
> };
>
I applied, compiled and try this patch it worked well, at least
for reading, I didn't try to write on the flash where my boolader
is stored. So you can add my:
Tested-by: Gregory Clement
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On Tue, Feb 05, 2013 at 05:17:01PM +0100, Thomas Petazzoni wrote: > Dear Jason Cooper, > > On Tue, 5 Feb 2013 10:31:35 -0500, Jason Cooper wrote: > > > One thing we've been doing a lot of with mvebu is using it for > > build-testing. For that use case, since the bootloader is there, I'd > > recommend setting it. This will reduce the likelyhood of nasty build > > breakages futher down the line as we'll catch them before pushing to > > arm-soc. > > To me, the defconfig should enable all the options needed for the > drivers of on-board devices. So we should enable the driver for this > SPI flash in the mvebu_defconfig. I agree. thx, Jason. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 11:30 PM, Cyril Chemparathy wrote: > NAPI needs to switch between polled and interrupt driven modes of operation. > Further, in a given poll, it needs to be able to limit the amount of traffic > processed to a specified budget. I don't think any of this is a problem. Polling, just scan cookies. Disable or ignore the callbacks. For IRQ mode, use the completion callback to push each cookie to NAPI, and thus let the IRQ drive the traffic. >> The thing you're looking for sounds more like an adapter on top >> of dmaengine, which can surely be constructed, some >> drivers/dma/dmaengine-napi.c or whatever. > > I'm not debating the possibility of duct-taping a network driver on top of > the dma-engine interface. That is very much doable, and we have done this > already. So it seems I have a different opinion on elegance. I think it can be a nice little adapter, and you're talking about duct-tape, like it's something ugly and crude. So let's get to the bottom of that. > Starting with a stock dma-engine driver, our first approach was to use > dmaengine_pause() and dmaengine_resume() in the network driver to throttle > completion callbacks per NAPI's needs. Why? Do you really need to limit this in the middle of transfers? I'm half-guessing that one transfer is typically something like one packet. Pausing and starting would be something you would use in case you had a circular buffer with an eternal ongoing transfer, and you wanted to slow that down. > Having learned our lessons from the first attempt, the second step was to > add a separate notification callback from the dma-engine layer - a > notification independent of any particular descriptor. With this callback > in place, we got rid of some of the state machine crap in the network > driver. > > The third step was to add a dmaengine_poll() call instead of constantly > bouncing a channel between paused and running states. This further cleaned > up some of the network driver code, but now the dma-engine driver looks like > crap if it needs to support both the traditional and new (i.e. notify + > poll) modes. This is where we are at today. I don't see why you have to modify dmaengine to do poll. It should be trivial as discussed to just keep track of the cookies, scan over them and poll out the completed work. Then to mitigate the load I guess you just do not issue too many dma transfers? Can you not regulate the workload by adjusting the number of transfer cookies you issue in parallel, and if they're not issued in parallel but adjacent, can you not just issue them so often? Or are you polling out half transfers or something, so that the granularity of one transfer/cookie would be enough? Maybe I'm not getting the picture here? Can you describe how the network stream is chopped into transfers in this hardware, I think that could ease our understanding? Especially I guess we need to know if the hardware is providing useful chunks like one packet or if it's just one eternal stream of bits that you then have to demux and put into skbufs or something. > Even with the addition of these extensions, the interaction between the > network driver and the dma-engine driver is clumsy and involves multiple > back and forth calls per packet. This is not elegant, and certainly not > efficient. In comparison, the virtqueue interface is a natural fit with the > network driver, and is free of the aforementioned problems. Yes the described approach and hacking around in dmaengine to do the polling seems ugly. But just a queue of cookies does not seem so ugly, rather the opposite. > [Russell writes] >> So yes, the DMA engine API supports it. Whether the _implementations_ >> themselves do is very much hit and miss (and in reality is much more >> miss than hit.) > > Don't these assume that the driver can determine the need for an interrupt > upfront at prep/submit time? AFAICT, this assumption doesn't hold true > with NAPI. Yes it does. You can however stop an ongoing transfer (by referring to the cookie), pick out the bytes transferred so far and trigger a new transfer using/not using an IRQ if you want. This is an abstracted way of doing the same brutal buffer slaying that I hear NAPI is doing to some network drivers. For example see the RX path of this driver: drivers/tty/serial/amba-pl011.c There is DMA for it, but we may stop the DMA transfer on an IRQ, take the partial buffer out and feed it to the TTY. Could just as well be a network packet. Sometimes it is, if there is a modem on the other end. RX DMA is triggered in pl011_dma_rx_trigger_dma(), then either pl011_dma_rx_callback() gets called if the DMA transfer completes, or we get an IRQ (like a timeout) and endup in pl011_dma_rx_irq(), where the transfer is stopped, buffer emtied and then we can decide what to do next. This could just as well have been some API calling in and saying "give me your buffer NOW". I think we need to look at an NAPI driver that does this
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On 02/05/2013 05:17 PM, Thomas Petazzoni wrote: > Dear Jason Cooper, > > On Tue, 5 Feb 2013 10:31:35 -0500, Jason Cooper wrote: > >> One thing we've been doing a lot of with mvebu is using it for >> build-testing. For that use case, since the bootloader is there, I'd >> recommend setting it. This will reduce the likelyhood of nasty build >> breakages futher down the line as we'll catch them before pushing to >> arm-soc. > > To me, the defconfig should enable all the options needed for the > drivers of on-board devices. So we should enable the driver for this > SPI flash in the mvebu_defconfig. > So that means we should enable the drivers for all the devices present on all the boards? > Best regards, > > Thomas > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
Dear Jason Cooper, On Tue, 5 Feb 2013 10:31:35 -0500, Jason Cooper wrote: > One thing we've been doing a lot of with mvebu is using it for > build-testing. For that use case, since the bootloader is there, I'd > recommend setting it. This will reduce the likelyhood of nasty build > breakages futher down the line as we'll catch them before pushing to > arm-soc. To me, the defconfig should enable all the options needed for the drivers of on-board devices. So we should enable the driver for this SPI flash in the mvebu_defconfig. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On 02/05/2013 07:41 AM, Russell King - ARM Linux wrote: > On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote: >> You're assuming that cookies complete in order. That is not necessarily >> true. > > Under what circumstances is that not true? > Notably when hardware can prioritize certain classes of traffic over others, for instance with data center bridging mechanisms. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] ARM: mvebu: Update defconfig to select SPI support
Hi Ezequiel, On 02/04/2013 05:38 PM, Ezequiel Garcia wrote: > Cc: Gregory Clement > Cc: Thomas Petazzoni > Cc: Lior Amsalem > Signed-off-by: Ezequiel Garcia > --- > arch/arm/configs/mvebu_defconfig |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/configs/mvebu_defconfig > b/arch/arm/configs/mvebu_defconfig > index 4e6f0ce..e243451 100644 > --- a/arch/arm/configs/mvebu_defconfig > +++ b/arch/arm/configs/mvebu_defconfig > @@ -40,6 +40,8 @@ CONFIG_MWIFIEX_SDIO=y > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_I2C=y > +CONFIG_SPI=y > +CONFIG_SPI_ORION=y > CONFIG_I2C_MV64XXX=y > CONFIG_SERIAL_8250_DW=y > CONFIG_GPIOLIB=y > For this patch you can add my Acked-by: Gregory Clement Regards, -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On 02/05/2013 07:38 AM, Russell King - ARM Linux wrote: > On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote: >> On Monday 04 February 2013, Linus Walleij wrote: >>> So I think the above concerns are moot. The callback we can >>> set on cookies is entirely optional, and it's even implemented by >>> each DMA engine, and some may not even support it but require >>> polling, and then it won't even be implemented by the driver. >> >> Just to ensure that everybody is talking about the same thing here: >> Is it just the callback that is optional, or also the interrupt >> coming from the hardware? > > If everyone implements stuff correctly, both. The callback most certainly > is optional as things stand. The interrupt - that depends on the DMA > engine. > > Some DMA engines you can't avoid it because you need to reprogram the > hardware with the next+1 transfer upon completion of an existing transfer. > Others may allow you to chain transfers in hardware. That's all up to > how the DMA engine driver is implemented and how the hardware behaves. > > Now, there's another problem here: that is, people abuse the API. People > don't pass DMA_CTRL_ACK | DMA_PREP_INTERRUPT into their operations by > default. People like typing '0'. > > The intention of the "DMA_PREP_INTERRUPT" is significant here: it means > "ask the hardware to send an interrupt upon completion of this transfer". > > Because soo many people like to type '0' instead in their DMA engine > clients, it means that this flag is utterly useless today - you have to > ignore it. So there's _no_ way for client drivers to actually tell the > a DMA engine driver which _doesn't_ need to signal interrupts at the end > of every transfer not to do so. > > So yes, the DMA engine API supports it. Whether the _implementations_ > themselves do is very much hit and miss (and in reality is much more > miss than hit.) > Don't these assume that the driver can determine the need for an interrupt upfront at prep/submit time? AFAICT, this assumption doesn't hold true with NAPI. Thanks -- Cyril. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On Tue, Feb 05, 2013 at 11:27:21AM -0300, Ezequiel Garcia wrote: > On Tue, Feb 05, 2013 at 07:48:33AM -0500, Jason Cooper wrote: > > Morning-ish Andrew, > > > > On Tue, Feb 05, 2013 at 01:38:27PM +0100, Andrew Lunn wrote: > > > > And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y > > > > > > Maybe it makes sense to provide a patch to mvebu_defconfig to add > > > CONFIG_MTD_M25P80=y ? > > > > I thought this as well, then reconsidered when he said there was nothing > > on it. So it's not really needed to boot. I don't have a strong > > opinion on it though, so =y, =m, or =n. > > > > Well, the SPI flash may not be empty, if that's what you meant. > For instnace, my Armada XP GP board has the bootloader on that SPI, > and boots from there. After booting, the SPI flash is no longer needed. Is the bootloader environment on there? Is there room for the dtb once u-boot is upgraded to support fdt? > IMHO, I don't think we should include the option CONFIG_MTD_M25P80 > as it is just a particular SPI master device present in a particular board. > > On the other hand, I don't have a strong opinion on this. > I've always wondered the *true* meaning of defconfigs, > so feel free to enligthen me :) Hmm, a quick look through Documentation/* didn't produce anything authoritative. There's Documentation/sh/new-machine.txt which says " Now all that's left to do is providing a defconfig for your new board. This way, other people who end up with this board can simply use this config for reference instead of trying to guess what settings are supposed to be used on it. " One thing we've been doing a lot of with mvebu is using it for build-testing. For that use case, since the bootloader is there, I'd recommend setting it. This will reduce the likelyhood of nasty build breakages futher down the line as we'll catch them before pushing to arm-soc. thx, Jason. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote: > On 02/04/2013 04:11 PM, Linus Walleij wrote: >> Cyril, just stack up the cookies and take a sweep over them to see >> which ones are baked when the NAPI poll comes in -> problem >> solved. > > You're assuming that cookies complete in order. That is not necessarily > true. So put them on a wait list? Surely you will have a list of pending cookies and pick from the front of the queue if there isn't a hole on queue position 0. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH V2 2/2] spi/bcm63xx: work around inability to keep CS up
On Tue, 05 Feb 2013 14:35:30 +
Grant Likely wrote:
> On Sun, 3 Feb 2013 15:15:13 +0100, Jonas Gorski wrote:
> > This SPI controller does not support keeping CS asserted after sending
> > a transfer.
> > Since messages expected on this SPI controller are rather short, we can
> > work around it for normal use cases by sending all transfers at once in
> > a big full duplex stream.
> >
> > This means that we cannot change the speed between transfers if they
> > require CS to be kept asserted, but these would have been rejected
> > before anyway because of the inability of keeping CS asserted.
> >
> > Signed-off-by: Jonas Gorski
>
> Are you checking the state of transfer->cs_change when merging
> transfers? If cs_change is set, then the transfers cannot be merged.
Yes, I do; I "flush" on each cs_change and after the last transfer:
> > + if (t->cs_change ||
> > + list_is_last(&t->transfer_list, &m->transfers)) {
> > + /* configure adapter for a new transfer */
> > + bcm63xx_spi_setup_transfer(spi, first);
> >
> > - /* send the data */
> > - status = bcm63xx_txrx_bufs(spi, t);
> > - if (status)
> > - goto exit;
> > + /* send the data */
> > + status = bcm63xx_txrx_bufs(spi, first, n_transfers);
> > + if (status)
> > + goto exit;
> > +
> > + m->actual_length += total_len;
> >
> > - m->actual_length += t->len;
> > + first = NULL;
> > + n_transfers = 0;
> > + total_len = 0;
> > + can_use_prepend = false;
> > + }
> > }
> > exit:
> > m->status = status;
> > --
> > 1.7.10.4
> >
>
> --
> Grant Likely, B.Sc, P.Eng.
> Secret Lab Technologies, Ltd.
P.S: Sorry Grant for receiving this double - I can't email.
--
Jonas Gorski
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH V2] spi: Remove erroneous __init, __exit and __exit_p() references in drivers
Some of the spi driver module remove hooks were annotated with __exit
and referenced with __exit_p(). Presumably these were supposed to be
__devinit, __devexit and __devexit_p() since __init/__exit for a
probe/remove hook has never been correct. They also got missed during
the big __devinit/__devexit purge since they didn't match the pattern.
Remove then now to be rid of it.
v2: purge __init also
Reported-by: Arnd Bergmann
[Arnd set a patch cleaning up one, and then I found more]
Signed-off-by: Grant Likely
---
drivers/spi/spi-atmel.c |2 +-
drivers/spi/spi-au1550.c |8
drivers/spi/spi-bfin5xx.c|2 +-
drivers/spi/spi-omap-100k.c |6 +++---
drivers/spi/spi-omap-uwire.c |6 +++---
drivers/spi/spi-orion.c |8
drivers/spi/spi-ppc4xx.c |6 +++---
drivers/spi/spi-s3c64xx.c|2 +-
drivers/spi/spi-txx9.c |6 +++---
9 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..656d137 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
.suspend= atmel_spi_suspend,
.resume = atmel_spi_resume,
.probe = atmel_spi_probe,
- .remove = __exit_p(atmel_spi_remove),
+ .remove = atmel_spi_remove,
};
module_platform_driver(atmel_spi_driver);
diff --git a/drivers/spi/spi-au1550.c b/drivers/spi/spi-au1550.c
index 4de66d1c..44dd34b 100644
--- a/drivers/spi/spi-au1550.c
+++ b/drivers/spi/spi-au1550.c
@@ -717,7 +717,7 @@ static void au1550_spi_bits_handlers_set(struct au1550_spi
*hw, int bpw)
}
}
-static void __init au1550_spi_setup_psc_as_spi(struct au1550_spi *hw)
+static void au1550_spi_setup_psc_as_spi(struct au1550_spi *hw)
{
u32 stat, cfg;
@@ -766,7 +766,7 @@ static void __init au1550_spi_setup_psc_as_spi(struct
au1550_spi *hw)
}
-static int __init au1550_spi_probe(struct platform_device *pdev)
+static int au1550_spi_probe(struct platform_device *pdev)
{
struct au1550_spi *hw;
struct spi_master *master;
@@ -968,7 +968,7 @@ err_nomem:
return err;
}
-static int __exit au1550_spi_remove(struct platform_device *pdev)
+static int au1550_spi_remove(struct platform_device *pdev)
{
struct au1550_spi *hw = platform_get_drvdata(pdev);
@@ -997,7 +997,7 @@ static int __exit au1550_spi_remove(struct platform_device
*pdev)
MODULE_ALIAS("platform:au1550-spi");
static struct platform_driver au1550_spi_drv = {
- .remove = __exit_p(au1550_spi_remove),
+ .remove = au1550_spi_remove,
.driver = {
.name = "au1550-spi",
.owner = THIS_MODULE,
diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c
index 7d7c991..317f564 100644
--- a/drivers/spi/spi-bfin5xx.c
+++ b/drivers/spi/spi-bfin5xx.c
@@ -1273,7 +1273,7 @@ static int bfin_spi_destroy_queue(struct
bfin_spi_master_data *drv_data)
return 0;
}
-static int __init bfin_spi_probe(struct platform_device *pdev)
+static int bfin_spi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct bfin5xx_spi_master *platform_info;
diff --git a/drivers/spi/spi-omap-100k.c b/drivers/spi/spi-omap-100k.c
index 3aef7fa..78d29a1 100644
--- a/drivers/spi/spi-omap-100k.c
+++ b/drivers/spi/spi-omap-100k.c
@@ -481,7 +481,7 @@ static int omap1_spi100k_transfer(struct spi_device *spi,
struct spi_message *m)
return 0;
}
-static int __init omap1_spi100k_reset(struct omap1_spi100k *spi100k)
+static int omap1_spi100k_reset(struct omap1_spi100k *spi100k)
{
return 0;
}
@@ -560,7 +560,7 @@ err1:
return status;
}
-static int __exit omap1_spi100k_remove(struct platform_device *pdev)
+static int omap1_spi100k_remove(struct platform_device *pdev)
{
struct spi_master *master;
struct omap1_spi100k*spi100k;
@@ -604,7 +604,7 @@ static struct platform_driver omap1_spi100k_driver = {
.name = "omap1_spi100k",
.owner = THIS_MODULE,
},
- .remove = __exit_p(omap1_spi100k_remove),
+ .remove = omap1_spi100k_remove,
};
diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index 0a94d9d..102b233 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -476,7 +476,7 @@ static void uwire_off(struct uwire_spi *uwire)
spi_master_put(uwire->bitbang.master);
}
-static int __init uwire_probe(struct platform_device *pdev)
+static int uwire_probe(struct platform_device *pdev)
{
struct spi_master *master;
struct uwire_spi*uwire;
@@ -536,7 +536,7 @@ static int __init uwire_probe(struct platform_device *pdev)
return status;
}
-static int __exit uwire_remove(struct platform_device *pdev)
+static int uwire_remove(st
Re: [PATCH] spi: orion: Use module_platform_driver()
On Mon, 4 Feb 2013 09:26:26 -0300, Ezequiel Garcia
wrote:
> This patch reduces and simplifies initalization code by
> using module_platform_driver().
> With this change it's necessary to remove the __init annotation
> to avoid section mismatch warnings.
>
> Signed-off-by: Ezequiel Garcia
Applied, thanks.
g.
> ---
> drivers/spi/spi-orion.c | 15 +++
> 1 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
> index b7e7182..d8cbf20 100644
> --- a/drivers/spi/spi-orion.c
> +++ b/drivers/spi/spi-orion.c
> @@ -396,7 +396,7 @@ static int orion_spi_setup(struct spi_device *spi)
> return 0;
> }
>
> -static int __init orion_spi_probe(struct platform_device *pdev)
> +static int orion_spi_probe(struct platform_device *pdev)
> {
> struct spi_master *master;
> struct orion_spi *spi;
> @@ -513,20 +513,11 @@ static struct platform_driver orion_spi_driver = {
> .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(orion_spi_of_match_table),
> },
> + .probe = orion_spi_probe,
> .remove = __exit_p(orion_spi_remove),
> };
>
> -static int __init orion_spi_init(void)
> -{
> - return platform_driver_probe(&orion_spi_driver, orion_spi_probe);
> -}
> -module_init(orion_spi_init);
> -
> -static void __exit orion_spi_exit(void)
> -{
> - platform_driver_unregister(&orion_spi_driver);
> -}
> -module_exit(orion_spi_exit);
> +module_platform_driver(orion_spi_driver);
>
> MODULE_DESCRIPTION("Orion SPI driver");
> MODULE_AUTHOR("Shadi Ammouri ");
> --
> 1.7.8.6
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH V2 2/2] spi/bcm63xx: work around inability to keep CS up
On Sun, 3 Feb 2013 15:15:13 +0100, Jonas Gorski wrote:
> This SPI controller does not support keeping CS asserted after sending
> a transfer.
> Since messages expected on this SPI controller are rather short, we can
> work around it for normal use cases by sending all transfers at once in
> a big full duplex stream.
>
> This means that we cannot change the speed between transfers if they
> require CS to be kept asserted, but these would have been rejected
> before anyway because of the inability of keeping CS asserted.
>
> Signed-off-by: Jonas Gorski
Are you checking the state of transfer->cs_change when merging
transfers? If cs_change is set, then the transfers cannot be merged.
g.
> ---
> V1 -> V2:
> * split out rejection logic into separate patch
> * fixed return type of bcm63xx_txrx_bufs()
> * slightly reworked bcm63xx_txrx_bufs, obsoleting one local variable
>
> drivers/spi/spi-bcm63xx.c | 134
> +++--
> 1 file changed, 106 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
> index 27667c1..9578af7 100644
> --- a/drivers/spi/spi-bcm63xx.c
> +++ b/drivers/spi/spi-bcm63xx.c
> @@ -37,6 +37,8 @@
>
> #define PFX KBUILD_MODNAME
>
> +#define BCM63XX_SPI_MAX_PREPEND 15
> +
> struct bcm63xx_spi {
> struct completion done;
>
> @@ -169,13 +171,17 @@ static int bcm63xx_spi_setup(struct spi_device *spi)
> return 0;
> }
>
> -static int bcm63xx_txrx_bufs(struct spi_device *spi, struct spi_transfer *t)
> +static int bcm63xx_txrx_bufs(struct spi_device *spi, struct spi_transfer
> *first,
> + unsigned int num_transfers)
> {
> struct bcm63xx_spi *bs = spi_master_get_devdata(spi->master);
> u16 msg_ctl;
> u16 cmd;
> u8 rx_tail;
> - unsigned int timeout = 0;
> + unsigned int i, timeout = 0, prepend_len = 0, len = 0;
> + struct spi_transfer *t = first;
> + bool do_rx = false;
> + bool do_tx = false;
>
> /* Disable the CMD_DONE interrupt */
> bcm_spi_writeb(bs, 0, SPI_INT_MASK);
> @@ -183,19 +189,45 @@ static int bcm63xx_txrx_bufs(struct spi_device *spi,
> struct spi_transfer *t)
> dev_dbg(&spi->dev, "txrx: tx %p, rx %p, len %d\n",
> t->tx_buf, t->rx_buf, t->len);
>
> - if (t->tx_buf)
> - memcpy_toio(bs->tx_io, t->tx_buf, t->len);
> + if (num_transfers > 1 && t->tx_buf && t->len <= BCM63XX_SPI_MAX_PREPEND)
> + prepend_len = t->len;
> +
> + /* prepare the buffer */
> + for (i = 0; i < num_transfers; i++) {
> + if (t->tx_buf) {
> + do_tx = true;
> + memcpy_toio(bs->tx_io + len, t->tx_buf, t->len);
> +
> + /* don't prepend more than one tx */
> + if (t != first)
> + prepend_len = 0;
> + }
> +
> + if (t->rx_buf) {
> + do_rx = true;
> + /* prepend is half-duplex write only */
> + if (t == first)
> + prepend_len = 0;
> + }
> +
> + len += t->len;
> +
> + t = list_entry(t->transfer_list.next, struct spi_transfer,
> +transfer_list);
> + }
> +
> + len -= prepend_len;
>
> init_completion(&bs->done);
>
> /* Fill in the Message control register */
> - msg_ctl = (t->len << SPI_BYTE_CNT_SHIFT);
> + msg_ctl = (len << SPI_BYTE_CNT_SHIFT);
>
> - if (t->rx_buf && t->tx_buf)
> + if (do_rx && do_tx && prepend_len == 0)
> msg_ctl |= (SPI_FD_RW << bs->msg_type_shift);
> - else if (t->rx_buf)
> + else if (do_rx)
> msg_ctl |= (SPI_HD_R << bs->msg_type_shift);
> - else if (t->tx_buf)
> + else if (do_tx)
> msg_ctl |= (SPI_HD_W << bs->msg_type_shift);
>
> switch (bs->msg_ctl_width) {
> @@ -209,7 +241,7 @@ static int bcm63xx_txrx_bufs(struct spi_device *spi,
> struct spi_transfer *t)
>
> /* Issue the transfer */
> cmd = SPI_CMD_START_IMMEDIATE;
> - cmd |= (0 << SPI_CMD_PREPEND_BYTE_CNT_SHIFT);
> + cmd |= (prepend_len << SPI_CMD_PREPEND_BYTE_CNT_SHIFT);
> cmd |= (spi->chip_select << SPI_CMD_DEVICE_ID_SHIFT);
> bcm_spi_writew(bs, cmd, SPI_CMD);
>
> @@ -223,9 +255,25 @@ static int bcm63xx_txrx_bufs(struct spi_device *spi,
> struct spi_transfer *t)
> /* read out all data */
> rx_tail = bcm_spi_readb(bs, SPI_RX_TAIL);
>
> + if (do_rx && rx_tail != len)
> + return -EIO;
> +
> + if (!rx_tail)
> + return 0;
> +
> + len = 0;
> + t = first;
> /* Read out all the data */
> - if (rx_tail)
> - memcpy_fromio(t->rx_ptr, bs->rx_io, rx_tail);
> + for (i = 0; i < num_transfers; i++) {
> + if (t->rx_buf)
> + memcpy_fromio(t-
Re: [PATCH V2 1/2] spi/bcm63xx: reject transfers unable to transfer
On Sun, 3 Feb 2013 15:15:12 +0100, Jonas Gorski wrote: > The hardware does not support keeping CS asserted after sending one > FIFO buffer worth of data, so reject transfers requiring CS being kept > asserted, either between transers or for a certain time after it, > or exceeding the FIFO size. > > Signed-off-by: Jonas Gorski Applied, thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH V2 0/2] spi/bcm63xx: fix multi transfer messages
On Sun, 3 Feb 2013 15:15:11 +0100, Jonas Gorski wrote: > The bcm63xx SPI controller does not support keeping CS up after doing a > transfer. Since this is problematic for most typical use cases, this > patchset introduces a workaround by combining small enough messages > to one transfer, rejecting anything that can't be fulfilled with the > hardware. > > Patch one properly rejects anything impossible to transfer with these > limitations. > Patch two introduces logic for combining transfers to one to be able to > use it for typical use cases (register accesses and flash access). > > Build and run tested on a BCM6368 with a SPI controlled switch attached > requiring write-then-read with CS asserted. > > Changes V1 -> V2: > * split into two patches > * fixed return type of bcm63xx_txrx_bufs() > * slightly reworked bcm63xx_txrx_bufs, obsoleting one local variable > * added a bit more comments in the code > * added error messages indicated why transfers were rejected Another option is to allow longer transfers if a GPIO is used for the CS line. A lot of SPI controllers need to do that. That isn't a critique of this patch because it is essentially a bug fix, but rather a way you can work around the limitation. g. > > Jonas Gorski (2): > spi/bcm63xx: reject transfers unable to transfer > spi/bcm63xx: work around inability to keep CS up > > drivers/spi/spi-bcm63xx.c | 179 > +++-- > 1 file changed, 125 insertions(+), 54 deletions(-) > > -- > 1.7.10.4 > -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH RFC 1/1] gpio: mcp23s08: convert driver to DT
On Thu, 31 Jan 2013 21:51:36 +0100, Linus Walleij wrote: > On Thu, Jan 31, 2013 at 4:58 PM, Lars Poeschel > wrote: > > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt > > @@ -0,0 +1,27 @@ > > +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for > > +8-/16-bit I/O expander with serial interface (I2C/SPI) > > + > > +Required properties: > > +- compatible : Should be "mcp,mcp23s08-gpio", "mcp,mcp23s17-gpio", > > + "mcp,mcp23008-gpio" or "mcp,mcp23017-gpio" > > +- base : The first gpio number that should be assigned by this chip. > > No. We do not tie the global GPIO numbers into the device tree. > > In the DT GPIOs are referenced by ampersand <&gpio0 1 2> > notation referring to the instance, so as you realize DT itself > has no need for that number. > > Further it is not OS-neutral. > > You have to find another way to handle this in the driver code. > In worst case: use AUXDATA. Hi Lars, The trick is to declare the io expander to be a "gpio-controller" and use the #gpio-cells property to declare how many cells (32-bit numbers) are need to specify a single gpio line. Most gpio controllers use "gpio-cells=<2>"; The first cell is the *controller local* gpio number, and the second cell is used for flags. That way your gpio controller can be referenced by other nodes in the tree with a "gpios" property. You can find lots of examples of this in the tree. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On Tue, Feb 05, 2013 at 07:48:33AM -0500, Jason Cooper wrote: > Morning-ish Andrew, > > On Tue, Feb 05, 2013 at 01:38:27PM +0100, Andrew Lunn wrote: > > > And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y > > > > Maybe it makes sense to provide a patch to mvebu_defconfig to add > > CONFIG_MTD_M25P80=y ? > > I thought this as well, then reconsidered when he said there was nothing > on it. So it's not really needed to boot. I don't have a strong > opinion on it though, so =y, =m, or =n. > Well, the SPI flash may not be empty, if that's what you meant. For instnace, my Armada XP GP board has the bootloader on that SPI, and boots from there. After booting, the SPI flash is no longer needed. IMHO, I don't think we should include the option CONFIG_MTD_M25P80 as it is just a particular SPI master device present in a particular board. On the other hand, I don't have a strong opinion on this. I've always wondered the *true* meaning of defconfigs, so feel free to enligthen me :) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 3/5] serial: pl011: use generic DMA slave configuration if possible
On Mon, 28 Jan 2013 17:57:35 +, Arnd Bergmann wrote:
> With the new OF DMA binding, it is possible to completely avoid the
> need for platform_data for configuring a DMA channel. In cases where the
> platform has already been converted, calling dma_request_slave_channel
> should get all the necessary information from the device tree.
>
> Like the patch that converts the dw_dma controller, this is completely
> untested and is looking for someone to try it out.
>
> Signed-off-by: Arnd Bergmann
> Cc: Grant Likely
> Cc: Jiri Slaby
> Cc: Greg Kroah-Hartman
> Cc: Linus Walleij
> Cc: spi-devel-general@lists.sourceforge.net
> Cc: Viresh Kumar
> Cc: Andy Shevchenko
> Cc: Vinod Koul
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@vger.kernel.org
Acked-by: Grant Likely
> ---
> drivers/tty/serial/amba-pl011.c | 62
> -
> 1 file changed, 37 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 3ea5408..c25b00e 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan,
> struct pl011_sgbuf *sg,
> }
> }
>
> -static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
> +static void pl011_dma_probe_initcall(struct device *dev, struct
> uart_amba_port *uap)
> {
> /* DMA is the sole user of the platform data right now */
> struct amba_pl011_data *plat = uap->port.dev->platform_data;
> @@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct
> uart_amba_port *uap)
> struct dma_chan *chan;
> dma_cap_mask_t mask;
>
> - /* We need platform data */
> - if (!plat || !plat->dma_filter) {
> - dev_info(uap->port.dev, "no DMA platform data\n");
> - return;
> - }
> + chan = dma_request_slave_channel(dev, "tx");
>
> - /* Try to acquire a generic DMA engine slave TX channel */
> - dma_cap_zero(mask);
> - dma_cap_set(DMA_SLAVE, mask);
> -
> - chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
> if (!chan) {
> - dev_err(uap->port.dev, "no TX DMA channel!\n");
> - return;
> + /* We need platform data */
> + if (!plat || !plat->dma_filter) {
> + dev_info(uap->port.dev, "no DMA platform data\n");
> + return;
> + }
> +
> + /* Try to acquire a generic DMA engine slave TX channel */
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_SLAVE, mask);
> +
> + chan = dma_request_channel(mask, plat->dma_filter,
> + plat->dma_tx_param);
> + if (!chan) {
> + dev_err(uap->port.dev, "no TX DMA channel!\n");
> + return;
> + }
> }
>
> dmaengine_slave_config(chan, &tx_conf);
> @@ -282,7 +287,18 @@ static void pl011_dma_probe_initcall(struct
> uart_amba_port *uap)
>dma_chan_name(uap->dmatx.chan));
>
> /* Optionally make use of an RX channel as well */
> - if (plat->dma_rx_param) {
> + chan = dma_request_slave_channel(dev, "rx");
> +
> + if (!chan && plat->dma_rx_param) {
> + chan = dma_request_channel(mask, plat->dma_filter,
> plat->dma_rx_param);
> +
> + if (!chan) {
> + dev_err(uap->port.dev, "no RX DMA channel!\n");
> + return;
> + }
> + }
> +
> + if (chan) {
> struct dma_slave_config rx_conf = {
> .src_addr = uap->port.mapbase + UART01x_DR,
> .src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
> @@ -291,12 +307,6 @@ static void pl011_dma_probe_initcall(struct
> uart_amba_port *uap)
> .device_fc = false,
> };
>
> - chan = dma_request_channel(mask, plat->dma_filter,
> plat->dma_rx_param);
> - if (!chan) {
> - dev_err(uap->port.dev, "no RX DMA channel!\n");
> - return;
> - }
> -
> dmaengine_slave_config(chan, &rx_conf);
> uap->dmarx.chan = chan;
>
> @@ -315,6 +325,7 @@ static void pl011_dma_probe_initcall(struct
> uart_amba_port *uap)
> struct dma_uap {
> struct list_head node;
> struct uart_amba_port *uap;
> + struct device *dev;
> };
>
> static LIST_HEAD(pl011_dma_uarts);
> @@ -325,7 +336,7 @@ static int __init pl011_dma_initcall(void)
>
> list_for_each_safe(node, tmp, &pl011_dma_uarts) {
> struct dma_uap *dmau = list_entry(node, struct dma_uap, node);
> - pl011_dma_probe_initcall(dmau->uap);
> + pl011_dma_probe_initcall(dmau->dev, dmau->uap);
> list_del(node);
> kfree(dmau);
> }
> @@ -334,18 +345,19 @
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Mon, 28 Jan 2013 17:57:34 +, Arnd Bergmann wrote:
> With the new OF DMA binding, it is possible to completely avoid the
> need for platform_data for configuring a DMA channel. In cases where the
> platform has already been converted, calling dma_request_slave_channel
> should get all the necessary information from the device tree.
>
> Like the patch that converts the dw_dma controller, this is completely
> untested and is looking for someone to try it out.
>
> Signed-off-by: Arnd Bergmann
> Cc: Grant Likely
> Cc: Mark Brown
> Cc: spi-devel-general@lists.sourceforge.net
> Cc: Viresh Kumar
> Cc: Andy Shevchenko
> Cc: Vinod Koul
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@vger.kernel.org
> ---
> drivers/spi/spi-pl022.c | 43 +--
> 1 file changed, 41 insertions(+), 2 deletions(-)
Acked-by: Grant Likely
>
> diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
> index b0fe393..371cc66f 100644
> --- a/drivers/spi/spi-pl022.c
> +++ b/drivers/spi/spi-pl022.c
> @@ -1139,6 +1139,35 @@ err_no_rxchan:
> return -ENODEV;
> }
>
> +static int pl022_dma_autoprobe(struct pl022 *pl022)
> +{
> + struct device *dev = &pl022->adev->dev;
> +
> + /* automatically configure DMA channels from platform, normally using
> DT */
> + pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
> + if (!pl022->dma_rx_channel)
> + goto err_no_rxchan;
> +
> + pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
> + if (!pl022->dma_tx_channel)
> + goto err_no_txchan;
> +
> + pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!pl022->dummypage)
> + goto err_no_dummypage;
> +
> + return 0;
> +
> +err_no_dummypage:
> + dma_release_channel(pl022->dma_tx_channel);
> + pl022->dma_tx_channel = NULL;
> +err_no_txchan:
> + dma_release_channel(pl022->dma_rx_channel);
> + pl022->dma_rx_channel = NULL;
> +err_no_rxchan:
> + return -ENODEV;
> +}
> +
> static void terminate_dma(struct pl022 *pl022)
> {
> struct dma_chan *rxchan = pl022->dma_rx_channel;
> @@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
> return -ENODEV;
> }
>
> +static inline int pl022_dma_autoprobe(struct pl022 *pl022)
> +{
> + return 0;
> +}
> +
> static inline int pl022_dma_probe(struct pl022 *pl022)
> {
> return 0;
> @@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const
> struct amba_id *id)
> goto err_no_irq;
> }
>
> - /* Get DMA channels */
> - if (platform_info->enable_dma) {
> + /* Get DMA channels, try autoconfiguration first */
> + status = pl022_dma_autoprobe(pl022);
> +
> + /* If that failed, use channels from platform_info */
> + if (status == 0)
> + platform_info->enable_dma = 1;
> + else if (platform_info->enable_dma) {
> status = pl022_dma_probe(pl022);
> if (status != 0)
> platform_info->enable_dma = 0;
> --
> 1.8.0
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: Ensure memory used for spi_write_then_read() is DMA safe
On Sun, 27 Jan 2013 14:35:04 +0800, Mark Brown
wrote:
> Use GFP_DMA in order to ensure that the memory we allocate for transfers
> in spi_write_then_read() can be DMAed. On most platforms this will have
> no effect.
>
> Signed-off-by: Mark Brown
Applied, thanks.
g.
> ---
> drivers/spi/spi.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 19ee901..14d0fba 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1656,7 +1656,8 @@ int spi_write_then_read(struct spi_device *spi,
>* using the pre-allocated buffer or the transfer is too large.
>*/
> if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock(&lock)) {
> - local_buf = kmalloc(max((unsigned)SPI_BUFSIZ, n_tx + n_rx),
> GFP_KERNEL);
> + local_buf = kmalloc(max((unsigned)SPI_BUFSIZ, n_tx + n_rx),
> + GFP_KERNEL | GFP_DMA);
> if (!local_buf)
> return -ENOMEM;
> } else {
> --
> 1.7.10.4
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 25/33] spi: Convert to devm_ioremap_resource()
On Mon, 21 Jan 2013 11:09:18 +0100, Thierry Reding
wrote:
> Convert all uses of devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
>
> devm_ioremap_resource() provides its own error messages so all explicit
> error messages can be removed from the failure code paths.
>
> Signed-off-by: Thierry Reding
> Cc: Grant Likely
> Cc: spi-devel-general@lists.sourceforge.net
Looks fine by me. Go ahead and merge with the rest of the series.
Acked-by: Grant Likely
> ---
> drivers/spi/spi-ep93xx.c | 7 +++
> drivers/spi/spi-mxs.c| 6 +++---
> drivers/spi/spi-omap2-mcspi.c| 7 +++
> drivers/spi/spi-s3c64xx.c| 7 +++
> drivers/spi/spi-sirf.c | 7 +++
> drivers/spi/spi-tegra20-sflash.c | 8 +++-
> drivers/spi/spi-tegra20-slink.c | 8 +++-
> 7 files changed, 21 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
> index acb1e19..2e31f32 100644
> --- a/drivers/spi/spi-ep93xx.c
> +++ b/drivers/spi/spi-ep93xx.c
> @@ -1085,10 +1085,9 @@ static int ep93xx_spi_probe(struct platform_device
> *pdev)
>
> espi->sspdr_phys = res->start + SSPDR;
>
> - espi->regs_base = devm_request_and_ioremap(&pdev->dev, res);
> - if (!espi->regs_base) {
> - dev_err(&pdev->dev, "failed to map resources\n");
> - error = -ENODEV;
> + espi->regs_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(espi->regs_base)) {
> + error = PTR_ERR(espi->regs_base);
> goto fail_put_clock;
> }
>
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index a3ede24..b735988 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -538,9 +538,9 @@ static int mxs_spi_probe(struct platform_device *pdev)
> if (!iores || irq_err < 0 || irq_dma < 0)
> return -EINVAL;
>
> - base = devm_request_and_ioremap(&pdev->dev, iores);
> - if (!base)
> - return -EADDRNOTAVAIL;
> + base = devm_ioremap_resource(&pdev->dev, iores);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>
> pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> if (IS_ERR(pinctrl))
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index b610f52..71a9482 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -1204,10 +1204,9 @@ static int omap2_mcspi_probe(struct platform_device
> *pdev)
> r->end += regs_offset;
> mcspi->phys = r->start;
>
> - mcspi->base = devm_request_and_ioremap(&pdev->dev, r);
> - if (!mcspi->base) {
> - dev_dbg(&pdev->dev, "can't ioremap MCSPI\n");
> - status = -ENOMEM;
> + mcspi->base = devm_ioremap_resource(&pdev->dev, r);
> + if (IS_ERR(mcspi->base)) {
> + status = PTR_ERR(mcspi->base);
> goto free_master;
> }
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index ad93231..3d4a7c4 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1276,10 +1276,9 @@ static int __init s3c64xx_spi_probe(struct
> platform_device *pdev)
> /* the spi->mode bits understood by this driver: */
> master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
>
> - sdd->regs = devm_request_and_ioremap(&pdev->dev, mem_res);
> - if (sdd->regs == NULL) {
> - dev_err(&pdev->dev, "Unable to remap IO\n");
> - ret = -ENXIO;
> + sdd->regs = devm_ioremap_resource(&pdev->dev, mem_res);
> + if (IS_ERR(sdd->regs)) {
> + ret = PTR_ERR(sdd->regs);
> goto err1;
> }
>
> diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
> index e0f43a5..78c8842 100644
> --- a/drivers/spi/spi-sirf.c
> +++ b/drivers/spi/spi-sirf.c
> @@ -535,10 +535,9 @@ static int spi_sirfsoc_probe(struct platform_device
> *pdev)
> }
> }
>
> - sspi->base = devm_request_and_ioremap(&pdev->dev, mem_res);
> - if (!sspi->base) {
> - dev_err(&pdev->dev, "IO remap failed!\n");
> - ret = -ENOMEM;
> + sspi->base = devm_ioremap_resource(&pdev->dev, mem_res);
> + if (IS_ERR(sspi->base)) {
> + ret = PTR_ERR(sspi->base);
> goto free_master;
> }
>
> diff --git a/drivers/spi/spi-tegra20-sflash.c
> b/drivers/spi/spi-tegra20-sflash.c
> index 448a8cc..69c9d23 100644
> --- a/drivers/spi/spi-tegra20-sflash.c
> +++ b/drivers/spi/spi-tegra20-sflash.c
> @@ -508,11 +508,9 @@ static int tegra_sflash_probe(struct platform_device
> *pdev)
> ret = -ENODEV;
> goto exit_free_master;
> }
> - tsd->base = devm_request_and_ioremap(&pdev->dev, r);
> - if (!tsd->base) {
> - dev_err(&pdev->dev,
> - "Cannot request memregion/iomap dma address\n");
> -
Re: [PATCH 2/2] spi: spi-mpc512x-psc: add support for gpio chip selects
On Mon, 14 Jan 2013 21:27:01 +0100, Anatolij Gustschin wrote:
> Currently the driver only uses one internal chip select. Add support
> for gpio chip selects configured by gpio specifiers in the device tree.
>
> Signed-off-by: Anatolij Gustschin
GPIO chip selects are now in the core spi library. Take a look at
master->cs_gpios and Documentation/devicetree/bindings/spi/spi-bus.txt.
You don't need to parse them manually.
g.
> ---
> drivers/spi/spi-mpc512x-psc.c | 80
> ++---
> 1 files changed, 75 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
> index 89480b2..4b2f391 100644
> --- a/drivers/spi/spi-mpc512x-psc.c
> +++ b/drivers/spi/spi-mpc512x-psc.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -50,6 +51,8 @@ struct mpc512x_psc_spi {
> spinlock_t lock;/* Message queue lock */
>
> struct completion done;
> + int num_cs;
> + int chipselects[0];
> };
>
> /* controller state */
> @@ -277,6 +280,7 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
> {
> struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
> struct mpc512x_psc_spi_cs *cs = spi->controller_state;
> + int gpio = mps->chipselects[spi->chip_select];
> unsigned long flags;
>
> if (spi->bits_per_word % 8)
> @@ -292,6 +296,9 @@ static int mpc512x_psc_spi_setup(struct spi_device *spi)
> cs->bits_per_word = spi->bits_per_word;
> cs->speed_hz = spi->max_speed_hz;
>
> + if (gpio_is_valid(gpio))
> + gpio_direction_output(gpio, spi->mode & SPI_CS_HIGH ? 0 : 1);
> +
> spin_lock_irqsave(&mps->lock, flags);
> if (!mps->busy)
> mpc512x_psc_spi_deactivate_cs(spi);
> @@ -405,6 +412,27 @@ static irqreturn_t mpc512x_psc_spi_isr(int irq, void
> *dev_id)
> return IRQ_NONE;
> }
>
> +static void mpc512x_spi_cs_control(struct spi_device *spi, bool on)
> +{
> + struct mpc512x_psc_spi *mps = spi_master_get_devdata(spi->master);
> + int gpio = mps->chipselects[spi->chip_select];
> +
> + gpio_set_value(gpio, on);
> +}
> +
> +static int mpc512x_spi_cs_num(struct device *dev)
> +{
> + int num_cs, ret;
> +
> + ret = of_property_read_u32(dev->of_node, "num-cs", &num_cs);
> + if (ret < 0) {
> + dev_warn(dev, "no num-cs property\n");
> + return of_gpio_named_count(dev->of_node, "cs-gpios");
> + }
> +
> + return num_cs;
> +}
> +
> /* bus_num is used only for the case dev->platform_data == NULL */
> static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
> u32 size, unsigned int irq,
> @@ -415,8 +443,17 @@ static int mpc512x_psc_spi_do_probe(struct device *dev,
> u32 regaddr,
> struct spi_master *master;
> int ret;
> void *tempp;
> + int i = 0, max_cs_num = 0;
> + int use_internal_cs = 0;
> + int num_cs;
> +
> + num_cs = mpc512x_spi_cs_num(dev);
> + if (!num_cs)
> + use_internal_cs = 1;
>
> - master = spi_alloc_master(dev, sizeof *mps);
> + dev_dbg(dev, "using %d gpio chipselects\n", num_cs);
> +
> + master = spi_alloc_master(dev, sizeof(*mps) + sizeof(int) * num_cs);
> if (master == NULL)
> return -ENOMEM;
>
> @@ -425,12 +462,14 @@ static int mpc512x_psc_spi_do_probe(struct device *dev,
> u32 regaddr,
> mps->irq = irq;
>
> if (pdata == NULL) {
> - dev_err(dev, "probe called without platform data, no "
> - "cs_control function will be called\n");
> - mps->cs_control = NULL;
> mps->sysclk = 0;
> master->bus_num = bus_num;
> - master->num_chipselect = 255;
> + if (use_internal_cs) {
> + mps->cs_control = NULL;
> + master->num_chipselect = 1;
> + } else {
> + mps->cs_control = mpc512x_spi_cs_control;
> + }
> } else {
> mps->cs_control = pdata->cs_control;
> mps->sysclk = pdata->sysclk;
> @@ -438,6 +477,28 @@ static int mpc512x_psc_spi_do_probe(struct device *dev,
> u32 regaddr,
> master->num_chipselect = pdata->max_chipselect;
> }
>
> + if (!pdata && !use_internal_cs) {
> + for (i = 0; i < num_cs; i++) {
> + int cs_gpio = of_get_named_gpio(dev->of_node,
> + "cs-gpios", i);
> +
> + dev_dbg(dev, "cs %d: gpio %d\n", i, cs_gpio);
> + mps->chipselects[i] = cs_gpio;
> + if (!gpio_is_valid(cs_gpio))
> + continue;
> +
> + max_cs_num = max(max_cs_num, cs_gpio);
> + ret = gpio_request(mps->chipselects[i],
> +
Re: [PATCH 1/2] spi: spi-mpc512x-psc: init mode bits supported by the driver
On Mon, 14 Jan 2013 21:27:00 +0100, Anatolij Gustschin wrote: > The driver should setup mode bits it supports, otherwise > adding an SPI device might fail even if the driver supports > the requested SPI mode. > > Signed-off-by: Anatolij Gustschin Applied, thanks. g. > --- > drivers/spi/spi-mpc512x-psc.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c > index 88e5441..89480b2 100644 > --- a/drivers/spi/spi-mpc512x-psc.c > +++ b/drivers/spi/spi-mpc512x-psc.c > @@ -438,6 +438,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, > u32 regaddr, > master->num_chipselect = pdata->max_chipselect; > } > > + master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST; > master->setup = mpc512x_psc_spi_setup; > master->transfer = mpc512x_psc_spi_transfer; > master->cleanup = mpc512x_psc_spi_cleanup; > -- > 1.7.5.4 > -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2] spi: spi-mpc512x-psc: don't use obsolet cell-index property
On Fri, 11 Jan 2013 01:05:48 +0100, Anatolij Gustschin wrote:
> Remove deprecated cell-index property and use spi alias to
> obtain the SPI PSC number used for SPI bus id.
>
> Signed-off-by: Anatolij Gustschin
> ---
> v2:
> - use of_alias_get_id() to get spi bus number
>
Applied, thanks.
g.
> drivers/spi/spi-mpc512x-psc.c | 16 +---
> 1 files changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
> index cb3a310..88e5441 100644
> --- a/drivers/spi/spi-mpc512x-psc.c
> +++ b/drivers/spi/spi-mpc512x-psc.c
> @@ -522,17 +522,11 @@ static int mpc512x_psc_spi_of_probe(struct
> platform_device *op)
> regaddr64 = of_translate_address(op->dev.of_node, regaddr_p);
>
> /* get PSC id (0..11, used by port_config) */
> - if (op->dev.platform_data == NULL) {
> - const u32 *psc_nump;
> -
> - psc_nump = of_get_property(op->dev.of_node, "cell-index", NULL);
> - if (!psc_nump || *psc_nump > 11) {
> - dev_err(&op->dev, "mpc512x_psc_spi: Device node %s "
> - "has invalid cell-index property\n",
> - op->dev.of_node->full_name);
> - return -EINVAL;
> - }
> - id = *psc_nump;
> + id = of_alias_get_id(op->dev.of_node, "spi");
> + if (id < 0) {
> + dev_err(&op->dev, "no alias id for %s\n",
> + op->dev.of_node->full_name);
> + return id;
> }
>
> return mpc512x_psc_spi_do_probe(&op->dev, (u32) regaddr64, (u32) size64,
> --
> 1.7.5.4
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/3] spi: Add helper functions for setting up transfers
On Sun, 27 Jan 2013 03:33:59 +, Mark Brown wrote: > On Wed, Jan 09, 2013 at 06:31:09PM +0100, Lars-Peter Clausen wrote: > > > The second function spi_sync_transfer() takes a SPI device and an array of > > spi_transfers. It will allocate a new spi_message (on the stack) and add all > > transfers in the array to the message. Finally it will call spi_sync() on > > the > > message. > > Reviewed-by: Mark Brown Looks good to me also. Go ahead and merge this series through the iio tree since it is the first user. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] spi: Remove erroneous __exit and __exit_p() references in drivers
Some of the spi driver module remove hooks were annotated with __exit
and referenced with __exit_p(). Presumably these were supposed to be
__devexit and __devexit_p() since __exit for a remove hook has never
been correct. They also got missed during the big __devexit purge since
they didn't match the pattern. Remove then now to be rid of it.
Reported-by: Arnd Bergmann
[Arnd set a patch cleaning up one, and then I found more]
Signed-off-by: Grant Likely
---
drivers/spi/spi-atmel.c |2 +-
drivers/spi/spi-au1550.c |4 ++--
drivers/spi/spi-omap-100k.c |4 ++--
drivers/spi/spi-omap-uwire.c |4 ++--
drivers/spi/spi-orion.c |4 ++--
drivers/spi/spi-ppc4xx.c |4 ++--
drivers/spi/spi-txx9.c |4 ++--
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..656d137 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
.suspend= atmel_spi_suspend,
.resume = atmel_spi_resume,
.probe = atmel_spi_probe,
- .remove = __exit_p(atmel_spi_remove),
+ .remove = atmel_spi_remove,
};
module_platform_driver(atmel_spi_driver);
diff --git a/drivers/spi/spi-au1550.c b/drivers/spi/spi-au1550.c
index 4de66d1c..363ff6b 100644
--- a/drivers/spi/spi-au1550.c
+++ b/drivers/spi/spi-au1550.c
@@ -968,7 +968,7 @@ err_nomem:
return err;
}
-static int __exit au1550_spi_remove(struct platform_device *pdev)
+static int au1550_spi_remove(struct platform_device *pdev)
{
struct au1550_spi *hw = platform_get_drvdata(pdev);
@@ -997,7 +997,7 @@ static int __exit au1550_spi_remove(struct platform_device
*pdev)
MODULE_ALIAS("platform:au1550-spi");
static struct platform_driver au1550_spi_drv = {
- .remove = __exit_p(au1550_spi_remove),
+ .remove = au1550_spi_remove,
.driver = {
.name = "au1550-spi",
.owner = THIS_MODULE,
diff --git a/drivers/spi/spi-omap-100k.c b/drivers/spi/spi-omap-100k.c
index 3aef7fa..d31e203 100644
--- a/drivers/spi/spi-omap-100k.c
+++ b/drivers/spi/spi-omap-100k.c
@@ -560,7 +560,7 @@ err1:
return status;
}
-static int __exit omap1_spi100k_remove(struct platform_device *pdev)
+static int omap1_spi100k_remove(struct platform_device *pdev)
{
struct spi_master *master;
struct omap1_spi100k*spi100k;
@@ -604,7 +604,7 @@ static struct platform_driver omap1_spi100k_driver = {
.name = "omap1_spi100k",
.owner = THIS_MODULE,
},
- .remove = __exit_p(omap1_spi100k_remove),
+ .remove = omap1_spi100k_remove,
};
diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index 0a94d9d..b8f2535 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -536,7 +536,7 @@ static int __init uwire_probe(struct platform_device *pdev)
return status;
}
-static int __exit uwire_remove(struct platform_device *pdev)
+static int uwire_remove(struct platform_device *pdev)
{
struct uwire_spi*uwire = dev_get_drvdata(&pdev->dev);
int status;
@@ -557,7 +557,7 @@ static struct platform_driver uwire_driver = {
.name = "omap_uwire",
.owner = THIS_MODULE,
},
- .remove = __exit_p(uwire_remove),
+ .remove = uwire_remove,
// suspend ... unuse ck
// resume ... use ck
};
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index b7e7182..4a548e8 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -479,7 +479,7 @@ out:
}
-static int __exit orion_spi_remove(struct platform_device *pdev)
+static int orion_spi_remove(struct platform_device *pdev)
{
struct spi_master *master;
struct resource *r;
@@ -513,7 +513,7 @@ static struct platform_driver orion_spi_driver = {
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(orion_spi_of_match_table),
},
- .remove = __exit_p(orion_spi_remove),
+ .remove = orion_spi_remove,
};
static int __init orion_spi_init(void)
diff --git a/drivers/spi/spi-ppc4xx.c b/drivers/spi/spi-ppc4xx.c
index 7a85f22..027b474 100644
--- a/drivers/spi/spi-ppc4xx.c
+++ b/drivers/spi/spi-ppc4xx.c
@@ -560,7 +560,7 @@ free_master:
return ret;
}
-static int __exit spi_ppc4xx_of_remove(struct platform_device *op)
+static int spi_ppc4xx_of_remove(struct platform_device *op)
{
struct spi_master *master = dev_get_drvdata(&op->dev);
struct ppc4xx_spi *hw = spi_master_get_devdata(master);
@@ -583,7 +583,7 @@ MODULE_DEVICE_TABLE(of, spi_ppc4xx_of_match);
static struct platform_driver spi_ppc4xx_of_driver = {
.probe = spi_ppc4xx_of
Re: [PATCH 1/2] ARM: mvebu: Add support for SPI controller in Armada 370/XP
Hi Ezequiel,
On 02/04/2013 05:38 PM, Ezequiel Garcia wrote:
> The Armada 370 and Armada XP SoC has an SPI controller.
> This patch adds support for this controller in Armada 370
> and Armada XP SoC common device tree files.
>
> Cc: Gregory Clement
> Cc: Thomas Petazzoni
> Cc: Lior Amsalem
> Signed-off-by: Ezequiel Garcia
> ---
> arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
> b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 28276fe..22340d5 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -145,6 +145,28 @@
> clocks = <&gateclk 17>;
> status = "disabled";
> };
> +
> + spi0: spi@d0010600 {
> + compatible = "marvell,orion-spi";
> + reg = <0xd0010600 0x50>;
Currently the driver only use the 5th first register. All of the other
mvebu platform declare the last register at offset 0x28. The Armada
370 SoC have also the last register at offset 0x28. Only for the
Armada XP SoC there are more registers and we have a the last register
at offset 0x50. Obviously the driver won't use these extra register.
So I think that the best for now is to declare:
reg = <0xd0010600 0x28>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + interrupts = <30>;
> + clocks = <&coreclk 0>;
> + status = "disabled";
> + };
> +
> + spi1: spi@d0010680 {
> + compatible = "marvell,orion-spi";
> + reg = <0xd0010680 0x50>;
and here:
reg = <0xd0010680 0x28>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <1>;
> + interrupts = <92>;
> + clocks = <&coreclk 0>;
> + status = "disabled";
> + };
> };
> };
>
>
Once it will be fixed, for this patch you can add my
Acked-by: Gregory Clement
Regards,
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] driver-core: constify data for class_find_device()
On Fri, 1 Feb 2013 20:40:17 +0100 (CET), MichaÅ MirosÅaw wrote: > All in-kernel users of class_find_device() don't really need mutable > data for match callback. > > In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c) > this patch changes match callbacks to use const search data. > > The const is propagated to rtc_class_open() and power_supply_get_by_name() > parameters. > > Note that there's a dev reference leak in suspend_test.c that's not > touched in this patch. > > Signed-off-by: MichaÅ MirosÅaw > --- > > patch against https://github.com/torvalds/linux.git master Acked-by: Grant Likely for the GPIO and SPI bits. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 14/19] spi/atmel: remove incorrect __exit_p()
On Fri, 25 Jan 2013 14:14:31 +, Arnd Bergmann wrote: > Since we no longer allow building without hotplug, the > atmel_spi_remove function is always present and we should > not use __exit_p() to refer to it. > > Without this patch, building at91_dt_defconfig results in: > > drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not > used [-Wunused-function] Looks good, but I took a deeper look and it is incomplete. I found an whole bunch more references. I've crafted a new patch to get rid of them. I'll post and commit it to my tree. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: s3c64xx: fix checkpatch warnings and error
On Thu, 31 Jan 2013 15:25:01 +0900, Jingoo Han wrote:
> Fix checkpatch warnings and error as below:
> ERROR: "foo * bar" should be "foo *bar"
> WARNING: please, no space before tabs
> WARNING: quoted string split across lines
> WARNING: msleep < 20ms can sleep for up to 20ms; see
> Documentation/timers/timers-howto.txt
>
> Signed-off-by: Jingoo Han
Applied, thanks.
g.
> ---
> drivers/spi/spi-s3c64xx.c | 33 +
> 1 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 4dd7b7c..ae8ef6d 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -62,7 +62,7 @@
> #define S3C64XX_SPI_CLKSEL_SRCMSK(3<<9)
> #define S3C64XX_SPI_CLKSEL_SRCSHFT 9
> #define S3C64XX_SPI_ENCLK_ENABLE (1<<8)
> -#define S3C64XX_SPI_PSR_MASK 0xff
> +#define S3C64XX_SPI_PSR_MASK 0xff
>
> #define S3C64XX_SPI_MODE_CH_TSZ_BYTE (0<<29)
> #define S3C64XX_SPI_MODE_CH_TSZ_HALFWORD (1<<29)
> @@ -743,8 +743,7 @@ static int s3c64xx_spi_transfer_one_message(struct
> spi_master *master,
> sdd->regs + S3C64XX_SPI_SLAVE_SEL);
>
> if (status) {
> - dev_err(&spi->dev, "I/O Error: "
> - "rx-%d tx-%d res:rx-%c tx-%c len-%d\n",
> + dev_err(&spi->dev, "I/O Error: rx-%d tx-%d res:rx-%c
> tx-%c len-%d\n",
> xfer->rx_buf ? 1 : 0, xfer->tx_buf ? 1 : 0,
> (sdd->state & RXBUSY) ? 'f' : 'p',
> (sdd->state & TXBUSY) ? 'f' : 'p',
> @@ -801,7 +800,7 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master
> *spi)
>
> /* Acquire DMA channels */
> while (!acquire_dma(sdd))
> - msleep(10);
> + usleep_range(1, 11000);
>
> pm_runtime_get_sync(&sdd->pdev->dev);
>
> @@ -843,16 +842,14 @@ static struct s3c64xx_spi_csinfo
> *s3c64xx_get_slave_ctrldata(
>
> cs = kzalloc(sizeof(*cs), GFP_KERNEL);
> if (!cs) {
> - dev_err(&spi->dev, "could not allocate memory for controller"
> - " data\n");
> + dev_err(&spi->dev, "could not allocate memory for controller
> data\n");
> of_node_put(data_np);
> return ERR_PTR(-ENOMEM);
> }
>
> cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
> if (!gpio_is_valid(cs->line)) {
> - dev_err(&spi->dev, "chip select gpio is not specified or "
> - "invalid\n");
> + dev_err(&spi->dev, "chip select gpio is not specified or
> invalid\n");
> kfree(cs);
> of_node_put(data_np);
> return ERR_PTR(-EINVAL);
> @@ -1078,8 +1075,8 @@ static int s3c64xx_spi_get_dmares(
> if (!sdd->pdev->dev.of_node) {
> res = platform_get_resource(pdev, IORESOURCE_DMA, tx ? 0 : 1);
> if (!res) {
> - dev_err(&pdev->dev, "Unable to get SPI-%s dma "
> - "resource\n", chan_str);
> + dev_err(&pdev->dev, "Unable to get SPI-%s dma
> resource\n",
> + chan_str);
> return -ENXIO;
> }
> dma_data->dmach = res->start;
> @@ -1135,8 +1132,7 @@ static void s3c64xx_spi_dt_gpio_free(struct
> s3c64xx_spi_driver_data *sdd)
> gpio_free(sdd->gpios[idx]);
> }
>
> -static struct s3c64xx_spi_info * s3c64xx_spi_parse_dt(
> - struct device *dev)
> +static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
> {
> struct s3c64xx_spi_info *sci;
> u32 temp;
> @@ -1148,16 +1144,14 @@ static struct s3c64xx_spi_info * s3c64xx_spi_parse_dt(
> }
>
> if (of_property_read_u32(dev->of_node, "samsung,spi-src-clk", &temp)) {
> - dev_warn(dev, "spi bus clock parent not specified, using "
> - "clock at index 0 as parent\n");
> + dev_warn(dev, "spi bus clock parent not specified, using clock
> at index 0 as parent\n");
> sci->src_clk_nr = 0;
> } else {
> sci->src_clk_nr = temp;
> }
>
> if (of_property_read_u32(dev->of_node, "num-cs", &temp)) {
> - dev_warn(dev, "number of chip select lines not specified, "
> - "assuming 1 chip select line\n");
> + dev_warn(dev, "number of chip select lines not specified,
> assuming 1 chip select line\n");
> sci->num_cs = 1;
> } else {
> sci->num_cs = temp;
> @@ -1247,8 +1241,8 @@ static int __init s3c64xx_spi_probe(struct
> platform_device *pdev)
> if (pdev->dev.of_node) {
> ret = of_alias_get_id(pdev->dev.of_node, "spi");
>
Re: [PATCH v2] spi: s3c64xx: Use devm_clk_get() and devm_request_irq()
On Thu, 10 Jan 2013 11:04:21 +0900, Jingoo Han wrote: > Use devm_clk_get() and devm_request_irq() rather than clk_get() and > request_irq() to make cleanup paths more simple. > > Signed-off-by: Jingoo Han Applied, thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: spi-imx: Add MODULE_ALIAS()
On Mon, 7 Jan 2013 20:42:55 -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Add an entry for MODULE_ALIAS().
>
> Signed-off-by: Fabio Estevam
Applied, thanks.
g.
> ---
> drivers/spi/spi-imx.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 9049132..0befeeb 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -949,3 +949,4 @@ module_platform_driver(spi_imx_driver);
> MODULE_DESCRIPTION("SPI Master Controller driver");
> MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> --
> 1.7.9.5
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] spi: tegra: remove checks for valid speed
On Sat, 5 Jan 2013 00:17:15 +0530, Laxman Dewangan wrote:
> SPI core make sure that all transfer has proper speed set
> before calling low level spi transfer. Hence, it is not
> require to have check in spi driver.
>
> Remove the check for speed validity from transfer and use it directly.
>
> Signed-off-by: Laxman Dewangan
Applied, thanks.
g.
> ---
> drivers/spi/spi-tegra20-sflash.c | 14 +++---
> drivers/spi/spi-tegra20-slink.c |6 +++---
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/spi/spi-tegra20-sflash.c
> b/drivers/spi/spi-tegra20-sflash.c
> index 448a8cc..9a42c15 100644
> --- a/drivers/spi/spi-tegra20-sflash.c
> +++ b/drivers/spi/spi-tegra20-sflash.c
> @@ -269,9 +269,7 @@ static int tegra_sflash_start_transfer_one(struct
> spi_device *spi,
> u32 speed;
> unsigned long command;
>
> - speed = t->speed_hz ? t->speed_hz : spi->max_speed_hz;
> - if (!speed)
> - speed = tsd->spi_max_frequency;
> + speed = t->speed_hz;
> if (speed != tsd->cur_speed) {
> clk_set_rate(tsd->clk, speed);
> tsd->cur_speed = speed;
> @@ -319,6 +317,15 @@ static int tegra_sflash_start_transfer_one(struct
> spi_device *spi,
> return tegra_sflash_start_cpu_based_transfer(tsd, t);
> }
>
> +static int tegra_sflash_setup(struct spi_device *spi)
> +{
> + struct tegra_sflash_data *tsd = spi_master_get_devdata(spi->master);
> +
> + /* Set speed to the spi max fequency if spi device has not set */
> + spi->max_speed_hz = spi->max_speed_hz ? : tsd->spi_max_frequency;
> + return 0;
> +}
> +
> static int tegra_sflash_transfer_one_message(struct spi_master *master,
> struct spi_message *msg)
> {
> @@ -492,6 +499,7 @@ static int tegra_sflash_probe(struct platform_device
> *pdev)
>
> /* the spi->mode bits understood by this driver: */
> master->mode_bits = SPI_CPOL | SPI_CPHA;
> + master->setup = tegra_sflash_setup;
> master->transfer_one_message = tegra_sflash_transfer_one_message;
> master->num_chipselect = MAX_CHIP_SELECT;
> master->bus_num = -1;
> diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
> index 651167f..29039f1 100644
> --- a/drivers/spi/spi-tegra20-slink.c
> +++ b/drivers/spi/spi-tegra20-slink.c
> @@ -728,9 +728,7 @@ static int tegra_slink_start_transfer_one(struct
> spi_device *spi,
> unsigned long command2;
>
> bits_per_word = t->bits_per_word;
> - speed = t->speed_hz ? t->speed_hz : spi->max_speed_hz;
> - if (!speed)
> - speed = tspi->spi_max_frequency;
> + speed = t->speed_hz;
> if (speed != tspi->cur_speed) {
> clk_set_rate(tspi->clk, speed * 4);
> tspi->cur_speed = speed;
> @@ -841,6 +839,8 @@ static int tegra_slink_setup(struct spi_device *spi)
>
> BUG_ON(spi->chip_select >= MAX_CHIP_SELECT);
>
> + /* Set speed to the spi max fequency if spi device has not set */
> + spi->max_speed_hz = spi->max_speed_hz ? : tspi->spi_max_frequency;
> ret = pm_runtime_get_sync(tspi->dev);
> if (ret < 0) {
> dev_err(tspi->dev, "pm runtime failed, e = %d\n", ret);
> --
> 1.7.1.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] spi: make sure all transfer has proper speed set
On Sat, 5 Jan 2013 00:17:14 +0530, Laxman Dewangan wrote:
> When spi client does the spi transfer and if it does not set
> the speed for each transfer then set it as default
> of spi device in spi core before calling low level transfer.
>
> This will remove the extra check in low level driver for setting
> speed.
>
> Signed-off-by: Laxman Dewangan
Applied, thanks.
g.
> ---
> drivers/spi/spi.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 19ee901..9676a29 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1366,12 +1366,14 @@ static int __spi_async(struct spi_device *spi, struct
> spi_message *message)
> }
>
> /**
> - * Set transfer bits_per_word as spi device default if it is not
> - * set for this transfer.
> + * Set transfer bits_per_word and max speed as spi device default if
> + * it is not set for this transfer.
>*/
> list_for_each_entry(xfer, &message->transfers, transfer_list) {
> if (!xfer->bits_per_word)
> xfer->bits_per_word = spi->bits_per_word;
> + if (!xfer->speed_hz)
> + xfer->speed_hz = spi->max_speed_hz;
> }
>
> message->spi = spi;
> --
> 1.7.1.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] spi: spi-gpio: Add checks for the dt properties
On Tue, 22 Jan 2013 16:50:30 +0100, Maxime Ripard wrote: > On 09/01/2013 09:37, Maxime Ripard wrote: > > On 27/12/2012 22:54, Maxime Ripard wrote: > >> The bindings assumed that the gpios properties were always there, which > >> made the NO_TX and NO_RX mode not usable from device tree. Add extra > >> checks to make sure that the driver can work if either MOSI or MISO is > >> not used. > > > > Can you give me your Acked-by on this, or do you have any comments on this? > > Ping? Mark has applied it and it is now in my tree. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 6/6] spi/ath79: add shutdown handler
On Thu, 27 Dec 2012 10:42:29 +0100, Gabor Juhos wrote:
> The SPI controller of the AR7xxx/AR9xxx SoCs
> have a special mode which allows the SoC to
> directly read data from SPI flash chips. In
> this mode, the content of the SPI flash chip
> can be accessed via a memory mapped region.
>
> During early init time, the kernel expects
> that the flash chip is accessible through
> that memory region because it reads board
> specific values (e.g. MAC address, WiFi
> calibration data) from the flash on various
> boards.
>
> This is working if the kernel is loaded
> directly by the bootloader because that
> leaves the SPI controller in the special
> mode. However it is not working in a kexec'd
> kernel because the SPI driver does not restore
> the special mode during shutdown.
>
> The patch adds a shutdown handler to fix this
> issue.
>
> Signed-off-by: Gabor Juhos
> ---
> drivers/spi/spi-ath79.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
> index 842acd8..73e491e 100644
> --- a/drivers/spi/spi-ath79.c
> +++ b/drivers/spi/spi-ath79.c
> @@ -293,7 +293,7 @@ err_put_master:
> return ret;
> }
>
> -static int ath79_spi_remove(struct platform_device *pdev)
> +static void __ath79_spi_remove(struct platform_device *pdev)
> {
> struct ath79_spi *sp = platform_get_drvdata(pdev);
>
> @@ -304,13 +304,23 @@ static int ath79_spi_remove(struct platform_device
> *pdev)
> iounmap(sp->base);
> platform_set_drvdata(pdev, NULL);
> spi_master_put(sp->bitbang.master);
> +}
>
> +static int ath79_spi_remove(struct platform_device *pdev)
> +{
> + __ath79_spi_remove(pdev);
> return 0;
> }
>
> +static void ath79_spi_shutdown(struct platform_device *pdev)
> +{
> + __ath79_spi_remove(pdev);
> +}
Just call ath79_spi_remote(pdev) directly from ath79_spi_shutdown(). No
need for the extra hook and __ version of the original function.
g.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 5/6] spi/ath79: avoid multiple initialization of the SPI controller
On Thu, 27 Dec 2012 10:42:28 +0100, Gabor Juhos wrote:
> Currently we are initializing the SPI controller in
> the chip select line function, and that function is
> called once for each SPI device on the bus. If a
> board has multiple SPI devices, the controller will
> be initialized multiple times.
>
> Introduce ath79_spi_{en,dis}able helper functions,
> and call those from probe/response in order to avoid
> the mutliple initialization of the controller.
>
> Signed-off-by: Gabor Juhos
Applied, thanks.
g.
> ---
> drivers/spi/spi-ath79.c | 41 -
> 1 file changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
> index 19d539e..842acd8 100644
> --- a/drivers/spi/spi-ath79.c
> +++ b/drivers/spi/spi-ath79.c
> @@ -96,16 +96,8 @@ static void ath79_spi_chipselect(struct spi_device *spi,
> int is_active)
>
> }
>
> -static int ath79_spi_setup_cs(struct spi_device *spi)
> +static void ath79_spi_enable(struct ath79_spi *sp)
> {
> - struct ath79_spi *sp = ath79_spidev_to_sp(spi);
> - struct ath79_spi_controller_data *cdata;
> - int status;
> -
> - cdata = spi->controller_data;
> - if (spi->chip_select && !cdata)
> - return -EINVAL;
> -
> /* enable GPIO mode */
> ath79_spi_wr(sp, AR71XX_SPI_REG_FS, AR71XX_SPI_FS_GPIO);
>
> @@ -115,6 +107,24 @@ static int ath79_spi_setup_cs(struct spi_device *spi)
>
> /* TODO: setup speed? */
> ath79_spi_wr(sp, AR71XX_SPI_REG_CTRL, 0x43);
> +}
> +
> +static void ath79_spi_disable(struct ath79_spi *sp)
> +{
> + /* restore CTRL register */
> + ath79_spi_wr(sp, AR71XX_SPI_REG_CTRL, sp->reg_ctrl);
> + /* disable GPIO mode */
> + ath79_spi_wr(sp, AR71XX_SPI_REG_FS, 0);
> +}
> +
> +static int ath79_spi_setup_cs(struct spi_device *spi)
> +{
> + struct ath79_spi_controller_data *cdata;
> + int status;
> +
> + cdata = spi->controller_data;
> + if (spi->chip_select && !cdata)
> + return -EINVAL;
>
> status = 0;
> if (spi->chip_select) {
> @@ -135,17 +145,10 @@ static int ath79_spi_setup_cs(struct spi_device *spi)
>
> static void ath79_spi_cleanup_cs(struct spi_device *spi)
> {
> - struct ath79_spi *sp = ath79_spidev_to_sp(spi);
> -
> if (spi->chip_select) {
> struct ath79_spi_controller_data *cdata = spi->controller_data;
> gpio_free(cdata->gpio);
> }
> -
> - /* restore CTRL register */
> - ath79_spi_wr(sp, AR71XX_SPI_REG_CTRL, sp->reg_ctrl);
> - /* disable GPIO mode */
> - ath79_spi_wr(sp, AR71XX_SPI_REG_FS, 0);
> }
>
> static int ath79_spi_setup(struct spi_device *spi)
> @@ -268,12 +271,15 @@ static int ath79_spi_probe(struct platform_device *pdev)
> dev_dbg(&pdev->dev, "register read/write delay is %u nsecs\n",
> sp->rrw_delay);
>
> + ath79_spi_enable(sp);
> ret = spi_bitbang_start(&sp->bitbang);
> if (ret)
> - goto err_clk_disable;
> + goto err_disable;
>
> return 0;
>
> +err_disable:
> + ath79_spi_disable(sp);
> err_clk_disable:
> clk_disable(sp->clk);
> err_clk_put:
> @@ -292,6 +298,7 @@ static int ath79_spi_remove(struct platform_device *pdev)
> struct ath79_spi *sp = platform_get_drvdata(pdev);
>
> spi_bitbang_stop(&sp->bitbang);
> + ath79_spi_disable(sp);
> clk_disable(sp->clk);
> clk_put(sp->clk);
> iounmap(sp->base);
> --
> 1.7.10
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 4/6] spi/ath79: use gpio_request_one
On Thu, 27 Dec 2012 10:42:27 +0100, Gabor Juhos wrote:
> Use gpio_request_one() instead of multiple gpiolib calls.
>
> Signed-off-by: Gabor Juhos
Applied, thanks.
g.
> ---
> drivers/spi/spi-ath79.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
> index a725e62..19d539e 100644
> --- a/drivers/spi/spi-ath79.c
> +++ b/drivers/spi/spi-ath79.c
> @@ -100,6 +100,7 @@ static int ath79_spi_setup_cs(struct spi_device *spi)
> {
> struct ath79_spi *sp = ath79_spidev_to_sp(spi);
> struct ath79_spi_controller_data *cdata;
> + int status;
>
> cdata = spi->controller_data;
> if (spi->chip_select && !cdata)
> @@ -115,22 +116,21 @@ static int ath79_spi_setup_cs(struct spi_device *spi)
> /* TODO: setup speed? */
> ath79_spi_wr(sp, AR71XX_SPI_REG_CTRL, 0x43);
>
> + status = 0;
> if (spi->chip_select) {
> - int status = 0;
> + unsigned long flags;
>
> - status = gpio_request(cdata->gpio, dev_name(&spi->dev));
> - if (status)
> - return status;
> + flags = GPIOF_DIR_OUT;
> + if (spi->mode & SPI_CS_HIGH)
> + flags |= GPIOF_INIT_HIGH;
> + else
> + flags |= GPIOF_INIT_LOW;
>
> - status = gpio_direction_output(cdata->gpio,
> -spi->mode & SPI_CS_HIGH);
> - if (status) {
> - gpio_free(cdata->gpio);
> - return status;
> - }
> + status = gpio_request_one(cdata->gpio, flags,
> + dev_name(&spi->dev));
> }
>
> - return 0;
> + return status;
> }
>
> static void ath79_spi_cleanup_cs(struct spi_device *spi)
> --
> 1.7.10
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 3/6] spi/ath79: remove superfluous chip select code
On Thu, 27 Dec 2012 10:42:26 +0100, Gabor Juhos wrote:
> The spi_bitbang driver calls the chipselect function
> of the driver from spi_bitbang_setup in order to
> deselect the given SPI chip, so we don't have to
> initialize the CS line here.
>
> Signed-off-by: Gabor Juhos
Applied, thanks.
g.
> ---
> drivers/spi/spi-ath79.c |6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
> index d4b8e12..a725e62 100644
> --- a/drivers/spi/spi-ath79.c
> +++ b/drivers/spi/spi-ath79.c
> @@ -128,12 +128,6 @@ static int ath79_spi_setup_cs(struct spi_device *spi)
> gpio_free(cdata->gpio);
> return status;
> }
> - } else {
> - if (spi->mode & SPI_CS_HIGH)
> - sp->ioc_base |= AR71XX_SPI_IOC_CS0;
> - else
> - sp->ioc_base &= ~AR71XX_SPI_IOC_CS0;
> - ath79_spi_wr(sp, AR71XX_SPI_REG_IOC, sp->ioc_base);
> }
>
> return 0;
> --
> 1.7.10
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/6] spi/ath79: add missing HIGH->LOW SCK transition
On Thu, 27 Dec 2012 10:42:25 +0100, Gabor Juhos wrote: > The 'ath79_spi_txrx_mode0' function does not > set the SCK signal to LOW at the end of a word > transfer. This causes communications errors with > certain devices (e.g. the PCF2123 RTC chip). > > The patch ensures that the SCK signal will be LOW. > > Signed-off-by: Gabor Juhos Applied, thanks. g. > --- > drivers/spi/spi-ath79.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c > index e025282..d4b8e12 100644 > --- a/drivers/spi/spi-ath79.c > +++ b/drivers/spi/spi-ath79.c > @@ -200,6 +200,8 @@ static u32 ath79_spi_txrx_mode0(struct spi_device *spi, > unsigned nsecs, > ath79_spi_delay(sp, nsecs); > ath79_spi_wr(sp, AR71XX_SPI_REG_IOC, out | AR71XX_SPI_IOC_CLK); > ath79_spi_delay(sp, nsecs); > + if (bits == 1) > + ath79_spi_wr(sp, AR71XX_SPI_REG_IOC, out); > > word <<= 1; > } > -- > 1.7.10 > -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/6] spi/ath79: add delay between SCK changes
On Thu, 27 Dec 2012 10:42:24 +0100, Gabor Juhos wrote: > The driver uses the "as fast as it can" approach > to drive the SCK signal. However this does not > work with certain low speed SPI chips (e.g. the > PCF2123 RTC chip). > > The patch adds per-bit slowdowns in order to be > able to use the driver with such chips as well. > > Signed-off-by: Gabor Juhos I've applied this, but please take a second look to make sure you're not doing something unintended. The ndelay call will spin until it completes. If the current context is interrupted or scheduled out then it will still spin when it gets back. You may be wasting more time than is necessary. It would be better to check the wall time over a loop iteration. And if the delay required is large, then it should sleep. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
Morning-ish Andrew, On Tue, Feb 05, 2013 at 01:38:27PM +0100, Andrew Lunn wrote: > > And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y > > Maybe it makes sense to provide a patch to mvebu_defconfig to add > CONFIG_MTD_M25P80=y ? I thought this as well, then reconsidered when he said there was nothing on it. So it's not really needed to boot. I don't have a strong opinion on it though, so =y, =m, or =n. thx, Jason. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote: > You're assuming that cookies complete in order. That is not necessarily > true. Under what circumstances is that not true? -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH V2] mxs: spi: clear XFER_COUNT in ctrl0 field in DMA descriptor
On Wed, 26 Dec 2012 14:48:51 +0900, Juha Lumme wrote: > On MX23 the XFER_COUNT part in ctrl0 field in DMA descriptor was improperly > OR'd during the construction of DMA descriptor chain, instead of being > freshly set. > Because of that too many bytes were being expected from SPI during the last > DMA cycle. > This caused a timeout (SSP_TIMEOUT) to happen in the processing of the last > DMA descriptor, and thus reads and writes were failing. > This is a fix for the problem, by clearing XFER_COUNT bytes in ctrl0 before > setting the new XFER_COUNT for DMA descriptor. > > Cc: Marek Vasut > Cc: Fabio Estevam > Cc: Shawn Guo Applied, thanks. g. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote: > On Monday 04 February 2013, Linus Walleij wrote: > > So I think the above concerns are moot. The callback we can > > set on cookies is entirely optional, and it's even implemented by > > each DMA engine, and some may not even support it but require > > polling, and then it won't even be implemented by the driver. > > Just to ensure that everybody is talking about the same thing here: > Is it just the callback that is optional, or also the interrupt > coming from the hardware? If everyone implements stuff correctly, both. The callback most certainly is optional as things stand. The interrupt - that depends on the DMA engine. Some DMA engines you can't avoid it because you need to reprogram the hardware with the next+1 transfer upon completion of an existing transfer. Others may allow you to chain transfers in hardware. That's all up to how the DMA engine driver is implemented and how the hardware behaves. Now, there's another problem here: that is, people abuse the API. People don't pass DMA_CTRL_ACK | DMA_PREP_INTERRUPT into their operations by default. People like typing '0'. The intention of the "DMA_PREP_INTERRUPT" is significant here: it means "ask the hardware to send an interrupt upon completion of this transfer". Because soo many people like to type '0' instead in their DMA engine clients, it means that this flag is utterly useless today - you have to ignore it. So there's _no_ way for client drivers to actually tell the a DMA engine driver which _doesn't_ need to signal interrupts at the end of every transfer not to do so. So yes, the DMA engine API supports it. Whether the _implementations_ themselves do is very much hit and miss (and in reality is much more miss than hit.) -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] spi: sirf: use clk_prepare_enable and clk_disable_unprepare
On Wed, 26 Dec 2012 10:48:33 +0800, Barry Song wrote: > From: Barry Song > > Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare > calls as required by common clock framework. > > Signed-off-by: Barry Song Applied, thanks. g. > --- > drivers/spi/spi-sirf.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c > index e0f43a5..38a191c 100644 > --- a/drivers/spi/spi-sirf.c > +++ b/drivers/spi/spi-sirf.c > @@ -570,7 +570,7 @@ static int spi_sirfsoc_probe(struct platform_device *pdev) > ret = -EINVAL; > goto free_pin; > } > - clk_enable(sspi->clk); > + clk_prepare_enable(sspi->clk); > sspi->ctrl_freq = clk_get_rate(sspi->clk); > > init_completion(&sspi->done); > @@ -594,7 +594,7 @@ static int spi_sirfsoc_probe(struct platform_device *pdev) > return 0; > > free_clk: > - clk_disable(sspi->clk); > + clk_disable_unprepare(sspi->clk); > clk_put(sspi->clk); > free_pin: > pinctrl_put(sspi->p); > @@ -618,7 +618,7 @@ static int spi_sirfsoc_remove(struct platform_device > *pdev) > if (sspi->chipselect[i] > 0) > gpio_free(sspi->chipselect[i]); > } > - clk_disable(sspi->clk); > + clk_disable_unprepare(sspi->clk); > clk_put(sspi->clk); > pinctrl_put(sspi->p); > spi_master_put(master); > -- > 1.7.5.4 > > > > Member of the CSR plc group of companies. CSR plc registered in England and > Wales, registered number 4187346, registered office Churchill House, > Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > More information can be found at www.csr.com. Follow CSR on Twitter at > http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] spi: sirf: add support for new SiRFmarco SMP SoC
On Wed, 26 Dec 2012 10:48:34 +0800, Barry Song wrote:
> From: Barry Song
>
> the driver is also compatible with SiRFmarco except SiRFprimaII,
> so simply add "sirf,marco-spi" to OF match table.
>
> Signed-off-by: Barry Song
Applied, thanks.
g.
> ---
> drivers/spi/spi-sirf.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
> index 38a191c..09ca0e3 100644
> --- a/drivers/spi/spi-sirf.c
> +++ b/drivers/spi/spi-sirf.c
> @@ -659,6 +659,7 @@ static const struct dev_pm_ops spi_sirfsoc_pm_ops = {
>
> static const struct of_device_id spi_sirfsoc_of_match[] = {
> { .compatible = "sirf,prima2-spi", },
> + { .compatible = "sirf,marco-spi", },
> {}
> };
> MODULE_DEVICE_TABLE(of, sirfsoc_spi_of_match);
> --
> 1.7.5.4
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and
> Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at
> http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
> And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y Hi Ezequiel Maybe it makes sense to provide a patch to mvebu_defconfig to add CONFIG_MTD_M25P80=y ? Andrew -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On Tue, Feb 05, 2013 at 08:24:33AM -0300, Ezequiel Garcia wrote: > This patch adds an SPI master device node for Armada XP-GP board. > This master node is an SPI flash controller 'n25q128a13'. > > Since there is no 'partitions' node declared, one full sized > partition named as the device will be created. > > Cc: Gregory Clement > Cc: Thomas Petazzoni > Cc: Lior Amsalem > Signed-off-by: Ezequiel Garcia > --- > This patch depends on: > > 1. Gregory's patch for Armada XP GP board: > arm: mvebu: support for the new Armada XP development > board(DB-MV784MP-GP) > > 2. My previous patch for SPI on Armada 370/XP: > arm: mvebu: Add support for SPI controller in Armada 370/XP > > And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y > > arch/arm/boot/dts/armada-xp-gp.dts | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) Very nice, thanks for listing the dependencies. That makes things a lot easier on this end. thx, Jason. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.
Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Lior Amsalem
Signed-off-by: Ezequiel Garcia
---
This patch depends on:
1. Gregory's patch for Armada XP GP board:
arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
2. My previous patch for SPI on Armada 370/XP:
arm: mvebu: Add support for SPI controller in Armada 370/XP
And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y
arch/arm/boot/dts/armada-xp-gp.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 3eea531..1c8afe2 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -97,5 +97,17 @@
phy = <&phy3>;
phy-mode = "rgmii-id";
};
+
+ spi0: spi@d0010600 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <10800>;
+ };
+ };
};
};
--
1.7.8.6
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
