On 29.11.2012 15:59, Philip, Avinash wrote:
> On Thu, Nov 29, 2012 at 18:11:42, Daniel Mack wrote:
>> On 29.11.2012 13:36, Philip, Avinash wrote:
>>> On Wed, Nov 28, 2012 at 22:28:59, Daniel Mack wrote:
>>> [...]
>>>> + if (!of_property_read_string(child, "ti,nand-ecc-opt", &s)) {
>>>> + for (val = 0; val < ARRAY_SIZE(nand_ecc_opts); val++)
>>>> + if (!strcasecmp(s, nand_ecc_opts[val])) {
>>>> + gpmc_nand_data->ecc_opt = val;
>>>> + break;
>>>> + }
>>>> +
>>>> + /*
>>>> + * AM335x RBL compatibility mode - dependns on runtime
>>>> + * detection of the error location module.
>>>> + */
>>>> + if (!strcasecmp(s, "bch8-am335xrbl-compatible")) {
>>>> + gpmc_nand_data->ecc_opt = OMAP_ECC_BCH8_CODE_HW;
>>>> + gpmc_nand_data->is_elm_used = true;
>>>
>>> Remove is_elm_used from struct omap_nand_platform_data. Now this data
>>> populated as part of run time detection of elm module. So please remove
>>> The usage of is_elm_used;
>>
>> So why do we need "bch8-am335xrbl-compatible" as special case then?
>>
>> I thought the whole idea here is to tell the driver we want bch8 *and*
>> the usage of the elm, instead of falling back to the (incompatible)
>> software mode? If I remove that assignment, "bch8-am335xrbl-compatible"
>> is the same than "bch8".
>>
>
> Here we have different problems present.
> 1. GPMC-NAND DT binding support.
> 2. Compatible ECC layout between kernel, boot loader.
> 3. Support for hardware accelerator, i.e ELM for error correction.
>
> So priority should go for GPMC DT binding support.
> Can you please proceed with GPMC-NAND DT bindings without considering
> ELM so that driver features existing can be obtained with DT.
>
> I will take care of ECC layout (or RBL) compatibility along with ELM
> series. I will make ELM series on top of your changes. This way we can
> avoid circular dependency
Ok, fair enough. I'll drop "bch8-am335xrbl-compatible" from the list
again and only care for those that are present in the enum.
Before I send the patches again, could you quickly state which
repository they will go through? I'll make sure there are no conflicts
when applying.
>> Which detail am I missing? :)
>
> I think what you need is NAND ECC layout to be common across Kernel and
> boot loader. Strictly speaking ELM is not a necessity for it. The common
> layout can be obtained even without presence of ELM, ELM is only a hardware
> accelerator for error correction. If ELM is not used, we can rely on software
> error correction, at least theoretically. But the way software error correction
> is handled currently in omap nand driver will not help us as ecc layout assumed
> is different.
Yes, understood, hence I need some workaround for now, which I can
happily keep in my local branch.
Thanks,
Daniel
--
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
