On Thu, Oct 8, 2015 at 9:54 PM, Ulf Hansson [off-list ref] wrote:

[...]

quoted

quoted

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.

quoted

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...

quoted

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.