LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [patch 4/9] powerpc/cell/cpufreq: add spu aware cpufreq governor
From: arnd @ 2008-07-15 19:51 UTC (permalink / raw)
  To: benh, cbe-oss-dev, linuxppc-dev; +Cc: Christian Krafft, Jeremy Kerr, Dave Jones
In-Reply-To: <20080715195139.316677337@arndb.de>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7043 bytes --]

From: Christian Krafft <krafft@de.ibm.com>

This patch adds a cpufreq governor that takes the number of running spus
into account. It's very similar to the ondemand governor, but not as complex.
Instead of hacking spu load into the ondemand governor it might be easier to
have cpufreq accepting multiple governors per cpu in future.
Don't know if this is the right way, but it would keep the governors simple.

Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dave Jones <davej@redhat.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
---
 arch/powerpc/platforms/cell/Kconfig             |    9 +
 arch/powerpc/platforms/cell/Makefile            |    1 +
 arch/powerpc/platforms/cell/cpufreq_spudemand.c |  184 +++++++++++++++++++++++
 3 files changed, 194 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/platforms/cell/cpufreq_spudemand.c

diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index 3959fcf..6ee571f 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -107,6 +107,15 @@ config CBE_CPUFREQ_PMI
 	  processor will not only be able to run at lower speed,
 	  but also at lower core voltage.
 
+config CBE_CPUFREQ_SPU_GOVERNOR
+	tristate "CBE frequency scaling based on SPU usage"
+	depends on SPU_FS && CPU_FREQ
+	default m
+	help
+	  This governor checks for spu usage to adjust the cpu frequency.
+	  If no spu is running on a given cpu, that cpu will be throttled to
+	  the minimal possible frequency.
+
 endmenu
 
 config OPROFILE_CELL
diff --git a/arch/powerpc/platforms/cell/Makefile b/arch/powerpc/platforms/cell/Makefile
index c2a7e4e..7fcf09b 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CBE_THERM)			+= cbe_thermal.o
 obj-$(CONFIG_CBE_CPUFREQ_PMI)		+= cbe_cpufreq_pmi.o
 obj-$(CONFIG_CBE_CPUFREQ)		+= cbe-cpufreq.o
 cbe-cpufreq-y				+= cbe_cpufreq_pervasive.o cbe_cpufreq.o
+obj-$(CONFIG_CBE_CPUFREQ_SPU_GOVERNOR)	+= cpufreq_spudemand.o
 
 ifeq ($(CONFIG_SMP),y)
 obj-$(CONFIG_PPC_CELL_NATIVE)		+= smp.o
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
new file mode 100644
index 0000000..a3c6c01
--- /dev/null
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -0,0 +1,184 @@
+/*
+ * spu aware cpufreq governor for the cell processor
+ *
+ * © Copyright IBM Corporation 2006-2008
+ *
+ * Author: Christian Krafft <krafft@de.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/cpufreq.h>
+#include <linux/sched.h>
+#include <linux/timer.h>
+#include <linux/workqueue.h>
+#include <asm/atomic.h>
+#include <asm/machdep.h>
+#include <asm/spu.h>
+
+#define POLL_TIME	100000		/* in µs */
+#define EXP		753		/* exp(-1) in fixed-point */
+
+struct spu_gov_info_struct {
+	unsigned long busy_spus;	/* fixed-point */
+	struct cpufreq_policy *policy;
+	struct delayed_work work;
+	unsigned int poll_int;		/* µs */
+};
+static DEFINE_PER_CPU(struct spu_gov_info_struct, spu_gov_info);
+
+static struct workqueue_struct *kspugov_wq;
+
+static int calc_freq(struct spu_gov_info_struct *info)
+{
+	int cpu;
+	int busy_spus;
+
+	cpu = info->policy->cpu;
+	busy_spus = atomic_read(&cbe_spu_info[cpu_to_node(cpu)].busy_spus);
+
+	CALC_LOAD(info->busy_spus, EXP, busy_spus * FIXED_1);
+	pr_debug("cpu %d: busy_spus=%d, info->busy_spus=%ld\n",
+			cpu, busy_spus, info->busy_spus);
+
+	return info->policy->max * info->busy_spus / FIXED_1;
+}
+
+static void spu_gov_work(struct work_struct *work)
+{
+	struct spu_gov_info_struct *info;
+	int delay;
+	unsigned long target_freq;
+
+	info = container_of(work, struct spu_gov_info_struct, work.work);
+
+	/* after cancel_delayed_work_sync we unset info->policy */
+	BUG_ON(info->policy == NULL);
+
+	target_freq = calc_freq(info);
+	__cpufreq_driver_target(info->policy, target_freq, CPUFREQ_RELATION_H);
+
+	delay = usecs_to_jiffies(info->poll_int);
+	queue_delayed_work_on(info->policy->cpu, kspugov_wq, &info->work, delay);
+}
+
+static void spu_gov_init_work(struct spu_gov_info_struct *info)
+{
+	int delay = usecs_to_jiffies(info->poll_int);
+	INIT_DELAYED_WORK_DEFERRABLE(&info->work, spu_gov_work);
+	queue_delayed_work_on(info->policy->cpu, kspugov_wq, &info->work, delay);
+}
+
+static void spu_gov_cancel_work(struct spu_gov_info_struct *info)
+{
+	cancel_delayed_work_sync(&info->work);
+}
+
+static int spu_gov_govern(struct cpufreq_policy *policy, unsigned int event)
+{
+	unsigned int cpu = policy->cpu;
+	struct spu_gov_info_struct *info, *affected_info;
+	int i;
+	int ret = 0;
+
+	info = &per_cpu(spu_gov_info, cpu);
+
+	switch (event) {
+	case CPUFREQ_GOV_START:
+		if (!cpu_online(cpu)) {
+			printk(KERN_ERR "cpu %d is not online\n", cpu);
+			ret = -EINVAL;
+			break;
+		}
+
+		if (!policy->cur) {
+			printk(KERN_ERR "no cpu specified in policy\n");
+			ret = -EINVAL;
+			break;
+		}
+
+		/* initialize spu_gov_info for all affected cpus */
+		for_each_cpu_mask(i, policy->cpus) {
+			affected_info = &per_cpu(spu_gov_info, i);
+			affected_info->policy = policy;
+		}
+
+		info->poll_int = POLL_TIME;
+
+		/* setup timer */
+		spu_gov_init_work(info);
+
+		break;
+
+	case CPUFREQ_GOV_STOP:
+		/* cancel timer */
+		spu_gov_cancel_work(info);
+
+		/* clean spu_gov_info for all affected cpus */
+		for_each_cpu_mask (i, policy->cpus) {
+			info = &per_cpu(spu_gov_info, i);
+			info->policy = NULL;
+		}
+
+		break;
+	}
+
+	return ret;
+}
+
+static struct cpufreq_governor spu_governor = {
+	.name = "spudemand",
+	.governor = spu_gov_govern,
+	.owner = THIS_MODULE,
+};
+
+/*
+ * module init and destoy
+ */
+
+static int __init spu_gov_init(void)
+{
+	int ret;
+
+	kspugov_wq = create_workqueue("kspugov");
+	if (!kspugov_wq) {
+		printk(KERN_ERR "creation of kspugov failed\n");
+		ret = -EFAULT;
+		goto out;
+	}
+
+	ret = cpufreq_register_governor(&spu_governor);
+	if (ret) {
+		printk(KERN_ERR "registration of governor failed\n");
+		destroy_workqueue(kspugov_wq);
+		goto out;
+	}
+out:
+	return ret;
+}
+
+static void __exit spu_gov_exit(void)
+{
+	cpufreq_unregister_governor(&spu_governor);
+	destroy_workqueue(kspugov_wq);
+}
+
+
+module_init(spu_gov_init);
+module_exit(spu_gov_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Christian Krafft <krafft@de.ibm.com>");
+
-- 
1.5.4.3

-- 

^ permalink raw reply related

* [patch 3/9] powerpc/axonram: enable partitioning of the Axons DDR2 DIMMs
From: arnd @ 2008-07-15 19:51 UTC (permalink / raw)
  To: benh, cbe-oss-dev, linuxppc-dev; +Cc: Maxim Shchetynin
In-Reply-To: <20080715195139.316677337@arndb.de>

From: Maxim Shchetynin <maxim@de.ibm.com>

DDR2 memory DIMMs on the Axon could be accessed only as one partition
when using file system drivers which are using the direct_access() method.
This patch enables for such file system drivers to access Axon's DDR2 memory
even if it is splitted in several partitions.

Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/powerpc/sysdev/axonram.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 9b639ed..9e105cb 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -150,7 +150,10 @@ axon_ram_direct_access(struct block_device *device, sector_t sector,
 	struct axon_ram_bank *bank = device->bd_disk->private_data;
 	loff_t offset;
 
-	offset = sector << AXON_RAM_SECTOR_SHIFT;
+	offset = sector;
+	if (device->bd_part != NULL)
+		offset += device->bd_part->start_sect;
+	offset <<= AXON_RAM_SECTOR_SHIFT;
 	if (offset >= bank->size) {
 		dev_err(&bank->device->dev, "Access outside of address space\n");
 		return -ERANGE;
-- 
1.5.4.3

-- 

^ permalink raw reply related

* [patch 2/9] powerpc/axonram: use only one block device major number
From: arnd @ 2008-07-15 19:51 UTC (permalink / raw)
  To: benh, cbe-oss-dev, linuxppc-dev; +Cc: Maxim Shchetynin
In-Reply-To: <20080715195139.316677337@arndb.de>

From: Maxim Shchetynin <maxim@de.ibm.com>

Axonram module registers one block device for each DDR2 DIMM found
on a system. This means that each DDR2 DIMM becomes its own block device
major number. This patch lets axonram module to register the only one
block device for all DDR2 DIMMs which also spares kernel resources.

Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/powerpc/sysdev/axonram.c |   23 +++++++++++++++--------
 1 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 7f59188..9b639ed 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -57,6 +57,8 @@
 #define AXON_RAM_SECTOR_SIZE		1 << AXON_RAM_SECTOR_SHIFT
 #define AXON_RAM_IRQ_FLAGS		IRQF_SHARED | IRQF_TRIGGER_RISING
 
+static int azfs_major, azfs_minor;
+
 struct axon_ram_bank {
 	struct of_device	*device;
 	struct gendisk		*disk;
@@ -227,19 +229,14 @@ axon_ram_probe(struct of_device *device, const struct of_device_id *device_id)
 		goto failed;
 	}
 
-	bank->disk->first_minor = 0;
+	bank->disk->major = azfs_major;
+	bank->disk->first_minor = azfs_minor;
 	bank->disk->fops = &axon_ram_devops;
 	bank->disk->private_data = bank;
 	bank->disk->driverfs_dev = &device->dev;
 
 	sprintf(bank->disk->disk_name, "%s%d",
 			AXON_RAM_DEVICE_NAME, axon_ram_bank_id);
-	bank->disk->major = register_blkdev(0, bank->disk->disk_name);
-	if (bank->disk->major < 0) {
-		dev_err(&device->dev, "Cannot register block device\n");
-		rc = -EFAULT;
-		goto failed;
-	}
 
 	bank->disk->queue = blk_alloc_queue(GFP_KERNEL);
 	if (bank->disk->queue == NULL) {
@@ -276,6 +273,8 @@ axon_ram_probe(struct of_device *device, const struct of_device_id *device_id)
 		goto failed;
 	}
 
+	azfs_minor += bank->disk->minors;
+
 	return 0;
 
 failed:
@@ -310,7 +309,6 @@ axon_ram_remove(struct of_device *device)
 
 	device_remove_file(&device->dev, &dev_attr_ecc);
 	free_irq(bank->irq_id, device);
-	unregister_blkdev(bank->disk->major, bank->disk->disk_name);
 	del_gendisk(bank->disk);
 	iounmap((void __iomem *) bank->io_addr);
 	kfree(bank);
@@ -341,6 +339,14 @@ static struct of_platform_driver axon_ram_driver = {
 static int __init
 axon_ram_init(void)
 {
+	azfs_major = register_blkdev(azfs_major, AXON_RAM_DEVICE_NAME);
+	if (azfs_major < 0) {
+		printk(KERN_ERR "%s cannot become block device major number\n",
+				AXON_RAM_MODULE_NAME);
+		return -EFAULT;
+	}
+	azfs_minor = 0;
+
 	return of_register_platform_driver(&axon_ram_driver);
 }
 
@@ -351,6 +357,7 @@ static void __exit
 axon_ram_exit(void)
 {
 	of_unregister_platform_driver(&axon_ram_driver);
+	unregister_blkdev(azfs_major, AXON_RAM_DEVICE_NAME);
 }
 
 module_init(axon_ram_init);
-- 
1.5.4.3

-- 

^ permalink raw reply related

* [patch 1/9] powerpc/cell/edac: log a syndrome code in case of correctable error
From: arnd @ 2008-07-15 19:51 UTC (permalink / raw)
  To: benh, cbe-oss-dev, linuxppc-dev; +Cc: Maxim Shchetynin
In-Reply-To: <20080715195139.316677337@arndb.de>

From: Maxim Shchetynin <maxim@de.ibm.com>

If correctable error occurs the syndrome code was logged as 0. This patch
lets EDAC to log a correct syndrome code to make problem investigation
easier.

Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/edac/cell_edac.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/cell_edac.c b/drivers/edac/cell_edac.c
index b54112f..0e024fe 100644
--- a/drivers/edac/cell_edac.c
+++ b/drivers/edac/cell_edac.c
@@ -33,7 +33,7 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci, int chan, u64 ar)
 {
 	struct cell_edac_priv		*priv = mci->pvt_info;
 	struct csrow_info		*csrow = &mci->csrows[0];
-	unsigned long			address, pfn, offset;
+	unsigned long			address, pfn, offset, syndrome;
 
 	dev_dbg(mci->dev, "ECC CE err on node %d, channel %d, ar = 0x%016lx\n",
 		priv->node, chan, ar);
@@ -44,10 +44,11 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci, int chan, u64 ar)
 		address = (address << 1) | chan;
 	pfn = address >> PAGE_SHIFT;
 	offset = address & ~PAGE_MASK;
+	syndrome = (ar & 0x000000001fe00000ul) >> 21;
 
 	/* TODO: Decoding of the error addresss */
 	edac_mc_handle_ce(mci, csrow->first_page + pfn, offset,
-			  0, 0, chan, "");
+			  syndrome, 0, chan, "");
 }
 
 static void cell_edac_count_ue(struct mem_ctl_info *mci, int chan, u64 ar)
-- 
1.5.4.3

-- 

^ permalink raw reply related

* [patch 0/9] Cell patches for 2.6.27, version 2
From: arnd @ 2008-07-15 19:51 UTC (permalink / raw)
  To: benh, cbe-oss-dev, linuxppc-dev

Hi Ben,

These are the remaining patches I have lined up for 2.6.27.
Thanks for including the others already. There were a few
comments in the last round that I hope all got addressed now.

I'm not sure about the final two patches for the IOMMU, I think
you wanted to investigate the situation more, but I haven't
seen an update from you any more. I'm convinced going to weak
ordering is the right move for the cell IOMMU, and even if it
is not, it will not break anything on current machines because
the firmware already overrides this setting.

I have left the copy_to_user in AZFS in place, I think we
need to follow up on this again, to either document that
copy_fromto_user needs to be able to work on uncached memory,
or to do an extra copy, but I think this should not hold up
the AZFS merge. All other comments for it have been addressed.

You can pull from the usual location at

master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git cell-next

	Arnd <><

--

^ permalink raw reply

* Re: 82xx performance
From: Arnd Bergmann @ 2008-07-15 19:50 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04AE6877@ismail.innsys.innovsys.com>

On Tuesday 15 July 2008, Rune Torgersen wrote:
> Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
> test I did is almost identical (within 1%) of what the arch/powerpc
> 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
> (I'll see if I can find an exact version, as I think my ppc port can be
> compiled for all versions from 2.6.18 to 25)

You probably already know git-bisect, but if you don't, you should
definitely give it a try. It's the best tool to find which patch
exactly broke your performance.

	Arnd <><

^ permalink raw reply

* DTC: libfdt Install Woes
From: Jon Loeliger @ 2008-07-15 19:26 UTC (permalink / raw)
  To: linuxppc-dev@ozlabs.org

David,

Somewhat recently, the DTC commit 6a6c972cdf9e
"dtc: Clean up included Makefile fragments"
removed this line

    LIBFDT_INCLUDES = fdt.h libfdt.h

from the libfdt/Makefile.libfdt.  As a result,
the standalone "make install" is onw failing.

We could put that line back, or remove the
top-level Makefile install target that is
trying to use this definition.

I'm not sure which direction you want to head here.

Thanks,
jdl

^ permalink raw reply

* Re: Videomode 800x480
From: Anatolij Gustschin @ 2008-07-15 18:29 UTC (permalink / raw)
  To: Alex_SYS; +Cc: linuxppc-embedded
In-Reply-To: <18470632.post@talk.nabble.com>

Hello,

Alex_SYS wrote:
> Hello, I have the problem that I need a Framebuffer resolution 800x480!
> Since now I have filled the fb_info, var and fix Structs!
> But there was the problem with the resolution!
> I have found out that the problem is the videomode!
> In modedb there is unfortunately no 800x480 Videomode, and I have tried my
> own 800x480 Struct, but the Kernel does`t want my settings (I tried to
> change an 800x600 to 800x480 only by changing yres to 480).
> Can someone tell me please a working fb_videomode struct for 800x480?

Values for 800x480 fb_videomode depend on the TFT-panel that
you are using. Without the spec of this panel it is hard to guess.
It is also hard to guess the value for .pixclock as we do not know
if internal or external clock is used as the source for display
reference clock. What is the value of GDC DCM0 register (at
offset 0x1fd0000 or 0x1fd0100 from the GDC base)?

Try something like this:
.xres = 800
.yres = 480
.pixclock = 40000
.left_margin = 86
.right_margin = 42
.upper_margin = 33
.lower_margin = 10
.hsync_len = 128
.vsync_len = 2

> The syncs are setted up by U-Boot .

then you probably should retrieve proper values for fb_videomode
from display controller registers set up by U-Boot. If you do not
have the spec for your panel, it is the way to go. Consult the
GDC manual (Display control registers section) and
Documentation/fb/framebuffer.txt in the linux source tree.

Best regards,
Anatolij

^ permalink raw reply

* RE: 82xx performance
From: Rune Torgersen @ 2008-07-15 18:25 UTC (permalink / raw)
  To: Arnd Bergmann, linuxppc-dev
In-Reply-To: <200807142244.07450.arnd@arndb.de>

> * Maybe there is a kernel version that supports your hardware in both
> arch/ppc/ and arch/powerpc. In that case, you could see if=20
> the platform
> change had an impact.

Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
test I did is almost identical (within 1%) of what the arch/powerpc
2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
(I'll see if I can find an exact version, as I think my ppc port can be
compiled for all versions from 2.6.18 to 25)

And running oprofile didn't help much, as it seems not to have been able
to figure out what in the kernel got called. (the Freescale 82xx dcoes
not have hw performance registers)

^ permalink raw reply

* RE: 82xx performance
From: Rune Torgersen @ 2008-07-15 18:12 UTC (permalink / raw)
  To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <9dc3e1e709ad1aa47ae4c73f18c4d5e0@bga.com>

> 9919_unit  Linux 2.6.25       powerpc-linux-gnu  434    32    32 =20
> > 1.0000 1
> > 9919_unit  Linux 2.6.18       powerpc-linux-gnu  445    32    32 =20
> > 1.0100 1
>=20
> Hmm, processor MHz is off by 11/445

I noticed that.

> And memory latency is off 13/500.
>=20
> That sounds like it will be 16/666.
>=20
> Are you using the same board and the same firmware?

Yes. Same board, same firmware, same filesystem, just booted with
different kernels.

>=20
> If so, look at /proc/cpuinfo and/or the boot log to see what
> frequency linux thinks the processor is running at.  It sounds
> like someone introduced or fixed a rounding error error calculating
> the timebase frequency for your board.

2.6.18 /proc/cpuinfo
processor       : 0
cpu             : G2_LE
revision        : 1.4 (pvr 8082 2014)
bogomips        : 296.96
chipset         : 8250
vendor          : Innovative Systems LLC
machine         : AP Gold

mem size                : 0x40000000
console baud            : 115200

core clock      : 447 MHz
CPM  clock      : 298 MHz
bus  clock      : 99 MHz


2.6.25 /proc/cpuinfo
processor       : 0
cpu             : G2_LE
clock           : 447.897600MHz
revision        : 1.4 (pvr 8082 2014)
bogomips        : 49.53
timebase        : 24883200
platform        : Innovative Systems ApMax


> Please try the sleep test: sleep for 100 seconds, and time with
> either a stopwatch or another system.  I think you will find they
> take different amounts of time, and all the results need to be scaled.
> You might be able to see it reading the hardware clock.

Sleep 100 takes excactly 100 seconds on both kernels (verified with
stopwatch and external ntp server)

^ permalink raw reply

* Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Anton Vorontsov @ 2008-07-15 17:48 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <9340606A-7A87-4475-A133-81F5B59C7960@kernel.crashing.org>

On Tue, Jul 15, 2008 at 11:23:42AM -0500, Kumar Gala wrote:
>>>
>> Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in
>> my patch:
>>
>> commit 91993d56812fd09b6cccea12d3c83df623cb0ea6
>> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Date:   Fri Jul 4 20:53:28 2008 +0400
>>
>>    powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
>>
>>    This patch adds few bindings for the new drivers to be submitted  
>> through
>>    the appropriate maintainers.
>>
>>    Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> diff --git a/Documentation/powerpc/device-tree/fsl/mcu- 
>> mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu- 
>> mpc8349emit
>> new file mode 100644
>> index 0000000..0f76633
>> --- /dev/null
>> +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt
>> ....
>
> Rebased the tree and fixed it.  Can you look over the files and make  
> sure everything looks ok.  (I'm partially concerned about the QE usb  
> node).

Yes, everything looks fine. b-w-of specified old QE USB bindings,
and no single driver actually used them.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* Re: GPIO drivers, other patches?
From: Anton Vorontsov @ 2008-07-15 17:42 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <20080715160048.GA31615@polina.dev.rtsoft.ru>

On Tue, Jul 15, 2008 at 08:00:48PM +0400, Anton Vorontsov wrote:
> On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote:
> > Anton,
> >
> > I think I've gotten most of the patches from you, 
> 
> Yes, much thanks!
> 
> > but I know there are  
> > few I've lost.  Can you just repost any patches that aren't in my  
> > powerpc-next tree.

While testing the tree in run-time found that this patch is missing:

[PATCH 3/4] powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC
http://patchwork.ozlabs.org/linuxppc/patch?id=18915

Without this patch rtc will fail to probe on MPC8610HPCD:

rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc_cmos: probe of rtc_cmos failed with error -38


Did you deliberately hold off this patch, i.e. should I ask Benjamin
to take this through his tree?

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Kumar Gala @ 2008-07-15 16:17 UTC (permalink / raw)
  To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080715161053.GA9356@polina.dev.rtsoft.ru>

>>
> Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in
> my patch:
>
> commit 91993d56812fd09b6cccea12d3c83df623cb0ea6
> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date:   Fri Jul 4 20:53:28 2008 +0400
>
>    powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
>
>    This patch adds few bindings for the new drivers to be submitted  
> through
>    the appropriate maintainers.
>
>    Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> diff --git a/Documentation/powerpc/device-tree/fsl/mcu- 
> mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu- 
> mpc8349emit
> new file mode 100644
> index 0000000..0f76633
> --- /dev/null
> +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt
> ....

duh.  will fix it up.

- k

^ permalink raw reply

* Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Kumar Gala @ 2008-07-15 16:23 UTC (permalink / raw)
  To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080715161053.GA9356@polina.dev.rtsoft.ru>

>>
> Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in
> my patch:
>
> commit 91993d56812fd09b6cccea12d3c83df623cb0ea6
> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date:   Fri Jul 4 20:53:28 2008 +0400
>
>    powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
>
>    This patch adds few bindings for the new drivers to be submitted  
> through
>    the appropriate maintainers.
>
>    Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> diff --git a/Documentation/powerpc/device-tree/fsl/mcu- 
> mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu- 
> mpc8349emit
> new file mode 100644
> index 0000000..0f76633
> --- /dev/null
> +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt
> ....

Rebased the tree and fixed it.  Can you look over the files and make  
sure everything looks ok.  (I'm partially concerned about the QE usb  
node).

- k

^ permalink raw reply

* Videomode 800x480
From: Alex_SYS @ 2008-07-15 17:24 UTC (permalink / raw)
  To: linuxppc-embedded


Hello, I have the problem that I need a Framebuffer resolution 800x480!
Since now I have filled the fb_info, var and fix Structs!
But there was the problem with the resolution!
I have found out that the problem is the videomode!
In modedb there is unfortunately no 800x480 Videomode, and I have tried my
own 800x480 Struct, but the Kernel does`t want my settings (I tried to
change an 800x600 to 800x480 only by changing yres to 480).
Can someone tell me please a working fb_videomode struct for 800x480?
The syncs are setted up by U-Boot .

Thank you very much
-- 
View this message in context: http://www.nabble.com/Videomode-800x480-tp18470632p18470632.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Please Help me for generating the download.bit image
From: Naresh Bhat @ 2008-07-15 17:13 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Hi All,

While generating the "linux_system.bit" for my ML403 board I am getting this
error

/bin/sh: line 1:  6954 Aborted                 bitgen -w -f bitgen.ut
system_linux
make: *** [implementation/system_linux.bit] Error 134

Done!

can anybody tell why I am getting this error? Please help me on this
issue....-:(

-- 

Naresh Bhat

[-- Attachment #2: Type: text/html, Size: 520 bytes --]

^ permalink raw reply

* Re: [PATCH 1/2] [POWERPC] 86xx: suspend support
From: Anton Vorontsov @ 2008-07-15 16:49 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi, Jason Jin
In-Reply-To: <899616AF-593D-4B7A-A64E-3F15934CE6CF@kernel.crashing.org>

On Tue, Jul 15, 2008 at 11:16:14AM -0500, Kumar Gala wrote:
>
> On Jun 6, 2008, at 2:24 PM, Anton Vorontsov wrote:
>
>> This patch adds suspend (standby, not suspend-to-ram) support for  
>> MPC86xx
>> processors.
>>
>> In standby mode MPC86xx is able to wakeup only upon external  
>> interrupts
>> (including sreset).
>>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> arch/powerpc/Kconfig                          |    2 +-
>> arch/powerpc/platforms/86xx/Makefile          |    1 +
>> arch/powerpc/platforms/86xx/mpc86xx_suspend.c |   92 ++++++++++++++++ 
>> +++++++++
>> 3 files changed, 94 insertions(+), 1 deletions(-)
>> create mode 100644 arch/powerpc/platforms/86xx/mpc86xx_suspend.c
>
> I'd like to understand how much PM support these patches really add w/ 
> regards to the work Scott's done for 83xx PM.

This support provides "sleep" mode, i.e. almost all internal core
functions are off, some peripherals could be turned off, but sysclk
must be preserved. Upon wakeup CPU continues execution where it was
put to sleep. This is also called standby mode.

This patch does not implement "deep sleep" (suspend-to-ram) mode yet.
Deep sleep can save more power: CPU can be turned off completely (except
SDRAM -- it must still receive refresh cycles).

But deep sleep is also more tricky to implement.. During deep sleep CPU
losing all track of execution and state, thus upon wakeup CPU starts
execution of the firmware, so the firmware should be also aware of deep
sleep capability.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* Re: [PATCH 1/2] [POWERPC] 86xx: suspend support
From: Kumar Gala @ 2008-07-15 16:16 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: Scott Wood, linuxppc-dev, Timur Tabi, Jason Jin
In-Reply-To: <20080606192443.GA20132@polina.dev.rtsoft.ru>


On Jun 6, 2008, at 2:24 PM, Anton Vorontsov wrote:

> This patch adds suspend (standby, not suspend-to-ram) support for  
> MPC86xx
> processors.
>
> In standby mode MPC86xx is able to wakeup only upon external  
> interrupts
> (including sreset).
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/Kconfig                          |    2 +-
> arch/powerpc/platforms/86xx/Makefile          |    1 +
> arch/powerpc/platforms/86xx/mpc86xx_suspend.c |   92 ++++++++++++++++ 
> +++++++++
> 3 files changed, 94 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/platforms/86xx/mpc86xx_suspend.c

I'd like to understand how much PM support these patches really add w/ 
regards to the work Scott's done for 83xx PM.

- k

^ permalink raw reply

* Re: 2.6.26 does not boot on Pegasos
From: Jon Smirl @ 2008-07-15 16:15 UTC (permalink / raw)
  To: Matt Sealey; +Cc: linuxppc-dev list
In-Reply-To: <487CC1F5.5090706@genesi-usa.com>

On 7/15/08, Matt Sealey <matt@genesi-usa.com> wrote:
> If you built this kernel yourself, you need to do it from a system with
>  an up-to-date binutils (2.18) otherwise, it does this.
>
>  If you got it from somewhere (like a distribution) then please tell us
>  where, as there are some other troubles with load-base location for
>  Fedora and so on...

Is it hard to put a check into the kernel make system to look for
binutils 2.17 and refuse to build with a nice error message? I poked
around in the makefile but I'm not 100% sure of how it works.

>
>  --
>  Matt Sealey <matt@genesi-usa.com>
>  Genesi, Manager, Developer Relations
>
>
>  Gabriel Paubert wrote:
>
> >        Hi,
> >
> > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> > The last message I have is:
> > gunzip (0xffffffff <----- some more hex digits)
> >
> > The configuration has been created from a working 2.6.25 one with
> > make oldconfig and answering N to new config options.
> >
> > Anybody has seen this or do I have to start digging deeper?
> >
> >        Regards,
> >        Gabriel
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>  _______________________________________________
>  Linuxppc-dev mailing list
>  Linuxppc-dev@ozlabs.org
>  https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [PATCH v2] powerpc: Fix a bunch of sparse warnings in the qe_lib
From: Kumar Gala @ 2008-07-15 16:15 UTC (permalink / raw)
  To: Andy Fleming; +Cc: linuxppc-dev, timur.tabi
In-Reply-To: <1210184384-28425-1-git-send-email-afleming@freescale.com>


On May 7, 2008, at 1:19 PM, Andy Fleming wrote:

> Mostly having to do with not marking things __iomem.  And some failure
> to use appropriate accessors to read MMIO regs.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/sysdev/qe_lib/qe.c       |    6 +++---
> arch/powerpc/sysdev/qe_lib/ucc.c      |    6 +++---
> arch/powerpc/sysdev/qe_lib/ucc_fast.c |   16 ++++++++--------
> include/asm-powerpc/ucc_fast.h        |    8 ++++----
> 4 files changed, 18 insertions(+), 18 deletions(-)

applied.

- k

^ permalink raw reply

* Re: [PATCH v2.6.26] powerpc: Add support for multiple gfar mdio interfaces
From: Kumar Gala @ 2008-07-15 16:15 UTC (permalink / raw)
  To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <1209751430-25656-1-git-send-email-afleming@freescale.com>


On May 2, 2008, at 1:03 PM, Andy Fleming wrote:

> The old code assumed there was only one, but the 8572 actually has 3.
>
> Also, our usual id, 0xe0024520, gets resolved to -1 somewhere, and  
> this was
> preventing the multiple buses from having different ids.  So we only  
> keep
> the low 20 bits, which have the interesting info, anyway.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c |   84 +++++++++++++++++ 
> +----------------------
> 1 files changed, 38 insertions(+), 46 deletions(-)

applied.

- k

^ permalink raw reply

* Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Anton Vorontsov @ 2008-07-15 16:10 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C3A1E950-3D5F-4172-90B6-1566D4A70B7C@kernel.crashing.org>

On Tue, Jul 15, 2008 at 08:21:38AM -0500, Kumar Gala wrote:
>
> On Jul 4, 2008, at 11:53 AM, Anton Vorontsov wrote:
>
>> This patch adds few bindings for the new drivers to be submitted  
>> through
>> the appropriate maintainers.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>>
>> Updated to decrypt MCU, and to split the bindings into appropriate  
>> files.
>>
>> .../powerpc/device-tree/fsl/mcu-mpc8349emitx.txt   |   17 +++++++++
>> Documentation/powerpc/device-tree/fsl/qe/usb.txt   |   37 +++++++++++ 
>> +++++++++
>> Documentation/powerpc/device-tree/fsl/upm-nand.txt |   28 +++++++++++ 
>> ++++
>> Documentation/powerpc/device-tree/gpio/led.txt     |   15 ++++++++
>> 4 files changed, 97 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/powerpc/device-tree/fsl/mcu- 
>> mpc8349emitx.txt
>> create mode 100644 Documentation/powerpc/device-tree/fsl/qe/usb.txt
>> create mode 100644 Documentation/powerpc/device-tree/fsl/upm-nand.txt
>> create mode 100644 Documentation/powerpc/device-tree/gpio/led.txt
>
> applied.

Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in
my patch:

commit 91993d56812fd09b6cccea12d3c83df623cb0ea6
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date:   Fri Jul 4 20:53:28 2008 +0400

    powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
    
    This patch adds few bindings for the new drivers to be submitted through
    the appropriate maintainers.
    
    Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

diff --git a/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emit
new file mode 100644
index 0000000..0f76633
--- /dev/null
+++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt
....

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* Re: GPIO drivers, other patches?
From: Kumar Gala @ 2008-07-15 16:09 UTC (permalink / raw)
  To: avorontsov; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <20080715160048.GA31615@polina.dev.rtsoft.ru>


On Jul 15, 2008, at 11:00 AM, Anton Vorontsov wrote:

> On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote:
>> Anton,
>>
>> I think I've gotten most of the patches from you,
>
> Yes, much thanks!
>
>> but I know there are
>> few I've lost.  Can you just repost any patches that aren't in my
>> powerpc-next tree.
>
> Only this minor patch is missing:
>
> [PATCH v3] powerpc/83xx: update mpc83xx_defconfig to support  
> MPC8360E-RDK
> http://patchwork.ozlabs.org/linuxppc/patch?id=18903

This one I'll hold off on until we update defconfigs after an -rc or  
two.

> There are also last two patches I need to rework a bit (to be in
> compliance with latest power management work done by Scott Wood):
>
> [PATCH 1/2] [POWERPC] 86xx: suspend support
> http://patchwork.ozlabs.org/linuxppc/patch?id=18836
>
> [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add wakeup-on-sw9 support
> http://patchwork.ozlabs.org/linuxppc/patch?id=18837
>
> I'll resubmit them today or tomorrow. (Though, I'll appreciate if you
> will look into these two, maybe you'll have any comments I can fix
> before resubmitting).

I want to hold off on these two patches.  I'd like to understand how  
the function in the larger 8xxx PM world.  I've applied Scott's 83xx  
PM patches for sleep and clearly we are doing a lot more work than on  
86xx.

- k

^ permalink raw reply

* Re: 2.6.26 does not boot on Pegasos
From: Gabriel Paubert @ 2008-07-15 15:59 UTC (permalink / raw)
  To: Matt Sealey; +Cc: linuxppc-dev list
In-Reply-To: <487CC1F5.5090706@genesi-usa.com>

On Tue, Jul 15, 2008 at 04:27:49PM +0100, Matt Sealey wrote:
> If you built this kernel yourself, you need to do it from a system with
> an up-to-date binutils (2.18) otherwise, it does this.
> 

Thanks, this is likely the problem. The distribution is Debian stable 
with all security udates but the binutils are still 2.17. I was also 
wondering why the zImage was exploding from 2 to 5MB and why it spent
so much time in gzip at the end of a build.

Trying to add Lenny source does not help, bummer. Aptitude fails 
with an error message like "Dynamic MMap ran out of room".

	Regards,
	Gabriel

^ permalink raw reply

* Re: GPIO drivers, other patches?
From: Anton Vorontsov @ 2008-07-15 16:00 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <AB4393B8-8578-4AFA-B23A-048F86A9A24D@kernel.crashing.org>

On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote:
> Anton,
>
> I think I've gotten most of the patches from you, 

Yes, much thanks!

> but I know there are  
> few I've lost.  Can you just repost any patches that aren't in my  
> powerpc-next tree.

Only this minor patch is missing:

[PATCH v3] powerpc/83xx: update mpc83xx_defconfig to support MPC8360E-RDK
http://patchwork.ozlabs.org/linuxppc/patch?id=18903


There are also last two patches I need to rework a bit (to be in
compliance with latest power management work done by Scott Wood):

[PATCH 1/2] [POWERPC] 86xx: suspend support
http://patchwork.ozlabs.org/linuxppc/patch?id=18836

[PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add wakeup-on-sw9 support
http://patchwork.ozlabs.org/linuxppc/patch?id=18837

I'll resubmit them today or tomorrow. (Though, I'll appreciate if you
will look into these two, maybe you'll have any comments I can fix
before resubmitting).

Thanks again,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply


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