On Thu, Nov 29, 2012 at 20:37:20, Daniel Mack wrote:
> 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.
I believe it should go through the OMAP trees.
Thanks
Avinash
>
> >> 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
