* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Michael Ellerman @ 2009-09-15 13:21 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253016701.5506.73.camel@laptop>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote:
> > This patchset contains the offline state driver implemented for
> > pSeries. For pSeries, we define three available_hotplug_states. They are:
> >
> > online: The processor is online.
> >
> > offline: This is the the default behaviour when the cpu is offlined
> > even in the absense of this driver. The CPU would call make an
> > rtas_stop_self() call and hand over the CPU back to the resource pool,
> > thereby effectively deallocating that vCPU from the LPAR.
> > NOTE: This would result in a configuration change to the LPAR
> > which is visible to the outside world.
> >
> > inactive: This cedes the vCPU to the hypervisor with a cede latency
> > specifier value 2.
> > NOTE: This option does not result in a configuration change
> > and the vCPU would be still entitled to the LPAR to which it earlier
> > belong to.
> >
> > Any feedback on the patchset will be immensely valuable.
>
> I still think its a layering violation... its the hypervisor manager
> that should be bothered in what state an off-lined cpu is in.
Yeah it probably is a layering violation, but when has that stopped us
before :)
Is it anticipated that this will be useful on platforms other than
pseries?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] dynamic logical partitioning infrastructure
From: Nathan Fontenot @ 2009-09-15 14:15 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AAE8BDE.3090002@linux.vnet.ibm.com>
Brian King wrote:
> Nathan Fontenot wrote:
>> +#include <linux/kernel.h>
>> +#include <linux/kref.h>
>> +#include <linux/notifier.h>
>> +#include <linux/proc_fs.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include <asm/prom.h>
>> +#include <asm/machdep.h>
>> +#include <asm/uaccess.h>
>> +#include <asm/rtas.h>
>> +#include <asm/pSeries_reconfig.h>
>> +
>> +#define CFG_CONN_WORK_SIZE 4096
>> +static char workarea[CFG_CONN_WORK_SIZE];
>> +spinlock_t workarea_lock;
>
> This can be:
>
> static DEFINE_SPINLOCK(workarea_lock);
>
> Then you can get rid of the runtime initializer.
Good catch, I will fix it in the updated patches.
>
>> +
>> +int release_drc(u32 drc_index)
>> +{
>> + int dr_status, rc;
>> +
>> + rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
>> + DR_ENTITY_SENSE, drc_index);
>> + if (rc || dr_status != DR_ENTITY_PRESENT)
>> + return -1;
>> +
>> + rc = rtas_set_indicator(ISOLATION_STATE, drc_index, ISOLATE);
>> + if (rc)
>> + return -1;
>> +
>> + rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
>> + if (rc) {
>> + rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
>> + return -1;
>> + }
>
> Is there a better return value here that might be more descriptive than -1?
Yes, I could return the rtas error code to the user to allow the caller to
evaluate it if they wanted to. For what I am doing I am only concerned with
success/failure so I did not deal with returning anything other than -1.
I'll update the next patch to return the rtas error for failures and 0
for success.
>
>
>> +
>> + return 0;
>> +}
>> +
>> +static int pseries_dlpar_init(void)
>> +{
>> + spin_lock_init(&workarea_lock);
>> +
>> + if (!machine_is(pseries))
>> + return 0;
>
> What's the point of this if check if you return 0 either way?
Yes, it seems a bit odd here, but in patches later in this series I
add additional initialization steps after the machine_is() check
such that it makes sense to bail out here if the check fails.
>
>> +
>> + return 0;
>> +}
>> +__initcall(pseries_dlpar_init);
>
>
>> Index: powerpc/arch/powerpc/platforms/pseries/reconfig.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/platforms/pseries/reconfig.c 2009-09-11
>> 12:43:39.000000000 -0500
>> +++ powerpc/arch/powerpc/platforms/pseries/reconfig.c 2009-09-11
>> 12:51:52.000000000 -0500
>> @@ -95,7 +95,7 @@
>> return parent;
>> }
>>
>> -static BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
>> +struct blocking_notifier_head pSeries_reconfig_chain =
>> BLOCKING_NOTIFIER_INIT(pSeries_reconfig_chain);
>
> Can't this just be?
>
> BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
>
I think I tried this and was having issues, I don't remember what they
were though. I will try to fix this in the updated patch.
-Nathan Fontenot
^ permalink raw reply
* RFC: delete UART current-speed from 4xx DTS?
From: Paul Gortmaker @ 2009-09-15 14:31 UTC (permalink / raw)
To: linuxppc-dev, jwboyer
One of the guys here was getting a messed up console on a bamboo board
(on linux boot), which he traced to the fact that the default dts has a
9600 baudrate coded into it (board was running 115k2, not 9600). Either
deleting the line, or replacing the 9600 with zero fixed the problem.
Looking at the Fsl boards, it seems that 99% of them don't list any
current-speed at all. I'm willing to whip up a patch to delete them
from the various boards, but I thought I'd check 1st to see if there was
some other reasoning/input. I suppose one could argue that u-boot
should be replacing the 9600 with 115k2 on the fly, but if the explicit
specification isn't helping anyone, then it probably just makes sense to
delete them anyway, I figured.
Here is the subset of boards I was considering deleting the lines from:
bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts
sequoia.dts taishan.dts walnut.dts yosemite.dts
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH 2/5] move of_drconf_cell definition to prom.h
From: Brian King @ 2009-09-15 14:38 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AAABD37.2050205@austin.ibm.com>
Nathan Fontenot wrote:
> Move the definition of the of_drconf_cell struct from numa.c to prom.h.
> This
> is needed so that we can parse the ibm,dynamic-memory device-tree property
> when DLPAR adding and removing memory.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
> ---
>
> Index: powerpc/arch/powerpc/include/asm/prom.h
> ===================================================================
> --- powerpc.orig/arch/powerpc/include/asm/prom.h 2009-09-11
> 12:43:39.000000000 -0500
> +++ powerpc/arch/powerpc/include/asm/prom.h 2009-09-11
> 12:52:11.000000000 -0500
> @@ -349,6 +349,18 @@
> */
> extern void __iomem *of_iomap(struct device_node *device, int index);
>
> +struct of_drconf_cell {
> + u64 base_addr;
> + u32 drc_index;
> + u32 reserved;
> + u32 aa_index;
> + u32 flags;
> +};
Might as well fix this up to use a tab instead of spaces for the indentation
if you are moving it.
> +
> +#define DRCONF_MEM_ASSIGNED 0x00000008
> +#define DRCONF_MEM_AI_INVALID 0x00000040
> +#define DRCONF_MEM_RESERVED 0x00000080
> +
> /*
> * NB: This is here while we transition from using asm/prom.h
> * to linux/of.h
> Index: powerpc/arch/powerpc/mm/numa.c
> ===================================================================
> --- powerpc.orig/arch/powerpc/mm/numa.c 2009-09-11 12:43:39.000000000
> -0500
> +++ powerpc/arch/powerpc/mm/numa.c 2009-09-11 12:52:11.000000000 -0500
> @@ -296,18 +296,6 @@
> return result;
> }
>
> -struct of_drconf_cell {
> - u64 base_addr;
> - u32 drc_index;
> - u32 reserved;
> - u32 aa_index;
> - u32 flags;
> -};
> -
> -#define DRCONF_MEM_ASSIGNED 0x00000008
> -#define DRCONF_MEM_AI_INVALID 0x00000040
> -#define DRCONF_MEM_RESERVED 0x00000080
> -
> /*
> * Read the next lmb list entry from the ibm,dynamic-memory property
> * and return the information in the provided of_drconf_cell structure.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 5/5] kernel handling of CPU DLPAR
From: Brian King @ 2009-09-15 14:48 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AAABDF5.4090604@austin.ibm.com>
Nathan Fontenot wrote:
> +static ssize_t cpu_probe_store(struct class *class, const char *buf,
> + size_t count)
> +{
> + struct device_node *dn;
> + u32 drc_index;
> + char *cpu_name;
> + int rc;
> +
> + drc_index = simple_strtoull(buf, NULL, 0);
Can just use simple_strtoul here instead.
> + if (!drc_index)
> + return -EINVAL;
> +
> + rc = acquire_drc(drc_index);
> + if (rc)
> + return rc;
> +
> + dn = configure_connector(drc_index);
> + if (!dn) {
> + release_drc(drc_index);
> + return rc;
> + }
> +
> + /* fixup dn name */
> + cpu_name = kzalloc(strlen(dn->full_name) + strlen("/cpus/") + 1,
> + GFP_KERNEL);
> + sprintf(cpu_name, "/cpus/%s", dn->full_name);
> + kfree(dn->full_name);
> + dn->full_name = cpu_name;
> +
> + rc = add_device_tree_nodes(dn);
> + if (rc)
> + release_drc(drc_index);
> +
> + return rc ? rc : count;
> +}
> +
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v3 1/3] pSeries: cede latency specifier helper function.
From: Daniel Walker @ 2009-09-15 14:45 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: Peter Zijlstra, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <20090915120701.20523.94109.stgit@sofia.in.ibm.com>
On Tue, 2009-09-15 at 17:37 +0530, Gautham R Shenoy wrote:
> // Used to pass parms from the OS to PLIC for SetAsrAndRfid
> u64 saved_gpr3; // Saved GPR3 x20-x27
> u64 saved_gpr4; // Saved GPR4 x28-x2F
> - u64 saved_gpr5; // Saved GPR5 x30-x37
> + union {
> + u64 saved_gpr5; // Saved GPR5 x30-x37
> + struct {
> + u8 cede_latency_hint; // x30
> + u8 reserved[7]; // x31-x36
> + } fields;
> + } gpr5_dword;
> +
>
> u8 dtl_enable_mask; // Dispatch Trace Log mask x38-x38
> u8 donate_dedicated_cpu; // Donate dedicated CPU cycles x39-x39
Could you drop the C99 style comments (use /* */ instead)? If you run
checkpatch on this it will error on these lines..
Daniel
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Balbir Singh @ 2009-09-15 14:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253016701.5506.73.camel@laptop>
* Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-09-15 14:11:41]:
> On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote:
> > This patchset contains the offline state driver implemented for
> > pSeries. For pSeries, we define three available_hotplug_states. They are:
> >
> > online: The processor is online.
> >
> > offline: This is the the default behaviour when the cpu is offlined
> > even in the absense of this driver. The CPU would call make an
> > rtas_stop_self() call and hand over the CPU back to the resource pool,
> > thereby effectively deallocating that vCPU from the LPAR.
> > NOTE: This would result in a configuration change to the LPAR
> > which is visible to the outside world.
> >
> > inactive: This cedes the vCPU to the hypervisor with a cede latency
> > specifier value 2.
> > NOTE: This option does not result in a configuration change
> > and the vCPU would be still entitled to the LPAR to which it earlier
> > belong to.
> >
> > Any feedback on the patchset will be immensely valuable.
>
> I still think its a layering violation... its the hypervisor manager
> that should be bothered in what state an off-lined cpu is in.
>
>From a design standpoint where we stand today is
1. A cede indicates that the CPU is no longer needed and can be
reassigned (remember we do dedicated CPU partitions in power)
2. What this patch is trying to do is to say "We don't need the
CPU, but please don't reassign, put it to sleep"
We work the same way with the hypervisor, that applications work with
the OS today, by providing madvise and other hints.
--
Balbir
^ permalink raw reply
* Re: RFC: delete UART current-speed from 4xx DTS?
From: Josh Boyer @ 2009-09-15 15:32 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <20090915143135.GA7015@windriver.com>
On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
>One of the guys here was getting a messed up console on a bamboo board
>(on linux boot), which he traced to the fact that the default dts has a
>9600 baudrate coded into it (board was running 115k2, not 9600). Either
>deleting the line, or replacing the 9600 with zero fixed the problem.
Once booted, was there a valid current-speed property in /proc/device-tree
for the serial node? I'm curious if U-Boot created it, or if the kernel
just used whatever baud was present already.
When I did the bamboo port a while ago, I recall having issues with either
a missing clock-frequency or current-speed (or both perhaps) and the bootloader
on the board was the original PIBS. It might have been an issue with PIBS
but I'm guessing the rest of the 4xx boards copied from either Ebony or
Bamboo in their ports and hence contain that property.
>Looking at the Fsl boards, it seems that 99% of them don't list any
>current-speed at all. I'm willing to whip up a patch to delete them
I think 99% of them use U-Boot, which should fix things up either way.
>from the various boards, but I thought I'd check 1st to see if there was
>some other reasoning/input. I suppose one could argue that u-boot
>should be replacing the 9600 with 115k2 on the fly, but if the explicit
>specification isn't helping anyone, then it probably just makes sense to
>delete them anyway, I figured.
Yeah, that's probably valid. I'd be happy to test on the set of boards I
have.
>Here is the subset of boards I was considering deleting the lines from:
>
> bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts
> sequoia.dts taishan.dts walnut.dts yosemite.dts
I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's
a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few
of the 405 boards I have as well.
It's easy enough for me to whip up a patch, and since I'll be testing either
way I'd be happy to do that if you'd like.
josh
^ permalink raw reply
* Hang in inflate_dynamic() mpc8321
From: Kumar G @ 2009-09-15 16:01 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]
Hi All,
Iam working on the new board bringup of linux ppc image on 2.6.24 using the
powerpc mpc832x. I used the file system image (based on the initrd ram disk
image), dtb file(generated by the dtc compiler for our mpc832x_rdb.dts) and
the kernel powepc compiled.
Iam facing a hang up in the booting in the call inflate_dynamic() from the
gunzip() function. Initially I suspected it could be RAM issues, and I
performed the simple RAM test (mtest) from the bootloader and it went
through succesfully.
Below is the log message observed in the system booting stuck at
"checking if image is initramfs..."
Log messages :
---------------------
Booting image at 00200000 ...
Image Name: Linux-2.6.24
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 808788 Bytes = 789.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01000000 ...
Image Name: TESTIMAGE
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1066209 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using the fdt at 0x400000
Loading Ramdisk to 03ea0000, end 03fa44e1 ... OK
Using MPC832x RDB machine description
Linux version 2.6.24 (test@test-desktop) (gcc version 4.2.1 (Sourcery G++
Lite 4.2-82)) #39 Fri Sep 4 13:04:50 IST 2009
Found initrd at 0xc3ea0000:0xc3fa44e1
console [udbg0] enabled
setup_arch: bootmem
mpc832x_rdb_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 16384
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: root=/dev/ram ramdisk_size=200000 rw ip=10.0.0.2:10
.0.0.1:10.0.0.1:255.0.0.0:Test:eth1:off console=t
tyS0,115200
IPIC (128 IRQ sources) at fdefd700
PID hash table entries: 256 (order: 8, 1024 bytes)
clocksource: timebase mult[7800001] shift[22] registered
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 62068k/65536k available (1592k kernel code, 3400k reserved, 88k
data, 60k bss, 112k init)
Mount-cache hash table entries: 512
SCSI subsystem initialized
checking if image is initramfs...
Please let me know what could be the problem.
Thanks in advance.
Regards,
kumar
[-- Attachment #2: Type: text/html, Size: 2929 bytes --]
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Linus Torvalds @ 2009-09-15 16:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Ingo Molnar, Linux Kernel list,
FUJITA Tomonori
In-Reply-To: <1252999835.8375.205.camel@pasglop>
On Tue, 15 Sep 2009, Benjamin Herrenschmidt wrote:
>
> So I don't know at this stage how to generate a "clean" pull request ...
It's rare, for but future reference, what you can do is to just do a
merge in a temporary branch, and get it that way.
'git shortlog' should have worked, though. It's only the 'diff' that is
based on the direct difference between two end-points, rather than based
on working with intersections of sets of commits.
Maybe the scripts use 'origin...master' or something for the shortlog, and
then the merge-base thing will confuse it? Haven't looked.
> In any case, the tree is still there waiting for you to pull. It seems
> to merge cleanly tonight though I haven't yet got a chance to test the
> result much.
It got a conflict with the AGP merge, but I fixed it up in what _seemed_
to be the obvious manner. But somebody should check out the resulting
drivers/char/agp/uninorth-agp.c file.
Linus
^ permalink raw reply
* Driver for using MPC8572's eTSEC1&2 in 16b encoded FIFO Mode?
From: Christopher Best @ 2009-09-15 18:37 UTC (permalink / raw)
To: linuxppc-dev
On the MPC8572, eTSEC1 and eTSEC2 can be configured to jointly operate in 16-bit encoded FIFO mode. Is there currently a Linux driver for interfacing with this FIFO mode?
Thanks,
Christopher
^ permalink raw reply
* Re: RFC: delete UART current-speed from 4xx DTS?
From: Paul Gortmaker @ 2009-09-15 19:32 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090915153220.GG12372@zod.rchland.ibm.com>
[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote:
> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
> >One of the guys here was getting a messed up console on a bamboo board
I meant to say Yosemite board (and hence u-boot), sorry for that. It
gives garbage up until the udbg -> ttyS0 handover, at which point the
console=ttyS0,115200 fixes things.
> >(on linux boot), which he traced to the fact that the default dts has a
> >9600 baudrate coded into it (board was running 115k2, not 9600). Either
> >deleting the line, or replacing the 9600 with zero fixed the problem.
>
> Once booted, was there a valid current-speed property in /proc/device-tree
> for the serial node? I'm curious if U-Boot created it, or if the kernel
> just used whatever baud was present already.
Had to go back to get this info; it turns out there is a valid prop in
all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600).
>
> When I did the bamboo port a while ago, I recall having issues with either
> a missing clock-frequency or current-speed (or both perhaps) and the bootloader
> on the board was the original PIBS. It might have been an issue with PIBS
> but I'm guessing the rest of the 4xx boards copied from either Ebony or
> Bamboo in their ports and hence contain that property.
Right - so there could still perhaps be the same issue with PIBS/bamboo
present that you saw earlier (given my inability to keep board names
straight)
>
> >Looking at the Fsl boards, it seems that 99% of them don't list any
> >current-speed at all. I'm willing to whip up a patch to delete them
>
> I think 99% of them use U-Boot, which should fix things up either way.
This is the interesting part -- being a yosemite (u-boot), I would have
thought so as well. I've not looked at the u-boot code, but it may only
add a current-speed if there isn't one yet. At least that is what the
behaviour tends to indicate. Board is running u-boot 1.3.3 so what we
are seeing here may not reflect what current u-boot code is doing
anyway...
>
> >from the various boards, but I thought I'd check 1st to see if there was
> >some other reasoning/input. I suppose one could argue that u-boot
> >should be replacing the 9600 with 115k2 on the fly, but if the explicit
> >specification isn't helping anyone, then it probably just makes sense to
> >delete them anyway, I figured.
>
> Yeah, that's probably valid. I'd be happy to test on the set of boards I
> have.
>
> >Here is the subset of boards I was considering deleting the lines from:
> >
> > bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts
> > sequoia.dts taishan.dts walnut.dts yosemite.dts
>
> I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's
> a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few
> of the 405 boards I have as well.
>
> It's easy enough for me to whip up a patch, and since I'll be testing either
> way I'd be happy to do that if you'd like.
Sure -- the testing effort will be greater than the time to make the
patch, so you doing coverage on all those would be great. I think I've
probably only got easy immediate access to a PIBS/bamboo at the moment.
We already know the yosemite is OK with the change, so that is one less
to test.
Thanks,
Paul.
>
> josh
^ permalink raw reply
* Re: RFC: delete UART current-speed from 4xx DTS?
From: Josh Boyer @ 2009-09-15 20:02 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <20090915193205.GA8115@windriver.com>
On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote:
>[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote:
>
>> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
>> >One of the guys here was getting a messed up console on a bamboo board
>
>I meant to say Yosemite board (and hence u-boot), sorry for that. It
>gives garbage up until the udbg -> ttyS0 handover, at which point the
>console=ttyS0,115200 fixes things.
Ok.
>> >(on linux boot), which he traced to the fact that the default dts has a
>> >9600 baudrate coded into it (board was running 115k2, not 9600). Either
>> >deleting the line, or replacing the 9600 with zero fixed the problem.
>>
>> Once booted, was there a valid current-speed property in /proc/device-tree
>> for the serial node? I'm curious if U-Boot created it, or if the kernel
>> just used whatever baud was present already.
>
>Had to go back to get this info; it turns out there is a valid prop in
>all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600).
Sorry, that was after you removed the property in the DTS entirely, or setting
it to 0, or just using the existing DTS as-is? I should have phrased my
question better, but I think I answered it myself already.
In my brief test with Sequoia and Bamboo, I removed the current-speed property
entirely and once booted there was no property in the serial node, which is
what I would expect for the old version of U-Boot on these boards. The good
news is that it seems to work fine :).
>> When I did the bamboo port a while ago, I recall having issues with either
>> a missing clock-frequency or current-speed (or both perhaps) and the bootloader
>> on the board was the original PIBS. It might have been an issue with PIBS
>> but I'm guessing the rest of the 4xx boards copied from either Ebony or
>> Bamboo in their ports and hence contain that property.
>
>Right - so there could still perhaps be the same issue with PIBS/bamboo
>present that you saw earlier (given my inability to keep board names
>straight)
OK. I'll be sure to test PIBS.
>
>>
>> >Looking at the Fsl boards, it seems that 99% of them don't list any
>> >current-speed at all. I'm willing to whip up a patch to delete them
>>
>> I think 99% of them use U-Boot, which should fix things up either way.
>
>This is the interesting part -- being a yosemite (u-boot), I would have
>thought so as well. I've not looked at the u-boot code, but it may only
>add a current-speed if there isn't one yet. At least that is what the
>behaviour tends to indicate. Board is running u-boot 1.3.3 so what we
>are seeing here may not reflect what current u-boot code is doing
>anyway...
Yeah, 1.3.3 is pretty old. However, I _think_ the kernel will just leave
the baud rate alone entirely without a current-speed property and without
console=ttyS0,<baud rate>. Example:
linux:/proc/device-tree/plb/opb/serial@ef600300 # ls
clock-frequency device_type interrupts reg
compatible interrupt-parent name virtual-reg
linux:/proc/device-tree/plb/opb/serial@ef600300 # cat /proc/cmdline
rootdelay=15 root=/dev/sda1 rw ip=off
linux:/proc/device-tree/plb/opb/serial@ef600300 # uname -a
Linux linux 2.6.31 #4 Tue Sep 15 16:57:49 UTC 2009 ppc ppc ppc GNU/Linux
linux:/proc/device-tree/plb/opb/serial@ef600300 # cat /proc/cpuinfo
processor : 0
cpu : 440EP Rev. B
clock : 399.999996MHz
revision : 24.211 (pvr 4222 18d3)
bogomips : 799.99
timebase : 399999996
platform : PowerPC 44x Platform
model : amcc,bamboo
Memory : 191 MB
linux:/proc/device-tree/plb/opb/serial@ef600300 #
>> I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's
>> a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few
>> of the 405 boards I have as well.
>>
>> It's easy enough for me to whip up a patch, and since I'll be testing either
>> way I'd be happy to do that if you'd like.
>
>Sure -- the testing effort will be greater than the time to make the
>patch, so you doing coverage on all those would be great. I think I've
>probably only got easy immediate access to a PIBS/bamboo at the moment.
>We already know the yosemite is OK with the change, so that is one less
>to test.
OK, sounds good. I'll do some more testing over the next few days and post
a patch. Thanks for bringing this to my attention.
josh
^ permalink raw reply
* Re: RFC: delete UART current-speed from 4xx DTS?
From: Paul Gortmaker @ 2009-09-15 20:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090915200223.GH12372@zod.rchland.ibm.com>
[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 16:02) Josh Boyer wrote:
> On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote:
> >[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote:
> >
> >> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
> >> >One of the guys here was getting a messed up console on a bamboo board
> >
> >I meant to say Yosemite board (and hence u-boot), sorry for that. It
> >gives garbage up until the udbg -> ttyS0 handover, at which point the
> >console=ttyS0,115200 fixes things.
>
> Ok.
>
> >> >(on linux boot), which he traced to the fact that the default dts has a
> >> >9600 baudrate coded into it (board was running 115k2, not 9600). Either
> >> >deleting the line, or replacing the 9600 with zero fixed the problem.
> >>
> >> Once booted, was there a valid current-speed property in /proc/device-tree
> >> for the serial node? I'm curious if U-Boot created it, or if the kernel
> >> just used whatever baud was present already.
> >
> >Had to go back to get this info; it turns out there is a valid prop in
> >all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600).
>
> Sorry, that was after you removed the property in the DTS entirely, or setting
> it to 0, or just using the existing DTS as-is? I should have phrased my
> question better, but I think I answered it myself already.
>
> In my brief test with Sequoia and Bamboo, I removed the current-speed property
> entirely and once booted there was no property in the serial node, which is
> what I would expect for the old version of U-Boot on these boards. The good
> news is that it seems to work fine :).
Yep - and if there is a node with a current-speed that differs from what
u-boot (1.3.3) is actively using, that current-speed setting will take
precedence for early printk and also that baud will appear in the
/proc/device-tree (just to clarify on what I'd tried to convey earlier).
[...]
> >> It's easy enough for me to whip up a patch, and since I'll be testing either
> >> way I'd be happy to do that if you'd like.
> >
> >Sure -- the testing effort will be greater than the time to make the
> >patch, so you doing coverage on all those would be great. I think I've
> >probably only got easy immediate access to a PIBS/bamboo at the moment.
> >We already know the yosemite is OK with the change, so that is one less
> >to test.
>
> OK, sounds good. I'll do some more testing over the next few days and post
> a patch. Thanks for bringing this to my attention.
No problem; thanks for the quick response and volunteering to test on
the boards you have.
Paul.
>
> josh
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Geoff Levand @ 2009-09-15 21:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1252653473.8566.98.camel@pasglop>
Hi Ben,
On 09/11/2009 12:17 AM, Benjamin Herrenschmidt wrote:
> This is the powerpc batch for 2.6.32.
Will we ever get this one in...
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073567.html
-Geoff
^ permalink raw reply
* [PATCH v4 0/7] Suspend/resume support for some 83xx/85xx/86xx boards
From: Anton Vorontsov @ 2009-09-15 21:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
On Tue, Sep 15, 2009 at 01:47:36AM +0400, Anton Vorontsov wrote:
> On Mon, Sep 14, 2009 at 03:45:10PM -0500, Scott Wood wrote:
> [...]
> > >You can't request the firmware in the qe driver's ->suspend()
> > >routine necause the firmware may be on e.g. NFS filesystem or USB
> > >stick (implies having QE Ethernet or QE USB fully functional).
> >
> > Is there any way for software to read out the current firmware from
> > the device, or is it write-only?
>
> Hm, I didn't look into iram stuff that much, but seemingly I can
> read it back and save. In the end, it's just a ram that we access
> in a weird way... Let me try it.
Okay... that might sound silly, but the microcode stuff isn't needed
at all. While the QE really shuts down, its iram is preserved. I'm
not sure why it didn't work for me before, but now it does work. Heh.
Note that QE reset is still needed, it's QE microcode reload that
we don't need. I was also curious if MPC8568 QE needs reset after
sleep, so I unpacked the board and tested it. It needs the reset just
as MPC8569. I also found a paragraph in reference manual that somewhat
proves "QE turns off during sleep" behaviour.
So here is a new patch set. Changes:
- Removed QE stuff from fsl_pmc;
- New patches added:
powerpc/qe: QE also shuts down on MPC8568
powerpc/qe: Implement QE driver for handling resume on MPC85xx
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 1/7] powerpc/qe: Make qe_reset() code path safe for repeated invocation
From: Anton Vorontsov @ 2009-09-15 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
For MPC8569 CPUs we'll need to reset QE after each suspend, so make
qe_reset() code path suitable for repeated invocation, that is:
- Don't initialize rheap structures if already initialized;
- Don't allocate muram for SDMA if already allocated, just reinitialize
registers with previously allocated muram offset;
- Remove __init attributes from qe_reset() and cpm_muram_init();
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/include/asm/qe.h | 2 +-
arch/powerpc/sysdev/cpm_common.c | 5 ++++-
arch/powerpc/sysdev/qe_lib/qe.c | 12 +++++++-----
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 20c0b07..fe507ff 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -87,7 +87,7 @@ extern spinlock_t cmxgcr_lock;
/* Export QE common operations */
#ifdef CONFIG_QUICC_ENGINE
-extern void __init qe_reset(void);
+extern void qe_reset(void);
#else
static inline void qe_reset(void) {}
#endif
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index e4b6d66..9de72c9 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -72,7 +72,7 @@ static phys_addr_t muram_pbase;
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS 4
-int __init cpm_muram_init(void)
+int cpm_muram_init(void)
{
struct device_node *np;
struct resource r;
@@ -81,6 +81,9 @@ int __init cpm_muram_init(void)
int i = 0;
int ret = 0;
+ if (muram_pbase)
+ return 0;
+
spin_lock_init(&cpm_muram_lock);
/* initialize the info header */
rh_init(&cpm_muram_info, 1,
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index fff2701..1ed1a9f 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -104,7 +104,7 @@ phys_addr_t get_qe_base(void)
EXPORT_SYMBOL(get_qe_base);
-void __init qe_reset(void)
+void qe_reset(void)
{
if (qe_immr == NULL)
qe_immr = ioremap(get_qe_base(), QE_IMMAP_SIZE);
@@ -330,16 +330,18 @@ EXPORT_SYMBOL(qe_put_snum);
static int qe_sdma_init(void)
{
struct sdma __iomem *sdma = &qe_immr->sdma;
- unsigned long sdma_buf_offset;
+ static unsigned long sdma_buf_offset = (unsigned long)-ENOMEM;
if (!sdma)
return -ENODEV;
/* allocate 2 internal temporary buffers (512 bytes size each) for
* the SDMA */
- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
- if (IS_ERR_VALUE(sdma_buf_offset))
- return -ENOMEM;
+ if (IS_ERR_VALUE(sdma_buf_offset)) {
+ sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
+ if (IS_ERR_VALUE(sdma_buf_offset))
+ return -ENOMEM;
+ }
out_be32(&sdma->sdebcr, (u32) sdma_buf_offset & QE_SDEBCR_BA_MASK);
out_be32(&sdma->sdmr, (QE_SDMR_GLB_1_MSK |
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/7] powerpc/qe: QE also shuts down on MPC8568
From: Anton Vorontsov @ 2009-09-15 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
It appears that QE shuts down on all MPC85xx CPUs (i.e. MPC8568 and
MPC8569) and thus needs reset upon resume.
So modify qe_alive_during_sleep() to account that.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/include/asm/qe.h | 23 ++++++++++++++++++++++-
arch/powerpc/sysdev/qe_lib/qe.c | 13 -------------
2 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index fe507ff..0947b36 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -163,7 +163,28 @@ int qe_get_snum(void);
void qe_put_snum(u8 snum);
unsigned int qe_get_num_of_risc(void);
unsigned int qe_get_num_of_snums(void);
-int qe_alive_during_sleep(void);
+
+static inline int qe_alive_during_sleep(void)
+{
+ /*
+ * MPC8568E reference manual says:
+ *
+ * "...power down sequence waits for all I/O interfaces to become idle.
+ * In some applications this may happen eventually without actively
+ * shutting down interfaces, but most likely, software will have to
+ * take steps to shut down the eTSEC, QUICC Engine Block, and PCI
+ * interfaces before issuing the command (either the write to the core
+ * MSR[WE] as described above or writing to POWMGTCSR) to put the
+ * device into sleep state."
+ *
+ * MPC8569E reference manual has a similar paragraph.
+ */
+#ifdef CONFIG_PPC_85xx
+ return 0;
+#else
+ return 1;
+#endif
+}
/* we actually use cpm_muram implementation, define this for convenience */
#define qe_muram_init cpm_muram_init
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 1ed1a9f..4eaf2a9 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -65,19 +65,6 @@ static unsigned int qe_num_of_snum;
static phys_addr_t qebase = -1;
-int qe_alive_during_sleep(void)
-{
- static int ret = -1;
-
- if (ret != -1)
- return ret;
-
- ret = !of_find_compatible_node(NULL, NULL, "fsl,mpc8569-pmc");
-
- return ret;
-}
-EXPORT_SYMBOL(qe_alive_during_sleep);
-
phys_addr_t get_qe_base(void)
{
struct device_node *qe;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/7] powerpc/qe: Implement QE driver for handling resume on MPC85xx
From: Anton Vorontsov @ 2009-09-15 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
So far the driver is used to reset QE upon resume, which is needed on
85xx. Later we can move some QE initialization steps into probe().
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 4eaf2a9..149393c 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -27,6 +27,8 @@
#include <linux/delay.h>
#include <linux/ioport.h>
#include <linux/crc32.h>
+#include <linux/mod_devicetable.h>
+#include <linux/of_platform.h>
#include <asm/irq.h>
#include <asm/page.h>
#include <asm/pgtable.h>
@@ -647,3 +649,35 @@ unsigned int qe_get_num_of_snums(void)
return num_of_snums;
}
EXPORT_SYMBOL(qe_get_num_of_snums);
+
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx)
+static int qe_resume(struct of_device *ofdev)
+{
+ if (!qe_alive_during_sleep())
+ qe_reset();
+ return 0;
+}
+
+static int qe_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ return 0;
+}
+
+static const struct of_device_id qe_ids[] = {
+ { .compatible = "fsl,qe", },
+ { },
+};
+
+static struct of_platform_driver qe_driver = {
+ .driver.name = "fsl-qe",
+ .match_table = qe_ids,
+ .probe = qe_probe,
+ .resume = qe_resume,
+};
+
+static int __init qe_drv_init(void)
+{
+ return of_register_platform_driver(&qe_driver);
+}
+device_initcall(qe_drv_init);
+#endif /* defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx) */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/7] powerpc/85xx/86xx: Add suspend/resume support
From: Anton Vorontsov @ 2009-09-15 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
This patch adds suspend/resume support for MPC8540 and MPC8641D-
compatible CPUs. To reach sleep state, we just write the SLP bit
into the PM control and status register.
So far we don't support Deep Sleep mode as found in newer MPC85xx
CPUs (i.e. MPC8536). It can be relatively easy implemented though,
and for it we reserve 'mem' suspend type.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/Kconfig | 11 +++++-
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_pmc.c | 88 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 99 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_pmc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d00131c..a0743a7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
+ PPC_85xx || PPC_86xx
config PPC_DCR_NATIVE
bool
@@ -642,6 +643,14 @@ config FSL_PCI
select PPC_INDIRECT_PCI
select PCI_QUIRKS
+config FSL_PMC
+ bool
+ default y
+ depends on SUSPEND && (PPC_85xx || PPC_86xx)
+ help
+ Freescale MPC85xx/MPC86xx power management controller support
+ (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
+
config 4xx_SOC
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9d4b174..5642924 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
+obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
new file mode 100644
index 0000000..a7635a9
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_pmc.c
@@ -0,0 +1,88 @@
+/*
+ * Suspend/resume support
+ *
+ * Copyright 2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.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 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/suspend.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/of_platform.h>
+
+struct pmc_regs {
+ __be32 devdisr;
+ __be32 devdisr2;
+ __be32 :32;
+ __be32 :32;
+ __be32 pmcsr;
+#define PMCSR_SLP (1 << 17)
+};
+
+static struct device *pmc_dev;
+static struct pmc_regs __iomem *pmc_regs;
+
+static int pmc_suspend_enter(suspend_state_t state)
+{
+ int ret;
+
+ setbits32(&pmc_regs->pmcsr, PMCSR_SLP);
+ /* At this point, the CPU is asleep. */
+
+ /* Upon resume, wait for SLP bit to be clear. */
+ ret = spin_event_timeout((in_be32(&pmc_regs->pmcsr) & PMCSR_SLP) == 0,
+ 10000, 10) ? 0 : -ETIMEDOUT;
+ if (ret)
+ dev_err(pmc_dev, "tired waiting for SLP bit to clear\n");
+ return ret;
+}
+
+static int pmc_suspend_valid(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_STANDBY)
+ return 0;
+ return 1;
+}
+
+static struct platform_suspend_ops pmc_suspend_ops = {
+ .valid = pmc_suspend_valid,
+ .enter = pmc_suspend_enter,
+};
+
+static int pmc_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ pmc_regs = of_iomap(ofdev->node, 0);
+ if (!pmc_regs)
+ return -ENOMEM;
+
+ pmc_dev = &ofdev->dev;
+ suspend_set_ops(&pmc_suspend_ops);
+ return 0;
+}
+
+static const struct of_device_id pmc_ids[] = {
+ { .compatible = "fsl,mpc8548-pmc", },
+ { .compatible = "fsl,mpc8641d-pmc", },
+ { },
+};
+
+static struct of_platform_driver pmc_driver = {
+ .driver.name = "fsl-pmc",
+ .match_table = pmc_ids,
+ .probe = pmc_probe,
+};
+
+static int __init pmc_init(void)
+{
+ return of_register_platform_driver(&pmc_driver);
+}
+device_initcall(pmc_init);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/7] powerpc/85xx: Add power management support for MPC85xxMDS boards
From: Anton Vorontsov @ 2009-09-15 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
- Add power management controller nodes;
- Add interrupts for RTC nodes, the RTC interrupt may be used as a
wakeup source;
- Add sleep properties and sleep-nexus nodes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 119 +++++++++++++++++++----------
arch/powerpc/boot/dts/mpc8569mds.dts | 111 ++++++++++++++++++---------
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
3 files changed, 153 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 00c2bbd..6d892ba 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -40,6 +40,8 @@
i-cache-line-size = <32>; // 32 bytes
d-cache-size = <0x8000>; // L1, 32K
i-cache-size = <0x8000>; // L1, 32K
+ sleep = <&pmc 0x00008000 // core
+ &pmc 0x00004000>; // timebase
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
@@ -94,31 +96,41 @@
interrupts = <16 2>;
};
- i2c@3000 {
+ i2c-sleep-nexus {
#address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- compatible = "fsl-i2c";
- reg = <0x3000 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ sleep = <&pmc 0x00000004>;
+ ranges;
- rtc@68 {
- compatible = "dallas,ds1374";
- reg = <0x68>;
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+
+ rtc@68 {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ interrupts = <3 1>;
+ interrupt-parent = <&mpic>;
+ };
};
- };
- i2c@3100 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <1>;
- compatible = "fsl-i2c";
- reg = <0x3100 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
};
dma@21300 {
@@ -128,6 +140,8 @@
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0>;
+ sleep = <&pmc 0x00000400>;
+
dma-channel@0 {
compatible = "fsl,mpc8568-dma-channel",
"fsl,eloplus-dma-channel";
@@ -176,6 +190,7 @@
interrupt-parent = <&mpic>;
tbi-handle = <&tbi0>;
phy-handle = <&phy2>;
+ sleep = <&pmc 0x00000080>;
mdio@520 {
#address-cells = <1>;
@@ -228,6 +243,7 @@
interrupt-parent = <&mpic>;
tbi-handle = <&tbi1>;
phy-handle = <&phy3>;
+ sleep = <&pmc 0x00000040>;
mdio@520 {
#address-cells = <1>;
@@ -242,30 +258,47 @@
};
};
- serial0: serial@4500 {
- cell-index = <0>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x4500 0x100>;
- clock-frequency = <0>;
- interrupts = <42 2>;
- interrupt-parent = <&mpic>;
+ duart-sleep-nexus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ sleep = <&pmc 0x00000002>;
+ ranges;
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
};
- global-utilities@e0000 { //global utilities block
- compatible = "fsl,mpc8548-guts";
+ global-utilities@e0000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8568-guts", "fsl,mpc8548-guts";
reg = <0xe0000 0x1000>;
+ ranges = <0 0xe0000 0x1000>;
fsl,has-rstcr;
- };
- serial1: serial@4600 {
- cell-index = <1>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x4600 0x100>;
- clock-frequency = <0>;
- interrupts = <42 2>;
- interrupt-parent = <&mpic>;
+ pmc: power@70 {
+ compatible = "fsl,mpc8568-pmc",
+ "fsl,mpc8548-pmc";
+ reg = <0x70 0x20>;
+ };
};
crypto@30000 {
@@ -277,6 +310,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0xfe>;
fsl,descriptor-types-mask = <0x12b0ebf>;
+ sleep = <&pmc 0x01000000>;
};
mpic: pic@40000 {
@@ -376,6 +410,7 @@
compatible = "fsl,qe";
ranges = <0x0 0xe0080000 0x40000>;
reg = <0xe0080000 0x480>;
+ sleep = <&pmc 0x00000800>;
brg-frequency = <0>;
bus-frequency = <396000000>;
fsl,qe-num-riscs = <2>;
@@ -509,6 +544,7 @@
bus-range = <0 255>;
ranges = <0x2000000 0x0 0x80000000 0x80000000 0x0 0x20000000
0x1000000 0x0 0x0 0xe2000000 0x0 0x800000>;
+ sleep = <&pmc 0x80000000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
#size-cells = <2>;
@@ -534,6 +570,7 @@
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
0x1000000 0x0 0x0 0xe2800000 0x0 0x800000>;
+ sleep = <&pmc 0x20000000>;
clock-frequency = <33333333>;
#interrupt-cells = <1>;
#size-cells = <2>;
@@ -570,5 +607,7 @@
55 2 /* msg2_tx */
56 2 /* msg2_rx */>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x00080000 /* controller */
+ &pmc 0x00040000>; /* message unit */
};
};
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/boot/dts/mpc8569mds.dts
index 880f896..b35e62c 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -41,6 +41,8 @@
i-cache-line-size = <32>; // 32 bytes
d-cache-size = <0x8000>; // L1, 32K
i-cache-size = <0x8000>; // L1, 32K
+ sleep = <&pmc 0x00008000 // core
+ &pmc 0x00004000>; // timebase
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
@@ -59,6 +61,7 @@
reg = <0xe0005000 0x1000>;
interrupts = <19 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x08000000>;
ranges = <0x0 0x0 0xfe000000 0x02000000
0x1 0x0 0xf8000000 0x00008000
@@ -158,51 +161,69 @@
interrupts = <18 2>;
};
- i2c@3000 {
+ i2c-sleep-nexus {
#address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- compatible = "fsl-i2c";
- reg = <0x3000 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ sleep = <&pmc 0x00000004>;
+ ranges;
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+
+ rtc@68 {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ interrupts = <3 1>;
+ interrupt-parent = <&mpic>;
+ };
+ };
- rtc@68 {
- compatible = "dallas,ds1374";
- reg = <0x68>;
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
};
};
- i2c@3100 {
+ duart-sleep-nexus {
#address-cells = <1>;
- #size-cells = <0>;
- cell-index = <1>;
- compatible = "fsl-i2c";
- reg = <0x3100 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
- };
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ sleep = <&pmc 0x00000002>;
+ ranges;
- serial0: serial@4500 {
- cell-index = <0>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x4500 0x100>;
- clock-frequency = <0>;
- interrupts = <42 2>;
- interrupt-parent = <&mpic>;
- };
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
- serial1: serial@4600 {
- cell-index = <1>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x4600 0x100>;
- clock-frequency = <0>;
- interrupts = <42 2>;
- interrupt-parent = <&mpic>;
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
};
L2: l2-cache-controller@20000 {
@@ -260,6 +281,7 @@
reg = <0x2e000 0x1000>;
interrupts = <72 0x8>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x00200000>;
/* Filled in by U-Boot */
clock-frequency = <0>;
status = "disabled";
@@ -276,6 +298,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0xbfe>;
fsl,descriptor-types-mask = <0x3ab0ebf>;
+ sleep = <&pmc 0x01000000>;
};
mpic: pic@40000 {
@@ -304,9 +327,18 @@
};
global-utilities@e0000 {
- compatible = "fsl,mpc8569-guts";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8569-guts", "fsl,mpc8548-guts";
reg = <0xe0000 0x1000>;
+ ranges = <0 0xe0000 0x1000>;
fsl,has-rstcr;
+
+ pmc: power@70 {
+ compatible = "fsl,mpc8569-pmc",
+ "fsl,mpc8548-pmc";
+ reg = <0x70 0x20>;
+ };
};
par_io@e0100 {
@@ -422,6 +454,7 @@
compatible = "fsl,qe";
ranges = <0x0 0xe0080000 0x40000>;
reg = <0xe0080000 0x480>;
+ sleep = <&pmc 0x00000800>;
brg-frequency = <0>;
bus-frequency = <0>;
fsl,qe-num-riscs = <4>;
@@ -680,6 +713,7 @@
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
0x1000000 0x0 0x00000000 0xe2800000 0x0 0x00800000>;
+ sleep = <&pmc 0x20000000>;
clock-frequency = <33333333>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
@@ -710,5 +744,6 @@
55 2 /* msg2_tx */
56 2 /* msg2_rx */>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x00080000>;
};
};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 20a61d0..995ddad 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -300,6 +300,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .compatible = "fsl,qe", },
{ .compatible = "gianfar", },
{ .compatible = "fsl,rapidio-delta", },
+ { .compatible = "fsl,mpc8548-guts", },
{},
};
--
1.6.3.3
^ permalink raw reply related
* [PATCH 6/7] powerpc/86xx: Add power management support for MPC8610HPCD boards
From: Anton Vorontsov @ 2009-09-15 21:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
This patch adds needed nodes and properties to support suspend/resume
on the MPC8610HPCD boards.
There is a dedicated switch (SW9) that is used to wake up the boards.
By default the SW9 button is routed to IRQ8, but could be re-routed
(via PIXIS) to sreset.
With 'no_console_suspend' kernel command line argument specified, the
board is also able to wakeup upon serial port input.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com> [dts]
---
Documentation/powerpc/dts-bindings/fsl/board.txt | 4 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 26 ++++++++++++
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 48 ++++++++++++++++++++--
3 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt b/Documentation/powerpc/dts-bindings/fsl/board.txt
index e8b5bc2..39e9415 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -20,12 +20,16 @@ Required properities:
- compatible : should be "fsl,fpga-pixis".
- reg : should contain the address and the length of the FPPGA register
set.
+- interrupt-parent: should specify phandle for the interrupt controller.
+- interrupts : should specify event (wakeup) IRQ.
Example (MPC8610HPCD):
board-control@e8000000 {
compatible = "fsl,fpga-pixis";
reg = <0xe8000000 32>;
+ interrupt-parent = <&mpic>;
+ interrupts = <8 8>;
};
* Freescale BCSR GPIO banks
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index f468d21..9535ce6 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -35,6 +35,8 @@
i-cache-line-size = <32>;
d-cache-size = <32768>; // L1
i-cache-size = <32768>; // L1
+ sleep = <&pmc 0x00008000 0 // core
+ &pmc 0x00004000 0>; // timebase
timebase-frequency = <0>; // From uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
@@ -60,6 +62,7 @@
5 0 0xe8480000 0x00008000
6 0 0xe84c0000 0x00008000
3 0 0xe8000000 0x00000020>;
+ sleep = <&pmc 0x08000000 0>;
flash@0,0 {
compatible = "cfi-flash";
@@ -105,6 +108,8 @@
compatible = "fsl,fpga-pixis";
reg = <3 0 0x20>;
ranges = <0 3 0 0x20>;
+ interrupt-parent = <&mpic>;
+ interrupts = <8 8>;
sdcsr_pio: gpio-controller@a {
#gpio-cells = <2>;
@@ -163,6 +168,7 @@
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x00000004 0>;
dfsrr;
};
@@ -174,6 +180,7 @@
clock-frequency = <0>;
interrupts = <42 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x00000002 0>;
};
serial1: serial@4600 {
@@ -184,6 +191,7 @@
clock-frequency = <0>;
interrupts = <42 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x00000008 0>;
};
spi@7000 {
@@ -196,6 +204,7 @@
interrupt-parent = <&mpic>;
mode = "cpu";
gpios = <&sdcsr_pio 7 0>;
+ sleep = <&pmc 0x00000800 0>;
mmc-slot@0 {
compatible = "fsl,mpc8610hpcd-mmc-slot",
@@ -213,6 +222,7 @@
reg = <0x2c000 100>;
interrupts = <72 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x04000000 0>;
};
mpic: interrupt-controller@40000 {
@@ -241,9 +251,18 @@
};
global-utilities@e0000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,mpc8610-guts";
reg = <0xe0000 0x1000>;
+ ranges = <0 0xe0000 0x1000>;
fsl,has-rstcr;
+
+ pmc: power@70 {
+ compatible = "fsl,mpc8610-pmc",
+ "fsl,mpc8641d-pmc";
+ reg = <0x70 0x20>;
+ };
};
wdt@e4000 {
@@ -262,6 +281,7 @@
fsl,playback-dma = <&dma00>;
fsl,capture-dma = <&dma01>;
fsl,fifo-depth = <8>;
+ sleep = <&pmc 0 0x08000000>;
};
ssi@16100 {
@@ -271,6 +291,7 @@
interrupt-parent = <&mpic>;
interrupts = <63 2>;
fsl,fifo-depth = <8>;
+ sleep = <&pmc 0 0x04000000>;
};
dma@21300 {
@@ -280,6 +301,7 @@
cell-index = <0>;
reg = <0x21300 0x4>; /* DMA general status register */
ranges = <0x0 0x21100 0x200>;
+ sleep = <&pmc 0x00000400 0>;
dma00: dma-channel@0 {
compatible = "fsl,mpc8610-dma-channel",
@@ -322,6 +344,7 @@
cell-index = <1>;
reg = <0xc300 0x4>; /* DMA general status register */
ranges = <0x0 0xc100 0x200>;
+ sleep = <&pmc 0x00000200 0>;
dma-channel@0 {
compatible = "fsl,mpc8610-dma-channel",
@@ -369,6 +392,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xe1000000 0x0 0x00100000>;
+ sleep = <&pmc 0x80000000 0>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <24 2>;
@@ -398,6 +422,7 @@
bus-range = <1 3>;
ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xe3000000 0x0 0x00100000>;
+ sleep = <&pmc 0x40000000 0>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <26 2>;
@@ -474,6 +499,7 @@
0x0000 0 0 4 &mpic 7 1>;
interrupt-parent = <&mpic>;
interrupts = <25 2>;
+ sleep = <&pmc 0x20000000 0>;
clock-frequency = <33333333>;
};
};
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 627908a..5abe137 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -19,6 +19,7 @@
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/pci.h>
+#include <linux/interrupt.h>
#include <linux/kdev_t.h>
#include <linux/delay.h>
#include <linux/seq_file.h>
@@ -41,10 +42,46 @@
#include "mpc86xx.h"
+static struct device_node *pixis_node;
static unsigned char *pixis_bdcfg0, *pixis_arch;
+#ifdef CONFIG_SUSPEND
+static irqreturn_t mpc8610_sw9_irq(int irq, void *data)
+{
+ pr_debug("%s: PIXIS' event (sw9/wakeup) IRQ handled\n", __func__);
+ return IRQ_HANDLED;
+}
+
+static void __init mpc8610_suspend_init(void)
+{
+ int irq;
+ int ret;
+
+ if (!pixis_node)
+ return;
+
+ irq = irq_of_parse_and_map(pixis_node, 0);
+ if (!irq) {
+ pr_err("%s: can't map pixis event IRQ.\n", __func__);
+ return;
+ }
+
+ ret = request_irq(irq, mpc8610_sw9_irq, 0, "sw9/wakeup", NULL);
+ if (ret) {
+ pr_err("%s: can't request pixis event IRQ: %d\n",
+ __func__, ret);
+ irq_dispose_mapping(irq);
+ }
+
+ enable_irq_wake(irq);
+}
+#else
+static inline void mpc8610_suspend_init(void) { }
+#endif /* CONFIG_SUSPEND */
+
static struct of_device_id __initdata mpc8610_ids[] = {
{ .compatible = "fsl,mpc8610-immr", },
+ { .compatible = "fsl,mpc8610-guts", },
{ .compatible = "simple-bus", },
{ .compatible = "gianfar", },
{}
@@ -55,6 +92,9 @@ static int __init mpc8610_declare_of_platform_devices(void)
/* Firstly, register PIXIS GPIOs. */
simple_gpiochip_init("fsl,fpga-pixis-gpio-bank");
+ /* Enable wakeup on PIXIS' event IRQ. */
+ mpc8610_suspend_init();
+
/* Without this call, the SSI device driver won't get probed. */
of_platform_bus_probe(NULL, mpc8610_ids, NULL);
@@ -250,10 +290,10 @@ static void __init mpc86xx_hpcd_setup_arch(void)
diu_ops.set_sysfs_monitor_port = mpc8610hpcd_set_sysfs_monitor_port;
#endif
- np = of_find_compatible_node(NULL, NULL, "fsl,fpga-pixis");
- if (np) {
- of_address_to_resource(np, 0, &r);
- of_node_put(np);
+ pixis_node = of_find_compatible_node(NULL, NULL, "fsl,fpga-pixis");
+ if (pixis_node) {
+ of_address_to_resource(pixis_node, 0, &r);
+ of_node_put(pixis_node);
pixis = ioremap(r.start, 32);
if (!pixis) {
printk(KERN_ERR "Err: can't map FPGA cfg register!\n");
--
1.6.3.3
^ permalink raw reply related
* [PATCH 7/7] powerpc/83xx: Add power management support for MPC83xx QE boards
From: Anton Vorontsov @ 2009-09-15 21:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090915214321.GA19377@oksana.dev.rtsoft.ru>
Simply add power management controller nodes and sleep properties.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/dts/kmeter1.dts | 7 +++++++
arch/powerpc/boot/dts/mpc832x_mds.dts | 9 +++++++++
arch/powerpc/boot/dts/mpc832x_rdb.dts | 9 +++++++++
arch/powerpc/boot/dts/mpc836x_mds.dts | 9 +++++++++
arch/powerpc/boot/dts/mpc836x_rdk.dts | 9 +++++++++
5 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/dts/kmeter1.dts
index 167044f..65b8b4f 100644
--- a/arch/powerpc/boot/dts/kmeter1.dts
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -59,6 +59,13 @@
reg = <0xe0000000 0x00000200>;
bus-frequency = <0>; /* Filled in by U-Boot */
+ pmc: power@b00 {
+ compatible = "fsl,mpc8360-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 436c9c6..05ad8c9 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -79,6 +79,13 @@
reg = <0x200 0x100>;
};
+ pmc: power@b00 {
+ compatible = "fsl,mpc8323-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -163,6 +170,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x4c>;
fsl,descriptor-types-mask = <0x0122003f>;
+ sleep = <&pmc 0x03000000>;
};
ipic: pic@700 {
@@ -428,5 +436,6 @@
0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ sleep = <&pmc 0x00010000>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 9a0952f..f4fadb2 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -62,6 +62,13 @@
reg = <0x200 0x100>;
};
+ pmc: power@b00 {
+ compatible = "fsl,mpc8323-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -141,6 +148,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x4c>;
fsl,descriptor-types-mask = <0x0122003f>;
+ sleep = <&pmc 0x03000000>;
};
ipic:pic@700 {
@@ -360,5 +368,6 @@
0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ sleep = <&pmc 0x00010000>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 39ff4c8..45cfa1c 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -99,6 +99,13 @@
reg = <0x200 0x100>;
};
+ pmc: power@b00 {
+ compatible = "fsl,mpc8360-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -194,6 +201,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x7e>;
fsl,descriptor-types-mask = <0x01010ebf>;
+ sleep = <&pmc 0x03000000>;
};
ipic: pic@700 {
@@ -470,5 +478,6 @@
0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ sleep = <&pmc 0x00010000>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index 6315d6f..bdf4459 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -71,6 +71,13 @@
reg = <0x200 0x100>;
};
+ pmc: power@b00 {
+ compatible = "fsl,mpc8360-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -161,6 +168,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x7e>;
fsl,descriptor-types-mask = <0x01010ebf>;
+ sleep = <&pmc 0x03000000>;
};
ipic: interrupt-controller@700 {
@@ -455,6 +463,7 @@
0xa800 0 0 2 &ipic 20 8
0xa800 0 0 3 &ipic 21 8
0xa800 0 0 4 &ipic 18 8>;
+ sleep = <&pmc 0x00010000>;
/* filled by u-boot */
bus-range = <0 0>;
clock-frequency = <0>;
--
1.6.3.3
^ permalink raw reply related
* Re: RFC: delete UART current-speed from 4xx DTS?
From: Benjamin Herrenschmidt @ 2009-09-15 21:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <20090915153220.GG12372@zod.rchland.ibm.com>
On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote:
> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
> >One of the guys here was getting a messed up console on a bamboo board
> >(on linux boot), which he traced to the fact that the default dts has a
> >9600 baudrate coded into it (board was running 115k2, not 9600). Either
> >deleting the line, or replacing the 9600 with zero fixed the problem.
>
> Once booted, was there a valid current-speed property in /proc/device-tree
> for the serial node? I'm curious if U-Boot created it, or if the kernel
> just used whatever baud was present already.
>
> When I did the bamboo port a while ago, I recall having issues with either
> a missing clock-frequency or current-speed (or both perhaps) and the bootloader
> on the board was the original PIBS. It might have been an issue with PIBS
> but I'm guessing the rest of the 4xx boards copied from either Ebony or
> Bamboo in their ports and hence contain that property.
I think I recently added code to legacy_serial probe the speed from the
HW if the property is absent, which should help.
Cheers,
Ben.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2009-09-15 21:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel list, linuxppc-dev list, Andrew Morton,
FUJITA Tomonori, Ingo Molnar
In-Reply-To: <alpine.LFD.2.01.0909150943580.4950@localhost.localdomain>
On Tue, 2009-09-15 at 09:53 -0700, Linus Torvalds wrote:
> It got a conflict with the AGP merge, but I fixed it up in what _seemed_
> to be the obvious manner. But somebody should check out the resulting
> drivers/char/agp/uninorth-agp.c file.
Thanks.
Michel, can you dbl check it ?
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox