* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Scott Wood @ 2011-11-18 18:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Zhao Chenhui
In-Reply-To: <54122A43-37D1-438B-A0DD-289B7AE2BA0B@kernel.crashing.org>
On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
>
> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
>
> > On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
> >> From: Li Yang <leoli@freescale.com>
> >>
> >> The timebase sync is not only necessary when using KEXEC. It should also
> >> be used by normal boot up and cpu hotplug. Remove the ifdef added by
> >> the KEXEC patch.
> >
> > Again, no it should not be used by normal boot up (whether KEXEC support
> > is enabled or not). We should only do timebase sync when we actually
> > need to (when we've actually just reset a core), and we should do it the
> > way U-Boot does rather than with smp-tbsync.c.
>
>
> How can we do u-boot bases timebase sync after the system us up and
> running? For example would we losing some ticks of time in the case
> that one core is up and we bring a second core online?
Yes, we'll lose a small handful of ticks relative to wall clock time --
but it'll be the same loss on all cores. It's better than possibly
having the timebase be imperfectly synchronized, and should complete more
quickly.
This is only during intrusive events such as kexec or deep sleep (we only
need to reset the core for jog on mpc8536 which has only one core).
During deep sleep all cores' timebases will be stopped. Kexec is
resetting the kernel; it's not going to care what the old timebase was,
and should resync from RTC.
Even if we end up using this for some future power management mode where
we take down some CPUs to the point their timebase stops, but never take
down others, the time loss should be negligible (for comparison, what's
the error tolerance on the crystal frequency?) and acceptable for what is
still a fairly intrusive and rare event.
-Scott
^ permalink raw reply
* [PATCH 3/3] [v2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-18 17:50 UTC (permalink / raw)
To: kumar.gala, scottwood, linuxppc-dev
In-Reply-To: <1321638601-6861-1-git-send-email-timur@freescale.com>
When the P1022's DIU video controller is active, the pixis must be accessed
in "indirect" mode, which uses localbus chip select addresses.
Switching between the DVI and LVDS monitor ports is handled by the pixis,
so that switching needs to be done via indirect mode.
This has the side-effect of no longer requiring U-Boot to enable the DIU.
Now Linux can enable the DIU all by itself.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 132 ++++++++++++++++++++++++++-----
1 files changed, 110 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index e0280e2..948f7ae 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -29,6 +29,10 @@
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+#define PMUXCR_ELBCDIU_MASK 0xc0000000
+#define PMUXCR_ELBCDIU_NOR16 0x80000000
+#define PMUXCR_ELBCDIU_DIU 0x40000000
+
/*
* Board-specific initialization of the DIU. This code should probably be
* executed when the DIU is opened, rather than in arch code, but the DIU
@@ -46,11 +50,22 @@
#define CLKDVDR_PXCLK_MASK 0x00FF0000
/* Some ngPIXIS register definitions */
+#define PX_CTL 3
+#define PX_BRDCFG0 8
+#define PX_BRDCFG1 9
+
+#define PX_BRDCFG0_ELBC_SPI_MASK 0xc0
+#define PX_BRDCFG0_ELBC_SPI_ELBC 0x00
+#define PX_BRDCFG0_ELBC_SPI_NULL 0xc0
+#define PX_BRDCFG0_ELBC_DIU 0x02
+
#define PX_BRDCFG1_DVIEN 0x80
#define PX_BRDCFG1_DFPEN 0x40
#define PX_BRDCFG1_BACKLIGHT 0x20
#define PX_BRDCFG1_DDCEN 0x10
+#define PX_CTL_ALTACC 0x80
+
/*
* DIU Area Descriptor
*
@@ -129,44 +144,117 @@ static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
*/
static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
- struct device_node *np;
- void __iomem *pixis;
- u8 __iomem *brdcfg1;
+ struct device_node *guts_node;
+ struct device_node *indirect_node = NULL;
+ struct ccsr_guts_85xx __iomem *guts;
+ u8 __iomem *lbc_lcs0_ba = NULL;
+ u8 __iomem *lbc_lcs1_ba = NULL;
+ u8 b;
- np = of_find_compatible_node(NULL, NULL, "fsl,p1022ds-fpga");
- if (!np)
- /* older device trees used "fsl,p1022ds-pixis" */
- np = of_find_compatible_node(NULL, NULL, "fsl,p1022ds-pixis");
- if (!np) {
- pr_err("p1022ds: missing ngPIXIS node\n");
+ /* Map the global utilities registers. */
+ guts_node = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
+ if (!guts_node) {
+ pr_err("p1022ds: missing global utilties device node\n");
return;
}
- pixis = of_iomap(np, 0);
- if (!pixis) {
- pr_err("p1022ds: could not map ngPIXIS registers\n");
- return;
+ guts = of_iomap(guts_node, 0);
+ if (!guts) {
+ pr_err("p1022ds: could not map global utilties device\n");
+ goto exit;
+ }
+
+ indirect_node = of_find_compatible_node(NULL, NULL,
+ "fsl,p1022ds-indirect-pixis");
+ if (!indirect_node) {
+ pr_err("p1022ds: missing pixis indirect mode node\n");
+ goto exit;
}
- brdcfg1 = pixis + 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
+
+ lbc_lcs0_ba = of_iomap(indirect_node, 0);
+ if (!lbc_lcs0_ba) {
+ pr_err("p1022ds: could not map localbus chip select 0\n");
+ goto exit;
+ }
+
+ lbc_lcs1_ba = of_iomap(indirect_node, 1);
+ if (!lbc_lcs1_ba) {
+ pr_err("p1022ds: could not map localbus chip select 1\n");
+ goto exit;
+ }
+
+ /* Make sure we're in indirect mode first. */
+ if ((in_be32(&guts->pmuxcr) & PMUXCR_ELBCDIU_MASK) !=
+ PMUXCR_ELBCDIU_DIU) {
+ struct device_node *pixis_node;
+ void __iomem *pixis;
+
+ pixis_node =
+ of_find_compatible_node(NULL, NULL, "fsl,p1022ds-fpga");
+ if (!pixis_node) {
+ pr_err("p1022ds: missing pixis node\n");
+ goto exit;
+ }
+
+ pixis = of_iomap(pixis_node, 0);
+ of_node_put(pixis_node);
+ if (!pixis) {
+ pr_err("p1022ds: could not map pixis registers\n");
+ goto exit;
+ }
+
+ /* Enable indirect PIXIS mode. */
+ setbits8(pixis + PX_CTL, PX_CTL_ALTACC);
+ iounmap(pixis);
+
+ /* Switch the board mux to the DIU */
+ out_8(lbc_lcs0_ba, PX_BRDCFG0); /* BRDCFG0 */
+ b = in_8(lbc_lcs1_ba);
+ b |= PX_BRDCFG0_ELBC_DIU;
+ out_8(lbc_lcs1_ba, b);
+
+ /* Set the chip mux to DIU mode. */
+ clrsetbits_be32(&guts->pmuxcr, PMUXCR_ELBCDIU_MASK,
+ PMUXCR_ELBCDIU_DIU);
+ in_be32(&guts->pmuxcr);
+ }
+
switch (port) {
case FSL_DIU_PORT_DVI:
- printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
- clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
- PX_BRDCFG1_DVIEN);
+ out_8(lbc_lcs0_ba, PX_BRDCFG1);
+ b = in_8(lbc_lcs1_ba);
+ b &= ~(PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT);
+ b |= PX_BRDCFG1_DVIEN;
+ out_8(lbc_lcs1_ba, b);
break;
case FSL_DIU_PORT_LVDS:
- printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
+ /*
+ * LVDS also needs backlight enabled, otherwise the display
+ * will be blank.
+ */
/* Enable the DFP port, disable the DVI and the backlight */
- clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
- PX_BRDCFG1_DFPEN);
+ out_8(lbc_lcs0_ba, PX_BRDCFG1);
+ b = in_8(lbc_lcs1_ba);
+ b &= ~PX_BRDCFG1_DVIEN;
+ b |= PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT;
+ out_8(lbc_lcs1_ba, b);
break;
default:
pr_err("p1022ds: unsupported monitor port %i\n", port);
}
- iounmap(pixis);
+exit:
+ if (lbc_lcs1_ba)
+ iounmap(lbc_lcs1_ba);
+ if (lbc_lcs0_ba)
+ iounmap(lbc_lcs0_ba);
+ if (guts)
+ iounmap(guts);
+
+ of_node_put(indirect_node);
+ of_node_put(guts_node);
}
/**
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/3] powerpc/85xx: p1022ds: disable the NOR flash node if video is enabled
From: Timur Tabi @ 2011-11-18 17:49 UTC (permalink / raw)
To: kumar.gala, scottwood, linuxppc-dev
The Freescale P1022 has a unique pin muxing "feature" where the DIU video
controller's video signals are muxed with 24 of the local bus address signals.
When the DIU is enabled, the bulk of the local bus is disabled, preventing
access to memory-mapped devices like NOR flash and the pixis FPGA.
Therefore, if the DIU is going to be enabled, then memory-mapped devices on
the localbus, like NOR flash, need to be disabled.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 70 ++++++++++++++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index fda1571..e0280e2 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -270,6 +270,54 @@ void __init p1022_ds_pic_init(void)
void __init mpc85xx_smp_init(void);
#endif
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/*
+ * Disables a node in the device tree.
+ *
+ * This function is called before kmalloc() is available, and it's only called
+ * once, so we instead of allocating the new property object via the bootmem
+ * allocator, we just create a static local variable.
+ */
+static void __init disable_one_node(struct device_node *np)
+{
+ struct property *old;
+ static struct property new = {
+ .name = "status",
+ .value = "disabled",
+ .length = sizeof("disabled"),
+ };
+
+ old = of_find_property(np, new.name, NULL);
+ if (old)
+ prom_update_property(np, &new, old);
+ else
+ prom_add_property(np, &new);
+}
+
+/* TRUE if there is a "video=fslfb" command-line parameter. */
+static bool fslfb;
+
+/*
+ * Search for a "video=fslfb" command-line parameter, and set 'fslfb' to
+ * true if we find it.
+ *
+ * We need to use early_param() instead of __setup() because the normal
+ * __setup() gets called to late. However, early_param() gets called very
+ * early, before the device tree is unflattened, so all we can do now is set a
+ * global variable. Later on, p1022_ds_setup_arch() will use that variable
+ * to determine if we need to update the device tree.
+ */
+static int __init early_video_setup(char *options)
+{
+ fslfb = (strncmp(options, "fslfb:", 6) == 0);
+
+ return 0;
+}
+early_param("video", early_video_setup);
+
+#endif
+
/*
* Setup the architecture
*/
@@ -307,6 +355,28 @@ static void __init p1022_ds_setup_arch(void)
diu_ops.set_monitor_port = p1022ds_set_monitor_port;
diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
diu_ops.valid_monitor_port = p1022ds_valid_monitor_port;
+
+ /*
+ * Delete the NOR flash node if there is video=fslfb... command-line
+ * parameter. When the DIU is active, NOR flash is unavailable, so we
+ * have to delete the node before the MTD driver loads.
+ */
+ if (fslfb) {
+ struct device_node *np =
+ of_find_compatible_node(NULL, NULL, "fsl,p1022-elbc");
+
+ if (np) {
+ np = of_find_compatible_node(np, NULL, "cfi-flash");
+ if (np) {
+ pr_info("p1022ds: disabling %s node",
+ np->full_name);
+ disable_one_node(np);
+ of_node_put(np);
+ }
+ }
+
+ }
+
#endif
#ifdef CONFIG_SMP
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/3] powerpc/85xx: add pixis indirect mode device tree node
From: Timur Tabi @ 2011-11-18 17:50 UTC (permalink / raw)
To: kumar.gala, scottwood, linuxppc-dev
In-Reply-To: <1321638601-6861-1-git-send-email-timur@freescale.com>
The Freescale P1022 has a unique pin muxing "feature" where the DIU video
controller's video signals are muxed with 24 of the local bus address signals.
When the DIU is enabled, the bulk of the local bus is disabled, preventing
access to memory-mapped devices like NOR flash and the pixis FPGA.
In this situation, the pixis supports "indirect mode", which allows access
to the pixis itself by reading/writing addresses on specific local bus
chip selects. CS0 is used to select which pixis register to access, and
CS1 is used to read/write the value.
To support this, we introduce another board-control child node of the
localbus node that contains a 'reg' property for CS0 and CS1. This will
produce the correct physical addresses for CS0 and CS1.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/p1022ds.dts | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
index 24a73e9..3e85d8c 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -24,6 +24,20 @@
0x2 0x0 0xf 0xffa00000 0x00040000
0x3 0x0 0xf 0xffdf0000 0x00008000>;
+ /*
+ * This node is used to access the pixis via "indirect" mode,
+ * which is done by writing the pixis register index to chip
+ * select 0 and the value to/from chip select 1. Indirect
+ * mode is the only way to access the pixis when DIU video
+ * is enabled. Note that this assumes that the first column
+ * of the 'ranges' property above is the chip select number.
+ */
+ board-control@0,0 {
+ compatible = "fsl,p1022ds-indirect-pixis";
+ reg = <0x0 0x0 1 /* CS0 */
+ 0x1 0x0 1>; /* CS1 */
+ };
+
nor@0,0 {
#address-cells = <1>;
#size-cells = <1>;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-18 17:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111117224558.GA18848@schlenkerla.am.freescale.net>
Scott Wood wrote:
>> > How do I update the device tree from platform code?
> prom_update_property()
I assume this needs to be called after the DT has been unflattened, since it takes a device_node* as a parameter. Is there any way I can modify the tree before it's unflattened? I'd like to fixup the tree in an early_param() function.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Kumar Gala @ 2011-11-18 14:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhao Chenhui
In-Reply-To: <4EC40406.1030408@freescale.com>
On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
> On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
>> From: Li Yang <leoli@freescale.com>
>>=20
>> The timebase sync is not only necessary when using KEXEC. It should =
also
>> be used by normal boot up and cpu hotplug. Remove the ifdef added by
>> the KEXEC patch.
>=20
> Again, no it should not be used by normal boot up (whether KEXEC =
support
> is enabled or not). We should only do timebase sync when we actually
> need to (when we've actually just reset a core), and we should do it =
the
> way U-Boot does rather than with smp-tbsync.c.
How can we do u-boot bases timebase sync after the system us up and =
running? For example would we losing some ticks of time in the case =
that one core is up and we bring a second core online?
- k=
^ permalink raw reply
* Re: [RFC PATCH 0/11] KVM: PPC: Update Book3S HV memory handling
From: Alexander Graf @ 2011-11-18 13:57 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Marcelo Tosatti, Avi Kivity, kvm-ppc, kvm list
In-Reply-To: <20111116225055.GA26985@bloggs.ozlabs.ibm.com>
On 16.11.2011, at 23:50, Paul Mackerras wrote:
> This series of patches updates the Book3S-HV KVM code that manages the
> guest hashed page table (HPT) to enable several things:
>=20
> * MMIO emulation and MMIO pass-through
>=20
> * Use of small pages (4kB or 64kB, depending on config) to back the
> guest memory
>=20
> * Pageable guest memory - i.e. backing pages can be removed from the
> guest and reinstated on demand, using the MMU notifier mechanism.
>=20
> On PPC970 we have no way to get DSIs and ISIs to come to the
> hypervisor, so we can't do MMIO emulation or pageable guest memory.
> On POWER7 we set the VPM1 bit in the LPCR to make all DSIs and ISIs
> come to the hypervisor (host) as HDSIs or HISIs.
>=20
> This series is RFC for the moment, although the first 5 or so patches
> are pretty solid and could go in. I am going to rework the later
> patches to use HPTEs with V=3D0 for the absent pages rather than =
key=3D31,
> which will require handling the HPTE-not-present HDSIs we will get and
> differentiating the case where the guest has created a HPTE but the
> underlying page is not resident from the case where the guest has
> created no HPTE for the address.
This touches areas that I'm sure non-PPC people would want to see as =
well. Could you please CC kvm@vger too next time?
Avi, Marcelo, mind to review some of the bits in this patch set? :)
Alex
^ permalink raw reply
* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Zhao Chenhui @ 2011-11-18 10:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4EC40406.1030408@freescale.com>
On Wed, Nov 16, 2011 at 12:42:14PM -0600, Scott Wood wrote:
> On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
> > From: Li Yang <leoli@freescale.com>
> >
> > The timebase sync is not only necessary when using KEXEC. It should also
> > be used by normal boot up and cpu hotplug. Remove the ifdef added by
> > the KEXEC patch.
>
> Again, no it should not be used by normal boot up (whether KEXEC support
> is enabled or not). We should only do timebase sync when we actually
> need to (when we've actually just reset a core), and we should do it the
> way U-Boot does rather than with smp-tbsync.c.
>
> -Scott
OK. I'll do it the way U-Boot does.
Thanks.
-chenhui
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Joakim Tjernlund @ 2011-11-18 8:22 UTC (permalink / raw)
To: Robert Richter; +Cc: linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <20111117232027.GW15738@erda.amd.com>
Robert Richter <robert.richter@amd.com> wrote on 2011/11/18 00:20:27:
>
> On 17.11.11 22:27:46, Joakim Tjernlund wrote:
> > > >> For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
> > > >> support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
> > > >> enables backtrace for me.
>
> > It sure seems to work :)
>
> Backtrace support also works in timer mode. This is already
> implemented on arm and sh (out of my mind, have to look at the code to
> be sure). This works if the architectural initialization code sets up
> ops->backtrace even on failure, which is exactly what you proposed.
>
> > Question, what is the sample rate for timer based oprofile?
> > Is it HZ depended?
>
> Yes, it uses the high resolution timer and sets it to HZ which is 4ms
> on most architectures. (I did some measurements and for some reason I
> got 8ms on x86 though it should be 4ms, but didn't debug this yet.)
>
> Unless there are volunteers I will queue up a patch for v3.3 to enable
> backtrace support in timer mode.
I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
correct backtrace but I cannot turn on frame pointers for the ppc kernel.
Isn't frame pointers needed for pcc? what about user space?
Jocke
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Joakim Tjernlund @ 2011-11-18 8:09 UTC (permalink / raw)
To: Robert Richter; +Cc: linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <20111117232027.GW15738@erda.amd.com>
Robert Richter <robert.richter@amd.com> wrote on 2011/11/18 00:20:27:
>
> On 17.11.11 22:27:46, Joakim Tjernlund wrote:
> > > >> For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
> > > >> support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
> > > >> enables backtrace for me.
>
> > It sure seems to work :)
>
> Backtrace support also works in timer mode. This is already
> implemented on arm and sh (out of my mind, have to look at the code to
> be sure). This works if the architectural initialization code sets up
> ops->backtrace even on failure, which is exactly what you proposed.
>
> > Question, what is the sample rate for timer based oprofile?
> > Is it HZ depended?
>
> Yes, it uses the high resolution timer and sets it to HZ which is 4ms
> on most architectures. (I did some measurements and for some reason I
> got 8ms on x86 though it should be 4ms, but didn't debug this yet.)
1-4 ms is a bit rough sample rate I guess. Ever considered using an extra
HW timer(for CPUs that has one to spare) which can set to something better?
>
> Unless there are volunteers I will queue up a patch for v3.3 to enable
> backtrace support in timer mode.
That would be nice, thank you.
Jocke
^ permalink raw reply
* ibm_newemac tx problem with jumbo frame enabled
From: Prashant Bhole @ 2011-11-18 5:03 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have been facing problem with ibm_newemac driver (v3.54).
The board gets disconnected and can not be pinged in between
some heavy network traffic. In my case I am running IOmeter
"All-in-One" 8 threads on the iSCSI target. MTU is 4088.
I found that after executing emac_full_tx_reset(), the board can
be pinged again. Again after some heavy traffic of 5-6 seconds,
traffic stops. This can be repeated after full tx reset.
Is this a known issue? what could cause this?
Any pointers would be greatly appreciated.
-
Prashant
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-11-18 3:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a few fixes remaining for powerpc in 3.2. Some tiny build
breakage, a couple of nasty ps3 bugs fixes, other very small and
quite obvious fixes and and a long standing issue with atomics &
ordering for which we have to use stronger barriers than we do to
be correct.
Cheers,
Ben.
The following changes since commit a9098b372606a15745cdeb012de4ee91c0df82c4:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 (2011-11-17 15:28:54 -0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Al Viro (4):
powerpc: Fix build breakage in jump_label.c
carma-fpga: Missed switch from of_register_platform_driver()
powerpc/fsl_udc_core: Fix dumb typo
powerpc/fsl: MCU_MPC8349EMITX wants I2C built-in, modular won't do...
Anton Blanchard (2):
powerpc: panic if we can't instantiate RTAS
powerpc: Copy down exception vectors after feature fixups
Benjamin Herrenschmidt (1):
powerpc: Fix atomic_xxx_return barrier semantics
Geoff Levand (2):
powerpc/ps3: Fix lost SMP IPIs
powerpc/ps3: Fix SMP lockdep boot warning
Kevin Hao (1):
powerpc/trace: Add a dummy stack frame for trace_hardirqs_off
Kumar Gala (3):
powerpc: Revert show_regs() define for readability
powerpc: Remove extraneous CONFIG_PPC_ADV_DEBUG_REGS define
powerpc/book3e-64: Fix debug support for userspace
Kyle Moffett (1):
powerpc: Remove buggy 9-year-old test for binutils < 2.12.1
Michael Neuling (1):
powerpc: Add hvcall.h include to book3s_hv.c
Suzuki Poulose (1):
powerpc/4xx: Fix typos in kexec config dependencies
Will Deacon (1):
powerpc/signal32: Fix sigset_t conversion when copying to user
arch/powerpc/Kconfig | 2 +-
arch/powerpc/Makefile | 6 ---
arch/powerpc/include/asm/atomic.h | 48 ++++++++++++------------
arch/powerpc/include/asm/bitops.h | 12 +++---
arch/powerpc/include/asm/futex.h | 7 ++-
arch/powerpc/include/asm/reg_booke.h | 2 +-
arch/powerpc/include/asm/sections.h | 2 +-
arch/powerpc/include/asm/synch.h | 9 +++-
arch/powerpc/kernel/entry_32.S | 15 +++++++
arch/powerpc/kernel/jump_label.c | 2 +
arch/powerpc/kernel/kvm.c | 1 -
arch/powerpc/kernel/misc_32.S | 2 +-
arch/powerpc/kernel/process.c | 24 +-----------
arch/powerpc/kernel/prom_init.c | 6 +--
arch/powerpc/kernel/setup_32.c | 2 +
arch/powerpc/kernel/setup_64.c | 1 +
arch/powerpc/kernel/signal_32.c | 2 +-
arch/powerpc/kernel/traps.c | 2 -
arch/powerpc/kvm/book3s_hv.c | 1 +
arch/powerpc/lib/feature-fixups.c | 23 +++++++++++
arch/powerpc/platforms/Kconfig | 2 +-
arch/powerpc/platforms/ps3/interrupt.c | 23 +++++++++++-
arch/powerpc/platforms/ps3/platform.h | 1 +
arch/powerpc/platforms/ps3/smp.c | 62 ++++++++++++++++---------------
drivers/misc/carma/carma-fpga-program.c | 9 ++--
drivers/misc/carma/carma-fpga.c | 9 ++--
drivers/usb/gadget/fsl_udc_core.c | 2 +-
27 files changed, 158 insertions(+), 119 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/3] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
From: LiuShuo @ 2011-11-18 2:08 UTC (permalink / raw)
To: dedekind1
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, Tang Yuantian,
linux-mtd, Jerry Huang, scottwood, akpm, dwmw2
In-Reply-To: <1321568016.2272.29.camel@koala>
Ok and I want to add another patch before 3/3.
-LiuShuo
> On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote:
>> From: Liu Shuo<b35362@freescale.com>
>>
>> If we use the Nand flash chip whose number of pages in a block is greater
>> than 64(for large page), we must treat the low bit of FBAR as being the
>> high bit of the page address due to the limitation of FCM, it simply uses
>> the low 6-bits (for large page) of the combined block/page address as the
>> FPAR component, rather than considering the actual block size.
> Looks like this patch depends on the previous white-space clean-up patch
> - could you please refactor it (and 3/3 too) and resend?
Ok and I am going to add another new patch before 3/3.
-LiuShuo
> Artem.
>
>
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Robert Richter @ 2011-11-17 23:20 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <OF8F2311F0.71A00B7A-ONC125794B.007583D0-C125794B.0075E666@transmode.se>
On 17.11.11 22:27:46, Joakim Tjernlund wrote:
> > >> For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
> > >> support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
> > >> enables backtrace for me.
> It sure seems to work :)
Backtrace support also works in timer mode. This is already
implemented on arm and sh (out of my mind, have to look at the code to
be sure). This works if the architectural initialization code sets up
ops->backtrace even on failure, which is exactly what you proposed.
> Question, what is the sample rate for timer based oprofile?
> Is it HZ depended?
Yes, it uses the high resolution timer and sets it to HZ which is 4ms
on most architectures. (I did some measurements and for some reason I
got 8ms on x86 though it should be 4ms, but didn't debug this yet.)
Unless there are volunteers I will queue up a patch for v3.3 to enable
backtrace support in timer mode.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Scott Wood @ 2011-11-17 22:45 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <4EC58AA0.2070905@freescale.com>
On Thu, Nov 17, 2011 at 04:28:48PM -0600, Timur Tabi wrote:
> Scott Wood wrote:
>
> > As we discussed earlier, you could have a kernel boot parameter that
> > indicates what mode you'd like the localbus to run in. Then, platform
> > code could update the device tree before any drivers bind.
>
> How do I update the device tree from platform code?
prom_update_property()
Or, since you shouldn't be declaring these devices directly under a
simple-bus node, selectively probe the devices that are accessible.
> > Or, have U-boot set up the desired mode before entering the kernel, and
> > provide an appropriate device tree.
>
> I can both of these features, but not in this patch.
This patch is the one that is adding a switch to indirect mode. You're
adding it to the wrong place (it shouldn't be in a function called by the
DIU driver), so it is relevant to this patch.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-17 22:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111117222515.GA18827@schlenkerla.am.freescale.net>
Scott Wood wrote:
> As we discussed earlier, you could have a kernel boot parameter that
> indicates what mode you'd like the localbus to run in. Then, platform
> code could update the device tree before any drivers bind.
How do I update the device tree from platform code?
> Or, have U-boot set up the desired mode before entering the kernel, and
> provide an appropriate device tree.
I can both of these features, but not in this patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Scott Wood @ 2011-11-17 22:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <4EC586B2.5060604@freescale.com>
On Thu, Nov 17, 2011 at 04:12:02PM -0600, Timur Tabi wrote:
> Scott Wood wrote:
>
> >> This has the side-effect of no longer requiring U-Boot to enable the DIU.
> >> Now Linux can enable the DIU all by itself.
> >
> > Under what circumstances does Linux do this?
>
> p1022ds_set_monitor_port() is called by the DIU driver when it enables
> the DIU. This happens on boot, for example, if you enable the
> framebuffer console.
>
> > How does Linux prevent the
> > NOR flash driver from binding to the device when this mode has been or
> > will be used?
>
> It doesn't. This isn't a simple problem to solve. On the P1022, NOR
> flash and the DIU are incompatible, and yet that's exactly what we ship
> on the P1022DS board. We could just remove the NOR flash node from the
> DTS.
As we discussed earlier, you could have a kernel boot parameter that
indicates what mode you'd like the localbus to run in. Then, platform
code could update the device tree before any drivers bind.
Or, have U-boot set up the desired mode before entering the kernel, and
provide an appropriate device tree.
Letting the kernel bind to localbus devices such as NOR flash, and then
taking the devices away without notice just because another device gets
initialized, is not the way to go. We've already left "it just works"
territory, might as well make the user choose explicitly.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
From: Artem Bityutskiy @ 2011-11-17 22:13 UTC (permalink / raw)
To: b35362
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, Tang Yuantian,
linux-mtd, Jerry Huang, scottwood, akpm, dwmw2
In-Reply-To: <1321349355-1639-2-git-send-email-b35362@freescale.com>
On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> If we use the Nand flash chip whose number of pages in a block is greater
> than 64(for large page), we must treat the low bit of FBAR as being the
> high bit of the page address due to the limitation of FCM, it simply uses
> the low 6-bits (for large page) of the combined block/page address as the
> FPAR component, rather than considering the actual block size.
Looks like this patch depends on the previous white-space clean-up patch
- could you please refactor it (and 3/3 too) and resend?
Artem.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-17 22:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111117213733.GC14736@schlenkerla.am.freescale.net>
Scott Wood wrote:
>> This has the side-effect of no longer requiring U-Boot to enable the DIU.
>> Now Linux can enable the DIU all by itself.
>
> Under what circumstances does Linux do this?
p1022ds_set_monitor_port() is called by the DIU driver when it enables the DIU. This happens on boot, for example, if you enable the framebuffer console.
> How does Linux prevent the
> NOR flash driver from binding to the device when this mode has been or
> will be used?
It doesn't. This isn't a simple problem to solve. On the P1022, NOR flash and the DIU are incompatible, and yet that's exactly what we ship on the P1022DS board. We could just remove the NOR flash node from the DTS.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-17 22:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111118082929.5ee8d4f07d84f2bf65e18006@canb.auug.org.au>
Stephen Rothwell wrote:
>> static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
>> {
>> - struct device_node *np;
>> - void __iomem *pixis;
>> - u8 __iomem *brdcfg1;
>> + struct device_node *guts_node = NULL;
>
> There is no point in initialising this as it is assigned before being
> used.
Ok.
>> + struct device_node *indirect_node = NULL;
>> + struct ccsr_guts_85xx __iomem *guts = NULL;
>> + u8 __iomem *lbc_lcs0_ba = NULL;
>> + u8 __iomem *lbc_lcs1_ba = NULL;
>
> And if you had multiple error path labels, you could avoid these others
> as well (and the NULL checks on the error path).
But I don't want multiple error path labels. The error path could only happen if someone passed in a broken device tree (i.e. pretty much never), so I'm not keen on complicating my code just to optimize something that will never be used.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/3] mtd/nand: fix coding style issue in drivers/mtd/nand/fsl_elbc.c
From: Artem Bityutskiy @ 2011-11-17 22:08 UTC (permalink / raw)
To: b35362; +Cc: linuxppc-dev, linux-kernel, linux-mtd, scottwood, akpm, dwmw2
In-Reply-To: <1321349355-1639-1-git-send-email-b35362@freescale.com>
On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> fix whitespaces,tabs coding style issue and use #include <linux/io.h> instead of <asm/io.h>
> in drivers/mtd/nand/fsl_elbc.c.
>
> Signed-off-by: Liu Shuo <b35362@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Hi, It is really matter of taste whether to use only tabs for
indentations or tabs + few spaces to align nicely with the previous
line. I personally prefer the latter and dislike when people use only
tabs. But other people love tabs and use them everywhere, even like
#define\tBLAH_BLAH\tvalue, which I find ugly, but I do not mind people
using this.
So no, please, let's leave the indentation as is in this file. It is ok
to assume tab is 8 spaces in the kernel.
Artem.
^ permalink raw reply
* Re: [PATCH net-next] ibm/emac: fix improper cleanup when device is removed to allow re-bind
From: David Miller @ 2011-11-17 22:05 UTC (permalink / raw)
To: wg; +Cc: Netdev, Linuxppc-dev
In-Reply-To: <4EC506E4.5060806@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 17 Nov 2011 14:06:44 +0100
> The re-binding (unbind..bind) of an EMAC device fails because the
> static variable "busy_phy_map" is not updated when the device is
> removed.
>
> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: add pixis indirect mode device tree node
From: Scott Wood @ 2011-11-17 21:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <1321556259-4459-1-git-send-email-timur@freescale.com>
On Thu, Nov 17, 2011 at 12:57:38PM -0600, Timur Tabi wrote:
> The Freescale P1022 has a unique pin muxing "feature" where the DIU video
> controller's video signals are muxed with 24 of the local bus address signals.
> When the DIU is enabled, the bulk of the local bus is disabled, preventing
> access to memory-mapped devices like NOR flash and the pixis FPGA.
>
> In this situation, the pixis supports "indirect mode", which allows access
> to the pixis itself by reading/writing addresses on specific local bus
> chip selects. CS0 is used to select which pixis register to access, and
> CS1 is used to read/write the value.
>
> To support this, we introduce another board-control child node of the
> localbus node that contains a 'reg' property for CS0 and CS1. This will
> produce the correct physical addresses for CS0 and CS1.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/boot/dts/p1022ds.dts | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
> index 24a73e9..3e85d8c 100644
> --- a/arch/powerpc/boot/dts/p1022ds.dts
> +++ b/arch/powerpc/boot/dts/p1022ds.dts
> @@ -24,6 +24,20 @@
> 0x2 0x0 0xf 0xffa00000 0x00040000
> 0x3 0x0 0xf 0xffdf0000 0x00008000>;
>
> + /*
> + * This node is used to access the pixis via "indirect" mode,
> + * which is done by writing the pixis register index to chip
> + * select 0 and the value to/from chip select 1. Indirect
> + * mode is the only way to access the pixis when DIU video
> + * is enabled. Note that this assumes that the first column
> + * of the 'ranges' property above is the chip select number.
> + */
> + board-control@0,0 {
> + compatible = "fsl,p1022ds-indirect-pixis";
> + reg = <0x0 0x0 1 /* CS0 */
> + 0x1 0x0 1>; /* CS1 */
> + };
> +
> nor@0,0 {
> #address-cells = <1>;
> #size-cells = <1>;
U-Boot should mark some of these devices as disabled, based on whether
indirect mode is enabled on boot. If you're not going to do that, at
least remove simple-bus from the compatible list.
Something like this is probably the best way to describe it:
localbus {
compatible = "...", "fsl,elbc", "simple-bus";
ranges = <...>;
#address-cells = <2>;
#size-cells = <2>;
mux {
compatible = "fsl,p1022ds-localbus-mux"; // no simple-bus
fsl,localbus-mux-mode = "indirect"; // inital state on boot
ranges;
#address-cells = <2>;
#size-cells = <2>;
board-control@0,0 {
compatible = "fsl,p1022ds-indirect-pixis";
reg = <0 0 1
1 0 1>;
fsl,localbus-mux-avail = "indirect";
};
flash@0,0 {
...
fsl,localbus-mux-avail = "direct";
};
...
};
};
Or encode the mode as part of reg, as I suggested for someone else here:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-November/009378.html
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Scott Wood @ 2011-11-17 21:37 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <1321556259-4459-2-git-send-email-timur@freescale.com>
On Thu, Nov 17, 2011 at 12:57:39PM -0600, Timur Tabi wrote:
> When the P1022's DIU video controller is active, the pixis must be accessed
> in "indirect" mode, which uses localbus chip select addresses.
>
> Switching between the DVI and LVDS monitor ports is handled by the pixis,
> so that switching needs to be done via indirect mode.
>
> This has the side-effect of no longer requiring U-Boot to enable the DIU.
> Now Linux can enable the DIU all by itself.
Under what circumstances does Linux do this? How does Linux prevent the
NOR flash driver from binding to the device when this mode has been or
will be used?
-Scott
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/85xx: separate MPIC handling code
From: Scott Wood @ 2011-11-17 21:33 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1321552581-29773-3-git-send-email-dbaryshkov@gmail.com>
On Thu, Nov 17, 2011 at 09:56:18PM +0400, Dmitry Eremin-Solenikov wrote:
> All mpc85xx boards deal with MPIC initialization in more or less the
> same way. The only difrerences are some flags (WANTS_RESET,
> BROKEN_FRR_NIRQS, SINGLE_DEST_CPU), and some bugs like leaking device
> node counter, etc. To minimize problems, switch all boards to use one
> single instance of code.
SINGLE_DEST_CPU should apply to all 85xx (the boards that omit it are
probably non-SMP where it doesn't matter), and probably BROKEN_FRR_NIRQS
as well (shouldn't hurt, at least).
> + mpc85xx_init_mpic(0, 1, 1);
This is awkward to read, named flags are better -- and already exist for
this. :-)
Something like this should be clearer and still allow any override the
board wishes (such as for 85xx CAMP):
#define MPC85XX_MPIC_FLAGS (...)
most_boards:
mpc85xx_init_mpic(MPC85XX_MPIC_FLAGS)
85xx CAMP:
mpc85xx_init_mpic(MPC85XX_MPIC_FLAGS & ~MPIC_WANTS_RESET);
-Scott
^ 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