* Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Benjamin Herrenschmidt @ 2013-09-11 1:15 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Chivers, paulus, linuxppc-dev, cproctor
In-Reply-To: <1378856847.12204.380.camel@snotra.buserror.net>
On Tue, 2013-09-10 at 18:47 -0500, Scott Wood wrote:
> No blank line before }
>
> > +CONFIG_CMDLINE_BOOL=y
> > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
>
> I take it there's no way to pass a command line in from whatever loader
> this board uses... but you could put it in the dts instead.
No, please don't put that in the device-tree. Somebody might want
different settings, this is typically what .config is for.
> Did you ever figure out the problem with the combined defconfig?
>
> > + help
> > + This option enables support for the Motorola (now Emerson) MVME5100
> > + board.
>
> Whitespace
>
> > +/* Board register addresses. */
> > +#define BOARD_STATUS_REG 0xfef88080
> > +#define BOARD_MODFAIL_REG 0xfef88090
> > +#define BOARD_MODRST_REG 0xfef880a0
> > +#define BOARD_TBEN_REG 0xfef880c0
> > +#define BOARD_SW_READ_REG 0xfef880e0
> > +#define BOARD_GEO_ADDR_REG 0xfef880e8
> > +#define BOARD_EXT_FEATURE1_REG 0xfef880f0
> > +#define BOARD_EXT_FEATURE2_REG 0xfef88100
>
> Use a space rather than a tab after #define.
>
> > +static unsigned int pci_membase;
>
> phys_addr_t
>
> > +static void mvme5100_restart(char *cmd)
> > +{
> > + u_char *restart;
>
> Is all that tabbing before "*restart" really necessary?
>
> > + restart = ioremap(BOARD_MODRST_REG, 4);
> > + local_irq_disable();
> > + mtmsr(mfmsr() | MSR_IP);
> > +
> > + out_8((u_char *) restart, 0x01);
>
> If ioremap() fails you'll panic here.
>
> In any case, you should map things at boot time.
>
> -Scott
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Stephen N Chivers @ 2013-09-11 0:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Chris Proctor
In-Reply-To: <1378856847.12204.380.camel@snotra.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 09/11/2013 09:47:27 AM:
> From: Scott Wood <scottwood@freescale.com>
> To: Stephen N Chivers/AUS/CSC@CSC
> Cc: Chris Proctor/AUS/CSC@CSC, <linuxppc-dev@lists.ozlabs.org>,
> <paulus@samba.org>, <benh@kernel.crashing.org>
> Date: 09/11/2013 09:47 AM
> Subject: Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100.
>
> On Thu, 2013-09-05 at 15:51 +1000, Stephen Chivers wrote:
> > Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> >
> > The MVME5100 is a 6U form factor VME64 computer with:
> >
> > - A single MPC7410 or MPC750 CPU
> > - A HAWK Processor Host Bridge (CPU to PCI) and
> > MultiProcessor Interrupt Controller (MPIC)
> > - Up to 500Mb of onboard memory
> > - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> > - Two 16550 compatible UARTS
> > - Two Intel E100 Fast Ethernets
> > - Two PCI Mezzanine Card (PMC) Slots
> > - PPCBug Firmware
> >
> > The HAWK PHB/MPIC is compatible with the MPC10x devices.
> >
> > There is no onboard disk support. This is usually provided by
> > installing a PMC in the first PMC slot.
> >
> > This patch revives the board support, it was present in early 2.6
> > series kernels. The board support in those days was by Matt Porter of
> > MontaVista Software.
> >
> > CSC Australia has around 31 of these boards in service. The kernel in
use
> > for the boards is based on 2.6.31. The boards are operated without
disks
> > from a file server.
> >
> > This patch is based on linux-3.11-rc7 and has been boot tested.
> >
> > V1->V2:
> > Address comments by Kular Gama and Scott Wood.
> > Minor adjustment to platforms/embedded6xx/Kconfig to ensure
> > correct indentation where possible.
> >
> > Signed-off-by: Stephen Chivers <schivers@csc.com>
> > ---
>
> Some comments below, and please run checkpatch.pl, but the next version
> can probably be non-RFC if you're happy with it.
Ok.
>
> > + PowerPC,7410 {
> > + device_type = "cpu";
> > + reg = <0x0>;
> > + /* Following required by dtc but not used */
> > + d-cache-line-size = <32>;
> > + i-cache-line-size = <32>;
> > + i-cache-size = <32768>;
> > + d-cache-size = <32768>;
> > + timebase-frequency = <25000000>;
> > + clock-frequency = <500000000>;
> > + bus-frequency = <100000000>;
> > + };
>
> Whitespace on bus-frequency
Ok. Will fix.
>
> > + mpic: interrupt-controller@f3f80000 {
> > + #interrupt-cells = <2>;
> > + #address-cells = <0>;
> > + device_type = "open-pic";
> > + compatible = "chrp,open-pic";
> > + interrupt-controller;
> > + reg = <0xf3f80000 0x40000>;
> > + };
> > +
> > + };
>
> No blank line before }
Ok. Will be fixed.
>
> > +CONFIG_CMDLINE_BOOL=y
> > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
>
> I take it there's no way to pass a command line in from whatever loader
> this board uses... but you could put it in the dts instead.
>
It can be done by reading the NVRAM/RTC (M48T37) and "overriding" the
DTS specification. But I wanted to keep things simple to start
with.
Putting the default command line in the DTS is required to support
a combined "defconfig" (pp6xx_defconfig) and I know it does work.
So I will do that.
> Did you ever figure out the problem with the combined defconfig?
Not really. But I have been forced to think about that as a new
project will be using some PMCs with 8250 UARTS (PCI) and they are
another way that the console moves from the debug port on the front
panel to somewhere else.
It is very likely that the HAWK UARTS will have to be registered as
platform devices by the board support file itself.
>
> > + help
> > + This option enables support for the Motorola (now
> Emerson) MVME5100
> > + board.
>
> Whitespace
Ok.
>
> > +/* Board register addresses. */
> > +#define BOARD_STATUS_REG 0xfef88080
> > +#define BOARD_MODFAIL_REG 0xfef88090
> > +#define BOARD_MODRST_REG 0xfef880a0
> > +#define BOARD_TBEN_REG 0xfef880c0
> > +#define BOARD_SW_READ_REG 0xfef880e0
> > +#define BOARD_GEO_ADDR_REG 0xfef880e8
> > +#define BOARD_EXT_FEATURE1_REG 0xfef880f0
> > +#define BOARD_EXT_FEATURE2_REG 0xfef88100
>
> Use a space rather than a tab after #define.
Ok.
>
> > +static unsigned int pci_membase;
>
> phys_addr_t
Ok.
>
> > +static void mvme5100_restart(char *cmd)
> > +{
> > + u_char *restart;
>
> Is all that tabbing before "*restart" really necessary?
Will fix.
>
> > + restart = ioremap(BOARD_MODRST_REG, 4);
> > + local_irq_disable();
> > + mtmsr(mfmsr() | MSR_IP);
> > +
> > + out_8((u_char *) restart, 0x01);
>
> If ioremap() fails you'll panic here.
Ok. Will do in mvme5100_setup_arch.
>
> In any case, you should map things at boot time.
>
> -Scott
Thanks,
Stephen.
>
>
>
^ permalink raw reply
* Re: [PATCH][RFC][v2] pci: fsl: rework PCIe driver compatible with Layerscape
From: Scott Wood @ 2013-09-11 0:25 UTC (permalink / raw)
To: Minghuan Lian; +Cc: linuxppc-dev, Zang Roy-R61911
In-Reply-To: <1377686572-3981-1-git-send-email-Minghuan.Lian@freescale.com>
On Wed, 2013-08-28 at 18:42 +0800, Minghuan Lian wrote:
> The Freescale's Layerscape series processors will use ARM cores.
> The LS1's PCIe controllers is the same as T4240's. So it's better
> the PCIe controller driver can support PowerPC and ARM
> simultaneously. This patch is for this purpose. It derives
> the common functions from arch/powerpc/sysdev/fsl_pci.c to
> drivers/pci/host/pcie-fsl.c and leaves several platform-dependent
> functions which should be implemented in platform files.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> ---
> Based on upstream master 3.11-rc7
> The function has been tested on MPC8315ERDB MPC8572DS P5020DS P3041DS
> and T4240QDS boards
>
> Change log:
> v2:
> 1. Use 'pci' instead of 'pcie' in new file name and file contents.
> 2. Use iowrite32be()/iowrite32() instead of out_be32/le32()
> 3. Fix ppc_md.dma_set_mask setting
> 4. Synchronizes host->first_busno and pci->first_busno.
> 5. Fix PCI IO space settings
> 6. Some small changes according to Scott's comments.
Could you please split this into two patches, where one moves the code,
and the other makes changes to it?
-Scott
^ permalink raw reply
* Re: [PATCH 2/6] powerpc: Provide for giveup_fpu/altivec to save state in alternate location
From: Paul Mackerras @ 2013-09-10 23:54 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <675235E3-6991-4DB1-90A4-935E826F6413@suse.de>
On Tue, Sep 10, 2013 at 12:12:47PM -0500, Alexander Graf wrote:
>
> On 10.09.2013, at 05:21, Paul Mackerras wrote:
>
> > @@ -212,6 +212,7 @@ struct thread_struct {
> > #endif
> > #endif
> > struct thread_fp_state fp_state;
> > + struct thread_fp_state *fp_save_area;
>
> Why do you need these pointers? Couldn't you handle everything you need through preempt notifiers?
As you note in your review of a later patch, no, I need the pointer so
that if in-kernel code wants to use FP or VSX, potentially in the
context of this same process, it knows where to save the FP/VSX state
away to.
Paul.
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: Put FP/VSX and VR state into structures
From: Paul Mackerras @ 2013-09-10 23:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <992F9967-6DA8-4BDF-A6BC-A8F9E8F4FF7D@suse.de>
On Tue, Sep 10, 2013 at 12:07:46PM -0500, Alexander Graf wrote:
>
> On 10.09.2013, at 05:20, Paul Mackerras wrote:
> > @@ -897,7 +897,7 @@ int fix_alignment(struct pt_regs *regs)
> > return -EFAULT;
> > }
> > } else if (flags & F) {
> > - data.dd = current->thread.TS_FPR(reg);
> > + data.ll = current->thread.TS_FPR(reg);
>
> I don't understand this change. Could you please explain?
It's simply that the type which we use to store the FPR values is now
an unsigned integer type rather than a floating-point type. If I
didn't make this change, the compiler would try to convert that
unsigned integer value into a floating-point value, which we don't
want.
> > --- a/arch/powerpc/kernel/tm.S
> > +++ b/arch/powerpc/kernel/tm.S
> > @@ -12,16 +12,15 @@
> > #include <asm/reg.h>
> >
> > #ifdef CONFIG_VSX
> > -/* See fpu.S, this is very similar but to save/restore checkpointed FPRs/VSRs */
> > -#define __SAVE_32FPRS_VSRS_TRANSACT(n,c,base) \
> > +/* See fpu.S, this is borrowed from there */
> > +#define __SAVE_32FPRS_VSRS(n,c,base) \
>
> Should this really be in tm.S with its new name?
Do you mean, could I merge it with __SAVE_32FPVSRS from fpu.S, put it
in ppc_asm.h and avoid having two very similar macros defined in
different places? Yes I could, and that's a good idea.
Paul.
^ permalink raw reply
* Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Scott Wood @ 2013-09-10 23:47 UTC (permalink / raw)
To: Stephen Chivers; +Cc: paulus, linuxppc-dev, cproctor
In-Reply-To: <20130905055122.F256EE07B6@canberra.localdomain>
On Thu, 2013-09-05 at 15:51 +1000, Stephen Chivers wrote:
> Add support for the Motorola/Emerson MVME5100 Single Board Computer.
>
> The MVME5100 is a 6U form factor VME64 computer with:
>
> - A single MPC7410 or MPC750 CPU
> - A HAWK Processor Host Bridge (CPU to PCI) and
> MultiProcessor Interrupt Controller (MPIC)
> - Up to 500Mb of onboard memory
> - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> - Two 16550 compatible UARTS
> - Two Intel E100 Fast Ethernets
> - Two PCI Mezzanine Card (PMC) Slots
> - PPCBug Firmware
>
> The HAWK PHB/MPIC is compatible with the MPC10x devices.
>
> There is no onboard disk support. This is usually provided by
> installing a PMC in the first PMC slot.
>
> This patch revives the board support, it was present in early 2.6
> series kernels. The board support in those days was by Matt Porter of
> MontaVista Software.
>
> CSC Australia has around 31 of these boards in service. The kernel in use
> for the boards is based on 2.6.31. The boards are operated without disks
> from a file server.
>
> This patch is based on linux-3.11-rc7 and has been boot tested.
>
> V1->V2:
> Address comments by Kular Gama and Scott Wood.
> Minor adjustment to platforms/embedded6xx/Kconfig to ensure
> correct indentation where possible.
>
> Signed-off-by: Stephen Chivers <schivers@csc.com>
> ---
Some comments below, and please run checkpatch.pl, but the next version
can probably be non-RFC if you're happy with it.
> + PowerPC,7410 {
> + device_type = "cpu";
> + reg = <0x0>;
> + /* Following required by dtc but not used */
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + i-cache-size = <32768>;
> + d-cache-size = <32768>;
> + timebase-frequency = <25000000>;
> + clock-frequency = <500000000>;
> + bus-frequency = <100000000>;
> + };
Whitespace on bus-frequency
> + mpic: interrupt-controller@f3f80000 {
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
> + device_type = "open-pic";
> + compatible = "chrp,open-pic";
> + interrupt-controller;
> + reg = <0xf3f80000 0x40000>;
> + };
> +
> + };
No blank line before }
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
I take it there's no way to pass a command line in from whatever loader
this board uses... but you could put it in the dts instead.
Did you ever figure out the problem with the combined defconfig?
> + help
> + This option enables support for the Motorola (now Emerson) MVME5100
> + board.
Whitespace
> +/* Board register addresses. */
> +#define BOARD_STATUS_REG 0xfef88080
> +#define BOARD_MODFAIL_REG 0xfef88090
> +#define BOARD_MODRST_REG 0xfef880a0
> +#define BOARD_TBEN_REG 0xfef880c0
> +#define BOARD_SW_READ_REG 0xfef880e0
> +#define BOARD_GEO_ADDR_REG 0xfef880e8
> +#define BOARD_EXT_FEATURE1_REG 0xfef880f0
> +#define BOARD_EXT_FEATURE2_REG 0xfef88100
Use a space rather than a tab after #define.
> +static unsigned int pci_membase;
phys_addr_t
> +static void mvme5100_restart(char *cmd)
> +{
> + u_char *restart;
Is all that tabbing before "*restart" really necessary?
> + restart = ioremap(BOARD_MODRST_REG, 4);
> + local_irq_disable();
> + mtmsr(mfmsr() | MSR_IP);
> +
> + out_8((u_char *) restart, 0x01);
If ioremap() fails you'll panic here.
In any case, you should map things at boot time.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property
From: Scott Wood @ 2013-09-10 23:33 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev
In-Reply-To: <1378454743-17637-1-git-send-email-Mingkai.Hu@freescale.com>
On Fri, 2013-09-06 at 16:05 +0800, Mingkai Hu wrote:
> Re-organize the SPI partitions and use the same SPI flash memory
> map for most of the platforms which have 16MB SPI flash mounted.
[snip]
> Based on 'next' branch on git tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>
> arch/powerpc/boot/dts/bsc9131rdb.dtsi | 35 ++++++++++++-----------------
> arch/powerpc/boot/dts/c293pcie.dts | 35 ++++++++++++-----------------
> arch/powerpc/boot/dts/mpc8536ds.dtsi | 12 +++++-----
> arch/powerpc/boot/dts/p1010rdb.dtsi | 40 ++++++++++++----------------------
> arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 24 +++++---------------
> arch/powerpc/boot/dts/p1020rdb-pd.dts | 34 ++++++++++++-----------------
> arch/powerpc/boot/dts/p1020rdb.dtsi | 23 ++++---------------
> arch/powerpc/boot/dts/p1021mds.dts | 17 +++++++--------
> arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 32 +++++++++------------------
> arch/powerpc/boot/dts/p1022ds.dtsi | 21 +++++++++---------
> arch/powerpc/boot/dts/p1023rds.dts | 10 ++-------
> arch/powerpc/boot/dts/p1024rdb.dtsi | 40 ++++++++++++----------------------
> arch/powerpc/boot/dts/p1025rdb.dtsi | 23 +++++--------------
> arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 40 ++++++++++++----------------------
> arch/powerpc/boot/dts/p2020rdb.dts | 38 ++++++++++----------------------
> arch/powerpc/boot/dts/p2041rdb.dts | 12 +++++-----
> arch/powerpc/boot/dts/p3041ds.dts | 12 +++++-----
> arch/powerpc/boot/dts/p4080ds.dts | 12 +++++-----
> arch/powerpc/boot/dts/p5020ds.dts | 12 +++++-----
> arch/powerpc/boot/dts/p5040ds.dts | 13 ++++++-----
What happens to exsting users whose flash is laid out the existing way,
when they upgrade to these device trees?
We really should not be putting partition layout info in the device tree
to begin with...
-Scott
^ permalink raw reply
* Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)
From: Guenter Roeck @ 2013-09-10 22:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Asai Thambi S P, linux-kernel@vger.kernel.org, Vasant Hegde,
Shivaprasad G Bhat, Paul Mackerras, linuxppc-dev
In-Reply-To: <1378850569.4121.28.camel@pasglop>
On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> > On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > > Hi all,
> > >
> > > powerpc allmodconfig build on the latest upstream kernel results in:
> > >
> > > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> > >
> > > This is due to commit 15863ff3b (powerpc: Make chip-id information
> > > available to userspace).
> > > Not surprising, as cpu_to_chip_id() is not exported.
> > >
> > Apart from the above error, I have a concern on the patch, purely based on the commit message.
> > (to be honest, I am not familiar with the ppc architecture)
> >
> > Commit message of 15863ff3b has the following text.
> >
> > ******************
> > So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> > was always default (-1) on ppc64 architecture.
> >
> > Now, some systems have an ibm,chip-id property in the cpu nodes in
> > the device tree. On these systems, we now use this information to
> > display physical_package_id
> > ******************
> >
> > Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
>
> There should be no negative side effect (appart from the missing
> EXPORT_SYMBOL of course). If the property is not found in the
> device-tree, the new function returns -1, so it should work fine on all
> systems.
>
Good. I submitted a patch doing just that yesterday or so.
Hope you'll accept it ;).
Thanks,
Guenter
^ permalink raw reply
* Re: Power PC Build problem
From: Scott Wood @ 2013-09-10 22:40 UTC (permalink / raw)
To: Jason Rennie; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <5226A3E3.2050308@rftechnology.com.au>
On Wed, 2013-09-04 at 13:07 +1000, Jason Rennie wrote:
> But when I try building it with the latest buildroot (2013.08) and I
> configure the kernel (3.10.10) I get one of two things. If I don't
> include specific settings for physmap compat support (Device Drivers
> -> MTD Support -> Mapping drivers for chip access) then I get a kernel
> panic when it can't mount the root filesystem as follows
[snip]
> -----------
> and when I do include the physmap settings
>
> <*> Flash device in physical memory map
> [*] Physmap compat support
> (0xFF000000) Physical start address of flash mapping
> (0x1000000) Physical length of flash mapping
> (2) Bank width in octets
>
> which I took from the earlier build and do seem to be right, it does
> the following.
> --------------------
> f0011a00.serial: ttyCPM0 at MMIO 0xc505ea00 (irq = 40) is a CPM UART
> f0011a60.serial: ttyCPM1 at MMIO 0xc5060a60 (irq = 43) is a CPM UART
> brd: module loaded
> physmap platform flash device: 01000000 at ff000000
> Machine check in kernel mode.
> Caused by (from SRR1=49030): Transfer error ack signal
> Oops: Machine check, sig: 7 [#1]
> PREEMPT Freescale MPC8272 ADS
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.10 #12
> task: c3830000 ti: c3832000 task.ti: c3832000
> NIP: c01a5da8 LR: c01a6200 CTR: c01a60cc
> REGS: c3833c00 TRAP: 0200 Not tainted (3.10.10)
> MSR: 00049030 <EE,ME,IR,DR> CR: 22000022 XER: 00000000
>
> GPR00: c01a59a0 c3833cb0 c3830000 00000000 c39c0e24 c3833cf8 00000002
> 00000aaa
> GPR08: c5080000 0000aaaa 00000002 00000002 42000024 00000000 c000406c
> 00000000
> GPR16: 00000000 00000000 c39c0e24 c02c9ff4 00000001 c02c8d30 c02c9fe8
> c0356e23
> GPR24: c02c8d78 00000001 00000000 00000001 c03b89d8 00000000 c39c0e24
> c3833cf8
> NIP [c01a5da8] jedec_reset+0x124/0x448
> LR [c01a6200] jedec_probe_chip+0x134/0x1050
> Call Trace:
> [c3833cb0] [c002d900] call_usermodehelper_exec+0x154/0x160
> (unreliable)
> [c3833cf0] [c01a59a0] mtd_do_chip_probe+0x78/0x34c
> [c3833d70] [c01a73a8] physmap_flash_probe+0x1ec/0x30c
> [c3833db0] [c01996c8] driver_probe_device+0xb8/0x1f4
> [c3833dd0] [c0197a64] bus_for_each_drv+0x60/0xa8
> [c3833e00] [c01995d8] device_attach+0x7c/0x94
> [c3833e20] [c0198ac4] bus_probe_device+0x34/0xac
> [c3833e40] [c0196f94] device_add+0x3d4/0x570
> [c3833e80] [c019acd0] platform_device_add+0x164/0x1dc
> [c3833ea0] [c039a438] physmap_init+0x34/0x50
> [c3833ec0] [c0003acc] do_one_initcall+0xdc/0x180
> [c3833ef0] [c0386bcc] kernel_init_freeable+0x11c/0x1c0
> [c3833f30] [c0004088] kernel_init+0x1c/0xf4
> [c3833f40] [c000d3a8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> 5529063e 7d2839ae 48000024 2f8a0002 40be0010 5529043e 7d283b2e
> 48000010
> 2f8a0004 409e0324 7d28392e 7c0004ac <81250008> 8105000c 81440018
> 7d6849d6
> ---[ end trace 06e97f39189bf8ef ]---
>
> Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000007
>
> Rebooting in 1 seconds..
> --------------------
> I assume it is crashing when it tries to probe the flash chips?
>
> I'm at a loss to work out what I am doing wrong here. Can anybody
> offer any pointers?
It sounds like the address you're specifying for flash is incorrect.
You shouldn't need to specify it this way; the information is in the
device tree (and for mpc8272ads the device tree says it's at
0xff800000).
Do you have CONFIG_MTD_PHYSMAP_OF enabled?
BTW, I don't see how this is a "build problem".
-Scott
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/b4860emu: Add device tree file for b4860emu
From: Scott Wood @ 2013-09-10 22:31 UTC (permalink / raw)
To: York Sun; +Cc: linuxppc-dev
In-Reply-To: <1378482199-10581-7-git-send-email-yorksun@freescale.com>
On Fri, 2013-09-06 at 08:43 -0700, York Sun wrote:
> B4860EMU is a emualtor target with minimum peripherals. It is based on
> B4860QDS and trimmed down most peripherals due to either not modeled or
> lack of board level connections. The main purpose of this minimum dts is
> to speed up booting on emulator.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
I did not give a reviewed-by in this context. Please strip gerrit tags
before posting.
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2";
It's "fsl,qoriq-clockgen-2.0" now.
Please be careful with copy-and-paste patches like this -- make sure
that it's up-to-date with what you copied from.
-Scott
^ permalink raw reply
* Re: [PATCH 3/7] i2c/rtc-ds3232: Fix irq for probing
From: Scott Wood @ 2013-09-10 22:26 UTC (permalink / raw)
To: York Sun; +Cc: linuxppc-dev
In-Reply-To: <1378482199-10581-3-git-send-email-yorksun@freescale.com>
On Fri, 2013-09-06 at 08:43 -0700, York Sun wrote:
> Driver shouldn't request irq when irq = 0. It is returned from parsing
> device tree. 0 means no interrupt.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Reviewed-by: Zang Tiefei-R61911 <tie-fei.zang@freescale.com>
> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> ---
> drivers/rtc/rtc-ds3232.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This should go via the i2c list and maintainer. It's not a PPC patch at
all.
Please do not lump unrelated patches into a single patchset.
-Scott
^ permalink raw reply
* Re: [PATCH 1/7] powerpc/mpc85xx: Fix EDAC address capture
From: Scott Wood @ 2013-09-10 22:25 UTC (permalink / raw)
To: York Sun; +Cc: linuxppc-dev
In-Reply-To: <1378482199-10581-1-git-send-email-yorksun@freescale.com>
On Fri, 2013-09-06 at 08:43 -0700, York Sun wrote:
> Extend err_addr to cover 64 bits for DDR errors.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> ---
> drivers/edac/mpc85xx_edac.c | 10 +++++++---
> drivers/edac/mpc85xx_edac.h | 1 +
> 2 files changed, 8 insertions(+), 3 deletions(-)
EDAC patches should go via the linux-edac list and maintainer.
BTW, were those "reviewed-by" and "tested-by" added by Andy manually, or
are they from gerrit? If the latter, please strip them before sending
upstream.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Export cpu_to_chip_id() to fix build error
From: Benjamin Herrenschmidt @ 2013-09-10 22:03 UTC (permalink / raw)
To: Guenter Roeck
Cc: Vasant Hegde, Paul Mackerras, linuxppc-dev, linux-kernel,
Shivaprasad G Bhat
In-Reply-To: <1378777076-4699-1-git-send-email-linux@roeck-us.net>
On Mon, 2013-09-09 at 18:37 -0700, Guenter Roeck wrote:
> powerpc allmodconfig build fails with:
>
> ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
>
> The problem was introduced with commit 15863ff3b (powerpc: Make chip-id
> information available to userspace).
Thanks, I'll send that to Linus asap.
Ben.
> Export the missing symbol.
>
> Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
> Cc: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/powerpc/kernel/smp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 442d8e2..8e59abc 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu)
> of_node_put(np);
> return of_get_ibm_chip_id(np);
> }
> +EXPORT_SYMBOL(cpu_to_chip_id);
>
> /* Helper routines for cpu to core mapping */
> int cpu_core_index_of_thread(int cpu)
^ permalink raw reply
* Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)
From: Benjamin Herrenschmidt @ 2013-09-10 22:02 UTC (permalink / raw)
To: Asai Thambi S P
Cc: linux-kernel@vger.kernel.org, Vasant Hegde, Paul Mackerras,
Shivaprasad G Bhat, linuxppc-dev, Guenter Roeck
In-Reply-To: <522E5FD5.40603@micron.com>
On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > Hi all,
> >
> > powerpc allmodconfig build on the latest upstream kernel results in:
> >
> > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> >
> > This is due to commit 15863ff3b (powerpc: Make chip-id information
> > available to userspace).
> > Not surprising, as cpu_to_chip_id() is not exported.
> >
> Apart from the above error, I have a concern on the patch, purely based on the commit message.
> (to be honest, I am not familiar with the ppc architecture)
>
> Commit message of 15863ff3b has the following text.
>
> ******************
> So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> was always default (-1) on ppc64 architecture.
>
> Now, some systems have an ibm,chip-id property in the cpu nodes in
> the device tree. On these systems, we now use this information to
> display physical_package_id
> ******************
>
> Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
There should be no negative side effect (appart from the missing
EXPORT_SYMBOL of course). If the property is not found in the
device-tree, the new function returns -1, so it should work fine on all
systems.
Cheers,
Ben.
>
> > Reverting this commit fixes the problem. Any good idea how to fix it
> > for real ?
> >
> > Guenter
> > --
> > 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/
^ permalink raw reply
* Re: [v3] powerpc/mpc85xx: Update the clock device tree nodes
From: Scott Wood @ 2013-09-10 21:46 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: <D07C73A334FF604B95B3CBD2A545D07B1503F161@039-SN2MPN1-012.039d.mgd.msft.net>
On Mon, 2013-08-26 at 21:49 -0500, Tang Yuantian-B29983 wrote:
> > > > > + };
> > > > > + 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?
>
> No size is needed.
Yes, it is. Register blocks have size -- even if it's just a single
register.
> > > 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.
> The Linux common clock framework is not ARM specific. Any other arch can use it.
Sure, it just seemed an odd choice of mailing list for something that
isn't ARM-specific.
> > 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.
> It is sub-clock node, is it really necessary to think about compatibility?
> I think that's the node clockgen's responsibility.
It describes registers, so yes, you need to consider compatibility. A
clock provider is not responsible for figuring out how to program
devices that consume its clocks, nor should it make any assumptions
about such devices.
> > > 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".
> Ok, I will change the compatible string.
> Do you think "fsl,ppc-core-*" is ok?
No. How about "fsl,qoriq-chassis1-*" (for e500mc/e5500) and
fsl,qoriq-chassis2-*" (for e6500)?
-Scott
^ permalink raw reply
* Re: [PATCH 6/6] KVM: PPC: Book3S HV: Use load/store_fp_state functions in HV guest entry/exit
From: Alexander Graf @ 2013-09-10 18:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <20130910102259.GG28145@iris.ozlabs.ibm.com>
On 10.09.2013, at 05:22, Paul Mackerras wrote:
> This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
> FP/VSX and VMX load/store functions instead of open-coding the
> FP/VSX/VMX load/store instructions. Since kvmppc_load/save_fp don't
> follow C calling conventions, we make them private symbols within
> book3s_hv_rmhandlers.S.
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/kernel/asm-offsets.c | 2 -
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 82 =
++++++++-------------------------
> 2 files changed, 18 insertions(+), 66 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/asm-offsets.c =
b/arch/powerpc/kernel/asm-offsets.c
> index 4c1609f..7982870 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -425,10 +425,8 @@ int main(void)
> DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
> DEFINE(VCPU_VRSAVE, offsetof(struct kvm_vcpu, arch.vrsave));
> DEFINE(VCPU_FPRS, offsetof(struct kvm_vcpu, arch.fp.fpr));
> - DEFINE(VCPU_FPSCR, offsetof(struct kvm_vcpu, arch.fp.fpscr));
> #ifdef CONFIG_ALTIVEC
> DEFINE(VCPU_VRS, offsetof(struct kvm_vcpu, arch.vr.vr));
> - DEFINE(VCPU_VSCR, offsetof(struct kvm_vcpu, arch.vr.vscr));
> #endif
> DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, arch.xer));
> DEFINE(VCPU_CTR, offsetof(struct kvm_vcpu, arch.ctr));
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S =
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index f5f2396..b5183ed 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1102,7 +1102,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
>=20
> /* save FP state */
> mr r3, r9
> - bl .kvmppc_save_fp
> + bl kvmppc_save_fp
>=20
> /* Increment yield count if they have a VPA */
> ld r8, VCPU_VPA(r9) /* do they have a VPA? */
> @@ -1591,7 +1591,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_206)
> std r31, VCPU_GPR(R31)(r3)
>=20
> /* save FP state */
> - bl .kvmppc_save_fp
> + bl kvmppc_save_fp
>=20
> /*
> * Take a nap until a decrementer or external interrupt occurs,
> @@ -1767,7 +1767,9 @@ kvm_no_guest:
> * Save away FP, VMX and VSX registers.
> * r3 =3D vcpu pointer
> */
> -_GLOBAL(kvmppc_save_fp)
> +kvmppc_save_fp:
> + mflr r30
> + mr r31,r3
Please note somewhere that e30 and r31 get clobbered by this function.
> mfmsr r5
> ori r8,r5,MSR_FP
> #ifdef CONFIG_ALTIVEC
> @@ -1782,42 +1784,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> #endif
> mtmsrd r8
> isync
> -#ifdef CONFIG_VSX
> -BEGIN_FTR_SECTION
> - reg =3D 0
> - .rept 32
> - li r6,reg*16+VCPU_FPRS
> - STXVD2X(reg,R6,R3)
> - reg =3D reg + 1
> - .endr
> -FTR_SECTION_ELSE
> -#endif
> - reg =3D 0
> - .rept 32
> - stfd reg,reg*8+VCPU_FPRS(r3)
> - reg =3D reg + 1
> - .endr
> -#ifdef CONFIG_VSX
> -ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
> -#endif
> - mffs fr0
> - stfd fr0,VCPU_FPSCR(r3)
> -
> + addi r3,r3,VCPU_FPRS
> + bl .store_fp_state
> #ifdef CONFIG_ALTIVEC
> BEGIN_FTR_SECTION
> - reg =3D 0
> - .rept 32
> - li r6,reg*16+VCPU_VRS
> - stvx reg,r6,r3
> - reg =3D reg + 1
> - .endr
> - mfvscr vr0
> - li r6,VCPU_VSCR
> - stvx vr0,r6,r3
> + addi r3,r31,VCPU_VRS
> + bl .store_vr_state
> END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> #endif
> mfspr r6,SPRN_VRSAVE
> stw r6,VCPU_VRSAVE(r3)
> + mtlr r30
> mtmsrd r5
> isync
> blr
> @@ -1826,8 +1803,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> * Load up FP, VMX and VSX registers
> * r4 =3D vcpu pointer
> */
> - .globl kvmppc_load_fp
> kvmppc_load_fp:
> + mflr r30
> + mr r31,r4
here too. It's also worth noting in the header comment that r4 is =
preserved (unlike what you'd expect from the C ABI).
Alex
> mfmsr r9
> ori r8,r9,MSR_FP
> #ifdef CONFIG_ALTIVEC
> @@ -1842,40 +1820,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> #endif
> mtmsrd r8
> isync
> - lfd fr0,VCPU_FPSCR(r4)
> - MTFSF_L(fr0)
> -#ifdef CONFIG_VSX
> -BEGIN_FTR_SECTION
> - reg =3D 0
> - .rept 32
> - li r7,reg*16+VCPU_FPRS
> - LXVD2X(reg,R7,R4)
> - reg =3D reg + 1
> - .endr
> -FTR_SECTION_ELSE
> -#endif
> - reg =3D 0
> - .rept 32
> - lfd reg,reg*8+VCPU_FPRS(r4)
> - reg =3D reg + 1
> - .endr
> -#ifdef CONFIG_VSX
> -ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
> -#endif
> -
> + addi r3,r4,VCPU_FPRS
> + bl .load_fp_state
> #ifdef CONFIG_ALTIVEC
> BEGIN_FTR_SECTION
> - li r7,VCPU_VSCR
> - lvx vr0,r7,r4
> - mtvscr vr0
> - reg =3D 0
> - .rept 32
> - li r7,reg*16+VCPU_VRS
> - lvx reg,r7,r4
> - reg =3D reg + 1
> - .endr
> + addi r3,r31,VCPU_VRS
> + bl .load_vr_state
> END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> #endif
> lwz r7,VCPU_VRSAVE(r4)
> mtspr SPRN_VRSAVE,r7
> + mtlr r30
> + mr r4,r31
> blr
> --=20
> 1.8.4.rc3
>=20
^ permalink raw reply
* Re: [PATCH 5/6] KVM: PPC: Book3S: Load/save FP/VMX/VSX state directly to/from vcpu struct
From: Alexander Graf @ 2013-09-10 18:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <20130910102221.GF28145@iris.ozlabs.ibm.com>
On 10.09.2013, at 05:22, Paul Mackerras wrote:
> Now that we have the vcpu floating-point and vector state stored in
> the same type of struct as the main kernel uses, we can load that
> state directly from the vcpu struct instead of having extra copies
> to/from the thread_struct. Similarly, when the guest state needs to
> be saved, we can have it saved it directly to the vcpu struct by
> setting the current->thread.fp_save_area and =
current->thread.vr_save_area
> pointers. That also means that we don't need to back up and restore
> userspace's FP/vector state. This all makes the code simpler and
> faster.
>=20
> Note that it's not necessary to save or modify =
current->thread.fpexc_mode,
> since nothing in KVM uses or is affected by its value. Nor is it
> necessary to touch used_vr or used_vsr.
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/kvm/book3s_pr.c | 72 =
++++++++++----------------------------------
> arch/powerpc/kvm/booke.c | 16 ----------
> arch/powerpc/kvm/booke.h | 4 ++-
> 3 files changed, 19 insertions(+), 73 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/book3s_pr.c =
b/arch/powerpc/kvm/book3s_pr.c
> index 90be91c..5eae919 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -462,16 +462,16 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, =
ulong msr)
> * both the traditional FP registers and the added VSX
> * registers into thread.fp_state.fpr[].
> */
> - if (current->thread.regs->msr & MSR_FP)
> + if (t->regs->msr & MSR_FP)
> giveup_fpu(current);
If you make a second version of this call that also gets a state area as =
parameter, you don't need the pointer in the thread struct anymore, no? =
Or do you? Ah, you want to be able to grab the FPU for in-kernel FPU =
using code, so it needs to be seamless.
Fiar enough - pointer it is then :).
Alex
^ permalink raw reply
* Re: [PATCH 2/6] powerpc: Provide for giveup_fpu/altivec to save state in alternate location
From: Alexander Graf @ 2013-09-10 17:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <20130910102110.GC28145@iris.ozlabs.ibm.com>
On 10.09.2013, at 05:21, Paul Mackerras wrote:
> This provides a facility which is intended for use by KVM, where the
> contents of the FP/VSX and VMX (Altivec) registers can be saved away
> to somewhere other than the thread_struct when kernel code wants to
> use floating point or VMX instructions. This is done by providing a
> pointer in the thread_struct to indicate where the state should be
> saved to. The giveup_fpu() and giveup_altivec() functions test these
> pointers and save state to the indicated location if they are =
non-NULL.
> Note that the MSR_FP/VEC bits in task->thread.regs->msr are still used
> to indicate whether the CPU register state is live, even when an
> alternate save location is being used.
>=20
> This also provides load_fp_state() and load_vr_state() functions, =
which
> load up FP/VSX and VMX state from memory into the CPU registers, and
> corresponding store_fp_state() and store_vr_state() functions, which
> store FP/VSX and VMX state into memory from the CPU registers.
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/include/asm/processor.h | 7 +++++++
> arch/powerpc/kernel/asm-offsets.c | 2 ++
> arch/powerpc/kernel/fpu.S | 25 ++++++++++++++++++++++++-
> arch/powerpc/kernel/ppc_ksyms.c | 4 ++++
> arch/powerpc/kernel/process.c | 7 +++++++
> arch/powerpc/kernel/vector.S | 29 =
+++++++++++++++++++++++++++--
> 6 files changed, 71 insertions(+), 3 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/processor.h =
b/arch/powerpc/include/asm/processor.h
> index 92f709d..8bc9d66 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -212,6 +212,7 @@ struct thread_struct {
> #endif
> #endif
> struct thread_fp_state fp_state;
> + struct thread_fp_state *fp_save_area;
Why do you need these pointers? Couldn't you handle everything you need =
through preempt notifiers?
Alex
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: Put FP/VSX and VR state into structures
From: Alexander Graf @ 2013-09-10 17:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <20130910102041.GB28145@iris.ozlabs.ibm.com>
On 10.09.2013, at 05:20, Paul Mackerras wrote:
> This creates new 'thread_fp_state' and 'thread_vr_state' structures
> to store FP/VSX state (including FPSCR) and Altivec/VSX state
> (including VSCR), and uses them in the thread_struct. In the
> thread_fp_state, the FPRs and VSRs are represented as u64 rather
> than double, since we rarely perform floating-point computations
> on the values, and this will enable the structures to be used
> in KVM code as well. Similarly FPSCR is now a u64 rather than
> a structure of two 32-bit values.
>=20
> This takes the offsets out of the macros such as SAVE_32FPRS,
> REST_32FPRS, etc. This enables the same macros to be used for normal
> and transactional state, enabling us to delete the transactional
> versions of the macros. This also removes the unused do_load_up_fpu
> and do_load_up_altivec, which were in fact buggy since they didn't
> create large enough stack frames to account for the fact that
> load_up_fpu and load_up_altivec are not designed to be called from C
> and assume that their caller's stack frame is an interrupt frame.
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
I like the idea of this patch. However this really needs an ack from Ben =
(or get applied by him). I also found the patch pretty large and =
subtile, so there's a good chance I missed a register overwrite if there =
was any :).
> ---
> arch/powerpc/include/asm/ppc_asm.h | 95 =
+++-------------------------------
> arch/powerpc/include/asm/processor.h | 40 +++++++-------
> arch/powerpc/include/asm/sfp-machine.h | 2 +-
> arch/powerpc/kernel/align.c | 6 +--
> arch/powerpc/kernel/asm-offsets.c | 25 +++------
> arch/powerpc/kernel/fpu.S | 59 +++++----------------
> arch/powerpc/kernel/process.c | 8 ++-
> arch/powerpc/kernel/ptrace.c | 49 +++++++++---------
> arch/powerpc/kernel/ptrace32.c | 11 ++--
> arch/powerpc/kernel/signal_32.c | 72 +++++++++++++-------------
> arch/powerpc/kernel/signal_64.c | 29 ++++++-----
> arch/powerpc/kernel/tm.S | 41 ++++++++-------
> arch/powerpc/kernel/traps.c | 10 ++--
> arch/powerpc/kernel/vecemu.c | 6 +--
> arch/powerpc/kernel/vector.S | 50 ++++++------------
> arch/powerpc/kvm/book3s_pr.c | 36 ++++++-------
> arch/powerpc/kvm/booke.c | 19 ++++---
> 17 files changed, 200 insertions(+), 358 deletions(-)
>=20
>=20
[...]
> diff --git a/arch/powerpc/include/asm/sfp-machine.h =
b/arch/powerpc/include/asm/sfp-machine.h
> index 3a7a67a..d89beab 100644
> --- a/arch/powerpc/include/asm/sfp-machine.h
> +++ b/arch/powerpc/include/asm/sfp-machine.h
> @@ -125,7 +125,7 @@
> #define FP_EX_DIVZERO (1 << (31 - 5))
> #define FP_EX_INEXACT (1 << (31 - 6))
>=20
> -#define __FPU_FPSCR (current->thread.fpscr.val)
> +#define __FPU_FPSCR (current->thread.fp_state.fpscr)
>=20
> /* We only actually write to the destination register
> * if exceptions signalled (if any) will not trap.
> diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
> index a27ccd5..eaa16bc 100644
> --- a/arch/powerpc/kernel/align.c
> +++ b/arch/powerpc/kernel/align.c
> @@ -660,7 +660,7 @@ static int emulate_vsx(unsigned char __user *addr, =
unsigned int reg,
> if (reg < 32)
> ptr =3D (char *) ¤t->thread.TS_FPR(reg);
> else
> - ptr =3D (char *) ¤t->thread.vr[reg - 32];
> + ptr =3D (char *) ¤t->thread.vr_state.vr[reg - 32];
>=20
> lptr =3D (unsigned long *) ptr;
>=20
> @@ -897,7 +897,7 @@ int fix_alignment(struct pt_regs *regs)
> return -EFAULT;
> }
> } else if (flags & F) {
> - data.dd =3D current->thread.TS_FPR(reg);
> + data.ll =3D current->thread.TS_FPR(reg);
I don't understand this change. Could you please explain?
> if (flags & S) {
> /* Single-precision FP store requires =
conversion... */
> #ifdef CONFIG_PPC_FPU
> @@ -975,7 +975,7 @@ int fix_alignment(struct pt_regs *regs)
> if (unlikely(ret))
> return -EFAULT;
> } else if (flags & F)
> - current->thread.TS_FPR(reg) =3D data.dd;
> + current->thread.TS_FPR(reg) =3D data.ll;
> else
> regs->gpr[reg] =3D data.ll;
>=20
[...]
> diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
> index 7b60b98..d781ca5 100644
> --- a/arch/powerpc/kernel/tm.S
> +++ b/arch/powerpc/kernel/tm.S
> @@ -12,16 +12,15 @@
> #include <asm/reg.h>
>=20
> #ifdef CONFIG_VSX
> -/* See fpu.S, this is very similar but to save/restore checkpointed =
FPRs/VSRs */
> -#define __SAVE_32FPRS_VSRS_TRANSACT(n,c,base) \
> +/* See fpu.S, this is borrowed from there */
> +#define __SAVE_32FPRS_VSRS(n,c,base) \
Should this really be in tm.S with its new name?
Alex
^ permalink raw reply
* Re: [PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe
From: Vladimir Murzin @ 2013-09-10 17:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: cbe-oss-dev@lists.ozlabs.org, Linux Fbdev development list,
Geoff Levand, linuxppc-dev@lists.ozlabs.org, Tomi Valkeinen,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <CAMuHMdWHHsOm8qREeVVPBxcqJoa85xfgd-9jzqCnMs=Z9yVFCw@mail.gmail.com>
On Tue, Sep 10, 2013 at 06:56:33PM +0200, Geert Uytterhoeven wrote:
> On Tue, Sep 10, 2013 at 6:46 PM, Vladimir Murzin <murzin.v@gmail.com> wrote:
> > diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> > index dbfe2c1..b269abd 100644
> > --- a/drivers/video/ps3fb.c
> > +++ b/drivers/video/ps3fb.c
> > @@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
> > .fb_compat_ioctl = ps3fb_ioctl
> > };
> >
> > -static struct fb_fix_screeninfo ps3fb_fix __initdata = {
> > +static struct fb_fix_screeninfo ps3fb_fix = {
> > .id = DEVICE_NAME,
> > .type = FB_TYPE_PACKED_PIXELS,
> > .visual = FB_VISUAL_TRUECOLOR,
>
> Fixed before by Geoff, but never applied:
> http://marc.info/?l=linux-fbdev&m=136914132618389&w=3
Great! Hope some day it will ;)
Sorry for the noise
Vladimir
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe
From: Geert Uytterhoeven @ 2013-09-10 16:56 UTC (permalink / raw)
To: Vladimir Murzin
Cc: cbe-oss-dev@lists.ozlabs.org, Linux Fbdev development list,
Geoff Levand, linuxppc-dev@lists.ozlabs.org, Tomi Valkeinen,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <1378831590-2349-1-git-send-email-murzin.v@gmail.com>
On Tue, Sep 10, 2013 at 6:46 PM, Vladimir Murzin <murzin.v@gmail.com> wrote:
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index dbfe2c1..b269abd 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
> .fb_compat_ioctl = ps3fb_ioctl
> };
>
> -static struct fb_fix_screeninfo ps3fb_fix __initdata = {
> +static struct fb_fix_screeninfo ps3fb_fix = {
> .id = DEVICE_NAME,
> .type = FB_TYPE_PACKED_PIXELS,
> .visual = FB_VISUAL_TRUECOLOR,
Fixed before by Geoff, but never applied:
http://marc.info/?l=linux-fbdev&m=136914132618389&w=3
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe
From: Vladimir Murzin @ 2013-09-10 16:46 UTC (permalink / raw)
To: linux-fbdev, cbe-oss-dev, linuxppc-dev
Cc: geoff, Vladimir Murzin, tomi.valkeinen, plagnioj
While cross-building for PPC64 I've got
WARNING: drivers/video/built-in.o(.text+0x9f9ca): Section mismatch in
reference from the function .ps3fb_probe() to th e variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/video/built-in.o(.text+0x9f9d2): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/built-in.o(.text+0xe222a): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/built-in.o(.text+0xe2232): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: vmlinux.o(.text+0x561d4a): Section mismatch in reference from
the function .ps3fb_probe() to the variable .init.data:ps3fb_fix The
function .ps3fb_probe() references the variable __initdata ps3fb_fix.
This is often because .ps3fb_probe lacks a __initdata annotation or
the annotation of ps3fb_fix is wrong.
Mismatch was introduced with 48c68c4f "Drivers: video: remove __dev*
attributes."
Remove __init data annotation from ps3fb_fix.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
drivers/video/ps3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index dbfe2c1..b269abd 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
.fb_compat_ioctl = ps3fb_ioctl
};
-static struct fb_fix_screeninfo ps3fb_fix __initdata = {
+static struct fb_fix_screeninfo ps3fb_fix = {
.id = DEVICE_NAME,
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_TRUECOLOR,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] powerpc: fix section mismatch warning for prom_rtas_call
From: Vladimir Murzin @ 2013-09-10 16:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vladimir Murzin, paulus, anton, nfont
While cross-building for PPC64 I've got
WARNING: vmlinux.o(.text.unlikely+0x1ba): Section mismatch in
reference from the function .prom_rtas_call() to the variable
.init.data:dt_string_start The function .prom_rtas_call() references
the variable __initdata dt_string_start. This is often because
.prom_rtas_call lacks a __initdata annotation or the annotation of
dt_string_start is wrong.
WARNING: vmlinux.o(.meminit.text+0xeb0): Section mismatch in reference
from the function .free_area_init_core.isra.47() to the function
.init.text:.set_pageblock_order() The function __meminit
.free_area_init_core.isra.47() references a function __init
.set_pageblock_order(). If .set_pageblock_order is only used by
.free_area_init_core.isra.47 then annotate .set_pageblock_order with a
matching annotation.
Fix it by proper annotation of prom_rtas_call.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
arch/powerpc/kernel/prom_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 7b6391b..12e656f 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1297,7 +1297,8 @@ static void __init prom_query_opal(void)
prom_opal_align = 0x10000;
}
-static int prom_rtas_call(int token, int nargs, int nret, int *outputs, ...)
+static int __init prom_rtas_call(int token, int nargs, int nret,
+ int *outputs, ...)
{
struct rtas_args rtas_args;
va_list list;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] powerpc: export cpu_to_chip_id
From: Vladimir Murzin @ 2013-09-10 16:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: chenhui.zhao, Vladimir Murzin, paulus, srivatsa.bhat, tglx
While cross-building for PPC64 I've got
ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
mtip32xx refer to topology_physical_package_id, which stands for
cpu_to_chip-id.
Make cpu_to_chip-id (and topology_physical_package_id) available for
external users.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
arch/powerpc/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 442d8e2..1d9c1c2 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu)
of_node_put(np);
return of_get_ibm_chip_id(np);
}
+EXPORT_SYMBOL_GPL(cpu_to_chip_id);
/* Helper routines for cpu to core mapping */
int cpu_core_index_of_thread(int cpu)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc/p1010rdb:update phy node in dts
From: Kumar Gala @ 2013-09-10 15:59 UTC (permalink / raw)
To: Zhao Qiang; +Cc: linuxppc-dev, Shengzhou Liu
In-Reply-To: <1378792243-27962-1-git-send-email-B45475@freescale.com>
On Sep 10, 2013, at 12:50 AM, Zhao Qiang wrote:
> Update phy node according to new P1010RDB-PB board.
>=20
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> arch/powerpc/boot/dts/p1010rdb.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
What about the old boards?
- k
>=20
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi =
b/arch/powerpc/boot/dts/p1010rdb.dtsi
> index 7fc3402..8c675bf 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dtsi
> +++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
> @@ -199,7 +199,7 @@
>=20
> mdio@24000 {
> phy0: ethernet-phy@0 {
> - interrupts =3D <3 1 0 0>;
> + interrupts =3D <0 1 0 0>;
> reg =3D <0x1>;
> };
>=20
> @@ -209,7 +209,7 @@
> };
>=20
> phy2: ethernet-phy@2 {
> - interrupts =3D <2 1 0 0>;
> + interrupts =3D <1 1 0 0>;
> reg =3D <0x2>;
> };
>=20
> --=20
> 1.8.0
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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