RE: [PATCH] SPI: SSP SPI Controller driver
On Thu, Nov 22, 2012 at 8:56 AM, Bi, Chao mailto:chao...@intel.com>> wrote: if (chip_info->enable_loopback) + chip->cr1 |= SSCR1_LBM; Who sets the enable_loopback? [Chao] 'enable_loopback' could be configured by SPI Protocol driver before it setup SPI controller. Generally it is not set by default because it's used for test and validation. Should it not then depend on (spi mode ) SPI_LOOP ? Or am I missing something. [Chao] I think it's up to protocol driver: if protocol driver choose to configure depend on (spi mode)SPI_LOOP, then it should set spi_device.controller_data to make 'enable_loopback' corresponds to (spi mode) SPI_LOOP, anyhow, SSP controller will always judge spi loop only through spi_device.controller_data which may be changed by protocol driver. in spi_intel_mid_ssp.c: /* protocol drivers may change the chip settings, so... */ /* if chip_info exists, use it */ chip_info = spi->controller_data; -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[RFC] spi: spi-fsl-spi: Making spi-fsl-spi partly platform-agnostic and adding a new mode for a new core
I am looking into writing a driver for a core running on sparc that is mostly
but not entirely compatible with the cpu mode of spi-fsl-spi. I am thinking of
what could be the best approach for realizing this. Any comments on a preferred
approach in this situation?
These are two different approaches I see to solve the situation without too much
code duplication:
Appproach A: Extend spi-fsl-spi and spi-fsl-lib to work outside of a FSL SOC
environtment and outside powerpc. This would require ifdefs for the driver to be
able to compile and work on sparc (or other platforms) - see patch draft at the
end. Everything that has to do with cpm and sysdev/fsl_soc.h needs to be within
ifdefs. Then the core in question could be added as another "mode" in the
spi-fsl-spi driver with core specific code embedded inside spi-fsl-spi.c just as
for the other existing modes.
Approach B: Put the general and cpu mode specific functions from spi-fsl-spi in
spi-fsl-lib or in a new separate c file and use these from both spi-fsl-spi and
a new driver for the core in question. Some ifdefs would still be needed, but
most things should be able to be handled with function pointers in such a
solution. The question is where to move the general and cpu mode functions (but
not the cpm related ones that could not compile)
Of course something in between A and B could be done as well, where all
functions stay in spi-fsl-spi.c but is exported so that they can be used with a
new driver. Then most ifdefs in fsl-spi-fsl would need to be in place for
compileability though.
Of course a third option that leaves spi-fsl-* alone but results in a lot of
code duplication is:
Approach C: Submit a totally separate driver for this core (with heavy copying
and pasting from spi-fsl-* as most of the functionality is the same as the cpu
mode parts of spi-fsl-spi). A lot of ugly code duplication. The only upside
compared to approach B is that there are mode register bits for this core that
conflicts with mode register bits in other mpc8xxx cores that are not currently
in use by the driver. If those would be used in the future in spi-fsl-spi, a
separate driver would not break for this core.
Core specific things that is needed in any approach (but can be mostly isolated
from spi-fsl-* in approach B):
- Add entries to the register struct for additional registers
- Adding core-specific chipselect discovery/handling code as there might be
built in chip select capabilities in the core.
- Add core-specific code to handle driver matching, bus numbering, getting clock
frequency, tx/rx_shifting, and dealing with possible word-length limitations.
Below follows a draft patch on how spi-fsl-spi with friends could be made
functioning in cpu mode outside of a FSL SOC environment. Approach A pointed out
above would add the new mode on top of this for the needed core specific
things. Note the ugly define on in/out_be16/32 that would need to be done in a
proper way in a real patch. I didn't want to clutter the patch below with that
now instead showing the ifdefs clearly.
Cheers,
Andreas Larsson
---
drivers/spi/Kconfig |4 ++--
drivers/spi/spi-fsl-lib.c | 10 ++
drivers/spi/spi-fsl-lib.h |8
drivers/spi/spi-fsl-spi.c | 32
4 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5b017af..8fbd698 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -218,11 +218,11 @@ config SPI_MPC512x_PSC
config SPI_FSL_LIB
tristate
- depends on FSL_SOC
+ depends on OF
config SPI_FSL_SPI
bool "Freescale SPI controller"
- depends on FSL_SOC
+ depends on OF
select SPI_FSL_LIB
help
This enables using the Freescale SPI controllers in master mode.
diff --git a/drivers/spi/spi-fsl-lib.c b/drivers/spi/spi-fsl-lib.c
index 1503574..0c9021d 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 __devinit 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 __devinit 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;
Re: [PATCH] SPI: SSP SPI Controller driver
> Thats what I was trying to understand. > > If I am not wrong the latency is time related. > Why only some platforms / modes need it also the value is not speed > dependent. Because the problem was fixed in the later devices. > Also the spi core today doesnt have slave mode support thats a > different discussion altogether may be we can leave it for now. I'd rather we kept the support in the driver ready for that. Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Ouverture de la vente privée Kickers : jusquà moins 50pourcent
Pour voir le message, veuillez utiliser un lecteur de mail compatible HTML Lien miroir : http://m10-fr.com/mc10_m/YT0xMyZiPTI1NDkwJmM9NDgzNjEyJmQ9MjAxMi0xMS0yMiAxMjowMDowMSZlPTEmaD0yNTQ4OCZmPTI1NDkwJmc9MjU0OTA= Lien de désinscription : http://m10-fr.com/mc10_unsub/YT0xMyZiPTI1NDkwJmM9NDgzNjEyJmQ9MjAxMi0xMS0yMiAxMjowMDowMSZlPTEmaD0yNTQ4OCZmPTI1NDkwJmc9MjU0OTA= -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 1/2] spi: sh-hspi: Improve performance
The driver attempts to read the recieved data immediately after
writing to the transmit buffer. If no data is available, the driver
currently waits 20ms until trying again. Since the hardware needs
to shift out the transmitted data, the first poll always fails,
leading to 20ms delay between bytes.
This patch reduces the polling interval to 1us, and also reduces
the timeout to 10ms.
Signed-off-by: Phil Edworthy
---
drivers/spi/spi-sh-hspi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-sh-hspi.c b/drivers/spi/spi-sh-hspi.c
index 934138c..0ca18c8 100644
--- a/drivers/spi/spi-sh-hspi.c
+++ b/drivers/spi/spi-sh-hspi.c
@@ -73,13 +73,13 @@ static u32 hspi_read(struct hspi_priv *hspi, int reg)
*/
static int hspi_status_check_timeout(struct hspi_priv *hspi, u32 mask, u32 val)
{
- int t = 256;
+ int t = 1; /* 10ms max timeout */
while (t--) {
if ((mask & hspi_read(hspi, SPSR)) == val)
return 0;
- msleep(20);
+ udelay(1);
}
dev_err(hspi->dev, "timeout\n");
--
1.7.5.4
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/2] spi: sh-hspi: add CS manual control support
The current HSPI driver used automatic CS control, leading to CS
active for each byte transmitted. This patch changes the driver
to manual CS control, and ensures CS is active thoughout a whole
message. Additionally, it uses the cs_change field to determine
if CS is disabled between transfers in the message.
Signed-off-by: Phil Edworthy
---
drivers/spi/spi-sh-hspi.c | 43 +--
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-sh-hspi.c b/drivers/spi/spi-sh-hspi.c
index 0ca18c8..592e236 100644
--- a/drivers/spi/spi-sh-hspi.c
+++ b/drivers/spi/spi-sh-hspi.c
@@ -68,6 +68,16 @@ static u32 hspi_read(struct hspi_priv *hspi, int reg)
return ioread32(hspi->addr + reg);
}
+static void hspi_bit_set(struct hspi_priv *hspi, int reg, u32 mask, u32 set)
+{
+ u32 val = hspi_read(hspi, reg);
+
+ val &= ~mask;
+ val |= set & mask;
+
+ hspi_write(hspi, reg, val);
+}
+
/*
* transfer function
*/
@@ -105,6 +115,13 @@ static int hspi_unprepare_transfer(struct spi_master
*master)
return 0;
}
+#define hspi_hw_cs_enable(hspi)hspi_hw_cs_ctrl(hspi, 0)
+#define hspi_hw_cs_disable(hspi) hspi_hw_cs_ctrl(hspi, 1)
+static void hspi_hw_cs_ctrl(struct hspi_priv *hspi, int hi)
+{
+ hspi_bit_set(hspi, SPSCR, (1 << 6), (hi) << 6);
+}
+
static void hspi_hw_setup(struct hspi_priv *hspi,
struct spi_message *msg,
struct spi_transfer *t)
@@ -155,7 +172,7 @@ static void hspi_hw_setup(struct hspi_priv *hspi,
hspi_write(hspi, SPCR, spcr);
hspi_write(hspi, SPSR, 0x0);
- hspi_write(hspi, SPSCR, 0x1); /* master mode */
+ hspi_write(hspi, SPSCR, 0x21); /* master mode / CS control */
}
static int hspi_transfer_one_message(struct spi_master *master,
@@ -166,12 +183,21 @@ static int hspi_transfer_one_message(struct spi_master
*master,
u32 tx;
u32 rx;
int ret, i;
+ unsigned int cs_change;
+ const int nsecs = 50;
dev_dbg(hspi->dev, "%s\n", __func__);
+ cs_change = 1;
ret = 0;
list_for_each_entry(t, &msg->transfers, transfer_list) {
- hspi_hw_setup(hspi, msg, t);
+
+ if (cs_change) {
+ hspi_hw_setup(hspi, msg, t);
+ hspi_hw_cs_enable(hspi);
+ ndelay(nsecs);
+ }
+ cs_change = t->cs_change;
for (i = 0; i < t->len; i++) {
@@ -198,9 +224,22 @@ static int hspi_transfer_one_message(struct spi_master
*master,
}
msg->actual_length += t->len;
+
+ if (t->delay_usecs)
+ udelay(t->delay_usecs);
+
+ if (cs_change) {
+ ndelay(nsecs);
+ hspi_hw_cs_disable(hspi);
+ ndelay(nsecs);
+ }
}
msg->status = ret;
+ if (!cs_change) {
+ ndelay(nsecs);
+ hspi_hw_cs_disable(hspi);
+ }
spi_finalize_current_message(master);
return ret;
--
1.7.5.4
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
