On Friday 11 September 2009, David Gibson wrote:
On Fri, Sep 11, 2009 at 12:14:55PM +0800, g r1x wrote:
Now, I'm writing a DMA driver on powerpc
440gx platform(2.6.26.5), as the only way to set up DMA Controller is
to access it's dcr registers with 'mfdcr' and 'mtdcr'.
I've found some
On Monday 28 September 2009, Anton Blanchard wrote:
262144 kstat_irqs_all
131072 irq_desc
16384 irq_stat
Could we dynamically allocate our irq structures?
There were patches floating around for that a few years ago,
but I haven't seen anyone working on it since.
131072 lppaca
On Friday 09 October 2009, Donald Kayser wrote:
On further comparison, this section of code has been added by the
vendor that actually ported linux 2.4 to this PPC HPPB target. So, if
anyone would like to lend a thought towards System Managment
Exceptions on PPC, please cc me at
on Rusty Russell's alloc_percpu: rename percpu vars
which cause name clashes patch.
Patch looks good, I checked both the cell bits I'm maintaining
and the other powerpc parts.
Acked-by: Arnd Bergmann a...@arndb.de
___
Linuxppc-dev mailing list
Linuxppc-dev
...@ellerman.id.au
Acked-by: Arnd Bergmann a...@arndb.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tuesday 13 October 2009, Jeremy Kerr wrote:
Or can this test be removed?
I'd prefer just to remove the test.
Yes, sounds good.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Thursday 22 October 2009, Frederic Weisbecker wrote:
I'm thinking that the simplier approach, would be to make the
default_llseek the unlocked one. Then you only have to audit the drivers
that have the BKL - ie the ones we are auditing anyway, and explicitly set
them to the bkl
On Tuesday 03 November 2009, Benjamin Herrenschmidt wrote:
(Though glibc can be nasty, afaik it might load up optimized variants of
some routines with hard wired cache line sizes based on the CPU type)
You can also get application with hand-coded cache optimizations
that are even harder, if not
On Sunday 15 November 2009, Alon Ziv wrote:
*)PORT_16450, },
- { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550A, },
Does not seem logical. If the device claims compatibility with
On Monday 16 November 2009, Christoph Hellwig wrote:
As mentioned before making generic_file_llseek the new default is
probably a bad idea. The majority of our file_operations instances
don't actually support seeking, so no_llseek should become the new
default if you spend some effort on
On Thursday 19 November 2009, Alon Ziv wrote:
On Monday, November 16, 2009, Arnd wrote:
- { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550A, },
Does not seem logical. If the
On Thursday 19 November 2009, Alon Ziv wrote:
Is the following better?
---
[PATCH] Xilinx 16550 UART is actually 16550A-compatible
Yes, that's better because it's guaranteed not to break any
other system, while fixing yours.
I'd still add support for the compatible=ns16550a property
so
On Thursday 19 November 2009, Alon Ziv wrote:
On Thursday, November 19, 2009, Arnd Bergmann wrote:
I'd still add support for the compatible=ns16550a property
so that we do the right thing for future systems.
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off
On Thursday 19 November 2009, Stephen Neuendorffer wrote:
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
No, the problem
On Saturday 21 November 2009, Grant Likely wrote:
BTW, while looking at that file... Arnd, does the .type = serial
stuff really need to be there?
Well, serial is one of the few that actually has some preexisting
binding with a well defined device-type, so I guess we should use
it.
Arnd
On Sunday 22 November 2009, Albert Herranz wrote:
config NOT_COHERENT_CACHE
bool
- depends on 4xx || 8xx || E200 || PPC_MPC512x
+ depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
default y
config CHECK_CACHE_COHERENCY
diff --git
On Sunday 22 November 2009, Albert Herranz wrote:
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+setup_usbgecko_bat:
+ /* prepare a BAT for early io */
+ lis r8, 0x0c00
+ ori r8, r8, 0x002a /* uncached, guarded ,rw */
+ lis r11, 0xcc00
+ ori r11, r11, 0x3 /*
On Sunday 22 November 2009, Albert Herranz wrote:
+ *
+ */
+struct mipc_device {
+ void __iomem *io_base;
+ int irq;
+
+ struct device *dev;
+
+ spinlock_t call_lock; /* serialize firmware calls */
+ spinlock_t io_lock; /* serialize access to io registers */
+
On Sunday 22 November 2009, Albert Herranz wrote:
The following patches add the base support for the Nintendo GameCube
and Wii video game consoles on the powerpc arch.
For each video game console, the following is included:
- a device tree source
- bootwrapper support
- udbg console option
On Monday 23 November 2009, Chris Friesen wrote:
We've had a mechanism sort of like this for quite a while. Hasn't been
pushed to mainline because it used board-specific hardware and we're
usually multiple kernel versions behind mainline.
Anyways, a couple things that we've found to be
On Monday 23 November 2009 19:10:55 Albert Herranz wrote:
Arnd Bergmann wrote:
On Sunday 22 November 2009, Albert Herranz wrote:
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+setup_usbgecko_bat:
+/* prepare a BAT for early io */
+lis r8, 0x0c00
+ori r8, r8, 0x002a
.
Reported-by: Alon Ziv al...@nolaviz.org
Signed-off-by: Michal Simek mon...@monstr.eu
Signed-off-by: Arnd Bergmann a...@arndb.de
---
Please apply to the tty tree for 2.6.33
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,6 +161,7 @@ static int of_platform_serial_remove
On Tuesday 24 November 2009, Segher Boessenkool wrote:
This option should be used only for options applicable to both the
GAMECUBE and WII, i.e. basically those options in the WII which
where inherited from the GAMECUBE to make it retro-compatible.
If GAMECUBE_COMMON is unacceptable,
On Thursday 10 December 2009, Sean MacLennan wrote:
To be honest, I can't find why we are scheduling :( They only way we
give up the CPU is with locking... and none of the locks where hit
during the problem. We also never get near our timeslice... the longest
run I saw when the problem
On Friday 11 December 2009, Sean MacLennan wrote:
Found it. We are calling sock_sendmsg, which is definitely a call that
can block! The receive side is done in a thread (which does no floating
point ;), but the send was called directly from the evil FP thread.
It looks like under light load,
On Thursday 10 December 2009, Grant Likely wrote:
On Wed, Dec 9, 2009 at 5:21 PM, David Miller da...@davemloft.net wrote:
From: David Miller da...@davemloft.net
Date: Wed, 09 Dec 2009 16:15:50 -0800 (PST)
What a shame, it's one of the cleanest driver probing models
in the tree.
And
On Friday 11 December 2009, Simon Richter wrote:
Hi,
since there has been a thread on allowing the use of a coprocessor in
the kernel already: I am wondering if it'd make sense to use AltiVec for
AES in dm-crypt, and how difficult it would be to implement that.
I'm using a PegasosII which
On Friday 11 December 2009 16:44:32 Grant Likely wrote:
platform users far outnumber of_platform users. I actually don't care
which becomes the 'preferred' bus, just as long as one is chosen. It
is easy to migrate features between them. When I look at the work
required though, I think it
this patch is) we could just merge
it via the powerpc tree.
Fine with me (cell_edac bits in particular).
Acked-by: Arnd Bergmann a...@arndb.de
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thursday 22 January 2009, Anton Vorontsov wrote:
+ /*
+ * These accessors duplicate sdhci_ops, but there are two reasons for
+ * this:
+ * 1. sdhci_ops are const, so the sdhci driver won't able to assign
+ * default ops;
You could assign the pointer to
-by: Arnd Bergmann a...@arndb.de
+ ret = of_address_to_resource(np, 0, mem);
+ if (ret)
+ goto err_no_addr;
+
+ host-ioaddr = ioremap(mem.start, resource_size(mem));
+ if (!host-ioaddr) {
+ ret = -ENOMEM;
+ goto err_addr_map;
+ }
Minor
On Saturday 31 January 2009, Geoff Levand wrote:
So I take it that the above showed that the code worked for some?
In my trials it blows up on the first load_module() call, and for my
config that was usbcore:
I looked into it some more with Remis yesterday, and we got ftrace
working by
On Monday 09 February 2009, Michael Neuling wrote:
arch/powerpc/oprofile/cell/spu_profiler.c is missing a asm/time.h
include which is required for ppc_proc_freq. This can cause compile
failures for some config combinations.
Signed-off-by: Michael Neuling mi...@neuling.org
Acked-by: Arnd
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is the best I could come up with.
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -91,15 +91,6 @@ config RTAS_FLASH
tristate Firmware flash interface
depends on PPC64 RTAS_PROC
-config PPC_PMI
On Tuesday 24 February 2009, Ira Snyder wrote:
This adds support to Linux for using virtio between two computers linked by
a PCI interface. This allows the use of virtio_net to create a familiar,
fast interface for communication. It should be possible to use other virtio
devices in the future,
On Thursday 26 February 2009, Ira Snyder wrote:
On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
I think so too. I was just getting something working, and thought it
would be better to have it out there rather than be working on it
forever. I'll try to break things up as I have
On Thursday 26 February 2009, Ira Snyder wrote:
On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
The registers are part of the board control registers. They don't fit at
all in the message unit. Doing this in the bootloader seems like a
logical place, but that would require any
On Friday 27 February 2009, Ira Snyder wrote:
On Thu, Feb 26, 2009 at 11:34:33PM +0100, Arnd Bergmann wrote:
I guess the best option for doing it in Linux then would be to have
a board control driver (not sure if this already exists) that exports
high-level functions to set up the inbound
On Wednesday 18 March 2009, mon...@monstr.eu wrote:
From: Michal Simek mon...@monstr.eu
Signed-off-by: Michal Simek mon...@monstr.eu
---
arch/microblaze/include/asm/of_device.h | 45 ++
arch/microblaze/include/asm/of_platform.h | 64 ++
arch/microblaze/include/asm/prom.h |
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
causing build failures if PCI is not set.
Maybe it should only select it if PCI is enabled ? Is
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote:
No, QPACE does not have any PCI devices whatsoever.
so something like select PPC_OF_PLATFORM_PCI if PCI would work you
think ?
Yes, that sounds good.
Arnd
On Thursday 02 April 2009, Harry Ciao wrote:
+#ifdef CONFIG_EDAC
+#define CPC925_MC_START0xf800
+#define CPC925_MC_END 0xf8ff /* sizeof 16MB */
+/* Register a platform device for CPC925 memory controller */
+static int __init maple_cpc925_edac_setup(void)
On Thursday 02 April 2009, Harry Ciao wrote:
Introduce IBM CPC925 EDAC driver source file, which makes use of error
detections on the IBM CPC925 Bridge and Memory Controller.
Signed-off-by: Harry Ciao qingtao@windriver.com
On a very brief review, the driver looks good to me, but please
On Thursday 02 April 2009, Geert Uytterhoeven wrote:
| arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to
`pci_io_base'
due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
shouldn't be built when CONFIG_PCI=n?
Right, the I/O workarounds are specific
and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE
and USB_OHCI_HCD_PPC_OF_LE are set.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 845479f..07e3e25 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -161,26
On Wednesday 22 April 2009, Kumar Gala wrote:
First of all, thanks for bringing this up, I'd love to see get_immrbase() gone.
arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
0x4000);
not sure? ideas?
Nobody has commented on this, so I've taken a brief look at
On Tuesday 21 April 2009, John Williams wrote:
Some (most?) of the Xilinx drivers currently have this construct:
#ifdef CONFIG_OF
// probe using OF
#else
If there are multiple ways of detecting the device, then
the driver should be compilable on any system that allows
either one.
At
On Friday 17 April 2009, John Linn wrote:
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
I just said in another email thread that we
On Sunday 10 February 2008, Jon Smirl wrote:
of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
What about adding a third param to
On Sunday 10 February 2008, Jon Smirl wrote:
On 2/9/08, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Sunday 10 February 2008, Jon Smirl wrote:
of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length
On Saturday 09 February 2008, Sean MacLennan wrote:
If anybody has suggestions on better ways to do this, fire away.
I guess the cleanest solution would be to include two complete device trees
for this platform, and then choose the correct one in cuboot-warp.c based
on the board revision.
The
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt. But the conditional logic should be in the manipulating
agent (u-boot or bootwrapper or
On Wednesday 13 February 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-02-13 at 18:35 +0100, Christian Krafft wrote:
sensors_detect crashes kernel on PowerPC, as it pokes directly to memory.
This patch adds a check_legacy_ioports to read_port and write_port.
It will now return ENXIO,
On Tuesday 19 February 2008, Sean MacLennan wrote:
I left in the volatiles, since I don't
understand why they where needed. The memory always seems to be access
with in_8 and out_8, which are declared volatile. But they could be
there to fix a very specific bug.
It's very unlikely that
On Tuesday 19 February 2008, Stefan Roese wrote:
On Tuesday 19 February 2008, Jean Delvare wrote:
With this Kconfig change, make menuconfig lets me select the
i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
that you want to restrict the build to PPC machines somehow,
On Wednesday 20 February 2008, Stephen Rothwell wrote:
- depends on IBM_OCP
+ depends on IBM_OCP || PPC_MERGE
not PPC_OF? or even OF (give the sparc guys the opportunity to build it
for us :-))?
Right, I was looking for that option but couldn't find it. I would
guess
On Wednesday 27 February 2008, Maynard Johnson wrote:
Sounds to me that your kernel module will try to copy_from_user() from
the user context of ... insmod :-)
Yeah, that's probably the problem (along with my lack of understanding
how VM works -- heh). I guess I was just getting
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
To pick up a few small fixes for the cell platform. Most of it is a follow-up
to the IOMMU rework that got merged in 2.6.25-rc1 and caused problems on
machines with large amounts of memory.
The
On Saturday 01 March 2008, Josh Boyer wrote:
--- linux-2.6.orig/drivers/serial/of_serial.c
+++ linux-2.6/drivers/serial/of_serial.c
@@ -72,6 +72,11 @@ static int __devinit of_platform_serial_
int port_type;
int ret;
+ if (!of_device_is_available(ofdev-node)) {
+
On Friday 29 February 2008, Michael Ellerman wrote:
On Fri, 2008-02-29 at 06:12 +0100, Arnd Bergmann wrote:
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
To pick up a few small fixes for the cell platform. Most
mean don't touch in all
circumstances, so original patch
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This is a patchset for 2.6.26 which contains following changes:
- cleanup [PATCH 1/11]
- move celleb files into platforms/cell/ [PATCH 2/11]..[PATCH 7/11]
- consolidate io-workarounds code [PATCH
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch moves the base code for celleb support into platforms/cell/.
All files in this patch are used by celleb-beat and celleb-native commonly.
Moving around the files this way is good, but
+++ b/arch/powerpc/platforms/cell/Makefile
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch moves the SCC (Super Companion Chip) related code for celleb
into platforms/cell/.
All files in this patch are used by celleb-beat and celleb-native commonly.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch moves files for Beat hvcall interfaces into platforms/cell/.
All files in this patch are used by celleb-beat only.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
if you address my comment
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch moves files for mmu and iommu on Beat into platforms/cell/.
All files in this patch are used by celleb-beat only.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
if you address my comment
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch moves SPU support code on Beat into platforms/cell/.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
if you address my comment to patch 2/11
On Wednesday 05 March 2008, Ishizaki Kou wrote:
Now, we can use generic io-workarounds mechanism and the workaround
code for spider-pci. This patch changes Celleb PCI code to use
spider-pci code.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED
-by: Arnd Bergmann [EMAIL PROTECTED]
This one looks good, but I wonder if we should make it possible to
also use it on QS20, which the current code doesn't allow.
It's a rather hypothetical question, because QS20 has been replaced
by QS21 as a product and it never supported PCIe cards with I/O space
/hvc_console.c splits given output into 16 bytes
at maximum.
Reported-by: Timur Tabi [EMAIL PROTECTED]
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
obviously correct
___
Linuxppc-dev mailing list
Linuxppc-dev
On Wednesday 05 March 2008, Ishizaki Kou wrote:
This patch splits cell io-workaround code into spider-pci dependent
code and a generic part, and also adds interfaces to the generic
io-workaround mechanism.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
---
Please test on CellBlade because
On Tuesday 11 March 2008, David Gibson wrote:
On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.
So,
On Monday 31 March 2008, Jerone Young wrote:
+{
+ unsigned long msr_save;
+
+ /* set wait state MSR */
+ local_irq_enable();
+ msr_save = mfmsr();
+ mtmsr(msr_save|MSR_WE);
Why don't you |MSR_WE|MSR_EE at the same time?
You technically can do this. But the
On Tuesday 25 March 2008, Carl Love wrote:
This patch fixes a bug in the code that records the SPU data and
context switches. The buffer_mutex lock must be held when the
kernel is adding data to the buffer between the kernel and the
OProfile daemon. The lock is not being held in the current
PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thursday 03 April 2008, John Linn wrote:
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the
On Thursday 03 April 2008, Josh Boyer wrote:
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
Signed-off-by: John Linn [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
This is the second time all three of us have Acked
forward all three patches in their latest version?
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wednesday 02 April 2008, Carl Love wrote:
On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
On Tuesday 25 March 2008, Carl Love wrote:
This patch fixes a bug in the code that records the SPU data and
context switches. The buffer_mutex lock must be held when the
kernel
On Tuesday 08 April 2008, Matt Sealey wrote:
Grant Likely wrote:
Sure, why not? If the firmware has already set it up correctly and no
devices using it are in use, then the kernel should be okay. :-)
That said, I can't imagine choosing to not put the cdm node into the
device tree.
On Friday 04 April 2008, Jerone Young wrote:
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path(/hypervisor);
+ if (node) {
+ /* if we find /hypervisor node is in
On Friday 04 April 2008, Josh Boyer wrote:
On Fri, 04 Apr 2008 01:12:38 -0500
Jerone Young [EMAIL PROTECTED] wrote:
+static int current_mode = 0;
Leave this as: static int current_mode;, so it'll end up in the bss
The problem here is that this defines the default case. Is
On Tuesday 08 April 2008, Josh Boyer wrote:
Actually, a static assignment to 0 has not caused the symbol to end up
in .data for many gcc versions, it always goes into .bss now unless you
assign it a value other than 0 or use explicit section attributes.
IIRC, gcc 3.2 is still supported
On Monday 07 April 2008, Hollis Blanchard wrote:
--- a/include/asm-powerpc/kvm.h
+++ b/include/asm-powerpc/kvm.h
@@ -1,6 +1,55 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ *
On Tuesday 08 April 2008, Hollis Blanchard wrote:
If there is one thing I have learned in my various porting efforts, it's that
using a variable-sized type in an interface is just begging for trouble.
x86 uses fixed 64-bit variables here (even with x86-32), so that might be the
right
On Tuesday 08 April 2008, Carl Love wrote:
On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote:
Our first thought to fix the bug was to just grab the mutex lock when
adding the switch notification data to the queue. The kernel gives us
an oops message saying something along the line
On Tuesday 08 April 2008, Jerone Young wrote:
+static struct sleep_mode modes[] = {
+ { .name = wait, .entry = ppc44x_idle },
+ { .name = spin, .entry = NULL },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+
On Thursday 10 April 2008, Jerone Young wrote:
Well it could be this simple. But the current code leaves a lot more
room to add different type waits or spins if need be (if they are ever
needed ... though none off the top of my head at the moment)...but it
does allow you to create another wait
On Wednesday 12 March 2008, York Sun wrote:
+#include linux/bootmem.h
+#include asm/rheap.h
+
+#undef DEBUG
+#ifdef DEBUG
+#define DPRINTK(fmt, args...) printk(KERN_DEBUG %s: fmt, __func__, ##
args)
+#else
+#define DPRINTK(fmt, args...)
+#endif
Please don't define your own debug
On Thursday 05 July 2007, Timur Tabi wrote:
static int at91_pcm_mmap(struct snd_pcm_substream *substream,
struct vm_area_struct *vma)
{
struct snd_pcm_runtime *runtime = substream-runtime;
return dma_mmap_writecombine(substream-pcm-card-dev, vma,
On Friday 06 July 2007, Timur Tabi wrote:
Arnd Bergmann wrote:
Not sure exactly what arm does here, but it sounds like you want
to call remap_pfn_range with the _PAGE_NO_CACHE bit set in the
protection flags, and _PAGE_GUARDED not set.
I always have a hard time with these mapping
On Saturday 07 July 2007, Grant Likely wrote:
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -63,6 +63,8 @@ static void __init mpc834x_itx_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
+
+
On Saturday 07 July 2007, Sergei Shtylyov wrote:
the reg-shift property. I'll send a patch shortly, and I'll reorder the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Certainly. BTW, was there really ns8250 -- 8250 is
On Saturday 07 July 2007, David Woodhouse wrote:
Can we add properties to indicate the common high-speed modes too? The
Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not
On Saturday 07 July 2007, Sergei Shtylyov wrote:
Arnd Bergmann wrote:
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
Hmm, are we still adding new IDE drivers? Do
On Sunday 08 July 2007, Segher Boessenkool wrote:
[EMAIL PROTECTED] {
+ device_type = 8042;
Drop the device_type. A number as a name isn't
all that great, either.
Yet it's kinda accepted years ago, see:
On Monday 09 July 2007, Scott Wood wrote:
In older versions of glibc (through 2.3), the dynamic linker executes a
small amount of code from the data segment, which is not marked as
executable. A recent change (commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
stops this from working; there
On Monday 09 July 2007, Scott Wood wrote:
The hardware in question doesn't support non-executable mappings;
otherwise, it'd never have worked in the first place. Note that this is
only allowed on 32-bit, non-book-E.
There isn't much value in enforcing non-exec mappings only if it happens
On Tuesday 10 July 2007, Josh Boyer wrote:
+#ifdef CONFIG_PPC64
+typedef unsigned long mm_context_id_t;
+
+typedef struct {
+ mm_context_id_t id;
+ u16 user_psize; /* page size index */
+
+#ifdef CONFIG_PPC_MM_SLICES
+ u64 low_slices_psize; /* SLB page size
On Tuesday 10 July 2007, Josh Boyer wrote:
+ u16 user_psize; /* page size index */
+
+#ifdef CONFIG_PPC64
This needs to be moved up to encompass the u16 user_psize member as
well, yes?
Yes, of course. my bad.
Arnd
___
1 - 100 of 1968 matches
Mail list logo
