From: b32955@freescale.com (Huang Shijie)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/23] mtd: st_spi_fsm: Add new device
Date: Fri, 29 Nov 2013 19:05:18 +0800 [thread overview]
Message-ID: <529874EE.402@freescale.com> (raw)
In-Reply-To: <20131128092904.GZ3296@lee--X1>
Hi Jones & Augus:
thanks for your explanations.
> Most controllers just take an OPCODE and pass it on to the controller
> and have done with it. The issue that you're attempting to rectify is
> that the m25p80 expects every controller to be an SPI controller
> registered to the SPI framework, but as we both know that's not always
> practical as the SPI framework doesn't allow all configuration
> information to be passed back to the controller driver. Our issue is
> not the same. We are required to send entire 'message sequences', to
> the controller rather than just opcodes. The JEDEC message sequence
> can be seen below. Bear in mind that this is also one of the more
> simple message sequences. Some of them even vary depending on which
> chip is present.
Frankly speaking, my quadspi driver's code is just like Jones's code.
Yes, a big "switch".
The opcode is just like an index to trigger the proper operation.
That's why i add this hook @->read_reg(). (the hook acts as the ioctl)
If we do not use this hooks, we should add more hooks such as
@->read_id, @->read_sr, @->read_cr...
That's make the interface not graceful enough.
I read the your patch implementing the read_id:
http://lists.infradead.org/pipermail/linux-mtd/2013-November/050221.html
it's more readable. But i think Jones's stfsm_read_reg() is workable too.
If you do not like the read_reg() hook, do you have any better idea?
thanks
Huang Shijie
next prev parent reply other threads:[~2013-11-29 11:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-22 16:22 [PATCH 00/23] mtd: st_spi_fsm: Add new device Lee Jones
2013-11-22 16:22 ` [PATCH 01/23] mtd: st_spi_fsm: Allocate resources and register with MTD framework Lee Jones
2013-11-22 16:22 ` [PATCH 02/23] mtd: st_spi_fsm: Supply all register address and bit logic defines Lee Jones
2013-11-22 16:22 ` [PATCH 03/23] mtd: st_spi_fsm: Initialise and configure the FSM for normal working conditions Lee Jones
2013-11-22 16:22 ` [PATCH 04/23] mtd: st_spi_fsm: Supply framework for device requests Lee Jones
2013-11-22 16:22 ` [PATCH 05/23] mtd: st_spi_fsm: Supply a method to read from the FSM's FIFO Lee Jones
2013-11-22 16:22 ` [PATCH 06/23] mtd: st_spi_fsm: Supply defines for the possible flash command opcodes Lee Jones
2013-11-22 16:22 ` [PATCH 07/23] mtd: st_spi_fsm: Add support for JEDEC ID extraction Lee Jones
2013-11-22 16:22 ` [PATCH 08/23] mtd: devices: Provide header for shared OPCODEs and SFDP commands Lee Jones
2013-11-22 16:22 ` [PATCH 09/23] mtd: st_spi_fsm: Provide device look-up table Lee Jones
2013-11-22 16:22 ` [PATCH 10/23] mtd: st_spi_fsm: Dynamically setup flash device based on JEDEC ID Lee Jones
2013-11-22 16:22 ` [PATCH 11/23] ARM: STi: Add support for the FSM Serial Flash Controller Lee Jones
2013-11-22 16:22 ` [PATCH 12/23] mtd: st_spi_fsm: Search for preferred FSM message sequence configurations Lee Jones
2013-11-22 16:22 ` [PATCH 13/23] mtd: st_spi_fsm: Fetch platform specific configurations Lee Jones
2013-11-22 16:22 ` [PATCH 14/23] mtd: st_spi_fsm: Prepare the read/write FSM message sequence(s) Lee Jones
2013-11-22 16:22 ` [PATCH 15/23] mtd: st_spi_fsm: Fetch boot-device from mode pins Lee Jones
2013-11-22 16:22 ` [PATCH 16/23] mtd: st_spi_fsm: Provide the erase one sector sequence Lee Jones
2013-11-22 16:22 ` [PATCH 17/23] mtd: st_spi_fsm: Provide the sequence for enabling 32bit addressing mode Lee Jones
2013-11-22 16:22 ` [PATCH 18/23] mtd: st_spi_fsm: Prepare read/write sequences according to configuration Lee Jones
2013-11-22 16:22 ` [PATCH 19/23] mtd: st_spi_fsm: Add a check to if the chip can handle an SoC reset Lee Jones
2013-11-22 16:22 ` [PATCH 20/23] mtd: st_spi_fsm: Provide a method to put the chip into 32bit addressing mode Lee Jones
2013-11-22 16:22 ` [PATCH 21/23] mtd: st_spi_fsm: Update the flash Volatile Configuration Register Lee Jones
2013-11-22 16:22 ` [PATCH 22/23] mtd: st_spi_fsm: Provide the default read/write configurations Lee Jones
2013-11-22 16:23 ` [PATCH 23/23] mtd: st_spi_fsm: Supply the N25Qxxx specific read configurations Lee Jones
2013-11-27 4:07 ` [PATCH 00/23] mtd: st_spi_fsm: Add new device Brian Norris
2013-11-27 11:52 ` Lee Jones
2013-11-28 3:34 ` Huang Shijie
2013-11-28 9:07 ` Angus Clark
2013-11-28 9:29 ` Lee Jones
2013-11-29 11:05 ` Huang Shijie [this message]
2013-11-29 11:53 ` Lee Jones
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=529874EE.402@freescale.com \
--to=b32955@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).