All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vignesh R <vigneshr@ti.com>
To: Michal Suchanek <hramrach@gmail.com>, Martin Sperl <martin@sperl.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Mark Brown <broonie@kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	MTD Maling List <linux-mtd@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
Date: Wed, 12 Aug 2015 14:57:03 +0530	[thread overview]
Message-ID: <55CB1167.7010804@ti.com> (raw)
In-Reply-To: <CAOMqctScUybdoZPgqH185qzDxB=TyutDMARextHx0XwC7L3Xmw@mail.gmail.com>



On 08/07/2015 03:46 PM, Michal Suchanek wrote:
[snip]
> On 7 August 2015 at 10:35, Vignesh R <vigneshr@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 to be done
>>> over normal spi access and using non-m25p80 devices on the same bus is
>>> a requirement.
>>>
>>> The place where it is known if a transfer can use the mmap access is m25p80.c
>>>
>>> So my suggestion is
>>>
>>>  - add a new method for spi master that gets the read opcode, dummy
>>> length, address, address length, buffer, buffer length and performs
>>> read from the flash memory in a hardware-specific way
>>>
>>> - add a check in m25p80.c that the master supports this feature and if
>>> so use it (eg check that the method is non-null)
>>>
>>> Presumably if some new SPI controllers with similar feature are
>>> supported in the future they can use the same inteface because you
>>> pass on everything the m25p80 read knows.
>>>
>>
>> Ok... Do you mean something like this?
>>
>> I will take m25p80 as example but can be expanded for any flash.
>>
>> In include/linux/mtd.h:
>>         struct spi_mtd_config_info {
>>                 struct spi_device       *spi;
>>                 u32                     page_size;
>>                 u8                      addr_width;
>>                 u8                      erase_opcode;
>>                 u8                      read_opcode;
>>                 u8                      read_dummy;
>>                 u8                      program_opcode;
>>                 enum read_mode          flash_read;
>>
>>         } /* subset of struct spi_nor */
>>
> 
> I would just pass these as separate arguments to the function but whatver.
> 
>> In m25p80.c:
>>
>>         static int m25p80_read(struct spi_nor *nor, loff_t from,
>>                                 size_t len, size_t *retlen,
>>                                 u_char *buf)
>>         {
>>                 struct spi_mtd_config_info info;
>>                 struct spi_device *spi;
>>
>>                 if (spi->master->spi_mtd_mmap_read) {
>>                   /* Populate spi_mtd_config_info */
>>                   spi->master->spi_mtd_mmap_read(&info, from, len,
>>                                                  retlen, buf);
>>                 }
>>                 else {
>>                 /* no mtd specific acceleration supported try normal
>>                  * SPI way of communicating with flash
>>                  * continue with current code
>>                  * set up spi_message and call spi_sync()
>>                  */
>>         }
>>
>>       }
>>
>> In spi-ti-qspi.c:
>> Implement spi_mtd_mmap_read while holding master->bus_lock mutex.
>>
> 

I will re-submit patches based on the above idea, if there are no
further comments..

-- 
Thanks
Vignesh

WARNING: multiple messages have this Message-ID (diff)
From: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
To: Michal Suchanek
	<hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Martin Sperl <martin-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org>
Cc: Russell King - ARM Linux
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Brian Norris
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	MTD Maling List
	<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
Date: Wed, 12 Aug 2015 14:57:03 +0530	[thread overview]
Message-ID: <55CB1167.7010804@ti.com> (raw)
In-Reply-To: <CAOMqctScUybdoZPgqH185qzDxB=TyutDMARextHx0XwC7L3Xmw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



On 08/07/2015 03:46 PM, Michal Suchanek wrote:
[snip]
> On 7 August 2015 at 10:35, Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org> 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 to be done
>>> over normal spi access and using non-m25p80 devices on the same bus is
>>> a requirement.
>>>
>>> The place where it is known if a transfer can use the mmap access is m25p80.c
>>>
>>> So my suggestion is
>>>
>>>  - add a new method for spi master that gets the read opcode, dummy
>>> length, address, address length, buffer, buffer length and performs
>>> read from the flash memory in a hardware-specific way
>>>
>>> - add a check in m25p80.c that the master supports this feature and if
>>> so use it (eg check that the method is non-null)
>>>
>>> Presumably if some new SPI controllers with similar feature are
>>> supported in the future they can use the same inteface because you
>>> pass on everything the m25p80 read knows.
>>>
>>
>> Ok... Do you mean something like this?
>>
>> I will take m25p80 as example but can be expanded for any flash.
>>
>> In include/linux/mtd.h:
>>         struct spi_mtd_config_info {
>>                 struct spi_device       *spi;
>>                 u32                     page_size;
>>                 u8                      addr_width;
>>                 u8                      erase_opcode;
>>                 u8                      read_opcode;
>>                 u8                      read_dummy;
>>                 u8                      program_opcode;
>>                 enum read_mode          flash_read;
>>
>>         } /* subset of struct spi_nor */
>>
> 
> I would just pass these as separate arguments to the function but whatver.
> 
>> In m25p80.c:
>>
>>         static int m25p80_read(struct spi_nor *nor, loff_t from,
>>                                 size_t len, size_t *retlen,
>>                                 u_char *buf)
>>         {
>>                 struct spi_mtd_config_info info;
>>                 struct spi_device *spi;
>>
>>                 if (spi->master->spi_mtd_mmap_read) {
>>                   /* Populate spi_mtd_config_info */
>>                   spi->master->spi_mtd_mmap_read(&info, from, len,
>>                                                  retlen, buf);
>>                 }
>>                 else {
>>                 /* no mtd specific acceleration supported try normal
>>                  * SPI way of communicating with flash
>>                  * continue with current code
>>                  * set up spi_message and call spi_sync()
>>                  */
>>         }
>>
>>       }
>>
>> In spi-ti-qspi.c:
>> Implement spi_mtd_mmap_read while holding master->bus_lock mutex.
>>
> 

I will re-submit patches based on the above idea, if there are no
further comments..

-- 
Thanks
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: vigneshr@ti.com (Vignesh R)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
Date: Wed, 12 Aug 2015 14:57:03 +0530	[thread overview]
Message-ID: <55CB1167.7010804@ti.com> (raw)
In-Reply-To: <CAOMqctScUybdoZPgqH185qzDxB=TyutDMARextHx0XwC7L3Xmw@mail.gmail.com>



On 08/07/2015 03:46 PM, Michal Suchanek wrote:
[snip]
> On 7 August 2015 at 10:35, Vignesh R <vigneshr@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 to be done
>>> over normal spi access and using non-m25p80 devices on the same bus is
>>> a requirement.
>>>
>>> The place where it is known if a transfer can use the mmap access is m25p80.c
>>>
>>> So my suggestion is
>>>
>>>  - add a new method for spi master that gets the read opcode, dummy
>>> length, address, address length, buffer, buffer length and performs
>>> read from the flash memory in a hardware-specific way
>>>
>>> - add a check in m25p80.c that the master supports this feature and if
>>> so use it (eg check that the method is non-null)
>>>
>>> Presumably if some new SPI controllers with similar feature are
>>> supported in the future they can use the same inteface because you
>>> pass on everything the m25p80 read knows.
>>>
>>
>> Ok... Do you mean something like this?
>>
>> I will take m25p80 as example but can be expanded for any flash.
>>
>> In include/linux/mtd.h:
>>         struct spi_mtd_config_info {
>>                 struct spi_device       *spi;
>>                 u32                     page_size;
>>                 u8                      addr_width;
>>                 u8                      erase_opcode;
>>                 u8                      read_opcode;
>>                 u8                      read_dummy;
>>                 u8                      program_opcode;
>>                 enum read_mode          flash_read;
>>
>>         } /* subset of struct spi_nor */
>>
> 
> I would just pass these as separate arguments to the function but whatver.
> 
>> In m25p80.c:
>>
>>         static int m25p80_read(struct spi_nor *nor, loff_t from,
>>                                 size_t len, size_t *retlen,
>>                                 u_char *buf)
>>         {
>>                 struct spi_mtd_config_info info;
>>                 struct spi_device *spi;
>>
>>                 if (spi->master->spi_mtd_mmap_read) {
>>                   /* Populate spi_mtd_config_info */
>>                   spi->master->spi_mtd_mmap_read(&info, from, len,
>>                                                  retlen, buf);
>>                 }
>>                 else {
>>                 /* no mtd specific acceleration supported try normal
>>                  * SPI way of communicating with flash
>>                  * continue with current code
>>                  * set up spi_message and call spi_sync()
>>                  */
>>         }
>>
>>       }
>>
>> In spi-ti-qspi.c:
>> Implement spi_mtd_mmap_read while holding master->bus_lock mutex.
>>
> 

I will re-submit patches based on the above idea, if there are no
further comments..

-- 
Thanks
Vignesh

  reply	other threads:[~2015-08-12  9:27 UTC|newest]

Thread overview: 124+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-28  8:41 [RFC PATCH 0/5] Add memory mapped read support for TI QSPI Vignesh R
2015-07-28  8:41 ` Vignesh R
2015-07-28  8:41 ` Vignesh R
2015-07-28  8:41 ` [RFC PATCH 1/5] spi: introduce flag for memory mapped read Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-31 18:17   ` Mark Brown
2015-07-31 18:17     ` Mark Brown
2015-07-31 18:17     ` Mark Brown
2015-08-03  4:57     ` Vignesh R
2015-08-03  4:57       ` Vignesh R
2015-08-03  4:57       ` Vignesh R
2015-08-04 15:51       ` Mark Brown
2015-08-04 15:51         ` Mark Brown
2015-08-04 17:59         ` R, Vignesh
2015-08-04 17:59           ` R, Vignesh
2015-08-04 17:59           ` R, Vignesh
2015-08-04 17:59           ` R, Vignesh
2015-08-05  5:21           ` Michal Suchanek
2015-08-05  5:21             ` Michal Suchanek
2015-08-05  5:21             ` Michal Suchanek
2015-08-05  5:35             ` Vignesh R
2015-08-05  5:35               ` Vignesh R
2015-08-05  5:35               ` Vignesh R
2015-08-05  5:57               ` Michal Suchanek
2015-08-05  5:57                 ` Michal Suchanek
2015-08-05  5:57                 ` Michal Suchanek
2015-08-05 11:50           ` Mark Brown
2015-08-05 11:50             ` Mark Brown
2015-08-05 12:40             ` Michal Suchanek
2015-08-05 12:40               ` Michal Suchanek
2015-08-05 12:40               ` Michal Suchanek
2015-08-05 12:44               ` Mark Brown
2015-08-05 12:44                 ` Mark Brown
2015-08-05 12:44                 ` Mark Brown
2015-08-05 12:56                 ` Michal Suchanek
2015-08-05 12:56                   ` Michal Suchanek
2015-08-06  9:02                   ` Mark Brown
2015-08-06  9:02                     ` Mark Brown
2015-08-06 10:01                     ` Michal Suchanek
2015-08-06 10:01                       ` Michal Suchanek
2015-08-06 10:22                       ` Russell King - ARM Linux
2015-08-06 10:22                         ` Russell King - ARM Linux
2015-08-06 10:22                         ` Russell King - ARM Linux
2015-08-06 11:00                         ` Mark Brown
2015-08-06 11:00                           ` Mark Brown
2015-08-06 11:02                         ` Michal Suchanek
2015-08-06 11:02                           ` Michal Suchanek
2015-08-06 11:02                           ` Michal Suchanek
2015-08-06 12:25                         ` Vignesh R
2015-08-06 12:25                           ` Vignesh R
2015-08-06 12:25                           ` Vignesh R
2015-08-06 12:25                           ` Vignesh R
2015-08-06 13:51                           ` Russell King - ARM Linux
2015-08-06 13:51                             ` Russell King - ARM Linux
2015-08-06 16:14                             ` Geert Uytterhoeven
2015-08-06 16:14                               ` Geert Uytterhoeven
2015-08-06 16:14                               ` Geert Uytterhoeven
2015-08-06 18:20                               ` Michal Suchanek
2015-08-06 18:20                                 ` Michal Suchanek
2015-08-06 18:20                                 ` Michal Suchanek
2015-08-06 21:33                               ` Russell King - ARM Linux
2015-08-06 21:33                                 ` Russell King - ARM Linux
2015-08-06 21:33                                 ` Russell King - ARM Linux
2015-08-07  7:38                                 ` Michal Suchanek
2015-08-07  7:38                                   ` Michal Suchanek
2015-08-07  7:38                                   ` Michal Suchanek
2015-08-07  8:35                                   ` Vignesh R
2015-08-07  8:35                                     ` Vignesh R
2015-08-07  8:25                                 ` Martin Sperl
2015-08-07  8:25                                   ` Martin Sperl
2015-08-07  8:25                                   ` Martin Sperl
2015-08-07 10:16                                   ` Michal Suchanek
2015-08-07 10:16                                     ` Michal Suchanek
2015-08-12  9:27                                     ` Vignesh R [this message]
2015-08-12  9:27                                       ` Vignesh R
2015-08-12  9:27                                       ` Vignesh R
2015-08-06 16:46                             ` Mark Brown
2015-08-06 16:46                               ` Mark Brown
2015-08-06 16:46                               ` Mark Brown
2015-08-06 18:20                           ` Mark Brown
2015-08-06 18:20                             ` Mark Brown
2015-08-06 11:23                       ` Mark Brown
2015-08-06 11:23                         ` Mark Brown
2015-08-06 11:23                         ` Mark Brown
2015-08-06 11:42                         ` Michal Suchanek
2015-08-06 11:42                           ` Michal Suchanek
2015-08-06 16:03                           ` Mark Brown
2015-08-06 16:03                             ` Mark Brown
2015-07-28  8:41 ` [RFC PATCH 2/5] spi: spi-ti-qspi: Add memory mapped read support Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41 ` [RFC PATCH 3/5] mtd: devices: m25p80: set flag to request memory mapped read Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41 ` [RFC PATCH 4/5] ARM: dts: DRA7: Add memory map region entries for qspi Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-31 13:48   ` Sekhar Nori
2015-07-31 13:48     ` Sekhar Nori
2015-07-31 13:48     ` Sekhar Nori
2015-08-03  5:09     ` Vignesh R
2015-08-03  5:09       ` Vignesh R
2015-08-03  5:09       ` Vignesh R
2015-08-03  5:09       ` Vignesh R
2015-07-31 18:19   ` Mark Brown
2015-07-31 18:19     ` Mark Brown
2015-07-31 18:19     ` Mark Brown
2015-08-03  5:02     ` Vignesh R
2015-08-03  5:02       ` Vignesh R
2015-08-03  5:02       ` Vignesh R
2015-08-03  5:02       ` Vignesh R
2015-08-04 15:52       ` Mark Brown
2015-08-04 15:52         ` Mark Brown
2015-08-04 15:52         ` Mark Brown
2015-07-31 21:28   ` Brian Norris
2015-07-31 21:28     ` Brian Norris
2015-08-03  5:06     ` Vignesh R
2015-08-03  5:06       ` Vignesh R
2015-08-03  5:06       ` Vignesh R
2015-08-03  5:06       ` Vignesh R
2015-07-28  8:41 ` [RFC PATCH 5/5] ARM: dts: AM4372: " Vignesh R
2015-07-28  8:41   ` Vignesh R
2015-07-28  8:41   ` Vignesh R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55CB1167.7010804@ti.com \
    --to=vigneshr@ti.com \
    --cc=broonie@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=geert@linux-m68k.org \
    --cc=hramrach@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=martin@sperl.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.