* Re: Relocatable kernel for ppc44x
From: John Williams @ 2011-06-15 9:38 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev, monstr, Suzuki Poulose
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AD9E@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
On Wed, Jun 15, 2011 at 11:30 AM, David Laight <David.Laight@aculab.com>wrote:
>
> > The PPC440X currently uses 256M TLB entries to pin the
> > lowmem. When we go for a relocatable kernel we have to :
> >
> > 1) Restrict the kernel load address to be 256M aligned
> >
> > OR
> >
> > 2) Use 16M TLB(the next possible TLB page size supported)
> > entries till the first
> > 256M and then use the 256M TLB entries for the rest of lowmem.
>
> What is wrong with:
>
> 3) Use 256M TLB entries with the lowest one including
> addresses below the kernel base.
>
> Clearly the kernel shouldn't be accessing the addresses
> below its base address - but that is true of a lot of
> address space mapped into the kernel.
>
It gets mucky since we will then need need to assess how much of that 256M
mapping will be above the kernel base, determine if that is sufficient to
boot the kernel, if not then setup additional 16MB mappings and so on. It
might be cleaner to just use multiple 16MB mappings directly?
By the way we have some patches to support a non-zero (but fixed) boot
address for PPC440. They are against 2.6.31, it's pretty simple stuff
except also requires changes in the simpleboot wrapper. We will post them
shortly since they are relevant to this discussion.
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
[-- Attachment #2: Type: text/html, Size: 1945 bytes --]
^ permalink raw reply
* RE: Relocatable kernel for ppc44x
From: David Laight @ 2011-06-15 9:30 UTC (permalink / raw)
To: Suzuki Poulose, monstr; +Cc: linuxppc-dev, John Williams
In-Reply-To: <4DF84D92.2030803@in.ibm.com>
=20
> The PPC440X currently uses 256M TLB entries to pin the=20
> lowmem. When we go for a relocatable kernel we have to :
>=20
> 1) Restrict the kernel load address to be 256M aligned
>=20
> OR
>=20
> 2) Use 16M TLB(the next possible TLB page size supported)=20
> entries till the first
> 256M and then use the 256M TLB entries for the rest of lowmem.
What is wrong with:
3) Use 256M TLB entries with the lowest one including
addresses below the kernel base.
Clearly the kernel shouldn't be accessing the addresses
below its base address - but that is true of a lot of
address space mapped into the kernel.
David
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Ralf Baechle @ 2011-06-15 8:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <4DF8329C.7000904@zytor.com>
On Tue, Jun 14, 2011 at 09:18:36PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 03:34 PM, Ralf Baechle wrote:
> >
> > There is no point in offering to build something that couldn't possibly be
> > used. It just makes the kernel harder to configure and inflates the test
> > matrix for no good reason.
> >
>
> I see... that's why a bunch of devices that only exist on ARM and MIPS
> SoCs are offered on x86 platforms?
Well, if you notice one of those, yell. Or send patches. Most of those
have been fixed.
Ralf
^ permalink raw reply
* Re: [PATCH 06/15] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2011-06-15 9:21 UTC (permalink / raw)
To: Dan Malek; +Cc: Scott Wood, linuxppc-dev, Willy Tarreau
In-Reply-To: <792A171E-D1E1-4F35-8AC2-40C5A7519D78@digitaldans.com>
Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 20:11:18:
>
> Hi Joakim.
>
> On Jun 14, 2011, at 11:00 AM, Joakim Tjernlund wrote:
>
> > I don't have a mpc850, do you?
>
> I have to say I do :-)
>
> > Probably but that is another matter. You could continue with that
> > if you like but I am stopping here ATM.
>
> Oh, come on... I've been thinking about this for years, wouldn't
> you like to work on it? It will be fun :-)
OK, it was fun :) This is a quick impl. for kernel ITLBs. What do
you think?
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 0f9080c..88278b4 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -33,6 +33,7 @@
#include <asm/ppc_asm.h>
#include "ppc_defs.h"
+#undef CONFIG_PIN_TLB
/* Macro to make the code more readable. */
#ifdef CONFIG_8xx_CPU6
#define DO_8xx_CPU6(val, reg) \
@@ -357,17 +358,23 @@ InstructionTLBMiss:
/* If we are faulting a kernel address, we have to use the
* kernel page tables.
*/
-#ifdef CONFIG_MODULES
- /* Since we PIN the first 8MB text, we only get ITLB misses
- * for modules
- */
andi. r21, r20, 0x0800 /* Address >= 0x80000000 */
beq 3f
+#ifdef CONFIG_MODULES
lis r21, swapper_pg_dir@h
ori r21, r21, swapper_pg_dir@l
rlwimi r20, r21, 0, 2, 19
-3:
+ lwz r21, 0(r20) /* Get the level 1 entry */
+ tophys(r21,r21)
+ ori r21, r21, MI_PS8MEG | MI_SVALID /* Set 8M byte page */
+#else
+ li r21, MI_PS8MEG | MI_SVALID /* Set 8M byte page */
#endif
+ DO_8xx_CPU6(0x2b80, r3)
+ mtspr MI_TWC, r21 /* Set segment attributes */
+ li r20, MI_BOOTINIT
+ b 5f
+3:
lwz r21, 0(r20) /* Get the level 1 entry */
rlwinm. r20, r21,0,0,19 /* Extract page descriptor page address */
@@ -401,7 +408,7 @@ InstructionTLBMiss:
*/
2: li r21, 0x00f0
rlwimi r20, r21, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */
- DO_8xx_CPU6(0x2d80, r3)
+5: DO_8xx_CPU6(0x2d80, r3)
mtspr MI_RPN, r20 /* Update TLB entry */
mfspr r20, M_TW /* Restore registers */
@@ -942,13 +949,16 @@ start_here:
*/
initial_mmu:
tlbia /* Invalidate all TLB entries */
-
+#ifdef CONFIG_PIN_TLB
+//#if 1
/* Always pin the first 8 MB ITLB to prevent ITLB
misses while mucking around with SRR0/SRR1 in asm
*/
lis r8, MI_RSV4I@h
ori r8, r8, 0x1c00
-
+#else
+ li r8, 0
+#endif
mtspr MI_CTR, r8 /* Set instruction MMU control */
#ifdef CONFIG_PIN_TLB
^ permalink raw reply related
* [PATCH][v2] Add support for RTC device: pt7c4338 in rtc-ds1307.c
From: Priyanka Jain @ 2011-06-15 8:59 UTC (permalink / raw)
To: akpm, w.sang, cbouatmailru, a.zummo, benh, galak, grant.likely,
b04825, linuxppc-dev, rtc-linux, p_gortmaker, linuxppc-release
Cc: Priyanka Jain
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Its register set is same as that of rtc device: DS1307.
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
Change for v2:
Incorporting Andrew Morton's comments to shorten patch by using
hunk: { "pt7c4338", ds_1307 }
Changes :
This patch will supersede patch:
"RTC driver(Linux) for PT7C4338 chip"
Incorporting Wolfram Sang's comments to reuse ds1307 driver.
drivers/rtc/Kconfig | 6 +++---
drivers/rtc/rtc-ds1307.c | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b8f4e9e..c6045dd 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -126,13 +126,13 @@ comment "I2C RTC drivers"
if I2C
config RTC_DRV_DS1307
- tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
+ tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025, PT7C4338"
help
If you say yes here you get support for various compatible RTC
chips (often with battery backup) connected with I2C. This driver
should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
- EPSON RX-8025 and probably other chips. In some cases the RTC
- must already have been initialized (by manufacturing or a
+ EPSON RX-8025, PT7C4338 and probably other chips. In some cases
+ the RTC must already have been initialized (by manufacturing or a
bootloader).
The first seven registers on these chips hold an RTC, and other
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 4724ba3..e851394 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -4,6 +4,8 @@
* Copyright (C) 2005 James Chapman (ds1337 core)
* Copyright (C) 2006 David Brownell
* Copyright (C) 2009 Matthias Fuchs (rx8025 support)
+ * Copyright (C) 2011 Priyanka Jain (Priyanka.Jain@freescale.com)
+ * (pt7c4338 support)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -149,6 +151,7 @@ static const struct i2c_device_id ds1307_id[] = {
{ "ds1340", ds_1340 },
{ "ds3231", ds_3231 },
{ "m41t00", m41t00 },
+ { "pt7c4338", ds_1307 },
{ "rx8025", rx_8025 },
{ }
};
--
1.6.5.6
^ permalink raw reply related
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Lennox Wu @ 2011-06-15 8:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
linux-arch, Jesper Nilsson, Russell King, Yoshinori Sato,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Matt Turner, Fenghua Yu, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <201106142222.43553.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
2011/6/15 Arnd Bergmann <arnd@arndb.de>
>
> > config SCORE
> > - def_bool y
> > - select HAVE_GENERIC_HARDIRQS
> > - select GENERIC_IRQ_SHOW
> > + def_bool y
> > + select HAVE_GENERIC_HARDIRQS
> > + select HAVE_PC_PARPORT
> > + select GENERIC_IRQ_SHOW
> >
> > choice
> > prompt "System type"
>
> Certainly not, no PIO support
>
> Yes, there is no platform of the Score supports PIO.
Best,
Lennox
[-- Attachment #2: Type: text/html, Size: 818 bytes --]
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Russell King - ARM Linux @ 2011-06-15 7:39 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Yu, Fenghua, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Luck, Tony,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <4DF8359F.10809@zytor.com>
On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 03:08 PM, Luck, Tony wrote:
> > I took a look at the back of all my ia64 systems - none of them
> > have a parallel port. It seems unlikely that new systems will
> > start adding parallel ports :-)
> >
> > So even if I had a printer (or other device) that used a parallel
> > port, I have no way to test it.
>
> If it has PCI slots, it can have a parallel port.
Is that a clue about where a select statement should be?
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Russell King - ARM Linux @ 2011-06-15 7:47 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, Arnd Bergmann, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <4DF83577.6040903@zytor.com>
On Tue, Jun 14, 2011 at 09:30:47PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 02:33 PM, Arnd Bergmann wrote:
> >>
> >> Why on earth restrict it like that? It's just a device driver, like
> >> more or less any other device driver...
> >
> > I'd say any other classic ISA/PC driver, including floppy, gameport or
> > serial-8250. One problem with these is that we never fully worked out
> > the dependencies for these, which we probably should. CONFIG_ISA
> > generally means ISA add-on cards, but that might not be enabled for
> > platforms that have a pc-parport but no ISA slots.
> >
>
> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
> are ubiquitous across just about every platform.
>
> Floppy is special (in the short bus sense), since it is closely tied to
> ISA DMA. Conditionalizing this on ISA DMA makes total sense.
No it doesn't. It depends on the ISA DMA API, not that the machine has
ISA DMA.
I have a platform which has no ISA DMA but uses the floppy driver. Please
don't break it.
^ permalink raw reply
* Re: [PATCH 00/15] Backport 8xx TLB to 2.4
From: Joakim Tjernlund @ 2011-06-15 7:43 UTC (permalink / raw)
To: Willy Tarreau, Dan Malek; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20110614193106.GA15583@1wt.eu>
Willy Tarreau <w@1wt.eu> wrote on 2011/06/14 21:31:06:
>
> Hi Joakim,
>
> On Tue, Jun 14, 2011 at 03:54:45PM +0200, Joakim Tjernlund wrote:
> > This is a backport from 2.6 which I did to overcome 8xx CPU
> > bugs. 8xx does not update the DAR register when taking a TLB
> > error caused by dcbX and icbi insns which makes it very
> > tricky to use these insns. Also the dcbst wrongly sets the
> > the store bit when faulting into DTLB error.
> > A few more bugs very found during development.
> >
> > I know 2.4 is in strict maintenance mode and 8xx is obsolete
> > but as it is still in use I wanted 8xx to age with grace.
>
> OK, I'm not opposed to merge these patches and I really welcome your
> work and want to thank you for having done it. However, I have
> absolutely *zero* skills on ppc, so I want to ensure that someone
> (possibly you) will be able to back me up in case of reported
> regressions once these patches are merged. Since you say that the
> code works on your board, I'm not much worried but at least Dan's
> comment about the risk of performance regression has to be considered.
> If we all agree that it's a tradeoff between performance and stability
> or security, then that's a different matter of course !
Yes, I will still be here :) If there are any regressions I will help out. If
we can't fix it, we can easily back these changes out. I guess I and
Dan will come to some agreement soon and I will post additional, if needed,
patches on top of what I already sent once Dan is happy.
Jocke
^ permalink raw reply
* Re: [PATCH 06/15] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2011-06-15 7:36 UTC (permalink / raw)
To: Dan Malek; +Cc: Scott Wood, linuxppc-dev, Willy Tarreau
In-Reply-To: <OF75A64D65.5ABAA9A9-ONC12578AF.0062124A-C12578AF.0062E416@LocalDomain>
Joakim Tjernlund/Transmode wrote on 2011/06/14 20:00:09:
> From: Joakim Tjernlund/Transmode
>
> Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 18:06:45:
> >
> >
> > Hi Joakim.
> >
> > On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote:
> >
> > > Various kernel asm modifies SRR0/SRR1 just before executing
> > > a rfi. .....
> >
> > I'm going to argue we can easily visually inspect for this
> > since the code is static with just a couple of RFIs in these
> > exception handlers.
>
> Yes, but then you also miss out on 8xx: Optimize ITLBMiss handler.
>
> >
> > Some 8xx processors have few TLB entries, and always taking
> > one for the kernel, especially if it isn't needed, could have a
> > detrimental effect on the application performance. Even the
> > "big" 8xx processors don't have that many entries. Some
> > benchmarks run on an MPC850 would likely show this.
>
> I don't have a mpc850, do you?
>
> >
> > Anyone making modifications to this level of software should
> > know of this problem, or make it known in a comment. If you
> > are making changes, just compile the code and manually
> > check it with the couple of configuration options that affect
> > the placement of the instructions.
>
> Very fragile but then again, not much are expected to change
> in this area for 8xx.
So I checked and SRR0/SRR1 are fine w.r.t to head_8xx.S, it does
not even come close. There are SRR0/SRR1 mods in entry.S too
which works fine ATM. We don't have the same control of
that file though.
Could you check what impact pinning ITLB on 850 has?
Jocke
^ permalink raw reply
* Re: Relocatable kernel for ppc44x
From: Suzuki Poulose @ 2011-06-15 6:13 UTC (permalink / raw)
To: monstr; +Cc: linuxppc-dev, John Williams
In-Reply-To: <4DF74E5D.9020908@monstr.eu>
On 06/14/11 17:34, Michal Simek wrote:
> Hi,
>
> have someone tried to support RELOCATABLE kernel on ppc44x?
As Josh, mentioned, I will be working on this. In fact I was trying a couple of
patches towards this on PPC440x. But, I am stuck in debugging the hang that I am
experiencing with the changes. I am setting up a RISCWatch processor probe to
debug the same.
Here is some information that I wanted to share :
The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go for a
relocatable kernel we have to :
1) Restrict the kernel load address to be 256M aligned
OR
2) Use 16M TLB(the next possible TLB page size supported) entries till the first
256M and then use the 256M TLB entries for the rest of lowmem.
Option 1 is not feasible.
Towards this, I have tried a patch which uses 16M TLB entries to map the entire
lowmem on an ebony board. But that doesn't seem to work. I am setting up the JTAG
to debug the state.
I have attached the patch below for your reference. Any suggestions/comments would
be really helpful.
Thanks
Suzuki
==============================
Use 16M TLB pages to pin the lowmem on PPC440x.
---
arch/powerpc/include/asm/mmu-44x.h | 9 +++++++++
arch/powerpc/kernel/head_44x.S | 2 +-
arch/powerpc/mm/44x_mmu.c | 2 +-
3 files changed, 11 insertions(+), 2 deletions(-)
Index: linux-2.6.38.1/arch/powerpc/include/asm/mmu-44x.h
===================================================================
--- linux-2.6.38.1.orig/arch/powerpc/include/asm/mmu-44x.h
+++ linux-2.6.38.1/arch/powerpc/include/asm/mmu-44x.h
@@ -121,7 +121,12 @@ typedef struct {
#endif
/* Size of the TLBs used for pinning in lowmem */
+#define PPC_PIN_SIZE (1 << 24) /* 16M */
+#define PPC44x_TLB_PIN_SIZE PPC44x_TLB_16M
+#if 0
#define PPC_PIN_SIZE (1 << 28) /* 256M */
+#define PPC44x_TLB_PIN_SIZE PPC44x_TLB_256M
+#endif
#if (PAGE_SHIFT == 12)
#define PPC44x_TLBE_SIZE PPC44x_TLB_4K
@@ -142,7 +147,11 @@ typedef struct {
#error "Unsupported PAGE_SIZE"
#endif
+#if 0
#define mmu_linear_psize MMU_PAGE_256M
+#else
+#define mmu_linear_psize MMU_PAGE_16M
+#endif
#define PPC44x_PGD_OFF_SHIFT (32 - PGDIR_SHIFT + PGD_T_LOG2)
#define PPC44x_PGD_OFF_MASK_BIT (PGDIR_SHIFT - PGD_T_LOG2)
Index: linux-2.6.38.1/arch/powerpc/kernel/head_44x.S
===================================================================
--- linux-2.6.38.1.orig/arch/powerpc/kernel/head_44x.S
+++ linux-2.6.38.1/arch/powerpc/kernel/head_44x.S
@@ -805,7 +805,7 @@ skpinv: addi r4,r4,1 /* Increment */
/* pageid fields */
clrrwi r3,r3,10 /* Mask off the effective page number */
- ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_256M
+ ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_PIN_SIZE
/* xlat fields */
clrrwi r4,r4,10 /* Mask off the real page number */
Index: linux-2.6.38.1/arch/powerpc/mm/44x_mmu.c
===================================================================
--- linux-2.6.38.1.orig/arch/powerpc/mm/44x_mmu.c
+++ linux-2.6.38.1/arch/powerpc/mm/44x_mmu.c
@@ -84,7 +84,7 @@ static void __init ppc44x_pin_tlb(unsign
: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
#endif
"r" (phys),
- "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
+ "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_PIN_SIZE),
"r" (entry),
"i" (PPC44x_TLB_PAGEID),
"i" (PPC44x_TLB_XLAT),
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 5:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Russell King, Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20110615044016.GC10553@ericsson.com>
On 06/14/2011 09:40 PM, Guenter Roeck wrote:
> On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote:
>> On 06/14/2011 03:34 PM, Ralf Baechle wrote:
>>>
>>> There is no point in offering to build something that couldn't possibly be
>>> used. It just makes the kernel harder to configure and inflates the test
>>> matrix for no good reason.
>>>
>>
>> I see... that's why a bunch of devices that only exist on ARM and MIPS
>> SoCs are offered on x86 platforms?
>>
> http://en.wikipedia.org/wiki/Two_wrongs_make_a_right
>
Except in this case it's not wrong. It was done that way because it was
discovered a long time ago that restricting drivers that were not
*inherently* limited to specific platform just resulted in more bitrot
and nasty surprises for the users who *did* need specific things after
all, even though the maintainers had not thought so.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Guenter Roeck @ 2011-06-15 4:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Russell King, Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <4DF8329C.7000904@zytor.com>
On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote:
> On 06/14/2011 03:34 PM, Ralf Baechle wrote:
> >
> > There is no point in offering to build something that couldn't possibly be
> > used. It just makes the kernel harder to configure and inflates the test
> > matrix for no good reason.
> >
>
> I see... that's why a bunch of devices that only exist on ARM and MIPS
> SoCs are offered on x86 platforms?
>
http://en.wikipedia.org/wiki/Two_wrongs_make_a_right
Guenter
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 4:31 UTC (permalink / raw)
To: Luck, Tony
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Russell King, Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Yu, Fenghua, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, linux-parisc@vger.kernel.org,
linux-cris-kernel@axis.com, linux-kernel@vger.kernel.org,
Ralf Baechle, Kyle McMartin, Paul Mundt,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <987664A83D2D224EAE907B061CE93D5301E7281306@orsmsx505.amr.corp.intel.com>
On 06/14/2011 03:08 PM, Luck, Tony wrote:
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 38280ef..849805a 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -23,6 +23,7 @@ config IA64
> select HAVE_ARCH_TRACEHOOK
> select HAVE_DMA_API_DEBUG
> select HAVE_GENERIC_HARDIRQS
> + select HAVE_PC_PARPORT
> select GENERIC_IRQ_PROBE
> select GENERIC_PENDING_IRQ if SMP
> select IRQ_PER_CPU
>
> I took a look at the back of all my ia64 systems - none of them
> have a parallel port. It seems unlikely that new systems will
> start adding parallel ports :-)
>
> So even if I had a printer (or other device) that used a parallel
> port, I have no way to test it.
>
If it has PCI slots, it can have a parallel port.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 4:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <201106142333.16203.arnd@arndb.de>
On 06/14/2011 02:33 PM, Arnd Bergmann wrote:
>>
>> Why on earth restrict it like that? It's just a device driver, like
>> more or less any other device driver...
>
> I'd say any other classic ISA/PC driver, including floppy, gameport or
> serial-8250. One problem with these is that we never fully worked out
> the dependencies for these, which we probably should. CONFIG_ISA
> generally means ISA add-on cards, but that might not be enabled for
> platforms that have a pc-parport but no ISA slots.
>
OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
are ubiquitous across just about every platform.
Floppy is special (in the short bus sense), since it is closely tied to
ISA DMA. Conditionalizing this on ISA DMA makes total sense.
Parallel port is an intermediate case... Centronics parallel ports
predate the PC ecosystem by quite a bit, and the particular arrangement
of ports became popular with the PC and spread to other platforms, but
the particular variant of it known as ECP (as opposed to EPP) is ISA DMA
specific.
> On the other hand, you have embedded platforms that currently build support
> for parport-pc but define the inb/outb macros to plain pointer dereferences
> (otherwise you can't build the 8250 driver). Loading parport-pc on those
> machines typically results in derefencing user memory in the best case.
>
> What I'd love to see is a configuration option for "arch has working
> PC-style inb/outb instructions", so we can build a kernel without them but
> still get MMIO based drivers for PCI-less platforms.
Now, isn't that was iowrite/ioread was designed for?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 4:18 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <20110614223404.GA30057@linux-mips.org>
On 06/14/2011 03:34 PM, Ralf Baechle wrote:
>
> There is no point in offering to build something that couldn't possibly be
> used. It just makes the kernel harder to configure and inflates the test
> matrix for no good reason.
>
I see... that's why a bunch of devices that only exist on ARM and MIPS
SoCs are offered on x86 platforms?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Benjamin Herrenschmidt @ 2011-06-15 2:33 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: McClintock Matthew-B29882, Wood Scott-B07421, Gala Kumar-B11780,
paulus@samba.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4DF814A3.7070209@freescale.com>
On Wed, 2011-06-15 at 02:10 +0000, Tabi Timur-B04825 wrote:
> Benjamin Herrenschmidt wrote:
> > We might want to generically have a CPU feature bit indicating we are
> > running in guest vs. HV mode. I know Paulus is planning to introduce one
> > so you may want to sync with him.
>
> Are you talking about CPU_FTR_HVMODE_206?
Well, not exactly. Paul wants to break that up since we're adding some
primitive support for 201 HV mode too (for 970's). Last we discussed,
the plan was to go for a generic HV mode bit and a separate bit for the
version.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Tabi Timur-B04825 @ 2011-06-15 2:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Tabi Timur-B04825, linuxppc-dev@ozlabs.org,
paulus@samba.org, McClintock Matthew-B29882, Gala Kumar-B11780
In-Reply-To: <1308103091.2635.13.camel@pasglop>
Benjamin Herrenschmidt wrote:
> We might want to generically have a CPU feature bit indicating we are
> running in guest vs. HV mode. I know Paulus is planning to introduce one
> so you may want to sync with him.
Are you talking about CPU_FTR_HVMODE_206?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Benjamin Herrenschmidt @ 2011-06-15 1:58 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, kumar.gala, Timur Tabi, linuxppc-dev
In-Reply-To: <20110614182517.776d7e77@schlenkerla.am.freescale.net>
On Tue, 2011-06-14 at 18:25 -0500, Scott Wood wrote:
> On Tue, 14 Jun 2011 18:15:26 -0500
> Timur Tabi <timur@freescale.com> wrote:
>
> > Scott Wood wrote:
> > > FWIW, it's not supported under KVM either -- though we don't support an SMP
> > > guest under KVM yet, and KVM silently ignores it rather than logs errors as
> > > the FSL HV does.
> >
> > Does KVM set the root compatible to "fsl,P4080DS-hv"?
>
> No, Qemu/KVM like to pretend they're fully emulating concrete hardware,
> even though there's stuff missing.
>
> The only upstream e500 KVM platform is currently mpc8544ds.
>
> For now, there's no SMP KVM guest support. Maybe kexec can be fixed to not
> hard-reset the core by the time that changes. :-)
We might want to generically have a CPU feature bit indicating we are
running in guest vs. HV mode. I know Paulus is planning to introduce one
so you may want to sync with him.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Guan Xuetao @ 2011-06-15 1:24 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <20110614190850.GA13526@linux-mips.org>
On Tue, 2011-06-14 at 20:08 +0100, Ralf Baechle wrote:
> The PC parallel port Kconfig as acquired one of those messy terms to
> describe it's architecture dependencies:
>
> depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
>
> This isn't just ugly - it also almost certainly describes the dependencies
> too coarse grainedly. This is an attempt at cleaing the mess up.
>
> I tried to faithfully aproximate the old behaviour but the existing
> behaviour seems inacurate if not wrong for some architectures or platforms.
> To improve on this I rely on comments from other arch and platforms
> maintainers. Any system that can take PCI multi-IO card or has a PC-style
> parallel port on the mainboard should probably should now do a
> select HAVE_PC_PARPORT. And some arch Kconfig files should further
> restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> need it.
>
> Thanks,
>
> Ralf
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index e57dcce..3832e7e 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -8,6 +8,7 @@ config UNICORE32
> select HAVE_KERNEL_BZIP2
> select HAVE_KERNEL_LZO
> select HAVE_KERNEL_LZMA
> + select HAVE_PC_PARPORT
> select GENERIC_FIND_FIRST_BIT
> select GENERIC_IRQ_PROBE
> select GENERIC_IRQ_SHOW
In UniCore32, only some debug-boards need to support parport.
So I'd like to add HAVE_PC_PARPORT and related configs to certian
*_defconfig, but not in Kconfig.
Thanks Ralf.
Guan Xuetao
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Scott Wood @ 2011-06-14 23:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <4DF7EB8E.8020308@freescale.com>
On Tue, 14 Jun 2011 18:15:26 -0500
Timur Tabi <timur@freescale.com> wrote:
> Scott Wood wrote:
> > FWIW, it's not supported under KVM either -- though we don't support an SMP
> > guest under KVM yet, and KVM silently ignores it rather than logs errors as
> > the FSL HV does.
>
> Does KVM set the root compatible to "fsl,P4080DS-hv"?
No, Qemu/KVM like to pretend they're fully emulating concrete hardware,
even though there's stuff missing.
The only upstream e500 KVM platform is currently mpc8544ds.
For now, there's no SMP KVM guest support. Maybe kexec can be fixed to not
hard-reset the core by the time that changes. :-)
-Scott
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Ralf Baechle @ 2011-06-14 22:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tue, Jun 14, 2011 at 01:25:46PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
Some of the older MIPS systems are based on PC chipsets from Intel, OPTi
or others. On those you can expect the parport_pc driver to actually work.
The ISA/PCI implementations are often between lackluster and pure brokeness
such as with non-functioning I/O port address space. So I don't want to
run such drivers on such a platforms, things might turn ugly.
Embedded systems often have PCI but no PCI slots or there may even be an
apropriate SuperIO chip in the the system but nothing wired to the parallel
port bits.
And there are systems such as DECstations which have nothing that even
at a parsec's distance has a similarity to (E)ISA or PCI - but still
PARPORT_PC is offered along with 40 other options that depend on it.
There is no point in offering to build something that couldn't possibly be
used. It just makes the kernel harder to configure and inflates the test
matrix for no good reason.
Ralf
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Timur Tabi @ 2011-06-14 23:15 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <20110614181406.294cdf5f@schlenkerla.am.freescale.net>
Scott Wood wrote:
> FWIW, it's not supported under KVM either -- though we don't support an SMP
> guest under KVM yet, and KVM silently ignores it rather than logs errors as
> the FSL HV does.
Does KVM set the root compatible to "fsl,P4080DS-hv"?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Scott Wood @ 2011-06-14 23:14 UTC (permalink / raw)
To: Timur Tabi; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <1308092673-13045-1-git-send-email-timur@freescale.com>
On Tue, 14 Jun 2011 18:04:33 -0500
Timur Tabi <timur@freescale.com> wrote:
> The Freescale hypervisor does not allow guests to write to the timebase
> registers (virtualizing the timebase register was deemed too complicated),
> so don't try to synchronize the timebase registers when we're running
> under the hypervisor.
>
> This typically happens when kexec support is enabled.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
FWIW, it's not supported under KVM either -- though we don't support an SMP
guest under KVM yet, and KVM silently ignores it rather than logs errors as
the FSL HV does.
-Scott
^ permalink raw reply
* [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Timur Tabi @ 2011-06-14 23:04 UTC (permalink / raw)
To: kumar.gala, scottwood, B29882, linuxppc-dev
The Freescale hypervisor does not allow guests to write to the timebase
registers (virtualizing the timebase register was deemed too complicated),
so don't try to synchronize the timebase registers when we're running
under the hypervisor.
This typically happens when kexec support is enabled.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p3041_ds.c | 11 +++++++++++
arch/powerpc/platforms/85xx/p4080_ds.c | 11 +++++++++++
arch/powerpc/platforms/85xx/p5020_ds.c | 11 +++++++++++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p3041_ds.c b/arch/powerpc/platforms/85xx/p3041_ds.c
index c0242bc..8b651dfe 100644
--- a/arch/powerpc/platforms/85xx/p3041_ds.c
+++ b/arch/powerpc/platforms/85xx/p3041_ds.c
@@ -40,6 +40,9 @@
static int __init p3041_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P3041DS"))
return 1;
@@ -51,6 +54,14 @@ static int __init p3041_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
diff --git a/arch/powerpc/platforms/85xx/p4080_ds.c b/arch/powerpc/platforms/85xx/p4080_ds.c
index 32ea5eb..ae859ab 100644
--- a/arch/powerpc/platforms/85xx/p4080_ds.c
+++ b/arch/powerpc/platforms/85xx/p4080_ds.c
@@ -39,6 +39,9 @@
static int __init p4080_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P4080DS"))
return 1;
@@ -50,6 +53,14 @@ static int __init p4080_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
diff --git a/arch/powerpc/platforms/85xx/p5020_ds.c b/arch/powerpc/platforms/85xx/p5020_ds.c
index 2ea9ccc..d951618 100644
--- a/arch/powerpc/platforms/85xx/p5020_ds.c
+++ b/arch/powerpc/platforms/85xx/p5020_ds.c
@@ -40,6 +40,9 @@
static int __init p5020_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P5020DS"))
return 1;
@@ -51,6 +54,14 @@ static int __init p5020_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
--
1.7.3.4
^ permalink raw reply related
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