2013-07-02 05:30:08

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
schemes") and 212012138deb ("mtd: nand: omap2: updated support for BCH4
ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM: OMAP2+:
Allow NAND transfer mode to be specified in DT") from the arm-soc tree.

I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).

--
Cheers,
Stephen Rothwell [email protected]

diff --cc Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index b3f23df,df338cb..0000000
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@@ -17,59 -17,27 +17,66 @@@ Required properties

Optional properties:

- - nand-bus-width: Set this numeric value to 16 if the hardware
- is wired that way. If not specified, a bus
- width of 8 is assumed.
+ - nand-bus-width: Determines data-width of the connected device
+ x16 = "16"
+ x8 = "8" (default)

- - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:

- "sw" Software method (default)
- "hw" Hardware method
- "hw-romcode" gpmc hamming mode method & romcode layout
- "bch4" 4-bit BCH ecc code
- "bch8" 8-bit BCH ecc code
+ - ti,nand-ecc-opt: Determines the ECC scheme used by driver.
+ It can be any of the following strings:
+
+ "hamming_code_sw" 1-bit Hamming ECC
+ - ECC calculation in software
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+
+ "hamming_code_hw" 1-bit Hamming ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+
+ "hamming_code_hw_romcode" 1-bit Hamming ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with ROM code
+
+ "bch4_code_hw_detection_sw" 4-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+ * depends on CONFIG_MTD_NAND_ECC_BCH
+
+ "bch4_code_hw" 4-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in hardware
+ - ECC layout compatible with ROM code
+ * depends on CONFIG_MTD_NAND_OMAP_BCH
+ * requires <elm_id> to be specified
+
+ "bch8_code_hw_detection_sw" 8-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible with S/W scheme
+ * depends on CONFIG_MTD_NAND_ECC_BCH
+
+ "bch8_code_hw" 8-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in hardware
+ - ECC layout compatible with ROM code
+ * depends on CONFIG_MTD_NAND_OMAP_BCH
+ * requires <elm_id> to be specified

+ - ti,nand-xfer-type: A string setting the data transfer type. One of:
+
+ "prefetch-polled" Prefetch polled mode (default)
+ "polled" Polled mode, without prefetch
+ "prefetch-dma" Prefetch enabled sDMA mode
+ "prefetch-irq" Prefetch enabled irq mode
+
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
+
+ - elm_id: Specifies elm device node. This is required to
+ support some BCH ECC schemes mentioned above.
+

For inline partiton table parsing (optional):


Attachments:
(No filename) (3.41 kB)
(No filename) (836.00 B)
Download all attachments

2013-07-02 05:47:45

by Gupta, Pekon

[permalink] [raw]
Subject: RE: linux-next: manual merge of the arm-soc tree with the l2-mtd tree

>
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
> BCH4
> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
> OMAP2+:
> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
>
> I fixed it up (maybe - see below) and can carry the fix as necessary (no
> action is required).
>
> --
> Cheers,
> Stephen Rothwell [email protected]
>
Yes following merge is correct. Apologies, as there were multiple OMAP2 NAND and GPMC updates and clean-up going into different trees, so these conflict came. Going forward you shouldn't find such issues, as code is more stable now. Thanks for help.

with regards, pekon

> diff --cc Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index b3f23df,df338cb..0000000
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@@ -17,59 -17,27 +17,66 @@@ Required properties
>
> Optional properties:
>
> - - nand-bus-width: Set this numeric value to 16 if the hardware
> - is wired that way. If not specified, a bus
> - width of 8 is assumed.
> + - nand-bus-width: Determines data-width of the connected
> device
> + x16 = "16"
> + x8 = "8" (default)
>
> - - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
>
> - "sw" Software method (default)
> - "hw" Hardware method
> - "hw-romcode" gpmc hamming mode method & romcode
> layout
> - "bch4" 4-bit BCH ecc code
> - "bch8" 8-bit BCH ecc code
> + - ti,nand-ecc-opt: Determines the ECC scheme used by driver.
> + It can be any of the following strings:
> +
> + "hamming_code_sw" 1-bit Hamming ECC
> + - ECC calculation in software
> + - Error detection in software
> + - ECC layout compatible with S/W
> scheme
> +
> + "hamming_code_hw" 1-bit Hamming ECC
> + - ECC calculation in hardware
> + - Error detection in software
> + - ECC layout compatible with S/W
> scheme
> +
> + "hamming_code_hw_romcode" 1-bit Hamming ECC
> + - ECC calculation in hardware
> + - Error detection in software
> + - ECC layout compatible with ROM
> code
> +
> + "bch4_code_hw_detection_sw" 4-bit BCH ECC
> + - ECC calculation in hardware
> + - Error detection in software
> + - ECC layout compatible with S/W
> scheme
> + * depends on
> CONFIG_MTD_NAND_ECC_BCH
> +
> + "bch4_code_hw" 4-bit BCH ECC
> + - ECC calculation in hardware
> + - Error detection in hardware
> + - ECC layout compatible with ROM
> code
> + * depends on
> CONFIG_MTD_NAND_OMAP_BCH
> + * requires <elm_id> to be specified
> +
> + "bch8_code_hw_detection_sw" 8-bit BCH ECC
> + - ECC calculation in hardware
> + - Error detection in software
> + - ECC layout compatible with S/W
> scheme
> + * depends on
> CONFIG_MTD_NAND_ECC_BCH
> +
> + "bch8_code_hw" 8-bit BCH ECC
> + - ECC calculation in hardware
> + - Error detection in hardware
> + - ECC layout compatible with ROM
> code
> + * depends on
> CONFIG_MTD_NAND_OMAP_BCH
> + * requires <elm_id> to be specified
>
> + - ti,nand-xfer-type: A string setting the data transfer type. One
> of:
> +
> + "prefetch-polled" Prefetch polled mode (default)
> + "polled" Polled mode, without prefetch
> + "prefetch-dma" Prefetch enabled sDMA
> mode
> + "prefetch-irq" Prefetch enabled irq mode
> +
> - - elm_id: Specifies elm device node. This is required to support BCH
> - error correction using ELM module.
> +
> + - elm_id: Specifies elm device node. This is required to
> + support some BCH ECC schemes mentioned
> above.
> +
>
> For inline partiton table parsing (optional):
>

2013-07-02 06:00:47

by Olof Johansson

[permalink] [raw]
Subject: Re: linux-next: manual merge of the arm-soc tree with the l2-mtd tree

On Mon, Jul 1, 2013 at 10:44 PM, Gupta, Pekon <[email protected]> wrote:
>>
>> Hi all,
>>
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
>> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
>> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
>> BCH4
>> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
>> OMAP2+:
>> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
>>
>> I fixed it up (maybe - see below) and can carry the fix as necessary (no
>> action is required).
>>
>> --
>> Cheers,
>> Stephen Rothwell [email protected]
>>
> Yes following merge is correct. Apologies, as there were multiple OMAP2 NAND and GPMC updates and clean-up going into different trees, so these conflict came. Going forward you shouldn't find such issues, as code is more stable now. Thanks for help.
>
> with regards, pekon

Sigh. The new bindings seem to never have been reviewed by any device
tree maintainers, and from the look of it, it might need some
discussion. It wasn't even cc:d to devicetree-discuss.

It's completely inappropriate to merge a patch like this at this time
without any kind of acks from the people reviewing bindings. Can it
please be dropped ASAP from the MTD tree? Thanks!

Or, if you want it in different wording: The mtd-tree patch is a
strong NAK until this has been sorted out.

It was also applied today, after the merge window opened. Don't merge
it for 3.11. Artem?


-Olof

2013-07-02 06:21:48

by Gupta, Pekon

[permalink] [raw]
Subject: RE: linux-next: manual merge of the arm-soc tree with the l2-mtd tree

>
> On Mon, Jul 1, 2013 at 10:44 PM, Gupta, Pekon <[email protected]> wrote:
> >>
> >> Hi all,
> >>
> >> Today's linux-next merge of the arm-soc tree got a conflict in
> >> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between
> commits
> >> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
> >> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
> >> BCH4
> >> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
> >> OMAP2+:
> >> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
> >>
> >> I fixed it up (maybe - see below) and can carry the fix as necessary (no
> >> action is required).
> >>
> >> --
> >> Cheers,
> >> Stephen Rothwell [email protected]
> >>
> > Yes following merge is correct. Apologies, as there were multiple OMAP2
> NAND and GPMC updates and clean-up going into different trees, so these
> conflict came. Going forward you shouldn't find such issues, as code is more
> stable now. Thanks for help.
> >
> > with regards, pekon
>
> Sigh. The new bindings seem to never have been reviewed by any device
> tree maintainers, and from the look of it, it might need some
> discussion. It wasn't even cc:d to devicetree-discuss.
>
> It's completely inappropriate to merge a patch like this at this time
> without any kind of acks from the people reviewing bindings. Can it
> please be dropped ASAP from the MTD tree? Thanks!
>
> Or, if you want it in different wording: The mtd-tree patch is a
> strong NAK until this has been sorted out.
>
> It was also applied today, after the merge window opened. Don't merge
> it for 3.11. Artem?
>
>
Hi OIof,

You may drop this patch if you wish so, but its not correct to say that this
was not reviewed. Following are comments from "Arnd Bergmann"
http://lists.infradead.org/pipermail/linux-mtd/2013-May/047030.html
And follow-up reasoning..
http://lists.infradead.org/pipermail/linux-mtd/2013-May/047032.html


And based on Arnd's feedbacks patches which contained changes in
binding string was even dropped from the series, please see
cover-letter of V3 set below.
http://lists.infradead.org/pipermail/linux-mtd/2013-June/047319.html
- PATCH-4 <DROPPED> update DT attribute for ti,nand-ecc-opt
- received feedback to keep DT mapping independent of linuxism
- PATCH-4:<NEW> : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
- independent patch for AM335x-evm.dts update based on PATCH-2

So, in case you have objections to same earlier patch where I had
introduced 'linux-based' nomenclature for bindings, that particular
one is already dropped in V3 of this patch series.


with regards, pekon

2013-07-02 07:26:11

by Artem Bityutskiy

[permalink] [raw]
Subject: Re: linux-next: manual merge of the arm-soc tree with the l2-mtd tree

On Mon, 2013-07-01 at 23:00 -0700, Olof Johansson wrote:
> It was also applied today, after the merge window opened. Don't merge
> it for 3.11. Artem?

OK, dropping it.

--
Best Regards,
Artem Bityutskiy

2013-07-02 07:28:50

by Artem Bityutskiy

[permalink] [raw]
Subject: Re: linux-next: manual merge of the arm-soc tree with the l2-mtd tree

On Tue, 2013-07-02 at 06:18 +0000, Gupta, Pekon wrote:
> You may drop this patch if you wish so, but its not correct to say that this
> was not reviewed. Following are comments from "Arnd Bergmann"
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/047030.html
> And follow-up reasoning..
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/047032.html

Pekon, let me drop these 3 patches so far anyway. Please, re-submit it
with CC to the devicetree-discuss mailing list. Thanks!

--
Best Regards,
Artem Bityutskiy