Alexey Brodkin writes:
> On Wed, 2016-10-19 at 22:50 +1100, Michael Ellerman wrote:
>> Vineet Gupta writes:
>> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> > > >
ARC CPU with enabled MMU sees entire 32-bit address space divided in 2
big parts:
1) 0 - 0x7fff_ (lower 2Gb): translated memory
I.e. all reads/writes from/to this region go through MMU and after
translation land somewhere in physical memory.
2) 0x8000_ - 0x_: untranslated
On 10/26/2016 09:36 AM, Marc Zyngier wrote:
> On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta
> wrote:
>> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>>> It definitely feels weird to encode the interrupt affinity in the DT
>>> (the kernel and possible userspace usually know much better than the
On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta
wrote:
> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>> It definitely feels weird to encode the interrupt affinity in the DT
>> (the kernel and possible userspace usually know much better than the
>> firmware). What is the actual reason for storing
On 10/26/2016 07:05 AM, Marc Zyngier wrote:
> It definitely feels weird to encode the interrupt affinity in the DT
> (the kernel and possible userspace usually know much better than the
> firmware). What is the actual reason for storing the affinity there?
The IDU intc supports various interrupt d
On 25/10/16 19:28, Vineet Gupta wrote:
> On 10/24/2016 05:46 AM, Yuriy Kolerov wrote:
>> Originally an initial distribution mode (its value resides in Device Tree)
>> for each common interrupt is set in idu_irq_xlate. This leads to the
>> following problems. idu_irq_xlate may be called several time
OK linux-next/axs103_smp_defconfig/arcv2 Wed Oct 26, 23:35
http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
Commit: Add linux-next specific files for 20161025
556dd18b9e4d9f4d75d3218a374b3b5834991ed1
Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 6.2.1
From: Noam Camus
Today we use smp_init_cpus() to set cpu possible mask
and we use smp_prepare_cpus() to set cpu present mask.
For possible mask we use all CPUs at range [0-NR_CPUS] and
for present mask we use all CPUs at range [0-max_cpus]
which is actually the same as possible mask (no hutplug).
