On 14/06/16 23:10, H. Nikolaus Schaller wrote: > Hi, > >> Am 14.06.2016 um 20:17 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: >> >> Hi Roger, >> >>> Am 08.06.2016 um 12:05 schrieb Roger Quadros <rogerq@xxxxxx>: >>> >> >>> >>> one at https://github.com/goldelico/gta04-kernel/blob/letux-4.7-rc1/arch/arm/boot/dts/omap3-gta04.dtsi#L602 >>> &gpmc { >>> ranges = <0 0 0x30000000 0x1000000>; /* CS0: 16MB for NAND */ >>> >>> nand@0,0 { >>> compatible = "ti,omap2-nand"; >>> reg = <0 0 4>; /* CS0, offset 0, IO size 4 */ >>> >>> and again at https://github.com/goldelico/gta04-kernel/blob/letux-4.7-rc1/arch/arm/boot/dts/omap3-gta04.dtsi#L1122 >> >> Therefore we merge on top of linus/master a private patch which - for simplicity (it is very difficult to track changes >> in the middle of a DT) it appends a second &gmpc node and relies on the DTC to do what should have been (will >> have been) merged in source code. >> >> Without these patches (introduced on our private kernel in 3.19) NAND did not work. >> >>> &gpmc { >>> ranges = <0 0 0x30000000 0x04>; /* CS0: NAND */ >>> >>> nand@0,0 { >>> reg = <0 0 0>; /* CS0, offset 0 */ >>> ti,nand-ecc-opt = "sw"; /* stay compatible with our old u-boot (does not support bch8) */ >>> >>> kernel@280000 { >>> reg = <0x280000 0x600000>; >>> }; >>> >>> filesystem@a80000 { >>> reg = <0x880000 0>; /* 0 = MTDPART_SIZ_FULL */ >>> }; >>> }; >>> }; >>> >>> >>> In the latter part ranges and reg property is wrong. Just get rid of it. >> >> No, they work on our setup. The original ranges / reg setting did not work. > > I have found what went wrong. > > There was upstream commit e2c5eb78a3cc9b0d69ae924c33da50a4cd6d1fa4 which > did fix these ranges, but we didn't get really aware of this change. > > Almost at the same time we rearranged the device tree file as described - starting with > our local copy which we thought to be correct. > > During rearrangement we found a discrepancy between what we had been working on > before and what we did find in linux/master. So we did falsely assume that we were right > and not linus/master and need to upstream this diff later on (which never happened). Hence > the diff was added to the second &gpmc node starting to make problems in 4.7-rc1. > > So you are right that we should try to get rid of the ranges / reg modification, if it passes tests. > And hopefully the gpio problem disappears with this. There are two separate issues. 1) GPIO-irqchip failing on an unrelated GPIO due to a bug in gpio irqchip code. This triggers when the GPMC CS resource allocation fails. This is fixed in v4.7-rc3 with the below 2 commits http://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=fixes&id=11f33a6d15bfa397867ac0d7f3481b6dd683286f http://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=fixes&id=f4833b8cc7edab57d3f3033e549111a546c2e02b 2) GPMC CS resource failing This is because of the invalid ranges property. This must be fixed in your local patches. -- cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
