On 15 January 2016 at 02:38, Wan Zongshun <vw@xxxxxxxxx> wrote: >>> >>> But I also met trouble in sdhci_execute_tuning of sdhci.c, I have to >>> suppose >>> only sdhci_pci_platform_execute_tuning is returning -EPERM(current code, >>> my assumption is right), so that those vendor that has no >>> slot->platform_execute_tuning could be skipped and go next standard >>> tuning process. >>> >>> If you have better idea for my requirement, please correct me. >> >> >> sdhci needs to become a set of library functions. >> >> Typically the mmc_host_ops ->execute_tuning() callback for sdhci, >> should be assigned to a default function, unless the sdhci variant has >> assigned it to something else. >> >> Yes, I realize that it requires core changes to sdhci to allow this. >> Although it's necessary do this conversion as I won't accept any more >> changes for sdhci that doesn't move the code into this direction. >> > > Ulf, > > Then Can you point me what's my next step for submitting tuning workaround > for AMD emmc4.5 driver? > > What your mean is you will change sdhci-pci-core.c to a core and library > function? Not me personally as I don't have the bandwidth to do it. Anybody that cares about sdhci are encouraged to give it a try! > And then I can implement a AMD specific emmc-pci driver call to those libs? The lib should provide common functionality needed among sdhci variants. If there specific needs for any sdhci variant, that variant should implement that part separately without affecting other variants. This isn't the case when adding an sdhci callback/quirk to the sdhci core, as that would affect more or less *all* sdhci variants. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
