Re: [linux-sunxi] [PATCH 3/3] MTD: m25p80: Add option to limit SPI transfer size.
Hi Michal, On Thu, Apr 30, 2015 at 11:46 PM, Michal Suchanek hramr...@gmail.com wrote: My SPI driver does not support DMA so sizes larger than 64 bytes return an error. Add an option to limit transfer size so m25p80 can be used with reduced speed with such controller. I suspect that this will be rejected as the maximum transfer size is a property of the SPI controller, not the device and should be exported to the device driver from the controller, not specified in the device's binding. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi, I give Maxime's patch a try, but get divide by zero in kernel traces due to spi max speed not being setted. I then tried declaring spidev in the DT, and my application just work's. Adding spi0 alias in DT give's me a beautyful /dev/spidev0.0, where Maxime's was creating /dev/spidev0.[0-3] nodes. Thanks Eric -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/3] MTD: m25p80: fix write return value.
The size of written data was added to user supplied value rather than written at the provided address. Signed-off-by: Michal Suchanek hramr...@gmail.com --- drivers/mtd/devices/m25p80.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index 7c8b169..0b2bc21 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -102,7 +102,7 @@ static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len, spi_sync(spi, m); - *retlen += m.actual_length - cmd_sz; + *retlen = m.actual_length - cmd_sz; } static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor) -- 2.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 0/3] Using SPI NOR flah on sunxi.
Hello, I tried to connect a SPI NOR flash to my sunxi board and due to the current sunxi SPI driver limitations it does not work. The SPI driver returns an error when more than 64 bytes are transferred at once due to lack of DMA support. I tried to hack in an option to limit the transfer size and discovered that the return value of write in m25p80 driver is wrong and never checked. This might be useful while working with other devices with limited driver support. Thanks Michal Michal Suchanek (3): MTD: m25p80: fix write return value. MTD: spi-nor: check for short writes in spi_nor_write. MTD: m25p80: Add option to limit SPI transfer size. Documentation/devicetree/bindings/mtd/m25p80.txt | 5 +++ drivers/mtd/devices/m25p80.c | 21 ++-- drivers/mtd/spi-nor/spi-nor.c| 42 ++-- 3 files changed, 40 insertions(+), 28 deletions(-) -- 2.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/3] MTD: spi-nor: check for short writes in spi_nor_write.
My SPI controller driver does not support DMA so writes are truncated to
FIFO size.
Check the amount of data actually written by the driver.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
drivers/mtd/spi-nor/spi-nor.c | 42 +-
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 14a5d23..75904b5 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -807,7 +807,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to,
size_t len,
size_t *retlen, const u_char *buf)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
- u32 page_offset, page_size, i;
+ u32 page_offset, page_remainder, page_size, i;
int ret;
dev_dbg(nor-dev, to 0x%08x, len %zd\n, (u32)to, len);
@@ -816,36 +816,28 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to,
size_t len,
if (ret)
return ret;
- write_enable(nor);
-
- page_offset = to (nor-page_size - 1);
-
- /* do all the bytes fit onto one page? */
- if (page_offset + len = nor-page_size) {
- nor-write(nor, to, len, retlen, buf);
- } else {
- /* the size of data remaining on the first page */
- page_size = nor-page_size - page_offset;
- nor-write(nor, to, page_size, retlen, buf);
+ /* write everything in nor-page_size chunks */
+ /* check the size of data actually written */
+ for (i = 0; i len; i += *retlen) {
+ page_size = len - i;
+ page_offset = (to + i) (nor-page_size - 1);
+ page_remainder = nor-page_size - page_offset;
+ if (page_size nor-page_size)
+ page_size = nor-page_size;
+ if (page_remainder (page_size page_remainder))
+ page_size = page_remainder;
- /* write everything in nor-page_size chunks */
- for (i = page_size; i len; i += page_size) {
- page_size = len - i;
- if (page_size nor-page_size)
- page_size = nor-page_size;
-
- ret = spi_nor_wait_till_ready(nor);
- if (ret)
- goto write_err;
+ write_enable(nor);
- write_enable(nor);
+ nor-write(nor, to + i, page_size, retlen, buf + i);
- nor-write(nor, to + i, page_size, retlen, buf + i);
- }
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ goto write_err;
}
- ret = spi_nor_wait_till_ready(nor);
write_err:
+ *retlen = i;
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_WRITE);
return ret;
}
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 0/3] Using SPI NOR flah on sunxi.
On 30 April 2015 at 18:30, thomas.bet...@rohde-schwarz.com wrote: Hello Michal: I tried to connect a SPI NOR flash to my sunxi board and due to the current sunxi SPI driver limitations it does not work. The SPI driver returns an error when more than 64 bytes are transferred at once due to lack of DMA support. Wouldn't it be easier to fix the SPI driver to handle transfers larger than 64 bytes, filling and draining the FIFO multiple times if neccessary? (As far as I can tell, most SPI drivers do this.) Yes, the intent is to fix this by adding dma support to the driver, eventually. The patch might be still useful for other hardware with developing SPI support. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 0/3] Using SPI NOR flah on sunxi.
Hello Michal: I tried to connect a SPI NOR flash to my sunxi board and due to the current sunxi SPI driver limitations it does not work. The SPI driver returns an error when more than 64 bytes are transferred at once due to lack of DMA support. Wouldn't it be easier to fix the SPI driver to handle transfers larger than 64 bytes, filling and draining the FIFO multiple times if neccessary? (As far as I can tell, most SPI drivers do this.) Just asking, Thomas -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 0/3] Using SPI NOR flah on sunxi.
On Thursday, April 30, 2015 at 06:56:18 PM, Michal Suchanek wrote: On 30 April 2015 at 18:30, thomas.bet...@rohde-schwarz.com wrote: Hello Michal: I tried to connect a SPI NOR flash to my sunxi board and due to the current sunxi SPI driver limitations it does not work. The SPI driver returns an error when more than 64 bytes are transferred at once due to lack of DMA support. Wouldn't it be easier to fix the SPI driver to handle transfers larger than 64 bytes, filling and draining the FIFO multiple times if neccessary? (As far as I can tell, most SPI drivers do this.) Yes, the intent is to fix this by adding dma support to the driver, eventually. The patch might be still useful for other hardware with developing SPI support. Please just fix the controller driver to correctly handle arbitrary transfer lengths. Best regards, Marek Vasut
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Wed, Apr 29, 2015 at 08:37:24PM +0200, Michal Suchanek wrote: On 29 April 2015 at 20:06, Mark Brown broo...@kernel.org wrote: I think the rest of the thread had that covered - there's both adding the device IDs and Maxime's patch. And adding device IDs is unacceptable for users of devboards while Maxime's patch is not accepted into the kernel. I am using a version of Maxime's patch myself right now. It does not seem it's going to be include in the kernel any time soon, however. A big reason for that is that it's not in my inbox for me to review, these messages I flagged as unhelpful aren't going to help with that if only because I don't want to create the impression that such behaviour achieves results. FWIW I added the ability to open any CS, even those claimed by kernel drivers. This addresses any potential race of spidev binding before the actual driver but has the potential to introduce some subtle bugs when you open and reconfigure a CS used by a kernel driver or send some commands that upset the device. This doesn't seem like an obviously good idea - having userspace be able to interact with a device without a running kernel driver knowing about it doesn't seem like something that will end well. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 1/3] MTD: m25p80: fix write return value.
On Thursday, April 30, 2015 at 03:33:47 PM, Michal Suchanek wrote: The size of written data was added to user supplied value rather than written at the provided address. You might want to work on the commit message a little, something like the following, but feel free to reword as seen fit. The 'retlen' points to a variable representing the number of data bytes written/read (see include/linux/mtd/mtd.h) by the current invocation of the function. This variable must be set, not incremented. Otherwise, the patch is correct I believe: Acked-by: Marek Vasut ma...@denx.de Signed-off-by: Michal Suchanek hramr...@gmail.com --- drivers/mtd/devices/m25p80.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index 7c8b169..0b2bc21 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -102,7 +102,7 @@ static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len, spi_sync(spi, m); - *retlen += m.actual_length - cmd_sz; + *retlen = m.actual_length - cmd_sz; } static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor) Best regards, Marek Vasut
[linux-sunxi] Availability of A83T boards for developers
Dear All, The newer octa-core SoC from Allwinner is the A83T (octa-core ARM Cortex-A7 @ 2.0 GHz with the PowerVR SGX544MP GPU) and can be found in tablets such as the one that Jean-Luc reviewed a few months ago, http://www.cnx-software.com/2014/12/06/allwinner-a83t-tablet-unboxing-first-boot-and-benchmarks/ For the A83T, there is documentation available at https://github.com/allwinner-zh/documents/tree/master/A83T The bootloader is at https://github.com/allwinner-zh/bootloader/tree/master/basic_loader The 3.4 Linux kernel is at https://github.com/allwinner-zh/linux-3.4-sunxi/tree/A83T Very soon, a few A83T dev boards will be produced in order to be given to developers who might be interested in mainline support. As with the previous donation of boards, I'll be doing the clerical work this time as well. Send me mail in private if you are interested to receive one. I'll process the requests and forward to Allwinner so that they can send you the boards. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Availability of A83T boards for developers
On Fri, May 01, 2015 at 06:37:11AM +0300, Simos Xenitellis wrote: Dear All, The newer octa-core SoC from Allwinner is the A83T (octa-core ARM Cortex-A7 @ 2.0 GHz with the PowerVR SGX544MP GPU) and can be found in tablets such as the one that Jean-Luc reviewed a few months ago, http://www.cnx-software.com/2014/12/06/allwinner-a83t-tablet-unboxing-first-boot-and-benchmarks/ For the A83T, there is documentation available at https://github.com/allwinner-zh/documents/tree/master/A83T The bootloader is at https://github.com/allwinner-zh/bootloader/tree/master/basic_loader The 3.4 Linux kernel is at https://github.com/allwinner-zh/linux-3.4-sunxi/tree/A83T Very soon, a few A83T dev boards will be produced in order to be given to developers who might be interested in mainline support. As with the previous donation of boards, I'll be doing the clerical work this time as well. Send me mail in private if you are interested to receive one. I'll process the requests and forward to Allwinner so that they can send you the boards. Simos Are you playing santa clause with other peoples accomplishments or donations again? Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/3] MTD: m25p80: fix write return value.
On 30 April 2015 at 20:43, Marek Vasut ma...@denx.de wrote: On Thursday, April 30, 2015 at 03:33:47 PM, Michal Suchanek wrote: The size of written data was added to user supplied value rather than written at the provided address. You might want to work on the commit message a little, something like the following, but feel free to reword as seen fit. The 'retlen' points to a variable representing the number of data bytes written/read (see include/linux/mtd/mtd.h) by the current invocation of the function. This variable must be set, not incremented. Otherwise, the patch is correct I believe: Acked-by: Marek Vasut ma...@denx.de ok, I will send an updated version. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
