On Fri, Dec 11, 2009 at 5:18 PM, Albert Herranz wrote:
> Grant Likely wrote:
>> Hi Albert.
>>
>
> Hi,
>
>> I'm ready to pick up your Gamecube and Wii patch sets for merging.
>> You seem to have 4 distinct patch sets. What order do they need to be
>> applied in, and what kernel version are they ba
On Sat, 2009-12-12 at 01:33 +0100, Albert Herranz wrote:
>
> I'll look into this.
> I used a single lmb range just as the current code does to avoid any
> unwanted side effects as I didn't audit all the mm code.
Well, I -may- be missing something ... but I think outside of the setup
of the initia
On Thu, 2009-12-10 at 20:24 -0600, Kumar Gala wrote:
> This is a good write up. We should have it as a commit message for
> the first patch.
No, that should go into Documentation/powerpc/
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.
Benjamin Herrenschmidt wrote:
> On Tue, 2009-12-08 at 19:43 +0100, Albert Herranz wrote:
>> Signed-off-by: Albert Herranz
>
> Acked-by: Benjamin Herrenschmidt
>
>> ---
>> v1 -> v2
>> - use a run-time flag to allow/disallow remapping reserved regions
>> - use lmbs to determine reserved regions
>
Grant Likely wrote:
> Hi Albert.
>
Hi,
> I'm ready to pick up your Gamecube and Wii patch sets for merging.
> You seem to have 4 distinct patch sets. What order do they need to be
> applied in, and what kernel version are they based on?
>
The patches were based on 2.6.32-rc8.
The apply order
Hi Albert.
I'm ready to pick up your Gamecube and Wii patch sets for merging.
You seem to have 4 distinct patch sets. What order do they need to be
applied in, and what kernel version are they based on?
Thanks,
g.
On Thu, Dec 3, 2009 at 3:47 PM, Albert Herranz wrote:
> The following patches ad
> The key to the solution IMHO is the ability to create an of_platform_device
> in a hardcoded way without data from a device tree, like we create a
> platform_device today. All these static of_devices would then be rooted
> in /sys/platform by default, while those that come from a device tree are
On Thu, 2009-12-03 at 21:35 +0100, Albert Herranz wrote:
> Add support for using the USB Gecko adapter as an early debugging
> console on the Nintendo GameCube and Wii video game consoles.
> The USB Gecko is a 3rd party memory card interface adapter that provides
> a EXI (External Interface) to USB
On Thu, 2009-12-03 at 21:34 +0100, Albert Herranz wrote:
> Add a set of entries to the fixmap table to allow usage of known
> reserved virtual address space by early debug code.
>
> The address space reserved is the top 128K of the 32-bit address
> space. This allows, if required, the use of a BAT
On Tue, 2009-12-08 at 19:43 +0100, Albert Herranz wrote:
> Signed-off-by: Albert Herranz
> ---
> arch/powerpc/platforms/embedded6xx/wii.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
Acked-by: Benjamin Herrenschmidt
> diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
> b
On Tue, 2009-12-08 at 19:43 +0100, Albert Herranz wrote:
> Signed-off-by: Albert Herranz
Acked-by: Benjamin Herrenschmidt
> ---
> v1 -> v2
> - use a run-time flag to allow/disallow remapping reserved regions
> - use lmbs to determine reserved regions
We won't need that once we fix proper disco
On Tue, 2009-12-08 at 19:43 +0100, Albert Herranz wrote:
> The top portion of MEM2 (the second 64MB memory block) in the Nintendo
> Wii video game console is used by the firmware running on the Starlet
> processor.
>
> Add code to calculate the portion of MEM2 safely useable by the
> Broadway proc
On Tue, 2009-12-08 at 19:43 +0100, Albert Herranz wrote:
> Signed-off-by: Albert Herranz
Acked-by: Benjamin Herrenschmidt
That will do for now. At some stage somebody should look at getting
proper sparsemem etc... working (or even normal linear memmap with a
hole which isn't actually hard but w
On Thu, 2009-12-03 at 23:47 +0100, Albert Herranz wrote:
> Add a default configuration for the Nintendo Wii video game console.
>
> Signed-off-by: Albert Herranz
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/configs/wii_defconfig | 1406
>
> 1 fil
On Thu, 2009-12-03 at 23:47 +0100, Albert Herranz wrote:
> +static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
> + struct irq_desc *desc)
> +{
> + struct irq_host *irq_host = get_irq_data(cascade_virq);
> + unsigned int virq;
> +
> + spin_lock
On Thu, 2009-12-03 at 23:47 +0100, Albert Herranz wrote:
> This patch extends the cputable entry of the 750CL to also match
> the 750CL-based "Broadway" cpu found on the Nintendo Wii.
>
> As of this patch, the following "Broadway" design revision levels have
> been seen in the wild:
> - DD1.2 (871
On Thu, 2009-12-03 at 23:47 +0100, Albert Herranz wrote:
> Add support for the Nintendo Wii video game console to the powerpc
> bootwrapper.
>
> dtbImage.wii is a wrapped image that contains a flat device tree,
> an entry point compatible with the Homebrew Channel and BootMii,
> and an optional in
On Thu, 2009-12-03 at 23:47 +0100, Albert Herranz wrote:
> Add a device tree source file for the Nintendo Wii video game console.
>
> Signed-off-by: Albert Herranz
Acked-by: Benjamin Herrenschmidt
> ---
> v1 -> v2
> - Document new bindings in Documentation/powerpc/dts-bindings.
> Suggestion
Hi Scott:
After enabling debugging option from kernel (2.6.29) , here is the log.
We do have an external debugger(BDI). But soon after the crash happens,
looks like the core freezes and hence reading from any location in memeory
gives "SAP: Read access failed" error.
I have disabled PCI.
--Than
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 i
On Dec 11, 2009, at 2:07 PM, Thiago Jung Bauermann wrote:
> On Fri 11 Dec 2009 00:27:36 Dave Kleikamp wrote:
>> On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
>>> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
#define PPC_DEBUG_FEATURE_INSN_BP_RANGE0x1
#define PPC_D
On Fri 11 Dec 2009 00:27:36 Dave Kleikamp wrote:
> On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> > On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> > > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
> > > #define PPC_DEBUG_FEATURE_INSN_BP_MASK0x2
> > > #define PPC_DEB
Junita Ajith wrote:
Hi Scott:
I am still stuck at Linux kernel booting in MPC8343EA based board.
I have disabled "Ethernet, PCI, USB, dma engines " in the *.dts file and
also in the kernel config.
I am using MPC8349emitxgp.dts ; enabled MPC8349ITX support in kernel
config also. In fact, I tr
Hi Grant:
Am 11.12.09 07:02 schrieb(en) Grant Likely:
The existing API (of_get_gpio()) doesn't operate on gpio-controller
nodes. It operates on a node that uses the gpio (has a 'gpios'
property as documented in
Documentation/powerpc/dts-bindings/gpio/gpio.txt).
Thanks a lot for that pointer -
On Fri, Dec 11, 2009 at 8:25 AM, Arnd Bergmann wrote:
> On Thursday 10 December 2009, Grant Likely wrote:
>> On Wed, Dec 9, 2009 at 5:21 PM, David Miller wrote:
>> > From: David Miller
>> > Date: Wed, 09 Dec 2009 16:15:50 -0800 (PST)
>> >> What a shame, it's one of the cleanest driver probing mo
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/hw_breakpoint.h | 55
Hi All,
Please find a new implementation of hardware breakpoint
interfaces for PPC64. These interfaces have undergone substantial
changes over the previous revision following their integration
with perf-events infrastructure (and hence the long break from
the previous posting). The hw-break
>
> On Thursday 10 December 2009, Grant Likely wrote:
> > On Wed, Dec 9, 2009 at 5:21 PM, David Miller wrote:
> > > From: David Miller
> > > 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 BTW, hav
On Fri, Dec 11, 2009 at 02:39:53PM +0100, Anatolij Gustschin wrote:
>Add nodes for PPC440SPe DMA, I2O, XOR engines and Memory
>Queue module which are used in the updated PPC440SPe ADMA
>driver. Also extend plb ranges property to specify address
>ranges for DMA0/1 and I2O engines.
>
>Signed-off-by:
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
> "Kumar" == Kumar Gala writes:
Hi,
Kumar> We need a binding document to go with this.
Ok, but where should it go? In the existing
powerpc/dts-bindings/fsl/8xxx_gpio.txt or somewhere seperate? I don't
see any other interrupt controller documentation besides the stuff in
booting-without-of.
On Thursday 10 December 2009, Grant Likely wrote:
> On Wed, Dec 9, 2009 at 5:21 PM, David Miller wrote:
> > From: David Miller
> > 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 BTW, have you folks who "d
On Dec 10, 2009, at 9:28 PM, David Gibson wrote:
> On Thu, Dec 10, 2009 at 08:41:53PM -0600, Kumar Gala wrote:
> [snip]
>>> +#define DBCR1_USER_DEBUG (DBCR1_IAC12M | DBCR1_IAC34M)
>>> +#define DBCR1_BASE_REG_VALUE (DBCR1_IAC1US | DBCR1_IAC1ER_10 | \
>>> +DBCR1_
Add nodes for PPC440SPe DMA, I2O, XOR engines and Memory
Queue module which are used in the updated PPC440SPe ADMA
driver. Also extend plb ranges property to specify address
ranges for DMA0/1 and I2O engines.
Signed-off-by: Yuri Tikhonov
Signed-off-by: Anatolij Gustschin
---
v3 of the updated PP
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 has a G4 running at 1 GHz; I get around 3
MB/s throughpu
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
While executing cpu_hotplug(from autotest) tests against latest
next on a power6 box, the machine locks up. A soft reset shows
the following trace
cpu 0x0: Vector: 100 (System Reset) at [cc9333d0]
pc: c03433d8: .find_next_bit+0x54/0xc4
lr: c0342f10: .cpumask_next_and
37 matches
Mail list logo
