Kukjin,
On Wed, Jun 11, 2014 at 8:28 AM, Kukjin Kim wrote:
> On 06/12/14 00:19, Doug Anderson wrote:
>>
>> Chander,
>>
>> On Tue, Jun 10, 2014 at 9:52 PM, Chander Kashyap
>> wrote:
>>>
>>> Hi Doug,
>>>
>>> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
>>> wrote:
On Tue, 10 Jun 2014, Do
Hi Doug,
On 13 June 2014 20:40, Doug Anderson wrote:
> Chander,
>
> On Fri, Jun 13, 2014 at 4:54 AM, Chander Kashyap
> wrote:
>> This patch is effectively changing the mcpm_entry_point address from
>> nsbase + 0x1c to nsbase + 0x8
>>
>> Hence while integrating with mainline u-boot we need to ta
Chander,
On Fri, Jun 13, 2014 at 4:54 AM, Chander Kashyap wrote:
> This patch is effectively changing the mcpm_entry_point address from
> nsbase + 0x1c to nsbase + 0x8
>
> Hence while integrating with mainline u-boot we need to take care for
> new mcpm_entry_point address.
>
> With Chromebook it
On Fri, 13 Jun 2014, Chander Kashyap wrote:
> This patch is effectively changing the mcpm_entry_point address from
> nsbase + 0x1c to nsbase + 0x8
>
> Hence while integrating with mainline u-boot we need to take care for
> new mcpm_entry_point address.
Why not inserting a NOP as the first instru
On Wed, Jun 11, 2014 at 8:58 PM, Kukjin Kim wrote:
> On 06/12/14 00:19, Doug Anderson wrote:
>>
>> Chander,
>>
>> On Tue, Jun 10, 2014 at 9:52 PM, Chander Kashyap
>> wrote:
>>>
>>> Hi Doug,
>>>
>>> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
>>> wrote:
On Tue, 10 Jun 2014, Doug Anders
On 06/12/14 00:19, Doug Anderson wrote:
Chander,
On Tue, Jun 10, 2014 at 9:52 PM, Chander Kashyap wrote:
Hi Doug,
On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre wrote:
On Tue, 10 Jun 2014, Doug Anderson wrote:
My S-state knowledge is not strong, but I believe that Lorenzo's
questions matt
Chander,
On Tue, Jun 10, 2014 at 9:52 PM, Chander Kashyap wrote:
> Hi Doug,
>
> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
> wrote:
>> On Tue, 10 Jun 2014, Doug Anderson wrote:
>>
>>> My S-state knowledge is not strong, but I believe that Lorenzo's
>>> questions matter if we're using S2 for
Hi Lorenzo and Chander,
On Wed, Jun 11, 2014 at 6:45 PM, Lorenzo Pieralisi
wrote:
> On Wed, Jun 11, 2014 at 01:14:21PM +0100, Chander Kashyap wrote:
>> On Wed, Jun 11, 2014 at 3:43 PM, Lorenzo Pieralisi
>> wrote:
>> > On Wed, Jun 11, 2014 at 05:52:10AM +0100, Chander Kashyap wrote:
>> >> Hi Doug
On 11 June 2014 18:45, Lorenzo Pieralisi wrote:
> On Wed, Jun 11, 2014 at 01:14:21PM +0100, Chander Kashyap wrote:
>> On Wed, Jun 11, 2014 at 3:43 PM, Lorenzo Pieralisi
>> wrote:
>> > On Wed, Jun 11, 2014 at 05:52:10AM +0100, Chander Kashyap wrote:
>> >> Hi Doug,
>> >>
>> >> On Tue, Jun 10, 2014
On Wed, Jun 11, 2014 at 01:14:21PM +0100, Chander Kashyap wrote:
> On Wed, Jun 11, 2014 at 3:43 PM, Lorenzo Pieralisi
> wrote:
> > On Wed, Jun 11, 2014 at 05:52:10AM +0100, Chander Kashyap wrote:
> >> Hi Doug,
> >>
> >> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
> >> wrote:
> >> > On Tue, 10
On Wed, Jun 11, 2014 at 3:43 PM, Lorenzo Pieralisi
wrote:
> On Wed, Jun 11, 2014 at 05:52:10AM +0100, Chander Kashyap wrote:
>> Hi Doug,
>>
>> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
>> wrote:
>> > On Tue, 10 Jun 2014, Doug Anderson wrote:
>> >
>> >> My S-state knowledge is not strong, bu
On Wed, Jun 11, 2014 at 05:52:10AM +0100, Chander Kashyap wrote:
> Hi Doug,
>
> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
> wrote:
> > On Tue, 10 Jun 2014, Doug Anderson wrote:
> >
> >> My S-state knowledge is not strong, but I believe that Lorenzo's
> >> questions matter if we're using S2
Hi Doug,
On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre wrote:
> On Tue, 10 Jun 2014, Doug Anderson wrote:
>
>> My S-state knowledge is not strong, but I believe that Lorenzo's
>> questions matter if we're using S2 for CPUidle (where we actually turn
>> off power and hot unplug CPUs) but not when
On Tue, 10 Jun 2014, Doug Anderson wrote:
> My S-state knowledge is not strong, but I believe that Lorenzo's
> questions matter if we're using S2 for CPUidle (where we actually turn
> off power and hot unplug CPUs) but not when we're using S1 for CPUidle
> (where we just enter WFI/WFE).
>
> I bel
Chander,
On Tue, Jun 10, 2014 at 1:12 AM, Chander Kashyap
wrote:
> On 10 June 2014 04:08, Lorenzo Pieralisi wrote:
>> On Mon, Jun 09, 2014 at 06:03:31PM +0100, Doug Anderson wrote:
>>
>> [...]
>>
>>> Cold boot and resume from suspend are detected via various special
>>> flags in various special
On 10 June 2014 04:08, Lorenzo Pieralisi wrote:
> On Mon, Jun 09, 2014 at 06:03:31PM +0100, Doug Anderson wrote:
>
> [...]
>
>> Cold boot and resume from suspend are detected via various special
>> flags in various special locations. Resume from suspend looks at
>> INFORM1 (0x10048004) for flags.
On Mon, Jun 09, 2014 at 06:03:31PM +0100, Doug Anderson wrote:
[...]
> Cold boot and resume from suspend are detected via various special
> flags in various special locations. Resume from suspend looks at
> INFORM1 (0x10048004) for flags. This register is 0 during a cold boot
> and has special
Lorenzo,
On Sat, Jun 7, 2014 at 11:12 AM, Lorenzo Pieralisi
wrote:
> On Fri, Jun 06, 2014 at 10:43:05PM +0100, Doug Anderson wrote:
>> On exynos mcpm systems the firmware is hardcoded to jump to an address
>> in SRAM (0x02073000) when secondary CPUs come up. By default the
>> firmware puts a bun
On Fri, Jun 06, 2014 at 10:43:05PM +0100, Doug Anderson wrote:
> On exynos mcpm systems the firmware is hardcoded to jump to an address
> in SRAM (0x02073000) when secondary CPUs come up. By default the
> firmware puts a bunch of code at that location. That code expects the
> kernel to fill in a
>> If this is all that is needed to solve the problem being discussed in
>> the other thread I have absolutely no issue with such a workaround going
>> into mainline.
>
> This plus the CCI fix that Andrew is planning to post.
Right - we'll need a patch to enable the CCI port for the cluster we
boo
Nicolas,
On Fri, Jun 6, 2014 at 3:35 PM, Nicolas Pitre wrote:
> On Fri, 6 Jun 2014, Doug Anderson wrote:
>
>> On exynos mcpm systems the firmware is hardcoded to jump to an address
>> in SRAM (0x02073000) when secondary CPUs come up. By default the
>> firmware puts a bunch of code at that locati
On Fri, 6 Jun 2014, Doug Anderson wrote:
> On exynos mcpm systems the firmware is hardcoded to jump to an address
> in SRAM (0x02073000) when secondary CPUs come up. By default the
> firmware puts a bunch of code at that location. That code expects the
> kernel to fill in a few slots with addres
22 matches
Mail list logo
