Message-ID: <CAOMqctTyHF1ciN3-0yg1smYJ5kbuwfT_kmavTL8ARuZ69wSgAg@mail.gmail.com>
Date:	Wed, 22 Jul 2015 10:38:14 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Marek Vasut <marex@...x.de>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	Brian Norris <computersforpeace@...il.com>,
	Richard Cochran <richardcochran@...il.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Mark Rutland <mark.rutland@....com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	Alison Chaiken <alison_chaiken@...tor.com>,
	Bean Huo 霍斌斌 (beanhuo) 
	<beanhuo@...ron.com>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Rafał Miłecki <zajec5@...il.com>,
	Kukjin Kim <kgene@...nel.org>,
	Ben Hutchings <ben@...adent.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Mark Brown <broonie@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"grmoore@...era.com" <grmoore@...era.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>,
	Huang Shijie <b32955@...escale.com>,
	Rob Herring <robh+dt@...nel.org>,
	Han Xu <han.xu@...escale.com>,
	Knut Wohlrab <knut.wohlrab@...bosch.com>,
	dmaengine <dmaengine@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

On 22 July 2015 at 10:24, Marek Vasut <marex@...x.de> wrote:
> On Wednesday, July 22, 2015 at 10:18:04 AM, Michal Suchanek wrote:
>> On 22 July 2015 at 09:58, Marek Vasut <marex@...x.de> wrote:
>> > On Wednesday, July 22, 2015 at 09:45:27 AM, Michal Suchanek wrote:
>> >> On 22 July 2015 at 09:33, Marek Vasut <marex@...x.de> wrote:
>> >> > On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote:
>> >> >> On 22 July 2015 at 06:49, Vinod Koul <vinod.koul@...el.com> wrote:
>> >> >> > On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote:
>> >> >> >> > Or alternatively we could publish the limitations of the channel
>> >> >> >> > using capabilities so SPI knows I have a dmaengine channel and
>> >> >> >> > it can transfer max N length transfers so would be able to
>> >> >> >> > break rather than guessing it or coding in DT. Yes it may come
>> >> >> >> > from DT but that should be dmaengine driver rather than client
>> >> >> >> > driver :)
>> >> >> >> >
>> >> >> >> > This can be done by dma_get_slave_caps(chan, &caps)
>> >> >> >> >
>> >> >> >> > And we add max_length as one more parameter to existing set
>> >> >> >> >
>> >> >> >> > Also all this could be handled in generic SPI-dmaengine layer so
>> >> >> >> > that individual drivers don't have to code it in
>> >> >> >> >
>> >> >> >> > Let me know if this idea is okay, I can push the dmaengine
>> >> >> >> > bits...
>> >> >> >>
>> >> >> >> It would be ok if there was a fixed limit. However, the limit
>> >> >> >> depends on SPI slave settings. Presumably for other buses using
>> >> >> >> the dmaengine the limit would depend on the bus or slave settings
>> >> >> >> as well. I do not see a sane way of passing this all the way to
>> >> >> >> the dmaengine driver.
>> >> >> >
>> >> >> > I don't see why this should be client (SPI) dependent. The max
>> >> >> > length supported is a dmaengine constraint, typically flowing from
>> >> >> > max blocks/length it can transfer. Know this limit can allow
>> >> >> > clients to split transfers.
>> >> >>
>> >> >> In practice on the board I have the maximum transfer length before it
>> >> >> fails depends on SPI bus speed which is set up per slave. I did not
>> >> >> try searching the space of possible settings thorougly and settled
>> >> >> for a setting that gives reasonable speed and transfer length.
>> >> >
>> >> > This looks more like a signal integrity issue though.
>> >>
>> >> It certainly does on the surface. However, when wrong data is
>> >> delivered over the SPI bus (such as when I use wrong phase setting)
>> >> the SPI controller happily delivers wrong data over PIO.
>> >>
>> >> The failure I am seeing is that the pl330 DMA program which repeatedly
>> >> waits for data from the SPI controller never finishes the read loop
>> >> and does not signal the interrupt. It seems it also leaves some data
>> >> in a FIFO somewhere so next command on the flash returns garbage and
>> >> fails.
>> >
>> > I observed something similar on MXS (mx28) SPI block. Do you use mixed
>> > PIO/DMA mode perhaps ?
>>
>> The SPI driver uses PIO for short transfers and DMA for transfers
>> longer than the controller FIFO. This seems to be the standard way to
>> do things.It works flawlessly so long as submitting overly long DMA
>> programs is avoided.
>
> Can you try doing JUST DMA, no PIO ? I remember seeing some bus synchronisation
> issues when I did mixed PIO/DMA on the MXS and it was nasty to track down. Just
> give pure DMA a go to see if the thing stabilizes somehow.

It's probably slower to set up DMA for 2-byte commands but it might
work nonetheless.

I will give it a go.

>
>> > Do you have the option to connect a bus analyzer?
>> > I can probably offer you some tools, I'm in Prague ...
>>
>> The flash chip is accessible when removing the bottom cover. It is
>> VSOP8 package slightly lower than SOP8 so attaching clips to it might
>> be a bit problematic. That's the only accessible part. Everything
>> other than SPI is inside the SoC.
>
> That might be doable, though you might want to try the above thing first.
>
>> Since SPI has no verification whatsoever the chip might be completely
>> dead and you can still read fine all zeroes or all ones when
>> attempting a read from it. I observed this behaviour when I used a
>> flash chip in a socket and it was not firmly seated. It was with a
>> different SPI controller, though.
>
> You should run into issues as soon as the SPI NOR framework tries to read
> status register, no ?

Yes, when the DMA transfer fails the next command fails due to garbage
lying around. However, you can unload the SPI NOR driver, load spidev
driver, and read enough garbage to empty the fifos. Then the flash
identifies as normal again and you can access it.

When the flash is not seated properly and acts autistic you get all
0xff or all 0 back whatever you send to it, obvously. The
identification by the SPI NOR driver fails then.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists