Re: [PATCH v6 01/16] spi/spi-atmel: fix probing failure after xfer-speed_hz set
On 7 March 2013 04:26, Wenyou Yang wenyou.y...@atmel.com wrote:
commit: 059b8ffeee5b427949872bb6ed5db5ae0788054e
cause the atmel spi probing failure.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Cc: spi-devel-general@lists.sourceforge.net
Cc: linux-ker...@vger.kernel.org
---
drivers/spi/spi-atmel.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 656d137..1eca815 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -846,9 +846,9 @@ static int atmel_spi_transfer(struct spi_device *spi,
struct spi_message *msg)
}
}
- /* FIXME implement these protocol options!! */
- if (xfer-speed_hz) {
- dev_dbg(spi-dev, no protocol options yet\n);
+ if (xfer-speed_hz spi-max_speed_hz) {
+ dev_dbg(spi-dev,
+ speed in transfer less than bus speed\n);
return -ENOPROTOOPT;
}
I sent a similar patch to spi-devl a while ago, which Grant said he applied.
https://patchwork.kernel.org/patch/2165301/
Can't find the patch in any upstream git tree so I guess Grant hasn't
pushed it yet.
regards
Joachim Eastwood
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v6 01/16] spi/spi-atmel: fix probing failure after xfer-speed_hz set
Hello. On 07-03-2013 7:26, Wenyou Yang wrote: commit: 059b8ffeee5b427949872bb6ed5db5ae0788054e Please also specify the summary line of that commit in parens (or however you like). cause the atmel spi probing failure. Signed-off-by: Wenyou Yang wenyou.y...@atmel.com Cc: spi-devel-general@lists.sourceforge.net Cc: linux-ker...@vger.kernel.org WBR, Sergei -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Reading many SPI words when CS is active
I need to read a SPI word of 80 bits length. I'm using the Overo EarthStorm, and based on the OMAP36XX specifications, I can only read a word between the range of 4-32 bits. My device is configured as SPI slave, when it receive the 80 bits word and read the RX buffer, it looks like the words are overwritten. Does anyone know what I have to do? The device which I'm receiving the SPI messages of, sends 5 clock cycles (SCLK) with 16 bits each one on the MISO when CS is low. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
RE: [PATCH v5 01/16] spi/spi-atmel: fix master-num_chipselect wrongly set.
-Original Message- From: Grant Likely [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: 2013年3月3日 7:16 To: Yang, Wenyou; linux-arm-ker...@lists.infradead.org Cc: Ferre, Nicolas; plagn...@jcrosoft.com; richard.gen...@gmail.com; Lin, JM; Yang, Wenyou; spi-devel-general@lists.sourceforge.net; linux-ker...@vger.kernel.org Subject: Re: [PATCH v5 01/16] spi/spi-atmel: fix master-num_chipselect wrongly set. On Tue, 26 Feb 2013 14:47:54 +0800, Wenyou Yang wenyou.y...@atmel.com wrote: if the spi property cs-gpios is set as below: cs-gpios = 0, pioC 11 0, 0, 0; the master-num_chipselect will wrongly be set to 0, and the spi fail to probe. Signed-off-by: Wenyou Yang wenyou.y...@atmel.com Cc: spi-devel-general@lists.sourceforge.net Cc: linux-ker...@vger.kernel.org I think I've got this bug fixed in the core spi code. Give it a couple of days and retest with linux-next. Hi Grant, Yes, in v3.9-rc1 this bug fixed, I retested on v3.9-rc1. But on spi/next git tree, it should to apply this patch. I sent the patches version 6, could you take a look them? Thanks a lot for your work. g. Best Regards, Wenyou Yang -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
RE: [PATCH v6 01/16] spi/spi-atmel: fix probing failure after xfer-speed_hz set
Hi Joachim,
-Original Message-
From: Joachim Eastwood [mailto:manab...@gmail.com]
Sent: 2013年3月7日 20:31
To: Yang, Wenyou
Cc: linux-arm-ker...@lists.infradead.org; grant.lik...@secretlab.ca; Ferre,
Nicolas; plagn...@jcrosoft.com; richard.gen...@gmail.com; Lin, JM;
spi-devel-general@lists.sourceforge.net; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v6 01/16] spi/spi-atmel: fix probing failure after
xfer-speed_hz set
On 7 March 2013 04:26, Wenyou Yang wenyou.y...@atmel.com wrote:
commit: 059b8ffeee5b427949872bb6ed5db5ae0788054e
cause the atmel spi probing failure.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Cc: spi-devel-general@lists.sourceforge.net
Cc: linux-ker...@vger.kernel.org
---
drivers/spi/spi-atmel.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 656d137..1eca815 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -846,9 +846,9 @@ static int atmel_spi_transfer(struct spi_device *spi,
struct spi_message *msg)
}
}
- /* FIXME implement these protocol options!! */
- if (xfer-speed_hz) {
- dev_dbg(spi-dev, no protocol options
yet\n);
+ if (xfer-speed_hz spi-max_speed_hz) {
+ dev_dbg(spi-dev,
+ speed in transfer less than bus
speed\n);
return -ENOPROTOOPT;
}
I sent a similar patch to spi-devl a while ago, which Grant said he applied.
https://patchwork.kernel.org/patch/2165301/
Can't find the patch in any upstream git tree so I guess Grant hasn't
pushed it yet.
Sorry, I didn't notice your patch before.
Furthermore, I made this patch based on your and Grant,s email.
I will drop this patch.
regards
Joachim Eastwood
Best Regards,
Wenyou Yang
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: add driver for BCM2835
On 03/05/2013 09:05 PM, Mark Brown wrote:
On Tue, Mar 05, 2013 at 07:49:02PM -0700, Stephen Warren wrote:
+static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+{
if (cs BCM2835_SPI_CS_DONE) { if (bs-len) { /* first interrupt
in a transfer */ /* fill the TX fifo with up to 16 bytes */
bcm2835_wr_fifo(bs, 16); } else { /* transfer complete */ /*
disable SPI interrupts */ cs = ~(BCM2835_SPI_CS_INTR |
BCM2835_SPI_CS_INTD); bcm2835_wr(bs, BCM2835_SPI_CS, cs);
/* wake up our bh */ complete(bs-done); } } else if (cs
BCM2835_SPI_CS_RXR) { /* read 12 bytes of data */
bcm2835_rd_fifo(bs, 12);
/* write up to 12 bytes */ bcm2835_wr_fifo(bs, 12); }
I'd feel happier if these were independent statements in case both
are asserted simultaneously.
I don't think it would be correct to make that change.
As background, CS_DONE is really TX FIFO EMPTY per the description
in the documentation.
When TA (Transfer Active) is set by bcm2835_spi_start_transfer(),
CS_DONE will immediately become set, and cause an interrupt. This will
cause the if/if (first interrupt in a transfer) case above to execute,
and the FIFO to be filled with up to 16 bytes. Once 12 of those bytes
have been transferred, CS_RXR (RX FIFO needs Reading) will be set
causing an interrupt, which will trigger the else case. At the end of
the message, we stop filling the TX FIFO, and so it eventually drains
completely, and CS_DONE fires again, causing the if/else (transfer
complete) path to be taken.
In the end-of-transfer case, it's possible CS_RXR may also be set,
since the last chunk of the transfer might just happen to be 12 bytes.
However, we don't want to execute the else cause to drain the FIFO,
since the CS_DONE case completes the completion, which then allows
bcm2835_spi_finish_transfer() to drain the FIFO based on the RXD (RX
FIFO has Data) field. Doing it in the IRQ handler too would confuse
things. I guess this SoC only has a CPU so it'd work out fine, but
it's probably best not to rely on it.
Also, I do wonder what happens if we process the CS_RXR interrupt too
late though, and CS_DONE gets set before we've transferred the entire
message simply because the FIFO drained unexpectedly.
With the current code, we'd simply write 16 bytes to the TX FIFO and
not read the RX FIFO, thus likely falling out of sync and overflowing
the TX FIFO next time around.
Equally, with your suggestion modification, we'd fill the TX FIFO with
16 bytes in the first if block, then again with 12 more bytes in the
second if block, and likely overflow the FIFO.
Perhaps the test order should be more like:
if (cs RXR) {
drain 12 bytes from RX FIFO
write up to 12 bytes to TX FIFO
} else if (cs DONE) {
if (len)
write up to 16 bytes to TX FIFO
else
finish transfer
}
And again the second block should be an else not an independent if, so
that if RXR was processed late, we don't end up writing first 12 then
16 bytes to the TX FIFO at once.
Does that all make sense?
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: add driver for BCM2835
On 03/05/2013 09:05 PM, Mark Brown wrote:
On Tue, Mar 05, 2013 at 07:49:02PM -0700, Stephen Warren wrote:
+switch (bpw) { +case 8: + break; +
default: +
dev_err(spi-dev, unsupported bits_per_word=%d\n, bpw); +
return -EINVAL; +}
Is there an assumption in the SPI core that bpw will never be 32? The
value is stored in a u8 in the controller and transfer structs, so
large values are physically possible. So if there is no such
assumption, then representing all of an SPI controller's supported BPW
in a mask/list would be a little unwieldy, so doing central checking
might not work well.
+if (!(spi-mode SPI_NO_CS) +
(spi-chip_select
spi-master-num_chipselect)) { +dev_err(spi-dev, +
invalid chipselect %u\n, + spi-chip_select); +
return
-EINVAL; ` + }
This seems like stuff the core should be able to do for you.
It looks like the core always validates the chip-select value, so I'll
remove that.
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] spi: slink-tegra20: move runtime pm calls to transfer_one_message
The prepare_transfer_hardware() is called in atomic context and
calling synchronous runtime pm calls can create scheduling deadlock.
Therefore, in place of calling runtime PM calls from prepare/unprepare
message transfer, calling this in transfer_one_message().
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
drivers/spi/spi-tegra20-slink.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index b8698b3..a829563 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -858,21 +858,6 @@ static int tegra_slink_setup(struct spi_device *spi)
return 0;
}
-static int tegra_slink_prepare_transfer(struct spi_master *master)
-{
- struct tegra_slink_data *tspi = spi_master_get_devdata(master);
-
- return pm_runtime_get_sync(tspi-dev);
-}
-
-static int tegra_slink_unprepare_transfer(struct spi_master *master)
-{
- struct tegra_slink_data *tspi = spi_master_get_devdata(master);
-
- pm_runtime_put(tspi-dev);
- return 0;
-}
-
static int tegra_slink_transfer_one_message(struct spi_master *master,
struct spi_message *msg)
{
@@ -885,6 +870,12 @@ static int tegra_slink_transfer_one_message(struct
spi_master *master,
msg-status = 0;
msg-actual_length = 0;
+ ret = pm_runtime_get_sync(tspi-dev);
+ if (ret 0) {
+ dev_err(tspi-dev, runtime get failed: %d\n, ret);
+ goto done;
+ }
+
single_xfer = list_is_singular(msg-transfers);
list_for_each_entry(xfer, msg-transfers, transfer_list) {
INIT_COMPLETION(tspi-xfer_completion);
@@ -921,6 +912,8 @@ static int tegra_slink_transfer_one_message(struct
spi_master *master,
exit:
tegra_slink_writel(tspi, tspi-def_command_reg, SLINK_COMMAND);
tegra_slink_writel(tspi, tspi-def_command2_reg, SLINK_COMMAND2);
+ pm_runtime_put(tspi-dev);
+done:
msg-status = ret;
spi_finalize_current_message(master);
return ret;
@@ -1148,9 +1141,7 @@ static int tegra_slink_probe(struct platform_device *pdev)
/* the spi-mode bits understood by this driver: */
master-mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
master-setup = tegra_slink_setup;
- master-prepare_transfer_hardware = tegra_slink_prepare_transfer;
master-transfer_one_message = tegra_slink_transfer_one_message;
- master-unprepare_transfer_hardware = tegra_slink_unprepare_transfer;
master-num_chipselect = MAX_CHIP_SELECT;
master-bus_num = -1;
--
1.7.1.1
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
