Re: [PATCH 1/3i v6] MMC/SD: Add callback function to detect card

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2013/3/22 Ulf Hansson <ulf.hansson@xxxxxxxxxx>:
> On 22 March 2013 08:42, Huang Changming-R66093 <r66093@xxxxxxxxxxxxx> wrote:
>>
>> <r66093@xxxxxxxxxxxxx>:
>>> >> >> Jerry,
>>> >> >>
>>> >> >> Function _mmc_detect_card_removed should only be called when card
>>> >> >> insert/removal or i/o error occur unless POLLING is used(called
>>> >> >> once per second). So it should _not_ impact performance much.
>>> >> > [jerry]
>>> >> > No, your understanding is wrong.
>>> >> > Function "_mmc_detect_card_removed " is called to check if our card
>>> >> > has
>>> >> been removed when driver run the function "mmc_rescan" every time.
>>> >> >
>>> >>
>>> >> But when will mmc_rescan be called?
>>> >> Besides boot up, only when card status change it will be called.
>>> >> So usually it should _not_ be called frequently.
>>> > [jerry]
>>> > For poll mode, how to know card status changed?
>>> > The answer is "mmc_rescan".
>>> > maybe you could read the last two lines of this function ago.
>>> >
>>>
>>> I mentioned this in my first response "unless POLLING is used(called once
>>> per second)". I was a bit confused firstly.
>>> I think slot-gpio is a better solution, with which you don't need the
>>> every second polling.
>> [jerry]
>> Not all Soc has GPIO to do this. our controller has the pin to detect the card status, need the external hardware to support it.
>> But due to some reasons, some boards don't do this work, so need the poll mode for all boards.
>>
>>> >> >> POLLING is poor for performance, why not change to slot-gpio if
>>> >> >> host is broken for card detect.
>>> >> > [jerry]
>>> >> > Some our boards can't support interrupt mode to detect card
>>> >> insert/removable, so we unify the poll mode.
>>> >> >
>>> >>
>>> >> Not support gpio interrupt?
>>> >> I think you only don't support sdh host interrupt.
>>> >
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
>>
>>
>
> A suggestion; the poll time out is 1s today. We could make some more
> intelligent update to the timeout value so we decrease the number of
> timeouts to happen. In other words minimize the number of mmc_rescan
> to be executed.
>
> 1. When no card is inserted, use 1 s.
> 2. When card is inserted, switch to 30 s timeout. The card removal
> will be detected anyway when a blk err occurs, due to that
> mmc_detect_card_removed will be called from the block layer at error
> handling path.
>

Ulf,

Sounds good! But I have one concern:
If the card is removed when there is no i/o access. Then the
mmc_rescan won't run until 30 seconds later (just imagine the worst
case). If within 30 seconds, the card is inserted again or another
different card is inserted, then issue may occur.

Then I have a suggestion as below:
1. keep current code as 1 second in mmc_rescan for polling.
2. When an i/o request come, we can cancel current delay work and
reschedule the delay detect work after 1 second from that point.
3. If next i/o request come within 1 second, we can reschedule the
detect work after 1 second from that point again.

So during continuous i/o operations, there will be no mmc_rescan execution.
Once i/o operation stopped, the mmc_rescan will be called every 1 second.
This way can solve above issue.
How do you think?

Thanks
Kevin

> Any thoughts?
>
> Kind regards
> Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux