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 m...@genesi-usa.com
Genesi, Manager, Developer Relations
___
Linuxppc-dev
On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder i...@ovro.caltech.edu 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, aligned
On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder i...@ovro.caltech.edu 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 i...@ovro.caltech.edu wrote:
On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
I'm pretty sure
this has absolutely no functional impact compared to the
old one? It doesn't change any behaviour, just implements exactly the
same in a much nicer way?
--
Matt Sealey m...@genesi-usa.com
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
a DMA-capable PCI
card in an MPC5200B board before? :)
--
Matt Sealey m...@genesi-usa.com
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
+-
+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 m...@genesi-usa.com
Genesi, Manager, Developer Relations
why you broke it ... good luck ;-).
I thought Grant *WAS* the MPC52xx maintainer :D
--
Matt Sealey m...@genesi-usa.com
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo
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 platforms.
-- Matt Sealey m
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
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 m...@genesi-usa.com wrote:
Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
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
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 milt...@bga.com
---
compile tested on Matt's 2.6.27.7 config, both
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:15 AM, Matt
?
-- Matt Sealey m...@genesi-usa.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 m...@genesi-usa.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https
different filesystem codes in 3
alternative loaders and
the kernel).
But unfortunately most systems have crap CIF support (ours included)
which do not
come up to the task.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc
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
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 Erickson
[EMAIL
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), perhaps something in the
/chosen node that U-Boot etc. can
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:
On Tue, 25 Nov 2008 12:53:12 -0600
Matt Sealey [EMAIL PROTECTED] wrote:
Nitpick, really
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's FirmWorks, CodeGen SmartFirmware, IBM SLOF
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?
Umm, so that it can be ported to new boards perhaps? So
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.
Here are the section of my
/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
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@ozlabs.org
https://ozlabs.org/mailman/listinfo
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
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
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
___
Linuxppc-dev mailing list
Linuxppc
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 prefer this.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager
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
, 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
kernel and compare results?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager
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, Manager, Developer Relations
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
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
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
___
Linuxppc-dev
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
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
https://ozlabs.org/mailman/listinfo
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 declaring
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 have one
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
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
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 great, I just don't think
anything will get done about it (emotional moment) as usual.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager
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
___
Linuxppc-dev mailing list
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 = controller pin1
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 controllers
at without delving. There is already
too much needless cross-referencing in Linux as it is.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo
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
with 8 devices
on it, I suppose you could have more than 100 if you got your
addresses right) and having a device 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
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
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
but supporting only a subset of
that controller, needs addressing.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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
Linuxppc-dev@ozlabs.org
https
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
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 it from the dts files.
Suggested-by: Scott
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 list
Linuxppc-dev@ozlabs.org
https
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 supported
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 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 e500
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 really
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!),
Checked where
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 a little jumpy
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, to which I
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 [EMAIL PROTECTED
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
https://ozlabs.org
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]
Genesi, Manager, Developer Relations
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
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
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 mailing list
- 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 PROTECTED]
Genesi, Manager, Developer Relations
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
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 consolidate the
existing PWM
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 NACKs back
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 though right
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 with it :)
--
Matt Sealey
. But as you said, there are uses for it; and
the APUS swap implementation did allow raw access, 16-bit and 32-bit
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
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 now I
, 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
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
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, Developer Relations
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 than
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
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]
Genesi, Manager, Developer Relations
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 _directly_
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 internal registers
) 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() functions,
that doesn't have
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 anything related
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
directive
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]
Genesi, Manager, Developer Relations
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
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 mailing list
Linuxppc-dev@ozlabs.org
https
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't support S
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:
Hi guys,
Quick
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 with that though.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager
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
pin it
to my wall)
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Scott Wood wrote:
Kevin Diggs wrote:
Hi,
x86 has bsf and bsr. PPC has cntlzw which I think is equivalent to
bsr. Anyone know of a sneaky algorithm to do bsf?
wordsize - 1 - cntlzw(x ~(x - 1
is important.. flipping bits here and there without
something in the way in the API is kind of clumsy)
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Grant Likely wrote:
On Thu, Apr 24, 2008 at 9:36 AM, Sascha Hauer [EMAIL PROTECTED] wrote:
Hi all,
Feel free to comment
Why not just have users who wish to use console serial port autodetection
add 3 lines to their nvramrc?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Olaf Hering wrote:
Pegasos2 has no current-speed property in
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED
, the matchlist is 5200b only..? No alarms and no
surprises.. :)
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Grant Likely wrote:
On Fri, Apr 18, 2008 at 12:11 PM, Matt Sealey [EMAIL PROTECTED] wrote:
Juergen Beisert wrote:
BTW, is anyone trying to shepherd this driver into the ALSA tree? Its
out of my area of expertise and responsibility, so I haven't been
pursuing it.
We (well, I) were going
experience with device trees and BSPs, and can work with the device
vendors and board manufacturers (Freescale for example) directly, with
them on the committee, who can give the docs a run though before any
board ever hits the streets...
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer
1 - 100 of 172 matches
Mail list logo
