* Re: [PATCH] powerpc/configs: Enbale Freescale IFC controller
From: Scott Wood @ 2014-01-17 18:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <B2E40837-4025-4975-8DAC-BB47E2B07E1A@kernel.crashing.org>
On Fri, 2014-01-17 at 11:02 -0600, Kumar Gala wrote:
> On Jan 17, 2014, at 12:09 AM, Prabhakar Kushwaha <prabhakar@freescale.com> wrote:
>
> > Currently IFC NAND driver is enabled in corenet32smp_defconfig. But IFC
> > controller is not enabled
> >
> > So, Enable IFC controller in corenet32smp_defconfig.
> >
> > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > ---
> > Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> > branch master
> >
> > arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
>
> Shouldn’t the NAND driver get the IFC controller enabled by Kconfig dependancies?
Yes (by select, not dependencies).
Prabhakar, was there an actual problem you saw before? Did you run
savedefconfig after making this change?
CONFIG_FSL_IFC isn't even user-selectable (though it probably should be,
as how else would it get enabled in the absence of NAND for catching NOR
errors?).
-Scott
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix compile error of pgtable-ppc64.h
From: Benjamin Herrenschmidt @ 2014-01-17 20:59 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul Mackerras, PowerPC email list, Aneesh Kumar K.V
In-Reply-To: <1389965453.5628.3.camel@ThinkPad-T5421>
On Fri, 2014-01-17 at 21:30 +0800, Li Zhong wrote:
> On Fri, 2014-01-17 at 12:27 +0530, Aneesh Kumar K.V wrote:
> > Li Zhong <zhong@linux.vnet.ibm.com> writes:
> >
> > > It seems that forward declaration couldn't work well with typedef, use
> > > struct spinlock directly to avoiding following build errors:
> > >
> > > In file included from include/linux/spinlock.h:81,
> > > from include/linux/seqlock.h:35,
> > > from include/linux/time.h:5,
> > > from include/uapi/linux/timex.h:56,
> > > from include/linux/timex.h:56,
> > > from include/linux/sched.h:17,
> > > from arch/powerpc/kernel/asm-offsets.c:17:
> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
> > >
> >
> > what compiler version ? I have seen that error in gcc 4.3 and it was
> > concluded that it is too old a compiler version to worry about. That
> > specific compiler version also gave error for forward declaring struct;
>
> gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC), and it doesn't
> report error after use struct directly.
Ok, I think that's justification enough then. I'll add that. It's all
too late for 3.13 anyway so I'll send these patches during the window
with an appropriate CC to stable.
Cheers,
Ben.
> >
> > > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > > ---
> > > arch/powerpc/include/asm/pgtable-ppc64.h | 6 +++---
> > > 1 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> > > index d27960c..bc141c9 100644
> > > --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> > > +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> > > @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> > > pmd_t *pmdp);
> > >
> > > #define pmd_move_must_withdraw pmd_move_must_withdraw
> > > -typedef struct spinlock spinlock_t;
> > > -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> > > - spinlock_t *old_pmd_ptl)
> > > +struct spinlock;
> > > +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> > > + struct spinlock *old_pmd_ptl)
> > > {
> > > /*
> > > * Archs like ppc64 use pgtable to store per pmd
>
^ permalink raw reply
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Scott Wood @ 2014-01-17 21:48 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52D9273E.10008@keymile.com>
On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
> Hi Scott,
>
> Thanks for you feedback.
>
> On 01/17/2014 12:35 AM, Scott Wood wrote:
> > On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
> >> This patch introduces the support for Keymile's kmp204x reference
> >> design. This design is based on Freescale's P2040/P2041 SoC.
> >>
> >> The peripherals used by this design are:
> >> - SPI NOR Flash as bootloader medium
> >> - NAND Flash with a ubi partition
> >> - 2 PCIe busses (hosts 1 and 3)
> >> - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
> >> - 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
> >> FPGA
> >> - 2 HW I2C busses
> >> - last but not least, the mandatory serial port
> >>
> >> The patch also adds a defconfig file for this reference design and a DTS
> >> file for the kmcoge4 board which is the first one based on this
> >> reference design.
> >>
> >> To try to avoid code duplication, the support was added directly to the
> >> corenet_generic.c file.
> >>
> >> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
> >> ---
> >> arch/powerpc/boot/dts/kmcoge4.dts | 165 ++++++++++++++++++
> >> arch/powerpc/configs/85xx/kmp204x_defconfig | 231 ++++++++++++++++++++++++++
> >> arch/powerpc/platforms/85xx/Kconfig | 14 ++
> >> arch/powerpc/platforms/85xx/Makefile | 1 +
> >> arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++++++
> >> 5 files changed, 463 insertions(+)
> >> create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
> >> create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
> >>
> >> diff --git a/arch/powerpc/boot/dts/kmcoge4.dts b/arch/powerpc/boot/dts/kmcoge4.dts
> >> new file mode 100644
> >> index 0000000..c10df6d
> >> --- /dev/null
> >> +++ b/arch/powerpc/boot/dts/kmcoge4.dts
> >> @@ -0,0 +1,165 @@
> >> +/*
> >> + * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
> >> + *
> >> + * (C) Copyright 2014
> >> + * Valentin Longchamp, Keymile AG, valentin.longchamp@keymile.com
> >> + *
> >> + * Copyright 2011 Freescale Semiconductor Inc.
> >> + *
> >> + * 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/ "fsl/p2041si-pre.dtsi"
> >> +
> >> +/ {
> >> + model = "keymile,kmcoge4";
> >> + compatible = "keymile,kmp204x";
> >
> > Don't put wildcards in compatible.
>
> Well it's a wildcard in the sense that we support both the p2040 and the p2041,
> but it's also the name of the plaftorm, similarly to names like '85xx' or 'tqm85xx'.
Names like 85xx are not allowed in device trees.
With "p204x", what would happen if a p2042 were introduced, that were
not compatible?
Why isn't the compatible "keymile,kmcoge4", like the model?
> > I realize it's common practice, but it would be good to get away from
> > putting partition layouts in the dts file. Alternatives include using
> > mtdparts on the command line, or having U-Boot put the partition info
> > into the dtb based on the mtdparts environment variable (there is
> > existing code for this).
>
> I agree that u-boot also has to know about the addresses because it also
> accesses these partitions.
>
> But I think it is clearer to have this in the device tree: I try to keep the
> kernel command line small and I don't like having u-boot "fixing" the dtb at
> runtime.
The problem is that the dts source is often far removed from the actual
programming of flash, and the partitioning can vary based on use case,
or change for other reasons (e.g. there have been requests to change
existing partition layouts to accommodate growth in U-Boot size).
Ideally it wouldn't be in the device tree at all, but having U-Boot fix
it up based on an environment variable is better than statically
defining it in a file in the Linux tree.
> >> + zl30343@1 {
> >> + compatible = "gen,spidev";
> >
> > Node names are supposed to be generic. Compatibles are supposed to be
> > specific.
>
> That's a very specific device for which we only have a userspace driver and for
> which we must use the generic kernel spidev driver.
The device tree describes the hardware, not what driver you want to use.
Plus, I don't see any driver that matches "gen,spidev" nor any binding
for it, and "gen" doesn't make sense as a vendor prefix. The only
instance of that string I can find in the Linux tree is in mgcoge.dts.
> > That's why the node name is
> > so specific and the compatible field very generic.
Userspace can't search for a node by compatible?
> >> + lbc: localbus@ffe124000 {
> >> + reg = <0xf 0xfe124000 0 0x1000>;
> >> + ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
> >> + 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
> >> + 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
> >> + 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
> >> +
> >> + nand@0,0 {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "fsl,elbc-fcm-nand";
> >> + reg = <0 0 0x40000>;
> >> +
> >> + partition@0 {
> >> + label = "ubi0";
> >> + reg = <0x0 0x8000000>;
> >> + };
> >> + };
> >> + };
> >
> > No nodes for those other chipselects?
>
> Well, there are nodes, but they are internally developed FPGAs and the drivers
> are not mainlined that's why I removed the nodes.
The device tree describes the hardware, not what drivers are currently
mainlined in Linux.
> >> diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig
> >> new file mode 100644
> >> index 0000000..3bbf4fa
> >> --- /dev/null
> >> +++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
> >
> > Why does this board need its own defconfig?
>
> Apart from the different drivers and FS that we use (or don't use) on the
> system,
That is not generally a good reason for a separate defconfig. Just
enable the drivers you need in the main defconfig, and don't worry about
the drivers you don't need. You may want a smaller kernel for actual
shipping products (though the changelog said this is a reference
board...), but in mainline we want a small number of defconfigs that
cover as many boards as possible (or at least, a reasonably small number
and not one per board).
> the most notable differences are:
> - lowmem must be set to a bigger size so that we can ioremap the the total
> memory requested for all of our PCIe devices
> - CGROUPS is enabled because that's a mandatory feature for our systems
> - NAND_ECC_BCH is enabled because it is used on all of our NAND devices
I don't think there would be a problem adding CGROUPS or NAND_ECC_BCH to
corenet32_smp_defconfig (though CGROUPS seems more like a use-case
configuration than something to do with the board itself). The lowmem
adjustment is probably a good reason, though I wish things like that
could be specified as a defconfig that #includes corenet32_smp_defconfig
and then just makes a couple changes.
> > The whole point of corenet_generic.c is to avoid duplicating all of this
> > stuff.
> >
> > Can't you just use corenet_generic as-is other than adding the
> > compatible to boards[]? If not, explain why and put it in a different
> > file.
> >
>
> That's a valid point and I have to admit I have hesitated about that. I have
> mostly based my work on the FSL SDK where every single board has a "dedicated" file.
>
> I agree that I do nothing different than the corenet_generic does and adding my
> platform to the boards[] would be the same and you are right, I should use that
> and avoid code duplication.
>
> The only thing that would "bother" me is thus the pr_info print from
> *_gen_setup_arch(), it would be nice if somehow we could differentiate it or at
> least make it more generic since the kmp204x boards are not strictly boards from
> Freescale.
Just remove the "from Freescale Semiconductor" part of the string.
-Scott
^ permalink raw reply
* Re: [PATCH 3/4 v2]powerpc/fsl-booke: Add support for T2080/T2081 SoC
From: Scott Wood @ 2014-01-17 22:27 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev
In-Reply-To: <1389866562-6235-1-git-send-email-Shengzhou.Liu@freescale.com>
On Thu, 2014-01-16 at 18:02 +0800, Shengzhou Liu wrote:
> + cpc: l3-cache-controller@10000 {
> + compatible = "cache";
> + reg = <0x10000 0x1000
> + 0x11000 0x1000
> + 0x12000 0x1000>;
> + interrupts = <16 2 1 27
> + 16 2 1 26
> + 16 2 1 25>;
> + };
Where's the specific compatible for this node?
> + corenet-cf@18000 {
> + compatible = "fsl,corenet2-cf";
> + reg = <0x18000 0x1000>;
> + interrupts = <16 2 1 31>;
> + fsl,ccf-num-csdids = <32>;
> + fsl,ccf-num-snoopids = <32>;
> + };
"fsl,corenet2-cf" doesn't appear in any other device tree nor in any
binding.
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,qoriq-clockgen-2.0", "fixed-clock";
> + reg = <0xe1000 0x1000>;
> + clock-output-names = "sysclk";
> + #clock-cells = <0>;
Please update this according to v9 of the clock binding:
In particular, sysclk goes in its own node, and compatible strings have
changed.
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,qoriq-rcpm-2.0";
> + reg = <0xe2000 0x1000>;
> + };
compatible = "fsl,t2080-rcpm-2.0", "fsl,qoriq-rcpm-2.0";
-Scott
^ permalink raw reply
* Re: Pull request: scottwood/linux.git
From: Scott Wood @ 2014-01-17 23:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1389758064.6933.56.camel@pasglop>
On Wed, 2014-01-15 at 14:54 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-01-10 at 18:44 -0600, Scott Wood wrote:
> > Highlights include 32-bit booke relocatable support, e6500 hardware
> > tablewalk support, various e500 SPE fixes, some new/revived boards, and
> > e6500 deeper idle and altivec powerdown modes.
>
> This breaks WSP (A2) build with 64K pages:
>
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S: Assembler messages:
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S:334: Error: can't resolve `L0^A' {*ABS* section} - `PUD_SHIFT' {*UND* section}
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S:334: Error: expression too complex
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S:334: Error: operand out of range (67 is not between 0 and 63)
> make[2]: *** [arch/powerpc/mm/tlb_low_64e.o] Error 1
>
> I'm merging anyway because nobody uses WSP anymore (I'm keen to remove it by 3.15 or so)
Does this apply to all non-FSL 64-bit book3e, or is there anything else
that is still in use?
> but in the meantime you may want to fix it (probably just ifdef the PUD level walk on
> 64k pages, look at what I do elsewhere).
Ifdeffing the PUD level doesn't make much sense in this case (other than
perhaps as the least intrusive way to make the error go away) because
that codepath is specific to e6500 which doesn't support 64K pages. The
whole e6500 section should be ifdeffed out if there are 64K pages (or
really, if CONFIG_PPC_FSL_BOOK3E isn't defined, and 64K pages should
conflict with PPC_FSL_BOOK3E).
-Scott
^ permalink raw reply
* [PATCH] powerpc/booke64: Guard e6500 tlb handler with CONFIG_PPC_FSL_BOOK3E
From: Scott Wood @ 2014-01-18 0:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
...and make CONFIG_PPC_FSL_BOOK3E conflict with CONFIG_PPC_64K_PAGES.
This fixes a build break with CONFIG_PPC_64K_PAGES on 64-bit book3e,
that was introduced by commit 28efc35fe68dacbddc4b12c2fa8f2df1593a4ad3
("powerpc/e6500: TLB miss handler with hardware tablewalk support").
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/mm/tlb_low_64e.S | 3 ++-
arch/powerpc/mm/tlb_nohash.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fa39517..ad912d5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -526,6 +526,7 @@ config PPC_16K_PAGES
config PPC_64K_PAGES
bool "64k page size" if 44x || PPC_STD_MMU_64 || PPC_BOOK3E_64
+ depends on !PPC_FSL_BOOK3E
select PPC_HAS_HASH_64K if PPC_STD_MMU_64
config PPC_256K_PAGES
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index 16250b1..c95eb32 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -240,6 +240,7 @@ itlb_miss_fault_bolted:
beq tlb_miss_common_bolted
b itlb_miss_kernel_bolted
+#ifdef CONFIG_PPC_FSL_BOOK3E
/*
* TLB miss handling for e6500 and derivatives, using hardware tablewalk.
*
@@ -409,7 +410,7 @@ itlb_miss_fault_e6500:
TLB_MISS_STATS_I(MMSTAT_TLB_MISS_NORM_FAULT)
tlb_epilog_bolted
b exc_instruction_storage_book3e
-
+#endif /* CONFIG_PPC_FSL_BOOK3E */
/**********************************************************************
* *
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 735839b..b37a58e 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -557,10 +557,12 @@ static void setup_mmu_htw(void)
patch_exception(0x1c0, exc_data_tlb_miss_htw_book3e);
patch_exception(0x1e0, exc_instruction_tlb_miss_htw_book3e);
break;
+#ifdef CONFIG_PPC_FSL_BOOK3E
case PPC_HTW_E6500:
patch_exception(0x1c0, exc_data_tlb_miss_e6500_book3e);
patch_exception(0x1e0, exc_instruction_tlb_miss_e6500_book3e);
break;
+#endif
}
pr_info("MMU: Book3E HW tablewalk %s\n",
book3e_htw_mode != PPC_HTW_NONE ? "enabled" : "not supported");
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v9] clk: corenet: Adds the clock binding
From: Scott Wood @ 2014-01-18 1:06 UTC (permalink / raw)
To: Tang Yuantian; +Cc: mark.rutland, b07421, devicetree, linuxppc-dev
In-Reply-To: <1389600995-28293-1-git-send-email-Yuantian.Tang@freescale.com>
On Mon, 2014-01-13 at 16:16 +0800, Tang Yuantian wrote:
> +Example for clock block and clock provider:
> +/ {
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
> + ranges = <0x0 0xe1000 0x1000>;
> + clock-frequency = 133333;
Missing <> around 133333, and the actual p5020ds input clock (based on
observing what U-Boot fills in) is 133333333, not 133333.
I'll fix when applying.
-Scott
^ permalink raw reply
* Pull request: scottwood/linux.git
From: Scott Wood @ 2014-01-18 1:22 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
This contains a fix for a chroma_defconfig build break that was
introduced by e6500 tablewalk support, and a device tree binding patch
that missed the previous pull request due to some last-minute polishing.
The following changes since commit fac515db45207718168cb55ca4d0a390e43b61af:
Merge remote-tracking branch 'scott/next' into next (2014-01-15 14:22:35 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to 4b3cbc82a04485f6400cb5b227798daaa8512a23:
clk: corenet: Adds the clock binding (2014-01-17 19:01:27 -0600)
----------------------------------------------------------------
Scott Wood (1):
powerpc/booke64: Guard e6500 tlb handler with CONFIG_PPC_FSL_BOOK3E
Tang Yuantian (1):
clk: corenet: Adds the clock binding
.../devicetree/bindings/clock/corenet-clock.txt | 134 +++++++++++++++++++++
arch/powerpc/Kconfig | 1 +
arch/powerpc/mm/tlb_low_64e.S | 3 +-
arch/powerpc/mm/tlb_nohash.c | 2 +
4 files changed, 139 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
^ permalink raw reply
* [PATCH V3 0/3] powerpc/powernv: Error logging interfaces
From: Deepthi Dharwar @ 2014-01-18 2:42 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
This patch series defines generic interfaces for error logging to
push down critical errors from powernv platform to FSP.
Also, it contains few minor fixes for the exisiting error logging
framework that retrieves error logs from FSP.
This patch only adds the framework to log errors. Coming days this
framework will be used to report all POWERNV errors in a phased manner.
We would ideally be targeting one sub-system at a time and use these
interfaces.
Changes from V2:
* Review comments from V2 have been addressed
includes comment formats, changing naming
conventions and incorporated error handling
of the buffers.
* Minor typo fix and use of pr_err/pr_fmt to
log errors.
Deepthi Dharwar (3):
powernv: Push critical error logs to FSP
powernv: Correct spell error in opal-elog.c
powernv: Have uniform logging of errors in opal-elog.c
arch/powerpc/include/asm/opal.h | 123 ++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-elog.c | 92 ++++++++++++++++--
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
3 files changed, 207 insertions(+), 9 deletions(-)
-- Deepthi
^ permalink raw reply
* [PATCH V3 1/3] powernv: Push critical error logs to FSP
From: Deepthi Dharwar @ 2014-01-18 2:43 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
In-Reply-To: <20140118024150.13537.11381.stgit@deepthi>
This patch provides error logging interfaces to report critical
powernv error logs to FSP.
All the required information to dump the error is collected
at POWERNV level through error log interfaces
and then pushed on to FSP.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 123 ++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-elog.c | 76 +++++++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
3 files changed, 200 insertions(+)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 013a696..51b8eb6 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -173,6 +173,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_SENSOR_READ 88
#define OPAL_GET_PARAM 89
#define OPAL_SET_PARAM 90
+#define OPAL_ELOG_SEND 92
#ifndef __ASSEMBLY__
@@ -267,6 +268,119 @@ enum OpalMessageType {
OPAL_MSG_TYPE_MAX,
};
+
+/* Classification of error/event type to be reported on OPAL */
+/* Platform Events/Errors: Report Machine Check Interrupt */
+#define OPAL_PLATFORM_ERR_EVT 0x01
+/* INPUT_OUTPUT: Report all I/O related events/errors */
+#define OPAL_INPUT_OUTPUT_ERR_EVT 0x02
+/* RESOURCE_DEALLOC: Hotplug events and errors */
+#define OPAL_RESOURCE_DEALLOC_ERR_EVT 0x03
+/* MISC: Miscellanous error */
+#define OPAL_MISC_ERR_EVT 0x04
+
+/* OPAL Subsystem IDs listed for reporting events/errors */
+#define OPAL_PROCESSOR_SUBSYSTEM 0x10
+#define OPAL_MEMORY_SUBSYSTEM 0x20
+#define OPAL_IO_SUBSYSTEM 0x30
+#define OPAL_IO_DEVICES 0x40
+#define OPAL_CEC_HARDWARE 0x50
+#define OPAL_POWER_COOLING 0x60
+#define OPAL_MISC_SUBSYSTEM 0x70
+#define OPAL_SURVEILLANCE_ERR 0x7A
+#define OPAL_PLATFORM_FIRMWARE 0x80
+#define OPAL_SOFTWARE 0x90
+#define OPAL_EXTERNAL_ENV 0xA0
+
+
+/*
+ * During reporting an event/error the following represents
+ * how serious the logged event/error is. (Severity)
+ */
+#define OPAL_INFO 0x00
+#define OPAL_RECOVERED_ERR_GENERAL 0x10
+
+/* 0x2X series is to denote set of Predictive Error */
+/* 0x20 Generic predictive error */
+#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
+/* 0x21 Predictive error, degraded performance */
+#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF 0x21
+/* 0x22 Predictive error, fault may be corrected after reboot */
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT 0x22
+/*
+ * 0x23 Predictive error, fault may be corrected after reboot,
+ * degraded performance
+ */
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
+/* 0x24 Predictive error, loss of redundancy */
+#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY 0x24
+
+/* 0x4X series for Unrecoverable Error */
+/* 0x40 Generic Unrecoverable error */
+#define OPAL_UNRECOVERABLE_ERR_GENERAL 0x40
+/* 0x41 Unrecoverable error bypassed with degraded performance */
+#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
+/* 0x44 Unrecoverable error bypassed with loss of redundancy */
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY 0x44
+/* 0x45 Unrecoverable error bypassed with loss of redundancy and performance */
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
+/* 0x48 Unrecoverable error bypassed with loss of function */
+#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
+
+/*
+ * OPAL Event Sub-type
+ * This field provides additional information on the non-error
+ * event type
+ */
+#define OPAL_NA 0x00
+#define OPAL_MISCELLANEOUS_INFO_ONLY 0x01
+#define OPAL_PREV_REPORTED_ERR_RECTIFIED 0x10
+#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
+#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR 0x21
+#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY 0x22
+#define OPAL_CONCURRENT_MAINTENANCE_EVENT 0x40
+#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
+#define OPAL_RESOURCE_SPARING_EVENT 0x70
+#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
+#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN 0xD0
+#define OPAL_ABNORMAL_POWER_OFF 0xE0
+
+/* Max user dump size is 14K */
+#define OPAL_LOG_MAX_DUMP 14336
+#define OPAL_USER_DATA_SZ 4
+
+/* Multiple user data sections */
+struct __attribute__((__packed__)) opal_user_data_section {
+ uint32_t tag;
+ uint16_t size;
+ uint16_t component_id;
+ char data_dump[OPAL_USER_DATA_SZ];
+};
+
+
+/*
+ * All the information regarding an error/event to be reported
+ * needs to populate this structure using pre-defined interfaces
+ * only
+ */
+struct __attribute__((__packed__)) opal_errorlog {
+
+ uint16_t component_id;
+ uint8_t error_event_type;
+ uint8_t subsystem_id;
+
+ uint8_t event_severity;
+ uint8_t event_subtype;
+ uint8_t user_section_count;
+ uint8_t elog_origin;
+
+ uint32_t user_section_size;
+ uint32_t reason_code;
+ uint32_t additional_info[4];
+
+ char user_data_dump[OPAL_LOG_MAX_DUMP];
+};
+
/* Machine check related definitions */
enum OpalMCE_Version {
OpalMCE_V1 = 1,
@@ -861,6 +975,15 @@ int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t *elog_type);
int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
int64_t opal_send_ack_elog(uint64_t log_id);
void opal_resend_pending_logs(void);
+struct opal_errorlog *opal_elog_create(uint8_t opal_error_event_type,
+ uint16_t opal_component_id, uint8_t opal_subsystem_id,
+ uint8_t opal_event_severity, uint8_t opal_event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3);
+int opal_elog_update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size);
+int opal_commit_errorlog_to_fsp(struct opal_errorlog *buf);
+int opal_commit_log_to_fsp(void *buf);
int64_t opal_validate_flash(uint64_t buffer, uint32_t *size, uint32_t *result);
int64_t opal_manage_flash(uint8_t op);
int64_t opal_update_flash(uint64_t blk_list);
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index fc891ae..5aa2d86 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -8,6 +8,9 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
+#undef DEBUG
+#define pr_fmt(fmt) "ELOG: " fmt
+
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/of.h>
@@ -16,6 +19,7 @@
#include <linux/fs.h>
#include <linux/vmalloc.h>
#include <linux/fcntl.h>
+#include <linux/mm.h>
#include <asm/uaccess.h>
#include <asm/opal.h>
@@ -272,6 +276,78 @@ static int init_err_log_buffer(void)
return 0;
}
+/* Interface to be used by POWERNV to push the logs to FSP via Sapphire */
+struct opal_errorlog *opal_elog_create(uint8_t opal_error_event_type,
+ uint16_t opal_component_id, uint8_t opal_subsystem_id,
+ uint8_t opal_event_severity, uint8_t opal_event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3)
+{
+ struct opal_errorlog *buf;
+
+ buf = kzalloc(sizeof(struct opal_errorlog), GFP_KERNEL);
+ if (!buf) {
+ pr_err("Failed to allocate buffer for generating error log\n");
+ return NULL;
+ }
+
+ buf->error_event_type = opal_error_event_type;
+ buf->component_id = opal_component_id;
+ buf->subsystem_id = opal_subsystem_id;
+ buf->event_severity = opal_event_severity;
+ buf->event_subtype = opal_event_subtype;
+ buf->reason_code = reason_code;
+ buf->additional_info[0] = info0;
+ buf->additional_info[1] = info1;
+ buf->additional_info[2] = info2;
+ buf->additional_info[3] = info3;
+ return buf;
+}
+
+int opal_elog_update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size)
+{
+ char *buffer;
+ struct opal_user_data_section *tmp;
+
+ if (!buf) {
+ pr_err("Cannot update user data. Error log buffer is invalid");
+ return -1;
+ }
+
+ buffer = (char *)buf->user_data_dump + buf->user_section_size;
+ if ((buf->user_section_size + size) > OPAL_LOG_MAX_DUMP) {
+ pr_err("Size of user data overruns the buffer");
+ return -1;
+ }
+
+ tmp = (struct opal_user_data_section *)buffer;
+ tmp->tag = tag;
+ tmp->size = size + sizeof(struct opal_user_data_section)
+ - OPAL_USER_DATA_SZ;
+ memcpy(tmp->data_dump, data, size);
+
+ buf->user_section_size += tmp->size;
+ buf->user_section_count++;
+ return 0;
+}
+
+int opal_commit_errorlog_to_fsp(struct opal_errorlog *buf)
+{
+ int rc;
+
+ rc = opal_commit_log_to_fsp((void *)
+ (vmalloc_to_pfn(buf) << PAGE_SHIFT));
+ if (rc == OPAL_SUCCESS) {
+ /* If the log has been committed, free the buffer */
+ kfree(buf);
+ buf = NULL;
+ } else
+ pr_err("Error log could not be committed to FSP");
+
+ return rc;
+}
+
/* Initialize error logging */
int __init opal_elog_init(void)
{
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index c4907aa..65c25277 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -136,3 +136,4 @@ OPAL_CALL(opal_sync_host_reboot, OPAL_SYNC_HOST_REBOOT);
OPAL_CALL(opal_sensor_read, OPAL_SENSOR_READ);
OPAL_CALL(opal_get_param, OPAL_GET_PARAM);
OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
+OPAL_CALL(opal_commit_log_to_fsp, OPAL_ELOG_SEND);
^ permalink raw reply related
* [PATCH V3 2/3] powernv: Correct spell error in opal-elog.c
From: Deepthi Dharwar @ 2014-01-18 2:43 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
In-Reply-To: <20140118024150.13537.11381.stgit@deepthi>
Correct spell error in opal-elog.c
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-elog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 5aa2d86..0f67faa 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -26,7 +26,7 @@
/* Maximum size of a single log on FSP is 16KB */
#define OPAL_MAX_ERRLOG_SIZE 16384
-/* maximu number of records powernv can hold */
+/* Maximum number of records powernv platform can hold */
#define MAX_NUM_RECORD 128
struct opal_err_log {
^ permalink raw reply related
* [PATCH V3 3/3] powernv: Have uniform logging of errors in opal-elog.c
From: Deepthi Dharwar @ 2014-01-18 2:43 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
In-Reply-To: <20140118024150.13537.11381.stgit@deepthi>
Currently some errors/info to be reported use
printk and the rest pr_fmt(). This patch
makes the complete error/event logging uniform.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-elog.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 0f67faa..78d3828 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -63,7 +63,7 @@ void opal_elog_ack(uint64_t ack_id)
struct opal_err_log *record, *next;
bool found = false;
- printk(KERN_INFO "OPAL Log ACK=%llx", ack_id);
+ pr_info("OPAL Log ACK=%llx", ack_id);
/* once user acknowledge a log delete record from list */
spin_lock_irqsave(&opal_elog_lock, flags);
@@ -189,7 +189,7 @@ static void opal_elog_read(void)
/* read log size and log ID from OPAL */
rc = opal_get_elog_size(&log_id, &elog_size, &elog_type);
if (rc != OPAL_SUCCESS) {
- pr_err("ELOG: Opal log read failed\n");
+ pr_err("Opal log read failed\n");
return;
}
if (elog_size >= OPAL_MAX_ERRLOG_SIZE)
@@ -203,7 +203,7 @@ static void opal_elog_read(void)
rc = opal_read_elog(__pa(err_log_data), elog_size, log_id);
if (rc != OPAL_SUCCESS) {
mutex_unlock(&err_log_data_mutex);
- pr_err("ELOG: log read failed for log-id=%llx\n", log_id);
+ pr_err("Reading of log failed for log-id=%llx\n", log_id);
/* put back the free node. */
spin_lock_irqsave(&opal_elog_lock, flags);
list_add(&record->link, &elog_ack_list);
@@ -265,7 +265,7 @@ static int init_err_log_buffer(void)
buf_ptr = vmalloc(sizeof(struct opal_err_log) * MAX_NUM_RECORD);
if (!buf_ptr) {
- printk(KERN_ERR "ELOG: failed to allocate memory.\n");
+ pr_err("Failed to allocate memory for error logging buffers.\n");
return -ENOMEM;
}
memset(buf_ptr, 0, sizeof(struct opal_err_log) * MAX_NUM_RECORD);
@@ -359,15 +359,13 @@ int __init opal_elog_init(void)
rc = sysfs_create_bin_file(opal_kobj, &opal_elog_attr);
if (rc) {
- printk(KERN_ERR "ELOG: unable to create sysfs file"
- "opal_elog (%d)\n", rc);
+ pr_err("Unable to create sysfs file opal_elog (%d)\n", rc);
return rc;
}
rc = sysfs_create_file(opal_kobj, &opal_elog_ack_attr.attr);
if (rc) {
- printk(KERN_ERR "ELOG: unable to create sysfs file"
- " opal_elog_ack (%d)\n", rc);
+ pr_err("Unable to create sysfs file opal_elog_ack (%d)\n", rc);
return rc;
}
^ permalink raw reply related
* Re: [PATCH] powerpc/configs: Enbale Freescale IFC controller
From: Prabhakar Kushwaha @ 2014-01-18 3:46 UTC (permalink / raw)
To: Scott Wood, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1389984587.24905.249.camel@snotra.buserror.net>
On 1/18/2014 12:19 AM, Scott Wood wrote:
> On Fri, 2014-01-17 at 11:02 -0600, Kumar Gala wrote:
>> On Jan 17, 2014, at 12:09 AM, Prabhakar Kushwaha <prabhakar@freescale.=
com> wrote:
>>
>>> Currently IFC NAND driver is enabled in corenet32smp_defconfig. But I=
FC
>>> controller is not enabled
>>>
>>> So, Enable IFC controller in corenet32smp_defconfig.
>>>
>>> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
>>> ---
>>> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/li=
nux.git
>>> branch master
>>>
>>> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>> Shouldn=E2=80=99t the NAND driver get the IFC controller enabled by Kc=
onfig dependancies?
> Yes (by select, not dependencies).
>
> Prabhakar, was there an actual problem you saw before? Did you run
> savedefconfig after making this change?
>
> CONFIG_FSL_IFC isn't even user-selectable (though it probably should be=
,
> as how else would it get enabled in the absence of NAND for catching NO=
R
> errors?).
>
Thanks Kumar and Scott for reviewing this patch.
Yes, it should be enabled by Kconfig dependency. as we have
config FSL_IFC
bool
depends on FSL_SOC
The only reason I changed this code because i wanted all powerpc/configs=20
to be similar as they have CONFIG_FSL_IFC enabled by default.
arch/powerpc/configs/mpc85xx_smp_defconfig:54:CONFIG_FSL_IFC=3Dy
arch/powerpc/configs/corenet64_smp_defconfig:29:CONFIG_FSL_IFC=3Dy
arch/powerpc/configs/mpc85xx_defconfig:51:CONFIG_FSL_IFC=3Dy
So either I should add in corenet32smp_defconfig to make similar to other=
s.
or
remove from all.
I chose first option.
Regards,
Prabhakar
^ permalink raw reply
* Re: [PATCH 1/2][v3] driver/memory:Move Freescale IFC driver to a common driver
From: Prabhakar Kushwaha @ 2014-01-18 3:48 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, Greg Kroah-Hartman, linuxppc-dev, linux-kernel,
Arnd Bergmann
In-Reply-To: <E7780BC2-F914-4D0C-8AB9-9FE7437A5C48@kernel.crashing.org>
On 1/17/2014 10:38 PM, Kumar Gala wrote:
> On Jan 15, 2014, at 11:42 PM, Prabhakar Kushwaha <prabhakar@freescale.com> wrote:
>
>> Freescale IFC controller has been used for mpc8xxx. It will be used
>> for ARM-based SoC as well. This patch moves the driver to driver/memory
>> and fix the header file includes.
>>
>> Also remove module_platform_driver() and instead call
>> platform_driver_register() from subsys_initcall() to make sure this module
>> has been loaded before MTD partition parsing starts.
>>
>> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Changes for v2:
>> - Move fsl_ifc in driver/memory
>>
>> Changes for v3:
>> - move device tree bindings to memory
>>
>> .../{powerpc => memory-controllers}/fsl/ifc.txt | 0
>> arch/powerpc/sysdev/Makefile | 1 -
>> drivers/memory/Makefile | 1 +
>> {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c | 8 ++++++--
>> drivers/mtd/nand/fsl_ifc_nand.c | 2 +-
>> .../include/asm => include/linux}/fsl_ifc.h | 0
>> 6 files changed, 8 insertions(+), 4 deletions(-)
>> rename Documentation/devicetree/bindings/{powerpc => memory-controllers}/fsl/ifc.txt (100%)
>> rename {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c (98%)
>> rename {arch/powerpc/include/asm => include/linux}/fsl_ifc.h (100%)
> The Kconfig option for FSL_IFC should move into drivers/memory/Kconfig
Thanks Kumar for taking time and review this patch.
You are correct. I was checking sysdev/Kconfig but it is defined in
powerpc/Kconfig
I missed it :)
Regards,
Prabhakar
^ permalink raw reply
* [PATCH 1/2][v5] driver/memory:Move Freescale IFC driver to a common driver
From: Prabhakar Kushwaha @ 2014-01-18 6:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, linux-kernel, Prabhakar Kushwaha
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/memory
and fix the header file includes.
Also remove module_platform_driver() and instead call
platform_driver_register() from subsys_initcall() to make sure this module
has been loaded before MTD partition parsing starts.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes for v2:
- Move fsl_ifc in driver/memory
Changes for v3:
- move device tree bindings to memory
Changes for v4: Rebased to
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Changes for v5:
- Moved powerpc/Kconfig option to driver/memory
.../{powerpc => memory-controllers}/fsl/ifc.txt | 0
arch/powerpc/Kconfig | 4 ----
arch/powerpc/sysdev/Makefile | 1 -
drivers/memory/Kconfig | 4 ++++
drivers/memory/Makefile | 1 +
{arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c | 8 ++++++--
drivers/mtd/nand/fsl_ifc_nand.c | 2 +-
.../include/asm => include/linux}/fsl_ifc.h | 0
8 files changed, 12 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => memory-controllers}/fsl/ifc.txt (100%)
rename {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c (98%)
rename {arch/powerpc/include/asm => include/linux}/fsl_ifc.h (100%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
rename to Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b44b52c..83fb8b3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -725,10 +725,6 @@ config FSL_LBC
controller. Also contains some common code used by
drivers for specific local bus peripherals.
-config FSL_IFC
- bool
- depends on FSL_SOC
-
config FSL_GTM
bool
depends on PPC_83xx || QUICC_ENGINE || CPM2
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index f67ac90..afbcc37 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o fsl_mpic_err.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_IFC) += fsl_ifc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 29a11db..b33bb0e 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -50,4 +50,8 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config FSL_IFC
+ bool
+ depends on FSL_SOC
+
endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 969d923..f2bf25c 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,6 +6,7 @@ ifeq ($(CONFIG_DDR),y)
obj-$(CONFIG_OF) += of_memory.o
endif
obj-$(CONFIG_TI_EMIF) += emif.o
+obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/arch/powerpc/sysdev/fsl_ifc.c b/drivers/memory/fsl_ifc.c
similarity index 98%
rename from arch/powerpc/sysdev/fsl_ifc.c
rename to drivers/memory/fsl_ifc.c
index d7fc722..135a950 100644
--- a/arch/powerpc/sysdev/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -30,8 +30,8 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/fsl_ifc.h>
#include <asm/prom.h>
-#include <asm/fsl_ifc.h>
struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
@@ -299,7 +299,11 @@ static struct platform_driver fsl_ifc_ctrl_driver = {
.remove = fsl_ifc_ctrl_remove,
};
-module_platform_driver(fsl_ifc_ctrl_driver);
+static int __init fsl_ifc_init(void)
+{
+ return platform_driver_register(&fsl_ifc_ctrl_driver);
+}
+subsys_initcall(fsl_ifc_init);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Freescale Semiconductor");
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 4335577..865b323 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -30,7 +30,7 @@
#include <linux/mtd/nand.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/nand_ecc.h>
-#include <asm/fsl_ifc.h>
+#include <linux/fsl_ifc.h>
#define FSL_IFC_V1_1_0 0x01010000
#define ERR_BYTE 0xFF /* Value returned for read
diff --git a/arch/powerpc/include/asm/fsl_ifc.h b/include/linux/fsl_ifc.h
similarity index 100%
rename from arch/powerpc/include/asm/fsl_ifc.h
rename to include/linux/fsl_ifc.h
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2][v5] powerpc/config: Enable memory driver
From: Prabhakar Kushwaha @ 2014-01-18 6:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, linux-kernel, Prabhakar Kushwaha
As Freescale IFC controller has been moved to driver to driver/memory.
So enable memory driver in powerpc config
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
Changes for v2: Sending as it is
Changes for v3: Sending as it is
Changes for v4: Rebased to
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
changes for v5:
- Rebased to branch next of
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
4 files changed, 4 insertions(+)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index bbd794d..087d437 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -142,6 +142,7 @@ CONFIG_RTC_DRV_DS3232=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_UIO=y
CONFIG_STAGING=y
+CONFIG_MEMORY=y
CONFIG_VIRT_DRIVERS=y
CONFIG_FSL_HV_MANAGER=y
CONFIG_EXT2_FS=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 63508dd..25b03f8 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -129,6 +129,7 @@ CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
+CONFIG_MEMORY=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_ISO9660_FS=m
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 83d3550..cba638c 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -216,6 +216,7 @@ CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
+CONFIG_MEMORY=y
# CONFIG_NET_DMA is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 4b68629..e315b8a 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -217,6 +217,7 @@ CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
+CONFIG_MEMORY=y
# CONFIG_NET_DMA is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc: Make sure "cache" directory is removed when offlining cpu
From: Paul Mackerras @ 2014-01-18 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
The code in remove_cache_dir() is supposed to remove the "cache"
subdirectory from the sysfs directory for a CPU when that CPU is
being offlined. It tries to do this by calling kobject_put() on
the kobject for the subdirectory. However, the subdirectory only
gets removed once the last reference goes away, and the reference
being put here may well not be the last reference. That means
that the "cache" subdirectory may still exist when the offlining
operation has finished. If the same CPU subsequently gets onlined,
the code tries to add a new "cache" subdirectory. If the old
subdirectory has not yet been removed, we get a WARN_ON in the
sysfs code, with stack trace, and an error message printed on the
console. Further, we ultimately end up with an online cpu with no
"cache" subdirectory.
This fixes it by doing an explicit kobject_del() at the point where
we want the subdirectory to go away. kobject_del() removes the sysfs
directory even though the object still exists in memory. The object
will get freed at some point in the future. A subsequent onlining
operation can create a new sysfs directory, even if the old object
still exists in memory, without causing any problems.
Cc: stable@vger.kernel.org # v3.0+
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/kernel/cacheinfo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 6549327..bfb8236 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -794,6 +794,9 @@ static void remove_cache_dir(struct cache_dir *cache_dir)
{
remove_index_dirs(cache_dir);
+ /* Remove cache dir from sysfs */
+ kobject_del(cache_dir->kobj);
+
kobject_put(cache_dir->kobj);
kfree(cache_dir);
--
1.8.5.2
^ permalink raw reply related
* RE: [PATCH v9] clk: corenet: Adds the clock binding
From: Yuantian Tang @ 2014-01-20 2:26 UTC (permalink / raw)
To: Scott Wood
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1390007187.24905.293.camel@snotra.buserror.net>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IDIwMTTlubQx5pyIMTjml6Ug5pif5pyf5YWtIDk6MDYNCj4gVG86IFRhbmcgWXVh
bnRpYW4tQjI5OTgzDQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgZ2FsYWtAa2VybmVsLmNyYXNo
aW5nLm9yZzsgbWFyay5ydXRsYW5kQGFybS5jb207DQo+IGRldmljZXRyZWVAdmdlci5rZXJuZWwu
b3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgTGkgWWFuZy1MZW8tDQo+IFI1ODQ3
Mg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY5XSBjbGs6IGNvcmVuZXQ6IEFkZHMgdGhlIGNsb2Nr
IGJpbmRpbmcNCj4gDQo+IE9uIE1vbiwgMjAxNC0wMS0xMyBhdCAxNjoxNiArMDgwMCwgVGFuZyBZ
dWFudGlhbiB3cm90ZToNCj4gPiArRXhhbXBsZSBmb3IgY2xvY2sgYmxvY2sgYW5kIGNsb2NrIHBy
b3ZpZGVyOg0KPiA+ICsvIHsNCj4gPiArCWNsb2NrZ2VuOiBnbG9iYWwtdXRpbGl0aWVzQGUxMDAw
IHsNCj4gPiArCQljb21wYXRpYmxlID0gImZzbCxwNTAyMC1jbG9ja2dlbiIsICJmc2wscW9yaXEt
Y2xvY2tnZW4tMS4wIjsNCj4gPiArCQlyYW5nZXMgPSA8MHgwIDB4ZTEwMDAgMHgxMDAwPjsNCj4g
PiArCQljbG9jay1mcmVxdWVuY3kgPSAxMzMzMzM7DQo+IA0KPiBNaXNzaW5nIDw+IGFyb3VuZCAx
MzMzMzMsIGFuZCB0aGUgYWN0dWFsIHA1MDIwZHMgaW5wdXQgY2xvY2sgKGJhc2VkIG9uDQo+IG9i
c2VydmluZyB3aGF0IFUtQm9vdCBmaWxscyBpbikgaXMgMTMzMzMzMzMzLCBub3QgMTMzMzMzLg0K
PiANClNvcnJ5LCA6KA0KDQo+IEknbGwgZml4IHdoZW4gYXBwbHlpbmcuDQo+IA0KVGhhbmsgeW91
IHZlcnkgbXVjaC4NCg0KUmVnYXJkcywNCll1YW50aWFuDQoNCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: linuxppc-dev@lists.ozlabs.org
From: Olof Johansson @ 2014-01-20 4:16 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: linuxppc-dev
In-Reply-To: <52D970C0.3020600@xenosoft.de>
Hi,
On Fri, Jan 17, 2014 at 10:04 AM, Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
[Removed some fairly verbose patch description]
> diff -rupN linux-3.13/arch/powerpc/platforms/pasemi/Kconfig
> linux-3.13-nemo/arch/powerpc/platforms/pasemi/Kconfig
> --- linux-3.13/arch/powerpc/platforms/pasemi/Kconfig 2013-12-06
> 18:34:04.000000000 +0100
> +++ linux-3.13-nemo/arch/powerpc/platforms/pasemi/Kconfig 2013-12-14
> 10:31:19.896353725 +0100
> @@ -14,6 +14,13 @@ config PPC_PASEMI
> menu "PA Semi PWRficient options"
> depends on PPC_PASEMI
>
> +config PPC_PASEMI_SB600
> + bool "Nemo SB600 South Bridge Support"
> + depends on PPC_PASEMI
> + select PPC_I8259
> + help
> + Workarounds for the SB600 South Bridge.
> +
> config PPC_PASEMI_IOMMU
> bool "PA Semi IOMMU support"
> depends on PPC_PASEMI
>
> Is it possible to integrate the support of the Nemo board to the official
> kernel sources? Thanks a lot to this list for the help to solve the boot
> problems with the kernel 3.13. Sorry, my English isn't very well. I hope you
> understand my email. But I'll learn more English. I promise it gets better.
We'd be happy to integrate support for it, but you should expect to
have to rework the patches to a form where they will be to our liking.
Your english seems to be quite sufficient so far, there are many
kernel developers who do not have english as main language. Ask if you
need something clarified when we reply to you.
Unfortunately, this patch alone doesn't do much good -- it just adds a
kernel config option without telling us much about what it's doing. It
would make more sense to also include the code changes that the config
option will result in (or makefile changes and c file additions, if
any).
In this case, isn't the southbridge just another PCI-e device? I don't
see how we would need a machine-specific configuration option to
enable it, but seeing the code changes that go along with it would
help explain to us.
-Olof
^ permalink raw reply
* RE: [PATCH 3/3] powerpc/fsl: Use the new interface to save or restore registers
From: Dongsheng.Wang @ 2014-01-20 5:57 UTC (permalink / raw)
To: Scott Wood
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org,
chenhui.zhao@freescale.com
In-Reply-To: <1389842143.24905.195.camel@snotra.buserror.net>
PiA+ID4gPiBVc2UgZnNsX2NwdV9zdGF0ZV9zYXZlL2ZzbF9jcHVfc3RhdGVfcmVzdG9yZSB0byBz
YXZlL3Jlc3RvcmUgcmVnaXN0ZXJzLg0KPiA+ID4gPiBVc2UgdGhlIGZ1bmN0aW9ucyB0byBzYXZl
L3Jlc3RvcmUgcmVnaXN0ZXJzLCBzbyB3ZSBkb24ndCBuZWVkIHRvDQo+ID4gPiA+IG1haW50YWlu
IHRoZSBjb2RlLg0KPiA+ID4gPg0KPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBXYW5nIERvbmdzaGVu
ZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiA+DQo+ID4gPiBJcyB0aGVyZSBh
bnkgZnVuY3Rpb25hbCBjaGFuZ2Ugd2l0aCB0aGlzIHBhdGNoc2V0IChlLmcuIHN1c3BlbmQNCj4g
PiA+IHN1cHBvcnRlZCBvbiBjaGlwcyB3aGVyZSBpdCB3YXNuJ3QgYmVmb3JlKSwgb3IgaXMgaXQg
anVzdCBjbGVhbnVwPyAgQQ0KPiA+ID4gY292ZXIgbGV0dGVyIHdvdWxkIGJlIHVzZWZ1bCB0byBk
ZXNjcmliZSB0aGUgcHVycG9zZSBvZiB0aGUgb3ZlcmFsbA0KPiA+ID4gcGF0Y2hzZXQgd2hlbiBp
dCBpc24ndCBvYnZpb3VzLg0KPiA+ID4NCj4gPg0KPiA+IFllcywganVzdCBjbGVhbnVwLi4NCj4g
DQo+IEl0IHNlZW1zIHRvIGJlIGludHJvZHVjaW5nIGNvbXBsZXhpdHkgcmF0aGVyIHRoYW4gcmVt
b3ZpbmcgaXQuICBJcyB0aGlzDQo+IGNsZWFudXAgbmVlZGVkIHRvIHByZXBhcmUgZm9yIGFkZGlu
ZyBuZXcgZnVuY3Rpb25hbGl0eT8NCj4gDQo+IFBsdXMsIEknbSBza2VwdGljYWwgdGhhdCB0aGlz
IGlzIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50LiAgSXQgbG9va3MgbGlrZQ0KPiB0aGUgbmV3IGNv
ZGUgc2F2ZXMgYSBsb3QgbW9yZSB0aGFuIHRoZSBvbGQgY29kZSBkb2VzLiAgV2h5Pw0KPiANCg0K
QWN0dWFsbHksIEkgd2FudCB0byB0YWtlIGEgcHJhY3RpY2FsIGV4YW1wbGUgdG8gcHVzaCB0aGUg
c2F2ZS9yZXN0b3JlIHBhdGNoZXMuDQpBbmQgdGhpcyBpcyBhbHNvIHJlYXNvbmFibGUgZm9yIDMy
Yml0LWhpYmVybmF0aW9uLCB0aGUgY29kZSBpcyBtb3JlIGNsZWFuLiA6KQ0KSSB0aGluayBJIG5l
ZWQgdG8gY2hhbmdlIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcGF0Y2guDQoNCj4gPiA+ID4gKw0K
PiA+ID4gPiArCS8qIFJlc3RvcmUgYmFzZSByZWdpc3RlciAqLw0KPiA+ID4gPiArCWxpCXI0LCAw
DQo+ID4gPiA+ICsJYmwJZnNsX2NwdV9zdGF0ZV9yZXN0b3JlDQo+ID4gPg0KPiA+ID4gV2h5IGFy
ZSB5b3UgY2FsbGluZyBhbnl0aGluZyB3aXRoICJmc2wiIGluIHRoZSBuYW1lIGZyb20gY29kZSB0
aGF0IGlzDQo+ID4gPiBzdXBwb3NlZCB0byBiZSBmb3IgYWxsIGJvb2tlPw0KPiA+ID4NCj4gPiBF
MjAwLCBFMzAwIG5vdCBzdXBwb3J0Lg0KPiA+IFN1cHBvcnQgRTUwMCwgRTUwMHYyLCBFNTAwTUMs
IEU1NTAwLCBFNjUwMC4NCj4gPg0KPiA+IERvIHlvdSBoYXZlIGFueSBzdWdnZXN0aW9ucyBhYm91
dCB0aGlzPw0KPiANCj4gV2hhdCBhYm91dCBub24tRlNMIGJvb2tlIHN1Y2ggYXMgNDR4Pw0KPiAN
Cj4gT3IgaWYgdGhpcyBmaWxlIG5ldmVyIHN1cHBvcnRlZCA0NHgsIHJlbmFtZSBpdCBhcHByb3By
aWF0ZWx5Lg0KPiANCkN1cnJlbnRseSBkb2VzIG5vdCBzdXBwb3J0LiBvayBjaGFuZ2UgdGhlIG5h
bWUgZmlyc3QsIGlmIGxhdGVyIHN1cHBvcnQsIGFuZA0KdGhlbiBhZ2FpbiB0byBtb2RpZnkgdGhl
IG5hbWUgb2YgdGhpcyBmdW5jdGlvbi4NCg0KSG93IGFib3V0IDg1eHhfY3B1X3N0YXRlX3Jlc3Rv
cmU/DQoNClRoYW5rcywNCi1Eb25nc2hlbmcNCg==
^ permalink raw reply
* RE: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore the core registers
From: Dongsheng.Wang @ 2014-01-20 6:03 UTC (permalink / raw)
To: Scott Wood
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org,
chenhui.zhao@freescale.com
In-Reply-To: <1389842249.24905.196.camel@snotra.buserror.net>
PiA+ID4gV2hhdCBpcyB0aGVyZSB0aGF0IGlzIHNwZWNmaWMgdG8gYSBwYXJ0aWN1bGFyIGNvcmUg
dHlwZSB0aGF0IGNhbid0IGJlDQo+IGhhbmRsZWQNCj4gPiA+IGZyb20gQyBjb2RlPw0KPiA+ID4N
Cj4gPg0KPiA+IEluIHRoZSBjb250ZXh0IG9mIHRoZSBjYWxsaW5nLCBtYXliZSBub3QgaW4gQyBl
bnZpcm9ubWVudC4oRGVlcCBzbGVlcCB3aXRob3V0DQo+ID4gQyBlbnZpcm9ubWVudCB3aGVuIGNh
bGxpbmcgdGhvc2UgaW50ZXJmYWNlcykNCj4gDQo+IENvdWxkIHlvdSBwcm92aWRlIGEgY29uY3Jl
dGUgZXhhbXBsZT8NCj4gDQoNCjopDQpEZWVwIHNsZWVwLCB0aGUgcGF0Y2hlcyB3aWxsIGNvbWVz
IG91dCBzb29uLg0KDQo+ID4gPiA+ICsJLyoNCj4gPiA+ID4gKwkgKiBOZWVkIHRvIHNhdmUgZmxv
YXQtcG9pbnQgcmVnaXN0ZXJzIGlmIE1TUltGUF0gPSAxLg0KPiA+ID4gPiArCSAqLw0KPiA+ID4g
PiArCW1mbXNyCXIxMg0KPiA+ID4gPiArCWFuZGkuCXIxMiwgcjEyLCBNU1JfRlANCj4gPiA+ID4g
KwliZXEJMWYNCj4gPiA+ID4gKwlkb19zcl9mcHJfcmVncyhzYXZlKQ0KPiA+ID4NCj4gPiA+IEMg
Y29kZSBzaG91bGQgaGF2ZSBhbHJlYWR5IGVuc3VyZWQgdGhhdCBNU1JbRlBdIGlzIG5vdCAxIChh
bmQgdGh1cyB0aGUgRlANCj4gPiA+IGNvbnRleHQgaGFzIGJlZW4gc2F2ZWQpLg0KPiA+ID4NCj4g
Pg0KPiA+IFllcywgcmlnaHQuIEJ1dCBJIG1lYW4gaWYgdGhlIEZQIHN0aWxsIHVzZSBpbiBjb3Jl
IHNhdmUgZmxvdywgd2UgbmVlZCB0byBzYXZlDQo+IGl0Lg0KPiA+IEluIHRoaXMgcHJvY2Vzcywg
aSBkb24ndCBjYXJlIHdoYXQgb3RoZXIgY29kZSBkbywgd2UgbmVlZCB0byBmb2N1cyBvbiBub3QN
Cj4gbG9zaW5nDQo+ID4gdmFsdWFibGUgZGF0YS4NCj4gDQo+IEl0IGlzIG5vdCBhbGxvd2VkIHRv
IHVzZSBGUCBhdCB0aGF0IHBvaW50Lg0KPiANCklmIE1TUltGUF0gbm90IGFjdGl2ZSwgdGhhdCBp
cyBGUCBub3QgYWxsb3dlZCB0byB1c2UuDQpCdXQgaGVyZSBpcyBhIG5vcm1hbCBqdWRnbWVudCwg
aWYgTVNSW0ZQXSBpcyBhY3RpdmUsIHRoaXMgbWVhbnMgdGhhdCB0aGUgZmxvYXRpbmcNCnBvaW50
IG1vZHVsZSBpcyBiZWluZyB1c2VkLiBJIG9mZmVyIGlzIGEgZnVuY3Rpb24gb2YgdGhlIGludGVy
ZmFjZSwgd2UgZG9uJ3Qga25vdw0Kd2hlcmUgaXMgdGhlIGZ1bmN0aW9uIHdpbGwgYmUgY2FsbGVk
LiBKdXN0IGJlY2F1c2Ugd2UgY2FsbCB0aGlzIGZ1bmN0aW9uIGluIHRoZQ0KY29udGV4dCBvZiB1
bmNlcnRhaW50eSwgd2UgbmVlZCB0aGlzIGp1ZGdtZW50IHRvIGVuc3VyZSB0aGF0IG5vIGRhdGEg
aXMgbG9zdC4NCg0KVGhhbmtzLA0KLURvbmdzaGVuZw0K
^ permalink raw reply
* [PATCH] powerpc/perf: Define perf_event_print_debug() to print PMU register values
From: Michael Ellerman @ 2014-01-20 6:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: khandual
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Currently the sysrq ShowRegs command does not print any PMU registers as
we have an empty definition for perf_event_print_debug(). This patch
defines perf_event_print_debug() to print various PMU registers.
Example output:
CPU: 0 PMU registers, ppmu = POWER7 n_counters = 6
PMC1: 00000000 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000
PMC5: 00000000 PMC6: 00000000 PMC7: deadbeef PMC8: deadbeef
MMCR0: 0000000080000000 MMCR1: 0000000000000000 MMCRA: 0f00000001000000
SIAR: 0000000000000000 SDAR: 0000000000000000 SIER: 0000000000000000
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
[mpe: Fix 32 bit build and rework formatting for compactness]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/perf_event_server.h | 1 +
arch/powerpc/perf/core-book3s.c | 55 ++++++++++++++++++++++++++--
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 3fd2f1b..9ed73714 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -14,6 +14,7 @@
#include <linux/device.h>
#include <uapi/asm/perf_event.h>
+/* Update perf_event_print_debug() if this changes */
#define MAX_HWEVENTS 8
#define MAX_EVENT_ALTERNATIVES 8
#define MAX_LIMITED_HWCOUNTERS 2
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 29b89e8..ff3d8a4 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -563,10 +563,6 @@ out:
static void perf_event_interrupt(struct pt_regs *regs);
-void perf_event_print_debug(void)
-{
-}
-
/*
* Read one performance monitor counter (PMC).
*/
@@ -645,6 +641,57 @@ static void write_pmc(int idx, unsigned long val)
}
}
+/* Called from sysrq_handle_showregs() */
+void perf_event_print_debug(void)
+{
+ unsigned long sdar, sier, flags;
+ u32 pmcs[MAX_HWEVENTS];
+ int i;
+
+ if (!ppmu->n_counter)
+ return;
+
+ local_irq_save(flags);
+
+ pr_info("CPU: %d PMU registers, ppmu = %s n_counters = %d",
+ smp_processor_id(), ppmu->name, ppmu->n_counter);
+
+ for (i = 0; i < ppmu->n_counter; i++)
+ pmcs[i] = read_pmc(i + 1);
+
+ for (; i < MAX_HWEVENTS; i++)
+ pmcs[i] = 0xdeadbeef;
+
+ pr_info("PMC1: %08x PMC2: %08x PMC3: %08x PMC4: %08x\n",
+ pmcs[0], pmcs[1], pmcs[2], pmcs[3]);
+
+ if (ppmu->n_counter > 4)
+ pr_info("PMC5: %08x PMC6: %08x PMC7: %08x PMC8: %08x\n",
+ pmcs[4], pmcs[5], pmcs[6], pmcs[7]);
+
+ pr_info("MMCR0: %016lx MMCR1: %016lx MMCRA: %016lx\n",
+ mfspr(SPRN_MMCR0), mfspr(SPRN_MMCR1), mfspr(SPRN_MMCRA));
+
+ sdar = sier = 0;
+#ifdef CONFIG_PPC64
+ sdar = mfspr(SPRN_SDAR);
+
+ if (ppmu->flags & PPMU_HAS_SIER)
+ sier = mfspr(SPRN_SIER);
+
+ if (ppmu->flags & PPMU_EBB) {
+ pr_info("MMCR2: %016lx EBBHR: %016lx\n",
+ mfspr(SPRN_MMCR2), mfspr(SPRN_EBBHR));
+ pr_info("EBBRR: %016lx BESCR: %016lx\n",
+ mfspr(SPRN_EBBRR), mfspr(SPRN_BESCR));
+ }
+#endif
+ pr_info("SIAR: %016lx SDAR: %016lx SIER: %016lx\n",
+ mfspr(SPRN_SIAR), sdar, sier);
+
+ local_irq_restore(flags);
+}
+
/*
* Check if a set of events can all go on the PMU at once.
* If they can't, this will look at alternative codes for the events
--
1.8.3.2
^ permalink raw reply related
* Re: KGDB panics on p2020 target
From: "“tiejun.chen”" @ 2014-01-20 8:25 UTC (permalink / raw)
To: Arun Chandran, linuxppc-dev
In-Reply-To: <CAFdej02gyEuDDWwBa4wG01NVf_-wOysdWha+mi+Z+0YafiUAGQ@mail.gmail.com>
On 01/17/2014 03:52 PM, Arun Chandran wrote:
> Hi,
>
> I am testing kgdb on freescale p2020 target.
>
> In target
> ------------
>
> 1)
> root@freescale-p2020ds:~# uname -a
> Linux freescale-p2020ds 3.10.20-rt14+ #9 SMP Thu Jan 16 16:32:15 IST 2014
> ppc GNU/Linux
>
> 2)
> root@freescale-p2020ds:~# cat /proc/cpuinfo
> processor : 0
> cpu : e500v2
> clock : 999.990008MHz
> revision : 4.0 (pvr 8021 1040)
> bogomips : 124.99
>
> processor : 1
> cpu : e500v2
> clock : 999.990008MHz
> revision : 4.0 (pvr 8021 1040)
> bogomips : 124.99
>
> total bogomips : 249.99
> timebase : 62499376
> platform : P2020 DS
> model : fsl,P2020DS
> Memory : 768 MB
>
> 3)
> freescale-p2020ds:~# echo "ttyS1,115200" >
> /sys/module/kgdboc/parameters/kgdoc
>
> 4) I set up host (settings given below); Then I send "SysRq : DEBUG"
>
> In host
> ----------
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> kgdb_breakpoint () at kernel/debug/debug_core.c:1013
> 1013 arch_kgdb_breakpoint();
> (gdb) b sys_sync
> Breakpoint 1 at 0xc0167288: file fs/sync.c, line 103.
> (gdb) c
> Continuing.
>
> I am able to take control in host; after that I am setting breakpoint at
> "sys_sync"
>
> In target
> ------------
> root@freescale-p2020ds:~# for i in 1 2 3 4 5 6 7 8 9
>> do
>> sync
>> done
>
> In host
> ----------
> Breakpoint 1, sys_sync () at fs/sync.c:103
> 103 {
> (gdb) c
> Continuing.
>
> Breakpoint is hit only one time instead of 9 times; after that target hangs.
I recommend you try upstream to take a further look at this, instead of that
Freescale distribution. As I recall currently KGDB works well in 85xx case in ML.
>
> Then i tried to send "SysRq : DEBUG" in target kernel panics.
>
> I have pasted the panic below.
>
> #########################################
> SysRq : DEBUG
> Kernel panic - not syncing: Recursive entry to debugger
The kernel already trap into kgdb_handle_exception() with the debug exception
while triggering that break point, but again you trigger another debug exception
by SysRq. Actually KGDB can't handle such this recursive behavior, so KGDB
always call kgdb_reenter_check() to prevent this scenario with this call trace.
static int kgdb_reenter_check(struct kgdb_state *ks)
{
unsigned long addr;
if (atomic_read(&kgdb_active) != raw_smp_processor_id())
return 0;
...
if (exception_level > 1) {
dump_stack();
panic("Recursive entry to debugger");
}
Tiejun
> CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
> Call Trace:
> [effe5d10] [c0008060] show_stack+0x4c/0x168 (unreliable)
> [effe5d50] [c0588878] panic+0xe4/0x224
> [effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
> [effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
> [effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
> [effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
> --- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
> LR = __handle_sysrq+0x154/0x1cc
> [effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
> [effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
> [effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
> [effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
> [effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
> [effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
> [effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
> [effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
> [c4f91b10] [c0004f60] do_IRQ+0x150/0x224
> [c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
> --- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
> LR = rpcauth_lookup_credcache+0xb8/0x2a4
> [c4f91c00] [24002424] 0x24002424 (unreliable)
> [c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
> [c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
> [c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
> [c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
> [c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
> [c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
> [c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
> [c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
> [c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
> [c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
> [c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
> [c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
> [c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
> [c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
> [c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
> --- Exception: c01 at 0xff08a98
> LR = 0xfed53e8
> CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
> Call Trace:
> [effe5bb0] [c0008060] show_stack+0x4c/0x168 (unreliable)
> [effe5bf0] [c00b2cac] kgdb_handle_exception+0x1c4/0x1f8
> [effe5c40] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
> [effe5c50] [c057e7e0] program_check_exception+0x10c/0x264
> [effe5c60] [c000f660] ret_from_except_full+0x0/0x4c
> --- Exception: 700 at kgdb_panic_event+0x1c/0x3c
> LR = notifier_call_chain+0x60/0xb0
> [effe5d20] [00000000] (nil) (unreliable)
> [effe5d40] [c05819dc] __atomic_notifier_call_chain+0x14/0x24
> [effe5d50] [c05888a8] panic+0x114/0x224
> [effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
> [effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
> [effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
> [effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
> --- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
> LR = __handle_sysrq+0x154/0x1cc
> [effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
> [effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
> [effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
> [effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
> [effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
> [effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
> [effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
> [effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
> [c4f91b10] [c0004f60] do_IRQ+0x150/0x224
> [c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
> --- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
> LR = rpcauth_lookup_credcache+0xb8/0x2a4
> [c4f91c00] [24002424] 0x24002424 (unreliable)
> [c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
> [c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
> [c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
> [c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
> [c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
> [c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
> [c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
> [c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
> [c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
> [c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
> [c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
> [c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
> [c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
> [c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
> [c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
> --- Exception: c01 at 0xff08a98
> LR = 0xfed53e8
>
>
> ########################################################
>
> Could you please share your thoughts on this issue?
>
> I have also attached my kernel .config.
>
> Regards,
> Arun C
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] powerpc: hugetlb: replace __get_cpu_var with get_cpu_var
From: Tiejun Chen @ 2014-01-20 8:39 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
Replace __get_cpu_var safely with get_cpu_var to avoid
the following call trace:
[ 7253.637591] BUG: using smp_processor_id() in preemptible [00000000 00000000]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
[ 7253.637606] Call Trace:
[ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
[ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
[ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
[ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
[ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
[ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
[ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
[ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
[ 7253.637686] --- Exception: c01 at 0xff16004
Signed-off-by: Tiejun Chen<tiejun.chen@windriver.com>
---
arch/powerpc/mm/hugetlbpage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 90bb6d9..eb92365 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -472,12 +472,13 @@ static void hugepd_free(struct mmu_gather *tlb, void *hugepte)
{
struct hugepd_freelist **batchp;
- batchp = &__get_cpu_var(hugepd_freelist_cur);
+ batchp = &get_cpu_var(hugepd_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpumask_equal(mm_cpumask(tlb->mm),
cpumask_of(smp_processor_id()))) {
kmem_cache_free(hugepte_cache, hugepte);
+ put_cpu_var(hugepd_freelist_cur);
return;
}
@@ -491,6 +492,7 @@ static void hugepd_free(struct mmu_gather *tlb, void *hugepte)
call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
*batchp = NULL;
}
+ put_cpu_var(hugepd_freelist_cur);
}
#endif
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] DMA: Freescale: change BWC from 256 bytes to 1024 bytes
From: Vinod Koul @ 2014-01-20 7:43 UTC (permalink / raw)
To: hongbo.zhang
Cc: linux-kernel, scottwood, dmaengine, dan.j.williams, linuxppc-dev
In-Reply-To: <1389852653-8806-1-git-send-email-hongbo.zhang@freescale.com>
On Thu, Jan 16, 2014 at 02:10:53PM +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> Freescale DMA has a feature of BandWidth Control (ab. BWC), which is currently
> 256 bytes and should be changed to 1024 bytes for best DMA throughput.
> Changing BWC from 256 to 1024 will improve DMA performance much, in cases
> whatever one channel is running or multi channels are running simultanously,
> large or small buffers are copied. And this change doesn't impact memory
> access performance remarkably, lmbench tests show that for some cases the
> memory performance are decreased very slightly, while the others are even
> better.
> Tested on T4240.
Applied, thanks
--
~Vinod
^ 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