From: Huang Shijie <b32955@freescale.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: angus.clark@st.com, linus.walleij@linaro.org,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
Mark Brown <broonie@kernel.org>,
linux-mtd@lists.infradead.org,
Brian Norris <computersforpeace@gmail.com>,
dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [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
WARNING: multiple messages have this Message-ID (diff)
From: Huang Shijie <b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Brian Norris
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
<angus.clark-qxv4g6HH51o@public.gmane.org>,
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [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
--
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: 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
WARNING: multiple messages have this Message-ID (diff)
From: Huang Shijie <b32955@freescale.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Brian Norris <computersforpeace@gmail.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <dwmw2@infradead.org>,
<linux-mtd@lists.infradead.org>, <angus.clark@st.com>,
<linus.walleij@linaro.org>, Mark Brown <broonie@kernel.org>,
<linux-spi@vger.kernel.org>
Subject: Re: [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: 75+ 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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:22 ` Lee Jones
2013-11-22 16:23 ` [PATCH 23/23] mtd: st_spi_fsm: Supply the N25Qxxx specific read configurations Lee Jones
2013-11-22 16:23 ` Lee Jones
2013-11-27 4:07 ` [PATCH 00/23] mtd: st_spi_fsm: Add new device Brian Norris
2013-11-27 4:07 ` Brian Norris
2013-11-27 4:07 ` Brian Norris
2013-11-27 4:07 ` Brian Norris
2013-11-27 11:52 ` Lee Jones
2013-11-27 11:52 ` Lee Jones
2013-11-27 11:52 ` Lee Jones
2013-11-27 11:52 ` Lee Jones
2013-11-28 3:34 ` Huang Shijie
2013-11-28 3:34 ` Huang Shijie
2013-11-28 3:34 ` Huang Shijie
2013-11-28 3:34 ` Huang Shijie
2013-11-28 9:07 ` Angus Clark
2013-11-28 9:07 ` Angus Clark
2013-11-28 9:07 ` Angus Clark
2013-11-28 9:07 ` Angus Clark
2013-11-28 9:29 ` Lee Jones
2013-11-28 9:29 ` Lee Jones
2013-11-28 9:29 ` Lee Jones
2013-11-28 9:29 ` Lee Jones
2013-11-29 11:05 ` Huang Shijie [this message]
2013-11-29 11:05 ` Huang Shijie
2013-11-29 11:05 ` Huang Shijie
2013-11-29 11:05 ` Huang Shijie
2013-11-29 11:53 ` Lee Jones
2013-11-29 11:53 ` Lee Jones
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=angus.clark@st.com \
--cc=broonie@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.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 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.