2010/9/30 Kyungmin Park <kyungmin.p...@samsung.com>:
> On Thu, Sep 30, 2010 at 1:09 PM, Chris Ball <c...@laptop.org> wrote:
>> Hi,
>>
>> On Wed, Sep 29, 2010 at 11:42:01PM -0400, Nicolas Pitre wrote:
>>> As I already said here:
>>>
>>>       http://article.gmane.org/gmane.linux.ports.arm.omap/39411
>>>
>>> I find those callbacks rather problematic.  Currently,
>>> mmc_host_disable() is called by the host driver (currently OMAP) and
>>> that's wrong.  Such decision cannot be made in the controller driver --
>>> it has to be made higher up the stack.
>>
>> I strongly agree.  I hadn't noticed that aspect of this design until
>> today.  It looked like Linus W had a nice core-integrated clocking
>> framework almost ready to go a year ago, but it lost out.  (Something
>> left to do was to give extra time after a request in case we're on a
>> broken card which requires the card clock to be present during its
>> writeback.)
>
> Do you mean this one?
> http://www.mail-archive.com/linux-embed...@vger.kernel.org/msg01883.html

That's it. If there is interest I can surely pick it up and wrap the
current enable/disable calls around it or even rewrite all drivers
to use the set_ios() approach as in this patchset I think.

What happened was that I had this iterated a few times as Pierre was
getting increasingly overloaded and it was on the verge of merging
when he resigned as MMC maintainer.

The next week or so the big hammer callbacks from OMAP were
merged as part of their mainline procedure.

> In previous time it used for our kernel and find it's difficult to
> handle and maintain and can't support the SD card.
> So try to find another method and implemente it at SDHCI drivers.

Why? The only difference between this solution and the one
that is inside the kernel now is that this will use set_ios() with
a zero argument to gate off the clock after a timeout instead
of special callbacks. (A features especially requested by Pierre.)

I can move the timeing code to wrap the current callbacks
instead atleast that would make things more according to spec.

For MMC cards that is.

For SD cards IIRC the spec is the same, but in practice all
SD cards (and especially all MicroSD and eMMCs we see these
days) survive gating the clock off like these current callbacks do.
That I believe is why people have so little trouble with the present
code.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to