Hi Ulf,
Thanks for reviewing this, it was very helpful!
> 1. mmc_detect_change does obviously not have to be run the same number
> of times as the mmc_rescan function. In other words, the calls to
> __pm_stay_awake is not paired with __pm_relay, I suppose this does not
> matter?
It shouldn't, sinc
Hi Zoran,
On 13 June 2013 19:56, Zoran Markovic wrote:
> This is a reworked implementation of wakelocks for the MMC core from
> Android kernel, originally authored by Colin Cross and San Mehat.
> The patch makes sure that whenever a MMC device is inserted/removed,
> the system stays awake until i
On 22 August 2013 19:08, Zoran Markovic wrote:
> Ulf,
>> I got confirmation from Broadcom that all cell phone reference designs
>> have card insert/removal configured as a wakeup IRQ. Unless our
>> customers change that - which I doubt - this results in a considerable
>> number of products impleme
Ulf,
> I got confirmation from Broadcom that all cell phone reference designs
> have card insert/removal configured as a wakeup IRQ. Unless our
> customers change that - which I doubt - this results in a considerable
> number of products implementing this feature.
>
> Please let me know how you wis
Ulf,
I got confirmation from Broadcom that all cell phone reference designs
have card insert/removal configured as a wakeup IRQ. Unless our
customers change that - which I doubt - this results in a considerable
number of products implementing this feature.
Please let me know how you wish to procee
On 24 June 2013 21:58, Zoran Markovic wrote:
>>> This patch is ported from the Android common tree, so you've probably
>>> been using it.
>>
>> We removed more or less all Android code in the mmc subsystem, since
>> it just didn't work. :-)
>>
>> The "deferred resume" was very useful though, so af
>> This patch is ported from the Android common tree, so you've probably
>> been using it.
>
> We removed more or less all Android code in the mmc subsystem, since
> it just didn't work. :-)
>
> The "deferred resume" was very useful though, so after some rework we
> kept it and could then improve t
On 19 June 2013 19:29, Colin Cross wrote:
> On Wed, Jun 19, 2013 at 7:21 AM, Ulf Hansson wrote:
>> It seems like a bad idea that an insertion of an SD card should
>> trigger the display to be light up. That is indirectly in principle
>> what you suggest should happen from user space once a new SD
On Wed, Jun 19, 2013 at 7:21 AM, Ulf Hansson wrote:
> It seems like a bad idea that an insertion of an SD card should
> trigger the display to be light up. That is indirectly in principle
> what you suggest should happen from user space once a new SD card is
> found. Right?
Most likely what will
On 18 June 2013 19:15, Colin Cross wrote:
> On Tue, Jun 18, 2013 at 6:17 AM, Ulf Hansson wrote:
>> On 17 June 2013 20:33, Colin Cross wrote:
>>> This is a generic requirement for using a kernel with autosleep
>>> enabled. Autosleep will enter suspend whenever there is no wakeup
>>> source/wakel
On Tue, Jun 18, 2013 at 6:17 AM, Ulf Hansson wrote:
> On 17 June 2013 20:33, Colin Cross wrote:
>> This is a generic requirement for using a kernel with autosleep
>> enabled. Autosleep will enter suspend whenever there is no wakeup
>> source/wakelock held. Consider the following sequence:
>>
>>
On 17 June 2013 20:33, Colin Cross wrote:
> On Mon, Jun 17, 2013 at 7:22 AM, Ulf Hansson wrote:
>> On 14 June 2013 22:52, Colin Cross wrote:
>>> On Fri, Jun 14, 2013 at 11:42 AM, Zoran Markovic
>>> wrote:
> I am not sure I understand why this patch is needed. When a new card
> is insert
On Mon, Jun 17, 2013 at 7:22 AM, Ulf Hansson wrote:
> On 14 June 2013 22:52, Colin Cross wrote:
>> On Fri, Jun 14, 2013 at 11:42 AM, Zoran Markovic
>> wrote:
I am not sure I understand why this patch is needed. When a new card
is inserted/removed and the upper levels gets notification
On 14 June 2013 22:52, Colin Cross wrote:
> On Fri, Jun 14, 2013 at 11:42 AM, Zoran Markovic
> wrote:
>>> I am not sure I understand why this patch is needed. When a new card
>>> is inserted/removed and the upper levels gets notification about the
>>> new card, triggering the mounting/un-mounting
On Fri, Jun 14, 2013 at 11:42 AM, Zoran Markovic
wrote:
>> I am not sure I understand why this patch is needed. When a new card
>> is inserted/removed and the upper levels gets notification about the
>> new card, triggering the mounting/un-mounting of the file system, why
>> should it be the lowes
> I am not sure I understand why this patch is needed. When a new card
> is inserted/removed and the upper levels gets notification about the
> new card, triggering the mounting/un-mounting of the file system, why
> should it be the lowest layer (mmc) that prevents the platform from
> enter suspend
On 13 June 2013 19:56, Zoran Markovic wrote:
> This is a reworked implementation of wakelocks for the MMC core from
> Android kernel, originally authored by Colin Cross and San Mehat.
> The patch makes sure that whenever a MMC device is inserted/removed,
> the system stays awake until it's reconfi
This is a reworked implementation of wakelocks for the MMC core from
Android kernel, originally authored by Colin Cross and San Mehat.
The patch makes sure that whenever a MMC device is inserted/removed,
the system stays awake until it's reconfigured for the new state.
It is assumed that 1/2 second
18 matches
Mail list logo
