On Thu, Mar 20, 2014 at 05:41:00PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> The current frequency of a cpu is reported through the sysfs file
> cpuinfo_cur_freq. This requires the driver to implement a
> "->get(unsigned int cpu)" method which will return the current
> opera
On Thu, Mar 20, 2014 at 05:40:58PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> Create a helper routine that can return the cpu-frequency for the
> corresponding pstate_id.
>
> Also, cache the values of the pstate_max, pstate_min and
> pstate_nominal and nr_pstates in a static
On Thu, Mar 20, 2014 at 05:40:57PM +0530, Gautham R. Shenoy wrote:
> From: "Srivatsa S. Bhat"
>
> On POWER systems, the CPU frequency is controlled at a core-level and
> hence we need to serialize so that only one of the threads in the core
> switches the core's frequency at a time.
>
> Using a
On Thu, Mar 20, 2014 at 9:55 PM, Srikar Dronamraju
wrote:
>
> I reverted commits 99b60ce6 and b0c29f79. Then applied the patches in
> the above url. The last one had a reject but it was pretty
> straightforward to resolve it. After this, specjbb completes.
>
> So reverting and applying v3 3/4 and
>
> Ok, so a big reason why this patch doesn't apply cleanly after reverting
> is because *most* of the changes were done at the top of the file with
> regards to documenting the ordering guarantees, the actual code changes
> are quite minimal.
>
> I reverted commits 99b60ce6 (documentation) and
On 03/10/2014 04:42 PM, Sudeep Holla wrote:
> Hi Anshuman,
>
> On 07/03/14 06:14, Anshuman Khandual wrote:
>> On 03/07/2014 09:36 AM, Anshuman Khandual wrote:
>>> On 02/19/2014 09:36 PM, Sudeep Holla wrote:
From: Sudeep Holla
This patch removes the redundant sysfs cacheinfo code by
On Wed, 2014-03-19 at 08:56 +0800, Chenhui Zhao wrote:
> On Tue, Mar 18, 2014 at 05:42:09PM -0500, Scott Wood wrote:
> > On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> > > On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > > > Why do you need the entry mapping on 32-bit but n
On Thu, 2014-03-20 at 19:47 +0800, Kevin Hao wrote:
> OK, so the intention of 'twi, isync' following the load is not to order the
> following storage access, but order the following delay loop instructions,
> right? But according to the e6500 manual, the instructions complete in order.
> The follow
On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
> I tried to work out what the 'twi, isync' instructions were for (in
> in_le32()).
> The best I could come up with was to ensure a synchronous bus-fault.
> But bus faults are probably only expected during device probing - not
> normal operati
On Thu, 2014-03-20 at 09:42 +0100, Valentin Longchamp wrote:
> On 03/20/2014 12:08 AM, Scott Wood wrote:
> > On Tue, Feb 11, 2014 at 12:50:07PM +0100, Valentin Longchamp wrote:
> >> + reset_cpld@1,0 {
> >> + interrupt-controller;
> >> + #interrupt-cells =
On Thu, Mar 20, 2014 at 1:20 PM, Davidlohr Bueso wrote:
>
> I reverted commits 99b60ce6 (documentation) and b0c29f79 (the offending
> commit), and then I cleanly applied the equivalent ones from v3 of the
> series (which was already *tested* and ready for upstream until you
> suggested looking int
On Thu, 2014-03-20 at 09:31 -0700, Davidlohr Bueso wrote:
> hmmm looking at ppc spinlock code, it seems that it doesn't have ticket
> spinlocks -- in fact Torsten Duwe has been trying to get them upstream
> very recently. Since we rely on the counter for detecting waiters, this
> might explain the
On Thu, 2014-03-20 at 12:25 -0700, Linus Torvalds wrote:
> On Thu, Mar 20, 2014 at 12:08 PM, Davidlohr Bueso wrote:
> >
> > Oh, it does. This atomics technique was tested at a customer's site and
> > ready for upstream.
>
> I'm not worried about the *original* patch. I'm worried about the
> incre
On Thu, Mar 20, 2014 at 12:08 PM, Davidlohr Bueso wrote:
>
> Oh, it does. This atomics technique was tested at a customer's site and
> ready for upstream.
I'm not worried about the *original* patch. I'm worried about the
incremental one.
Your original patch never applied to my tree - I think it
On Thu, 2014-03-20 at 11:36 -0700, Linus Torvalds wrote:
> On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso wrote:
> >
> > Comparing with the patch I sent earlier this morning, looks equivalent,
> > and fwiw, passes my initial qemu bootup, which is the first way of
> > detecting anything stupid g
On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso wrote:
>
> Comparing with the patch I sent earlier this morning, looks equivalent,
> and fwiw, passes my initial qemu bootup, which is the first way of
> detecting anything stupid going on.
>
> So, Srikar, please try this patch out, as opposed to m
On Thu, Mar 20, 2014 at 11:03 AM, Davidlohr Bueso wrote:
>
> I still wonder about ppc and spinlocks (no ticketing!!) ... sure the
> "waiters" patch might fix the problem just because we explicitly count
> the members of the plist. And I guess if we cannot rely on all archs
> having an equivalent s
On Thu, 2014-03-20 at 10:42 -0700, Linus Torvalds wrote:
> On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso wrote:
> >> It strikes me that the "spin_is_locked()" test has no barriers wrt the
> >> writing of the new futex value on the wake path. And the read barrier
> >> obviously does nothing wrt
On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso wrote:
>> It strikes me that the "spin_is_locked()" test has no barriers wrt the
>> writing of the new futex value on the wake path. And the read barrier
>> obviously does nothing wrt the write either. Or am I missing
>> something? So the write tha
On Thu, 2014-03-20 at 09:41 -0700, Linus Torvalds wrote:
> On Wed, Mar 19, 2014 at 10:56 PM, Davidlohr Bueso wrote:
> >
> > This problem suggests that we missed a wakeup for a task that was adding
> > itself to the queue in a wait path. And the only place that can happen
> > is with the hb spinloc
Hi Cédric,
On Thu, 2014-03-20 at 16:09 +0100, Cédric Le Goater wrote:
> 16 files changed, 465 insertions(+), 100 deletions(-)
Do you have these in a git branch somewhere so I can merge and test
them?
Thanks.
-Geoff
___
Linuxppc-dev mailing list
Linu
On Wed, Mar 19, 2014 at 10:56 PM, Davidlohr Bueso wrote:
>
> This problem suggests that we missed a wakeup for a task that was adding
> itself to the queue in a wait path. And the only place that can happen
> is with the hb spinlock check for any pending waiters.
Ok, so thinking about hb_waiters_
On Wed, 2014-03-19 at 22:56 -0700, Davidlohr Bueso wrote:
> On Thu, 2014-03-20 at 11:03 +0530, Srikar Dronamraju wrote:
> > > > Joy,.. let me look at that with ppc in mind.
> > >
> > > OK; so while pretty much all the comments from that patch are utter
> > > nonsense (what was I thinking), I canno
The previous patch broke compatibility for 64bit big endian kernel.
This patch adds a config option to compile the boot wrapper in 64bit
only when CPU_LITTLE_ENDIAN is selected. It restores 32bit compilation
and linking for the big endian kernel.
Signed-off-by: Cédric Le Goater
---
arch/powerpc
Values will need to be byte-swapped when calling prom (big endian) from
a little endian boot wrapper.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.h|3 +++
arch/powerpc/boot/ofconsole.c |6 --
arch/powerpc/boot/oflib.c | 22 +++---
3 files ch
When the boot wrapper is compiled in 64bit, there is no need to
use __div64_32.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/stdio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/boot/stdio.c b/arch/powerpc/boot/stdio.c
index 5b57800bbc67..a701261b17
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/elf_util.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/elf_util.c b/arch/powerpc/boot/elf_util.c
index 1567a0c0f05c..316552dea4d8 100644
--- a/arch/powerpc/boot/elf_util.c
+++ b/arch/powerpc/boot/elf_util.c
@@
These are not the most efficient versions of swab but the wrapper does
not do much byte swapping. On a big endian cpu, these routines are
a no-op.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.h |7 +++
arch/powerpc/boot/swab.h | 29 +
2 files c
This makes ihandle 64bit friendly.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.h|2 +-
arch/powerpc/boot/oflib.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
index 3f35cf0ec432..bf228fea3517
When entering the boot wrapper in little endian, we will need to fix
the endian order using a fixup trampoline like in the kernel. This
patch overrides the _zimage_start entry point for this purpose.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/Makefile |2 ++
arch/powerpc/boo
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/main.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index a28f02165e97..46a7464e13c2 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -205,7 +205,11 @@ vo
The boot wrapper is now compiled using -m64 for 64bit kernels.
The linker script is generated using the kernel preprocessor flags
to make use of the CONFIG_PPC64 definitions and the wrapper script is
modified to take into account the new elf64ppc format.
zImage is compiled as a position independe
This patch defines a 'prom' routine similar to 'enter_prom' in the
kernel.
The difference is in the MSR which is built before entering prom. Big
endian order is enforced as in the kernel but 32bit mode is not. It
prepares ground for the next patches which will introduce Little endian
order.
Signe
This patch fixes 64bit compile warnings and updates the wrapper code
to converge the kernel code in prom_init.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.c|4 ++--
arch/powerpc/boot/of.h|3 ++-
arch/powerpc/boot/oflib.c | 15 ---
3 files changed, 12 in
This patch updates the wrapper code to converge with the kernel code in
prom_init.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/oflib.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/oflib.c b/arch/powerpc/boot/oflib.c
index c3288a3446
It could certainly be improved using Elf macros and byteswapping
routines, but the initial version of the code is organised to be a
single file program with limited dependencies. yaboot is the same.
Please scream if you want a total rewrite.
Signed-off-by: Cédric Le Goater
---
From the comment
This patch fixes warnings when the wrapper is compiled in 64bit and
updates the boot wrapper code related to prom to converge with the
kernel code in prom_init. This should make the review of changes easier.
The kernel has a different number of possible arguments (10) when
entering prom. There doe
This patch adds support a 64bit wrapper entry point. As in 32bit, the
entry point does its own relocation and can be loaded at any address
by the firmware.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/crt0.S | 108 --
1 file changed, 104 inse
Compilation is changed for little endian and entry points between the
wrapper and the kernel are modified to fix endian order with the
FIXUP_ENDIAN trampoline.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/Makefile |7 +--
arch/powerpc/boot/crt0.S |1 +
arch/p
Hi,
The following patchset adds support for 64bit little endian boot
wrapper. It is based on original code from Andrew Tauferner.
The first patches provide fixes for 64bit support. I also changed
the prom code to make it converge with the prom_init kernel code.
They have a lot in common and t
arch/powerpc/boot/oflib.c:211:9: warning: cast to pointer from integer of \
different size [-Wint-to-pointer-cast]
return (phandle) of_call_prom("finddevice", 1, 1, name);
This is a work around. The definite solution would be to define the
phandle typedef as a u32, as in the k
This is mostly useful to make to the boot wrapper code closer with
the kernel code in prom_init.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/oflib.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/oflib.c b/arch/powerpc/boot/oflib.c
inde
On Thu, 2014-03-20 at 15:38 +0530, Srikar Dronamraju wrote:
> > This problem suggests that we missed a wakeup for a task that was adding
> > itself to the queue in a wait path. And the only place that can happen
> > is with the hb spinlock check for any pending waiters. Just in case we
> > missed s
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file
Signed-off-by: Gerhard Sittig
Signed-off-by: Alexander Popov
---
arch/powerpc/boot/dts/mpc51
From: Gerhard Sittig
introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Gerhard Sittig
[ a13xp0p0...@gmail.com: turn this into a separate patch ]
---
.../devicetree/bindings/dma/mpc512x-dma.txt| 55 ++
1 file changed, 55 insertion
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use
to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When re
Fix mpc_dma_probe() error path and mpc_dma_remove(): manually free IRQs and
dispose IRQ mappings before devm_* takes care of other resources.
Moreover replace devm_request_irq() with request_irq() since there is no need
to use it because the original code always frees IRQ manually with
devm_free_ir
Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.
Signed-off-by: Alexander Popov
---
drive
Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.
Signed-off-by: Alexander Popov
Acked-by: Anatolij Gustschin
Acked-by: Gerhard Sittig
---
drivers/dma/mpc512x_dma.c |
2013/7/14 Gerhard Sittig :
> this series
> - introduces slave s/g support (that's support for DMA transfers which
>involve peripherals in contrast to mem-to-mem transfers)
> - adds device tree based lookup support for DMA channels
> - combines floating patches and related feedback which already
I noticed KVM is broken when KVM in-kernel XICS emulation
(CONFIG_KVM_XICS) is disabled.
The problem was introduced in 48eaef05 (KVM: PPC: Book3S HV: use
xics_wake_cpu only when defined). It used CONFIG_KVM_XICS to wrap
xics_wake_cpu, where CONFIG_PPC_ICP_NATIVE should have been
used.
Signed-off
From: "Gautham R. Shenoy"
The current frequency of a cpu is reported through the sysfs file
cpuinfo_cur_freq. This requires the driver to implement a
"->get(unsigned int cpu)" method which will return the current
operating frequency.
Implement a function named powernv_cpufreq_get() which reads t
From: "Gautham R. Shenoy"
Create a driver attribute named cpuinfo_nominal_freq which
creates a sysfs read-only file named cpuinfo_nominal_freq. Export
the frequency corresponding to the nominal_pstate through this
interface.
Nominal frequency is the highest non-turbo frequency for the
platform.
From: "Gautham R. Shenoy"
Create a helper routine that can return the cpu-frequency for the
corresponding pstate_id.
Also, cache the values of the pstate_max, pstate_min and
pstate_nominal and nr_pstates in a static structure so that they can
be reused in the future to perform any validations.
From: "Srivatsa S. Bhat"
On POWER systems, the CPU frequency is controlled at a core-level and
hence we need to serialize so that only one of the threads in the core
switches the core's frequency at a time.
Using a global mutex lock would needlessly serialize _all_ frequency
transitions in the s
From: Vaidyanathan Srinivasan
Backend driver to dynamically set voltage and frequency on
IBM POWER non-virtualized platforms. Power management SPRs
are used to set the required PState.
This driver works in conjunction with cpufreq governors
like 'ondemand' to provide a demand based frequency an
From: "Gautham R. Shenoy"
Hi,
This is the v3 of the consolidated patchset consisting
patches for enabling cpufreq on IBM POWERNV platforms
along with some enhancements. I have incorporated the review
for v2 (which can be found at [1]).
- This patchset contains code for the platform driver to s
From: Kevin Hao
> Sent: 20 March 2014 11:48
> To: Scott Wood
> Cc: linuxppc-dev@lists.ozlabs.org; Chenhui Zhao; jason@freescale.com;
> linux-ker...@vger.kernel.org
> Subject: Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
>
> On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wo
On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood wrote:
> > The sequence "write, readback, sync" will guarantee this according to the
> > manual.
>
> If you're referring to the section you quoted above, the manual does not
> say that. It only talks about when accesses "to memory regions af
Hello Johannes,
On 03/19/2014 04:54 PM, Johannes Thumshirn wrote:
> On Wed, Mar 19, 2014 at 01:46:37PM +0100, Valentin Longchamp wrote:
>> Hello,
>>
>> We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe
>> buses with this topology:
>>
>> PCIe 0 <---> PEX8505 switch <--->
> This problem suggests that we missed a wakeup for a task that was adding
> itself to the queue in a wait path. And the only place that can happen
> is with the hb spinlock check for any pending waiters. Just in case we
> missed some assumption about checking the hash bucket spinlock as a way
> of
Yes, this patch is run by checkpatch and found 0 errors, 0 warnings.
-Original Message-
From: Shevchenko, Andriy [mailto:andriy.shevche...@intel.com]
Sent: 2014年3月20日 17:45
To: Shi Xuelin-B29237
Cc: Koul, Vinod; Williams, Dan J; dmaeng...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org
Su
From: Xuelin Shi
dmaengine_unmap_put does below two things:
a) unmap pages for srcs and dests
b) free unmap struct
The unmap struct data is generated but only initialized while
other some dma contions are met, like dma alignment etc.
If the unmap data is not initialized, call dmaengine_unmap_put
On 03/20/2014 12:08 AM, Scott Wood wrote:
> On Tue, Feb 11, 2014 at 12:50:07PM +0100, Valentin Longchamp wrote:
>> +reset_cpld@1,0 {
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +reg = <1 0 0x80>;
>> +
On Thu, Mar 20, 2014 at 11:03:50AM +0530, Srikar Dronamraju wrote:
> > > Joy,.. let me look at that with ppc in mind.
> >
> > OK; so while pretty much all the comments from that patch are utter
> > nonsense (what was I thinking), I cannot actually find a real bug.
> >
> > But could you try the be
From: Xuelin Shi
The count which is used to get_unmap_data maybe not the same as the
count computed in dmaengine_unmap which causes to free data in a
wrong pool.
This patch fixes this issue by keeping the map count with unmap_data
structure and use this count to get the pool.
Signed-off-by: Xue
66 matches
Mail list logo
