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
On 08/07/2015 03:46 PM, Michal Suchanek wrote:
[snip]
On 7 August 2015 at 10:35, Vignesh R vigne...@ti.com 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
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,
>>>
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
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
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
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 where
On 6 August 2015 at 23:33, Russell King - ARM Linux
li...@arm.linux.org.uk 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
li...@arm.linux.org.uk wrote:
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R
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
On 7 August 2015 at 10:25, Martin Sperl mar...@sperl.org 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 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 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
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
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
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
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
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
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
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
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
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
>
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
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 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
li...@arm.linux.org.uk 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
On 6 August 2015 at 11:02, Mark Brown broo...@kernel.org wrote:
On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote:
On 5 August 2015 at 14:44, Mark Brown broo...@kernel.org wrote:
On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
I don't think sending 03 or other
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
is
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
On 6 August 2015 at 13:23, Mark Brown broo...@kernel.org 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
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 basically
On 6 August 2015 at 12:22, Russell King - ARM Linux
li...@arm.linux.org.uk 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
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 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 things
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 number
On 6 August 2015 at 18:14, Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
li...@arm.linux.org.uk 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
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 bus
On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote:
On 5 August 2015 at 14:44, Mark Brown broo...@kernel.org 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
On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
li...@arm.linux.org.uk 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
On Thu, Aug 06, 2015 at 01:42:32PM +0200, Michal Suchanek wrote:
On 6 August 2015 at 13:23, Mark Brown broo...@kernel.org 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
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
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
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 supposed to
On 5 August 2015 at 13:50, Mark Brown broo...@kernel.org 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
On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
On 5 August 2015 at 13:50, Mark Brown broo...@kernel.org 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
On 5 August 2015 at 14:44, Mark Brown broo...@kernel.org wrote:
On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
On 5 August 2015 at 13:50, Mark Brown broo...@kernel.org wrote:
As far as I can tell you want to set a per spi_message flag saying that
the message is a flash
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
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
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
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
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
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
Hello,
On 4 August 2015 at 19:59, R, Vignesh vigne...@ti.com 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
On 08/05/2015 10:51 AM, Michal Suchanek wrote:
Hello,
On 4 August 2015 at 19:59, R, Vignesh vigne...@ti.com 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
On 5 August 2015 at 07:35, Vignesh R vigne...@ti.com wrote:
On 08/05/2015 10:51 AM, Michal Suchanek wrote:
Hello,
On 4 August 2015 at 19:59, R, Vignesh vigne...@ti.com 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
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 slave can
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
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 distinguish
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
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(hence
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
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
64 matches
Mail list logo
