From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <529707C3.40208@st.com> Date: Thu, 28 Nov 2013 09:07:15 +0000 From: Angus Clark MIME-Version: 1.0 To: Huang Shijie Subject: Re: [PATCH 00/23] mtd: st_spi_fsm: Add new device References: <1385137380-28968-1-git-send-email-lee.jones@linaro.org> <20131127040723.GZ9468@ld-irv-0074.broadcom.com> <20131127115226.GC3296@lee--X1> <5296B9C5.3060704@freescale.com> In-Reply-To: <5296B9C5.3060704@freescale.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Lee Jones , linus.walleij@linaro.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Mark Brown , linux-mtd@lists.infradead.org, Brian Norris , dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Huang Shijie, On 11/28/2013 03:34 AM, Huang Shijie wrote: > 于 2013年11月27日 19:52, Lee Jones 写道: >> However, as we send entire 'message sequences' to the FSM Controller >> as opposed to merely OPCODEs we would have to extract the OPCODE from >> flash->command[0] and call our own functions to craft the correct >> 'message sequence' for the task. For this reason we rejected the idea >> and went with a stand-alone driver. >> > could you send me the datasheet of your spi nor controller? > I can change my code if it really not good enough. I will reply to the "mtd: spi-nor" thread regarding the proposed framework, but a couple of answers to your specific questions below. > > we can store the opcode to a field, such as spi_nor_write_op. >> The framework which Huang is proposing suffers from the same issues. >> Only providing read(), write(), read_reg() and write_reg() doesn't >> work for our use-case, as we'd have to decode the flash->command[0] and >> invoke our own internal routines as before. >> >> The only framework with would work for us would consist almost all >> of the important functions such as; read(), write(), erase(), >> wait_busy(), read_jedec(), read_status_reg(), write_status_reg(), >> read_control_reg(), write_control_reg(), etc. However, this approach >> > read_jedec() can be replaced by read_reg(0x9f); > > read_status() can be replaced by read_reg(0x5); > > .... > > write_control_reg() can be replaced by write_reg(xx). Unfortunately the H/W Controller in question comes with a few restrictions. One restriction is that data must be read in multiples of 4 bytes. As such, it would not be able to honour a call of "flash->read_reg(flash, OPCODE_RDID, id, 5);" Of course, if the H/W driver knows that we are issuing a read_jedec() operation, then it can make the assumption that over-reading is benign, and we can instead read 8 bytes of data from the Flash device, and return 5 to the caller. However, without knowing what operation is being requested, no such assumption can be made. > Please correct me if i am wrong. > > IMHO, the current four hooks for spi-nor{} can do all the things. > > read/write/read_reg/write_reg. As it stands, the spi-nor framework cannot support the requirements of the st_spi_fsm controller. I will go into further details on the "mtd: spi-nor" thread. Cheers, Angus -- ------------------------------------- Angus Clark ST Microelectronics (R&D) Ltd. 1000 Aztec West, Bristol, BS32 4SQ email: angus.clark@st.com tel: +44 (0) 1454 462389 st-tina: 065 2389 ------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Angus Clark Subject: Re: [PATCH 00/23] mtd: st_spi_fsm: Add new device Date: Thu, 28 Nov 2013 09:07:15 +0000 Message-ID: <529707C3.40208@st.com> References: <1385137380-28968-1-git-send-email-lee.jones@linaro.org> <20131127040723.GZ9468@ld-irv-0074.broadcom.com> <20131127115226.GC3296@lee--X1> <5296B9C5.3060704@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Lee Jones , linus.walleij@linaro.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Mark Brown , linux-mtd@lists.infradead.org, Brian Norris , dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org To: Huang Shijie Return-path: In-Reply-To: <5296B9C5.3060704@freescale.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org List-Id: linux-spi.vger.kernel.org SGkgSHVhbmcgU2hpamllLAoKT24gMTEvMjgvMjAxMyAwMzozNCBBTSwgSHVhbmcgU2hpamllIHdy b3RlOgo+IOS6jiAyMDEz5bm0MTHmnIgyN+aXpSAxOTo1MiwgTGVlIEpvbmVzIOWGmemBkzoKPj4g SG93ZXZlciwgYXMgd2Ugc2VuZCBlbnRpcmUgJ21lc3NhZ2Ugc2VxdWVuY2VzJyB0byB0aGUgRlNN IENvbnRyb2xsZXIKPj4gYXMgb3Bwb3NlZCB0byBtZXJlbHkgT1BDT0RFcyB3ZSB3b3VsZCBoYXZl IHRvIGV4dHJhY3QgdGhlIE9QQ09ERSBmcm9tCj4+IGZsYXNoLT5jb21tYW5kWzBdIGFuZCBjYWxs IG91ciBvd24gZnVuY3Rpb25zIHRvIGNyYWZ0IHRoZSBjb3JyZWN0Cj4+ICdtZXNzYWdlIHNlcXVl bmNlJyBmb3IgdGhlIHRhc2suIEZvciB0aGlzIHJlYXNvbiB3ZSByZWplY3RlZCB0aGUgaWRlYQo+ PiBhbmQgd2VudCB3aXRoIGEgc3RhbmQtYWxvbmUgZHJpdmVyLgo+Pgo+IGNvdWxkIHlvdSBzZW5k IG1lIHRoZSBkYXRhc2hlZXQgb2YgeW91ciBzcGkgbm9yIGNvbnRyb2xsZXI/Cj4gSSBjYW4gY2hh bmdlIG15IGNvZGUgaWYgaXQgcmVhbGx5IG5vdCBnb29kIGVub3VnaC4KCkkgd2lsbCByZXBseSB0 byB0aGUgIm10ZDogc3BpLW5vciIgdGhyZWFkIHJlZ2FyZGluZyB0aGUgcHJvcG9zZWQgZnJhbWV3 b3JrLCBidXQKYSBjb3VwbGUgb2YgYW5zd2VycyB0byB5b3VyIHNwZWNpZmljIHF1ZXN0aW9ucyBi ZWxvdy4KCj4gCj4gd2UgY2FuIHN0b3JlIHRoZSBvcGNvZGUgdG8gYSBmaWVsZCwgc3VjaCBhcyBz cGlfbm9yX3dyaXRlX29wLgo+PiBUaGUgZnJhbWV3b3JrIHdoaWNoIEh1YW5nIGlzIHByb3Bvc2lu ZyBzdWZmZXJzIGZyb20gdGhlIHNhbWUgaXNzdWVzLgo+PiBPbmx5IHByb3ZpZGluZyByZWFkKCks IHdyaXRlKCksIHJlYWRfcmVnKCkgYW5kIHdyaXRlX3JlZygpIGRvZXNuJ3QKPj4gd29yayBmb3Ig b3VyIHVzZS1jYXNlLCBhcyB3ZSdkIGhhdmUgdG8gZGVjb2RlIHRoZSBmbGFzaC0+Y29tbWFuZFsw XSBhbmQKPj4gaW52b2tlIG91ciBvd24gaW50ZXJuYWwgcm91dGluZXMgYXMgYmVmb3JlLgo+Pgo+ PiBUaGUgb25seSBmcmFtZXdvcmsgd2l0aCB3b3VsZCB3b3JrIGZvciB1cyB3b3VsZCBjb25zaXN0 IGFsbW9zdCBhbGwKPj4gb2YgdGhlIGltcG9ydGFudCBmdW5jdGlvbnMgc3VjaCBhczsgcmVhZCgp LCB3cml0ZSgpLCBlcmFzZSgpLAo+PiB3YWl0X2J1c3koKSwgcmVhZF9qZWRlYygpLCByZWFkX3N0 YXR1c19yZWcoKSwgd3JpdGVfc3RhdHVzX3JlZygpLAo+PiByZWFkX2NvbnRyb2xfcmVnKCksIHdy aXRlX2NvbnRyb2xfcmVnKCksIGV0Yy4gSG93ZXZlciwgdGhpcyBhcHByb2FjaAo+PiAgIAo+IHJl YWRfamVkZWMoKSBjYW4gYmUgcmVwbGFjZWQgYnkgcmVhZF9yZWcoMHg5Zik7Cj4gCj4gcmVhZF9z dGF0dXMoKSBjYW4gYmUgcmVwbGFjZWQgYnkgcmVhZF9yZWcoMHg1KTsKPiAKPiAuLi4uCj4gCj4g d3JpdGVfY29udHJvbF9yZWcoKSBjYW4gYmUgcmVwbGFjZWQgYnkgd3JpdGVfcmVnKHh4KS4KClVu Zm9ydHVuYXRlbHkgdGhlIEgvVyBDb250cm9sbGVyIGluIHF1ZXN0aW9uIGNvbWVzIHdpdGggYSBm ZXcgcmVzdHJpY3Rpb25zLiAgT25lCnJlc3RyaWN0aW9uIGlzIHRoYXQgZGF0YSBtdXN0IGJlIHJl YWQgaW4gbXVsdGlwbGVzIG9mIDQgYnl0ZXMuICBBcyBzdWNoLCBpdAp3b3VsZCBub3QgYmUgYWJs ZSB0byBob25vdXIgYSBjYWxsIG9mICJmbGFzaC0+cmVhZF9yZWcoZmxhc2gsIE9QQ09ERV9SRElE LCBpZCwgNSk7IgoKT2YgY291cnNlLCBpZiB0aGUgSC9XIGRyaXZlciBrbm93cyB0aGF0IHdlIGFy ZSBpc3N1aW5nIGEgcmVhZF9qZWRlYygpIG9wZXJhdGlvbiwKdGhlbiBpdCBjYW4gbWFrZSB0aGUg YXNzdW1wdGlvbiB0aGF0IG92ZXItcmVhZGluZyBpcyBiZW5pZ24sIGFuZCB3ZSBjYW4gaW5zdGVh ZApyZWFkIDggYnl0ZXMgb2YgZGF0YSBmcm9tIHRoZSBGbGFzaCBkZXZpY2UsIGFuZCByZXR1cm4g NSB0byB0aGUgY2FsbGVyLgpIb3dldmVyLCB3aXRob3V0IGtub3dpbmcgd2hhdCBvcGVyYXRpb24g aXMgYmVpbmcgcmVxdWVzdGVkLCBubyBzdWNoIGFzc3VtcHRpb24KY2FuIGJlIG1hZGUuCgo+IFBs ZWFzZSBjb3JyZWN0IG1lIGlmIGkgYW0gd3JvbmcuCj4gCj4gSU1ITywgdGhlIGN1cnJlbnQgZm91 ciBob29rcyBmb3Igc3BpLW5vcnt9IGNhbiBkbyBhbGwgdGhlIHRoaW5ncy4KPiAKPiAgICAgIHJl YWQvd3JpdGUvcmVhZF9yZWcvd3JpdGVfcmVnLgoKQXMgaXQgc3RhbmRzLCB0aGUgc3BpLW5vciBm cmFtZXdvcmsgY2Fubm90IHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUKc3Rfc3BpX2Zz bSBjb250cm9sbGVyLiAgSSB3aWxsIGdvIGludG8gZnVydGhlciBkZXRhaWxzIG9uIHRoZSAibXRk OiBzcGktbm9yIiB0aHJlYWQuCgpDaGVlcnMsCgpBbmd1cwoKCi0tIAotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCkFuZ3VzIENsYXJrClNUIE1pY3JvZWxlY3Ryb25pY3MgKFIm RCkgTHRkLgoxMDAwIEF6dGVjIFdlc3QsIEJyaXN0b2wsIEJTMzIgNFNRCmVtYWlsOiBhbmd1cy5j bGFya0BzdC5jb20KdGVsOiArNDQgKDApIDE0NTQgNDYyMzg5CnN0LXRpbmE6IDA2NSAyMzg5Ci0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eCBNVEQgZGlzY3Vzc2lvbiBt YWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9s aW51eC1tdGQvCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: angus.clark@st.com (Angus Clark) Date: Thu, 28 Nov 2013 09:07:15 +0000 Subject: [PATCH 00/23] mtd: st_spi_fsm: Add new device In-Reply-To: <5296B9C5.3060704@freescale.com> References: <1385137380-28968-1-git-send-email-lee.jones@linaro.org> <20131127040723.GZ9468@ld-irv-0074.broadcom.com> <20131127115226.GC3296@lee--X1> <5296B9C5.3060704@freescale.com> Message-ID: <529707C3.40208@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Huang Shijie, On 11/28/2013 03:34 AM, Huang Shijie wrote: > ? 2013?11?27? 19:52, Lee Jones ??: >> However, as we send entire 'message sequences' to the FSM Controller >> as opposed to merely OPCODEs we would have to extract the OPCODE from >> flash->command[0] and call our own functions to craft the correct >> 'message sequence' for the task. For this reason we rejected the idea >> and went with a stand-alone driver. >> > could you send me the datasheet of your spi nor controller? > I can change my code if it really not good enough. I will reply to the "mtd: spi-nor" thread regarding the proposed framework, but a couple of answers to your specific questions below. > > we can store the opcode to a field, such as spi_nor_write_op. >> The framework which Huang is proposing suffers from the same issues. >> Only providing read(), write(), read_reg() and write_reg() doesn't >> work for our use-case, as we'd have to decode the flash->command[0] and >> invoke our own internal routines as before. >> >> The only framework with would work for us would consist almost all >> of the important functions such as; read(), write(), erase(), >> wait_busy(), read_jedec(), read_status_reg(), write_status_reg(), >> read_control_reg(), write_control_reg(), etc. However, this approach >> > read_jedec() can be replaced by read_reg(0x9f); > > read_status() can be replaced by read_reg(0x5); > > .... > > write_control_reg() can be replaced by write_reg(xx). Unfortunately the H/W Controller in question comes with a few restrictions. One restriction is that data must be read in multiples of 4 bytes. As such, it would not be able to honour a call of "flash->read_reg(flash, OPCODE_RDID, id, 5);" Of course, if the H/W driver knows that we are issuing a read_jedec() operation, then it can make the assumption that over-reading is benign, and we can instead read 8 bytes of data from the Flash device, and return 5 to the caller. However, without knowing what operation is being requested, no such assumption can be made. > Please correct me if i am wrong. > > IMHO, the current four hooks for spi-nor{} can do all the things. > > read/write/read_reg/write_reg. As it stands, the spi-nor framework cannot support the requirements of the st_spi_fsm controller. I will go into further details on the "mtd: spi-nor" thread. Cheers, Angus -- ------------------------------------- Angus Clark ST Microelectronics (R&D) Ltd. 1000 Aztec West, Bristol, BS32 4SQ email: angus.clark at st.com tel: +44 (0) 1454 462389 st-tina: 065 2389 ------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754505Ab3K1JbK (ORCPT ); Thu, 28 Nov 2013 04:31:10 -0500 Received: from eu1sys200aog117.obsmtp.com ([207.126.144.143]:41819 "EHLO eu1sys200aog117.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200Ab3K1JbF (ORCPT ); Thu, 28 Nov 2013 04:31:05 -0500 Message-ID: <529707C3.40208@st.com> Date: Thu, 28 Nov 2013 09:07:15 +0000 From: Angus Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100312 Lightning/1.0b2pre Shredder/3.0.1 MIME-Version: 1.0 To: Huang Shijie Cc: Lee Jones , Brian Norris , , , , , , Mark Brown , Subject: Re: [PATCH 00/23] mtd: st_spi_fsm: Add new device References: <1385137380-28968-1-git-send-email-lee.jones@linaro.org> <20131127040723.GZ9468@ld-irv-0074.broadcom.com> <20131127115226.GC3296@lee--X1> <5296B9C5.3060704@freescale.com> In-Reply-To: <5296B9C5.3060704@freescale.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.65.49.178] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Huang Shijie, On 11/28/2013 03:34 AM, Huang Shijie wrote: > 于 2013年11月27日 19:52, Lee Jones 写道: >> However, as we send entire 'message sequences' to the FSM Controller >> as opposed to merely OPCODEs we would have to extract the OPCODE from >> flash->command[0] and call our own functions to craft the correct >> 'message sequence' for the task. For this reason we rejected the idea >> and went with a stand-alone driver. >> > could you send me the datasheet of your spi nor controller? > I can change my code if it really not good enough. I will reply to the "mtd: spi-nor" thread regarding the proposed framework, but a couple of answers to your specific questions below. > > we can store the opcode to a field, such as spi_nor_write_op. >> The framework which Huang is proposing suffers from the same issues. >> Only providing read(), write(), read_reg() and write_reg() doesn't >> work for our use-case, as we'd have to decode the flash->command[0] and >> invoke our own internal routines as before. >> >> The only framework with would work for us would consist almost all >> of the important functions such as; read(), write(), erase(), >> wait_busy(), read_jedec(), read_status_reg(), write_status_reg(), >> read_control_reg(), write_control_reg(), etc. However, this approach >> > read_jedec() can be replaced by read_reg(0x9f); > > read_status() can be replaced by read_reg(0x5); > > .... > > write_control_reg() can be replaced by write_reg(xx). Unfortunately the H/W Controller in question comes with a few restrictions. One restriction is that data must be read in multiples of 4 bytes. As such, it would not be able to honour a call of "flash->read_reg(flash, OPCODE_RDID, id, 5);" Of course, if the H/W driver knows that we are issuing a read_jedec() operation, then it can make the assumption that over-reading is benign, and we can instead read 8 bytes of data from the Flash device, and return 5 to the caller. However, without knowing what operation is being requested, no such assumption can be made. > Please correct me if i am wrong. > > IMHO, the current four hooks for spi-nor{} can do all the things. > > read/write/read_reg/write_reg. As it stands, the spi-nor framework cannot support the requirements of the st_spi_fsm controller. I will go into further details on the "mtd: spi-nor" thread. Cheers, Angus -- ------------------------------------- Angus Clark ST Microelectronics (R&D) Ltd. 1000 Aztec West, Bristol, BS32 4SQ email: angus.clark@st.com tel: +44 (0) 1454 462389 st-tina: 065 2389 -------------------------------------