On 05/27/2015 09:37 AM, Arnd Bergmann wrote:
> On Sunday 24 May 2015 20:32:29 Hauke Mehrtens wrote:
>> @@ -124,17 +124,7 @@
>> <0x00026000 0 &gic GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
>>
>> /* Ethernet Controller 3 */
>> - <0x00027000 0 &gic GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
>> -
>> - /* NAND Controller */
>> - <0x00028000 0 &gic GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 1 &gic GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 2 &gic GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 3 &gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 4 &gic GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 5 &gic GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 6 &gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
>> - <0x00028000 7 &gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>> + <0x00027000 0 &gic GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
>>
>> chipcommon: chipcommon@0 {
>> reg = <0x00000000 0x1000>;
>> @@ -143,4 +133,30 @@
>> #gpio-cells = <2>;
>> };
>> };
>> +
>> + nand: nand@18028000 {
>> + compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1", "brcm,brcmnand";
>> + reg = <0x18028000 0x600>, <0x1811a408 0x600>, <0x18028f00 0x20>;
>> + reg-names = "nand", "iproc-idm", "iproc-ext";
>> + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
>
> I think I'd rather leave the interrupt-map in the brcm node, and use
>
> interrupts = <0>;
>
> here.
There are two conflicting interests ;-)
In the first approach we probed the NAND controller through bcma and
just added the additional information we can not probe through device
tree. That was this version:
https://patchwork.ozlabs.org/patch/473181/
This version needs some changes to the brcmnand driver and this
additional part:
https://patchwork.ozlabs.org/patch/473182/
This code is simular to the iproc_nand.c
Brian wanted us to use the iproc_nand.c which is possible, but then we
completely ignore what we have probed in bcma and only use device tree.
And this nand driver is not a subnode of the bcma bus any more so we can
not use the irqs defined there.
>
>> + status = "disabled";
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + brcm,nand-has-wp;
>> +
>> + nandcs@0 {
>> + compatible = "brcm,nandcs";
>> + reg = <0>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + nand-ecc-strength = <8>;
>> + nand-ecc-step-size = <512>;
>> +
>> + linux,part-probe = "ofpart", "bcm47xxpart";
>> + };
>> + };
>
> This seems fine in principle, once the exact binding has been nailed down.
>
> "bcm47xxpart" does not seem like an appropriate string here.
We are already thinking and talking about how to solve this problem.
There are some parsers that are able to parse some partition layout
based on information various sources or some vendor headers and some are
also guessing in addition, like they are assuming that the bootloader is
in the first block and n bytes long. The current module is that the
flash driver defines which partition parsers to take, it is hard coded
into the code. I do not like that. ;-)
I am trying to get a simple patch in which makes it possible to
overwrite the defaults from the flash driver with device tree.
As it uses the same format it should be easy to convert devices from the
old style to the new one. This deice tree attribute is already supported
by one driver I moved the code to make it available for all drivers.
The patch I am talking about: https://patchwork.ozlabs.org/patch/475988/
Hauke
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
