On Sep 10, 2015, at 3:13 AM, James Morse wrote:
> On 09/09/15 14:22, Jungseok Lee wrote:
>> On Sep 9, 2015, at 1:47 AM, James Morse wrote:
>>> On 08/09/15 15:54, Jungseok Lee wrote:
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/i
On 09/09/15 14:22, Jungseok Lee wrote:
> On Sep 9, 2015, at 1:47 AM, James Morse wrote:
>> On 08/09/15 15:54, Jungseok Lee wrote:
>>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 463fa2e7e34c..10b57a006da8 100644
On Sep 9, 2015, at 1:47 AM, James Morse wrote:
> On 08/09/15 15:54, Jungseok Lee wrote:
>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>>
>> Hi James,
>>
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index e16351819fed..d42371f3f5a1 100644
>>> --- a/arch/arm64/ker
On 08/09/15 15:54, Jungseok Lee wrote:
> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>
> Hi James,
>
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index e16351819fed..d42371f3f5a1 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -19
On Sep 8, 2015, at 10:45 AM, AKASHI Takahiro wrote:
> Jungseok,
Hi Akashi,
> On 09/08/2015 01:34 AM, Jungseok Lee wrote:
>> On Sep 8, 2015, at 1:06 AM, James Morse wrote:
>>> On 07/09/15 16:48, Jungseok Lee wrote:
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
Hi James,
>>>
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
Hi James,
> Having to handle interrupts on top of an existing kernel stack means the
> kernel stack must be large enough to accomodate both the maximum kernel
> usage, and the maximum irq handler usage. Switching to a different stack
> when processi
On 09/07/2015 11:36 PM, James Morse wrote:
Having to handle interrupts on top of an existing kernel stack means the
kernel stack must be large enough to accomodate both the maximum kernel
usage, and the maximum irq handler usage. Switching to a different stack
when processing irqs allows us to ma
On 09/08/2015 10:45 AM, AKASHI Takahiro wrote:
Jungseok,
On 09/08/2015 01:34 AM, Jungseok Lee wrote:
On Sep 8, 2015, at 1:06 AM, James Morse wrote:
On 07/09/15 16:48, Jungseok Lee wrote:
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
Hi James,
Having to handle interrupts on top of an exis
Jungseok,
On 09/08/2015 01:34 AM, Jungseok Lee wrote:
On Sep 8, 2015, at 1:06 AM, James Morse wrote:
On 07/09/15 16:48, Jungseok Lee wrote:
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
Hi James,
Having to handle interrupts on top of an existing kernel stack means the
kernel stack must be
On Sep 8, 2015, at 1:06 AM, James Morse wrote:
> On 07/09/15 16:48, Jungseok Lee wrote:
>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>>
>> Hi James,
>>
>>> Having to handle interrupts on top of an existing kernel stack means the
>>> kernel stack must be large enough to accomodate both the m
On 07/09/15 16:48, Jungseok Lee wrote:
> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>
> Hi James,
>
>> Having to handle interrupts on top of an existing kernel stack means the
>> kernel stack must be large enough to accomodate both the maximum kernel
>> usage, and the maximum irq handler usa
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
Hi James,
> Having to handle interrupts on top of an existing kernel stack means the
> kernel stack must be large enough to accomodate both the maximum kernel
> usage, and the maximum irq handler usage. Switching to a different stack
> when processi
Having to handle interrupts on top of an existing kernel stack means the
kernel stack must be large enough to accomodate both the maximum kernel
usage, and the maximum irq handler usage. Switching to a different stack
when processing irqs allows us to make the stack size smaller.
Maximum kernel st
13 matches
Mail list logo