Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1585273
| From | Boris Brezillon <boris.brezillon@free-electrons.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() |
| Date | 2017-02-21 13:50 +0100 |
| Message-ID | <tdi3f-2DN-3@gated-at.bofh.it> (permalink) |
| References | <td3xg-1sB-9@gated-at.bofh.it> <td3xg-1sB-13@gated-at.bofh.it> <tdgkO-1pa-23@gated-at.bofh.it> <tdguu-1L2-27@gated-at.bofh.it> <tdhqx-2nT-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, 21 Feb 2017 13:02:48 +0100 Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote: > On 21/02/2017 12:06, Boris Brezillon wrote: > > > Marc Gonzalez wrote: > > > >> On 20/02/2017 22:12, Boris Brezillon wrote: > >> > >>> Some NAND controllers can assign different NAND timings to different > >>> CS lines. Pass the CS line information to ->setup_data_interface() so > >>> that the NAND controller driver knows which CS line is concerned by > >>> the setup_data_interface() request. > >> > >> I'm confused, because I thought I was already doing that. > >> On my platform, I have different timings for each chip. > >> (thus, for each CS, right?) > >> > >> In chip->select_chip, I program the appropriate timings > >> which the controller will be using. > >> > >> What am I missing? > > > > Maybe you don't have multi-dies chips, which is the case I'm fixing > > here. If you have 2 separate chips, the existing hook should work just > > fine. > > Right. You asked me to add an explicit: > > res = of_property_count_u32_elems(np, "reg"); > if (res < 0) > return res; > > if (res != 1) > return -ENOTSUPP; /* Multi-CS chips are not supported */ > > I was under the impression that multi-die chips are seen as a single > larger "composite" chip. And I had assumed that different dies would > not only require identical timings, but would also be identical in > all other aspects. This it incorrect? This is correct, except some chips (that's true at least for ONFI compatible ones) allow dynamic configuration of timings, and each die can be configured in a different timing mode. That's what's happening when you reset dies. They will automatically enter timing mode 0 (the slowest mode), and you have to explicitly set them back to timing mode X (the fastest supported mode). While doing that, you'll have some of your dies configured in timing 0, while others have already been switched to timing mode X, and that's the main reason for having per-die timing configuration.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RESEND PATCH 0/3] mtd: nand: atmel: Add ->setup_data_interface() + PM ops Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-02-20 22:20 +0100
[RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-02-20 22:20 +0100
Re: [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() Marc Gonzalez <marc_gonzalez@sigmadesigns.com> - 2017-02-21 12:00 +0100
Re: [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-02-21 12:10 +0100
Re: [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() Marc Gonzalez <marc_gonzalez@sigmadesigns.com> - 2017-02-21 13:10 +0100
Re: [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-02-21 13:50 +0100
[RESEND PATCH 2/3] mtd: nand: atmel: Add ->setup_data_interface() hooks Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-02-20 22:20 +0100
Re: [RESEND PATCH 2/3] mtd: nand: atmel: Add ->setup_data_interface() hooks Marek Vasut <marek.vasut@gmail.com> - 2017-02-20 23:50 +0100
Re: [RESEND PATCH 2/3] mtd: nand: atmel: Add ->setup_data_interface() hooks Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-02-21 09:20 +0100
csiph-web