LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] powerpc: enable access to HT Host-Bridge on Maple
From: Dmitry Eremin-Solenikov @ 2011-07-04 12:46 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <288B47E0-3869-486D-B753-62EFA1EEF66D@kernel.crashing.org>

Hello,

On 03.07.2011 01:50, Segher Boessenkool wrote:
>>>> +static int u3_ht_root_write_config(struct pci_controller *hose, u8
>>>> offset,
>>>> + int len, u32 val)
>>>> +{
>>>> + volatile void __iomem *addr;
>>>> +
>>>> + addr = hose->cfg_addr + ((offset & ~3) << 2) + (4 - len - (offset
>>>> & 3));
>>>> +
>>>> + if (offset >= PCI_BASE_ADDRESS_0 && offset < PCI_CAPABILITY_LIST)
>>>> + return PCIBIOS_SUCCESSFUL;
>>>
>>> This is a workaround for something; at the very least it needs a
>>> comment,
>>> but probably it shouldn't be here at all.
>>
>> I'll add a comment. Basically these registers are unimplemented on u3/u4
>> bridges and at least some kinds of access to them cause system freeze.
>> I'll try to check what triggers what this night.
>
> I don't think the hardware freezes, but probably Linux isn't happy when it
> tries to write to the non-existent BARs. Or something like that.

I've run several experiments. At least writing to the ROM_ADDRESS (0x30) 
causes some kind of strange reboot (I see 'Error: Magic number in 
message area NVRAM is not valid.') errors on the service console and 
Linux consoles are silent. Writing to other BARs seem to cause no direct 
effect (reg remains =0), but causes very strange behaviour during boot. 
All PCI access cycles seem to return 0, strange DRAM ECC error pops up, 
etc. I'd prefer to leave these register writes disabled, even if it's 
the problem of some hardware revision (?).


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
From: K.Prasad @ 2011-07-04 13:27 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Ingo Molnar, Paul Mundt, linuxppc-dev, LKML, Peter Zijlstra
In-Reply-To: <1306273947-8410-3-git-send-email-fweisbec@gmail.com>

On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> Migrate conditional hw_breakpoint code compilation under
> the new config to prepare for letting the user chose whether
> or not to build this feature
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Prasad <prasad@linux.vnet.ibm.com>
> Cc: Paul Mundt <lethal@linux-sh.org>
> ---
>  arch/arm/include/asm/hw_breakpoint.h     |    4 ++--
>  arch/arm/include/asm/processor.h         |    2 +-
>  arch/arm/kernel/Makefile                 |    2 +-
>  arch/arm/kernel/entry-header.S           |    2 +-
>  arch/arm/kernel/ptrace.c                 |    4 ++--
>  arch/powerpc/include/asm/cputable.h      |    4 ++--
>  arch/powerpc/include/asm/hw_breakpoint.h |    6 +++---
>  arch/powerpc/include/asm/processor.h     |    4 ++--
>  arch/powerpc/kernel/Makefile             |    2 +-
>  arch/powerpc/kernel/process.c            |   18 +++++++++---------
>  arch/powerpc/kernel/ptrace.c             |   13 +++++++------
>  arch/powerpc/lib/Makefile                |    2 +-
>  arch/sh/kernel/Makefile                  |    2 +-
>  arch/sh/kernel/cpu/sh4a/Makefile         |    2 +-
>  include/linux/hw_breakpoint.h            |    6 +++---
>  include/linux/perf_event.h               |    4 ++--
>  include/linux/ptrace.h                   |    6 +++---
>  include/linux/sched.h                    |    2 +-
>  kernel/events/Makefile                   |    2 +-
>  kernel/events/core.c                     |    4 ++--
>  kernel/ptrace.c                          |    4 ++--
>  samples/Kconfig                          |    2 +-
>  22 files changed, 49 insertions(+), 48 deletions(-)
> 

Making the hardware breakpoint patches modular has always been a goal.
I've looked at the PowerPC parts of the code and they look harmless.

Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>

Thanks,
K.Prasad

^ permalink raw reply

* Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
From: Frederic Weisbecker @ 2011-07-04 13:29 UTC (permalink / raw)
  To: K.Prasad; +Cc: Ingo Molnar, Paul Mundt, linuxppc-dev, LKML, Peter Zijlstra
In-Reply-To: <20110704132746.GA2963@in.ibm.com>

On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote:
> On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> > Migrate conditional hw_breakpoint code compilation under
> > the new config to prepare for letting the user chose whether
> > or not to build this feature
> > 
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Prasad <prasad@linux.vnet.ibm.com>
> > Cc: Paul Mundt <lethal@linux-sh.org>
> > ---
> >  arch/arm/include/asm/hw_breakpoint.h     |    4 ++--
> >  arch/arm/include/asm/processor.h         |    2 +-
> >  arch/arm/kernel/Makefile                 |    2 +-
> >  arch/arm/kernel/entry-header.S           |    2 +-
> >  arch/arm/kernel/ptrace.c                 |    4 ++--
> >  arch/powerpc/include/asm/cputable.h      |    4 ++--
> >  arch/powerpc/include/asm/hw_breakpoint.h |    6 +++---
> >  arch/powerpc/include/asm/processor.h     |    4 ++--
> >  arch/powerpc/kernel/Makefile             |    2 +-
> >  arch/powerpc/kernel/process.c            |   18 +++++++++---------
> >  arch/powerpc/kernel/ptrace.c             |   13 +++++++------
> >  arch/powerpc/lib/Makefile                |    2 +-
> >  arch/sh/kernel/Makefile                  |    2 +-
> >  arch/sh/kernel/cpu/sh4a/Makefile         |    2 +-
> >  include/linux/hw_breakpoint.h            |    6 +++---
> >  include/linux/perf_event.h               |    4 ++--
> >  include/linux/ptrace.h                   |    6 +++---
> >  include/linux/sched.h                    |    2 +-
> >  kernel/events/Makefile                   |    2 +-
> >  kernel/events/core.c                     |    4 ++--
> >  kernel/ptrace.c                          |    4 ++--
> >  samples/Kconfig                          |    2 +-
> >  22 files changed, 49 insertions(+), 48 deletions(-)
> > 
> 
> Making the hardware breakpoint patches modular has always been a goal.
> I've looked at the PowerPC parts of the code and they look harmless.
> 
> Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>

Great!

I'll push that soon, thanks guys for your acks!

^ permalink raw reply

* Re: [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events
From: K.Prasad @ 2011-07-04 13:32 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Peter Zijlstra, Will Deacon, LKML, Paul Mundt, Ingo Molnar,
	linuxppc-dev
In-Reply-To: <1306273947-8410-5-git-send-email-fweisbec@gmail.com>

On Tue, May 24, 2011 at 11:52:25PM +0200, Frederic Weisbecker wrote:
> The breakpoint support ability in an arch is not related
> to the fact perf events is built or not. HAVE_HW_BREAKPOINT
> only shows an ability so this dependency makes no sense
> anymore. Archs that select HAVE_HW_BREAKPOINT already
> ensure that perf event is built.
> 
> Remove that dependency.
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Prasad <prasad@linux.vnet.ibm.com>
> Cc: Paul Mundt <lethal@linux-sh.org>
> ---
>  arch/Kconfig |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index f78c2be..ce4be89 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -149,7 +149,6 @@ config HAVE_DEFAULT_NO_SPIN_MUTEXES
> 
>  config HAVE_HW_BREAKPOINT
>  	bool
> -	depends on PERF_EVENTS
> 
>  config HAVE_MIXED_BREAKPOINTS_REGS
>  	bool
> -- 

Just a thought you might want to consider...

The need to keep the ability (HAVE_HW_BREAKPOINT) and the user-choice to
enable hardware breakpoints (through HW_BREAKPOINT) in separate config
options isn't very clear to me (and is a bit confusing with very similar
names).

Why not make HAVE_HW_BREAKPOINT selectable by the user (which in turn
would turn on PERF_EVENTS) for a given architecture?

Thanks,
K.Prasad

^ permalink raw reply

* Re: [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events
From: Frederic Weisbecker @ 2011-07-04 13:37 UTC (permalink / raw)
  To: K.Prasad
  Cc: Peter Zijlstra, Will Deacon, LKML, Paul Mundt, Ingo Molnar,
	linuxppc-dev
In-Reply-To: <20110704133223.GB2963@in.ibm.com>

On Mon, Jul 04, 2011 at 07:02:23PM +0530, K.Prasad wrote:
> On Tue, May 24, 2011 at 11:52:25PM +0200, Frederic Weisbecker wrote:
> > The breakpoint support ability in an arch is not related
> > to the fact perf events is built or not. HAVE_HW_BREAKPOINT
> > only shows an ability so this dependency makes no sense
> > anymore. Archs that select HAVE_HW_BREAKPOINT already
> > ensure that perf event is built.
> > 
> > Remove that dependency.
> > 
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Prasad <prasad@linux.vnet.ibm.com>
> > Cc: Paul Mundt <lethal@linux-sh.org>
> > ---
> >  arch/Kconfig |    1 -
> >  1 files changed, 0 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index f78c2be..ce4be89 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -149,7 +149,6 @@ config HAVE_DEFAULT_NO_SPIN_MUTEXES
> > 
> >  config HAVE_HW_BREAKPOINT
> >  	bool
> > -	depends on PERF_EVENTS
> > 
> >  config HAVE_MIXED_BREAKPOINTS_REGS
> >  	bool
> > -- 
> 
> Just a thought you might want to consider...
> 
> The need to keep the ability (HAVE_HW_BREAKPOINT) and the user-choice to
> enable hardware breakpoints (through HW_BREAKPOINT) in separate config
> options isn't very clear to me (and is a bit confusing with very similar
> names).
> 
> Why not make HAVE_HW_BREAKPOINT selectable by the user (which in turn
> would turn on PERF_EVENTS) for a given architecture?

But then how kconfig knows if the allows that? You need to know if the
arch has the ability to support breakpoints.

This is a commin pattern in Linux Kconfig. Things are often seperated between
ability (some constant value provided by the arch) and the user choice that
depends on that ability.
The advantage of doing this is that you can centralize the generic dependencies,
help menu, etc... into a single place.
 
> Thanks,
> K.Prasad
> 

^ permalink raw reply

* Re: hvc_console change results in corrupt oops output
From: Benjamin Herrenschmidt @ 2011-07-04 13:56 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: borntraeger, brueckner, linuxppc-dev
In-Reply-To: <20110704205738.742e56d0@kryten>

On Mon, 2011-07-04 at 20:57 +1000, Anton Blanchard wrote:

 .../...

> The hypervisor gives us a busy return, so we could retry a number of
> times instead of dropping it on the floor. We'd need to do it in the
> hvc_console driver - the tty drivers share the same backend
> functions so we can't hide it in the pseries put_chars function.

For kernel console, I don't see why not wait forever ... If the
underlying backend really lost the connection it can always return a
negative error no ?

Or we could have "well defined" return codes for "wait forever" vs.
"drop this" ... maybe return -EAGAIN.

Cheers,
Ben.

^ permalink raw reply

* Re: hvc_console change results in corrupt oops output
From: Hendrik Brueckner @ 2011-07-04 14:24 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: borntraeger, brueckner, linuxppc-dev, Anton Blanchard
In-Reply-To: <1309787787.14501.268.camel@pasglop>

On Mon, Jul 04, 2011 at 11:56:27PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-07-04 at 20:57 +1000, Anton Blanchard wrote:
> 
>  .../...
> 
> > The hypervisor gives us a busy return, so we could retry a number of
> > times instead of dropping it on the floor. We'd need to do it in the
> > hvc_console driver - the tty drivers share the same backend
> > functions so we can't hide it in the pseries put_chars function.
> 
> For kernel console, I don't see why not wait forever ... If the
> underlying backend really lost the connection it can always return a
> negative error no ?
> 
> Or we could have "well defined" return codes for "wait forever" vs.
> "drop this" ... maybe return -EAGAIN.

I will check this again for my hvc_iucv back-end.  Meanwhile a found
an old thread discussing the same issue.  It covers some differences
between console and ttys which actually does not matter for hvc-backend
because of the shared put_chars() routine.

You can read the thread on lkml.org: http://lkml.org/lkml/2009/10/15/149


Kind regards,
  Hendrik

^ permalink raw reply

* Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
From: K.Prasad @ 2011-07-04 17:44 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Ingo Molnar, Paul Mundt, linuxppc-dev, LKML, Peter Zijlstra
In-Reply-To: <20110704132912.GB5551@somewhere>

On Mon, Jul 04, 2011 at 03:29:14PM +0200, Frederic Weisbecker wrote:
> On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote:
> > On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> > > Migrate conditional hw_breakpoint code compilation under
> > > the new config to prepare for letting the user chose whether
> > > or not to build this feature
> > > 
> > 
> > Making the hardware breakpoint patches modular has always been a goal.
> > I've looked at the PowerPC parts of the code and they look harmless.
> > 
> > Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>
> 
> Great!
> 
> I'll push that soon, thanks guys for your acks!

Meanwhile, I was testing hardware breakpoints through perf and found
that monitoring a given address fails when using 'perf record' (returns
-ENOSPC) while 'perf stat' and watchpoint through gdb works fine (see
logs below).

Has this behaviour been reported for other perf counters?

Thanks,
K.Prasad

# tools/perf/perf --version
perf version 3.0.0-rc5
# 
# grep pid_max /proc/kallsyms 
ffffffff81a25010 D pid_max
ffffffff81a25014 D pid_max_min
ffffffff81a25018 D pid_max_max
# 
# uname -a
Linux llm37.in.ibm.com 3.0.0-rc5 #1 SMP Mon Jul 4 22:24:02 IST 2011
x86_64 x86_64 x86_64 GNU/Linux
# 
# tools/perf/perf stat -e mem:0xffffffff81a25010:rw make kernel/futex.o
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
make[1]: `kernel/futex.o' is up to date.

 Performance counter stats for 'make kernel/futex.o':

               188 mem:0xffffffff81a25010:rw                                   

      10.734957333 seconds time elapsed

# tools/perf/perf record -e
mem:0xffffffff81a25010:rw make kernel/futex.o

  Error: sys_perf_event_open() syscall returned with 28 (No space left
on device).  /bin/dmesg may provide additional information.

  Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?

^ permalink raw reply

* [PATCH 1/3] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Roy Zang @ 2011-07-05  4:19 UTC (permalink / raw)
  To: linux-mmc; +Cc: Xu lei, linuxppc-dev, akpm

From: Xu lei <B33228@freescale.com>

For Freescale eSDHC registers only support 32-bit accesses,
this patch ensure that all Freescale eSDHC register accesses
are 32-bit.

Signed-off-by: Xu lei <B33228@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 drivers/mmc/host/sdhci-of-esdhc.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index ba40d6d..c9a8519 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1,7 +1,7 @@
 /*
  * Freescale eSDHC controller driver.
  *
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2010 Freescale Semiconductor, Inc.
  * Copyright (c) 2009 MontaVista Software, Inc.
  *
  * Authors: Xiaobo Xie <X.Xie@freescale.com>
@@ -23,11 +23,21 @@
 static u16 esdhc_readw(struct sdhci_host *host, int reg)
 {
 	u16 ret;
+	int base = reg & ~0x3;
+	int shift = (reg & 0x2) * 8;
 
 	if (unlikely(reg == SDHCI_HOST_VERSION))
-		ret = in_be16(host->ioaddr + reg);
+		ret = in_be32(host->ioaddr + base) & 0xffff;
 	else
-		ret = sdhci_be32bs_readw(host, reg);
+		ret = (in_be32(host->ioaddr + base) >> shift) & 0xffff;
+	return ret;
+}
+
+static u8 esdhc_readb(struct sdhci_host *host, int reg)
+{
+	int base = reg & ~0x3;
+	int shift = (reg & 0x3) * 8;
+	u8 ret = (in_be32(host->ioaddr + base) >> shift) & 0xff;
 	return ret;
 }
 
@@ -79,7 +89,7 @@ struct sdhci_of_data sdhci_esdhc = {
 	.ops = {
 		.read_l = sdhci_be32bs_readl,
 		.read_w = esdhc_readw,
-		.read_b = sdhci_be32bs_readb,
+		.read_b = esdhc_readb,
 		.write_l = sdhci_be32bs_writel,
 		.write_w = esdhc_writew,
 		.write_b = esdhc_writeb,
-- 
1.6.0.6

^ permalink raw reply related

* [PATCH 3/3] eSDHC: fix incorrect default value of the capabilities register on P4080
From: Roy Zang @ 2011-07-05  4:19 UTC (permalink / raw)
  To: linux-mmc; +Cc: akpm, linuxppc-dev
In-Reply-To: <1309839543-6031-2-git-send-email-tie-fei.zang@freescale.com>

P4080 eSDHC errata 12 describes incorrect default value of the
the host controller capabilities register.

The default value of the VS18 and VS30 fields in the host controller
capabilities register (HOSTCAPBLT) are incorrect. The default of these bits
should be zero instead of one in the eSDHC logic.

This patch adds the workaround for these errata.

Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
 drivers/mmc/host/sdhci-of-core.c |    3 +++
 drivers/mmc/host/sdhci.c         |    6 ++++++
 include/linux/mmc/sdhci.h        |    4 ++++
 3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index fede43d..9bdd30d 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -182,6 +182,9 @@ static int __devinit sdhci_of_probe(struct platform_device *ofdev)
 	if (of_device_is_compatible(np, "fsl,esdhc"))
 		host->quirks |= SDHCI_QUIRK_QORIQ_PROCTL_WEIRD;
 
+	if (of_device_is_compatible(np, "fsl,p4080-esdhc"))
+		host->quirks |= SDHCI_QUIRK_QORIQ_HOSTCAPBLT_ONLY_VS33;
+
 	clk = of_get_property(np, "clock-frequency", &size);
 	if (clk && size == sizeof(*clk) && *clk)
 		of_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 77174e5..7e0b4cd 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2396,6 +2396,12 @@ int sdhci_add_host(struct sdhci_host *host)
 	caps[1] = (host->version >= SDHCI_SPEC_300) ?
 		sdhci_readl(host, SDHCI_CAPABILITIES_1) : 0;
 
+	 /* Make sure clean the VS18 and VS30 bit. P4080 incorrectly
+	  * set the voltage capability bits
+	  */
+	if (host->quirks & SDHCI_QUIRK_QORIQ_HOSTCAPBLT_ONLY_VS33)
+		caps[0] &= ~(SDHCI_CAN_VDD_180 | SDHCI_CAN_VDD_300);
+
 	if (host->quirks & SDHCI_QUIRK_FORCE_DMA)
 		host->flags |= SDHCI_USE_SDMA;
 	else if (!(caps[0] & SDHCI_CAN_DO_SDMA))
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index d87abc7..7ffd458 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -89,6 +89,10 @@ struct sdhci_host {
 #define SDHCI_QUIRK_UNSTABLE_RO_DETECT			(1U<<31)
 /* Controller has weird bit setting for Protocol Control Register */
 #define SDHCI_QUIRK_QORIQ_PROCTL_WEIRD			(0x100000000U)
+/* Controller can only supports 3.3V, but the capabilities register
+ * has incorrect set 1.8V and 3.0V
+ */
+#define SDHCI_QUIRK_QORIQ_HOSTCAPBLT_ONLY_VS33		(0x200000000U)
 
 	int irq;		/* Device IRQ */
 	void __iomem *ioaddr;	/* Mapped address */
-- 
1.6.0.6

^ permalink raw reply related

* [PATCH 2/3] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Roy Zang @ 2011-07-05  4:19 UTC (permalink / raw)
  To: linux-mmc; +Cc: Xu lei, linuxppc-dev, akpm
In-Reply-To: <1309839543-6031-1-git-send-email-tie-fei.zang@freescale.com>

From: Xu lei <B33228@freescale.com>

When esdhc module was enabled in p5020, there were following errors:

mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 whilst initialising SD card
mmc0: Unexpected interrupt 0x02000000.
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 whilst initialising SD card
mmc0: Unexpected interrupt 0x02000000.

It is because ESDHC controller has different bit setting for PROCTL
register, when kernel sets Power Control Register by method for standard
SD Host Specification, it would overwritten FSL ESDHC PROCTL[DMAS];
when it set Host Control Registers[DMAS], it sets PROCTL[EMODE] and
PROCTL[D3CD]. These operations will set bad bits for PROCTL Register
on FSL ESDHC Controller and cause errors, so this patch will make esdhc
driver access FSL PROCTL Register according to block guide instead of
standard SD Host Specification.

For some FSL chips, such as MPC8536/P2020, PROCTL[VOLT_SEL] and PROCTL[DMAS]
bits are reserved and even if they are set to wrong bits there is no error.
But considering that all FSL ESDHC Controller register map is not fully
compliant to standard SD Host Specification, we put the patch to all of
FSL ESDHC Controllers.

Signed-off-by: Lei Xu <B33228@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 drivers/mmc/host/sdhci-of-core.c |    3 ++
 drivers/mmc/host/sdhci.c         |   62 ++++++++++++++++++++++++++++++-------
 include/linux/mmc/sdhci.h        |    6 ++-
 3 files changed, 57 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index 60e4186..fede43d 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -179,6 +179,9 @@ static int __devinit sdhci_of_probe(struct platform_device *ofdev)
 	if (sdhci_of_wp_inverted(np))
 		host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
 
+	if (of_device_is_compatible(np, "fsl,esdhc"))
+		host->quirks |= SDHCI_QUIRK_QORIQ_PROCTL_WEIRD;
+
 	clk = of_get_property(np, "clock-frequency", &size);
 	if (clk && size == sizeof(*clk) && *clk)
 		of_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 58d5436..77174e5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -674,7 +674,7 @@ static void sdhci_set_transfer_irqs(struct sdhci_host *host)
 static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
 {
 	u8 count;
-	u8 ctrl;
+	u32 ctrl;
 	struct mmc_data *data = cmd->data;
 	int ret;
 
@@ -807,14 +807,28 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
 	 * is ADMA.
 	 */
 	if (host->version >= SDHCI_SPEC_200) {
-		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
-		ctrl &= ~SDHCI_CTRL_DMA_MASK;
-		if ((host->flags & SDHCI_REQ_USE_DMA) &&
-			(host->flags & SDHCI_USE_ADMA))
-			ctrl |= SDHCI_CTRL_ADMA32;
-		else
-			ctrl |= SDHCI_CTRL_SDMA;
-		sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+		if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) {
+#define ESDHCI_PROCTL_DMAS_MASK		0x00000300
+#define ESDHCI_PROCTL_ADMA32		0x00000200
+#define ESDHCI_PROCTL_SDMA		0x00000000
+			ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
+			ctrl &= ~ESDHCI_PROCTL_DMAS_MASK;
+			if ((host->flags & SDHCI_REQ_USE_DMA) &&
+				(host->flags & SDHCI_USE_ADMA))
+				ctrl |= ESDHCI_PROCTL_ADMA32;
+			else
+				ctrl |= ESDHCI_PROCTL_SDMA;
+			sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
+		} else {
+			ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+			ctrl &= ~SDHCI_CTRL_DMA_MASK;
+			if ((host->flags & SDHCI_REQ_USE_DMA) &&
+				(host->flags & SDHCI_USE_ADMA))
+				ctrl |= SDHCI_CTRL_ADMA32;
+			else
+				ctrl |= SDHCI_CTRL_SDMA;
+			sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+		}
 	}
 
 	if (!(host->flags & SDHCI_REQ_USE_DMA)) {
@@ -1138,19 +1152,32 @@ out:
 static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
 {
 	u8 pwr = 0;
+	u8 volt = 0;
 
 	if (power != (unsigned short)-1) {
 		switch (1 << power) {
+#define	ESDHCI_FSL_POWER_MASK	0x40
+#define	ESDHCI_FSL_POWER_180	0x00
+#define	ESDHCI_FSL_POWER_300	0x40
 		case MMC_VDD_165_195:
-			pwr = SDHCI_POWER_180;
+			if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD)
+				pwr = ESDHCI_FSL_POWER_180;
+			else
+				pwr = SDHCI_POWER_180;
 			break;
 		case MMC_VDD_29_30:
 		case MMC_VDD_30_31:
-			pwr = SDHCI_POWER_300;
+			if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD)
+				pwr = ESDHCI_FSL_POWER_300;
+			else
+				pwr = SDHCI_POWER_300;
 			break;
 		case MMC_VDD_32_33:
 		case MMC_VDD_33_34:
-			pwr = SDHCI_POWER_330;
+			if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD)
+				pwr = ESDHCI_FSL_POWER_300;
+			else
+				pwr = SDHCI_POWER_330;
 			break;
 		default:
 			BUG();
@@ -1162,6 +1189,17 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
 
 	host->pwr = pwr;
 
+	/* Now FSL ESDHC Controller has no Bus Power bit,
+	 * and PROCTL[21] bit is for voltage selection */
+	if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) {
+		volt = sdhci_readb(host, SDHCI_POWER_CONTROL);
+		volt &= ~ESDHCI_FSL_POWER_MASK;
+		volt |= pwr;
+		sdhci_writeb(host, volt, SDHCI_POWER_CONTROL);
+
+		return;
+	}
+
 	if (pwr == 0) {
 		sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
 		return;
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 6a68c4e..d87abc7 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -21,7 +21,7 @@ struct sdhci_host {
 	/* Data set by hardware interface driver */
 	const char *hw_name;	/* Hardware bus name */
 
-	unsigned int quirks;	/* Deviations from spec. */
+	u64 quirks;	/* Deviations from spec. */
 
 /* Controller doesn't honor resets unless we touch the clock register */
 #define SDHCI_QUIRK_CLOCK_BEFORE_RESET			(1<<0)
@@ -86,7 +86,9 @@ struct sdhci_host {
 /* Controller treats ADMA descriptors with length 0000h incorrectly */
 #define SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC		(1<<30)
 /* The read-only detection via SDHCI_PRESENT_STATE register is unstable */
-#define SDHCI_QUIRK_UNSTABLE_RO_DETECT			(1<<31)
+#define SDHCI_QUIRK_UNSTABLE_RO_DETECT			(1U<<31)
+/* Controller has weird bit setting for Protocol Control Register */
+#define SDHCI_QUIRK_QORIQ_PROCTL_WEIRD			(0x100000000U)
 
 	int irq;		/* Device IRQ */
 	void __iomem *ioaddr;	/* Mapped address */
-- 
1.6.0.6

^ permalink raw reply related

* Re: hvc_console change results in corrupt oops output
From: Tabi Timur-B04825 @ 2011-07-05  4:17 UTC (permalink / raw)
  To: Hendrik Brueckner
  Cc: linuxppc-dev@lists.ozlabs.org, Anton Blanchard,
	borntraeger@de.ibm.com
In-Reply-To: <20110704142429.GA2147@linux.vnet.ibm.com>

On Mon, Jul 4, 2011 at 9:24 AM, Hendrik Brueckner
<brueckner@linux.vnet.ibm.com> wrote:

> I will check this again for my hvc_iucv back-end. =A0Meanwhile a found
> an old thread discussing the same issue. =A0It covers some differences
> between console and ttys which actually does not matter for hvc-backend
> because of the shared put_chars() routine.
>
> You can read the thread on lkml.org: http://lkml.org/lkml/2009/10/15/149

I started that thread.  After much soul searching, we came to the
conclusion that HVC is not compatible with hypervisors that return
BUSY on writes.  So I threw out my HVC driver and rewrote it as a
standard console and TTY driver.  That driver is waiting to be
included in the 3.1 kernel.

--=20
Timur Tabi
Linux kernel developer at Freescale=

^ permalink raw reply

* [PATCH 1/3] powerpc/47x: allow kernel to be loaded in higher physical memory
From: Tony Breeds @ 2011-07-05  4:36 UTC (permalink / raw)
  To: LinuxPPC-dev, Josh Boyer, Benjamin Herrenschmidt

From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>

The 44x code (which is shared by 47x) assumes the available physical memory
begins at 0x00000000.  This is not necessarily the case in an AMP
environment.

Support CONFIG_RELOCATABLE for 476 in order to allow the kernel to be
loaded into a higher memory range.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/Kconfig                          |    2 +-
 arch/powerpc/configs/44x/iss476-smp_defconfig |    6 ++--
 arch/powerpc/kernel/head_44x.S                |   42 ++++++++++++++++++++-----
 arch/powerpc/mm/44x_mmu.c                     |   13 ++++++--
 4 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2729c66..7cef1fc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -841,7 +841,7 @@ config LOWMEM_CAM_NUM
 
 config RELOCATABLE
 	bool "Build a relocatable kernel (EXPERIMENTAL)"
-	depends on EXPERIMENTAL && ADVANCED_OPTIONS && FLATMEM && FSL_BOOKE
+	depends on EXPERIMENTAL && ADVANCED_OPTIONS && FLATMEM && (FSL_BOOKE || PPC_47x)
 	help
 	  This builds a kernel image that is capable of running at the
 	  location the kernel is loaded at (some alignment restrictions may
diff --git a/arch/powerpc/configs/44x/iss476-smp_defconfig b/arch/powerpc/configs/44x/iss476-smp_defconfig
index 92f863a..a6eb6ad 100644
--- a/arch/powerpc/configs/44x/iss476-smp_defconfig
+++ b/arch/powerpc/configs/44x/iss476-smp_defconfig
@@ -3,8 +3,8 @@ CONFIG_SMP=y
 CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_SPARSE_IRQ=y
 CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
 CONFIG_BLK_DEV_INITRD=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 CONFIG_EXPERT=y
@@ -21,10 +21,11 @@ CONFIG_ISS4xx=y
 CONFIG_HZ_100=y
 CONFIG_MATH_EMULATION=y
 CONFIG_IRQ_ALL_CPUS=y
-CONFIG_SPARSE_IRQ=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="root=/dev/issblk0"
 # CONFIG_PCI is not set
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_RELOCATABLE=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -67,7 +68,6 @@ CONFIG_EXT3_FS=y
 # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
 CONFIG_EXT3_FS_POSIX_ACL=y
 CONFIG_EXT3_FS_SECURITY=y
-CONFIG_INOTIFY=y
 CONFIG_PROC_KCORE=y
 CONFIG_TMPFS=y
 CONFIG_CRAMFS=y
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 5e12b74..f8e971b 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -93,6 +93,30 @@ _ENTRY(_start);
 
 	bl	early_init
 
+#ifdef CONFIG_RELOCATABLE
+	/*
+	 * r25 will contain RPN/ERPN for the start address of memory
+	 *
+	 * Add the difference between KERNELBASE and PAGE_OFFSET to the
+	 * start of physical memory to get kernstart_addr.
+	 */
+	lis	r3,kernstart_addr@ha
+	la	r3,kernstart_addr@l(r3)
+
+	lis	r4,KERNELBASE@h
+	ori	r4,r4,KERNELBASE@l
+	lis	r5,PAGE_OFFSET@h
+	ori	r5,r5,PAGE_OFFSET@l
+	subf	r4,r5,r4
+
+	rlwinm	r6,r25,0,28,31	/* ERPN */
+	rlwinm	r7,r25,0,0,3	/* RPN - assuming 256 MB page size */
+	add	r7,r7,r4
+
+	stw	r6,0(r3)
+	stw	r7,4(r3)
+#endif
+
 /*
  * Decide what sort of machine this is and initialize the MMU.
  */
@@ -1001,9 +1025,6 @@ clear_utlb_entry:
 	lis	r3,PAGE_OFFSET@h
 	ori	r3,r3,PAGE_OFFSET@l
 
-	/* Kernel is at the base of RAM */
-	li r4, 0			/* Load the kernel physical address */
-
 	/* Load the kernel PID = 0 */
 	li	r0,0
 	mtspr	SPRN_PID,r0
@@ -1013,9 +1034,8 @@ clear_utlb_entry:
 	clrrwi	r3,r3,12		/* Mask off the effective page number */
 	ori	r3,r3,PPC47x_TLB0_VALID | PPC47x_TLB0_256M
 
-	/* Word 1 */
-	clrrwi	r4,r4,12		/* Mask off the real page number */
-					/* ERPN is 0 for first 4GB page */
+	/* Word 1 - use r25.  RPN is the same as the original entry */
+
 	/* Word 2 */
 	li	r5,0
 	ori	r5,r5,PPC47x_TLB2_S_RWX
@@ -1026,7 +1046,7 @@ clear_utlb_entry:
 	/* We write to way 0 and bolted 0 */
 	lis	r0,0x8800
 	tlbwe	r3,r0,0
-	tlbwe	r4,r0,1
+	tlbwe	r25,r0,1
 	tlbwe	r5,r0,2
 
 /*
@@ -1124,7 +1144,13 @@ head_start_common:
 	lis	r4,interrupt_base@h	/* IVPR only uses the high 16-bits */
 	mtspr	SPRN_IVPR,r4
 
-	addis	r22,r22,KERNELBASE@h
+	/*
+	 * If the kernel was loaded at a non-zero 256 MB page, we need to
+	 * mask off the most significant 4 bits to get the relative address
+	 * from the start of physical memory
+	 */
+	rlwinm	r22,r22,0,4,31
+	addis	r22,r22,PAGE_OFFSET@h
 	mtlr	r22
 	isync
 	blr
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index 024acab..f60e006 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -186,10 +186,11 @@ void __init MMU_init_hw(void)
 unsigned long __init mmu_mapin_ram(unsigned long top)
 {
 	unsigned long addr;
+	unsigned long memstart = memstart_addr & ~(PPC_PIN_SIZE - 1);
 
 	/* Pin in enough TLBs to cover any lowmem not covered by the
 	 * initial 256M mapping established in head_44x.S */
-	for (addr = PPC_PIN_SIZE; addr < lowmem_end_addr;
+	for (addr = memstart + PPC_PIN_SIZE; addr < lowmem_end_addr;
 	     addr += PPC_PIN_SIZE) {
 		if (mmu_has_feature(MMU_FTR_TYPE_47x))
 			ppc47x_pin_tlb(addr + PAGE_OFFSET, addr);
@@ -218,19 +219,25 @@ unsigned long __init mmu_mapin_ram(unsigned long top)
 void setup_initial_memory_limit(phys_addr_t first_memblock_base,
 				phys_addr_t first_memblock_size)
 {
+	u64 size;
+
+#ifndef CONFIG_RELOCATABLE
 	/* We don't currently support the first MEMBLOCK not mapping 0
 	 * physical on those processors
 	 */
 	BUG_ON(first_memblock_base != 0);
+#endif
 
 	/* 44x has a 256M TLB entry pinned at boot */
-	memblock_set_current_limit(min_t(u64, first_memblock_size, PPC_PIN_SIZE));
+	size = (min_t(u64, first_memblock_size, PPC_PIN_SIZE));
+	memblock_set_current_limit(first_memblock_base + size);
 }
 
 #ifdef CONFIG_SMP
 void __cpuinit mmu_init_secondary(int cpu)
 {
 	unsigned long addr;
+	unsigned long memstart = memstart_addr & ~(PPC_PIN_SIZE - 1);
 
 	/* Pin in enough TLBs to cover any lowmem not covered by the
 	 * initial 256M mapping established in head_44x.S
@@ -241,7 +248,7 @@ void __cpuinit mmu_init_secondary(int cpu)
 	 * stack. current (r2) isn't initialized, smp_processor_id()
 	 * will not work, current thread info isn't accessible, ...
 	 */
-	for (addr = PPC_PIN_SIZE; addr < lowmem_end_addr;
+	for (addr = memstart + PPC_PIN_SIZE; addr < lowmem_end_addr;
 	     addr += PPC_PIN_SIZE) {
 		if (mmu_has_feature(MMU_FTR_TYPE_47x))
 			ppc47x_pin_tlb(addr + PAGE_OFFSET, addr);
-- 
1.7.4.4

^ permalink raw reply related

* [PATCH 2/3] powerpc/44x: don't use tlbivax on AMP systems
From: Tony Breeds @ 2011-07-05  4:38 UTC (permalink / raw)
  To: LinuxPPC-dev, Josh Boyer, Benjamin Herrenschmidt
In-Reply-To: <20110705043657.GF13483@ozlabs.org>

From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>

Since other OS's may be running on the other cores don't use tlbivax

Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/include/asm/mmu.h |    7 ++++++-
 arch/powerpc/kernel/setup_32.c |    2 ++
 arch/powerpc/mm/tlb_hash32.c   |    4 ++++
 arch/powerpc/mm/tlb_nohash.c   |   19 +++++++++++++++++++
 4 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 4138b21..bb5591f 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -120,9 +120,14 @@ static inline int mmu_has_feature(unsigned long feature)
 	return (cur_cpu_spec->mmu_features & feature);
 }
 
+static inline void mmu_clear_feature(unsigned long feature)
+{
+	cur_cpu_spec->mmu_features &= ~feature;
+}
+
 extern unsigned int __start___mmu_ftr_fixup, __stop___mmu_ftr_fixup;
 
-/* MMU initialization (64-bit only fo now) */
+/* MMU initialization */
 extern void early_init_mmu(void);
 extern void early_init_mmu_secondary(void);
 
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 620d792..6bae164 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -127,6 +127,8 @@ notrace void __init machine_init(unsigned long dt_ptr)
 	/* Do some early initialization based on the flat device tree */
 	early_init_devtree(__va(dt_ptr));
 
+	early_init_mmu();
+
 	probe_machine();
 
 	setup_kdump_trampoline();
diff --git a/arch/powerpc/mm/tlb_hash32.c b/arch/powerpc/mm/tlb_hash32.c
index 27b863c..9a445f6 100644
--- a/arch/powerpc/mm/tlb_hash32.c
+++ b/arch/powerpc/mm/tlb_hash32.c
@@ -177,3 +177,7 @@ void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
 	flush_range(vma->vm_mm, start, end);
 }
 EXPORT_SYMBOL(flush_tlb_range);
+
+void __init early_init_mmu(void)
+{
+}
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 0bdad3a..04990b9 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -35,6 +35,7 @@
 #include <linux/preempt.h>
 #include <linux/spinlock.h>
 #include <linux/memblock.h>
+#include <linux/of_fdt.h>
 
 #include <asm/tlbflush.h>
 #include <asm/tlb.h>
@@ -266,6 +267,17 @@ EXPORT_SYMBOL(flush_tlb_page);
 
 #endif /* CONFIG_SMP */
 
+#ifdef CONFIG_PPC_47x
+void __init early_init_mmu_47x(void)
+{
+#ifdef CONFIG_SMP
+	unsigned long root = of_get_flat_dt_root();
+	if (of_get_flat_dt_prop(root, "cooperative-partition", NULL))
+		mmu_clear_feature(MMU_FTR_USE_TLBIVAX_BCAST);
+#endif /* CONFIG_SMP */
+}
+#endif /* CONFIG_PPC_47x */
+
 /*
  * Flush kernel TLB entries in the given range
  */
@@ -584,4 +596,11 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base,
 	/* Finally limit subsequent allocations */
 	memblock_set_current_limit(first_memblock_base + ppc64_rma_size);
 }
+#else /* ! CONFIG_PPC64 */
+void __init early_init_mmu(void)
+{
+#ifdef CONFIG_PPC_47x
+	early_init_mmu_47x();
+#endif
+}
 #endif /* CONFIG_PPC64 */
-- 
1.7.4.4

^ permalink raw reply related

* [PATCH 3/3] powerpc/44x: boot wrapper: allow kernel to load into non-zero address
From: Tony Breeds @ 2011-07-05  4:38 UTC (permalink / raw)
  To: LinuxPPC-dev, Josh Boyer, Benjamin Herrenschmidt
In-Reply-To: <20110705043657.GF13483@ozlabs.org>

From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>

For AMP, different kernel instances load into separate memory regions.
Read the start of memory from the device tree and limit the memory to what's
specified in the device tree.

Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/boot/treeboot-iss4xx.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/treeboot-iss4xx.c b/arch/powerpc/boot/treeboot-iss4xx.c
index fcc4495..329e710 100644
--- a/arch/powerpc/boot/treeboot-iss4xx.c
+++ b/arch/powerpc/boot/treeboot-iss4xx.c
@@ -34,9 +34,29 @@
 
 BSS_STACK(4096);
 
+static u32 ibm4xx_memstart;
+
 static void iss_4xx_fixups(void)
 {
-	ibm4xx_sdram_fixup_memsize();
+	void *memory;
+	u32 reg[3];
+
+	memory = finddevice("/memory");
+	if (!memory)
+		fatal("Can't find memory node\n");
+	/* This assumes #address-cells = 2, #size-cells =1 and that */
+	getprop(memory, "reg", reg, sizeof(reg));
+	if (reg[2])
+		/* If the device tree specifies the memory range, use it */
+		ibm4xx_memstart = reg[1];
+	else
+		/* othersize, read it from the SDRAM controller */
+		ibm4xx_sdram_fixup_memsize();
+}
+
+static void *iss_4xx_vmlinux_alloc(unsigned long size)
+{
+	return (void *)ibm4xx_memstart;
 }
 
 #define SPRN_PIR	0x11E	/* Processor Indentification Register */
@@ -48,6 +68,7 @@ void platform_init(void)
 
 	simple_alloc_init(_end, avail_ram, 128, 64);
 	platform_ops.fixups = iss_4xx_fixups;
+	platform_ops.vmlinux_alloc = iss_4xx_vmlinux_alloc;
 	platform_ops.exit = ibm44x_dbcr_reset;
 	pir_reg = mfspr(SPRN_PIR);
 	fdt_set_boot_cpuid_phys(_dtb_start, pir_reg);
-- 
1.7.4.4

^ permalink raw reply related

* [PATCH] mm: Fix output of total_ram.
From: Tony Breeds @ 2011-07-05  4:44 UTC (permalink / raw)
  To: LinuxPPC-dev, Benjamin Herrenschmidt

On 32bit platforms that support >= 4GB memory total_ram was truncated.
This creates a confusing printk:
	Top of RAM: 0x100000000, Total RAM: 0x0
Fix that:
	Top of RAM: 0x100000000, Total RAM: 0x100000000

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
 arch/powerpc/mm/mem.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 29d4dde..ac1c3d3 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -249,7 +249,7 @@ static int __init mark_nonram_nosave(void)
  */
 void __init paging_init(void)
 {
-	unsigned long total_ram = memblock_phys_mem_size();
+	unsigned long long total_ram = memblock_phys_mem_size();
 	phys_addr_t top_of_ram = memblock_end_of_DRAM();
 	unsigned long max_zone_pfns[MAX_NR_ZONES];
 
@@ -269,7 +269,7 @@ void __init paging_init(void)
 	kmap_prot = PAGE_KERNEL;
 #endif /* CONFIG_HIGHMEM */
 
-	printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
+	printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
 	       (unsigned long long)top_of_ram, total_ram);
 	printk(KERN_DEBUG "Memory hole size: %ldMB\n",
 	       (long int)((top_of_ram - total_ram) >> 20));
-- 
1.7.4.4

^ permalink raw reply related

* [PATCH] powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
From: Anton Blanchard @ 2011-07-05  6:12 UTC (permalink / raw)
  To: benh, mikey, linuxppc-dev


We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.

Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---

Index: linux-powerpc/arch/powerpc/kernel/crash.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/kernel/crash.c	2011-07-05 15:04:18.512140484 +1000
+++ linux-powerpc/arch/powerpc/kernel/crash.c	2011-07-05 15:05:51.483747575 +1000
@@ -240,7 +240,8 @@ static void crash_kexec_wait_realmode(in
 		if (i == cpu)
 			continue;
 
-		while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
+		while ((paca[i].kexec_state < KEXEC_STATE_REAL_MODE) &&
+				(msecs > 0)) {
 			barrier();
 			if (!cpu_possible(i)) {
 				break;

^ permalink raw reply

* Re: [PATCH 1/3] powerpc/47x: allow kernel to be loaded in higher physical memory
From: Suzuki Poulose @ 2011-07-05  6:18 UTC (permalink / raw)
  To: LinuxPPC-dev, Josh Boyer, Benjamin Herrenschmidt
In-Reply-To: <20110705043657.GF13483@ozlabs.org>

On 07/05/11 10:06, Tony Breeds wrote:
> From: Dave Kleikamp<shaggy@linux.vnet.ibm.com>
>
> The 44x code (which is shared by 47x) assumes the available physical memory
> begins at 0x00000000.  This is not necessarily the case in an AMP
> environment.
>
> Support CONFIG_RELOCATABLE for 476 in order to allow the kernel to be
> loaded into a higher memory range.

I think the code assumes, the kernel is loaded in 256M aligned page. You may
want to mention that in the description here.

Thanks
Suzuki

^ permalink raw reply

* Re: [PATCH 2/3] eSDHC: Fix errors when booting kernel with fsl esdhc
From: S, Venkatraman @ 2011-07-05  6:17 UTC (permalink / raw)
  To: Roy Zang; +Cc: Xu lei, linux-mmc, akpm, linuxppc-dev
In-Reply-To: <1309839543-6031-2-git-send-email-tie-fei.zang@freescale.com>

On Tue, Jul 5, 2011 at 9:49 AM, Roy Zang <tie-fei.zang@freescale.com> wrote=
:
> From: Xu lei <B33228@freescale.com>
>
> When esdhc module was enabled in p5020, there were following errors:
>
> mmc0: Timeout waiting for hardware interrupt.
> mmc0: error -110 whilst initialising SD card
> mmc0: Unexpected interrupt 0x02000000.
> mmc0: Timeout waiting for hardware interrupt.
> mmc0: error -110 whilst initialising SD card
> mmc0: Unexpected interrupt 0x02000000.
>
> It is because ESDHC controller has different bit setting for PROCTL
> register, when kernel sets Power Control Register by method for standard
> SD Host Specification, it would overwritten FSL ESDHC PROCTL[DMAS];
> when it set Host Control Registers[DMAS], it sets PROCTL[EMODE] and
> PROCTL[D3CD]. These operations will set bad bits for PROCTL Register
> on FSL ESDHC Controller and cause errors, so this patch will make esdhc
> driver access FSL PROCTL Register according to block guide instead of
> standard SD Host Specification.
>
> For some FSL chips, such as MPC8536/P2020, PROCTL[VOLT_SEL] and PROCTL[DM=
AS]
> bits are reserved and even if they are set to wrong bits there is no erro=
r.
> But considering that all FSL ESDHC Controller register map is not fully
> compliant to standard SD Host Specification, we put the patch to all of
> FSL ESDHC Controllers.
>
> Signed-off-by: Lei Xu <B33228@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A03 ++
> =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 62 ++++++++++++++++++++=
++++++++++-------
> =A0include/linux/mmc/sdhci.h =A0 =A0 =A0 =A0| =A0 =A06 ++-
> =A03 files changed, 57 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of=
-core.c
> index 60e4186..fede43d 100644
> --- a/drivers/mmc/host/sdhci-of-core.c
> +++ b/drivers/mmc/host/sdhci-of-core.c
> @@ -179,6 +179,9 @@ static int __devinit sdhci_of_probe(struct platform_d=
evice *ofdev)
> =A0 =A0 =A0 =A0if (sdhci_of_wp_inverted(np))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0host->quirks |=3D SDHCI_QUIRK_INVERTED_WRI=
TE_PROTECT;
>
> + =A0 =A0 =A0 if (of_device_is_compatible(np, "fsl,esdhc"))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 host->quirks |=3D SDHCI_QUIRK_QORIQ_PROCTL_=
WEIRD;
> +
> =A0 =A0 =A0 =A0clk =3D of_get_property(np, "clock-frequency", &size);
> =A0 =A0 =A0 =A0if (clk && size =3D=3D sizeof(*clk) && *clk)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of_host->clock =3D be32_to_cpup(clk);
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 58d5436..77174e5 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -674,7 +674,7 @@ static void sdhci_set_transfer_irqs(struct sdhci_host=
 *host)
> =A0static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_com=
mand *cmd)
> =A0{
> =A0 =A0 =A0 =A0u8 count;
> - =A0 =A0 =A0 u8 ctrl;
> + =A0 =A0 =A0 u32 ctrl;
> =A0 =A0 =A0 =A0struct mmc_data *data =3D cmd->data;
> =A0 =A0 =A0 =A0int ret;
>
> @@ -807,14 +807,28 @@ static void sdhci_prepare_data(struct sdhci_host *h=
ost, struct mmc_command *cmd)
> =A0 =A0 =A0 =A0 * is ADMA.
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0if (host->version >=3D SDHCI_SPEC_200) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl =3D sdhci_readb(host, SDHCI_HOST_CONTR=
OL);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl &=3D ~SDHCI_CTRL_DMA_MASK;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((host->flags & SDHCI_REQ_USE_DMA) &&
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (host->flags & SDHCI_USE_AD=
MA))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D SDHCI_CTRL_ADMA32=
;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D SDHCI_CTRL_SDMA;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL=
_WEIRD) {
> +#define ESDHCI_PROCTL_DMAS_MASK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x0000030=
0
> +#define ESDHCI_PROCTL_ADMA32 =A0 =A0 =A0 =A0 =A0 0x00000200
> +#define ESDHCI_PROCTL_SDMA =A0 =A0 =A0 =A0 =A0 =A0 0x00000000

Breaks the code flow / readability. Can be moved to top of the file ?

> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl =3D sdhci_readl(host, =
SDHCI_HOST_CONTROL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl &=3D ~ESDHCI_PROCTL_DM=
AS_MASK;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((host->flags & SDHCI_RE=
Q_USE_DMA) &&
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (host->flag=
s & SDHCI_USE_ADMA))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D E=
SDHCI_PROCTL_ADMA32;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D E=
SDHCI_PROCTL_SDMA;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sdhci_writel(host, ctrl, SD=
HCI_HOST_CONTROL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl =3D sdhci_readb(host, =
SDHCI_HOST_CONTROL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl &=3D ~SDHCI_CTRL_DMA_M=
ASK;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((host->flags & SDHCI_RE=
Q_USE_DMA) &&
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (host->flag=
s & SDHCI_USE_ADMA))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D S=
DHCI_CTRL_ADMA32;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D S=
DHCI_CTRL_SDMA;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sdhci_writeb(host, ctrl, SD=
HCI_HOST_CONTROL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0if (!(host->flags & SDHCI_REQ_USE_DMA)) {
> @@ -1138,19 +1152,32 @@ out:
> =A0static void sdhci_set_power(struct sdhci_host *host, unsigned short po=
wer)
> =A0{
> =A0 =A0 =A0 =A0u8 pwr =3D 0;
> + =A0 =A0 =A0 u8 volt =3D 0;
>
> =A0 =A0 =A0 =A0if (power !=3D (unsigned short)-1) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0switch (1 << power) {
> +#define =A0 =A0 =A0 =A0ESDHCI_FSL_POWER_MASK =A0 0x40
> +#define =A0 =A0 =A0 =A0ESDHCI_FSL_POWER_180 =A0 =A00x00
> +#define =A0 =A0 =A0 =A0ESDHCI_FSL_POWER_300 =A0 =A00x40

<As above>

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case MMC_VDD_165_195:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D SDHCI_POWER_180;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks & SDHCI_QU=
IRK_QORIQ_PROCTL_WEIRD)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D ESD=
HCI_FSL_POWER_180;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D SDH=
CI_POWER_180;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case MMC_VDD_29_30:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case MMC_VDD_30_31:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D SDHCI_POWER_300;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks & SDHCI_QU=
IRK_QORIQ_PROCTL_WEIRD)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D ESD=
HCI_FSL_POWER_300;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D SDH=
CI_POWER_300;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case MMC_VDD_32_33:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case MMC_VDD_33_34:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D SDHCI_POWER_330;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks & SDHCI_QU=
IRK_QORIQ_PROCTL_WEIRD)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D ESD=
HCI_FSL_POWER_300;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pwr =3D SDH=
CI_POWER_330;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0default:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG();
> @@ -1162,6 +1189,17 @@ static void sdhci_set_power(struct sdhci_host *hos=
t, unsigned short power)
>
> =A0 =A0 =A0 =A0host->pwr =3D pwr;
>
> + =A0 =A0 =A0 /* Now FSL ESDHC Controller has no Bus Power bit,
> + =A0 =A0 =A0 =A0* and PROCTL[21] bit is for voltage selection */

Multiline comment style needed..

> + =A0 =A0 =A0 if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 volt =3D sdhci_readb(host, SDHCI_POWER_CONT=
ROL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 volt &=3D ~ESDHCI_FSL_POWER_MASK;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 volt |=3D pwr;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 sdhci_writeb(host, volt, SDHCI_POWER_CONTRO=
L);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> + =A0 =A0 =A0 }
> +
> =A0 =A0 =A0 =A0if (pwr =3D=3D 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sdhci_writeb(host, 0, SDHCI_POWER_CONTROL)=
;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index 6a68c4e..d87abc7 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -21,7 +21,7 @@ struct sdhci_host {
> =A0 =A0 =A0 =A0/* Data set by hardware interface driver */
> =A0 =A0 =A0 =A0const char *hw_name; =A0 =A0/* Hardware bus name */
>
> - =A0 =A0 =A0 unsigned int quirks; =A0 =A0/* Deviations from spec. */
> + =A0 =A0 =A0 u64 quirks; =A0 =A0 /* Deviations from spec. */
>
> =A0/* Controller doesn't honor resets unless we touch the clock register =
*/
> =A0#define SDHCI_QUIRK_CLOCK_BEFORE_RESET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 (1<<0)
> @@ -86,7 +86,9 @@ struct sdhci_host {
> =A0/* Controller treats ADMA descriptors with length 0000h incorrectly */
> =A0#define SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC =A0 =A0 =A0 =A0 =A0 (1<<3=
0)
> =A0/* The read-only detection via SDHCI_PRESENT_STATE register is unstabl=
e */
> -#define SDHCI_QUIRK_UNSTABLE_RO_DETECT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (=
1<<31)
> +#define SDHCI_QUIRK_UNSTABLE_RO_DETECT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (=
1U<<31)
> +/* Controller has weird bit setting for Protocol Control Register */
> +#define SDHCI_QUIRK_QORIQ_PROCTL_WEIRD =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (=
0x100000000U)
>
> =A0 =A0 =A0 =A0int irq; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Device IRQ */
> =A0 =A0 =A0 =A0void __iomem *ioaddr; =A0 /* Mapped address */
> --
> 1.6.0.6
>

^ permalink raw reply

* Re: hvc_console change results in corrupt oops output
From: Benjamin Herrenschmidt @ 2011-07-05  6:22 UTC (permalink / raw)
  To: Tabi Timur-B04825
  Cc: borntraeger@de.ibm.com, Hendrik Brueckner,
	linuxppc-dev@lists.ozlabs.org, Anton Blanchard
In-Reply-To: <CAOZdJXW0Lota0ZuEnOHhsU93v7WmvYztEMyfg+UsMKxFdoXNXQ@mail.gmail.com>

On Tue, 2011-07-05 at 04:17 +0000, Tabi Timur-B04825 wrote:
> On Mon, Jul 4, 2011 at 9:24 AM, Hendrik Brueckner
> <brueckner@linux.vnet.ibm.com> wrote:
> 
> > I will check this again for my hvc_iucv back-end.  Meanwhile a found
> > an old thread discussing the same issue.  It covers some differences
> > between console and ttys which actually does not matter for hvc-backend
> > because of the shared put_chars() routine.
> >
> > You can read the thread on lkml.org: http://lkml.org/lkml/2009/10/15/149
> 
> I started that thread.  After much soul searching, we came to the
> conclusion that HVC is not compatible with hypervisors that return
> BUSY on writes. 

That is a fun conclusion considering that hvc has been written for the
pseries hypervisor which ... can return BUSY on writes :-)

> So I threw out my HVC driver and rewrote it as a
> standard console and TTY driver.  That driver is waiting to be
> included in the 3.1 kernel.

Sucktastic.

We just need to fix HVC properly.

Cheers,
Ben.

^ permalink raw reply

* [PATCH] powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
From: Michael Neuling @ 2011-07-05  6:40 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20110705161202.62dc7d24@kryten>

The existing code it pretty ugly.  How about we clean it up even more
like this?

From: Anton Blanchard <anton@samba.org>

We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@kernel.org>

diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 4e6ee94..cc6a9d5 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -242,12 +242,8 @@ static void crash_kexec_wait_realmode(int cpu)
 
 		while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
 			barrier();
-			if (!cpu_possible(i)) {
+			if (!cpu_possible(i) || !cpu_online(i) || (msecs <= 0))
 				break;
-			}
-			if (!cpu_online(i)) {
-				break;
-			}
 			msecs--;
 			mdelay(1);
 		}

^ permalink raw reply related

* Re: [PATCH 3/3] eSDHC: fix incorrect default value of the capabilities register on P4080
From: Anton Vorontsov @ 2011-07-05 10:18 UTC (permalink / raw)
  To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <1309839543-6031-3-git-send-email-tie-fei.zang@freescale.com>

On Tue, Jul 05, 2011 at 12:19:03PM +0800, Roy Zang wrote:
> P4080 eSDHC errata 12 describes incorrect default value of the
> the host controller capabilities register.
> 
> The default value of the VS18 and VS30 fields in the host controller
> capabilities register (HOSTCAPBLT) are incorrect. The default of these bits
> should be zero instead of one in the eSDHC logic.
> 
> This patch adds the workaround for these errata.
> 
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
>  drivers/mmc/host/sdhci-of-core.c |    3 +++
>  drivers/mmc/host/sdhci.c         |    6 ++++++
>  include/linux/mmc/sdhci.h        |    4 ++++
>  3 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
> index fede43d..9bdd30d 100644
> --- a/drivers/mmc/host/sdhci-of-core.c
> +++ b/drivers/mmc/host/sdhci-of-core.c
> @@ -182,6 +182,9 @@ static int __devinit sdhci_of_probe(struct platform_device *ofdev)
>  	if (of_device_is_compatible(np, "fsl,esdhc"))
>  		host->quirks |= SDHCI_QUIRK_QORIQ_PROCTL_WEIRD;
>  
> +	if (of_device_is_compatible(np, "fsl,p4080-esdhc"))
> +		host->quirks |= SDHCI_QUIRK_QORIQ_HOSTCAPBLT_ONLY_VS33;

Should really use voltage-ranges, not quirks.

http://www.spinics.net/lists/linux-mmc/msg02785.html

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

^ permalink raw reply

* Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
From: Frederic Weisbecker @ 2011-07-05 13:49 UTC (permalink / raw)
  To: K.Prasad; +Cc: Ingo Molnar, Paul Mundt, linuxppc-dev, LKML, Peter Zijlstra
In-Reply-To: <20110704174416.GA2166@in.ibm.com>

On Mon, Jul 04, 2011 at 11:14:16PM +0530, K.Prasad wrote:
> On Mon, Jul 04, 2011 at 03:29:14PM +0200, Frederic Weisbecker wrote:
> > On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote:
> > > On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> > > > Migrate conditional hw_breakpoint code compilation under
> > > > the new config to prepare for letting the user chose whether
> > > > or not to build this feature
> > > > 
> > > 
> > > Making the hardware breakpoint patches modular has always been a goal.
> > > I've looked at the PowerPC parts of the code and they look harmless.
> > > 
> > > Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>
> > 
> > Great!
> > 
> > I'll push that soon, thanks guys for your acks!
> 
> Meanwhile, I was testing hardware breakpoints through perf and found
> that monitoring a given address fails when using 'perf record' (returns
> -ENOSPC) while 'perf stat' and watchpoint through gdb works fine (see
> logs below).
> 
> Has this behaviour been reported for other perf counters?

Nope I haven't anything like that. What I reported privately to you a
few ago was actually due to a mistake of mine. Otherwise I haven't seen
other problems.

-ENOSPC is likely related to the breakpoint slot reservation, in kernel/events/hw_breakpoint.c

^ permalink raw reply

* Re: hvc_console change results in corrupt oops output
From: Tabi Timur-B04825 @ 2011-07-05 13:51 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: borntraeger@de.ibm.com, Hendrik Brueckner,
	linuxppc-dev@lists.ozlabs.org, Anton Blanchard
In-Reply-To: <1309846963.14501.270.camel@pasglop>

Benjamin Herrenschmidt wrote:

> That is a fun conclusion considering that hvc has been written for the
> pseries hypervisor which ... can return BUSY on writes :-)

Go read the original thread.  The problem is that tty writes and console=20
writes are treated the same by the hvc client driver.  If a client driver=20
detects that the hypervisor is busy, it has the choice of either spinning=20
or returning right away.  Spinning is not acceptable for tty output, so=20
all drivers return right away.  hvc then drops the unwritten characters.

According to Hendrik, this is still happening.

> We just need to fix HVC properly.

Where were you two years ago?  I complained about the problem, and even=20
posted a hackish "fix".  The response I got was tepid -- some=20
acknowledgement that the problem exists, but no real desire to fix it by=20
anyone.

So I had no choice but to abandon hvc.  And frankly, I still don't=20
understand why it exists.  Since then, I wrote a very nice console/tty=20
driver, and I have no plans to return to hvc even if the problem is fixed.

--=20
Timur Tabi
Linux kernel developer at Freescale=

^ permalink raw reply

* [RFC] virtio: expose for non-virtualization users too
From: Ohad Ben-Cohen @ 2011-07-05 14:06 UTC (permalink / raw)
  To: Rusty Russell, virtualization
  Cc: Carsten Otte, linux-ia64, kvm, Michael S. Tsirkin, linux-mips,
	Heiko Carstens, Paul Mackerras, H. Peter Anvin, linux-s390,
	linux-sh, x86, Alexander Graf, Christian Borntraeger, Ingo Molnar,
	Avi Kivity, Russell King, Xiantao Zhang, Ohad Ben-Cohen,
	Fenghua Yu, Arnd Bergmann, Chris Metcalf, John Stultz, kvm-ppc,
	Thomas Gleixner, linux-omap, linux-arm-kernel, Tony Luck,
	kvm-ia64, Marcelo Tosatti, linux-kernel, Ralf Baechle, Paul Mundt,
	Martin Schwidefsky, linux390, Andrew Morton, linuxppc-dev

virtio has been so far used only in the context of virtualization,
and the virtio Kconfig was sourced directly by the relevant arch
Kconfigs when VIRTUALIZATION was selected.

Now that we start using virtio for inter-processor communications,
we need to source the virtio Kconfig outside of the virtualization
scope too.

Moreover, some architectures might use virtio for both virtualization
and inter-processor communications, so directly sourcing virtio
might yield unexpected results due to conflicting selections.

The simple solution offered by this patch is to always source virtio's
Kconfig in drivers/Kconfig, and remove it from the appropriate arch
Kconfigs. Additionally, a virtio menu entry has been added so virtio
drivers don't show up in the general drivers menu.

This way anyone can use virtio, though it's arguably less accessible
(and neat!) for virtualization users now.

Note: some architectures (mips and sh) seem to have a VIRTUALIZATION
menu merely for sourcing virtio's Kconfig, so that menu is removed too.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
The motivation behind this patch is: https://lkml.org/lkml/2011/6/21/47

If the general approach is agreed upon, we can either merge the patch
independently, or add it to the AMP patch set.

 arch/ia64/kvm/Kconfig    |    1 -
 arch/mips/Kconfig        |   16 ----------------
 arch/powerpc/kvm/Kconfig |    1 -
 arch/s390/kvm/Kconfig    |    1 -
 arch/sh/Kconfig          |   16 ----------------
 arch/tile/kvm/Kconfig    |    1 -
 arch/x86/kvm/Kconfig     |    1 -
 drivers/Kconfig          |    2 ++
 drivers/virtio/Kconfig   |    3 +++
 9 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig
index fa4d1e5..9806e55 100644
--- a/arch/ia64/kvm/Kconfig
+++ b/arch/ia64/kvm/Kconfig
@@ -49,6 +49,5 @@ config KVM_INTEL
 	  extensions.
 
 source drivers/vhost/Kconfig
-source drivers/virtio/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 653da62..a627a2c 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2489,20 +2489,4 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
-menuconfig VIRTUALIZATION
-	bool "Virtualization"
-	default n
-	---help---
-	  Say Y here to get to see options for using your Linux host to run other
-	  operating systems inside virtual machines (guests).
-	  This option alone does not add any kernel code.
-
-	  If you say N, all options in this submenu will be skipped and disabled.
-
-if VIRTUALIZATION
-
-source drivers/virtio/Kconfig
-
-endif # VIRTUALIZATION
-
 source "lib/Kconfig"
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index b7baff7..105b691 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -99,6 +99,5 @@ config KVM_E500
 	  If unsure, say N.
 
 source drivers/vhost/Kconfig
-source drivers/virtio/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig
index f66a1bd..a216341 100644
--- a/arch/s390/kvm/Kconfig
+++ b/arch/s390/kvm/Kconfig
@@ -37,6 +37,5 @@ config KVM
 # OK, it's a little counter-intuitive to do this, but it puts it neatly under
 # the virtualization menu.
 source drivers/vhost/Kconfig
-source drivers/virtio/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index bbdeb48..748ff19 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -897,20 +897,4 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
-menuconfig VIRTUALIZATION
-	bool "Virtualization"
-	default n
-	---help---
-	  Say Y here to get to see options for using your Linux host to run other
-	  operating systems inside virtual machines (guests).
-	  This option alone does not add any kernel code.
-
-	  If you say N, all options in this submenu will be skipped and disabled.
-
-if VIRTUALIZATION
-
-source drivers/virtio/Kconfig
-
-endif # VIRTUALIZATION
-
 source "lib/Kconfig"
diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig
index b88f9c0..669fcdb 100644
--- a/arch/tile/kvm/Kconfig
+++ b/arch/tile/kvm/Kconfig
@@ -33,6 +33,5 @@ config KVM
 	  If unsure, say N.
 
 source drivers/vhost/Kconfig
-source drivers/virtio/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 50f6364..65cf823 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -76,6 +76,5 @@ config KVM_MMU_AUDIT
 # the virtualization menu.
 source drivers/vhost/Kconfig
 source drivers/lguest/Kconfig
-source drivers/virtio/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 3bb154d..795218e 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -114,6 +114,8 @@ source "drivers/uio/Kconfig"
 
 source "drivers/vlynq/Kconfig"
 
+source "drivers/virtio/Kconfig"
+
 source "drivers/xen/Kconfig"
 
 source "drivers/staging/Kconfig"
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 3dd6294..57e493b 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -7,6 +7,8 @@ config VIRTIO_RING
 	tristate
 	depends on VIRTIO
 
+menu "Virtio drivers"
+
 config VIRTIO_PCI
 	tristate "PCI driver for virtio devices (EXPERIMENTAL)"
 	depends on PCI && EXPERIMENTAL
@@ -33,3 +35,4 @@ config VIRTIO_BALLOON
 
 	 If unsure, say M.
 
+endmenu
-- 
1.7.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox