On 06/18/2015 04:53 PM, Shilpasri G Bhat wrote:
> The idle cpus which stay in snooze for a long period can degrade the
> perfomance of the sibling cpus. If the cpu stays in snooze for more
> than target residency of the next available idle state, then exit from
> snooze. This gives a chance to the
On Mon, 2015-06-15 at 12:42 -0400, David Long wrote:
> From: "David A. Long"
>
> The pt_regs_offset structure is used for HAVE_REGS_AND_STACK_ACCESS_API
> feature and has identical definitions in four different arch ptrace.h
> include files. It seems unlikely that definition would ever need to b
On Thu, 2015-06-18 at 18:17 +0200, Torsten Duwe wrote:
> Did I miss anything else? I have the notrace optimisations and
> kernel live patching in the queue, which depends on this, so I'd
> really appreciate a comment whether it is acceptable in this form
> or not. Thanks in advance!
Hi Torsten,
S
The driver retains compatibility with old device trees, but we don't
want the old nodes lying around to be copied, or used as a reference
(some of the mux options are incorrect), or even just being clutter.
We will also need the #clock-cells in the clockgen node in order to
add fman nodes.
Signed
This allows the "clocks" property to be used in the absence of
legacy nodes, and for clocks that the legacy nodes do not describe.
Signed-off-by: Scott Wood
---
drivers/clk/clk-qoriq.c | 63 -
1 file changed, 62 insertions(+), 1 deletion(-)
diff -
The clock driver now takes care of ensuring that the mux only
exposes options that are valid. The driver was currently being overly
conservative in some cases -- for example, the "min_cpufreq =
get_bus_freq()" restriction only applies to chips with erratum
A-004510, and whether the freq_mask used
Having multiple clock implementations pointing at the same hardware is
asking for trouble if both get used -- for example, cached values will be
incorrect. Point the legacy nodes at the new clocks, before anything
starts using the new clocks. The pll/mux details in old device trees
will be ignore
The device tree should describe the chips (or chip-like subblocks) in
the system, but it generally does not describe individual registers --
it should identify, rather than describe, a programming interface.
This has not been the case with the QorIQ clockgen nodes. The
knowledge of what each bit
Freescale's Layerscape ARM chips use the same structure.
Signed-off-by: Scott Wood
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c |
Get the CPU clock's potential parent clocks from the clock interface
itself, rather than manually parsing the clocks property to find a
phandle, looking at the clock-names property of that, and assuming that
those are valid parent clocks for the cpu clock.
This is necessary for cpufreq to continue
The binding requires compatible and reg properties, but the ls1021a
device tree does not contain them. This will break with subsequent
clock driver changes. If required (it's not clear to me whether the
ls1 code currently works at all -- I tried multi_v7_defconfig and it
didn't boot, whereas I wa
The existing device tree bindings are error-prone and inflexible.
Correct the mistake by moving the knowledge into the driver, which
has more flexibility in describing the quirks of each chip. This leaves
the device tree to its proper role of identifying a programming interface
rather than descri
On PHB3, PE might be reserved in advance to reflect the M64 segments
consumed by the PE according to M64 BARs (exclude VF BARs) of the PCI
devices included in the PE. The PE is picked based on M64 BARs instead
of the bridge's M64 windows, which might include VF BARs. Otherwise,
wrong PE could be pi
The patch changes the type of last argument of pnv_ioda_setup_bus_PE()
and phb::pick_m64_pe() to boolean. No functional change.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8
arch/powerpc/platforms/powernv/pci.h | 2 +-
2 files changed, 5 insertions(+)
On PHB3, some PEs might be reserved in advance to reflect the M64
segments consumed by those PEs. We're reserving PEs based on the
M64 window of root port, which might contain VF BAR. The PEs for
VFs are allocated dynamically, not reserved based on the consumed
M64 segments. So the M64 window of ro
When CONFIG_PCI_IOV is enabled in kernel configuration, the logic reserving
PEs according to consumed M64 segments in bridge's M64 window won't work
properly. The bridge's M64 window contains VF BARs, which are M64 BARs.
Current code could reserve and pick PE number according to M64 segments
accomo
The PE numbers are reserved according to root port's M64 window,
which is aligned to M64 segment finely. So one PE shouldn't be
reserved for multiple times. We will reserve PE numbers according
to the M64 BARs of PCI device in subsequent patches, which aren't
aligned to M64 segment size finely. It
On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
> On 6/12/15, Denis Kirjanov wrote:
> > Fix the memory leak in create_gatt_table:
> > we've lost a kfree on the exit path for the pages array allocated
> > in uninorth_create_gatt_table
> >
> > Signed-off-by: Denis Kirjanov
>
> Hi Ben, Mic
On 06/18/2015 08:30 AM, Guenter Roeck wrote:
> On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote:
> [ ... ]
>> What happened to this series? I want to add shutdown support to my
>> platform and I need to write a register on the PMIC in one driver to
>> configure it for shutdown instead o
On Thu, 18 Jun 2015, Michal Hocko wrote:
> [Sorry for the late reply - I meant to answer in the previous threads
> but something always preempted me from that]
>
> On Wed 10-06-15 09:26:48, Eric B Munson wrote:
> > The cost of faulting in all memory to be locked can be very high when
> > working
On Mon, Jun 15, 2015 at 12:42:59PM -0400, David Long wrote:
> From: "David A. Long"
>
> Several architectures have identical or functionally equivalent code
> implementing parts of the HAVE_REGS_AND_STACK_ACCESS_API feature. Move
> that code out of the architecture directories.
>
> Signed-off-b
On Thu, 18 Jun 2015 18:17:27 +0200
Torsten Duwe wrote:
> Did I miss anything else? I have the notrace optimisations and
> kernel live patching in the queue, which depends on this, so I'd
> really appreciate a comment whether it is acceptable in this form
> or not. Thanks in advance!
>
> To
Finn Thain writes:
> When I have reliable documentation I always define macros. So I agree that
> "command" bytes like 0x34 and 0x3800 should have names but what are the
> correct names? Are we constructing an opcode containing RTC register file
> addresses or are we issuing read/write accesse
On Thu, 18 Jun 2015 18:21:07 +0200
Torsten Duwe wrote:
> +
> _GLOBAL(ftrace_stub)
> + nop
> + nop
> +.localentry ftrace_stub,.-ftrace_stub
You might want to run checkpatch and fix your whitespace errors.
-- Steve
> blr
> #else
> _GLOBAL_TOC(_mcount)
> @@ -1211,12
This is an *emergency* parachute to avoid an endless recursion and
consecutively a kernel stack overflow, should any function within some
ftrace framework cause an access fault, which calls _mcount / ftrace_caller
in return and so on. It might also call an ftrace'd function directly.
As Michael El
Using -mprofile-kernel on early boot code not only confuses the checker
but is also useless, as the infrastructure is not yet in place. Proceed
like with -pg (remove it from CFLAGS), equally with time.o and ftrace itself.
* arch/powerpc/kernel/Makefile:
- remove -mprofile-kernel from low lev
* Makefile:
- globally use -mprofile-kernel in case it's configured.
* arch/powerpc/Kconfig / kernel/trace/Kconfig:
- declare that ppc64 HAVE_MPROFILE_KERNEL and HAVE_DYNAMIC_FTRACE_WITH_REGS,
and use it.
Signed-off-by: Torsten Duwe
--
Makefile |5 -
arch/po
Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2.
Initial work started by Vojtech Pavlik, used with permission.
* arch/powerpc/kernel/entry_64.S:
- enhance _mcount with a stub to test (ftrace_trace_function ==
&ftrace_stub)
as suggested in Documentation/trace/ftrace-design.txt
Did I miss anything else? I have the notrace optimisations and
kernel live patching in the queue, which depends on this, so I'd
really appreciate a comment whether it is acceptable in this form
or not. Thanks in advance!
Torsten
___
Linuxppc-dev
On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote:
[ ... ]
>
> What happened to this series? I want to add shutdown support to my
> platform and I need to write a register on the PMIC in one driver to
> configure it for shutdown instead of restart and then write an MMIO
> register to te
[Sorry for the late reply - I meant to answer in the previous threads
but something always preempted me from that]
On Wed 10-06-15 09:26:48, Eric B Munson wrote:
> The cost of faulting in all memory to be locked can be very high when
> working with large mappings. If only portions of the mapping
On 6/12/15, Denis Kirjanov wrote:
> Fix the memory leak in create_gatt_table:
> we've lost a kfree on the exit path for the pages array allocated
> in uninorth_create_gatt_table
>
> Signed-off-by: Denis Kirjanov
Hi Ben, Michael
Will you take the patch through your trees or do I need to send it
On Thu, Jun 18, 2015 at 1:54 PM, Guenter Roeck wrote:
> On 06/17/2015 11:53 PM, Frans Klaver wrote:
>>
>> On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd
>> wrote:
>>>
>>> On 10/06/2014 10:28 PM, Guenter Roeck wrote:
Various drivers implement architecture and/or device specific means to
>
On 06/17/2015 11:53 PM, Frans Klaver wrote:
On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd wrote:
On 10/06/2014 10:28 PM, Guenter Roeck wrote:
Various drivers implement architecture and/or device specific means to
remove power from the system. For the most part, those drivers set the
global va
The idle cpus which stay in snooze for a long period can degrade the
perfomance of the sibling cpus. If the cpu stays in snooze for more
than target residency of the next available idle state, then exit from
snooze. This gives a chance to the cpuidle governor to re-evaluate the
last idle state of t
[46796.501487] Unable to handle kernel paging request for data at
address 0x02dd
[46796.514365] Faulting instruction address: 0xc00c5978
[46796.524217] Oops: Kernel access of bad area, sig: 11 [#1]
[46796.529351] PREEMPT CMPC885
[46796.532144] CPU: 0 PID: 1107 Comm: snmpd Not tainted 3.18.14
PEs for VFs don't have primary bus. So they have to have their own reset
backend, which is used during EEH recovery. The patch implements the reset
backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained
in the PE.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei Ya
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/pl
After PE reset, OPAL API opal_pci_reinit() is called on all devices
contained in the PE to reinitialize them. However, VFs can't be seen
from skiboot firmware. We have to implement the functions, similar
those in skiboot firmware, to reinitialize VFs after reset on PE
for VFs.
[gwshan: changelog a
Different from PCI bus dependent PE, PE for VFs doesn't have the
primary bus, on which the PCI hotplug is implemented. The patch
supports error recovery, especially the PCI hotplug for VF's PE.
The hotplug on VF's PE is implemented based on VFs, instead of
PCI bus any more.
[gwshan: changelog and
Current EEH recovery code works with the assumption: the PE has primary
bus. Unfortunately, that's not true for VF PEs, which generally contains
one or multiple VFs (for VF group case).
The patch introduces a weak function pcibios_bus_add_device() which is
called by pci_bus_add_device(). In this f
EEH address cache, which helps to locate the PCI device according to
the given (physical) MMIO address, didn't cover PCI bridges. Also, it
shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
should be returned.
Also, by doing so, it removes the type check in
eeh_addr_cache_insert_d
VFs and their corresponding pci_dn instances are created and released
dynamically as their PF's SRIOV capability is enabled and disabled.
The patch creates and releases EEH devices for VFs when creating and
releasing their pci_dn instances, which means EEH devices and pci_dn
instances have same lif
During EEH recovery, hotplug is applied to the devices which don't
have drivers or their drivers don't support EEH. However, the hotplug,
which was implemented based on PCI bus, can't be applied to VF directly.
The patch renames virtn_{add,remove}() and exports them so that they
can be used in PCI
As commit ac205b7bb72f ("PCI: make sriov work with hotplug remove") indicates,
VFs, which might be hooked to same PCI bus as their PF should be removed
before the PF. Otherwise, the PCI hot unplugging on the PCI bus would
cause kernel crash.
The patch applies the above pattern to PowerPC PCI hotpl
The patch caches the VF index in pci_dn, which can be used to calculate
VF's bus, device and function number. Those information helps to locate
the VF's PCI device instance when doing hotplug during EEH recovery if
necessary.
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/include
This patchset enables EEH on SRIOV VFs. The general idea is to create proper
VF edev and VF PE and handle them properly.
Different from the Bus PE, VF PE just contain one VF. This introduces the
difference of EEH error handling on a VF PE. Generally, it has several
differences.
First, the VF's re
On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd wrote:
> On 10/06/2014 10:28 PM, Guenter Roeck wrote:
>> Various drivers implement architecture and/or device specific means to
>> remove power from the system. For the most part, those drivers set the
>> global variable pm_power_off to point to a fun
Hi Finn,
On Thu, Jun 18, 2015 at 6:49 AM, Finn Thain wrote:
> On Tue, 16 Jun 2015, in which I wrote:
>> On Mon, 15 Jun 2015, Geert Uytterhoeven wrote:
>> > More magic values...
>>
>> [...] The only useful RTC documentation I've ever come across is this:
>> http://mac.linux-m68k.org/devel/plushw.p
49 matches
Mail list logo
