On Tue, Oct 6, 2015 at 5:18 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > +Russell > > On 28 September 2015 at 09:18, Hongtao Wu <wuht06@xxxxxxxxx> wrote: >>>> >> >> On Thu, Sep 10, 2015 at 9:28 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>> >>> On 14 August 2015 at 18:55, Hongtao Wu <wuht06@xxxxxxxxx> wrote: >>> > the Spreadtrum MMC host driver is used to supply EMMC, SD, and >>> > SDIO types of memory cards >>> >>> Perhaps some more information about the controller. Are there any >>> specific features it support or doesn't support!? >> >> Thanks for kindly reply. >> Yes, spreadtrum MMC host controllers have some specific features as follows: >> (1) We don't have controls for sampling clock tuning and re-tuning, we take >> place of them with three registers as follows: >> (a) CLK_WR_DL(Offset 080h): Data write clock delay line. >> (b) CLK_RD_POS_DL(Offset 0x84h): Posedge data read clock delay line. >> (c) CLK_RD_NEG_DL(Offset 088h): Negedge data read clock delay line. >> >> (2) We don't have Power Control Register(Offset 029h), all our controller's >> power >> come from PMIC, rather than directly from CPU. >> >> (3) We don't have bit[6](Card Insertion), bit[7] (Card Removal), bit[8] >> (Card Interrupt) >> and bit[12:9] in Normal Interrupt Status Register(Offset 030h). Because the >> detect >> gpio pin doesn't connect to the register of our host controller. So we can't >> operate bit[18:16](Card Detect Pin Level, Card State stable and Card >> Inserted) >> in Present State Register(Offset 024h). > > Thanks for clarifying! > > You have some differences towards the "standard" sdhci variant, but > that doesn't mean you should go off and implement a new driver from > scratch, instead you should create a new sdhci variant and re-use code > from the generic sdhci driver. > > The current problem with such approach, is that the sdhci driver isn't > designed as a library but instead a driver consisting of too many > quirks and callbacks. While you start to adopt your driver towards > sdhci, you will need to add yet another bunch of new quirks and > callbacks to suite your hw. > > Now, as the number of callbacks and quirks continues to increase I > will sooner or later give up maintaining it, as each line of code will > depend on a quirk. So, we need to start turning sdhci into a library > *right now*! Russell King, has pointed out this several times as well, > but unfortunate I haven't yet seen anyone willing to help out in this > field. > > I would of course be very happy if you would like to have a look at > that, but I realize it's a difficult task, So, unless you are happy > with taking on such a challenge, I suggest you go for an intermediate > step, which thus means convert your driver to a sdhci variant driver > and add the quirks/callbacks you need to suite your hw. > > [...] > > Kind regards > Uffe Thanks for kindly suggestion! I think it's a good idea to turn sdhci into a library. But for me it's too difficult to take on such a challenge. However, I will try my best to support you to do it. As you suggested, I will consider converting our eMMC host driver to a sdhci variant driver. However, our controller has some features, which differentiate it from standard sd host controller. For example, our controller doesn't have such functions as follows: tuning or re-tuning, Power Control Register, PIO or ADMA transfer mode, UHS-II and so on. So, if we use sdchi variant driver right now, I think it has a litter redundancy. Now our sdio team are discussing improving our eMMC host controller, we are making it more standardized. But you know, changing a IP block is a long process. Maybe it will take us about one or two years. So what do you think if we use ourself eMMC host driver right now, and convert it when our new host controller is ready. thanks. Hongtao. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
