Re: pSeries boot failure due to wrong interrupt controller
On Fri, 2015-06-26 at 17:35 -0500, Jeremy Linton wrote: > On 6/26/2015 4:54 PM, Benjamin Herrenschmidt wrote: > > Ah I missed that completely. From your discussion, it looks correct, I'll > > see if I can find a machine to test, however I think we dropped support for > > POWER3 so it might be non-trivial to do so. > > Thanks, the problem originally cropped up on a power4+, I was going to > test > it on power5 too, but I don't have access anymore. I do have a power3 as well, > but I think that machine has other issues (the BUG_ON in the platform table > for starters). Ok, I don't think I still have one of these, but if you re-send the patch with S-O-B etc... I'll review & ack it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pSeries boot failure due to wrong interrupt controller
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/26/2015 4:54 PM, Benjamin Herrenschmidt wrote: > Ah I missed that completely. From your discussion, it looks correct, I'll > see if I can find a machine to test, however I think we dropped support for > POWER3 so it might be non-trivial to do so. Thanks, the problem originally cropped up on a power4+, I was going to test it on power5 too, but I don't have access anymore. I do have a power3 as well, but I think that machine has other issues (the BUG_ON in the platform table for starters). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJVjdPIAAoJEL5i86xrzcy7KA0H+QHVe3IFy12DlgxP0kbbaDtr D5JLqh9OHBxZohotRzQz5errCIBYGxIYy93P6S2NvQSKS1gqZFFrvdyIs0f3UYo0 izzRVh/Gf10p0d3MJDI0EYC7OlxlP4hJ8lZKU2PNFQvhLT4eE1i/XJAySJLJsSpG WD9CiP5Flixm/ECBPbyeg9nnc5c+EM4xPhE6J3Zp5pX7gU0cieJb2rzhz/7/TsI1 6AYMOPC4JpL3aK5z4eKuVgzvuJ/MyCjHdwii0TpNBhhhyidq8PEDoH3Y61CIOszq Uu5HAQoToqBZdKM7siiZY0LJVQVpJaze4zhjexqhGa/Ll0iquj3V13xZ5qjj1eA= =oeSx -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pSeries boot failure due to wrong interrupt controller
On Fri, 2015-06-26 at 12:54 -0500, Jeremy Linton wrote:
> Ping? Anyone?
>
> I'm adding ppc-dev to see if anyone there is interested in picking up the
> patch..
Ah I missed that completely. From your discussion, it looks correct,
I'll see if I can find a machine to test, however I think we dropped
support for POWER3 so it might be non-trivial to do so.
And yes, when there is no map, the parent should be the interrupt-parent
with a fallback to the parent node if that doesn't exist.
Cheers,
Ben.
> Thanks,
> Jeremy
>
>
> Ok so I messed up the formatting a little and was lazy and didn't checkpatch
> it
> cause I mean, it was 1 line! If someone wants it resent I will do so.
>
>
>
>
>
> On 6/23/2015 8:42 AM, Rob Herring wrote:
> > +Grant
> >
> > On Mon, Jun 22, 2015 at 2:44 PM, Jeremy Linton
> > wrote:
> >> The OF IRQ logic was refactored a while back, and it appears that it
> >> broke the case where a device doesn't have an interrupt-map
> >> (legacy/ISA platform peripherals). In particular on the older pSeries
> >> platforms the console serial port (keyboard/etc) is attached via a
> >> Winbond super I/O controller. With the refactored logic
> >> of_irq_parse_raw() returns with the out_irq->np pointing at the bus,
> >> rather than the interrupt controller. This results in the platform
> >> logic getting confused about the appropriate interrupt host, and in
> >> ics_rtas_host_match() it doesn't match "chrp,iic" and the xics takes
> >> over and tries to use RTAS to map the interrupt. RTAS then crashes the
> >> machine.
> >>
> >> This tweaks the "-> no map, getting parent" behavior to behave as
> >> before, and the machine boots.
> >
> > I think the real question is why doesn't of_irq_find_parent return the
> > interrupt controller node instead of the bus node.
> >
> > While I think this fix is correct, I think of_irq_parse_raw should be
> > a nop in the case of no interrupt-map.
> >
> > Rob
> >
> >>
> >> Thanks
> >>
> >> Signed-off-by: Jeremy Linton
> >>
> >>
> >> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> >> index 1a79806..78b4161b 100644
> >> --- a/drivers/of/irq.c
> >> +++ b/drivers/of/irq.c
> >> @@ -252,7 +252,6 @@ int of_irq_parse_raw(const __be32 *addr, struct
> >> of_phandle_args *out_irq)
> >> * Successfully parsed an interrrupt-map translation; copy
> >> new
> >> * interrupt specifier into the out_irq structure
> >> */
> >> - out_irq->np = newpar;
> >>
> >> match_array = imap - newaddrsize - newintsize;
> >> for (i = 0; i < newintsize; i++)
> >> @@ -262,6 +261,7 @@ int of_irq_parse_raw(const __be32 *addr, struct
> >> of_phandle_args *out_irq)
> >>
> >> skiplevel:
> >> /* Iterate again with new parent */
> >> + out_irq->np = newpar;
> >> pr_debug(" -> new parent: %s\n",
> >> of_node_full_name(newpar));
> >> of_node_put(ipar);
> >> ipar = newpar;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
On 06/19/15 12:58, Kees Cook wrote: On Fri, Jun 19, 2015 at 7:12 AM, David Long wrote: On 06/19/15 00:19, Michael Ellerman wrote: On Mon, 2015-06-15 at 12:42 -0400, David Long wrote: From: "David A. Long" The pt_regs_offset structure is used for HAVE_REGS_AND_STACK_ACCESS_API feature and has identical definitions in four different arch ptrace.h include files. It seems unlikely that definition would ever need to be changed regardless of architecture so lets move it into include/linux/ptrace.h. Signed-off-by: David A. Long --- arch/powerpc/kernel/ptrace.c | 5 - Built and booted on powerpc, but is there an easy way to actually test the code paths in question? There is an easy way to "smoke test" it on all archiectures that also implement kprobes (which powerpc does). If I'm understanding the powerpc code correctly (WRT register naming conventions) just do the following: cd /sys/kernel/debug/tracing echo 'p do_fork %gpr0' > kprobe_events echo 1 > events/kprobes/enable ls cat trace echo 0 > events/kprobes/enable Every fork() call done on the system between those two echo commands (hence the "ls") should append a line to the trace file. For a more exhaustive test one could repeat this sequence for every register in the architecture. This should work the same on all architectures supporting kprobes. You just have to use the appropriate register names for your architecture after the "%". Is this something we could codify into the selftests directory? It seems like a great thing to capture in a single place somewhere (the register lists, that is). e -Kees Due to the architecture-specific naming of registers this would have to be added to the architecture subdirectories. I only see powerpc and x86 subdirs at this time so extending that infrastructure would have to be part of this. Verifying the register contents would also require some change to the kernel, possibly a simple test module, which would have to be unique to each architecture. Without that we could only check for recognition of the register name, although maybe that's good enough. Acked-by: Michael Ellerman cheers Thanks, -dl -dl ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pSeries boot failure due to wrong interrupt controller
Ping? Anyone?
I'm adding ppc-dev to see if anyone there is interested in picking up the
patch..
Thanks,
Jeremy
Ok so I messed up the formatting a little and was lazy and didn't checkpatch it
cause I mean, it was 1 line! If someone wants it resent I will do so.
On 6/23/2015 8:42 AM, Rob Herring wrote:
> +Grant
>
> On Mon, Jun 22, 2015 at 2:44 PM, Jeremy Linton
> wrote:
>> The OF IRQ logic was refactored a while back, and it appears that it
>> broke the case where a device doesn't have an interrupt-map
>> (legacy/ISA platform peripherals). In particular on the older pSeries
>> platforms the console serial port (keyboard/etc) is attached via a
>> Winbond super I/O controller. With the refactored logic
>> of_irq_parse_raw() returns with the out_irq->np pointing at the bus,
>> rather than the interrupt controller. This results in the platform
>> logic getting confused about the appropriate interrupt host, and in
>> ics_rtas_host_match() it doesn't match "chrp,iic" and the xics takes
>> over and tries to use RTAS to map the interrupt. RTAS then crashes the
>> machine.
>>
>> This tweaks the "-> no map, getting parent" behavior to behave as
>> before, and the machine boots.
>
> I think the real question is why doesn't of_irq_find_parent return the
> interrupt controller node instead of the bus node.
>
> While I think this fix is correct, I think of_irq_parse_raw should be
> a nop in the case of no interrupt-map.
>
> Rob
>
>>
>> Thanks
>>
>> Signed-off-by: Jeremy Linton
>>
>>
>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
>> index 1a79806..78b4161b 100644
>> --- a/drivers/of/irq.c
>> +++ b/drivers/of/irq.c
>> @@ -252,7 +252,6 @@ int of_irq_parse_raw(const __be32 *addr, struct
>> of_phandle_args *out_irq)
>> * Successfully parsed an interrrupt-map translation; copy
>> new
>> * interrupt specifier into the out_irq structure
>> */
>> - out_irq->np = newpar;
>>
>> match_array = imap - newaddrsize - newintsize;
>> for (i = 0; i < newintsize; i++)
>> @@ -262,6 +261,7 @@ int of_irq_parse_raw(const __be32 *addr, struct
>> of_phandle_args *out_irq)
>>
>> skiplevel:
>> /* Iterate again with new parent */
>> + out_irq->np = newpar;
>> pr_debug(" -> new parent: %s\n", of_node_full_name(newpar));
>> of_node_put(ipar);
>> ipar = newpar;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RESEND PATCH v8] powerpc/powernv: Add poweroff (EPOW, DPO) events support for PowerNV platform
On 06/11/2015 05:13 PM, Vipin K Parashar wrote:
This patch adds support for OPAL EPOW (Early Power Off Warning) and
Hi Micheal,
Please use below expansion for EPOW acronym in commit log
once u add this patch.
EPOW = Environmental and Power Warnings
It matches with PAPR expansion for EPOW. This way we will have same
EPOW expansion for pSeries and PowerNV platforms avoiding any confusion.
Thanks for your help with this.
DPO (Delayed Power Off) events for the PowerNV platform. These events
are generated on FSP (Flexible Service Processor) based systems. EPOW
events are generated due to various critical system conditions that
require system shutdown. A few examples of these conditions are high
ambient temperature or system running on UPS power with low UPS battery.
DPO event is generated in response to admin initiated system shutdown
request. Upon receipt of EPOW and DPO events the host kernel invokes
orderly_poweroff() for performing graceful system shutdown.
Reviewed-by: Joel Stanley
Reviewed-by: Vaibhav Jain
Reviewed-by: Michael Ellerman
Signed-off-by: Vipin K Parashar
---
arch/powerpc/include/asm/opal-api.h| 40 +++
arch/powerpc/include/asm/opal.h| 3 +-
arch/powerpc/platforms/powernv/opal-power.c| 147 ++---
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
4 files changed, 173 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..f460435 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -730,6 +730,46 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/*
+ * EPOW status sharing (OPAL and the host)
+ *
+ * The host will pass on OPAL, a buffer of length OPAL_SYSEPOW_MAX
+ * with individual elements being 16 bits wide to fetch the system
+ * wide EPOW status. Each element in the buffer will contain the
+ * EPOW status in it's bit representation for a particular EPOW sub
+ * class as defiend here. So multiple detailed EPOW status bits
+ * specific for any sub class can be represented in a single buffer
+ * element as it's bit representation.
+ */
+
+/* System EPOW type */
+enum OpalSysEpow {
+ OPAL_SYSEPOW_POWER = 0,/* Power EPOW */
+ OPAL_SYSEPOW_TEMP = 1,/* Temperature EPOW */
+ OPAL_SYSEPOW_COOLING= 2,/* Cooling EPOW */
+ OPAL_SYSEPOW_MAX= 3,/* Max EPOW categories */
+};
+
+/* Power EPOW */
+enum OpalSysPower {
+ OPAL_SYSPOWER_UPS = 0x0001, /* System on UPS power */
+ OPAL_SYSPOWER_CHNG = 0x0002, /* System power config change */
+ OPAL_SYSPOWER_FAIL = 0x0004, /* System impending power failure */
+ OPAL_SYSPOWER_INCL = 0x0008, /* System incomplete power */
+};
+
+/* Temperature EPOW */
+enum OpalSysTemp {
+ OPAL_SYSTEMP_AMB= 0x0001, /* System over ambient temperature */
+ OPAL_SYSTEMP_INT= 0x0002, /* System over internal temperature */
+ OPAL_SYSTEMP_HMD= 0x0004, /* System over ambient humidity */
+};
+
+/* Cooling EPOW */
+enum OpalSysCooling {
+ OPAL_SYSCOOL_INSF = 0x0001, /* System insufficient cooling */
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..8b174f3 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -141,7 +141,8 @@ int64_t opal_pci_fence_phb(uint64_t phb_id);
int64_t opal_pci_reinit(uint64_t phb_id, uint64_t reinit_scope, uint64_t
data);
int64_t opal_pci_mask_pe_error(uint64_t phb_id, uint16_t pe_number, uint8_t
error_type, uint8_t mask_action);
int64_t opal_set_slot_led_status(uint64_t phb_id, uint64_t slot_id, uint8_t
led_type, uint8_t led_action);
-int64_t opal_get_epow_status(__be64 *status);
+int64_t opal_get_epow_status(__be16 *epow_status, __be16 *num_epow_classes);
+int64_t opal_get_dpo_status(__be64 *dpo_timeout);
int64_t opal_set_system_attention_led(uint8_t led_action);
int64_t opal_pci_next_error(uint64_t phb_id, __be64 *first_frozen_pe,
__be16 *pci_error_type, __be16 *severity);
diff --git a/arch/powerpc/platforms/powernv/opal-power.c
b/arch/powerpc/platforms/powernv/opal-power.c
index ac46c2c..58dc330 100644
--- a/arch/powerpc/platforms/powernv/opal-power.c
+++ b/arch/powerpc/platforms/powernv/opal-power.c
@@ -9,9 +9,12 @@
* 2 of the License, or (at your option) any later version.
*/
+#define pr_fmt(fmt)"opal-power: "fmt
+
#include
#include
#include
+#include
#include
#include
@@ -19,30 +22,116 @@
#define SOFT_OFF 0x00
#define SOFT_REBOOT 0x01
+/* Detect EPOW event */
+static bool detect_epow(void)
+{
+ u16 epow;
+ int i, rc;
+ __be16 epow_classes;
+ __be16 opal_epow_status[OPAL_SYSEPOW_MAX] = {0};
+
+
Re: [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode
On Thursday, June 25, 2015 09:05:49 AM Preeti U Murthy wrote: > On 06/25/2015 05:36 AM, Rafael J. Wysocki wrote: > > On Thu, Jun 25, 2015 at 12:06 AM, Benjamin Herrenschmidt > > wrote: > >> On Wed, 2015-06-24 at 15:50 +0200, Rafael J. Wysocki wrote: > >>> 4.2 material I suppose? > >> > >> And stable. Without this, if you configure without TICK_ONESHOT, the > >> machine will hang. > > > > OK, which -stable? All of them or any specific series? > > This needs to go into stable/linux-3.19.y, > stable/linux-4.0.y, stable/linux-4.1.y. So essentially 3.19+. OK, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/2] arm64: dts: Add the arasan mmc nodes in apm-storm.dtsi
Any comments on this patch ??
On Fri, Jun 19, 2015 at 5:30 PM, Suman Tripathi wrote:
> This patch adds the arasan mmc nodes to reuse the of-arasan
> driver for APM X-Gene SoC.
>
> Signed-off-by: Suman Tripathi
> ---
> ---
> arch/arm64/boot/dts/apm/apm-mustang.dts | 4 +++
> arch/arm64/boot/dts/apm/apm-storm.dtsi | 43
> +
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts
> b/arch/arm64/boot/dts/apm/apm-mustang.dts
> index 83578e7..7a3ea72 100644
> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
> @@ -52,3 +52,7 @@
> &xgenet {
> status = "ok";
> };
> +
> +&mmc0 {
> + status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index c8d3e0e..8e03ecd 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -145,6 +145,40 @@
> clock-output-names = "socplldiv2";
> };
>
> + ahbclk: ahbclk@1f2ac000 {
> + compatible = "apm,xgene-device-clock";
> + #clock-cells = <1>;
> + clocks = <&socplldiv2 0>;
> + reg = <0x0 0x1f2ac000 0x0 0x1000
> + 0x0 0x1700 0x0 0x2000>;
> + reg-names = "csr-reg", "div-reg";
> + csr-offset = <0x0>;
> + csr-mask = <0x1>;
> + enable-offset = <0x8>;
> + enable-mask = <0x1>;
> + divider-offset = <0x164>;
> + divider-width = <0x5>;
> + divider-shift = <0x0>;
> + clock-output-names = "ahbclk";
> + };
> +
> + sdioclk: sdioclk@1f2ac000 {
> + compatible = "apm,xgene-device-clock";
> + #clock-cells = <1>;
> + clocks = <&socplldiv2 0>;
> + reg = <0x0 0x1f2ac000 0x0 0x1000
> + 0x0 0x1700 0x0 0x2000>;
> + reg-names = "csr-reg", "div-reg";
> + csr-offset = <0x0>;
> + csr-mask = <0x2>;
> + enable-offset = <0x8>;
> + enable-mask = <0x2>;
> + divider-offset = <0x178>;
> + divider-width = <0x8>;
> + divider-shift = <0x0>;
> + clock-output-names = "sdioclk";
> + };
> +
> qmlclk: qmlclk {
> compatible = "apm,xgene-device-clock";
> #clock-cells = <1>;
> @@ -533,6 +567,15 @@
> interrupts = <0x0 0x4f 0x4>;
> };
>
> + mmc0: mmc@1c00 {
> + compatible = "arasan,sdhci-4.9a";
> + reg = <0x0 0x1c00 0x0 0x100>;
> + interrupts = <0x0 0x49 0x4>;
> + dma-coherent;
> + clock-names = "clk_xin", "clk_ahb";
> + clocks = <&sdioclk 0>, <&ahbclk 0>;
> + };
> +
> phy1: phy@1f21a000 {
> compatible = "apm,xgene-phy";
> reg = <0x0 0x1f21a000 0x0 0x100>;
> --
> 1.8.2.1
>
--
Thanks,
with regards,
Suman Tripathi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5] powerpc/rcpm: add RCPM driver
From: Tang Yuantian
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
Signed-off-by: Chenhui Zhao
Signed-off-by: Tang Yuantian
---
v5:
- update chassis version for t1040 in bindings
v4:
- refine bindings document
v3:
- added static and __init modifier to fsl_rcpm_init
v2:
- fix code style issues
- refine compatible string match part
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 44 +++
arch/powerpc/include/asm/fsl_guts.h| 105 +++
arch/powerpc/include/asm/fsl_pm.h | 48 +++
arch/powerpc/platforms/85xx/Kconfig| 1 +
arch/powerpc/sysdev/Kconfig| 5 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_rcpm.c | 338 +
7 files changed, 542 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
create mode 100644 arch/powerpc/include/asm/fsl_pm.h
create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..dc52f70
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,44 @@
+* Run Control and Power Management
+
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+ - reg : Offset and length of the register set of RCPM block.
+ - compatible : Sould contain a chip-specific RCPM block compatible string
+ and (if applicable) may contain a chassis-version RCPM compatible
string.
+ Chip-specific strings are of the form "fsl,-rcpm", such as:
+ * "fsl,p2041-rcpm"
+ * "fsl,p3041-rcpm"
+ * "fsl,p4080-rcpm"
+ * "fsl,p5020-rcpm"
+ * "fsl,p5040-rcpm"
+ * "fsl,t4240-rcpm"
+ * "fsl,b4420-rcpm"
+ * "fsl,b4860-rcpm"
+
+ Chassis-version RCPM strings include:
+ * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
+ * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
+ * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+
+All references to "1.0" and "2.0" refer to the QorIQ chassis version to
+which the chip complies.
+Chassis VersionExample Chips
+------
+1.0p4080, p5020, p5040, p2041, p3041
+2.0t4240, b4860, b4420
+2.1t1040
+
+Example:
+The RCPM node for T4240:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+The RCPM node for P4080:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,qoriq-rcpm-1.0";
+ reg = <0xe2000 0x1000>;
+ };
diff --git a/arch/powerpc/include/asm/fsl_guts.h
b/arch/powerpc/include/asm/fsl_guts.h
index 43b6bb1..a67413c 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -188,5 +188,110 @@ static inline void guts_set_pmuxcr_dma(struct ccsr_guts
__iomem *guts,
#endif
+struct ccsr_rcpm_v1 {
+ u8 res[4];
+ __be32 cdozsr; /* 0x0004 Core Doze Status Register */
+ u8 res0008[4];
+ __be32 cdozcr; /* 0x000c Core Doze Control Register */
+ u8 res0010[4];
+ __be32 cnapsr; /* 0x0014 Core Nap Status Register */
+ u8 res0018[4];
+ __be32 cnapcr; /* 0x001c Core Nap Control Register */
+ u8 res0020[4];
+ __be32 cdozpsr;/* 0x0024 Core Doze Previous Status Register */
+ u8 res0028[4];
+ __be32 cnappsr;/* 0x002c Core Nap Previous Status Register */
+ u8 res0030[4];
+ __be32 cwaitsr;/* 0x0034 Core Wait Status Register */
+ u8 res0038[4];
+ __be32 cwdtdsr;/* 0x003c Core Watchdog Detect Status Register */
+ __be32 powmgtcsr; /* 0x0040 PM Control&Status Register */
+#define RCPM_POWMGTCSR_SLP 0x0002
+ u8 res0044[12];
+ __be32 ippdexpcr; /* 0x0050 IP Powerdown Exception Control Register */
+ u8 res0054[16];
+ __be32 cpmimr; /* 0x0064 Core PM IRQ Mask Register */
+ u8 res0068[4];
+ __be32 cpmcimr;/* 0x006c Core PM Critical IRQ Mask Register */
+ u8 res0070[4];
+ __be32 cpmmcmr;/* 0x0074 Core PM Machine Check Mask Register */
+ u8 res0078[4];
+ __be32 cpmnmimr; /* 0x007c Core PM NMI Mask Register */
+ u8 res0080[4];
+ __be32 ctbenr; /* 0x0084 Core Time Base Enable Register */
+
Re: [v2,9/9] fsl/fman: Add FMan MAC driver
On Thu, 2015-06-25 at 19:59 -0500, Scott Wood wrote: > On Fri, 2015-06-26 at 01:06 +0200, Paul Bolle wrote: > > (Evolution 3.16 is basically unbearable for replying to patches. > > Anyone > > else running into this?) You replied with Evolution v3.16, didn't you? Look how it wrapped that line. Now imagine how a patch of a few thousands lines might look like when replying. (Of course a patch of a few thousands lines is part of the issue here. As in: no one can really handle that.) And if you set certain lines to "preformatted" to undo the wrapping it inserts ">" in the tabs! There's more. I'll stop now, as this is drifting too far off topic. > If you mean the crazy lag when selecting moderate-to-large amounts of > > text (for snipping), yes. One of my replies I had to do over a few times because evolution or I lost track of what was selected. Ie, I thought I had selected hundreds of lines but something much smaller was deleted. Something like that. As confusing as it gets, so who knows what actually happened? Yes, I know, I should ask for a refund. Thanks, Paul Bolle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
