Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1240294 > unrolled thread

Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC Ulf Hansson <ulf.hansson@linaro.org> - 2015-10-06 11:20 +0200
    Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC Hongtao Wu <wuht06@gmail.com> - 2015-10-08 15:40 +0200
      Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC Ulf Hansson <ulf.hansson@linaro.org> - 2015-10-08 16:00 +0200
        Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC Hongtao Wu <wuht06@gmail.com> - 2015-10-09 15:30 +0200

#1240294 — Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC

+Russell

On 28 September 2015 at 09:18, Hongtao Wu <wuht06@gmail.com> wrote:
>>>
>
> On Thu, Sep 10, 2015 at 9:28 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> On 14 August 2015 at 18:55, Hongtao Wu <wuht06@gmail.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1242357

On Tue, Oct 6, 2015 at 5:18 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> +Russell
>
> On 28 September 2015 at 09:18, Hongtao Wu <wuht06@gmail.com> wrote:
>>>>
>>
>> On Thu, Sep 10, 2015 at 9:28 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>>
>>> On 14 August 2015 at 18:55, Hongtao Wu <wuht06@gmail.com> 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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242388

[...]

>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243365

On Thu, Oct 8, 2015 at 9:54 PM, Ulf Hansson <ulf.hansson@linaro.org> 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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web