Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
Hello Lubomir, Am 01.06.2013 18:44, schrieb Lubomir Popov: New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older OMAPs and derivatives as well. The only anticipated exception would be the OMAP2420, which shall require driver modification. - Rewritten i2c_read to operate correctly with all types of chips (old function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try to identify unconfigured bus. - Status functions now read irqstatus_raw as per TRM guidelines (except for OMAP243X and OMAP34XX). - Driver now supports up to I2C5 (OMAP5). Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- V5 changes: - Replaced some printf() with puts(). - Minor formatting touches, checkpatch-clean. V4 changes: - New i2c_probe is built unconditionally, old code is removed. CONFIG_I2C_PROBE_WRITE is no longer needed. - Added a small delay to work around breakage in AM335X SPL. - Some whitespace and general formatting cleanup. V3 changes: - Removed old functions and conditional compilation. New functions are now built unconditionally for all SoCs using this driver. The only chip that should break is the OMAP2420 dinosaur. - Interrupts are enabled for OMAP243X and OMAP34XX only (where we don't have an irqstatus_raw register). V2 changes: - Probe tries to identify misconfigured pads as well. - Status is retrieved from irqstatus_raw rather than from stat. - Some minor style format changes. drivers/i2c/omap24xx_i2c.c | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Just one comment: Your patch has 9 checkpatch warnings which are all lines (printf strings) over 80 chars ... some with lines 110 characters ... I know, tom gave you a OK for this ... I am also unhappy with splitting a printf-string over 2 or more lines ... but we have this 80 characters rule ... Wolfgang, what do you think? Should we loosen this rule for printf-strings? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot ERROR cannot umount.
Hi mind, On Sat, 1 Jun 2013 12:01:44 +0530, mind entropy mindentr...@gmail.com wrote: Hi, I am setting up a nfs boot and I am getting a ***ERROR: Cannot umount. How can I fix this? See ./README in the U-Boot source code. Thanks, Gautam. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Hello Piotr,
On 05/31/2013 02:26 PM, Piotr Wilczek wrote:
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
void *dst;
unsigned long len;
@@ -60,7 +65,14 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
puts(Error: malloc in gunzip failed!\n);
return NULL;
}
- if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) !=
0) {
+
+ bmp = dst;
+
+ /* align to 32-bit-aligned-address + 2 */
+ if ((unsigned int)bmp % 0x04 != 0x02)
+ bmp = (bmp_image_t *)(((unsigned int)dst + 0x02) ~0x01);
This is wrong. Suppose that bmp % 4 == 3, then (dst + 2) % 4 == 1,
and thus ((dst + 2) ~1) % 4 == 0, which is not an aligned+2 address.
+
+ if (gunzip(bmp, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) !=
0) {
free(dst);
return NULL;
}
@@ -68,8 +80,6 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
puts(Image could be truncated
(increase
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
--
Regards,
Nikita.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
Hello Lubomir, Am 01.06.2013 18:44, schrieb Lubomir Popov: New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older OMAPs and derivatives as well. The only anticipated exception would be the OMAP2420, which shall require driver modification. - Rewritten i2c_read to operate correctly with all types of chips (old function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try to identify unconfigured bus. - Status functions now read irqstatus_raw as per TRM guidelines (except for OMAP243X and OMAP34XX). - Driver now supports up to I2C5 (OMAP5). Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- V5 changes: - Replaced some printf() with puts(). - Minor formatting touches, checkpatch-clean. V4 changes: - New i2c_probe is built unconditionally, old code is removed. CONFIG_I2C_PROBE_WRITE is no longer needed. - Added a small delay to work around breakage in AM335X SPL. - Some whitespace and general formatting cleanup. V3 changes: - Removed old functions and conditional compilation. New functions are now built unconditionally for all SoCs using this driver. The only chip that should break is the OMAP2420 dinosaur. - Interrupts are enabled for OMAP243X and OMAP34XX only (where we don't have an irqstatus_raw register). V2 changes: - Probe tries to identify misconfigured pads as well. - Status is retrieved from irqstatus_raw rather than from stat. - Some minor style format changes. drivers/i2c/omap24xx_i2c.c | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Many thanks for testing, to Tom as well (he did it on the Beagleboards, but for one of the older versions, V3 I believe, right?). When it comes to versions, I see that V1 and V2 are still listed in patchwork, probably because of slightly different wording of the subject: http://patchwork.ozlabs.org/patch/233823/ http://patchwork.ozlabs.org/patch/246204/ Could you or Tom clean this up, please? Thanks. Just one comment: Your patch has 9 checkpatch warnings which are all lines (printf strings) over 80 chars ... some with lines 110 characters ... I know, tom gave you a OK for this ... I am also unhappy with splitting a printf-string over 2 or more lines ... but we have this 80 characters rule ... Wolfgang, what do you think? Should we loosen this rule for printf-strings? Yes, I had the long strings splitted in the older versions, but then unrolled them back as per Tom's recommendation. IMHO, grep-ability is worth breaking this particular rule... But perhaps only for pure strings w/o format placeholders? I mean, strings could be splitted at the format parameters of printf/sprintf arguments. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree
Hi Stephen, On 06/02/2013 01:24 AM, Stephen Warren wrote: On 05/14/2013 12:02 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This can be useful to force bootcmd to execute as soon as U-Boot has started. My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property bootcmd set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts. Jerry, does this patch look OK, or do you have comments on it? Thanks. I'm good with the patch. Acked-by: Gerald Van Baren vanba...@cideas.com Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
On Sun, Jun 02, 2013 at 07:20:50AM +0200, Heiko Schocher wrote: Hello Lubomir, Am 01.06.2013 18:44, schrieb Lubomir Popov: New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older OMAPs and derivatives as well. The only anticipated exception would be the OMAP2420, which shall require driver modification. - Rewritten i2c_read to operate correctly with all types of chips (old function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try to identify unconfigured bus. - Status functions now read irqstatus_raw as per TRM guidelines (except for OMAP243X and OMAP34XX). - Driver now supports up to I2C5 (OMAP5). Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- V5 changes: - Replaced some printf() with puts(). - Minor formatting touches, checkpatch-clean. V4 changes: - New i2c_probe is built unconditionally, old code is removed. CONFIG_I2C_PROBE_WRITE is no longer needed. - Added a small delay to work around breakage in AM335X SPL. - Some whitespace and general formatting cleanup. V3 changes: - Removed old functions and conditional compilation. New functions are now built unconditionally for all SoCs using this driver. The only chip that should break is the OMAP2420 dinosaur. - Interrupts are enabled for OMAP243X and OMAP34XX only (where we don't have an irqstatus_raw register). V2 changes: - Probe tries to identify misconfigured pads as well. - Status is retrieved from irqstatus_raw rather than from stat. - Some minor style format changes. drivers/i2c/omap24xx_i2c.c | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Just one comment: Your patch has 9 checkpatch warnings which are all lines (printf strings) over 80 chars ... some with lines 110 characters ... I know, tom gave you a OK for this ... I am also unhappy with splitting a printf-string over 2 or more lines ... but we have this 80 characters rule ... Wolfgang, what do you think? Should we loosen this rule for printf-strings? We have loosened the rule for printf strings already, in order to make it easier for tracking down error messages. However, checkpatch needs tweaking at times for our print functions vs kernel print functions. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree
On 05/14/2013 12:02 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This can be useful to force bootcmd to execute as soon as U-Boot has started. My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property bootcmd set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts. Jerry, does this patch look OK, or do you have comments on it? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V5] spi: Add support for preamble bytes
On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #defineSPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #defineSPI_3WIRE 0x10/* SI/SO signals shared */ #defineSPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec I think this 0xec is a value of rx_data what does it indicates and does this value specific to hw? -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V5] spi: exynos: Support SPI_PREAMBLE mode
Hi,
I know this has been reviewed multiples time, but I have few questions on it.
I think this preamble is one of spi mode characteristic, if so does it
specific to a hw?
On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skipping all data before and
including the preamble. The client will receive only data bytes after
the preamble.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Remove preamable_count variable which is not really needed
- Fix checkpatch warning (multiple assignments)
Changes in V3:
- Modified the if logic in spi_rx_tx function
- Added blank lines as suggested by Minkyu Kang.
- Removed in_bytes check in while loop.
- Added a error check.
Changes in V4:
- Corrected a if condition.
Changes in V5:
- In commit message header changed EXYNOS: SPI: to spi:exynos.
drivers/spi/exynos_spi.c | 69 +++--
1 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 607e1cd..01378d0 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -51,6 +51,7 @@ struct exynos_spi_slave {
unsigned int mode;
enum periph_id periph_id; /* Peripheral ID for this device */
unsigned int fifo_size;
+ int skip_preamble;
};
static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -105,6 +106,8 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
unsigned int cs,
else
spi_slave-fifo_size = 256;
+ spi_slave-skip_preamble = 0;
+
spi_slave-freq = bus-frequency;
if (max_hz)
spi_slave-freq = min(max_hz, spi_slave-freq);
@@ -217,17 +220,23 @@ static void spi_request_bytes(struct exynos_spi *regs,
int count)
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
-static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
- void **dinp, void const **doutp)
+static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
+ void **dinp, void const **doutp, unsigned long flags)
{
struct exynos_spi *regs = spi_slave-regs;
uchar *rxp = *dinp;
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
+ int toread;
+ unsigned start = get_timer(0);
+ int stopping;
out_bytes = in_bytes = todo;
+ stopping = spi_slave-skip_preamble (flags SPI_XFER_END)
+ !(spi_slave-mode SPI_SLAVE);
+
/*
* If there's something to send, do a software reset and set a
* transaction size.
@@ -238,6 +247,8 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
* Bytes are transmitted/received in pairs. Wait to receive all the
* data because then transmission will be done as well.
*/
+ toread = in_bytes;
+
while (in_bytes) {
int temp;
@@ -248,15 +259,43 @@ static void spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
writel(temp, regs-tx_data);
out_bytes--;
}
- if (rx_lvl 0 in_bytes) {
+ if (rx_lvl 0) {
temp = readl(regs-rx_data);
- if (rxp)
- *rxp++ = temp;
- in_bytes--;
+ if (spi_slave-skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave-skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
+ }
+ toread--;
+ } else if (!toread) {
+ /*
+* We have run out of input data, but haven't read
+* enough bytes after the preamble yet. Read some
more,
+* and make sure that we transmit dummy bytes too, to
+* keep things going.
+*/
+ assert(!out_bytes);
+ out_bytes = in_bytes;
+ toread = in_bytes;
+ txp = NULL;
+
Re: [U-Boot] [PATCH 1/2 V5] spi: Add support for preamble bytes
Hi, On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki jagannadh.t...@gmail.comwrote: On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #defineSPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #defineSPI_3WIRE 0x10/* SI/SO signals shared */ #defineSPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec I think this 0xec is a value of rx_data what does it indicates and does this value specific to hw? We have a later change which generalises this using the device tree, but it is dependent on various other patches and adjusts the generic SPI interface. If we can get this one in then I'm sure Vadim will supply a new patch for consideration. -- Thanks, Jagan. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V5] spi: Add support for preamble bytes
On Sun, Jun 2, 2013 at 11:25 PM, Simon Glass s...@chromium.org wrote: Hi, On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki jagannadh.t...@gmail.com wrote: On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #defineSPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #defineSPI_3WIRE 0x10/* SI/SO signals shared */ #defineSPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec I think this 0xec is a value of rx_data what does it indicates and does this value specific to hw? We have a later change which generalises this using the device tree, but it is dependent on various other patches and adjusts the generic SPI interface. If we can get this one in then I'm sure Vadim will supply a new patch for consideration. Means this value is specific to exynos is it? -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V5] spi: exynos: Support SPI_PREAMBLE mode
Hi,
On Sun, Jun 2, 2013 at 10:41 AM, Jagan Teki jagannadh.t...@gmail.comwrote:
Hi,
I know this has been reviewed multiples time, but I have few questions on
it.
I think this preamble is one of spi mode characteristic, if so does it
specific to a hw?
On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skipping all data before and
including the preamble. The client will receive only data bytes after
the preamble.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Remove preamable_count variable which is not really needed
- Fix checkpatch warning (multiple assignments)
Changes in V3:
- Modified the if logic in spi_rx_tx function
- Added blank lines as suggested by Minkyu Kang.
- Removed in_bytes check in while loop.
- Added a error check.
Changes in V4:
- Corrected a if condition.
Changes in V5:
- In commit message header changed EXYNOS: SPI: to spi:exynos.
drivers/spi/exynos_spi.c | 69
+++--
1 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 607e1cd..01378d0 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -51,6 +51,7 @@ struct exynos_spi_slave {
unsigned int mode;
enum periph_id periph_id; /* Peripheral ID for this device
*/
unsigned int fifo_size;
+ int skip_preamble;
};
static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -105,6 +106,8 @@ struct spi_slave *spi_setup_slave(unsigned int
busnum, unsigned int cs,
else
spi_slave-fifo_size = 256;
+ spi_slave-skip_preamble = 0;
+
spi_slave-freq = bus-frequency;
if (max_hz)
spi_slave-freq = min(max_hz, spi_slave-freq);
@@ -217,17 +220,23 @@ static void spi_request_bytes(struct exynos_spi
*regs, int count)
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
-static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
- void **dinp, void const **doutp)
+static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
+ void **dinp, void const **doutp, unsigned long
flags)
{
struct exynos_spi *regs = spi_slave-regs;
uchar *rxp = *dinp;
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
+ int toread;
+ unsigned start = get_timer(0);
+ int stopping;
out_bytes = in_bytes = todo;
+ stopping = spi_slave-skip_preamble (flags SPI_XFER_END)
+ !(spi_slave-mode SPI_SLAVE);
+
/*
* If there's something to send, do a software reset and set a
* transaction size.
@@ -238,6 +247,8 @@ static void spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
* Bytes are transmitted/received in pairs. Wait to receive all
the
* data because then transmission will be done as well.
*/
+ toread = in_bytes;
+
while (in_bytes) {
int temp;
@@ -248,15 +259,43 @@ static void spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
writel(temp, regs-tx_data);
out_bytes--;
}
- if (rx_lvl 0 in_bytes) {
+ if (rx_lvl 0) {
temp = readl(regs-rx_data);
- if (rxp)
- *rxp++ = temp;
- in_bytes--;
+ if (spi_slave-skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave-skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
+ }
+ toread--;
+ } else if (!toread) {
+ /*
+* We have run out of input data, but haven't
read
+* enough bytes after the preamble yet. Read
some more,
+* and make sure that we transmit dummy bytes
too, to
+* keep things going.
+
Re: [U-Boot] [PATCH 1/2 V5] spi: Add support for preamble bytes
Hi Jagan, On Sun, Jun 2, 2013 at 11:00 AM, Jagan Teki jagannadh.t...@gmail.comwrote: On Sun, Jun 2, 2013 at 11:25 PM, Simon Glass s...@chromium.org wrote: Hi, On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki jagannadh.t...@gmail.com wrote: On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #defineSPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #defineSPI_3WIRE 0x10/* SI/SO signals shared */ #defineSPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec I think this 0xec is a value of rx_data what does it indicates and does this value specific to hw? We have a later change which generalises this using the device tree, but it is dependent on various other patches and adjusts the generic SPI interface. If we can get this one in then I'm sure Vadim will supply a new patch for consideration. Means this value is specific to exynos is it? Yes, it is actually specific to snow, a particular board. We are working on generalising this using device tree, and moving this logic to the generic spi code, but these patches will come later, and sit on top of this one. These patches have now been outstanding on the list for a very long time, and have been thoroughly reviewed and tested. -- Thanks, Jagan. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] spi: exynos: Support word transfers
On Thu, May 30, 2013 at 11:22 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Since SPI register access is so expensive, it is worth transferring data
a word at a time if we can. This complicates the driver unfortunately.
Use the byte-swapping feature to avoid having to convert to/from big
endian in software.
This change increases speed from about 2MB/s to about 4.5MB/s.
Based on [PATCH V2] spi: exynos: Minimise access to SPI FIFO level
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Rebased on [PATCH V2] spi: exynos: Minimise access to SPI FIFO level
arch/arm/include/asm/arch-exynos/spi.h | 11 -
drivers/spi/exynos_spi.c | 79
++--
2 files changed, 74 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/spi.h
b/arch/arm/include/asm/arch-exynos/spi.h
index 7cab1e9..e67ad27 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -34,7 +34,7 @@ struct exynos_spi {
unsigned intrx_data;/* 0x1c */
unsigned intpkt_cnt;/* 0x20 */
unsigned char reserved2[4];
- unsigned char reserved3[4];
+ unsigned intswap_cfg; /* 0x28 */
unsigned intfb_clk; /* 0x2c */
unsigned char padding[0xffd0];
};
@@ -74,5 +74,14 @@ struct exynos_spi {
/* Packet Count */
#define SPI_PACKET_CNT_EN (1 16)
+/* Swap config */
+#define SPI_TX_SWAP_EN (1 0)
+#define SPI_TX_BYTE_SWAP (1 2)
+#define SPI_TX_HWORD_SWAP (1 3)
+#define SPI_TX_BYTE_SWAP (1 2)
+#define SPI_RX_SWAP_EN (1 4)
+#define SPI_RX_BYTE_SWAP (1 6)
+#define SPI_RX_HWORD_SWAP (1 7)
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index bcca3d6..4dda23b 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -216,12 +216,29 @@ static void spi_get_fifo_levels(struct exynos_spi *regs,
*
* @param regs SPI peripheral registers
* @param countNumber of bytes to transfer
+ * @param step Number of bytes to transfer in each packet (1 or 4)
*/
-static void spi_request_bytes(struct exynos_spi *regs, int count)
+static void spi_request_bytes(struct exynos_spi *regs, int count, int step)
{
+ /* For word address we need to swap bytes */
+ if (step == 4) {
+ setbits_le32(regs-mode_cfg,
+SPI_MODE_CH_WIDTH_WORD |
SPI_MODE_BUS_WIDTH_WORD);
+ count /= 4;
+ setbits_le32(regs-swap_cfg, SPI_TX_SWAP_EN | SPI_RX_SWAP_EN
|
+ SPI_TX_BYTE_SWAP | SPI_RX_BYTE_SWAP |
+ SPI_TX_HWORD_SWAP | SPI_RX_HWORD_SWAP);
+ } else {
+ /* Select byte access and clear the swap configuration */
+ clrbits_le32(regs-mode_cfg,
+SPI_MODE_CH_WIDTH_WORD |
SPI_MODE_BUS_WIDTH_WORD);
+ writel(0, regs-swap_cfg);
+ }
+
assert(count count (1 16));
setbits_le32(regs-ch_cfg, SPI_CH_RST);
clrbits_le32(regs-ch_cfg, SPI_CH_RST);
+
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
@@ -236,6 +253,7 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
int toread;
unsigned start = get_timer(0);
int stopping;
+ int step;
out_bytes = in_bytes = todo;
@@ -243,10 +261,19 @@ static int spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
!(spi_slave-mode SPI_SLAVE);
/*
+* Try to transfer words if we can. This helps read performance at
+* SPI clock speeds above about 20MHz.
+*/
+ step = 1;
+ if (!((todo | (uintptr_t)rxp | (uintptr_t)txp) 3)
+ !spi_slave-skip_preamble)
+ step = 4;
+
+ /*
* If there's something to send, do a software reset and set a
* transaction size.
*/
- spi_request_bytes(regs, todo);
+ spi_request_bytes(regs, todo, step);
/*
* Bytes are transmitted/received in pairs. Wait to receive all the
@@ -259,14 +286,26 @@ static int spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, rx_lvl, tx_lvl);
+
+ /*
+* Don't completely fill the txfifo, since we don't want our
+* rxfifo to overflow, and it may already contain data.
+*/
while (tx_lvl spi_slave-fifo_size/2 out_bytes) {
- temp = txp ? *txp++ : 0xff;
+ if (!txp)
+
Re: [U-Boot] [U-Boot,1/2,V5] spi: Add support for preamble bytes
On 29-05-2013 01:40, Rajeshwari Shinde wrote: A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #define SPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #define SPI_3WIRE 0x10/* SI/SO signals shared */ #define SPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec + /*--- * Representation of a SPI slave, i.e. what we're communicating with. * Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2, V5] spi: exynos: Support SPI_PREAMBLE mode
On 29-05-2013 01:40, Rajeshwari Shinde wrote:
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skipping all data before and
including the preamble. The client will receive only data bytes after
the preamble.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Remove preamable_count variable which is not really needed
- Fix checkpatch warning (multiple assignments)
Changes in V3:
- Modified the if logic in spi_rx_tx function
- Added blank lines as suggested by Minkyu Kang.
- Removed in_bytes check in while loop.
- Added a error check.
Changes in V4:
- Corrected a if condition.
Changes in V5:
- In commit message header changed EXYNOS: SPI: to spi:exynos.
drivers/spi/exynos_spi.c | 69 +++--
1 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 607e1cd..01378d0 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -51,6 +51,7 @@ struct exynos_spi_slave {
unsigned int mode;
enum periph_id periph_id; /* Peripheral ID for this device */
unsigned int fifo_size;
+ int skip_preamble;
};
static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -105,6 +106,8 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
unsigned int cs,
else
spi_slave-fifo_size = 256;
+ spi_slave-skip_preamble = 0;
+
spi_slave-freq = bus-frequency;
if (max_hz)
spi_slave-freq = min(max_hz, spi_slave-freq);
@@ -217,17 +220,23 @@ static void spi_request_bytes(struct exynos_spi *regs,
int count)
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
-static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
- void **dinp, void const **doutp)
+static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
+ void **dinp, void const **doutp, unsigned long flags)
{
struct exynos_spi *regs = spi_slave-regs;
uchar *rxp = *dinp;
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
+ int toread;
+ unsigned start = get_timer(0);
+ int stopping;
out_bytes = in_bytes = todo;
+ stopping = spi_slave-skip_preamble (flags SPI_XFER_END)
+ !(spi_slave-mode SPI_SLAVE);
+
/*
* If there's something to send, do a software reset and set a
* transaction size.
@@ -238,6 +247,8 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
* Bytes are transmitted/received in pairs. Wait to receive all the
* data because then transmission will be done as well.
*/
+ toread = in_bytes;
+
while (in_bytes) {
int temp;
@@ -248,15 +259,43 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
writel(temp, regs-tx_data);
out_bytes--;
}
- if (rx_lvl 0 in_bytes) {
+ if (rx_lvl 0) {
temp = readl(regs-rx_data);
- if (rxp)
- *rxp++ = temp;
- in_bytes--;
+ if (spi_slave-skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave-skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
+ }
+ toread--;
+ } else if (!toread) {
+ /*
+* We have run out of input data, but haven't read
+* enough bytes after the preamble yet. Read some more,
+* and make sure that we transmit dummy bytes too, to
+* keep things going.
+*/
+ assert(!out_bytes);
+ out_bytes = in_bytes;
+ toread = in_bytes;
+ txp = NULL;
+ spi_request_bytes(regs, toread);
+ }
+ if (spi_slave-skip_preamble get_timer(start) 100) {
+ printf(SPI timeout: in_bytes=%d, out_bytes=%d, ,
+ in_bytes, out_bytes);
+ return -1;
}
Re: [U-Boot] [U-Boot, 2/2, V5] spi: exynos: Support SPI_PREAMBLE mode
On 29-05-2013 01:40, Rajeshwari Shinde wrote:
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skipping all data before and
including the preamble. The client will receive only data bytes after
the preamble.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in V2:
- Remove preamable_count variable which is not really needed
- Fix checkpatch warning (multiple assignments)
Changes in V3:
- Modified the if logic in spi_rx_tx function
- Added blank lines as suggested by Minkyu Kang.
- Removed in_bytes check in while loop.
- Added a error check.
Changes in V4:
- Corrected a if condition.
Changes in V5:
- In commit message header changed EXYNOS: SPI: to spi:exynos.
drivers/spi/exynos_spi.c | 69 +++--
1 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 607e1cd..01378d0 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -51,6 +51,7 @@ struct exynos_spi_slave {
unsigned int mode;
enum periph_id periph_id; /* Peripheral ID for this device */
unsigned int fifo_size;
+ int skip_preamble;
};
static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -105,6 +106,8 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
unsigned int cs,
else
spi_slave-fifo_size = 256;
+ spi_slave-skip_preamble = 0;
+
spi_slave-freq = bus-frequency;
if (max_hz)
spi_slave-freq = min(max_hz, spi_slave-freq);
@@ -217,17 +220,23 @@ static void spi_request_bytes(struct exynos_spi *regs,
int count)
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
-static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
- void **dinp, void const **doutp)
+static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
+ void **dinp, void const **doutp, unsigned long flags)
{
struct exynos_spi *regs = spi_slave-regs;
uchar *rxp = *dinp;
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
+ int toread;
+ unsigned start = get_timer(0);
+ int stopping;
out_bytes = in_bytes = todo;
+ stopping = spi_slave-skip_preamble (flags SPI_XFER_END)
+ !(spi_slave-mode SPI_SLAVE);
+
/*
* If there's something to send, do a software reset and set a
* transaction size.
@@ -238,6 +247,8 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
* Bytes are transmitted/received in pairs. Wait to receive all the
* data because then transmission will be done as well.
*/
+ toread = in_bytes;
+
while (in_bytes) {
int temp;
@@ -248,15 +259,43 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
writel(temp, regs-tx_data);
out_bytes--;
}
- if (rx_lvl 0 in_bytes) {
+ if (rx_lvl 0) {
temp = readl(regs-rx_data);
- if (rxp)
- *rxp++ = temp;
- in_bytes--;
+ if (spi_slave-skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave-skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
+ }
+ toread--;
+ } else if (!toread) {
+ /*
+* We have run out of input data, but haven't read
+* enough bytes after the preamble yet. Read some more,
+* and make sure that we transmit dummy bytes too, to
+* keep things going.
+*/
+ assert(!out_bytes);
+ out_bytes = in_bytes;
+ toread = in_bytes;
+ txp = NULL;
+ spi_request_bytes(regs, toread);
+ }
+ if (spi_slave-skip_preamble get_timer(start) 100) {
+ printf(SPI timeout: in_bytes=%d, out_bytes=%d, ,
+ in_bytes,
Re: [U-Boot] [U-Boot,1/2,V5] spi: Add support for preamble bytes
On 29-05-2013 01:40, Rajeshwari Shinde wrote: A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #define SPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #define SPI_3WIRE 0x10/* SI/SO signals shared */ #define SPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec + /*--- * Representation of a SPI slave, i.e. what we're communicating with. * Applied to u-boot-spi/master -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/2] cmd_sf: Add print mesgs on sf read/write commands
On 27-05-2013 15:41, Jagannadha Sutradharudu Teki wrote:
This patch adds a print messages while using 'sf read' and
'sf write' commands to make sure that how many bytes read/written
from/into flash device.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
common/cmd_sf.c | 26 +++---
drivers/mtd/spi/spi_flash.c |3 ---
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 12d1aca..3a40444 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -234,7 +234,7 @@ static int do_spi_flash_read_write(int argc, char * const
argv[])
unsigned long len;
void *buf;
char *endp;
- int ret;
+ int ret = 1;
if (argc 4)
return -1;
@@ -264,19 +264,23 @@ static int do_spi_flash_read_write(int argc, char * const
argv[])
if (strcmp(argv[0], update) == 0)
ret = spi_flash_update(flash, offset, len, buf);
- else if (strcmp(argv[0], read) == 0)
- ret = spi_flash_read(flash, offset, len, buf);
- else
- ret = spi_flash_write(flash, offset, len, buf);
+ else if (strncmp(argv[0], read, 4) == 0 ||
+ strncmp(argv[0], write, 5) == 0) {
+ int read;
+
+ read = strncmp(argv[0], read, 4) == 0;
+ if (read)
+ ret = spi_flash_read(flash, offset, len, buf);
+ else
+ ret = spi_flash_write(flash, offset, len, buf);
+
+ printf(SF: %zu bytes @ %#x %s: %s\n, (size_t)len, (u32)offset,
+ read ? Read : Written, ret ? ERROR : OK);
+ }
unmap_physmem(buf, len);
- if (ret) {
- printf(SPI flash %s failed\n, argv[0]);
- return 1;
- }
-
- return 0;
+ return ret == 0 ? 0 : 1;
}
static int do_spi_flash_erase(int argc, char * const argv[])
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 77938d3..aeb1ccb 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -125,9 +125,6 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
}
}
- debug(SF: program %s %zu bytes @ %#x\n,
- ret ? failure : success, len, offset);
-
spi_release_bus(flash-spi);
return ret;
}
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, U-BOOT] sf: Fix sf read for memory-mapped SPI flashes
On 27-05-2013 15:44, Jagannadha Sutradharudu Teki wrote:
Missing return after memcpy is done for memory-mapped SPI flashes,
hence added retun 0 after memcpy done.
The return is missing in below patch
sf: Enable FDT-based configuration and memory mapping
(sha1: bb8215f437a7c948eec82a6abe754c226978bd6d)
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Acked-by: Simon Glass s...@chromium.org
---
drivers/mtd/spi/spi_flash.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index aeb1ccb..1d45e3b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -148,8 +148,10 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
u8 cmd[5];
/* Handle memory-mapped SPI */
- if (flash-memory_map)
+ if (flash-memory_map) {
memcpy(data, flash-memory_map + offset, len);
+ return 0;
+ }
cmd[0] = CMD_READ_ARRAY_FAST;
spi_flash_addr(offset, cmd);
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/2] cmd_sf: Add print mesg for 'sf erase' command
On 27-05-2013 15:41, Jagannadha Sutradharudu Teki wrote:
This patch adds a print messages while using 'sf erase' command
to make sure that how many bytes erased in flash device.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
common/cmd_sf.c |8 +++-
drivers/mtd/spi/spi_flash.c |7 ++-
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 1daff70..12d1aca 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -305,12 +305,10 @@ static int do_spi_flash_erase(int argc, char * const
argv[])
}
ret = spi_flash_erase(flash, offset, len);
- if (ret) {
- printf(SPI flash %s failed\n, argv[0]);
- return 1;
- }
+ printf(SF: %zu bytes @ %#x Erased: %s\n, (size_t)len, (u32)offset,
+ ret ? ERROR : OK);
- return 0;
+ return ret == 0 ? 0 : 1;
}
#ifdef CONFIG_CMD_SF_TEST
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index d2bee3a..77938d3 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -206,7 +206,7 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
{
- u32 start, end, erase_size;
+ u32 end, erase_size;
int ret;
u8 cmd[4];
@@ -226,8 +226,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
cmd[0] = CMD_ERASE_4K;
else
cmd[0] = CMD_ERASE_64K;
- start = offset;
- end = start + len;
+ end = offset + len;
while (offset end) {
spi_flash_addr(offset, cmd);
@@ -251,8 +250,6 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
offset, size_t len)
goto out;
}
- debug(SF: Successfully erased %zu bytes @ %#x\n, len, start);
-
out:
spi_release_bus(flash-spi);
return ret;
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] exynos: spl: Add a custom spi copy function
Hi,
I think this needs to send as v3, as Simon sent v2 for this.
http://patchwork.ozlabs.org/patch/243139/
--
Thanks,
Jagan.
On Thu, May 30, 2013 at 12:01 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch implements a custom spi_copy funtion to copy u-boot from SF
to RAM. This is faster then iROM spi_copy funtion as this runs spi at
50Mhz and also in WORD mode of operation.
Changed a printf in pinmux.c to debug just to avoid the compilation
error in SPL.
Removed enum for boot mode from spl_boot.c as it was already define
in spl.h
Based on [PATCH V2] spi: exynos: Support word transfers
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Tom Wai-Hong Tam waih...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Corrected the commit message.
- Added a SPI timeout check.
- Corrected the comments.
arch/arm/cpu/armv7/exynos/pinmux.c |2 +-
arch/arm/include/asm/arch-exynos/spi.h |2 +
board/samsung/smdk5250/spl_boot.c | 136 ---
include/configs/exynos5250-dt.h|3 +
spl/Makefile |4 +
5 files changed, 132 insertions(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index bd499b4..c484a86 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -427,7 +427,7 @@ static int exynos4_pinmux_config(int peripheral, int
flags)
case PERIPH_ID_SDMMC1:
case PERIPH_ID_SDMMC3:
case PERIPH_ID_SDMMC4:
- printf(SDMMC device %d not implemented\n, peripheral);
+ debug(SDMMC device %d not implemented\n, peripheral);
return -1;
default:
debug(%s: invalid peripheral %d, __func__, peripheral);
diff --git a/arch/arm/include/asm/arch-exynos/spi.h
b/arch/arm/include/asm/arch-exynos/spi.h
index e67ad27..3430ac1 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -43,6 +43,8 @@ struct exynos_spi {
#define SPI_TIMEOUT_MS 10
+#define SF_READ_DATA_CMD 0x3
+
/* SPI_CHCFG */
#define SPI_CH_HS_EN (1 6)
#define SPI_CH_RST (1 5)
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index c0bcf46..85a5d68 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -22,17 +22,13 @@
#includecommon.h
#includeconfig.h
+#include asm/arch/clk.h
+#include asm/arch/spi.h
+#include asm/arch/pinmux.h
+#include asm/arch/periph.h
+#include asm/arch/spl.h
-enum boot_mode {
- BOOT_MODE_MMC = 4,
- BOOT_MODE_SERIAL = 20,
- /* Boot based on Operating Mode pin settings */
- BOOT_MODE_OM = 32,
- BOOT_MODE_USB, /* Boot using USB download */
-};
-
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
- typedef u32 (*usb_copy_func_t)(void);
+typedef u32 (*usb_copy_func_t)(void);
/*
* Set/clear program flow prediction and return the previous state.
@@ -48,6 +44,119 @@ static int config_branch_prediction(int set_cr_z)
return cr CR_Z;
}
+static void spi_rx_tx(struct exynos_spi *regs, int todo,
+ void *dinp, void const *doutp, int i)
+{
+ uint *rxp = (uint *)(dinp + (i * (32 * 1024)));
+ int rx_lvl, tx_lvl;
+ uint out_bytes, in_bytes;
+
+ out_bytes = todo;
+ in_bytes = todo;
+ setbits_le32(regs-ch_cfg, SPI_CH_RST);
+ clrbits_le32(regs-ch_cfg, SPI_CH_RST);
+ writel(((todo * 8) / 32) | SPI_PACKET_CNT_EN, regs-pkt_cnt);
+
+ while (in_bytes) {
+ uint32_t spi_sts;
+ int temp;
+
+ spi_sts = readl(regs-spi_sts);
+ rx_lvl = ((spi_sts 15) 0x7f);
+ tx_lvl = ((spi_sts 6) 0x7f);
+ while (tx_lvl 32 out_bytes) {
+ temp = 0x;
+ writel(temp, regs-tx_data);
+ out_bytes -= 4;
+ tx_lvl += 4;
+ }
+ while (rx_lvl = 4 in_bytes) {
+ temp = readl(regs-rx_data);
+ if (rxp)
+ *rxp++ = temp;
+ in_bytes -= 4;
+ rx_lvl -= 4;
+ }
+ }
+}
+
+/*
+* Copy uboot from spi flash to RAM
+*
+* @parma uboot_sizesize of u-boot to copy
+* @param uboot_addraddress in u-boot to copy
+*/
+static void exynos_spi_copy(unsigned int uboot_size, unsigned int uboot_addr)
+{
+ int upto, todo;
+ int i, timeout = 100;
+ struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
+
+ set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
+
Re: [U-Boot] [PATCH v3] spi/arm-pl022: Add support for ARM PL022 spi controller
Hi, Does this tested on hw, please re-base the tree and send the next version patch. Let me know if it ok to review under current tree. -- Thanks, Jagan. On Thu, Dec 13, 2012 at 7:31 PM, Armando Visconti armando.visco...@st.com wrote: On 12/13/2012 12:41 PM, Vipin KUMAR wrote: From: Armando Viscontiarmando.visco...@st.com This patch adds the support for the ARM PL022 SPI controller for the standard variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO. Signed-off-by: Armando Viscontiarmando.visco...@st.com Signed-off-by: Vipin Kumarvipin.ku...@st.com --- Changes in v3 Added void to spi_init arguments Used readl/writel in place of u16 accessors Fix: Provided address of register in place of value to readl/writel IO accessors Tested with spear1340-evb I recall now that SPI variant is same also on the new SoC (I2C cell is different). So no need to test over it. SPEAr1340 is enough. Ciao, Arm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] SPI: Add Orion SPI driver
Hi, Does this tested on hw, please re-base the tree and send the next version patch. Let me know if it ok to review under current tree. -- Thanks, Jagan. On Mon, Feb 11, 2013 at 9:09 AM, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] Sent: 17 January 2013 00:55 To: Sebastian Hesselbarth Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert Aribaud; Prafulla Wadaskar; Andy Fleming; Joe Hershberger; Daniel Stodden; Luka Perkov Subject: [PATCH v3 04/10] SPI: Add Orion SPI driver This adds an SPI driver found on Marvell Orion SoCs. This driver is taken from kirkwood_spi but removes mpp configuration as dove has dedicated spi pins. To have a common driver for orion5x, kirkwood, and dove, mpp configuration should be handled in some cpu/board- specific the proposal of having common driver will be greatly appreciated. Pls go ahead and do it if possible for you I think adding orion_spi.c to enable dove support doesn't sound good. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] sf: spansion: Add support for S25FL128S_64K
On Thu, May 30, 2013 at 7:19 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
This commit is based on the patch from Xie Xiaobo x@freescale.com
with commit head title as sf: spansion: Add support for S25FL128S.
pulled the same code changes into current u-boot tree with little update
on the name field.
http://patchwork.ozlabs.org/patch/218145/
SPANSION recommend S25FL128S supersedes S25FL129P, and the two flash
memory have the same device ID and Memory architecture. So they can
use the same config parameters.
Signed-off-by: Xie Xiaobo x@freescale.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spansion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 2218e2f..dad4fbb 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -101,7 +101,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.idcode2 = 0x4d01,
.pages_per_sector = 256,
.nr_sectors = 256,
- .name = S25FL129P_64K,
+ .name = S25FL129P_64K/S25FL128S_64K,
Any comments on this notation, as the ID's are same for these parts upto 5bytes.
if you need to differ then we should read the 6th byte.
If i.e the case increase the byte count on probe function for this, due to extra
over head only for this, i just noted like this. does it make sense?
Request comments.
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
Hi,
On Thu, May 30, 2013 at 7:19 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Use the exact names for W25Q 0x40XX ID's flash parts, as the same
sizes of flashes comes with different ID's. so-that the distinguishes
becomes easy with this change.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/winbond.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 8457808..3c0ca88 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -55,27 +55,27 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
{
.id = 0x4014,
.nr_blocks = 16,
- .name = W25Q80BL,
+ .name = W25Q80BL/W25Q80BV,
},
{
.id = 0x4015,
.nr_blocks = 32,
- .name = W25Q16,
+ .name = W25Q16CL/W25Q16DV,
The id codes were same for these two parts, I think there is no way to
detect the separately.
Any idea?
Thanks,
Jagan.
},
{
.id = 0x4016,
.nr_blocks = 64,
- .name = W25Q32,
+ .name = W25Q32BV,
},
{
.id = 0x4017,
.nr_blocks = 128,
- .name = W25Q64,
+ .name = W25Q64CV,
},
{
.id = 0x4018,
.nr_blocks = 256,
- .name = W25Q128,
+ .name = W25Q128BV,
},
{
.id = 0x4019,
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
Hello Lubomir, Am 02.06.2013 13:42, schrieb Lubomir Popov: Hello Lubomir, Am 01.06.2013 18:44, schrieb Lubomir Popov: New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older OMAPs and derivatives as well. The only anticipated exception would be the OMAP2420, which shall require driver modification. [...] drivers/i2c/omap24xx_i2c.c | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Many thanks for testing, to Tom as well (he did it on the Beagleboards, but for one of the older versions, V3 I believe, right?). When it comes to versions, I see that V1 and V2 are still listed in patchwork, probably because of slightly different wording of the subject: http://patchwork.ozlabs.org/patch/233823/ http://patchwork.ozlabs.org/patch/246204/ Could you or Tom clean this up, please? Thanks. Cleared the v3 v4 version, but missed the v2 and v1, Done. Just one comment: Your patch has 9 checkpatch warnings which are all lines (printf strings) over 80 chars ... some with lines 110 characters ... I know, tom gave you a OK for this ... I am also unhappy with splitting a printf-string over 2 or more lines ... but we have this 80 characters rule ... Wolfgang, what do you think? Should we loosen this rule for printf-strings? Yes, I had the long strings splitted in the older versions, but then unrolled them back as per Tom's recommendation. IMHO, grep-ability is worth breaking this particular rule... But perhaps only for pure Yep. strings w/o format placeholders? I mean, strings could be splitted at the format parameters of printf/sprintf arguments. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
Hello Tom, Am 02.06.2013 15:08, schrieb Tom Rini: On Sun, Jun 02, 2013 at 07:20:50AM +0200, Heiko Schocher wrote: Hello Lubomir, Am 01.06.2013 18:44, schrieb Lubomir Popov: New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older OMAPs and derivatives as well. The only anticipated exception would be the OMAP2420, which shall require driver modification. [...9 Just one comment: Your patch has 9 checkpatch warnings which are all lines (printf strings) over 80 chars ... some with lines 110 characters ... I know, tom gave you a OK for this ... I am also unhappy with splitting a printf-string over 2 or more lines ... but we have this 80 characters rule ... Wolfgang, what do you think? Should we loosen this rule for printf-strings? We have loosened the rule for printf strings already, in order to make it easier for tracking down error messages. However, checkpatch needs tweaking at times for our print functions vs kernel print functions. Ok, great, missed that, thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
