On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
>> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
>> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>> >
>> > I'm pr
On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>
> I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> want. They don't change byte ordering.
Are they guaranteed to only do 32-bit, ali
there something like a direct ioread32le() or so, which will
not change behaviour across architectures, is present on ARM and PPC,
and will handle both PCI address space, and "normal" "ioremapped"
memory?
--
Matt Sealey
Genesi, Manager, Developer Relations
__
eth0_pd.rx_sram_size = 0;
> -
> - eth1_pd.tx_sram_addr = 0;
> - eth1_pd.tx_sram_size = 0;
> - eth1_pd.rx_sram_addr = 0;
> - eth1_pd.rx_sram_size = 0;
> + eth_po
; +-
> +The FEC node can specify one of the following properties to configure
> +the MII link:
Is it fec or ethernet? Obviously the first one is an example only but
it should least reflect real life..
--
Matt Sealey
Genesi, Manager, Developer Relations
__
?
What's the expected impact and how come nobody tried a DMA-capable PCI
card in an MPC5200B board before? :)
--
Matt Sealey
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
red to the
old one? It doesn't change any behaviour, just implements exactly the
same in a much nicer way?
--
Matt Sealey
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
have to explain to the
> maintainer why you broke it ... good luck ;-).
I thought Grant *WAS* the MPC52xx maintainer :D
--
Matt Sealey
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
is only Freescale eSDHC controller known to exists
+ on OF platforms.
Nit; would probably be better English as
This selects the OF support for Secure Digital Host Controller
Interfaces. So far, only the Freescale eSDHC controller is known
to exist on OF platform
also able to configure
either port as CONSOLE in U-Boot so the Hardware is ok.
So you're getting debug output (udbg type stuff) on them?
-- Matt Sealey
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
some light
on why Efika ATA DMA doesn't work? :)
-- Matt Sealey
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Grant Likely wrote:
On Wed, Jan 7, 2009 at 8:51 PM, Matt Sealey wrote:
Grant Likely wrote:
From: Grant Likely
The MPC5200 PIC driver doesn't correctly update the .status field of
the irq_desc structure when the set_type hook is called. This patch
adds the required code.
Also cleans u
Grant Likely wrote:
From: Grant Likely
The MPC5200 PIC driver doesn't correctly update the .status field of
the irq_desc structure when the set_type hook is called. This patch
adds the required code.
Also cleans up the external IRQ typename field to be something easier
to read (very minor).
still around, you can still
output to it (check prom_init.c) and if not, the open firmware
framebuffer console driver is your best friend..
sumedh tirodkar wrote:
Isn't there any other way that i can access the VGA registers? So as
to reconfigure them...
-Sumedh
On Wed, Dec 31, 2008 at 4:1
heir specific names.
Note that this does not setup the cpu_die pointers in either
smp_ops (request a given cpu die) or ppc_md (make this cpu die),
for other platforms but there are generic versions in smp.c.
Reported-By: Matt Sealey
Signed-off-by: Milton Miller
---
compile tested on Matt'
c platform support to
get SMP? Why?
-- Matt Sealey
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
boot what could be a perfectly workable kernel
on previous U-Boot versions.
Isn't there any documentation on this apart from git changesets hidden
behind obscure many-digit hashes?
--
Matt Sealey
___
Linuxppc-dev mailing list
Linuxppc-dev@ozla
d load it's
own initrd without the help of Yaboot or GRUB, for example, right in
the boot wrapper,
and to the location it sees best to load it, and not what Yaboot
decides for it, and there
would be no need to maintain 4 different filesystem codes in 3
alternative loaders and
th
ich may vary.
>
I think I covered that in "I can think of a bunch of reasons why it's a good
idea.. " - but the current implementation is hardcoded in the kernel so
there is no problem with *certain* boards having it done this way, and that
information being moved from the
On Tue, Nov 25, 2008 at 2:17 PM, Grant Likely <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
> > But here's the real question; why do you need an opensource
> implementation?
> > Curiosity?
>
>
On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
>
> > I can think of a bunch of reasons why it's a good idea..
>
> Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
> implementation?
>
Yes, there
ust like
the linux,initrd-start and -end, making a whole new node seems wasteful.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
On Tue, Nov 25, 2008 at 1:04 PM, Grant Erickson <[EMAIL PROTECTED]>wrote:
> On 11/25/08 10:55 AM, Josh Boyer wrote:
> &g
On Tue, Nov 25, 2008 at 12:55 PM, Josh Boyer <[EMAIL PROTECTED]>wrote:
> On Tue, 25 Nov 2008 12:53:12 -0600
> "Matt Sealey" <[EMAIL PROTECTED]> wrote:
>
> > Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
> > property(ies)
Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
property(ies), perhaps something in the
/chosen node that U-Boot etc. can then fill out?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
On Tue, Nov 25, 2008 at 12:34 PM, Grant Erick
agine what it might be.
Tim, did you ever see any ethernet problems like this?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ne command out of it - "make tools/mkimage" doesn't work and I got
tired of reverse engineering the chickenscratch..)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlab
o patch it onto and another interrupt controller patch crippled
performance so it wasn't a really good test..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Lehmann, Hans (Ritter Elektronik) wrote:
We take a vanilla kernel with rt11 patches from Ingo Mollnar.
uxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
René Bürgel wrote:
Matt Sealey schrieb:
Alternativly, if you have more control over your serial device, just
send breaks continuously, open and close the serial port. Open it again
and receiving data fails, if the bug is present.
Well I have a couple systems I can write data from here, a
sing the system over a serial console, how are you supposed to test
serial port operation? USB doesn't work in >2.6.24 so I guess I have to
hope netconsole works :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Wolfram Sang wrote:
On Mon, Nov 03, 2008 at 03:57:09PM -0600, Matt Sealey wrote:
Optionally you can further
reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined.
I would much prefer this.
I submitted a patch to enable pipelining on a MPC5200B recently. It was
disabled because
ce tree in
the kernel source and make sure efika.forth follows it as best as I
can, and then make a release.. that won't fix anything for people who
don't run the script, however.
> Optionally you can further
reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined.
I would much
a patch along with a couple other things tomorrow or the
weekend based on what I hear here..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
st thing I have EVER seen submitted to mainline :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
so I don't think it is any fault of that).
Any clues why we would get this?
I've had the same problem with my MPC8641D but since I broke it
last week I've not had a chance to actually test it since.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Ma
e that Freescale might fix
it after the fact in some useless future revision, the biggest
problem is that if nobody writes a driver for it, nobody experiences
the problem!
Once the patch is in maybe someone will be willing to use the
BestComm-assisted PIO idea as implemented in the bplan 2.6.19
ker
at I have to have 3 windows
open to understand the intent of a 10 line snippet in a driver..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ld really
rock as it's bringing the abstraction and description of the
device tree back into userspace, where let's be honest, they do
not give a crap about device tree bindings, only what pin does
what action :D
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
_
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 08:11:12PM -0500, Matt Sealey wrote:
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
A bunch of things spring to mind:
* How do you define a GPIO bank in a device tree, not a controller
Not a controller
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
A bunch of things spring to mind:
* How do you define a GPIO bank in a device tree, not a controller
Not a controller? What do you mean by "bank"? There is no such
thing. There are GPIO contro
David Gibson wrote:
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
Uh.. no. The gpio specifier has a format that's gpio controller
specific, but it must include the actual pin number, although exactly
how it's encoded might vary.
So, you use
gpios = <&am
ver there is no standard way to expose it. And people just grab a
pin they "know" is free on their particular board.
Are you sure you do NOT see any shortcomings here?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
__
es. I actually saw the voltage
controller framework go into 2.6.27 and they have designed it
around the operation of two PMUI chips which are pretty much
the industry standard. GPIO device tree does not seem to have
gotten the same amount of attention.
Yes, your idea, Mitch's discussion was
es which change every other week. Specifying the
bare minimum here for the functionality a single user uses
defeats the object of having a descriptive device tree.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ing these if it is their responsibility,
are things like the mysterious i2c binding going to be published
under this TSC?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Scott Wood wrote:
Matt Sealey wrote:
Nobody is saying that device_type should not be used in real OF when an
appropriate method interface exists. What we're saying is that flat
device trees, which are incapable of providing a method interface,
should not lie and claim that they hav
David Gibson wrote:
On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:
Mitch Bradley wrote:
device_type in 1275 defines the runtime method interface. It's *not*
for declaring the general class of the device, although it often
matches that in practice.
It *is* for declarin
pins which are NOT consecutive because the current GPIO
spec stops after specifying a controller bank (the 32-bit
register).
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
rth script for real OF, this is such a great idea, I don't
know why it's not already there :)
* http://www.powerdeveloper.org/platforms/efika/devicetree
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
umbered "reg" is the first port on the back of the chassis
and finding out that is not how it's connected :)
I'm really big on descriptive device trees that I can just browse
and know what I am looking at without delving. There is already
too much needless cross-referencing
oint, I concede to your much better plan :D
Back to the other discussion, where we give individual GPIOs some
names so they are detectable and not just programmable as a bank,
do you have any ideas about that? :/
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
t
of first pin) with the current system?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ice tree that goes on for 8
screens would not be so bad to maintain.
And no, I did NOT just volunteer to write one, I'm happy coding my
device tree updates in Forth :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
u were
bitbanging some protocol (SPI, I2C or so) or driving a device
where you could change this stuff, or even dynamically work
out if a connector was inserted a certain way (I'm thinking of
maybe an expansion connector which can run line-reversed like
PCI Express.. but made out of GPIO. Am I nuts?)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
cated to a controller and usable (these
may be pin 5, pin 9 and pin 20, so a "base" of pin 5 would be
outrageously inadequate).
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Lin
full 8 timers as a
"gpio-controller" and "pwm-controller" both at the same time,
sharing the same reg property but supporting only a subset of
that controller, needs addressing.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
as to keep 32-bit pointers in the unlikely event that
someone actually uses the client interface (besides yaboot!).
Having I/O in the 36-bit range could cause all sorts of
explosions, and we're running real-mode so trapping and faking
I/O accesses is REALLy difficult :}
--
Matt Sealey &l
Becky Bruce wrote:
On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote:
Yeah so I saw BookE and e500 stuff go past but nothing specific for
e600/XAEN. I mailed Becky and got no response. I'm glad to know it's
in there though, somewhere.
Huh? I have one mail from you, on Sep 1,
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
I think I got it. ;-) You think that I'm not aware of that we _can_
use the device_type for matching the nodes. Well, I'm aware of it,
sure we can. ;-)
I'm sure you are aware, I am just
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
I'm extremely troubled that it is "not used in the code", surely
device_type is checked as a legacy for Open Firmware (otherwise a lot of
devices may never be detected!),
Kumar Gala wrote:
On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote:
~~
The CCSR window always takes precedence over all local access windows.
However, the CCSR window must not overlap an LAW that maps to the DDR
controller. Otherwise, undefined behavior occurs.
~~
So, it's not r
Kumar Gala wrote:
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support the
MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of
y requires non-contiguous memory..?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support the
MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of e500/BookE support go past but nothing
specific :)
NOT supp
LAWs means it is not fine enough
granularity to map between 2GB and 4GB into a window (you can
have 2GB or 4GB but not some more arbitrary value?)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing lis
ed from new DTS but, just
concerned about your comment and it's impact...)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Anton Vorontsov wrote:
We don't want to encourage the device_type usage. It isn't used in the
code, so we can simply remove
Milton Miller wrote:
+ /* remove any stale propertys so ours can be found */
s/propertys/properties
?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
e loss of preemption.
TCP/IP copy with checksum? Probably absolutely definitely..
Straight memcpy? I am not so sure.
Like I said I am far more worried about how you'd get a reasonable
benchmark out of it. Profiling kernels is a messy business..
--
Matt Sealey <[EMAIL PROTECTED]
on earth do we benchmark the differences here?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
that discussion if it's being codified into
a proper standard? Someone should just submit a reasonable extension
to a reasonable extension-managing body :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev m
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-09 at 10:37 -0500, Matt Sealey wrote:
Ahem, but nobody here wants AltiVec in the kernel do they?
It depends. We do use altivec in the kernel for example for
RAID accelerations.
The reason where we require a -real-good- reason to do it is
simply
llion
other things..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Bill Gatliff wrote:
This series proposes a "generic PWM" driver API.
This proposed API is motivated by the author's need to support
pluggable devices; a secondary objective is to co
Timur Tabi wrote:
On Thu, Oct 9, 2008 at 10:59 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
If you really want to build a single-cpu single-board kernel, disable CHRP
and PMAC for those board configs, but the default definitely should be to
enable them all within reason
The problem i
nel, disable CHRP
and PMAC for those board configs, but the default definitely should be to
enable them all within reason (obviously coherent and non-coherent designs
cannot coexist in the same kernel, 32-bit and 64-bit do not play well in
the same kernel..)
--
Matt Sealey <[EMAIL PROTECTED]>
page, zeroing 4kb aligned to a 4kb boundary - or whatever your page
size happens to be, the number of errors that can occur are absolutely
tiny and performance can go through the roof).
Ahem, but nobody here wants AltiVec in the kernel do they?
--
Matt Sealey <[EMAIL PR
Grant Likely wrote:
On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
If this patchset is okay with everyone, is it possible that it could
be rushed into 2.6.27 before it hits rc10 or release? :/
no
Shucks :(
At least it'll patch cleanly against 2.6.27 t
If this patchset is okay with everyone, is it possible that it could
be rushed into 2.6.27 before it hits rc10 or release? :/
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
John Rigby wrote:
The following three patches add pci support for MPC5121
These got no
swaps through "mirrored" memory regions - you could write any way
you wanted if you so pleased, or just handle the difference yourself,
or do both if you were a masochist :D
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
sible") is more correct.
The problem is the check against an unsigned value for interrupts (is there
any reason why you would need 4 billion interrupts possible instead of just
2 billion?) although I must say, the patch will work, and probably 99.999%
of people will never see a problem
Benjamin Herrenschmidt wrote:
On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
It's far more common than people might think at first glance. With x86
I am sure it would benefit the platform a little more if the OF support
was in-line with the shared code between PPC and SPARC (and
Gerald Van Baren wrote:
Matt Sealey wrote:
>>
The Toshiba TOPAS910 ARM development board also runs Open Firmware and
contains patches to support OF device trees.
I dare say there might be an x86 box or two out there, too. But they
have ACPI tables too which is far more common..
More
also runs Open Firmware and
contains patches to support OF device trees.
I dare say there might be an x86 box or two out there, too. But they
have ACPI tables too which is far more common..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Develope
e magic in hardware
like Amiga PowerUP cards which endianswap for you :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
e never had this much whining about Apple's device tree, people just
implemented the workarounds..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ible USB drivers and tries to make gpio fit the new gpio specs
and i2c and can buses exposed.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
e which may contain some "errors". There seems to be a lot less
data in our tree...
I can't vouch for the correctness of your tree, though, or tell you
what might be wrong (looks fine as far as I am concerned, but what
do I know? :)
--
Matt Sealey <[EMAIL PROTECTED]>
Gene
Lennert Buytenhek wrote:
On Thu, Sep 04, 2008 at 08:44:31AM -0500, Matt Sealey wrote:
script, but in either case, wouldn't a real sram node in the device
tree be the proper solution here? Hardcoding addresses for devices
Probably.
I guess you don't want to pass that info _direct
os running right now to test but I will, as soon as
possible,
make sure this works first.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Lennert Buytenhek wrote:
This gets rid of a big mv643xx_eth annoyance of mine where the driver
exports the offsets of some of its in
plications) for embedded processors which nobody is
really taking on. But, not many people want to do this kind of work..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
David Jander wrote:
Hello,
I was wondering if there is a good replacement for GLibc memcpy() function
Michel Dänzer wrote:
On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote:
or other graphics drivers can be told "please only use the first 32MB" and
then either manually or automatically, map the rest as ramdisk.
You can limit the amount of video RAM used by X using the VideoRam
di
Jon Smirl wrote:
On 7/20/08, Matt Sealey <[EMAIL PROTECTED]> wrote:
Hi guys,
I know this isn't a PPC question, but since some of the RadeonFB developers
live here I thought best (and it's about a PPC platform).
Is there any way to hack up the RadeonFB driver - or anyth
s, a better solution is to use some kind of in-kernel subsystem to
"allocate" and return a 32MB segment of PCI memory (and put it in an
named rheap) but I assume other drivers can and will simply walk all
over it?
--
Matt Sealey <[EMAIL PROTECTED]>
Gabriel Paubert wrote:
On Tue, Jul 15, 2008 at 04:27:49PM +0100, Matt Sealey wrote:
If you built this kernel yourself, you need to do it from a system with
an up-to-date binutils (2.18) otherwise, it does this.
Note to the linux-ppc guys; is there any changelog entry which reports
this
If you built this kernel yourself, you need to do it from a system with
an up-to-date binutils (2.18) otherwise, it does this.
If you got it from somewhere (like a distribution) then please tell us
where, as there are some other troubles with load-base location for
Fedora and so on...
--
Matt
I think I'll reiterate here as it got lost in my rambling, that I am wondering
if NAP is enabled *by default* and if not, why not on processors that don't
doze? (powersave-nap is 0 here)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Matt Sealey wrote:
Jon Smirl wrote:
On 7/7/08, Matt Sealey <[EMAIL PROTECTED]> wrote:
to do that the samples have to be alternated as they are fed into the
AC97 stream. I think the codec can capture that way too but you
didn't put a transceiver on the S/PDIF line.
OT, but the IDT STAC9766 doesn&
the only system that can
benefit..
On a related note does anyone know of the status or what is going on with
Clifford Wolf's dmatransfer API?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailin
entered on processors
that
support a seperate HID0[DOZE], however is it possible to extend it such that nap
is never entered?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
d at all, in fact I found it harder to read. You may as well throw away
all
the docs altogether and produce a well-commented example set if that is the
route
this is going down. I think having everything as a plaintext file, while nice
and
accessible for everyone, might have something to do
and compile test
just so my kernel builds are "cleaner"..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
1 - 100 of 197 matches
Mail list logo
