This patch adds some internal documentation in libfdt.h, in the form
of comments on the error codes and some functions. Only a couple of
functions are covered so far, leaving the documentation still woefully
inadequate, but hey, it's a start.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index
On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz <[EMAIL PROTECTED]> wrote:
>
> + root = of_find_node_by_path("/");
> + if (root)
> + model = of_get_property(root, "model", NULL);
> + of_node_put(root);
The paranoid part of me says:
On Wed, 24 Oct 2007 01:13:21 +0200 Marian Balakowicz <[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -155,11 +155,7 @@ static void __init lite5200_setup_arch(void)
> #endif
>
> #ifdef CONFIG_PCI
> - np = of_find_node_by_type(NULL, "pci");
> - if (np) {
>
Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
uses struct scatterlist->page which no longer exists since commit
18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
sg_page(sg) instead of sg->page.
Signed
On Tue, 2007-10-23 at 23:00 +0200, Johannes Berg wrote:
> Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
> 78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
> uses struct scatterlist->page which no longer exists since commit
> 18dabf473e15850c0dbc8ff13ac1e2806d542c
On Tue, Oct 23 2007, Johannes Berg wrote:
> On Tue, 2007-10-23 at 23:00 +0200, Johannes Berg wrote:
> > Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
> > 78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
> > uses struct scatterlist->page which no longer exists sin
On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
> I lost track - which kernel are you booting? This looks like something
> that should be fixed, did you try 2.6.24-rc1?
No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
give it a try, but I don't think I can confirm it work
On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote:
> No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> give it a try, but I don't think I can confirm it works before tomorrow.
> I see the build failure got fixed with commit
> 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
On Wed, 2007-10-24 at 11:23 +0200, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote:
>
> > No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> > give it a try, but I don't think I can confirm it works before tomorrow.
> > I see the build failure got
On Wed, Oct 24 2007, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
>
> > I lost track - which kernel are you booting? This looks like something
> > that should be fixed, did you try 2.6.24-rc1?
>
> No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
napi_disable / napi_enable must be applied on all ehea queues.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/dr
Michael Neuling wrote:
> This moves the ability to scale cputime into generic code. This
> allows us to fix the issue in kernel/timer.c (noticed by Balbir) where
> we could only add an unscaled value to the scaled utime/stime.
>
> This adds a cputime_to_scaled function. As before, the POWERPC
>
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a Geyser 1, and I'm a very annoyed that it was
applied. It causes appletouch to continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device
(Geyser 3 mode)
because the G
Dale Farnsworth wrote:
> Valentine wrote:
>> Actually I also don't see much reason for the
>> USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
>> Is this really needed?
>
> I think so. The SOC host controllers are BE and the PCI
> host controllers are LE. Or, do you have an alternative
> me
Hello, I wrote:
>>> The only thing I'm still unusre about is that deterministic accounting.
>>>Could you point me at the patch which deals with this (at least for System
>>>390
>>See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
> Wait, how this is related to the hrt
On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
> Dale Farnsworth wrote:
> >Valentine wrote:
> >>Actually I also don't see much reason for the
> >>USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
> >>Is this really needed?
> >
> >I think so. The SOC host controllers are BE
Hi Johannes,
On 10/24/07, Johannes Berg <[EMAIL PROTECTED]> wrote:
> The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
> without testing on a Geyser 1,
My fault, sorry. However Anton's device has product ID of 90x30B which
is Geyser 1 as far as I understand... But yes, we shou
So, like, the other day David Gibson mumbled:
> It's potentially useful for users of libfdt to sanity check a device
> tree (or, rather, a blob of data which may or may not be a device
> tree) before processing it in more detail with libfdt.
>
> This patch renames the libfdt internal function _fdt
On Wed, 2007-10-24 at 11:23 +0200, Jens Axboe wrote:
> On Wed, Oct 24 2007, Johannes Berg wrote:
> > On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
> >
> > > I lost track - which kernel are you booting? This looks like something
> > > that should be fixed, did you try 2.6.24-rc1?
> >
> > No
On Wed, 2007-10-24 at 12:44 +0200, Johannes Berg wrote:
> The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
> without testing on a Geyser 1, and I'm a very annoyed that it was
> applied. It causes appletouch to continuously printk:
I spoke too soon, I don't have a Geyser 1 but
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a fountain touchpad. It causes appletouch to
continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device
(Geyser 3 mode)
because the fountain touchpad doesn't respond to
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(5331){t:'S';sz:0}
arg() on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(030d){t:03;sz:0} arg(ff863
Hi,
> My fault, sorry.
No, actually, I was wrong about Geyser 1, mine is a fountain.
> Is there a way to "plug" these Geysers? Waking up the kernel
> continuously is not nice.
Not sure really, maybe checking for is_geyser instead of is_geyser_3?
johannes
signature.asc
Description: This is a
On 10/24/07, Johannes Berg <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > My fault, sorry.
>
> No, actually, I was wrong about Geyser 1, mine is a fountain.
>
> > Is there a way to "plug" these Geysers? Waking up the kernel
> > continuously is not nice.
>
> Not sure really, maybe checking for is_geyser ins
On Wed, 2007-10-24 at 09:34 -0400, Dmitry Torokhov wrote:
> Well, but what about fountains then? Regardless of the model, if there
> is a way to stop "empty" meaurements, we should do it.
There is no way on fountains though. We could check the measurement
ourselves and if no finger is detected de
So, like, the other day David Gibson mumbled:
> This patch adds some internal documentation in libfdt.h, in the form
> of comments on the error codes and some functions. Only a couple of
> functions are covered so far, leaving the documentation still woefully
> inadequate, but hey, it's a start.
>
Dale Farnsworth wrote:
> On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
>> Dale Farnsworth wrote:
>>> Valentine wrote:
Actually I also don't see much reason for the
USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
Is this really needed?
>>> I think so. The S
On 10/23/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
> This patch adds support for 'generic-mpc5200' compatible
> boards which do not need a platform specific setup.
>
> Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
I like this patch and I think it will make it easier to support
multip
On 10/23/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 01:13:33AM +0200, Marian Balakowicz wrote:
> > Add device tree source file for TQM5200 board.
> >
> > Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
> > ---
> >
> > arch/powerpc/boot/dts/tqm5200.dts | 236
> > ++
Jon Smirl wrote:
> Is this consensus on how the tree should look?
>
> There is no attempt to describe the codec connections inside the
> device tree.
I don't think I agree with that. The device tree should indicate which codec
is
connected to which I2S/AC97 device.
I see that you do that for
On 10/23/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
> Add LED driver for Promess Motion-PRO board.
>
> Signed-off-by: Jan Wrobel <[EMAIL PROTECTED]>
> Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
> ---
>
> drivers/leds/Kconfig |7 +
> drivers/leds/Makefile |3
On Wed, Oct 24, 2007 at 05:44:51PM +0400, Valentine Barshak wrote:
> Dale Farnsworth wrote:
> >On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
> >>Dale Farnsworth wrote:
> >>>Valentine wrote:
> Actually I also don't see much reason for the
> USB_OHCI_HCD_PPC_OF_BE/USB_OH
Dale Farnsworth wrote:
> On Wed, Oct 24, 2007 at 05:44:51PM +0400, Valentine Barshak wrote:
>> Dale Farnsworth wrote:
>>> On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
Dale Farnsworth wrote:
> Valentine wrote:
>> Actually I also don't see much reason for the
>
On Wednesday 24 October 2007, Johannes Berg wrote:
> Show Details
> I've been getting these warnings (many more of them but this is a list
> of unique ones) on my quad G5 with 32-bit userspace:
>
> ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(5331){t:'S';sz:0}
> arg() on /dev/.tm
On 10/24/07, Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-24 at 09:34 -0400, Dmitry Torokhov wrote:
>
> > Well, but what about fountains then? Regardless of the model, if there
> > is a way to stop "empty" meaurements, we should do it.
>
> There is no way on fountains though. We could
So, like, the other day David Gibson mumbled:
> Although it's a low-level function that shouldn't normally be needed,
> there are circumstances where it's useful for users of libfdt to use
> the _fdt_next_tag() function. Therefore, this patch renames it to
> fdt_next_tag() and publishes it in libf
So, like, the other day David Gibson mumbled:
> This patch adds some internal documentation in libfdt.h, in the form
> of comments on the error codes and some functions. Only a couple of
> functions are covered so far, leaving the documentation still woefully
> inadequate, but hey, it's a start.
>
Jon Smirl wrote:
> What I meant was that there is no attempt to describe how the codec is
> connected to the external world. Those connections are described in
> the fabric driver.
Hmmm, I'm not sure I'm okay with that. We can always add properties to those
nodes if it's necessary. However, no
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > codec0: [EMAIL PROTECTED] {
> > compatible = "ti,tas5508";
> > reg = <0>;
> > i2s-handle = <&[EMAIL PROTECTED]>;
> > };
>
> I'd do this the other way around -- that is:
>
> [EMAIL PROTECTED] {
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> > > Is this consensus on how the tree should look?
> > >
> > > There is no attempt to describe the codec connections inside the
> > > device tree.
> >
> > I don't think I ag
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > codec0: [EMAIL PROTECTED] {
> > > compatible = "ti,tas5508";
> > > reg = <0>;
> > > i2s-handle = <&[EMAIL PROTECTED]>;
> > > };
> >
> > I'd
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > Jon Smirl wrote:
> > > > Is this consensus on how the tree should look?
> > > >
> > > > There is no attempt to describe the codec con
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > Is this consensus on how the tree should look?
> >
> > There is no attempt to describe the codec connections inside the
> > device tree.
>
> I don't think I agree with that. The device tree should indicate which codec
> is
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Two valid methods have been proposed
> > 1. a codec-
>
> oops
>
> 1. a codec-handle property in the i2s node
> 2. an i2s-handle property in the codec node
>
> Either are reasonable. I prefer putting the handle in the i2s node;
> but I'm look
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > What I meant was that there is no attempt to describe how the codec is
> > connected to the external world. Those connections are described in
> > the fabric driver.
>
> Hmmm, I'm not sure I'm okay with that. We can always
Jon Smirl wrote:
> I see your point about putting the child node onto the control bus.
> ac97 is both a control and data bus. For the i2s case the child should
> go onto the i2c bus.
I know AC97 is *also* a control bus, but treating I2S and AC97 differently is
bad, IMHO. If you're going to put
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Two valid methods have been proposed
> > > 1. a codec-
> >
> > oops
> >
> > 1. a codec-handle property in the i2s node
> > 2. an i2s-handle property in the codec node
> >
> > Either are re
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > The DTC experts need to tell us which way to make the pointers between
> > i2s and i2c for the codec. Here's a another way it could be done that
> > looks more like the ac97 model.
>
> I *really* don't think this is a good idea. Put the nod
On Sun, 23 Sep 2007, Geoff Levand wrote:
> Subject: Cell: Wrap master run control bit
>
> From: Masato Noguchi <[EMAIL PROTECTED]>
>
> Add platform specific SPU run control routines to the spufs. The current
> spufs implementation uses the SPU master run control bit (MFC_SR1[S]) to
> control SPE
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > I see your point about putting the child node onto the control bus.
> > ac97 is both a control and data bus. For the i2s case the child should
> > go onto the i2c bus.
>
> I know AC97 is *also* a control bus, but treating I
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Do you want to pick one and add it to the device tree documentation
> > with an example for i2s and ac97? I'll use which ever one is picked.
>
> Sure, I'll draft something up and post it for review.
>
> On the device probing front; what about
Jon Smirl wrote:
> It makes sense to me, there needs to be some way to trigger loading
> the fabric driver.
Well, you only really two have choices:
1) Probe on the AC97/SSI nodes
2) When the driver initializes, just scan all the nodes in the device tree (no
probing).
I think option #2 makes th
On Wed, 17 Oct 2007, Scott Wood wrote:
> Geert Uytterhoeven wrote:
> >> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> >> index 39b27e5..795f988 100755
> >> --- a/arch/powerpc/boot/wrapper
> >> +++ b/arch/powerpc/boot/wrapper
> >> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile
These patches update ohci-ppc-of and the dts files for the new bindings.
The "compatible" is set to "usb-ohci" and the "big-endian" quirkiness is
expressed by a property, not by the "compatible" name.
Also user-selectable USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE config
options are removed, si
Rework ohci-ppc-of driver to use big-endian property instead of
ohci-be/ohci-le compatible strings. Also remove unnecessary
user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD
Adjust mpc52xx DTS entries to support reworked ohci-ppc-of driver.
Use compatible "usb-ohci" and an empty big-endian property for
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO support.
This also adds OHCI DTS entry for Sequoia PowerPC 440EPx board.
Signed-off-by: Valentine Barshak <[EMAIL
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Do you want to pick one and add it to the device tree documentation
> > > with an example for i2s and ac97? I'll use which ever one is picked.
> >
> > Sure, I'll draft something up and pos
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > It makes sense to me, there needs to be some way to trigger loading
> > the fabric driver.
>
> Well, you only really two have choices:
>
> 1) Probe on the AC97/SSI nodes
> 2) When the driver initializes, just scan all the n
Grant Likely wrote:
> Now is probably a good time to mention that there is *nothing* in the
> device tree that enforces a 1:1 relationship between device tree nodes
> and driver instances. Sure, it make sense to register the i2s and
> codec drivers from probing on the i2s and codec nodes. Howeve
Grant Likely wrote:
> If you need to scan the tree, don't do it when the driver registers,
> do it in the platform code instead. Otherwise you unconditionally
> incur the penalty of scanning the whole device tree on every system
> that loads the driver, regardless of whether or not the device is
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > If you need to scan the tree, don't do it when the driver registers,
> > do it in the platform code instead. Otherwise you unconditionally
> > incur the penalty of scanning the whole device tree on every system
> > that
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > Now is probably a good time to mention that there is *nothing* in the
> > device tree that enforces a 1:1 relationship between device tree nodes
> > and driver instances. Sure, it make sense to register the i2s and
> >
The ps3 target produces two images, and the binary one is not the
"primary" image that corresponds to the -o flag; thus, it no longer
uses the generic binary flag.
On platforms which do use the binary flag, it no longer produces a
.bin suffix, so that the output file matches what was passed to the
On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> Heh, I'm one of the folks who objected to it; here's what was written:
>
> > > >
> > > > [EMAIL PROTECTED] { // use to trigger loading platform specific fabric
> > > > driver
> > > > device_type = "pseudo-sound"
> > > > };
> > >
> > > I
Thanks for all of the replies, it's nice to hear that the 440GX isn't
obsolete yet... A relatively arbitrary decision, but I'm going to send
the Ocotea board to Josh.
jeff
Jeff Mock wrote:
> Is the Ocotea board (the original 440GX eval board) still interesting?
> I'm wrapping up a project u
On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Heh, I'm one of the folks who objected to it; here's what was written:
> >
> > > > >
> > > > > [EMAIL PROTECTED] { // use to trigger loading platform specific
> > > > > fabric driver
> > >
Jon Smirl wrote:
> Calling it directly from the platform code is an option, but where
> does the fabric driver code live? It doesn't make a lot of sense to
> put ALSA code into arch/powerpc/platforms/52xx. I could make a
> function call from arch/powerpc/platforms/52xx over to
> sound/soc/powerpc
From: Grant Likely <[EMAIL PROTECTED]>
Device drivers should not access the CDM registers directly to modify
the clocking. Instead, provide a helper function for setting the MCLK
value so that the registers can be properly protected from concurent
access.
---
arch/powerpc/platforms/52xx/efika.c
From: Grant Likely <[EMAIL PROTECTED]>
port_config and the cdm are the responsibility of firmware; and if
firmware doesn't set it up correctly, it should be fixed up by
platform code on a per-board basis because it's a property of the
board.
Drivers should never touch these registers.
Signed-off
Domen,
Here's a real solution to the problem. I've somewhat tested this on
the lite5200b. Can you give it a spin on efika and see if SPI still
works for you?
Thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev maili
On 24/10/07 12:24 -0600, Grant Likely wrote:
> Domen,
>
> Here's a real solution to the problem. I've somewhat tested this on
> the lite5200b. Can you give it a spin on efika and see if SPI still
> works for you?
My test case was lite5200b too, I don't think I ever tried SPI on
efika.
(Are even
Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-23 at 20:57 -0500, Valentine Barshak wrote:
>
>> +static int m88e_init(struct mii_phy *phy)
>> +{
>> +printk("%s: Marvell 88E Ethernet\n", __FUNCTION__);
>> +phy_write(phy, 0x14, 0x0ce3);
>> +phy_write(phy, 0x18, 0x4101);
>> +
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Calling it directly from the platform code is an option, but where
> > does the fabric driver code live? It doesn't make a lot of sense to
> > put ALSA code into arch/powerpc/platforms/52xx. I could make a
> > function call
Jon Smirl wrote:
> Why are you using a vendor named directory? I don't believe vendor
> named directories are used anywhere in the kernel. The directories are
> always named after the platform or architecture. Vendor directories
> end up in a big mess if Freescale decides to sell a CPU to someone
The AMCC 440GX processor is by no means obsolete. There are more
customers for this processor every month. There is a new, comprehensive
evaluation kit called "Taishan"
(http://www.amcc.com/Embedded/evalkits/440GX_PB_1_04.pdf), which AMCC
provides to customers and partners. "Ocotea" is a board that
On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Why are you using a vendor named directory? I don't believe vendor
> > named directories are used anywhere in the kernel. The directories are
> > always named after the platform or architecture. Vendor directories
> > end u
On Wed, Oct 17, 2007 at 04:07:48PM +1000, Tony Breeds wrote:
> On Tue, Oct 16, 2007 at 03:25:25PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > Not sure when this started happening, but I wanted to report it. I'll
> > start bisecting in a day or two if noone else has gotten around to
> > looking at
On 10/24/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> On 24/10/07 12:24 -0600, Grant Likely wrote:
> > Domen,
> >
> > Here's a real solution to the problem. I've somewhat tested this on
> > the lite5200b. Can you give it a spin on efika and see if SPI still
> > works for you?
>
> My test case wa
Hello.
Olof Johansson wrote:
> Not sure when this started happening, but I wanted to report it. I'll
> start bisecting in a day or two if noone else has gotten around to
> looking at it:
> $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> $ time ./a.out & sleep 2 ; killall a.out
> re
On 24/10/07 14:14 -0600, Grant Likely wrote:
> On 10/24/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> > On 24/10/07 12:24 -0600, Grant Likely wrote:
> > > Domen,
> > >
> > > Here's a real solution to the problem. I've somewhat tested this on
> > > the lite5200b. Can you give it a spin on efika an
While browsing the i2c-mpc.c driver I noticed some things that look odd
to me so I figured I report them. Could not find a maintainer in the MAINTANERS
file
so I sent here, cc:ed linuxppc-dev as well.
1) There are a lot of return -1 error code that is propagated back to
userspace. Should be ch
On Thu, 2007-10-25 at 00:17 +0400, Sergei Shtylyov wrote:
> Hello.
>
> Olof Johansson wrote:
>
> > Not sure when this started happening, but I wanted to report it. I'll
> > start bisecting in a day or two if noone else has gotten around to
> > looking at it:
>
> > $ echo "int main(void) { while
Valentine Barshak wrote:
> Rework ohci-ppc-of driver to use big-endian property instead of
> ohci-be/ohci-le compatible strings. Also remove unnecessary
> user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
> USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
> and USB_OHCI_LITTLE_
On 10/24/07, Tjernlund <[EMAIL PROTECTED]> wrote:
> While browsing the i2c-mpc.c driver I noticed some things that look odd
> to me so I figured I report them. Could not find a maintainer in the
> MAINTANERS file
> so I sent here, cc:ed linuxppc-dev as well.
There appear to be more issues with th
Well, I suppose that it was really just a little poke to see if anyone
from AMCC reads the mailing list :) No offense intended.
The 440GX worked out great for my project, a new spectrometer for the
radio telescope in Arecibo. There are 14 of these boxes running in
parallel at the telescope.
On Wed, 24 Oct 2007 16:54:57 +1000
Michael Neuling <[EMAIL PROTECTED]> wrote:
> +/* Estimate the scaled cputime by scaling the real cputime based on
> + * the last scaled to real ratio */
> +static inline cputime_t cputime_to_scaled(const cputime_t ct)
> +{
> + if (cpu_has_feature(CPU_FTR_SPUR
On Wed, Oct 24, 2007 at 09:28:42AM -0600, Grant Likely wrote:
> On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
[snip]
> > My vote is for this version. In fact, I think it *has* to be this way. If
> > you're using a CS4270 codec (as I am), the I2C interface is *optional*.
On Wed, Oct 24, 2007 at 11:54:23AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Do you want to pick one and add it to the device tree documentation
> > > with an example for i2s and ac97? I'll use which ever one is picked.
> >
> > Sure, I'll draft something u
On Wed, Oct 24, 2007 at 10:38:11AM -0600, Grant Likely wrote:
> On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
[snip]
> > > For example:
> > > [EMAIL PROTECTED] {
> > > compatible = ",,sound" // The board might have
> > > more than
On Wed, Oct 24, 2007 at 11:19:33AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 10/24/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > codec0: [EMAIL PROTECTED] {
> > > > compatible = "ti,tas5508";
> > > > reg = <0>;
> > > >
Sergei Shtylyov writes:
> I've just realized that I've missed the call to account_process_time() in
> the new timer_interrupt(). :-<
Which is bogus. I had removed it in the version of the patch that I
posted in early September, but apparently it crept back in.
> Anyway, this leads to e
On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> I'm afraid I still don't understand quite what information this
> "fabric" driver is conveying. Is it really inherently platform
> specific, or is it something that can be encoded directly in a
> sensible way. If the latter we could have a ge
Benjamin Herrenschmidt writes:
> Your input would be much more valuable if you actually pointed out where
> that happens and why since you seem to know it.
He did already, a couple of messages ago.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozla
On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
> On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> > I'm afraid I still don't understand quite what information this
> > "fabric" driver is conveying. Is it really inherently platform
> > specific, or is it something that can be enco
On Wed, 24 Oct 2007 12:24:26 -0600 Grant Likely <[EMAIL PROTECTED]> wrote:
>
> +static spinlock_t mpc52xx_cdm_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_SPINLOCK(mpc52xx_cdm_lock);
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpgXWtYRBJgy.pg
On Thu, 2007-10-25 at 10:19 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > Your input would be much more valuable if you actually pointed out where
> > that happens and why since you seem to know it.
>
> He did already, a couple of messages ago.
Allright, I missed that.
Be
Add documentation for another handful of libfdt functions to libfdt.h
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2007-10-25 10:52:31.0 +1000
+++ dtc/libfdt/l
On Wed, 2007-10-24 at 14:24 +1000, Michael Ellerman wrote:
> The loop to check parent nodes for a dma-window property in
> pci_dma_dev_setup_pSeriesLP() does not use the of_* accessors and
> does not properly manage refcounts, fix it to do so.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]
On Wednesday 24 October 2007, Matt Sealey wrote:
> Can we just make sure real quickly that the changing of compatibles
> doesn't break existing, not-easily-flashable firmwares?
Yeah, I'm not keen on such breakage either...
___
Linuxppc-dev mailing list
L
On 10/24/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 24 October 2007, Matt Sealey wrote:
> > Can we just make sure real quickly that the changing of compatibles
> > doesn't break existing, not-easily-flashable firmwares?
>
> Yeah, I'm not keen on such breakage either...
Add my voi
1 - 100 of 105 matches
Mail list logo
