On 08/07/2015 03:46 PM, Michal Suchanek wrote:
[snip]
> On 7 August 2015 at 10:35, Vignesh R wrote:
>>
>>
>> On 08/07/2015 01:08 PM, Michal Suchanek wrote:
>>
>>> Now since the description is clearer it's obvious that ti-qspi cannot
>>> work fully mmapped as fsl-qspi does because the setup has t
On 7 August 2015 at 10:25, Martin Sperl wrote:
> On 8/6/2015 23:33, Russell King - ARM Linux wrote:
>>
>> On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
>>>
>>>
>>> Irrespective of the dummy bytes.
>>> What if the spi device is not a FLASH ROM, but some other device,
>>> which
On 08/07/2015 01:08 PM, Michal Suchanek wrote:
> Now since the description is clearer it's obvious that ti-qspi cannot
> work fully mmapped as fsl-qspi does because the setup has to be done
> over normal spi access and using non-m25p80 devices on the same bus is
> a requirement.
>
> The place w
On 8/6/2015 23:33, Russell King - ARM Linux wrote:
On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
Irrespective of the dummy bytes.
What if the spi device is not a FLASH ROM, but some other device,
which receives a data packet that accidentally looks like an m25p80 READ
comm
On 6 August 2015 at 23:33, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
>> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
>> wrote:
>> > On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>> >> On the whole following are m
On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> >> On the whole following are my requirements:
> >> 1. to be able to communicate with non -flash
On 6 August 2015 at 18:14, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
> wrote:
>> On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>>> On the whole following are my requirements:
>>> 1. to be able to communicate with non -flash SPI devices via c
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> 1.Write to flash config register via config port to switch to QUAD MODE
> (or any mode that flash supports).
> 2. Populate QSPI_SPI_SETUP_REGx with flash read command, number of
> address bytes to use and dummy bytes required.
These thi
On Thu, Aug 06, 2015 at 02:51:29PM +0100, Russell King - ARM Linux wrote:
> The M25P80 driver just appends additional bytes to the message to
> achieve this:
>
> struct m25p *flash = nor->priv;
> unsigned int dummy = nor->read_dummy;
>
> /* convert the dummy cycles to the
On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>> On the whole following are my requirements:
>> 1. to be able to communicate with non -flash SPI devices via config port
>> ( this functionality is supported by current dr
On Thu, Aug 06, 2015 at 01:42:32PM +0200, Michal Suchanek wrote:
> On 6 August 2015 at 13:23, Mark Brown wrote:
> > Sure, but at the end of the day it's just emitting standard SPI messages
> > which don't know anything about flash. If those messages are a sensible
> > interface here then why bot
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> On the whole following are my requirements:
> 1. to be able to communicate with non -flash SPI devices via config port
> ( this functionality is supported by current driver, I dont want to
> break it). Or pump any spi_message on to SPI bu
On 08/06/2015 03:52 PM, Russell King - ARM Linux wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>> Disclaimer: I am not familiar with the hardware for which this patch
>> adds support.
>>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is bas
On 6 August 2015 at 13:23, Mark Brown wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is basically supposed to implement m25p80.c in hardware when this flag
>> is set.
>
> But what in concrete t
On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
> However, I am familiar m25p80.c and as I understand it the controller
> is basically supposed to implement m25p80.c in hardware when this flag
> is set.
But what in concrete terms is that supposed to mean? It's currently
just an
On 6 August 2015 at 12:22, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>> Disclaimer: I am not familiar with the hardware for which this patch
>> adds support.
>>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is b
On Thu, Aug 06, 2015 at 11:22:25AM +0100, Russell King - ARM Linux wrote:
> If that's the case, then maybe you should consider whether using the SPI
> bus infrastructure is really the best way forward. Would it make more
> sense instead to adopt a different software structure, something more
> hi
On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
> Disclaimer: I am not familiar with the hardware for which this patch
> adds support.
>
> However, I am familiar m25p80.c and as I understand it the controller
> is basically supposed to implement m25p80.c in hardware when this flag
On 6 August 2015 at 11:02, Mark Brown wrote:
> On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote:
>> On 5 August 2015 at 14:44, Mark Brown wrote:
>> > On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
>
>> >> I don't think sending 03 or other random byte as the first
On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote:
> On 5 August 2015 at 14:44, Mark Brown wrote:
> > On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
> >> I don't think sending 03 or other random byte as the first byte of a
> >> SPI transfer can be used as reliable
On 5 August 2015 at 14:44, Mark Brown wrote:
> On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
>> On 5 August 2015 at 13:50, Mark Brown wrote:
>
>> > As far as I can tell you want to set a per spi_message flag saying that
>> > the message is a flash read command? If that's what
On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
> On 5 August 2015 at 13:50, Mark Brown wrote:
> > As far as I can tell you want to set a per spi_message flag saying that
> > the message is a flash read command? If that's what this is trying to
> > do then why do you need to set
On 5 August 2015 at 13:50, Mark Brown wrote:
> On Tue, Aug 04, 2015 at 11:29:52PM +0530, R, Vignesh wrote:
>> On 8/4/2015 9:21 PM, Mark Brown wrote:
>> > On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
>
>> > I still can't tell from the above what this interface is supposed to do.
>> >
On Tue, Aug 04, 2015 at 11:29:52PM +0530, R, Vignesh wrote:
> On 8/4/2015 9:21 PM, Mark Brown wrote:
> > On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
> > I still can't tell from the above what this interface is supposed to do.
> > It sounds like the use of memory mapped mode is suppo
On 5 August 2015 at 07:35, Vignesh R wrote:
>
>
> On 08/05/2015 10:51 AM, Michal Suchanek wrote:
>> Hello,
>>
>> On 4 August 2015 at 19:59, R, Vignesh wrote:
>>>
>>>
>>> On 8/4/2015 9:21 PM, Mark Brown wrote:
On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
>>>
>>> TI QSPI co
On 08/05/2015 10:51 AM, Michal Suchanek wrote:
> Hello,
>
> On 4 August 2015 at 19:59, R, Vignesh wrote:
>>
>>
>> On 8/4/2015 9:21 PM, Mark Brown wrote:
>>> On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
>>>
@use_mmap_mode: Some SPI controller chips are optimized for interactin
Hello,
On 4 August 2015 at 19:59, R, Vignesh wrote:
>
>
> On 8/4/2015 9:21 PM, Mark Brown wrote:
>> On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
>>
>>> @use_mmap_mode: Some SPI controller chips are optimized for interacting
>>> with serial flash memories. These chips have memory map
On 8/4/2015 9:21 PM, Mark Brown wrote:
> On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
>
>> @use_mmap_mode: Some SPI controller chips are optimized for interacting
>> with serial flash memories. These chips have memory mapped interface,
>> through which entire serial flash memory sl
On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote:
> @use_mmap_mode: Some SPI controller chips are optimized for interacting
> with serial flash memories. These chips have memory mapped interface,
> through which entire serial flash memory slave can be read/written as if
> though they are
Hi,
On 7/31/2015 11:47 PM, Mark Brown wrote:
> On Tue, Jul 28, 2015 at 02:11:12PM +0530, Vignesh R wrote:
>
>> Introduce use_mmap_read field in spi_message struct. This can be set by
>> mtd devices (m25p80) to indicate to spi-master (ti-qspi) to perform
>> memory mapped read. This helps to distin
On Tue, Jul 28, 2015 at 02:11:12PM +0530, Vignesh R wrote:
> Introduce use_mmap_read field in spi_message struct. This can be set by
> mtd devices (m25p80) to indicate to spi-master (ti-qspi) to perform
> memory mapped read. This helps to distinguish whether the spi-message is
> from mtd layer(hen
TI QSPI controller has SFI translator which exposes entire flash memory
as memory mapped region for read. With this interface, the CPU
can copy data from flash using normal memcpy call. SFI translator
takes care of generating appropriate SPI signals to read data from
flash. This interface works onl
32 matches
Mail list logo
