<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/arch/powerpc/platforms/ps3, branch linux-4.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2015-09-30T00:33:02Z</updated>
<entry>
<title>powerpc/ps3: Remove unused os_area_db_id_video_mode</title>
<updated>2015-09-30T00:33:02Z</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2015-09-25T02:14:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4fa9a3f6b616fd9f2555d9d0c04513a942750986'/>
<id>urn:sha1:4fa9a3f6b616fd9f2555d9d0c04513a942750986</id>
<content type='text'>
This struct is unused, which is now a build error with gcc 6:

  error: 'os_area_db_id_video_mode' defined but not used

There doesn't seem to be any good reason to keep it around so remove it,
it's in the history if anyone needs it.

Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>genirq/irqdomain: Allow irq domain aliasing</title>
<updated>2015-07-29T22:14:36Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2015-07-28T13:46:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ad3aedfbb04b3a2af54473cfe31f13953cfe9d84'/>
<id>urn:sha1:ad3aedfbb04b3a2af54473cfe31f13953cfe9d84</id>
<content type='text'>
It is not uncommon (at least with the ARM stuff) to have a piece
of hardware that implements different flavours of "interrupts".
A typical example of this is the GICv3 ITS, which implements
standard PCI/MSI support, but also some form of "generic MSI".

So far, the PCI/MSI domain is registered using the ITS device_node,
so that irq_find_host can return it. On the contrary, the raw MSI
domain is not registered with an device_node, making it impossible
to be looked up by another subsystem (obviously, using the same
device_node twice would only result in confusion, as it is not
defined which one irq_find_host would return).

A solution to this is to "type" domains that may be aliasing, and
to be able to lookup an device_node that matches a given type.
For this, we introduce irq_find_matching_host() as a superset
of irq_find_host:

struct irq_domain *irq_find_matching_host(struct device_node *node,
                                enum irq_domain_bus_token bus_token);

where bus_token is the "type" we want to match the domain against
(so far, only DOMAIN_BUS_ANY is defined). This result in some
moderately invasive changes on the PPC side (which is the only
user of the .match method).

This has otherwise no functionnal change.

Reviewed-by: Hanjun Guo &lt;hanjun.guo@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Cc: &lt;linux-arm-kernel@lists.infradead.org&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Cc: Ma Jun &lt;majun258@huawei.com&gt;
Cc: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Cc: Duc Dang &lt;dhdang@apm.com&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Jiang Liu &lt;jiang.liu@linux.intel.com&gt;
Cc: Jason Cooper &lt;jason@lakedaemon.net&gt;
Link: http://lkml.kernel.org/r/1438091186-10244-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
</entry>
<entry>
<title>powerpc: use device_initcall for registering rtc devices</title>
<updated>2015-06-16T18:12:29Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2015-05-02T00:05:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8f6b9512ceadc6bd52777c299111dc642b4c65b6'/>
<id>urn:sha1:8f6b9512ceadc6bd52777c299111dc642b4c65b6</id>
<content type='text'>
Currently these two RTC devices are in core platform code
where it is not possible for them to be modular.  It will
never be modular, so using module_init as an alias for
__initcall can be somewhat misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future.  If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.

Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups.  As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- they will remain at level 6 in initcall ordering.

Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Geoff Levand &lt;geoff@infradead.org&gt;
Acked-by: Geoff Levand &lt;geoff@infradead.org&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
</entry>
<entry>
<title>powerpc: Drop return value of smp_ops-&gt;probe()</title>
<updated>2015-04-10T10:02:49Z</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2015-04-04T08:28:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a7f4ee1fe93aa9ae191971be9324edb8f9fbcb4a'/>
<id>urn:sha1:a7f4ee1fe93aa9ae191971be9324edb8f9fbcb4a</id>
<content type='text'>
smp_ops-&gt;probe() is currently supposed to return the number of cpus in
the system.

The last actual usage of the value was removed in May 2007 in e147ec8f1808
"[POWERPC] Simplify smp_space_timers". We still passed the value around
until June 2010 when even that was finally removed in c1aa687d499a
"powerpc: Clean up obsolete code relating to decrementer and timebase".

So drop that requirement, probe() now returns void, and update all
implementations.

Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/ps3: Write highmem info to repository</title>
<updated>2015-01-22T06:31:21Z</updated>
<author>
<name>Geoff Levand</name>
<email>geoff@infradead.org</email>
</author>
<published>2015-01-13T01:00:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5ae74630ee4fa98bbba7a7cd8ee6919fd9f38561'/>
<id>urn:sha1:5ae74630ee4fa98bbba7a7cd8ee6919fd9f38561</id>
<content type='text'>
Add calls to the ps3_mm_set_repository_highmem() routine when the ps3
r1 highmem region is either created or destroyed.

Signed-off-by: Geoff Levand &lt;geoff@infradead.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/ps3: Add ps3_mm_set_repository_highmem</title>
<updated>2015-01-22T06:31:21Z</updated>
<author>
<name>Geoff Levand</name>
<email>geoff@infradead.org</email>
</author>
<published>2015-01-13T01:00:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d4b18bd675b850fbf395304433952130034bdd89'/>
<id>urn:sha1:d4b18bd675b850fbf395304433952130034bdd89</id>
<content type='text'>
Add the new routine ps3_mm_set_repository_highmem() that saves highmem info to
the LV1 hypervisor registry so that the info will be available to second stage
OS's loaded by petitboot/kexec. FreeBSD and some Linux derivatives use
this feature.

Also, move the existing ps3_mm_get_repository_highmem() routine up in
the source file.

This implementation of ps3_mm_set_repository_highmem() assumes the repository
will have a single highmem region entry (at index 0).

Signed-off-by: Geoff Levand &lt;geoff@infradead.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/ps3: Add empty repository highmem routines</title>
<updated>2015-01-22T06:31:21Z</updated>
<author>
<name>Geoff Levand</name>
<email>geoff@infradead.org</email>
</author>
<published>2015-01-13T01:00:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c02d35067307dc65ebc52d1f5855102da184146b'/>
<id>urn:sha1:c02d35067307dc65ebc52d1f5855102da184146b</id>
<content type='text'>
To avoid the need for preprocessor conditionals in C source files add a set of
empty inline repository highmem write routines to platform.h that are used when
CONFIG_PS3_REPOSITORY_WRITE is not defined.

Signed-off-by: Geoff Levand &lt;geoff@infradead.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/mm: don't do tlbie for updatepp request with NO HPTE fault</title>
<updated>2014-12-05T05:26:15Z</updated>
<author>
<name>Aneesh Kumar K.V</name>
<email>aneesh.kumar@linux.vnet.ibm.com</email>
</author>
<published>2014-12-04T05:30:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aefa5688c070727b8729de1aef85cad7b9933fc7'/>
<id>urn:sha1:aefa5688c070727b8729de1aef85cad7b9933fc7</id>
<content type='text'>
upatepp can get called for a nohpte fault when we find from the linux
page table that the translation was hashed before. In that case
we are sure that there is no existing translation, hence we could
avoid doing tlbie.

We could possibly race with a parallel fault filling the TLB. But
that should be ok because updatepp is only ever relaxing permissions.
We also look at linux pte permission bits when filling hash pte
permission bits. We also hold the linux pte busy bits while
inserting/updating a hashpte entry, hence a paralle update of
linux pte is not possible. On the other hand mprotect involves
ptep_modify_prot_start which cause a hpte invalidate and not updatepp.

Performance number:
We use randbox_access_bench written by Anton.

Kernel with THP disabled and smaller hash page table size.

    86.60%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_updatepp
     2.10%  random_access_b  random_access_bench              [.] doit
     1.99%  random_access_b  [kernel.kallsyms]                [k] .do_raw_spin_lock
     1.85%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_insert
     1.26%  random_access_b  [kernel.kallsyms]                [k] .native_flush_hash_range
     1.18%  random_access_b  [kernel.kallsyms]                [k] .__delay
     0.69%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_remove
     0.37%  random_access_b  [kernel.kallsyms]                [k] .clear_user_page
     0.34%  random_access_b  [kernel.kallsyms]                [k] .__hash_page_64K
     0.32%  random_access_b  [kernel.kallsyms]                [k] fast_exception_return
     0.30%  random_access_b  [kernel.kallsyms]                [k] .hash_page_mm

With Fix:

    27.54%  random_access_b  random_access_bench              [.] doit
    22.90%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_insert
     5.76%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_remove
     5.20%  random_access_b  [kernel.kallsyms]                [k] fast_exception_return
     5.12%  random_access_b  [kernel.kallsyms]                [k] .__hash_page_64K
     4.80%  random_access_b  [kernel.kallsyms]                [k] .hash_page_mm
     3.31%  random_access_b  [kernel.kallsyms]                [k] data_access_common
     1.84%  random_access_b  [kernel.kallsyms]                [k] .trace_hardirqs_on_caller

Signed-off-by: Aneesh Kumar K.V &lt;aneesh.kumar@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc: Remove more traces of bootmem</title>
<updated>2014-11-19T10:41:51Z</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2014-11-18T05:47:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e39f223fc93580c86ccf6b3422033e349f57f0dd'/>
<id>urn:sha1:e39f223fc93580c86ccf6b3422033e349f57f0dd</id>
<content type='text'>
Although we are now selecting NO_BOOTMEM, we still have some traces of
bootmem lying around. That is because even with NO_BOOTMEM there is
still a shim that converts bootmem calls into memblock calls, but
ultimately we want to remove all traces of bootmem.

Most of the patch is conversions from alloc_bootmem() to
memblock_virt_alloc(). In general a call such as:

  p = (struct foo *)alloc_bootmem(x);

Becomes:

  p = memblock_virt_alloc(x, 0);

We don't need the cast because memblock_virt_alloc() returns a void *.
The alignment value of zero tells memblock to use the default alignment,
which is SMP_CACHE_BYTES, the same value alloc_bootmem() uses.

We remove a number of NULL checks on the result of
memblock_virt_alloc(). That is because memblock_virt_alloc() will panic
if it can't allocate, in exactly the same way as alloc_bootmem(), so the
NULL checks are and always have been redundant.

The memory returned by memblock_virt_alloc() is already zeroed, so we
remove several memsets of the result of memblock_virt_alloc().

Finally we convert a few uses of __alloc_bootmem(x, y, MAX_DMA_ADDRESS)
to just plain memblock_virt_alloc(). We don't use memblock_alloc_base()
because MAX_DMA_ADDRESS is ~0ul on powerpc, so limiting the allocation
to that is pointless, 16XB ought to be enough for anyone.

Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>Merge branch 'topic/get-cpu-var' into next</title>
<updated>2014-11-05T10:00:31Z</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2014-11-05T10:00:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dd521d1eb4bc7f12a0d440134cb3a72852b6da9c'/>
<id>urn:sha1:dd521d1eb4bc7f12a0d440134cb3a72852b6da9c</id>
<content type='text'>
</content>
</entry>
</feed>
