On Thu, Oct 8, 2015 at 9:54 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > [...] > >>> 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. > > Yes, I totally understand and thanks for your support. > >> >> 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. > > I realize that, but I would very much appreciate if you give it try - > I think it should be doable. > > Of course, you will need to change the "sdhci core" to suite your > needs and normally people do that via adding callbacks and quirks. > Perhaps you can keep my request in mind of turning sdhci into a > library and thus limit the number of added quirks and callbacks... > >> >> 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. >> > > Well, that won't help the current HW so I would encourage you to do > the "sdhci variant" work anyway. Likely it will also benefit you when > you try to upstream the next variant of the driver to cope with your > new HW. > > Kind regards > Uffe Thanks for your quick reply. We will use the "standard" sdhci variant to cope with our new HW as you suggest. Maybe it will take us a long time, but we will try to do it. -- 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
