This patch cleans up the SMT thread handling, removing hard coded
bits here or there and providing a set of helpers to convert between
linux cpu numbers, thread numbers and cores.
This implementation requires the number of threads per core to be a
power of 2 and identical on all cores in the syste
At present, all the example dtbs we use in the testsuite are version
17 and have reservation map, then structure block then strings block
(the natural ordering based on alignment constraints). However, all
libfdt's read-only and in-place write functions should also work on
v16 trees, and on trees
On Wed Oct 24 17:11:29 EST 2007, Stephen Rothwell wrote:
> On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz wrote:
>>
>> +root = of_find_node_by_path("/");
>> +if (root)
>> +model = of_get_property(root, "model", NULL);
>> +of_node_put(ro
The fdt_set_header() macro casts an arbitrary pointer into (struct
fdt_header *) to set fdt header fields. While we need to change the
type, so that we can use this macro on the usual (void *) used to
represent a device tree blob, the current macro also casts away any
const on the input pointer, w
On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> 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 inherent
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
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 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]
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 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
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 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
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 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
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 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>;
> > > >
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: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 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, 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
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 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
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 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
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 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
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 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
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, 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
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
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
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
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 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
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
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
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
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
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
> > >
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, 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
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, 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
> >
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
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
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
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
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
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
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
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
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
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 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
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 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, 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
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, 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
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, 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 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, 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, 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, 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] {
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:
> 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
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.
>
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
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
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
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 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
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 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
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
> > ++
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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, 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: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 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
1 - 100 of 105 matches
Mail list logo
