* 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/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: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: 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/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
* [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
* 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
* 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
* 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: [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: [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: 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: [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
* [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
* [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 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
* 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
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Scott Wood @ 2011-11-18 18:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <4EC68F14.9020206@freescale.com>
On Fri, Nov 18, 2011 at 11:00:04AM -0600, Timur Tabi wrote:
> 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.
What's wrong with doing it in setup_arch()?
Modifying a flat device tree is a more complicated task, and the kernel's
code is read-only. It's not worth bringing libfdt or similar complexity
in for this, when there are other alternatives.
If it really needs to be done early, consider doing it from U-Boot. The
bootwrapper would be a decent place as well, but we probably shouldn't
require its use just for this.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-18 18:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111118180651.GC28562@schlenkerla.am.freescale.net>
Scott Wood wrote:
> What's wrong with doing it in setup_arch()?
Well, I was hoping to encapsulate everything into one function -- the early_param() callback function. But I guess that's not going to work.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC PATCH 0/11] KVM: PPC: Update Book3S HV memory handling
From: Paul Mackerras @ 2011-11-18 21:54 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev, Marcelo Tosatti, Avi Kivity, kvm-ppc, kvm list
In-Reply-To: <AA9CC080-B96B-41C7-A054-8286CF8BC3FE@suse.de>
On Fri, Nov 18, 2011 at 02:57:11PM +0100, Alexander Graf wrote:
>
> 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? :)
I did cc the last patch (the one that adds barriers in the MMU
notifier sequence/count logic) to kvm@vger. Do you mean I should cc
the whole series? The only other thing touching generic code is the
addition of the KVM_MEMSLOT_IO flag in the first patch.
I'm hoping the extra barriers will be OK since they are no-ops on
x86. In fact I now think that the smp_wmbs I added to
kvm_mmu_notifier_invalidate_page and kvm_mmu_notifier_change_pte
aren't in fact necessary, since it's only necessary to ensure that the
sequence number increase is visible before the point where
kvm_unmap_hva or kvm_set_spte_hva unlock the bitlock on the first rmap
chain they look at, which will be ensured anyway by the barrier before
the unlock.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Stephen Rothwell @ 2011-11-19 1:04 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <4EC5860D.5000606@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]
Hi Timur,
On Thu, 17 Nov 2011 16:09:17 -0600 Timur Tabi <timur@freescale.com> wrote:
>
> Stephen Rothwell wrote:
>
> >> + 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.
But you are already optimizing for the error path by doing the
assignments and NULL checks that are unneeded in the non error path.
What I am suggesting is adding a little more code that could end up doing
less at run time.
How about (not even compile tested):
static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
struct device_node *guts_node;
struct device_node *indirect_node;
struct ccsr_guts_85xx __iomem *guts;
u8 __iomem *lbc_lcs0_ba;
u8 __iomem *lbc_lcs1_ba;
u8 b;
/* 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;
}
guts = of_iomap(guts_node, 0);
of_node_put(guts_node);
if (!guts) {
pr_err("p1022ds: could not map global utilties device\n");
return;
}
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_guts_iounmap;
}
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_indirect_node;
}
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_lcs0_iounmap;
}
/* 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_lcs1_iounmap;
}
pixis = of_iomap(pixis_node, 0);
of_node_put(pixis_node);
if (!pixis) {
pr_err("p1022ds: could not map pixis registers\n");
goto exit_lcs1_iounmap;
}
/* 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:
/* Enable the DVI port, disable the DFP and the backlight */
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:
/*
* LVDS also needs backlight enabled, otherwise the display
* will be blank.
*/
/* Enable the DFP port, disable the DVI and the backlight */
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);
}
exit_lcs1_iounmap:
iounmap(lbc_lcs1_ba);
exit_lcs0_iounmap:
iounmap(lbc_lcs0_ba);
exit_indirect_node:
of_node_put(indirect_node);
exit_guts_iounmap:
iounmap(guts);
}
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Avi Kivity @ 2011-11-20 12:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <20111116225209.GB26985@bloggs.ozlabs.ibm.com>
On 11/17/2011 12:52 AM, Paul Mackerras wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> This adds support for adding PCI device I/O regions to the guest memory
> map, and for trapping guest accesses to emulated MMIO regions and
> delivering them to qemu for MMIO emulation. To trap guest accesses to
> emulated MMIO regions, we reserve key 31 for the hypervisor's use and
> set the VPM1 bit in LPCR, which sends all page faults to the host.
> Any page fault that is not a key fault gets reflected immediately to the
> guest. We set HPTEs for emulated MMIO regions to have key = 31, and
> don't allow the guest to create HPTEs with key = 31. Any page fault
> that is a key fault with key = 31 is then a candidate for MMIO
> emulation and thus gets sent up to qemu. We also load the instruction
> that caused the fault for use later when qemu has done the emulation.
>
> [paulus@samba.org: Cleaned up, moved kvmppc_book3s_hv_emulate_mmio()
> to book3s_64_mmu_hv.c]
>
>
> + /*
> + * XXX WARNING: We do not know for sure whether the instruction we just
> + * read from memory is the same that caused the fault in the first
> + * place. We don't have a problem with the guest shooting itself in
> + * the foot that way, however we must be careful that we enforce
> + * the write permission based on the instruction we are actually
> + * emulating, not based on dsisr. Unfortunately, the KVM code for
> + * instruction emulation isn't smart enough for that to work
> + * so right now we just do it badly and racily, but that will need
> + * fixing
> + */
> +
Ouch, I assume this will be fixed before merging?
> }
>
> int kvmppc_core_prepare_memory_region(struct kvm *kvm,
> - struct kvm_userspace_memory_region *mem)
> + struct kvm_memory_slot *memslot,
> + struct kvm_userspace_memory_region *mem)
> {
> unsigned long psize, porder;
> unsigned long i, npages, totalpages;
> unsigned long pg_ix;
> struct kvmppc_pginfo *pginfo;
> - unsigned long hva;
> struct kvmppc_rma_info *ri = NULL;
> + struct vm_area_struct *vma;
> struct page *page;
> + unsigned long hva;
> +
> + /*
> + * This could be an attempt at adding memory or it could be MMIO
> + * pass-through. We need to treat them differently but the only
> + * way for us to know what it is is to look at the VMA and play
> + * guess work so let's just do that
> + */
There is no "the VMA". There could be multiple VMAs, or none (with the
mmap() coming afterwards). You could do all the checks you want here,
only to have host userspace remap it under your feet. This needs to be
done on a per-page basis at fault time.
Please see the corresponding x86 code (warning: convoluted), which has a
similar problem (though I have no idea if you can use a similar solution).
> +
> + /*
> + * We require read & write permission as we cannot yet
> + * enforce guest read-only protection or no access.
> + */
> + if ((vma->vm_flags & (VM_READ | VM_WRITE)) !=
> + (VM_READ | VM_WRITE))
> + goto err_unlock;
This, too, must be done at get_user_pages() time.
What happens if mmu notifiers tell you to write protect a page?
> void kvm_arch_commit_memory_region(struct kvm *kvm,
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index c107fae..774b04d 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -105,6 +105,9 @@ struct kvm_userspace_memory_region {
> #define KVM_MEM_LOG_DIRTY_PAGES 1UL
> #define KVM_MEMSLOT_INVALID (1UL << 1)
>
> +/* Kernel internal use */
> +#define KVM_MEMSLOT_IO (1UL << 31)
> +
Please define it internally then (and leave a comment so we don't
overlap it).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC PATCH 10/11] KVM: PPC: Implement MMU notifiers
From: Avi Kivity @ 2011-11-20 12:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <20111116235220.GK26985@bloggs.ozlabs.ibm.com>
On 11/17/2011 01:52 AM, Paul Mackerras wrote:
> This implements the low-level functions called by the MMU notifiers in
> the generic KVM code, and defines KVM_ARCH_WANT_MMU_NOTIFIER if
> CONFIG_KVM_BOOK3S_64_HV so that the generic KVM MMU notifiers get
> included.
>
> That means we also have to take notice of when PTE invalidations are
> in progress, as indicated by mmu_notifier_retry(). In kvmppc_h_enter,
> if any invalidation is in progress we just install a non-present HPTE.
> In kvmppc_book3s_hv_page_fault, if an invalidation is in progress we
> just return without resolving the guest, causing it to encounter another
> page fault immediately. This is better than spinning inside
> kvmppc_book3s_hv_page_fault because this way the guest can get preempted
> by a hypervisor decrementer interrupt without us having to do any
> special checks.
>
> We currently maintain a referenced bit in the rmap array, and when we
> clear it, we make all the HPTEs that map the corresponding page be
> non-present, as if the page were invalidated. In future we could use
> the hardware reference bit in the guest HPT instead.
>
> The kvm_set_spte_hva function is implemented as kvm_unmap_hva. The
> former appears to be unused anyway.
This is mostly used for COW (after ksm, not fork). So if you want to
use ksm, this avoids an exit.
> This all means that on processors that support virtual partition
> memory (POWER7), we can claim support for the KVM_CAP_SYNC_MMU
> capability, and we no longer have to pin all the guest memory.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH][v2] powerpc/p1023: set IRQ[4:6, 11] to active-high level sensitive for PCIe
From: Kumar Gala @ 2011-11-20 15:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1321506575-21730-1-git-send-email-galak@kernel.crashing.org>
On Nov 16, 2011, at 11:09 PM, Kumar Gala wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> P1023 external IRQ[4:6, 11] are not pin out, but the interrupts are
> utilized by the PCIe controllers. As they are not exposed as pins we
> need to set them as active-high (internal to the SoC these interrupts
> are pulled down).
>
> IRQs[0:3,7:10] are pulled up on the board so we have them set as
> active-low.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> v2:
> * cleaned up commit message & added comments to be clear about IRQ usage
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
From: Kumar Gala @ 2011-11-20 15:53 UTC (permalink / raw)
To: Paul Bolle; +Cc: linux-kernel, Anatolij Gustschin, linuxppc-dev, Shengzhou Liu
In-Reply-To: <1321141830.20271.22.camel@x61.thuisdomein>
On Nov 12, 2011, at 5:50 PM, Paul Bolle wrote:
> The driver for the Freescale P3060 QDS got added by commit 96cc017c5b
> ("[...] Add support for P3060QDS board"). Its Kconfig entry selects
> MPC8xxx_GPIO. But at the time that driver got added MPC8xxx_GPIO was
> already renamed to GPIO_MPC8XXX, by commit c68308dd50c ("gpio: move
> mpc8xxx/512x gpio driver to drivers/gpio").
>
> So make this driver select GPIO_MPC8XXX.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Bravely untested: I haven't got the hardware nor the PPC toolchain
> needed to build this. And it seems this needs (build) testing anyhow.
>
> 1) Sent to the people who wrote the two patches mentioned in the commit
> explanation and CC'd the non-authors who signed-off these patches.
>
> 2) The config tools do not complain about selects that cannot be met
> because they concern a Kconfig symbol that doesn't even exist. Shouldn't
> they be made to complain in that case?
>
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k
^ 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