On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote:
>
> In all code I have done for the XFB, I map it like any other RAM and
> dcbst it after writing to it. Maybe that is slower though, WIMG=0100
> might be better. Dunno.
Well, it depends also what you want to do with it. If you want
Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we
want the framebuffer
in MEM1 for performance reasons.
How big is the fb ?
A bit more than a megabyte, something like that.
We have plenty of BATs on these things... s
There you can find the hardware interface that supports the IPC
mechanism.
It is made up of a pair of registers to pass data between the
processors and a
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data
available for it.
Ok. So the right way t
They are a bit special because registers are in reverse little
endian format,
must be written in 32-bit chunks, and (all things point to) they
have hardware bugs.
Well.. first what is "reverse little endian" ? :-) Big endian ?
Nah. Little-endian, with a 32-bit bus swizzle. This is not the
Segher Boessenkool wrote:
>> So what is at d000 ?
>
> 0c00 is the flipper-compatible stuff
> 0d00 is the hollywood new devices
> 0d80 is the same as part of 0d00, but with some extra bits
> sometimes.
>
Also, when in Wii native mode, stuff like EXI, SI and AI (which is
flipp
BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)
There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).
+ /* Team Twiizers' 'min
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O
area) */
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DSP core
somewhere
in the IO chip setup to use memory fro
On Thu, 2009-11-26 at 22:38 +0100, Albert Herranz wrote:
> Yup. The idea is to map the first 16MB of MEM1 with a BAT.
> Mapping the whole 24MB with BATs may not be possible because we want the
> framebuffer
> in MEM1 for performance reasons.
How big is the fb ? We have plenty of BATs on these th
Benjamin Herrenschmidt wrote:
>>> Good point. I can't even guarantee that the kernel will work reliably
>>> with nobats :-) At least you really want the kernel .text to be fully
>>> covered by an IBAT.
>>>
>> It works with nobats.
>
> But does it work -reliably- ? :-)
>
It does AFAICT. My Wii is
Benjamin Herrenschmidt wrote:
> On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:
>
>>> Are the above OHCI and EHCI "special" ? If not, there's an existing
>>> binding for that sort of thing, which btw requires properties to
>>> indicate the endianness of the registers and in-memory data st
> > Good point. I can't even guarantee that the kernel will work reliably
> > with nobats :-) At least you really want the kernel .text to be fully
> > covered by an IBAT.
> >
>
> It works with nobats.
But does it work -reliably- ? :-)
I haven't looked at that for years, but we used to have a
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:
> > Are the above OHCI and EHCI "special" ? If not, there's an existing
> > binding for that sort of thing, which btw requires properties to
> > indicate the endianness of the registers and in-memory data structures
> > etc...
> >
>
> They
Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
>> We need nobats (or a hack in the mmu_mapin_ram() code) because of the
>> discontiguous ram problem.
>
> I would vote for a hack in mmu_mapin_ram() for now.
>
I'll cook that.
> Cheers,
> Ben.
>
Thanks,
Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
>>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> Like others have said already, don't do this. If you need
>> a workaround, put it in the platform code.
>>
>>> +/memreserve/
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
>
> Weird layout... nothing you can do about I suppose.
>
> Out of curios
On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
>
> We need nobats (or a hack in the mmu_mapin_ram() code) because of the
> discontiguous ram problem.
I would vote for a hack in mmu_mapin_ram() for now.
Cheers,
Ben.
___
Linuxppc-dev mailing
On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
> > +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>
> Like others have said already, don't do this. If you need
> a workaround, put it in the platform code.
>
> > +/memreserve/ 0x1000 0x0004000; /* DSP R
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DS
Segher Boessenkool wrote:
>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>
> Like others have said already, don't do this. If you need
> a workaround, put it in the platform code.
>
I'll do. Thanks.
>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
>
> This
Segher Boessenkool wrote:
+ i2c-video {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "virtual,i2c-gpio";
>>> There isn't a documented binding for this. Is there a driver for it?
>>>
>
> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
Like others have said already, don't do this. If you need
a workaround, put it in the platform code.
> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
This address is fixed in the DSP hardware, right? If not,
you
>>> + i2c-video {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "virtual,i2c-gpio";
>>
>> There isn't a documented binding for this. Is there a driver for it?
>>
>
> I have a driver for it. Bu
Grant Likely wrote:
> This looks pretty good to me. The documentation format isn't strict,
> just follow the pattern seen in other bindings. Make sure you post
> new bindings to devicetree-disc...@lists.ozlabs.org for review. A
> couple of comments below.
>
Ok. I know it now for the next time
On Mon, Nov 23, 2009 at 12:54 PM, Albert Herranz
wrote:
> Grant Likely wrote:
>> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz
>> wrote:
>>> + i2c-video {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz
> wrote:
>> Add a device tree source file for the Nintendo Wii video game console.
>>
>> Signed-off-by: Albert Herranz
>
> Same comments apply here as for the gamecube.dts file, plus a few more below.
>
Ok, I'll try to addr
On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz wrote:
> Add a device tree source file for the Nintendo Wii video game console.
>
> Signed-off-by: Albert Herranz
Same comments apply here as for the gamecube.dts file, plus a few more below.
Cheers,
g.
> ---
> arch/powerpc/boot/dts/wii.dts | 2
Add a device tree source file for the Nintendo Wii video game console.
Signed-off-by: Albert Herranz
---
arch/powerpc/boot/dts/wii.dts | 244 +
1 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/wii.dts
diff --gi
27 matches
Mail list logo
