On Mon, Nov 22, 2010 at 10:22 PM, Philip Rakity <prakity@xxxxxxxxxxx> wrote: > > I implemented the first sdhci-pxa.c controller for the pxa168 over a year ago. Also fixed issues on Tavor. > > This approach is not sufficient to make Aspen nor Tavor work. > > There are a number of silicon issues that need to be addressed. > > > > > On Nov 22, 2010, at 7:16 PM, zhangfei gao wrote: > >> On Mon, Nov 22, 2010 at 9:55 PM, Chris Ball <cjb@xxxxxxxxxx> wrote: >>> Hi, >>> >>> On Mon, Nov 22, 2010 at 09:46:14PM -0500, Mark F. Brown wrote: >>>>> config MMC_SDHCI_PXA >>>>> tristate "Marvell PXA168/PXA910/MMP2 SD Host Controller support" >>>>> - depends on ARCH_PXA || ARCH_MMP >>>>> + depends on (ARCH_PXA || ARCH_MMP) && (MACH_MARVELL_JASPER || MACH_FLINT) >>>>> select MMC_SDHCI >>>>> select MMC_SDHCI_IO_ACCESSORS >>>>> help >>>>> - This selects the Marvell(R) PXA168/PXA910/MMP2 SD Host Controller. >>>>> - If you have a PXA168/PXA910/MMP2 platform with SD Host Controller >>>>> + This selects the Marvell(R) MMP2 SD Host Controller. >>>>> + If you have a MMP2 platform with SD Host Controller >>>>> and a card slot, say Y or M here. >>>> >>>> Currently the driver sdhci-pxa only supports the 88AP610 (MMP2) >>>> platform only. Until the sdhci-pxa code fixed or forked to support >>>> pxa168 and pxa910 we need to Philip's patch. Any feedback on this >>>> would be good thanks. >>> >> The patch "sdhci-pxa: init_sdh for different platform" already >> submitted, to be merged. >> The platfrom specific register accessing are move to arch >> for mmp2, arch/arm/mach-mmp/include/mach/mmp2_sdh.h >> for pxa168, another file may be needed >> arch/arm/mach-mmp/include/mach/pxa168_sdh.h Zhangfei, I think Philip is correct here. You need to add support for PXA168 and PXA910 before you declare support for it in the Kconfig. When the proper accessors and support are added for those platforms then you can add the Kconfig entries. If MMP2 is currently the only supported platform, then we should just mention CPU_MMP2. >> >>> I don't mind changing the Kconfig text, but tying an SoC-level host >>> controller to dependencies on specific machines seems pretty wrong. >>> We should ask Haojian and Eric what they think. I think Philip >>> suggested using CPU_MMP2 at one point -- how about that? >>> Chris I agree CPU_MMP2 is better here. >>> -- >>> Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/> >>> One Laptop Per Child >>> > > -- 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
