[patch 0/3] cell bug fixes for 2.6.22

[patch 0/3] cell bug fixes for 2.6.22

[Arnd Bergmann]

These are some small fixes that I'd still like to get into 2.6.22.
The first one still needs an Acked-by: benh, the other two have
been reviewed on the list already.

	Arnd <><

--

[patch 1/3] powerpc: fix pci_setup_phb_io_dynamic for pci_iomap

[Arnd Bergmann]

From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
We had a problem on a system with only dynamically allocated
PCI buses (using of_pci_phb_driver) in combination with libata.
This setup ended up having no "primary" phb, which means
that pci_io_base never got initialized and all IO port
numbers are 64 bit numbers, which is larger than the
PIO_MASK limit.

Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-2.6/arch/powerpc/kernel/of_platform.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/of_platform.c
+++ linux-2.6/arch/powerpc/kernel/of_platform.c
@@ -433,7 +433,7 @@ static int __devinit of_pci_phb_probe(st
 	 * Note also that we don't do ISA, this will also be fixed with a
 	 * more massive rework.
 	 */
-	pci_setup_phb_io(phb, 0);
+	pci_setup_phb_io(phb, pci_io_base == 0);
 
 	/* Init pci_dn data structures */
 	pci_devs_phb_init_dynamic(phb);

--

[patch 2/3] cbe_cpufreq: limit frequency via cpufreq notifier chain

[Arnd Bergmann]

From: Thomas Renninger <trenn@suse.de>
and get rid of cpufreq_set_policy call that caused a build
failure due interfering commits

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>

---
 arch/powerpc/platforms/cell/cbe_cpufreq.c |   28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

Index: linux-2.6/arch/powerpc/platforms/cell/cbe_cpufreq.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ linux-2.6/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -67,6 +67,7 @@ static u64 MIC_Slow_Next_Timer_table[] =
 	0x00003FC000000000ull,
 };
 
+static unsigned int pmi_frequency_limit = 0;
 /*
  * hardware specific functions
  */
@@ -164,7 +165,6 @@ static int set_pmode(int cpu, unsigned i
 
 static void cbe_cpufreq_handle_pmi(struct of_device *dev, pmi_message_t pmi_msg)
 {
-	struct cpufreq_policy policy;
 	u8 cpu;
 	u8 cbe_pmode_new;
 
@@ -173,15 +173,27 @@ static void cbe_cpufreq_handle_pmi(struc
 	cpu = cbe_node_to_cpu(pmi_msg.data1);
 	cbe_pmode_new = pmi_msg.data2;
 
-	cpufreq_get_policy(&policy, cpu);
+	pmi_frequency_limit = cbe_freqs[cbe_pmode_new].frequency;
 
-	policy.max = min(policy.max, cbe_freqs[cbe_pmode_new].frequency);
-	policy.min = min(policy.min, policy.max);
+	pr_debug("cbe_handle_pmi: max freq=%d\n", pmi_frequency_limit);
+}
+
+static int pmi_notifier(struct notifier_block *nb,
+				       unsigned long event, void *data)
+{
+	struct cpufreq_policy *policy = data;
 
-	pr_debug("cbe_handle_pmi: new policy.min=%d policy.max=%d\n", policy.min, policy.max);
-	cpufreq_set_policy(&policy);
+	if (event != CPUFREQ_INCOMPATIBLE)
+		return 0;
+
+	cpufreq_verify_within_limits(policy, 0, pmi_frequency_limit);
+	return 0;
 }
 
+static struct notifier_block pmi_notifier_block = {
+	.notifier_call = pmi_notifier,
+};
+
 static struct pmi_handler cbe_pmi_handler = {
 	.type			= PMI_TYPE_FREQ_CHANGE,
 	.handle_pmi_message	= cbe_cpufreq_handle_pmi,
@@ -238,12 +250,21 @@ static int cbe_cpufreq_cpu_init(struct c
 
 	cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
 
+	if (pmi_dev) {
+		/* frequency might get limited later, initialize limit with max_freq */
+		pmi_frequency_limit = max_freq;
+		cpufreq_register_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
+	}
+
 	/* this ensures that policy->cpuinfo_min and policy->cpuinfo_max are set correctly */
 	return cpufreq_frequency_table_cpuinfo(policy, cbe_freqs);
 }
 
 static int cbe_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 {
+	if (pmi_dev)
+		cpufreq_unregister_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
+
 	cpufreq_frequency_table_put_attr(policy->cpu);
 	return 0;
 }

--

[patch 3/3] scc_sio: fix link failure

[Arnd Bergmann]

From: Christoph Hellwig <hch@lst.de>
scc_sio.o should only be built if the txx9 serial driver is actually built
into the kernel.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>

Index: linux-2.6/arch/powerpc/platforms/celleb/Makefile
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/celleb/Makefile
+++ linux-2.6/arch/powerpc/platforms/celleb/Makefile
@@ -4,5 +4,5 @@ obj-y				+= interrupt.o iommu.o setup.o 
 
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_PPC_UDBG_BEAT)	+= udbg_beat.o
-obj-$(CONFIG_HAS_TXX9_SERIAL)	+= scc_sio.o
+obj-$(CONFIG_SERIAL_TXX9)	+= scc_sio.o
 obj-$(CONFIG_SPU_BASE)		+= spu_priv1.o

--

Re: [patch 1/3] powerpc: fix pci_setup_phb_io_dynamic for pci_iomap

[Benjamin Herrenschmidt]

On Mon, 2007-06-04 at 20:14 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> We had a problem on a system with only dynamically allocated
> PCI buses (using of_pci_phb_driver) in combination with libata.
> This setup ended up having no "primary" phb, which means
> that pci_io_base never got initialized and all IO port
> numbers are 64 bit numbers, which is larger than the
> PIO_MASK limit.

That's for 2.6.22 ? I wonder if a better fix is to initialize
pci_io_base statically and clear it in iSeries code... didn't I post a
patch for that a while ago ?

Ben.

Re: [patch 1/3] powerpc: fix pci_setup_phb_io_dynamic for pci_iomap

[Arnd Bergmann]

On Tuesday 05 June 2007, Benjamin Herrenschmidt wrote:
> 
> On Mon, 2007-06-04 at 20:14 +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> > We had a problem on a system with only dynamically allocated
> > PCI buses (using of_pci_phb_driver) in combination with libata.
> > This setup ended up having no "primary" phb, which means
> > that pci_io_base never got initialized and all IO port
> > numbers are 64 bit numbers, which is larger than the
> > PIO_MASK limit.
> 
> That's for 2.6.22 ? I wonder if a better fix is to initialize
> pci_io_base statically and clear it in iSeries code... didn't I post a
> patch for that a while ago ?

We talked about this, but I can't find a patch from you that did this.
Either way should be fine, mine may be slightly less invasive, while
statically initializing pci_io_base is what you also do in your
rewrite of that code for 2.6.23.

	Arnd <><

Re: [patch 1/3] powerpc: fix pci_setup_phb_io_dynamic for pci_iomap

[Benjamin Herrenschmidt]

On Mon, 2007-06-04 at 20:14 +0200, Arnd Bergmann wrote:
> plain text document attachment (pci-iomap-fix-2.diff)
> From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> We had a problem on a system with only dynamically allocated
> PCI buses (using of_pci_phb_driver) in combination with libata.
> This setup ended up having no "primary" phb, which means
> that pci_io_base never got initialized and all IO port
> numbers are 64 bit numbers, which is larger than the
> PIO_MASK limit.
> 
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Paulus, that's a bug fix, should probably go into 2.6.22

> ---
> Index: linux-2.6/arch/powerpc/kernel/of_platform.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/of_platform.c
> +++ linux-2.6/arch/powerpc/kernel/of_platform.c
> @@ -433,7 +433,7 @@ static int __devinit of_pci_phb_probe(st
>  	 * Note also that we don't do ISA, this will also be fixed with a
>  	 * more massive rework.
>  	 */
> -	pci_setup_phb_io(phb, 0);
> +	pci_setup_phb_io(phb, pci_io_base == 0);
>  
>  	/* Init pci_dn data structures */
>  	pci_devs_phb_init_dynamic(phb);
> 
> --