| Message ID | 1399668412-10818-1-git-send-email-pekon@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hello Pekon, On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote: > From: Minal Shah <minalkshah@gmail.com> > > DRA7xx platform has in-build GPMC and ELM h/w engines which can be used > for accessing externel NAND flash device. This patch: > - adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines > - adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm > *Important* > On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch > So following board settings are required for NAND device detection: > SW5.9 (GPMC_WPN) = LOW > SW5.1 (NAND_BOOTn) = HIGH > > Signed-off-by: Minal Shah <minalkshah@gmail.com> > Signed-off-by: Pekon Gupta <pekon@ti.com> > --- > arch/arm/boot/dts/dra7-evm.dts | 117 +++++++++++++++++++++++++++++++++++++++++ > arch/arm/boot/dts/dra7.dtsi | 20 +++++++ > 2 files changed, 137 insertions(+) > > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts > index 5f1f6da..ed4e974 100644 > --- a/arch/arm/boot/dts/dra7-evm.dts > +++ b/arch/arm/boot/dts/dra7-evm.dts > @@ -108,6 +108,37 @@ > 0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs3.qspi1_cs1 */ > >; > }; > + > + nand_flash_x16: nand_flash_x16 { > + /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch > + * So NAND flash requires following switch settings: > + * SW5.9 (GPMC_WPN) = LOW > + * SW5.1 (NAND_BOOTn) = HIGH */ > + pinctrl-single,pins = < > + 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */ > + 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1 */ > + 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2 */ > + 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3 */ > + 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4 */ > + 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5 */ > + 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6 */ > + 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7 */ > + 0x20 (PIN_INPUT | MUX_MODE0) /* gpmc_ad8 */ > + 0x24 (PIN_INPUT | MUX_MODE0) /* gpmc_ad9 */ > + 0x28 (PIN_INPUT | MUX_MODE0) /* gpmc_ad10 */ > + 0x2C (PIN_INPUT | MUX_MODE0) /* gpmc_ad11 */ > + 0x30 (PIN_INPUT | MUX_MODE0) /* gpmc_ad12 */ > + 0x34 (PIN_INPUT | MUX_MODE0) /* gpmc_ad13 */ > + 0x38 (PIN_INPUT | MUX_MODE0) /* gpmc_ad14 */ > + 0x3C (PIN_INPUT | MUX_MODE0) /* gpmc_ad15 */ > + 0xd8 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0 */ > + 0xcc (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen */ > + 0xb4 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0 */ > + 0xc4 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale */ > + 0xc8 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren */ > + 0xd0 (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle */ > + >; > + }; > }; > > &i2c1 { > @@ -353,3 +384,89 @@ > }; > }; > }; > + > +&elm { > + status = "okay"; > +}; > + > +&gpmc { > + status = "okay"; > + pinctrl-names = "default"; > + pinctrl-0 = <&nand_flash_x16>; > + ranges = <0 0 0 0x1000000>; > + nand@0,0 { > + reg = <0 0 0x380>; > + ti,nand-ecc-opt = "bch8"; > + ti,elm-id = <&elm>; > + nand-bus-width = <16>; > + gpmc,device-width = <2>; > + gpmc,sync-clk-ps = <0>; > + gpmc,cs-on-ns = <0>; > + gpmc,cs-rd-off-ns = <40>; > + gpmc,cs-wr-off-ns = <40>; > + gpmc,adv-on-ns = <0>; > + gpmc,adv-rd-off-ns = <30>; > + gpmc,adv-wr-off-ns = <30>; > + gpmc,we-on-ns = <5>; > + gpmc,we-off-ns = <25>; > + gpmc,oe-on-ns = <2>; > + gpmc,oe-off-ns = <20>; > + gpmc,access-ns = <20>; > + gpmc,wr-access-ns = <40>; > + gpmc,rd-cycle-ns = <40>; > + gpmc,wr-cycle-ns = <40>; > + gpmc,wait-on-read = "true"; > + gpmc,wait-on-write = "true"; > + gpmc,bus-turnaround-ns = <0>; > + gpmc,cycle2cycle-delay-ns = <0>; > + gpmc,clk-activation-ns = <0>; > + gpmc,wait-monitoring-ns = <0>; > + gpmc,wr-data-mux-bus-ns = <0>; > + /* MTD partition table */ > + /* All SPL-* partitions are sized to minimal length > + * which can be independently programmable. For > + * NAND flash this is equal to size of erase-block */ > + #address-cells = <1>; > + #size-cells = <1>; > + partition@0 { > + label = "NAND.SPL"; > + reg = <0x00000000 0x000020000>; > + }; > + partition@1 { > + label = "NAND.SPL.backup1"; > + reg = <0x00020000 0x00020000>; > + }; > + partition@2 { > + label = "NAND.SPL.backup2"; > + reg = <0x00040000 0x00020000>; > + }; > + partition@3 { > + label = "NAND.SPL.backup3"; > + reg = <0x00060000 0x00020000>; > + }; > + partition@4 { > + label = "NAND.u-boot-spl-os"; > + reg = <0x00080000 0x00040000>; > + }; > + partition@5 { > + label = "NAND.u-boot"; > + reg = <0x000c0000 0x00100000>; > + }; > + partition@6 { > + label = "NAND.u-boot-env"; > + reg = <0x001c0000 0x00020000>; > + }; > + partition@7 { > + label = "NAND.u-boot-env"; > + reg = <0x001e0000 0x00020000>; > + }; > + partition@8 { > + label = "NAND.kernel"; > + reg = <0x00200000 0x00800000>; > + }; > + partition@9 { > + label = "NAND.file-system"; > + reg = <0x00a00000 0x0f600000>; > + }; > + }; > +}; > diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi > index 37a0595..6af775a 100644 > --- a/arch/arm/boot/dts/dra7.dtsi > +++ b/arch/arm/boot/dts/dra7.dtsi > @@ -776,6 +776,26 @@ > interrupts = <0 343 0x4>; > status = "disabled"; > }; > + > + elm: elm@48078000 { > + compatible = "ti,am3352-elm"; > + reg = <0x48078000 0x2000>; It is really necessary to map all this 8 KB address space for GPMC registers? I don't have access to the DRA7 TRM but for example the OMAP3 TRM says that the GPMC module register address space size is 16 MB while in practice the registers use less than 1 KB (0..0x02d0 to be exact) so in arch/arm/boot/dts/omap3.dtsi we have: gpmc: gpmc@6e000000 { ... reg = <0x6e000000 0x02d0>; ... }; Shouldn't this be similar (the same?) for DRA7 GPMC device node? Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGVsbG8sDQoNCkZyb206IEphdmllciBNYXJ0aW5leiBDYW5pbGxhcyBbbWFpbHRvOmphdmllckBk b3doaWxlMC5vcmddDQo+T24gRnJpLCBNYXkgOSwgMjAxNCBhdCAxMDo0NiBQTSwgUGVrb24gR3Vw dGEgPHBla29uQHRpLmNvbT4gd3JvdGU6DQo+PiBGcm9tOiBNaW5hbCBTaGFoIDxtaW5hbGtzaGFo QGdtYWlsLmNvbT4NClsuLi5dDQo+PiArJmdwbWMgew0KPj4gKyAgICAgICBzdGF0dXMgPSAib2th eSI7DQo+PiArICAgICAgIHBpbmN0cmwtbmFtZXMgPSAiZGVmYXVsdCI7DQo+PiArICAgICAgIHBp bmN0cmwtMCA9IDwmbmFuZF9mbGFzaF94MTY+Ow0KPj4gKyAgICAgICByYW5nZXMgPSA8MCAwIDAg MHgxMDAwMDAwPjsNCj4+ICsgICAgICAgbmFuZEAwLDAgew0KPj4gKyAgICAgICAgICAgICAgIHJl ZyA9IDwwIDAgMHgzODA+Ow0KWy4uLl0NCg0KPj4gZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jvb3Qv ZHRzL2RyYTcuZHRzaSBiL2FyY2gvYXJtL2Jvb3QvZHRzL2RyYTcuZHRzaQ0KPj4gaW5kZXggMzdh MDU5NS4uNmFmNzc1YSAxMDA2NDQNCj4+IC0tLSBhL2FyY2gvYXJtL2Jvb3QvZHRzL2RyYTcuZHRz aQ0KPj4gKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMvZHJhNy5kdHNpDQo+PiBAQCAtNzc2LDYgKzc3 NiwyNiBAQA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJydXB0cyA9IDwwIDM0MyAw eDQ+Ow0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgc3RhdHVzID0gImRpc2FibGVkIjsNCj4+ ICAgICAgICAgICAgICAgICB9Ow0KPj4gKw0KPj4gKyAgICAgICAgICAgICAgIGVsbTogZWxtQDQ4 MDc4MDAwIHsNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAidGksYW0z MzUyLWVsbSI7DQo+PiArICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHg0ODA3ODAwMCAw eDIwMDA+Ow0KPg0KPkl0IGlzIHJlYWxseSBuZWNlc3NhcnkgdG8gbWFwIGFsbCB0aGlzIDggS0Ig YWRkcmVzcyBzcGFjZSBmb3IgR1BNQyByZWdpc3RlcnM/DQo+DQo+SSBkb24ndCBoYXZlIGFjY2Vz cyB0byB0aGUgRFJBNyBUUk0gYnV0IGZvciBleGFtcGxlIHRoZSBPTUFQMyBUUk0gc2F5cw0KPnRo YXQgdGhlIEdQTUMgbW9kdWxlIHJlZ2lzdGVyIGFkZHJlc3Mgc3BhY2Ugc2l6ZSBpcyAxNiBNQiB3 aGlsZSBpbg0KPnByYWN0aWNlIHRoZSByZWdpc3RlcnMgdXNlIGxlc3MgdGhhbiAxIEtCICgwLi4w eDAyZDAgdG8gYmUgZXhhY3QpIHNvDQo+aW4gYXJjaC9hcm0vYm9vdC9kdHMvb21hcDMuZHRzaSB3 ZSBoYXZlOg0KPg0KVGhlc2UgYXJlIG5vdCBHUE1DIHJlZ2lzdGVycy4gUGxhdGZvcm1zIGZyb20g T01BUDQgYW5kIGJleW9uZA0KKGxpa2UgQU0zMzV4LCBPTUFQNSkgaGF2ZSBhbm90aGVyIHNtYWxs IGhhcmR3YXJlIGVuZ2luZSBjYWxsZWQgRUxNIFsxXQ0KKEVycm9yIExvY2F0ZXIgTW9kdWxlKSBp biBhZGRpdGlvbiB0byBHUE1DLCB3aGljaCBpcyB1c2VkIGZvciBkZXRlY3RpbmcNCkVDQyBlcnJv cnMgaW4gaGFyZHdhcmUuIEVMTSBEcml2ZXIgJEtFUk5FTC9kcml2ZXJzL210ZC9kZXZpY2VzL2Vs bS5jDQoNCkhvd2V2ZXIsIHRoYW5rcyBmb3IgcG9pbnRpbmcgb3V0LCB0aGlzIGFkZHJlc3Mtc3Bh Y2UgZm9yIEVMTSBpcyBpbmNvcnJlY3QuDQpMYXN0IEVMTSByZWdpc3RlciBvZmZzZXQgaXMgMHhG QzAgKEVMTV9FUlJPUl9MT0NBVElPTl8xNV83KSBbMV0uDQoNCj5ncG1jOiBncG1jQDZlMDAwMDAw IHsNCj4uLi4NCj4gICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHg2ZTAwMDAwMCAweDAy ZDA+Ow0KPi4uLg0KPn07DQo+DQo+U2hvdWxkbid0IHRoaXMgYmUgc2ltaWxhciAodGhlIHNhbWU/ KSBmb3IgRFJBNyBHUE1DIGRldmljZSBub2RlPw0KPg0KTmV3ZXIgcGxhdGZvcm1zIGhhdmUgdXBn cmFkZWQgdmVyc2lvbiBvZiBHUE1DIGVuZ2luZSB3aGljaCBzdXBwb3J0cw0KQkNIMTYgRUNDIHNj aGVtZSBpbiBoYXJkd2FyZS4gVGh1cyB0aGUgR1BNQyBhZGRyZXNzIHNwYWNlIHdhcw0KZXhwYW5k ZWQgdG8gaW5jbHVkZSBzb21lIGV4dHJhIHJlZ2lzdGVycyByZXF1aXJlZCBmb3IgQkNIMTYgRUND IFsyXS4NCg0KDQo+VGhhbmtzIGEgbG90IGFuZCBiZXN0IHJlZ2FyZHMsDQo+SmF2aWVyDQoNClsx XSBodHRwOi8vd3d3LnRpLmNvbS9saXQvZ3BuL2FtMzM1OSAgICAoU2VjdGlvbiA3LjQgdG8gNy40 LjUpDQoNClsyXSBodHRwOi8vd3d3LnRpLmNvbS9saXQvZ3BuL2FtMzM1OSAgICAoU2VjdGlvbiA3 LjEgdG8gNy4xLjUpDQooVGhvdWdoIHRoZSBBTTMzNXggYWRkcmVzcyBzcGFjZSBtZW50aW9ucyAw eDM2OCBhcyBsYXN0IGFkZHJlc3MsDQogaXQgc2hvdWxkIGJlIDB4Mzc4LiBJIGhhdmUgcmFpc2Vk IGRvY3VtZW50YXRpb24gYnVnIGZvciBpdCkuDQoNCg0Kd2l0aCByZWdhcmRzLCBwZWtvbg0K -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Pekon, On Mon, May 12, 2014 at 9:03 AM, Gupta, Pekon <pekon@ti.com> wrote: > Hello, > > From: Javier Martinez Canillas [mailto:javier@dowhile0.org] >>On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote: >>> From: Minal Shah <minalkshah@gmail.com> > [...] >>> +&gpmc { >>> + status = "okay"; >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&nand_flash_x16>; >>> + ranges = <0 0 0 0x1000000>; >>> + nand@0,0 { >>> + reg = <0 0 0x380>; > [...] > >>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi >>> index 37a0595..6af775a 100644 >>> --- a/arch/arm/boot/dts/dra7.dtsi >>> +++ b/arch/arm/boot/dts/dra7.dtsi >>> @@ -776,6 +776,26 @@ >>> interrupts = <0 343 0x4>; >>> status = "disabled"; >>> }; >>> + >>> + elm: elm@48078000 { >>> + compatible = "ti,am3352-elm"; >>> + reg = <0x48078000 0x2000>; >> >>It is really necessary to map all this 8 KB address space for GPMC registers? >> >>I don't have access to the DRA7 TRM but for example the OMAP3 TRM says >>that the GPMC module register address space size is 16 MB while in >>practice the registers use less than 1 KB (0..0x02d0 to be exact) so >>in arch/arm/boot/dts/omap3.dtsi we have: >> > These are not GPMC registers. Platforms from OMAP4 and beyond > (like AM335x, OMAP5) have another small hardware engine called ELM [1] > (Error Locater Module) in addition to GPMC, which is used for detecting > ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c > Yes, I know what ELM is, I just made a mistake when adding my comments inline. I actually meant the 8KB from the following device node: > + gpmc: gpmc@50000000 { > + compatible = "ti,am3352-gpmc"; > + ti,hwmods = "gpmc"; > + reg = <0x50000000 0x2000>; > + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; > + gpmc,num-cs = <8>; > + gpmc,num-waitpins = <2>; > + #address-cells = <2>; > + #size-cells = <1>; > + status = "disabled"; > + }; > However, thanks for pointing out, this address-space for ELM is incorrect. > Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1]. > And yes, comments applies to ELM register address space as well. >>gpmc: gpmc@6e000000 { >>... >> reg = <0x6e000000 0x02d0>; >>... >>}; >> >>Shouldn't this be similar (the same?) for DRA7 GPMC device node? >> > Newer platforms have upgraded version of GPMC engine which supports > BCH16 ECC scheme in hardware. Thus the GPMC address space was > expanded to include some extra registers required for BCH16 ECC [2]. > > I see and did the GPMC register space became that big to need to map 8KB? Although the smallest unit for ioremap is PAGE_SIZE and using any of these reg sizes: reg = <0x6e000000 0x02d0>; reg = <0x6e000000 0x0400>; reg = <0x6e000000 0x1000>; in practice have the same effect, DTS should describe the hardware and not an implementation detail so I think that we should use only the register size that is defined in the TRM. > > [1] http://www.ti.com/lit/gpn/am3359 (Section 7.4 to 7.4.5) > > [2] http://www.ti.com/lit/gpn/am3359 (Section 7.1 to 7.1.5) > (Though the AM335x address space mentions 0x368 as last address, > it should be 0x378. I have raised documentation bug for it). > > > with regards, pekon Best regards, Javier [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>From: Javier Martinez Canillas [mailto:javier@dowhile0.org] [...] >> Newer platforms have upgraded version of GPMC engine which supports >> BCH16 ECC scheme in hardware. Thus the GPMC address space was >> expanded to include some extra registers required for BCH16 ECC [2]. >> >> > >I see and did the GPMC register space became that big to need to map 8KB? > >Although the smallest unit for ioremap is PAGE_SIZE and using any of >these reg sizes: > >reg = <0x6e000000 0x02d0>; >reg = <0x6e000000 0x0400>; >reg = <0x6e000000 0x1000>; > >in practice have the same effect, DTS should describe the hardware and >not an implementation detail so I think that we should use only the >register size that is defined in the TRM. > Yes, I agree with you. I have fixed this in newer version of the patch and will be sending it soon. But this series will only contain updates for new platforms with addition of NAND node in DTS, so that this series is not stalled for any reason. For fixing existing platform/boards DTS I'll send another series soon. For now, I'll use GPMC address-space size = 0x380 as it matches with actual hardware and is working. >> >> [1] http://www.ti.com/lit/gpn/am3359 (Section 7.4 to 7.4.5) >> >> [2] http://www.ti.com/lit/gpn/am3359 (Section 7.1 to 7.1.5) >> (Though the AM335x address space mentions 0x368 as last address, >> it should be 0x378. I have raised documentation bug for it). >> >> >> with regards, pekon > >Best regards, >Javier > >[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
On Mon, May 12, 2014 at 11:05 AM, Gupta, Pekon <pekon@ti.com> wrote: >>From: Javier Martinez Canillas [mailto:javier@dowhile0.org] > [...] > >>> Newer platforms have upgraded version of GPMC engine which supports >>> BCH16 ECC scheme in hardware. Thus the GPMC address space was >>> expanded to include some extra registers required for BCH16 ECC [2]. >>> >>> >> >>I see and did the GPMC register space became that big to need to map 8KB? >> >>Although the smallest unit for ioremap is PAGE_SIZE and using any of >>these reg sizes: >> >>reg = <0x6e000000 0x02d0>; >>reg = <0x6e000000 0x0400>; >>reg = <0x6e000000 0x1000>; >> >>in practice have the same effect, DTS should describe the hardware and >>not an implementation detail so I think that we should use only the >>register size that is defined in the TRM. >> > Yes, I agree with you. > I have fixed this in newer version of the patch and will be sending it soon. > But this series will only contain updates for new platforms with addition > of NAND node in DTS, so that this series is not stalled for any reason. > For fixing existing platform/boards DTS I'll send another series soon. > Yes, I agree that fixing existing platforms is a matter of a different series, I just didn't want to introduce more :-) > For now, I'll use GPMC address-space size = 0x380 as it matches with > actual hardware and is working. > Perfect, thanks a lot! >>> >>> [1] http://www.ti.com/lit/gpn/am3359 (Section 7.4 to 7.4.5) >>> >>> [2] http://www.ti.com/lit/gpn/am3359 (Section 7.1 to 7.1.5) >>> (Though the AM335x address space mentions 0x368 as last address, >>> it should be 0x378. I have raised documentation bug for it). >>> >>> >>> with regards, pekon >> >>Best regards, >>Javier >> >>[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334 Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Pekon, On 05/12/2014 12:05 PM, Gupta, Pekon wrote: >> From: Javier Martinez Canillas [mailto:javier@dowhile0.org] > [...] > >>> Newer platforms have upgraded version of GPMC engine which supports >>> BCH16 ECC scheme in hardware. Thus the GPMC address space was >>> expanded to include some extra registers required for BCH16 ECC [2]. >>> >>> >> >> I see and did the GPMC register space became that big to need to map 8KB? >> >> Although the smallest unit for ioremap is PAGE_SIZE and using any of >> these reg sizes: >> >> reg = <0x6e000000 0x02d0>; >> reg = <0x6e000000 0x0400>; >> reg = <0x6e000000 0x1000>; >> >> in practice have the same effect, DTS should describe the hardware and >> not an implementation detail so I think that we should use only the >> register size that is defined in the TRM. >> > Yes, I agree with you. > I have fixed this in newer version of the patch and will be sending it soon. > But this series will only contain updates for new platforms with addition > of NAND node in DTS, so that this series is not stalled for any reason. > For fixing existing platform/boards DTS I'll send another series soon. > > For now, I'll use GPMC address-space size = 0x380 as it matches with > actual hardware and is working. How did you get 0x380? From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0 So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide) For the ELM module it should be 4KB i.e. 0x1000 cheers, -roger >>> >>> [1] http://www.ti.com/lit/gpn/am3359 (Section 7.4 to 7.4.5) >>> >>> [2] http://www.ti.com/lit/gpn/am3359 (Section 7.1 to 7.1.5) >>> (Though the AM335x address space mentions 0x368 as last address, >>> it should be 0x378. I have raised documentation bug for it). >>> >>> >>> with regards, pekon >> >> Best regards, >> Javier >> >> [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334 > ?{.n?+???????+%??lzwm??b????r??zX??&j??????}????z?&j:+v???????zZ+??+zf???h???~????i???z? ?w????????&?)?f > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGkgUm9nZXIsDQoNCj4+DQo+PiBGb3Igbm93LCBJJ2xsIHVzZSBHUE1DIGFkZHJlc3Mtc3BhY2Ug c2l6ZSA9IDB4MzgwIGFzIGl0IG1hdGNoZXMgd2l0aA0KPj4gYWN0dWFsIGhhcmR3YXJlIGFuZCBp cyB3b3JraW5nLg0KPg0KPkhvdyBkaWQgeW91IGdldCAweDM4MD8NCj4NCj5Gcm9tIERSQTcgVFJN LCBHUE1DIGFkZHJlc3MgcmFuZ2UgaXMgMHg1MDAwIDAwMDAgOiAweDUwMDAgMDJEMA0KPlNvIHRo ZSBhZGRyZXNzLXNwYWNlIHNpemUgc2hvdWxkIGJlIDB4MkQ0IChhcyBsYXN0IHJlZ2lzdGVyQDJE MCBpcyAzMi1iaXRzIHdpZGUpDQo+DQpJIHRoaW5rIHRoYXQgaXMgY29weS1wYXN0ZSBlcnJvciBp biBkb2N1bWVudGF0aW9uLg0KSW4gdGhlIHNhbWUgVFJNLCB5b3UgJ2xsIGZpbmQgdGhlIGNvcnJl Y3QgYWRkcmVzcyBvZmZzZXRzIGZvciBHUE1DIFJlZ2lzdGVycyBpbiBiZWxvdw0KKlNlY3Rpb246 IDE1LjQuNy4xIEdQTUMgUmVnaXN0ZXIgU3VtbWFyeSoNClJlZ2lzdGVyICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFN0YXJ0aW5nIE9mZnNldCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEVuZCBPZmZzZXQNCkdQTUNfQkNIX1JFU1VMVDRfaSAgICAweDAwMDAg MDMwMCArICgweDAwMDAgMDAxMCAqIGkpICAgICAweDUwMDAgMDMwMCArICgweDAwMDAgMDAxMCAq IGkpDQpHUE1DX0JDSF9SRVNVTFQ1X2kgICAgMHgwMDAwIDAzMDQgKyAoMHgwMDAwIDAwMTAgKiBp KSAgICAgMHg1MDAwIDAzMDQgKyAoMHgwMDAwIDAwMTAgKiBpKQ0KR1BNQ19CQ0hfUkVTVUxUNl9p ICAgIDB4MDAwMCAwMzA4ICsgKDB4MDAwMCAwMDEwICogaSkgICAgIDB4NTAwMCAwMzA4ICsgKDB4 MDAwMCAwMDEwICogaSkNCldoZXJlIGkgPSAwIHRvIDcgLi4gDQoNClNvIHRoYXQgbWFrZXMgbGFz dCBhZGRyZXNzIDB4NTAwMF8wMzc4IChmb3IgR1BNQ19CQ0hfUkVTVUxUNl83KQ0KQXMgdGhlIGVh Y2ggcmVnaXN0ZXIgYmFuayAoaSkgaXMgaW5jcmVtZW50aW5nIGF0IDB4MTAsIHNvIGxhc3QgYWNj ZXNzaWJsZSBhZGRyZXNzIGlzIDB4MzdGLg0KDQpJIGhhdmUgYWxyZWFkeSByYWlzZWQgZG9jdW1l bnRhdGlvbiBidWcgZm9yIEFNMzM1eCBUUk0sDQpOZWVkIHRvIHJhaXNlIHRoZSBzYW1lIGZvciBE UkE3eHggVFJNLg0KDQo+Rm9yIHRoZSBFTE0gbW9kdWxlIGl0IHNob3VsZCBiZSA0S0IgaS5lLiAw eDEwMDANCj4NClllcywgdGhhdCBpcyBjb3JyZWN0LiBJIGhhdmUgZml4ZWQgdGhhdCBub3cuDQoN Cg0KPmNoZWVycywNCj4tcm9nZXINCj4NCj4+Pj4NCj4+Pj4gWzFdIGh0dHA6Ly93d3cudGkuY29t L2xpdC9ncG4vYW0zMzU5ICAgIChTZWN0aW9uIDcuNCB0byA3LjQuNSkNCj4+Pj4NCj4+Pj4gWzJd IGh0dHA6Ly93d3cudGkuY29tL2xpdC9ncG4vYW0zMzU5ICAgIChTZWN0aW9uIDcuMSB0byA3LjEu NSkNCj4+Pj4gKFRob3VnaCB0aGUgQU0zMzV4IGFkZHJlc3Mgc3BhY2UgbWVudGlvbnMgMHgzNjgg YXMgbGFzdCBhZGRyZXNzLA0KPj4+PiAgaXQgc2hvdWxkIGJlIDB4Mzc4LiBJIGhhdmUgcmFpc2Vk IGRvY3VtZW50YXRpb24gYnVnIGZvciBpdCkuDQoNCg0Kd2l0aCByZWdhcmRzLCBwZWtvbg0K -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/14/2014 11:25 AM, Roger Quadros wrote: > Hi Pekon, > > On 05/12/2014 12:05 PM, Gupta, Pekon wrote: >>> From: Javier Martinez Canillas [mailto:javier@dowhile0.org] >> [...] >> >>>> Newer platforms have upgraded version of GPMC engine which supports >>>> BCH16 ECC scheme in hardware. Thus the GPMC address space was >>>> expanded to include some extra registers required for BCH16 ECC [2]. >>>> >>>> >>> >>> I see and did the GPMC register space became that big to need to map 8KB? >>> >>> Although the smallest unit for ioremap is PAGE_SIZE and using any of >>> these reg sizes: >>> >>> reg = <0x6e000000 0x02d0>; >>> reg = <0x6e000000 0x0400>; >>> reg = <0x6e000000 0x1000>; >>> >>> in practice have the same effect, DTS should describe the hardware and >>> not an implementation detail so I think that we should use only the >>> register size that is defined in the TRM. >>> >> Yes, I agree with you. >> I have fixed this in newer version of the patch and will be sending it soon. >> But this series will only contain updates for new platforms with addition >> of NAND node in DTS, so that this series is not stalled for any reason. >> For fixing existing platform/boards DTS I'll send another series soon. >> >> For now, I'll use GPMC address-space size = 0x380 as it matches with >> actual hardware and is working. > > How did you get 0x380? > > From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0 > So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide) Sorry for the noise. Just figured out that the register space is not numerically arranged in the TRM. The last register is P GPMC_BCH_RESULT6_i 0x5000 0308 + (0x0000 0010 * i) i = 0 to 7 So size should be 0x37C. cheers, -roger > > For the ELM module it should be 4KB i.e. 0x1000 > > cheers, > -roger > >>>> >>>> [1] http://www.ti.com/lit/gpn/am3359 (Section 7.4 to 7.4.5) >>>> >>>> [2] http://www.ti.com/lit/gpn/am3359 (Section 7.1 to 7.1.5) >>>> (Though the AM335x address space mentions 0x368 as last address, >>>> it should be 0x378. I have raised documentation bug for it). >>>> >>>> >>>> with regards, pekon >>> >>> Best regards, >>> Javier >>> >>> [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334 >> ?{.n?+???????+%??lzwm??b????r??zX??&j??????}????z?&j:+v???????zZ+??+zf???h???~????i???z? ?w????????&?)?f >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>From: Quadros, Roger [...] >>> For now, I'll use GPMC address-space size = 0x380 as it matches with >>> actual hardware and is working. >> >> How did you get 0x380? >> >> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0 >> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide) > >Sorry for the noise. >Just figured out that the register space is not numerically arranged in the TRM. > >The last register is P GPMC_BCH_RESULT6_i > 0x5000 0308 + (0x0000 0010 * i) > i = 0 to 7 > >So size should be 0x37C. > Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10, so I aligned the last address to 0x380 boundary. Hope leaving room for extra 4 bytes (0x380 - 0x37C) will not matter much? All platforms from OMAP4 onwards share the same version of GPMC engine. So this remains consistent. Only OMAP3 has older version of GPMC engine which has register-space till 0x2d0. >cheers, >-roger > with regards, pekon
On 05/14/2014 12:09 PM, Gupta, Pekon wrote: >> From: Quadros, Roger > [...] > >>>> For now, I'll use GPMC address-space size = 0x380 as it matches with >>>> actual hardware and is working. >>> >>> How did you get 0x380? >>> >>> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0 >>> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide) >> >> Sorry for the noise. >> Just figured out that the register space is not numerically arranged in the TRM. >> >> The last register is P GPMC_BCH_RESULT6_i >> 0x5000 0308 + (0x0000 0010 * i) >> i = 0 to 7 >> >> So size should be 0x37C. >> > Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10, > so I aligned the last address to 0x380 boundary. Hope leaving room for > extra 4 bytes (0x380 - 0x37C) will not matter much? Functionally it won't matter but it always good to describe the hardware as accurately as possible and avoid confusion to future developers as to why extra 4 bytes were used in the device tree. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 14, 2014 at 11:17 AM, Roger Quadros <rogerq@ti.com> wrote: > On 05/14/2014 12:09 PM, Gupta, Pekon wrote: >>> From: Quadros, Roger >> [...] >> >>>>> For now, I'll use GPMC address-space size = 0x380 as it matches with >>>>> actual hardware and is working. >>>> >>>> How did you get 0x380? >>>> >>>> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0 >>>> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide) >>> arch/arm/boot/dts/omap3.dtsi is using reg = <0x6e000000 0x02d0> so that should be fixed to 0x2d4 too. >>> Sorry for the noise. >>> Just figured out that the register space is not numerically arranged in the TRM. >>> >>> The last register is P GPMC_BCH_RESULT6_i >>> 0x5000 0308 + (0x0000 0010 * i) >>> i = 0 to 7 >>> >>> So size should be 0x37C. >>> >> Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10, >> so I aligned the last address to 0x380 boundary. Hope leaving room for >> extra 4 bytes (0x380 - 0x37C) will not matter much? > > Functionally it won't matter but it always good to describe the hardware as > accurately as possible and avoid confusion to future developers as to why > extra 4 bytes were used in the device tree. > I don't think that aligning makes too much sense since in practice ioremap() will map a complete page anyways so if we are not using 0x1000 (e.g: PAGE_SIZE on ARM) is just because we want the DT to strictly model what the hardware registers address size really is. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 5f1f6da..ed4e974 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -108,6 +108,37 @@ 0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs3.qspi1_cs1 */ >; }; + + nand_flash_x16: nand_flash_x16 { + /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch + * So NAND flash requires following switch settings: + * SW5.9 (GPMC_WPN) = LOW + * SW5.1 (NAND_BOOTn) = HIGH */ + pinctrl-single,pins = < + 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */ + 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1 */ + 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2 */ + 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3 */ + 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4 */ + 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5 */ + 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6 */ + 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7 */ + 0x20 (PIN_INPUT | MUX_MODE0) /* gpmc_ad8 */ + 0x24 (PIN_INPUT | MUX_MODE0) /* gpmc_ad9 */ + 0x28 (PIN_INPUT | MUX_MODE0) /* gpmc_ad10 */ + 0x2C (PIN_INPUT | MUX_MODE0) /* gpmc_ad11 */ + 0x30 (PIN_INPUT | MUX_MODE0) /* gpmc_ad12 */ + 0x34 (PIN_INPUT | MUX_MODE0) /* gpmc_ad13 */ + 0x38 (PIN_INPUT | MUX_MODE0) /* gpmc_ad14 */ + 0x3C (PIN_INPUT | MUX_MODE0) /* gpmc_ad15 */ + 0xd8 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0 */ + 0xcc (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen */ + 0xb4 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0 */ + 0xc4 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale */ + 0xc8 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren */ + 0xd0 (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle */ + >; + }; }; &i2c1 { @@ -353,3 +384,89 @@ }; }; }; + +&elm { + status = "okay"; +}; + +&gpmc { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&nand_flash_x16>; + ranges = <0 0 0 0x1000000>; + nand@0,0 { + reg = <0 0 0x380>; + ti,nand-ecc-opt = "bch8"; + ti,elm-id = <&elm>; + nand-bus-width = <16>; + gpmc,device-width = <2>; + gpmc,sync-clk-ps = <0>; + gpmc,cs-on-ns = <0>; + gpmc,cs-rd-off-ns = <40>; + gpmc,cs-wr-off-ns = <40>; + gpmc,adv-on-ns = <0>; + gpmc,adv-rd-off-ns = <30>; + gpmc,adv-wr-off-ns = <30>; + gpmc,we-on-ns = <5>; + gpmc,we-off-ns = <25>; + gpmc,oe-on-ns = <2>; + gpmc,oe-off-ns = <20>; + gpmc,access-ns = <20>; + gpmc,wr-access-ns = <40>; + gpmc,rd-cycle-ns = <40>; + gpmc,wr-cycle-ns = <40>; + gpmc,wait-on-read = "true"; + gpmc,wait-on-write = "true"; + gpmc,bus-turnaround-ns = <0>; + gpmc,cycle2cycle-delay-ns = <0>; + gpmc,clk-activation-ns = <0>; + gpmc,wait-monitoring-ns = <0>; + gpmc,wr-data-mux-bus-ns = <0>; + /* MTD partition table */ + /* All SPL-* partitions are sized to minimal length + * which can be independently programmable. For + * NAND flash this is equal to size of erase-block */ + #address-cells = <1>; + #size-cells = <1>; + partition@0 { + label = "NAND.SPL"; + reg = <0x00000000 0x000020000>; + }; + partition@1 { + label = "NAND.SPL.backup1"; + reg = <0x00020000 0x00020000>; + }; + partition@2 { + label = "NAND.SPL.backup2"; + reg = <0x00040000 0x00020000>; + }; + partition@3 { + label = "NAND.SPL.backup3"; + reg = <0x00060000 0x00020000>; + }; + partition@4 { + label = "NAND.u-boot-spl-os"; + reg = <0x00080000 0x00040000>; + }; + partition@5 { + label = "NAND.u-boot"; + reg = <0x000c0000 0x00100000>; + }; + partition@6 { + label = "NAND.u-boot-env"; + reg = <0x001c0000 0x00020000>; + }; + partition@7 { + label = "NAND.u-boot-env"; + reg = <0x001e0000 0x00020000>; + }; + partition@8 { + label = "NAND.kernel"; + reg = <0x00200000 0x00800000>; + }; + partition@9 { + label = "NAND.file-system"; + reg = <0x00a00000 0x0f600000>; + }; + }; +}; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 37a0595..6af775a 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -776,6 +776,26 @@ interrupts = <0 343 0x4>; status = "disabled"; }; + + elm: elm@48078000 { + compatible = "ti,am3352-elm"; + reg = <0x48078000 0x2000>; + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; + ti,hwmods = "elm"; + status = "disabled"; + }; + + gpmc: gpmc@50000000 { + compatible = "ti,am3352-gpmc"; + ti,hwmods = "gpmc"; + reg = <0x50000000 0x2000>; + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <2>; + #address-cells = <2>; + #size-cells = <1>; + status = "disabled"; + }; }; };