* [RFC PATCH v3 01/12] powerpc/book3s: Split the common exception prolog logic into two section.
From: Mahesh J Salgaonkar @ 2013-08-26 19:31 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Cc: Jeremy Kerr, Paul Mackerras, Anton Blanchard
In-Reply-To: <20130826192616.2855.18749.stgit@mars>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This patch splits the common exception prolog logic into two parts to
facilitate reuse of existing code in the next patch. The second part will
be reused in the machine check exception routine in the next patch.
Please note that this patch does not introduce or change existing code
logic. Instead it is just a code movement.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/exception-64s.h | 67 ++++++++++++++++--------------
1 file changed, 35 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 07ca627..2386d40 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -248,6 +248,40 @@ do_kvm_##n: \
#define NOTEST(n)
+#define EXCEPTION_PROLOG_COMMON_2(n, area) \
+ std r2,GPR2(r1); /* save r2 in stackframe */ \
+ SAVE_4GPRS(3, r1); /* save r3 - r6 in stackframe */ \
+ SAVE_2GPRS(7, r1); /* save r7, r8 in stackframe */ \
+ ld r9,area+EX_R9(r13); /* move r9, r10 to stackframe */ \
+ ld r10,area+EX_R10(r13); \
+ std r9,GPR9(r1); \
+ std r10,GPR10(r1); \
+ ld r9,area+EX_R11(r13); /* move r11 - r13 to stackframe */ \
+ ld r10,area+EX_R12(r13); \
+ ld r11,area+EX_R13(r13); \
+ std r9,GPR11(r1); \
+ std r10,GPR12(r1); \
+ std r11,GPR13(r1); \
+ BEGIN_FTR_SECTION_NESTED(66); \
+ ld r10,area+EX_CFAR(r13); \
+ std r10,ORIG_GPR3(r1); \
+ END_FTR_SECTION_NESTED(CPU_FTR_CFAR, CPU_FTR_CFAR, 66); \
+ GET_LR(r9,area); /* Get LR, later save to stack */ \
+ ld r2,PACATOC(r13); /* get kernel TOC into r2 */ \
+ std r9,_LINK(r1); \
+ mfctr r10; /* save CTR in stackframe */ \
+ std r10,_CTR(r1); \
+ lbz r10,PACASOFTIRQEN(r13); \
+ mfspr r11,SPRN_XER; /* save XER in stackframe */ \
+ std r10,SOFTE(r1); \
+ std r11,_XER(r1); \
+ li r9,(n)+1; \
+ std r9,_TRAP(r1); /* set trap number */ \
+ li r10,0; \
+ ld r11,exception_marker@toc(r2); \
+ std r10,RESULT(r1); /* clear regs->result */ \
+ std r11,STACK_FRAME_OVERHEAD-16(r1); /* mark the frame */
+
/*
* The common exception prolog is used for all except a few exceptions
* such as a segment miss on a kernel address. We have to be prepared
@@ -281,38 +315,7 @@ do_kvm_##n: \
beq 4f; /* if from kernel mode */ \
ACCOUNT_CPU_USER_ENTRY(r9, r10); \
SAVE_PPR(area, r9, r10); \
-4: std r2,GPR2(r1); /* save r2 in stackframe */ \
- SAVE_4GPRS(3, r1); /* save r3 - r6 in stackframe */ \
- SAVE_2GPRS(7, r1); /* save r7, r8 in stackframe */ \
- ld r9,area+EX_R9(r13); /* move r9, r10 to stackframe */ \
- ld r10,area+EX_R10(r13); \
- std r9,GPR9(r1); \
- std r10,GPR10(r1); \
- ld r9,area+EX_R11(r13); /* move r11 - r13 to stackframe */ \
- ld r10,area+EX_R12(r13); \
- ld r11,area+EX_R13(r13); \
- std r9,GPR11(r1); \
- std r10,GPR12(r1); \
- std r11,GPR13(r1); \
- BEGIN_FTR_SECTION_NESTED(66); \
- ld r10,area+EX_CFAR(r13); \
- std r10,ORIG_GPR3(r1); \
- END_FTR_SECTION_NESTED(CPU_FTR_CFAR, CPU_FTR_CFAR, 66); \
- GET_LR(r9,area); /* Get LR, later save to stack */ \
- ld r2,PACATOC(r13); /* get kernel TOC into r2 */ \
- std r9,_LINK(r1); \
- mfctr r10; /* save CTR in stackframe */ \
- std r10,_CTR(r1); \
- lbz r10,PACASOFTIRQEN(r13); \
- mfspr r11,SPRN_XER; /* save XER in stackframe */ \
- std r10,SOFTE(r1); \
- std r11,_XER(r1); \
- li r9,(n)+1; \
- std r9,_TRAP(r1); /* set trap number */ \
- li r10,0; \
- ld r11,exception_marker@toc(r2); \
- std r10,RESULT(r1); /* clear regs->result */ \
- std r11,STACK_FRAME_OVERHEAD-16(r1); /* mark the frame */ \
+4: EXCEPTION_PROLOG_COMMON_2(n, area) \
ACCOUNT_STOLEN_TIME
/*
^ permalink raw reply related
* [RFC PATCH v3 00/12] Machine check handling in linux host.
From: Mahesh J Salgaonkar @ 2013-08-26 19:31 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Cc: Jeremy Kerr, Paul Mackerras, Anton Blanchard
Hi,
Please find the patch set that performs the machine check handling inside linux
host. The design is to be able to handle re-entrancy so that we do not clobber
the machine check information during nested machine check interrupt.
The patch 2 introduces separate emergency stack in paca structure exclusively
for machine check exception handling. Patch 3 implements the logic to save the
raw MCE info onto the emergency stack and prepares to take another exception.
Patch 4 implements the additional checks that helps to decide whether to
deliver machine check event to host kernel right away or queue it up and
return. Patch 5 and 6 adds CPU-side hooks for early machine check handler
and TLB flush. The patch 7 and 8 is responsible to detect SLB/TLB errors and
flush them off in the real mode. The patch 9 implements the logic to decode
and save high level MCE information to per cpu buffer without clobbering.
Patch 10 implements mechanism to queue up MCE event in cases where early
handler can not deliver the event to host kernel right away. The patch 12
adds the basic error handling to the high level C code with MMU on.
I have tested SLB multihit, MC coming from opal context on powernv.
Please review and let me know your comments.
Changes in v3:
- Rebased to v3.11-rc7
- Handle MCE coming from opal context, secondary thread nap and return
from interrupt. Queue up the MCE event in this scenario and log it
later during syscall exit path. (patch 4 and 10).
Changes in v2:
- Moved early machine check handling code under CPU_FTR_HVMODE section.
This makes sure that the early machine check handler will get executed
only in hypervisor kernel.
- Add dedicated emergency stack for machine check so that we don't end up
disturbing others who use same emergency stack.
- Fixed the machine check early handle where it used to assume that r1 always
contains the valid stack pointer.
- Fixed an issue where per-cpu mce_nest_count variable underflows when kvm
fails to handle MC error and exit the guest.
- Fixed the code to restore r13 while before exiting early handler.
Thanks,
-Mahesh.
---
Mahesh Salgaonkar (12):
powerpc/book3s: Split the common exception prolog logic into two section.
powerpc/book3s: Introduce exclusive emergency stack for machine check exception.
powerpc/book3s: handle machine check in Linux host.
Validate r1 value before going to host kernel in virtual mode.
powerpc/book3s: Introduce a early machine check hook in cpu_spec.
powerpc/book3s: Add flush_tlb operation in cpu_spec.
powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power7.
powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power8.
powerpc/book3s: Decode and save machine check event.
Queue up and process delayed MCE events.
powerpc/powernv: Remove machine check handling in OPAL.
powerpc/powernv: Machine check exception handling.
arch/powerpc/include/asm/bitops.h | 5
arch/powerpc/include/asm/cputable.h | 12 +
arch/powerpc/include/asm/exception-64s.h | 67 +++---
arch/powerpc/include/asm/mce.h | 198 +++++++++++++++++
arch/powerpc/include/asm/paca.h | 9 +
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/asm-offsets.c | 4
arch/powerpc/kernel/cpu_setup_power.S | 38 ++-
arch/powerpc/kernel/cputable.c | 16 +
arch/powerpc/kernel/entry_64.S | 5
arch/powerpc/kernel/exceptions-64s.S | 181 ++++++++++++++++
arch/powerpc/kernel/mce.c | 345 ++++++++++++++++++++++++++++++
arch/powerpc/kernel/mce_power.c | 287 +++++++++++++++++++++++++
arch/powerpc/kernel/setup_64.c | 10 +
arch/powerpc/kernel/traps.c | 15 +
arch/powerpc/kvm/book3s_hv_ras.c | 50 ++--
arch/powerpc/platforms/powernv/opal.c | 161 ++++----------
arch/powerpc/xmon/xmon.c | 4
18 files changed, 1228 insertions(+), 180 deletions(-)
create mode 100644 arch/powerpc/include/asm/mce.h
create mode 100644 arch/powerpc/kernel/mce.c
create mode 100644 arch/powerpc/kernel/mce_power.c
--
-Mahesh
^ permalink raw reply
* [PATCH] powerpc/hvsi: increase handshake timeout from 200ms to 400ms.
From: Eugene Surovegin @ 2013-08-26 18:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
This solves a problem observed in kexec'ed kernel where 200ms timeout is
too short and bootconsole fails to initialize. Console did eventually
become workable but much later into the boot process.
Observed timeout was around 260ms, but I decided to make it a little bigger
for more reliability.
This has been tested on Power7 machine with Petitboot as a primary
bootloader and PowerNV firmware.
Signed-off-by: Eugene Surovegin <surovegin@google.com>
---
drivers/tty/hvc/hvsi_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
index 3396eb9..ac27671 100644
--- a/drivers/tty/hvc/hvsi_lib.c
+++ b/drivers/tty/hvc/hvsi_lib.c
@@ -341,8 +341,8 @@ void hvsilib_establish(struct hvsi_priv *pv)
pr_devel("HVSI@%x: ... waiting handshake\n", pv->termno);
- /* Try for up to 200s */
- for (timeout = 0; timeout < 20; timeout++) {
+ /* Try for up to 400ms */
+ for (timeout = 0; timeout < 40; timeout++) {
if (pv->established)
goto established;
if (!hvsi_get_packet(pv))
--
1.7.10.2
^ permalink raw reply related
* Re: Loading kernel on MPC86x
From: Martin Hinner @ 2013-08-26 18:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1377537249.3033.26.camel@snotra.buserror.net>
On Mon, Aug 26, 2013 at 7:14 PM, Scott Wood <scottwood@freescale.com> wrote:
>> that kernel must be at location 0. Another problem was that interrupts
>> got re-enabled during execution of my bootloader (I am doing some
>> syscalls -> goes to Cisco rom),
> Do you mean you're calling into the rom after Linux has already started
> executing? That's not normal for 8xx.
No, in bootloader. I have disabled interrupts and then later did a
syscall which probably enabled them again. As I have overwritten some
of Cisco ROM data it crashed (at random place).
>> I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
>> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
>> not address of CPM/SCM parameter RAM ? TX buffer address can be read
>> from SMC parameter RAM. Wouldn't this solution be more portable? At
>> least this way I do it when I take over console from Cisco
>> startup/rommon.
>
> The point was to keep things as simple as possible (e.g. for use in
> temporary handcoded asm as needed). This is a hacky debugging feature
> that assumes you know what you're doing and can set the address to match
> what the loader does (and that the loader's choice of address is
> static). If you have an improvement that keeps it simple, feel free to
> send a patch.
How about making CONFIG_PPC_EARLY_DEBUG_CPM_PARRAM that woud carry
address of SMCx parameter RAM (IMMR+0x04180 on MPC866) and this value
would be used in case CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is zero ? This
would allow kernel hackers to still use
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR for assembly debugging (+legacy use)
and everyone else can use it as a more reliable option that does not
rely on particular bootloader behavior. Early debug is good even for
end-users so as they can send debug output if anything goes wrong at
early stage.
Anyway, difference between _PARRAM and _ADDR is only one lwz
instruction, so I guess it is possible to completely discard _ADDR if
there is no legacy use for it. I am also not sure if this works with
SCC UART ports or only CPM SMC UART.
Martin
^ permalink raw reply
* Re: Loading kernel on MPC86x
From: Scott Wood @ 2013-08-26 17:14 UTC (permalink / raw)
To: Martin Hinner; +Cc: linuxppc-dev
In-Reply-To: <CAPVwjkyPKo0SmoEkJttzz0fXrTcyuv7K1nuhOzW9CdGXD+t7_A@mail.gmail.com>
On Sat, 2013-08-24 at 19:15 +0200, Martin Hinner wrote:
> Hello again,
>
> just a quick update: I have spent some more time on this and now I
> can boot into kernel (it works even with initramfs and simple assembly
> HelloWorld, so it's time to compile userland now). The problem was
> that kernel must be at location 0. Another problem was that interrupts
> got re-enabled during execution of my bootloader (I am doing some
> syscalls -> goes to Cisco rom),
Do you mean you're calling into the rom after Linux has already started
executing? That's not normal for 8xx.
> otherwise it crashed randomly. And
> finally it seems that stack must be < 8M. After this kernel boots.
>
> Anyway, I would still appreciate clarification on vmlinux:__start
> entry conditions:
>
> - must be loaded at 0 (but why arch/powerpc/boot/main.c has option to
> allocate space for kernel at nonzero addr ?)
arch/powerpc/boot/main.c is not just for 8xx.
> - stack? Does it really have to be < 8M ?
The stack is allocated by the kernel. It shouldn't matter what is in r1
when you initially enter the kernel.
> - interrupts disabled (really ;-) )
> - MSR.PR=0/LE=0/EE=0, but what other bits (RI? IP=0? ME?)
> - IMMR 0xff000000
> - and of course correct entry arguments in registers
>
> anything else?
>
> I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
> not address of CPM/SCM parameter RAM ? TX buffer address can be read
> from SMC parameter RAM. Wouldn't this solution be more portable? At
> least this way I do it when I take over console from Cisco
> startup/rommon.
The point was to keep things as simple as possible (e.g. for use in
temporary handcoded asm as needed). This is a hacky debugging feature
that assumes you know what you're doing and can set the address to match
what the loader does (and that the loader's choice of address is
static). If you have an improvement that keeps it simple, feel free to
send a patch.
-Scott
^ permalink raw reply
* Re: [v3] powerpc/mpc85xx: Update the clock device tree nodes
From: Scott Wood @ 2013-08-26 17:00 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Wood Scott-B07421, Mike Turquette, linuxppc-dev@lists.ozlabs.org,
devicetree@vger.kernel.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B1503BE58@039-SN2MPN1-012.039d.mgd.msft.net>
On Sun, 2013-08-25 at 21:42 -0500, Tang Yuantian-B29983 wrote:
> > >
> > > clockgen: global-utilities@e1000 {
> > > - compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
> > > + compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0",
> > > + "fixed-clock";
> > > + clock-output-names = "sysclk";
> > > + #clock-cells = <0>;
> >
> > Does U-Boot fill in clock-frequency here?
> >
> Yes, clock-frequency will be filled by uboot.
> You suggested we'd better not add it here.
Right -- I was just making sure.
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + pll0: pll0@800 {
> > > + #clock-cells = <1>;
> > > + reg = <0x800>;
> > > + compatible = "fsl,core-pll-clock";
> > > + clocks = <&clockgen>;
> > > + clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> > > + };
> > > + pll1: pll1@820 {
> > > + #clock-cells = <1>;
> > > + reg = <0x820>;
> > > + compatible = "fsl,core-pll-clock";
> > > + clocks = <&clockgen>;
> > > + clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> > > + };
> >
> > Please leave a blank line between properties and nodes, and between nodes.
> >
> OK, will add.
>
> > What does reg represent? Where is the binding for this?
> >
> > The compatible is too vague.
> Reg is register offset.
With no size?
> I should have had a binding document.
> About the compatible, you should pointed it out earlier in SDK review.
Sorry, it doesn't work that way. I don't know why I didn't notice this
stuff there -- the SDK review was probably rushed, with someone shouting
"urgent". The SDK does not dictate what goes upstream. Device tree
bindings should go upstream first.
> It is too later to change since the clock driver is merged for months although
> I sent this patch first.
It should not have gone in without an approved binding. It seems it
went in via Mike Turquette (why is a non-ARM-specific tree using
linux-arm-kernel as its list, BTW?). No ack from Ben, Kumar, or me is
shown in the commit.
In any case, you can preserve compatibility with existing trees without
using this compatible in new trees. The driver can check for both
compatibles, with a comment indicating that "fsl,core-mux-clock" is
deprecated and for compatibility only.
> Besides, it is not too bad because other arch use the similar name.
I don't follow. This is a specific Freescale register interface, not a
general concept.
In any case, which "similar names" are you referring to? A search in
arch/arm/boot/dts for "mux" with "clk" or "clock" turns up
"allwinner,sun4i-apb1-mux-clk" which is much more specific than
"fsl,core-mux-clock".
-Scott
^ permalink raw reply
* Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction
From: Scott Wood @ 2013-08-26 16:36 UTC (permalink / raw)
To: Zhang Haijun
Cc: Wood Scott-B07421, linux-mmc@vger.kernel.org,
cbouatmailru@gmail.com, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org, Xie Xiaobo-R63061
In-Reply-To: <521AA947.6080209@freescale.com>
On Mon, 2013-08-26 at 09:03 +0800, Zhang Haijun wrote:
> On 08/23/2013 11:40 PM, Scott Wood wrote:
>
> > On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote:
> > > Hi, Anton and all
> > >
> > > Is there any advice on these two patches ?
> > >
> > > [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system
> > > transaction
> > > [PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.
> > >
> > >
> > > [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
> > > This patch is Act-by Scott.
> > > Patch 4/4 is split to four patches and Act-by Anton.
> > >
> > >
> > > Thanks all.
> > >
> > >
> > >
> > [snip]
> > > > > + if (!(((SVR_SOC_VER(svr) == SVR_T4240) && (SVR_REV(svr) == 0x10))
> > > > > ||
> > > > > + ((SVR_SOC_VER(svr) == SVR_B4860) && (SVR_REV(svr) == 0x10))
> > > > > ||
> > > > > + ((SVR_SOC_VER(svr) == SVR_P1010) && (SVR_REV(svr) == 0x10))
> > > > > ||
> > > > > + ((SVR_SOC_VER(svr) == SVR_P3041) && (SVR_REV(svr) <= 0x20))
> > > > > ||
> > > > > + ((SVR_SOC_VER(svr) == SVR_P2041) && (SVR_REV(svr) <= 0x20))
> > > > > ||
> > > > > + ((SVR_SOC_VER(svr) == SVR_P5040) && SVR_REV(svr) == 0x20)))
> > > > > + return;
> > You need to include variants here. If P5040 is affected, then P5021 is
> > affected. If P2041 is affected, then P2040 is affected, etc.
> >
> > -Scott
> >
> >
> Hi, Scott
>
> This workaround is for CR:ENGR00229586: A-005055, Configs Affected
> only list these soc and its version.
> I was also wonder why only these boards?
>
> But I can't add soc like P5021 as I think it should be. Maybe there
> are some difference between them.
The only difference between P5040 and P5021 is the number of cores
enabled. It is physically the same silicon. Likewise with a lot of
other variants.
-Scott
^ permalink raw reply
* Re: Pull request: scottwood/linux.git next
From: Scott Wood @ 2013-08-26 15:48 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20130824010733.GA6116@home.buserror.net>
On Fri, 2013-08-23 at 20:07 -0500, Scott Wood wrote:
> The following changes since commit afbcdd97bf117bc2d01b865a32f78f662437a4d8:
>
> powerpc/wsp: Fix early debug build (2013-08-16 10:59:27 +1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
>
> for you to fetch changes up to 622e03eb3498c32ee29de5c1d6d381f443e58fad:
>
> powerpc/85xx: Add C293PCIE board support (2013-08-23 19:43:24 -0500)
>
> ----------------------------------------------------------------
> Chunhe Lan (1):
> powerpc/85xx: Add P1023RDB board support
>
> Haijun.Zhang (1):
> powerpc/85xx: Add support for 85xx cpu type detection
>
> Mingkai Hu (3):
> powerpc/85xx: Add SEC6.0 device tree
> powerpc/85xx: Add silicon device tree for C293
> powerpc/85xx: Add C293PCIE board support
>
> Scott Wood (5):
> powerpc/fsl-booke: Work around erratum A-006958
> powerpc: Convert some mftb/mftbu into mfspr
> powerpc/85xx: Remove -Wa,-me500
> powerpc/booke64: Use appropriate -mcpu
> powerpc/e500: Set -mcpu flag for 32-bit e500
>
> Wang Dongsheng (1):
> powerpc: add Book E support to 64-bit hibernation
Oh, forgot again: Highlights include changes in compiler flag settings
on e500 family cores, booke64 hibernation support, support for two new
boards, and an erratum workaround.
-Scott
^ permalink raw reply
* Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
From: Gleb Natapov @ 2013-08-26 12:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, linux-doc, Alexey Kardashevskiy, linux-kernel, kvm-ppc,
Alexander Graf, Paul Mackerras, linuxppc-dev
In-Reply-To: <1376441474.4255.39.camel@pasglop>
On Wed, Aug 14, 2013 at 10:51:14AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
> > This is to reserve a capablity number for upcoming support
> > of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
> > which support mulptiple DMA map/unmap operations per one call.
>
> Gleb, any chance you can put this (and the next one) into a tree to
> "lock in" the numbers ?
>
Applied it. Sorry for slow response, was on vocation and still go
through the email backlog.
> I've been wanting to apply the whole series to powerpc-next, that's
> stuff has been simmering for way too long and is in a good enough shape
> imho, but I need the capabilities and ioctl numbers locked in your tree
> first.
>
> Cheers,
> Ben.
>
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > Changes:
> > 2013/07/16:
> > * changed the number
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > include/uapi/linux/kvm.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index acccd08..99c2533 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
> > #define KVM_CAP_PPC_RTAS 91
> > #define KVM_CAP_IRQ_XICS 92
> > #define KVM_CAP_ARM_EL1_32BIT 93
> > +#define KVM_CAP_SPAPR_MULTITCE 94
> >
> > #ifdef KVM_CAP_IRQ_ROUTING
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Gleb.
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Handle the boundary condition correctly
From: Aneesh Kumar K.V @ 2013-08-26 12:14 UTC (permalink / raw)
To: Alexander Graf; +Cc: paulus, linuxppc-dev, kvm-ppc
In-Reply-To: <932EC6E7-BC15-474F-9E8B-4321B2126BE4@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 26.08.2013, at 05:28, Aneesh Kumar K.V wrote:
>
>> Alexander Graf <agraf@suse.de> writes:
>>
>>> On 23.08.2013, at 04:31, Aneesh Kumar K.V wrote:
>>>
>>>> Alexander Graf <agraf@suse.de> writes:
>>>>
>>>>> On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
>>>>>
>>>>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>>>
>>>>> Isn't this you?
>>>>
>>>> Yes. The patches are generated using git format-patch and sent by
>>>> git send-email. That's how it always created patches for me. I am not sure if
>>>> there is a config I can change to avoid having From:
>>>>
>>>>>
>>>>>>
>>>>>> We should be able to copy upto count bytes
>>>>>
>>>>> Why?
>>>>>
>>>>
>>>> Without this we end up doing
>>>>
>>>> + struct kvm_get_htab_buf {
>>>> + struct kvm_get_htab_header header;
>>>> + /*
>>>> + * Older kernel required one extra byte.
>>>> + */
>>>> + unsigned long hpte[3];
>>>> + } hpte_buf;
>>>>
>>>>
>>>> even though we are only looking for one hpte entry.
>>>
>>> Ok, please give me an example with real numbers and why it breaks.
>>>
>>>>
>>>> http://mid.gmane.org/1376995766-16526-4-git-send-email-aneesh.kumar@linux.vnet.ibm.com
>>>>
>>
>> Didn't quiet get what you are looking for. As explained before, we now
>> need to pass an array with array size 3 even though we know we need to
>> read only 2 entries because kernel doesn't loop correctly.
>
> But we need to do that regardless, because newer QEMU needs to be able to run on older kernels, no?
>
yes. So use space will have to pass an array of size 3. But that should
not prevent us from fixing this right ?
-aneesh
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Handle the boundary condition correctly
From: Alexander Graf @ 2013-08-26 11:10 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, kvm-ppc
In-Reply-To: <87wqn9dtbi.fsf@linux.vnet.ibm.com>
On 26.08.2013, at 05:28, Aneesh Kumar K.V wrote:
> Alexander Graf <agraf@suse.de> writes:
>=20
>> On 23.08.2013, at 04:31, Aneesh Kumar K.V wrote:
>>=20
>>> Alexander Graf <agraf@suse.de> writes:
>>>=20
>>>> On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
>>>>=20
>>>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>>=20
>>>> Isn't this you?
>>>=20
>>> Yes. The patches are generated using git format-patch and sent by
>>> git send-email. That's how it always created patches for me. I am =
not sure if
>>> there is a config I can change to avoid having From:
>>>=20
>>>>=20
>>>>>=20
>>>>> We should be able to copy upto count bytes
>>>>=20
>>>> Why?
>>>>=20
>>>=20
>>> Without this we end up doing
>>>=20
>>> + struct kvm_get_htab_buf {
>>> + struct kvm_get_htab_header header;
>>> + /*
>>> + * Older kernel required one extra byte.
>>> + */
>>> + unsigned long hpte[3];
>>> + } hpte_buf;
>>>=20
>>>=20
>>> even though we are only looking for one hpte entry.
>>=20
>> Ok, please give me an example with real numbers and why it breaks.
>>=20
>>>=20
>>> =
http://mid.gmane.org/1376995766-16526-4-git-send-email-aneesh.kumar@linux.=
vnet.ibm.com
>>>=20
>=20
> Didn't quiet get what you are looking for. As explained before, we now
> need to pass an array with array size 3 even though we know we need to
> read only 2 entries because kernel doesn't loop correctly.
But we need to do that regardless, because newer QEMU needs to be able =
to run on older kernels, no?
Alex
^ permalink raw reply
* Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang @ 2013-08-26 10:33 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree, vinod.koul, linux-kernel, djbw, Scott Wood,
linuxppc-dev
In-Reply-To: <5216D461.4010604@freescale.com>
On 08/23/2013 11:17 AM, Hongbo Zhang wrote:
> On 08/22/2013 07:16 AM, Stephen Warren wrote:
>> On 08/21/2013 05:00 PM, Scott Wood wrote:
>>> On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:
>>>> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
>>>>> + - reg : <registers mapping for channel>
>>>>> + - interrupts : <interrupt mapping for DMA channel
>>>>> IRQ>
>>>> s/interrupts/specifier/
>>> Do you mean s/interrupt mapping/interrupt specifier/?
>>>
>>> And probably s/registers mapping/register specifier/ as well.
>> Yup.
>>
> OK, I will update these descriptions.
>
Since Scott has clarified all the doubts, and no further comment till
now, so my next iteration will include this s/mapping/specifier only.
I will sent it out this Tuesday, if there is still any comment/doubt,
please let me know.
^ permalink raw reply
* Re: [PATCH 0/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag
From: Gleb Natapov @ 2013-08-26 10:20 UTC (permalink / raw)
To: Yann Droneaud
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, Alex Williamson,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <cover.1377372576.git.ydroneaud@opteya.com>
On Sat, Aug 24, 2013 at 10:14:06PM +0200, Yann Droneaud wrote:
> Hi,
>
> Following a patchset asking to change calls to get_unused_flag() [1]
> to use O_CLOEXEC, Alex Williamson [2][3] decided to change VFIO
> to use the flag.
>
> Since it's a related subsystem to KVM, using O_CLOEXEC for
> file descriptors created by KVM might be applicable too.
>
> I'm suggesting to change calls to anon_inode_getfd() to use O_CLOEXEC
> as default flag.
>
> This patchset should be reviewed to not break existing userspace program.
>
> BTW, if it's not applicable, I would suggest that new ioctls be added to
> KVM subsystem, those ioctls would have a "flag" field added to their arguments.
> Such "flag" would let userspace choose the open flag to use.
> See for example other APIs using anon_inode_getfd() such as fanotify,
> inotify, signalfd and timerfd.
>
> You might be interested to read:
>
> - Secure File Descriptor Handling (Ulrich Drepper, 2008)
> http://udrepper.livejournal.com/20407.html
>
> - Excuse me son, but your code is leaking !!! (Dan Walsh, March 2012)
> http://danwalsh.livejournal.com/53603.html
>
Applied, thanks.
> Regards.
>
> [1] http://lkml.kernel.org/r/cover.1376327678.git.ydroneaud@opteya.com
> [2] http://lkml.kernel.org/r/1377186804.25163.17.camel@ul30vt.home
> [3] http://lkml.kernel.org/r/20130822171744.1297.13711.stgit@bling.home
>
> Yann Droneaud (2):
> kvm: use anon_inode_getfd() with O_CLOEXEC flag
> ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
>
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
> arch/powerpc/kvm/book3s_64_vio.c | 2 +-
> arch/powerpc/kvm/book3s_hv.c | 2 +-
> virt/kvm/kvm_main.c | 6 +++---
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> --
> 1.8.3.1
--
Gleb.
^ permalink raw reply
* Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
From: Yann Droneaud @ 2013-08-26 8:23 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, Gleb Natapov, Paolo Bonzini, Alexander Graf, kvm-ppc,
linux-kernel, Alex Williamson, Paul Mackerras, linuxppc-dev
In-Reply-To: <521B0622.9090208@redhat.com>
Le 26.08.2013 09:39, Paolo Bonzini a écrit :
> Il 25/08/2013 17:04, Alexander Graf ha scritto:
>> On 24.08.2013, at 21:14, Yann Droneaud wrote:
>>
>>>
>>> This patch set O_CLOEXEC flag on all file descriptors created
>>> with anon_inode_getfd() to not leak file descriptors across exec().
>>>
>>> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
>>> Link:
>>> http://lkml.kernel.org/r/cover.1377372576.git.ydroneaud@opteya.com
>>
>> Reviewed-by: Alexander Graf <agraf@suse.de>
>>
>> Would it make sense to simply inherit the O_CLOEXEC flag from the
>> parent kvm fd instead? That would give user space the power to keep
>> fds across exec() if it wants to.
>
> Does it make sense to use non-O_CLOEXEC file descriptors with KVM at
> all? Besides fork() not being supported by KVM, as described in
> Documentation/virtual/kvm/api.txt, the VMAs of the parent process go
> away as soon as you exec(). I'm not sure how you can use the inherited
> file descriptor in a sensible way after exec().
>
Sounds a lot like InfiniBand subsystem behavor: IB file descriptors
are of no use accross exec() since memory mappings tied to those fds
won't be available in the new process:
https://lkml.org/lkml/2013/7/8/380
http://mid.gmane.org/f58540dc64fec1ac0e496dfcd3cc1af7@meuh.org
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply
* Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
From: Paolo Bonzini @ 2013-08-26 8:28 UTC (permalink / raw)
To: Yann Droneaud
Cc: kvm, Gleb Natapov, Paolo Bonzini, Alexander Graf, kvm-ppc,
linux-kernel, Alex Williamson, Paul Mackerras, linuxppc-dev
In-Reply-To: <156342996ba92cb5f49519b0c2e9d6ac@meuh.org>
Il 26/08/2013 10:23, Yann Droneaud ha scritto:
>
> Sounds a lot like InfiniBand subsystem behavor: IB file descriptors
> are of no use accross exec() since memory mappings tied to those fds
> won't be available in the new process:
>
> https://lkml.org/lkml/2013/7/8/380
> http://mid.gmane.org/f58540dc64fec1ac0e496dfcd3cc1af7@meuh.org
Yes, it is very similar.
Paolo
^ permalink raw reply
* Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
From: Paolo Bonzini @ 2013-08-26 7:39 UTC (permalink / raw)
To: Alexander Graf
Cc: Yann Droneaud, kvm, Gleb Natapov, linux-kernel, kvm-ppc,
Alex Williamson, Paul Mackerras, linuxppc-dev
In-Reply-To: <3557EF65-4327-4DAE-999A-B0EE13C433F5@suse.de>
Il 25/08/2013 17:04, Alexander Graf ha scritto:
>
> On 24.08.2013, at 21:14, Yann Droneaud wrote:
>
>> KVM uses anon_inode_get() to allocate file descriptors as part
>> of some of its ioctls. But those ioctls are lacking a flag argument
>> allowing userspace to choose options for the newly opened file descriptor.
>>
>> In such case it's advised to use O_CLOEXEC by default so that
>> userspace is allowed to choose, without race, if the file descriptor
>> is going to be inherited across exec().
>>
>> This patch set O_CLOEXEC flag on all file descriptors created
>> with anon_inode_getfd() to not leak file descriptors across exec().
>>
>> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
>> Link: http://lkml.kernel.org/r/cover.1377372576.git.ydroneaud@opteya.com
>
> Reviewed-by: Alexander Graf <agraf@suse.de>
>
> Would it make sense to simply inherit the O_CLOEXEC flag from the
> parent kvm fd instead? That would give user space the power to keep
> fds across exec() if it wants to.
Does it make sense to use non-O_CLOEXEC file descriptors with KVM at
all? Besides fork() not being supported by KVM, as described in
Documentation/virtual/kvm/api.txt, the VMAs of the parent process go
away as soon as you exec(). I'm not sure how you can use the inherited
file descriptor in a sensible way after exec().
Paolo
^ permalink raw reply
* [PATCH] powerpc: DSCR FSCR cleanup
From: Michael Neuling @ 2013-08-26 3:55 UTC (permalink / raw)
To: benh; +Cc: Linux PPC dev, Paul Mackerras
As suggested by paulus we can simplify the Data Stream Control Register
(DSCR) Facility Status and Control Register (FSCR) handling.
Firstly, we simplify the asm by using a rldimi.
Secondly, we now use the FSCR only to control the DSCR facility, rather
than both the FSCR and HFSCR. Users will see no functional change from
this but will get a minor speedup as they will trap into the kernel only
once (rather than twice) when they first touch the DSCR. Also, this
changes removes a bunch of ugly FTR_SECTION code.
Signed-off-by: Michael Neuling <mikey@neuling.org>
--
arch/powerpc/kernel/entry_64.S | 31 ++++++-------------------------
arch/powerpc/kernel/traps.c | 7 ++-----
2 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2bd0b88..513dc4d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -575,34 +575,15 @@ BEGIN_FTR_SECTION
ld r7,DSCR_DEFAULT@toc(2)
ld r0,THREAD_DSCR(r4)
cmpwi r6,0
- li r8, FSCR_DSCR
bne 1f
ld r0,0(r7)
- b 3f
1:
- BEGIN_FTR_SECTION_NESTED(70)
- mfspr r6, SPRN_FSCR
- or r6, r6, r8
- mtspr SPRN_FSCR, r6
- BEGIN_FTR_SECTION_NESTED(69)
- mfspr r6, SPRN_HFSCR
- or r6, r6, r8
- mtspr SPRN_HFSCR, r6
- END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
- b 4f
- END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
-3:
- BEGIN_FTR_SECTION_NESTED(70)
- mfspr r6, SPRN_FSCR
- andc r6, r6, r8
- mtspr SPRN_FSCR, r6
- BEGIN_FTR_SECTION_NESTED(69)
- mfspr r6, SPRN_HFSCR
- andc r6, r6, r8
- mtspr SPRN_HFSCR, r6
- END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
- END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
-4: cmpd r0,r25
+BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r8, SPRN_FSCR
+ rldimi r8, r6, FSCR_DSCR_LG, (63 - FSCR_DSCR_LG)
+ mtspr SPRN_FSCR, r8
+END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+ cmpd r0,r25
beq 2f
mtspr SPRN_DSCR,r0
2:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index e435bc0..0ba68a2 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1322,13 +1322,10 @@ void facility_unavailable_exception(struct pt_regs *regs)
if (status == FSCR_DSCR_LG) {
/* User is acessing the DSCR. Set the inherit bit and allow
* the user to set it directly in future by setting via the
- * H/FSCR DSCR bit.
+ * FSCR DSCR bit. We always leave HFSCR DSCR set.
*/
current->thread.dscr_inherit = 1;
- if (hv)
- mtspr(SPRN_HFSCR, value | HFSCR_DSCR);
- else
- mtspr(SPRN_FSCR, value | FSCR_DSCR);
+ mtspr(SPRN_FSCR, value | FSCR_DSCR);
return;
}
^ permalink raw reply related
* Re: [PATCH] powerpc/kvm: Handle the boundary condition correctly
From: Aneesh Kumar K.V @ 2013-08-26 3:28 UTC (permalink / raw)
To: Alexander Graf; +Cc: paulus, linuxppc-dev, kvm-ppc
In-Reply-To: <527D8312-EA18-4962-9069-B54FA738F5FA@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 23.08.2013, at 04:31, Aneesh Kumar K.V wrote:
>
>> Alexander Graf <agraf@suse.de> writes:
>>
>>> On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
>>>
>>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>
>>> Isn't this you?
>>
>> Yes. The patches are generated using git format-patch and sent by
>> git send-email. That's how it always created patches for me. I am not sure if
>> there is a config I can change to avoid having From:
>>
>>>
>>>>
>>>> We should be able to copy upto count bytes
>>>
>>> Why?
>>>
>>
>> Without this we end up doing
>>
>> + struct kvm_get_htab_buf {
>> + struct kvm_get_htab_header header;
>> + /*
>> + * Older kernel required one extra byte.
>> + */
>> + unsigned long hpte[3];
>> + } hpte_buf;
>>
>>
>> even though we are only looking for one hpte entry.
>
> Ok, please give me an example with real numbers and why it breaks.
>
>>
>> http://mid.gmane.org/1376995766-16526-4-git-send-email-aneesh.kumar@linux.vnet.ibm.com
>>
Didn't quiet get what you are looking for. As explained before, we now
need to pass an array with array size 3 even though we know we need to
read only 2 entries because kernel doesn't loop correctly.
-aneesh
^ permalink raw reply
* RE: [v3] powerpc/mpc85xx: Update the clock device tree nodes
From: Tang Yuantian-B29983 @ 2013-08-26 2:42 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130823200827.GA29737@home.buserror.net>
> >
> > clockgen: global-utilities@e1000 {
> > - compatible =3D "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
> > + compatible =3D "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0",
> > + "fixed-clock";
> > + clock-output-names =3D "sysclk";
> > + #clock-cells =3D <0>;
>=20
> Does U-Boot fill in clock-frequency here?
>=20
Yes, clock-frequency will be filled by uboot.
You suggested we'd better not add it here.
> > + #address-cells =3D <1>;
> > + #size-cells =3D <0>;
> > + pll0: pll0@800 {
> > + #clock-cells =3D <1>;
> > + reg =3D <0x800>;
> > + compatible =3D "fsl,core-pll-clock";
> > + clocks =3D <&clockgen>;
> > + clock-output-names =3D "pll0", "pll0-div2", "pll0-div4";
> > + };
> > + pll1: pll1@820 {
> > + #clock-cells =3D <1>;
> > + reg =3D <0x820>;
> > + compatible =3D "fsl,core-pll-clock";
> > + clocks =3D <&clockgen>;
> > + clock-output-names =3D "pll1", "pll1-div2", "pll1-div4";
> > + };
>=20
> Please leave a blank line between properties and nodes, and between nodes=
.
>=20
OK, will add.
> What does reg represent? Where is the binding for this?
>=20
> The compatible is too vague.
Reg is register offset. I should have had a binding document.
About the compatible, you should pointed it out earlier in SDK review.
It is too later to change since the clock driver is merged for months altho=
ugh=20
I sent this patch first.
Besides, it is not too bad because other arch use the similar name.
Regards,
Yuantian
>=20
> > + mux0: mux0@0 {
> > + #clock-cells =3D <0>;
> > + reg =3D <0x0>;
> > + compatible =3D "fsl,core-mux-clock";
> > + clocks =3D <&pll0 0>, <&pll0 1>, <&pll0 2>,
> > + <&pll1 0>, <&pll1 1>, <&pll1 2>;
> > + clock-names =3D "pll0_0", "pll0_1", "pll0_2",
> > + "pll1_0", "pll1_1", "pll1_2";
> > + clock-output-names =3D "cmux0";
> > + };
>=20
> What does reg represent? Where is the binding for this?
>=20
> The compatible is too vague.
>=20
> -Scott
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
From: Wang Dongsheng-B40534 @ 2013-08-26 2:34 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Zhao Chenhui-B35336
In-Reply-To: <1377271865.20722.44.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMjMsIDIwMTMgMTE6MzEgUE0NCj4gVG86IFdhbmcg
RG9uZ3NoZW5nLUI0MDUzNA0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IEt1bWFyIEdhbGE7IFpo
YW8gQ2hlbmh1aS1CMzUzMzY7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBT
dWJqZWN0OiBSZTogW1BBVENIIDEvMl0gcG93ZXJwYy84NXh4OiBhZGQgaGFyZHdhcmUgYXV0b21h
dGljYWxseSBlbnRlcg0KPiBhbHRpdmVjIGlkbGUgc3RhdGUNCj4gDQo+IE9uIFRodSwgMjAxMy0w
OC0yMiBhdCAyMTo1MiAtMDUwMCwgV2FuZyBEb25nc2hlbmctQjQwNTM0IHdyb3RlOg0KPiA+DQo+
ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogV29vZCBTY290dC1C
MDc0MjENCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjIsIDIwMTMgMTE6MTkgUE0NCj4g
PiA+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+IENjOiBXb29kIFNjb3R0LUIwNzQy
MTsgS3VtYXIgR2FsYTsgWmhhbyBDaGVuaHVpLUIzNTMzNjsgbGludXhwcGMtDQo+ID4gPiBkZXZA
bGlzdHMub3psYWJzLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzJdIHBvd2VycGMv
ODV4eDogYWRkIGhhcmR3YXJlIGF1dG9tYXRpY2FsbHkNCj4gZW50ZXINCj4gPiA+IGFsdGl2ZWMg
aWRsZSBzdGF0ZQ0KPiA+ID4NCj4gPiA+IE9uIFdlZCwgMjAxMy0wOC0yMSBhdCAyMjoxMyAtMDUw
MCwgV2FuZyBEb25nc2hlbmctQjQwNTM0IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjEN
Cj4gPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjAsIDIwMTMgODozOSBBTQ0KPiA+ID4g
PiA+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+ID4gPiBDYzogV29vZCBTY290dC1C
MDc0MjE7IEt1bWFyIEdhbGE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiA+
ID4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzJdIHBvd2VycGMvODV4eDogYWRkIGhhcmR3YXJlIGF1
dG9tYXRpY2FsbHkNCj4gPiA+ID4gPiBlbnRlciBhbHRpdmVjIGlkbGUgc3RhdGUNCj4gPiA+ID4g
Pg0KPiA+ID4gPiA+IEl0IGp1c3Qgc2VlbXMgd3JvbmcgdG8gaGF2ZSBhbiBhZC1ob2MgbWVjaGFu
aXNtIGZvciBydW5uaW5nDQo+ID4gPiA+ID4gY29yZS1zcGVjaWZpYyBjb2RlIHdoZW4gd2UgaGF2
ZSBjcHV0YWJsZS4uLiAgSWYgd2UgcmVhbGx5IG5lZWQNCj4gdGhpcywNCj4gPiA+ID4gPiBtYXli
ZSB3ZSBzaG91bGQgYWRkIGEgImNwdV9zZXR1cF9sYXRlIiBmdW5jdGlvbiBwb2ludGVyLg0KPiA+
ID4gPiA+DQo+ID4gPiA+ID4gV2l0aCB5b3VyIHBhdGNoLCB3aGVuIGRvZXMgdGhlIHBvd2VyIG1h
bmFnZW1lbnQgcmVnaXN0ZXIgZ2V0IHNldA0KPiA+ID4gPiA+IHdoZW4gaG90IHBsdWdnaW5nIGEg
Y3B1Pw0KPiA+ID4gPiA+DQo+ID4gPiA+IFVtLi4gSSBkb24ndCBkZWFsIHdpdGggdGhpcyBzaXR1
YXRpb24uIEkgd2lsbCBmaXggaXQuDQo+ID4gPiA+IF9fc2V0dXAvcmVzdG9yZV9jcHVfZTY1MDAg
bG9va3MgZ29vZC4gQnV0IG9ubHkgYm9vdGNwdSBjYWxsDQo+ID4gPiBfX3NldHVwX2NwdV9lNjUw
MCwgbm90IG9uIGVhY2ggY3B1Lg0KPiA+ID4gPiBJIHRoaW5rIHRoaXMgaXMgYSBidWcuDQo+ID4g
Pg0KPiA+ID4gT3RoZXIgQ1BVcyBjYWxsIF9fcmVzdG9yZV9jcHVfZTY1MDAuDQo+ID4gPg0KPiA+
IE5vLCB0aGVyZSBpcyBib290Y29yZSBvZiBzZWNvbmRhcnkgdGhyZWFkLCBhbmQgb3RoZXIgY29y
ZXMgb2YgZmlyc3QNCj4gdGhyZWFkIGNhbGwgX19yZXN0b3JlX2NwdV9lNjUwMC4NCj4gDQo+IFRo
aXMgaXMgdGhlIHVwc3RyZWFtIGxpc3QgLS0gdGhlcmUgaXMgbm8gZTY1MDAgdGhyZWFkIHN1cHBv
cnQgeWV0LiA6LSkNCj4gDQo+IEJ1dCBpbiB0aGUgU0RLIEkgZG8gc2VlIGdlbmVyaWNfc2Vjb25k
YXJ5X2NvbW1vbl9pbml0IGJlaW5nIGNhbGxlZCBmcm9tDQo+IGdlbmVyaWNfc2Vjb25kYXJ5X3Ro
cmVhZF9pbml0LCB3aGljaCBtZWFucyBfX3Jlc3RvcmVfY3B1X2U2NTAwIHdpbGwgYmUNCj4gY2Fs
bGVkLg0KDQpUaGFua3MuDQo=
^ permalink raw reply
* Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction
From: Zhang Haijun @ 2013-08-26 1:50 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linux-mmc@vger.kernel.org,
cbouatmailru@gmail.com, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org, Xie Xiaobo-R63061
In-Reply-To: <521AA947.6080209@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
On 08/26/2013 09:03 AM, Zhang Haijun wrote:
> On 08/23/2013 11:40 PM, Scott Wood wrote:
>> On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote:
>>> Hi, Anton and all
>>>
>>> Is there any advice on these two patches ?
>>>
>>> [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system
>>> transaction
>>> [PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.
>>>
>>>
>>> [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
>>> This patch is Act-by Scott.
>>> Patch 4/4 is split to four patches and Act-by Anton.
>>>
>>>
>>> Thanks all.
>>>
>>>
>>>
>> [snip]
>>>>> + if (!(((SVR_SOC_VER(svr) == SVR_T4240) && (SVR_REV(svr) == 0x10))
>>>>> ||
>>>>> + ((SVR_SOC_VER(svr) == SVR_B4860) && (SVR_REV(svr) == 0x10))
>>>>> ||
>>>>> + ((SVR_SOC_VER(svr) == SVR_P1010) && (SVR_REV(svr) == 0x10))
>>>>> ||
>>>>> + ((SVR_SOC_VER(svr) == SVR_P3041) && (SVR_REV(svr) <= 0x20))
>>>>> ||
>>>>> + ((SVR_SOC_VER(svr) == SVR_P2041) && (SVR_REV(svr) <= 0x20))
>>>>> ||
>>>>> + ((SVR_SOC_VER(svr) == SVR_P5040) && SVR_REV(svr) == 0x20)))
>>>>> + return;
>> You need to include variants here. If P5040 is affected, then P5021 is
>> affected. If P2041 is affected, then P2040 is affected, etc.
>>
>> -Scott
>>
>>
> Hi, Scott
>
> This workaround is for CR:ENGR00229586: A-005055, Configs Affected
> onlylist these soc and its version.
> I was also wonder why only these boards?
>
> But Ican't add soc like P5021 as I think it should be. Maybe there are
> some difference between them.
>
> --
> Thanks & Regards
>
> Haijun
Hi, Scott
I found there are update about this errata.
I'll update thispatch.
Thanks.
--
Thanks & Regards
Haijun
[-- Attachment #2: Type: text/html, Size: 4265 bytes --]
^ permalink raw reply
* Re: Detecting LD/ST instruction
From: Michael Neuling @ 2013-08-26 1:37 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: eraninan, linuxppc-dev
In-Reply-To: <20130824084734.GA30210@us.ibm.com>
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> wrote:
> Michael Neuling [mikey@neuling.org] wrote:
> | > I am working on implementing the 'perf mem' command for Power
> | > systems. This would for instance, let us know where in the memory
> | > hierarchy (L1, L2, Local RAM etc) the data for a load/store
> | > instruction was found (hit).
> | >
> | > On Power7, if the mcmcra[DCACHE_MISS] is clear _and_ the
> | > instruction is a load/store, then it implies a L1-hit.
> | >
> | > Unlike on Power8, the Power7 event vector has no indication
> | > if the instruction was load/store.
> | >
> | > In the context of a PMU interrupt, is there any way to determine
> | > if an instruction is a load/store ?
> |
> | You could read the instruction from memory and work it out.
> |
> | We do something similar to this in power_pmu_bhrb_to() where we read the
> | instruction and work out where the branch is going to.
> |
> | If you do this, please use and/or extend the functions in
> | arch/powerpc/lib/code-patching.c
>
> Here is a draft of what I could come up with. With this patch,
> the number of L1 hits on Power7 matches that on Power8 for one
> application.
Nice, the approach is along the lines of what I was thinking.
> But, wondering if there is a more efficient way to do this - there
> are over 50 flavors of load and store!
I dunno, there might be. If you look at all the opcodes in binary,
there's often a nice little pattern you can use.
Did you catch all the VSX and VMX loads/stores?
<snip>
> + if (op == 31) {
> + n = sizeof(x_form_load_store) / sizeof(int);
> +
> + for (i = 0; i < n; i++) {
Yeah, this might be a bit slow... Are there any instructions with op ==
31 that aren't a load/store?
>
> + if (x_form_load_store[i] == load_store_xval(*instr))
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH V3] mmc:of_spi: Update the code of getting voltage-ranges
From: Zhang Haijun @ 2013-08-26 1:05 UTC (permalink / raw)
To: Chris Ball
Cc: linux-mmc, Haijun Zhang, cbouatmailru, scottwood, linuxppc-dev,
X.Xie
In-Reply-To: <87txiepflk.fsf@octavius.laptop.org>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On 08/25/2013 12:19 PM, Chris Ball wrote:
> Hi Haijun,
>
> On Sun, Aug 11 2013, Haijun Zhang wrote:
>> Using function mmc_of_parse_voltage() to get voltage-ranges.
>>
>> Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> The patchset contains patches 1-3 of 3, and also this unnumbered patch
> v3. Which order should I use to apply this patch?
>
> Thanks,
>
> - Chris.
Thanks Chris,
So, I'll numbered them an resend them to you.
Thanks a lot.
--
Thanks & Regards
Haijun
[-- Attachment #2: Type: text/html, Size: 1320 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction
From: Zhang Haijun @ 2013-08-26 1:03 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linux-mmc@vger.kernel.org,
cbouatmailru@gmail.com, cjb@laptop.org,
linuxppc-dev@lists.ozlabs.org, Xie Xiaobo-R63061
In-Reply-To: <1377272410.20722.46.camel@snotra.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
On 08/23/2013 11:40 PM, Scott Wood wrote:
> On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote:
>> Hi, Anton and all
>>
>> Is there any advice on these two patches ?
>>
>> [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system
>> transaction
>> [PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.
>>
>>
>> [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
>> This patch is Act-by Scott.
>> Patch 4/4 is split to four patches and Act-by Anton.
>>
>>
>> Thanks all.
>>
>>
>>
> [snip]
>>>> + if (!(((SVR_SOC_VER(svr) == SVR_T4240) && (SVR_REV(svr) == 0x10))
>>>> ||
>>>> + ((SVR_SOC_VER(svr) == SVR_B4860) && (SVR_REV(svr) == 0x10))
>>>> ||
>>>> + ((SVR_SOC_VER(svr) == SVR_P1010) && (SVR_REV(svr) == 0x10))
>>>> ||
>>>> + ((SVR_SOC_VER(svr) == SVR_P3041) && (SVR_REV(svr) <= 0x20))
>>>> ||
>>>> + ((SVR_SOC_VER(svr) == SVR_P2041) && (SVR_REV(svr) <= 0x20))
>>>> ||
>>>> + ((SVR_SOC_VER(svr) == SVR_P5040) && SVR_REV(svr) == 0x20)))
>>>> + return;
> You need to include variants here. If P5040 is affected, then P5021 is
> affected. If P2041 is affected, then P2040 is affected, etc.
>
> -Scott
>
>
Hi, Scott
This workaround is for CR:ENGR00229586: A-005055, Configs Affected
onlylist these soc and its version.
I was also wonder why only these boards?
But Ican't add soc like P5021 as I think it should be. Maybe there are
some difference between them.
--
Thanks & Regards
Haijun
[-- Attachment #2: Type: text/html, Size: 3364 bytes --]
^ permalink raw reply
* Re: Ethernet over PCIe driver for Inter-Processor Communication
From: David Hawkins @ 2013-08-25 22:38 UTC (permalink / raw)
To: Saravanan S; +Cc: linuxppc-dev@lists.ozlabs.org, Ira W. Snyder
In-Reply-To: <CAEqOc-SdBZgiB1HZOQAJhgq_epdGsqMXaiSO0Axcd9ZBq6kLDw@mail.gmail.com>
Hi S.Saravanan,
>> Root complex's would normally interrupt a device via a PCIe write
>> to a register in a BAR on the end-point (or in extended configuration
>> space registers depending on the hardware implementation).
>
> MPC8640 End point implements only the Type 0 header (Page 1116) . The
> header implements five BARs (Page 1165).
One of those BARs typically provides access to the PowerPC memory
mapped registers (or at least a 1MB window onto those registers).
This is how your root complex can write to some form of messaging
register.
>> PCIe drivers need some way to interrupt the processor, so there must
>> be an option somewhere ... for example, what are the message register
>> interrupts intended for? See p479
>>
>> http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8641DRM.pdf
>>
>> (Ira and myself have not used the MPC8640 so are not familiar with
>> its user manual).
>
> Message registers are for interrupting the processor. A write to
> them sends an interrupt to the processor. Actually message registers
> are used by the RC to enable interrupts to the processor when an EP
> sends an MSI transaction to RC. In RC driver i register separately for
> the msi interrupts from all three EPs.
This is pretty much what you are looking for then right?
The end-points interrrupt the root-complex using PCIe MSI interrupts,
whereas the root-complex interrupts an end-point by writing directly
to its MSI interrupt.
> To access them in the EP from the RC i will have to set an inbound
> window mapping the PIC register space in the EP to the PCI mem space
> assigned to it . An inbound window maps a PCI address on the bus
> received by the PCIe controller to a platform address. I will try that
> and let u know .
Right, as I comment above, one of the BARs typically exposes the PowerPC
internal registers.
>> Feel free to discuss your ideas for your PCIe driver (eg., why start
>> with rionet rather than Ira's driver), either on-list, or email Ira
>> and myself directly
>
> To be frank with you there was no particular reason in starting with
> rionet. Maybe because our board also had SRIO interface and we are using
> rionet driver successfully. I had looked at Ira's driver later. I will
> study that also and try to come back with a skeleton for my driver.
Its always a good idea to discuss different options, and to stub out
drivers or create minimal (but functional) drivers. That way you'll
be able to see how similar your new driver is to other drivers, and
you'll quickly discover if there is a hardware feature in the
existing driver that you cannot emulate (eg., some SRIO feature
used by the rionet driver).
>> One further note. You might want to look at rproc/rpmsg and their virtio
>> driver support. That seems to be where the Linux world is moving for
>> inter-processor communications. See for example the ARM CPUs interfacing
>> with DSPs.
>
> I will study that as i am not familiar with virtio .
Follow Ira's advice. Talk to the guys working on virtio, tell them what
you are trying to do. They'll likely have good advice for you.
Good luck!
Cheers,
Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox