* Re: [PATCH 03/11] [POWERPC] Add common mpc52xx_setup_pci() routine
From: Stephen Rothwell @ 2007-10-24 7:16 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071023231321.29359.96506.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Wed, 24 Oct 2007 01:13:21 +0200 Marian Balakowicz <m8@semihalf.com> 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) {
> - mpc52xx_add_bridge(np);
> - of_node_put(np);
> - }
> + mpc52xx_setup_pci();
> #endif
Normally we would have no "#ifdef CONFIG_PCI" here but instead define a
static inline void mpc52xx_setup_pci(void) { }
in the header file for the non PCI case.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* PPC4xx 2x eth phy
From: - Reyneke @ 2007-10-24 7:26 UTC (permalink / raw)
To: linuxppc-embedded
Some quick feedback to the list. A few weeks ago I talked about the problem=
of the second ethernet connection not working when the first ethernet conn=
ection does not have a link.
Basically the problem is PHYs that don't generate a RX clock when no link i=
s present (i.e. ET1011. It turns out that in case of the 440Epx, there is s=
ome interdependency within the EMAC which means that when EMAC1 initialises=
, there MUST be a RX clock on EMAC0. If that is not the case, EMAC1 will NO=
T send/receive even though initialisation and auto-negotiation is successfu=
l.
There is some linux code for handling missing RX clocks, but this code does=
not extend to the scenario where one EMAC is dependent on another EMAC's P=
HY having a receive clock.
Regards
Jan Reyneke
> HI,
>
> We've run into a bit of an odd problem and we are not sure where to go an=
d
> look for the cause.
>
> We have some 440EPx based hardware with two GIG-Ethernet ports using RGMI=
I
> and 2x ET1011C PHY's. Problem is that eth1 will only initialise correctly
> (i.e. receive and transmit) if eth0 has a link. Eth0 always work OK,
> regardless of eth1 status. Eth1 will work OK if eth0 has a link (i.e.
> initialised) at time of setup. Once initialised, eth0 status is
> irrelevant.
> All this is during Linux boot process.
>
> Any ideas?
>
> We can access PHY registers via u-boot (mii commands). Same 1Gig link
> speed
> is used on both ports. Linux kernel is 2.6.19.
_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk=
^ permalink raw reply
* CPM microcode uploading and CPM reset on MPC8560
From: Vladislav Nyaykalo @ 2007-10-24 8:05 UTC (permalink / raw)
To: linuxppc-embedded
Hello to everyone,
I need to insert a function that uploads CPM microcode and resets CPM
somewhere during kernel initialization before UART is initialized. Could you
please suggest me the best suitable place.
Target platform: MPC8560
Kernel: 2.6.10
Regards,
Vlad
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
^ permalink raw reply
* [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-23 21:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev list, Paul Mackerras, Jens Axboe
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-off-by: Johannes Berg <johannes@sipsolutions.net>
---
If it was fixed before please ignore, I just ran into this.
--- linux-2.6.orig/include/asm/dma-mapping.h 2007-10-23 22:55:33.551133142 +0200
+++ linux-2.6/include/asm/dma-mapping.h 2007-10-23 22:56:07.081133142 +0200
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct sc
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
+ sg->dma_address = page_to_bus(sg_page(sg)) + sg->offset;
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(s
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_devic
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-23 21:47 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev list, Paul Mackerras, Jens Axboe
In-Reply-To: <1193173222.7733.42.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
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
> 18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
> sg_page(sg) instead of sg->page.
This doesn't help though, when I boot I get a NULL-pointer dereference
that looks approximately like this:
NIP blk_rq_map_sg + 0x64/0x190
LR ide_map_sg + 0x38/?
Call trace:
cfq_remove_request + 0x168 (unreliable)
cfq_dispatch_request + 0x44
ide_build_sglist + 0x38?
pmac_ide_dma_setup + 0xa0?
ide_do_rw_disk? + ?
[...]
I can upload the picture I took but it's hardly readable (taken with my
crappy cell phone)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Jens Axboe @ 2007-10-24 9:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193176034.4097.3.camel@johannes.berg>
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 since commit
> > 18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
> > sg_page(sg) instead of sg->page.
>
> This doesn't help though, when I boot I get a NULL-pointer dereference
> that looks approximately like this:
>
> NIP blk_rq_map_sg + 0x64/0x190
> LR ide_map_sg + 0x38/?
> Call trace:
> cfq_remove_request + 0x168 (unreliable)
> cfq_dispatch_request + 0x44
> ide_build_sglist + 0x38?
> pmac_ide_dma_setup + 0xa0?
> ide_do_rw_disk? + ?
> [...]
>
> I can upload the picture I took but it's hardly readable (taken with my
> crappy cell phone)
I lost track - which kernel are you booting? This looks like something
that should be fixed, did you try 2.6.24-rc1?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:22 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071024091446.GL14671@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
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 works before tomorrow.
I see the build failure got fixed with commit
5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:23 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217742.5715.6.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
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.
Wait, now I lost track. This patch is identical to that commit 5edad...,
what I was thinking of was the oops I got.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:24 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217816.5715.8.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
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 fixed with commit
> > 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
>
> Wait, now I lost track. This patch is identical to that commit 5edad...,
> what I was thinking of was the oops I got.
Nah, never mind. Apologies to everybody. I'm confused, Jens says the
oops was fixed. I'll verify that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Jens Axboe @ 2007-10-24 9:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217742.5715.6.camel@johannes.berg>
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
> 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.
0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it
will break on IDE. I'm confident that a newer kernel will solve this
issue.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] taskstats scaled time cleanup
From: Balbir Singh @ 2007-10-24 9:52 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-s390, linux-kernel, linuxppc-dev, paulus, linux390, akpm
In-Reply-To: <8789.1193208897@neuling.org>
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
> version does the scaling based on the last SPURR/PURR ratio
> calculated. The generic and s390 (only other arch to implement
> asm/cputime.h) versions are both NOPs.
>
> Also moves the SPURR and PURR snapshots closer.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Looks good to me
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* [PATCH] ehea: fix port_napi_disable/enable
From: Jan-Bernd Themann @ 2007-10-24 9:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
napi_disable / napi_enable must be applied on all ehea queues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
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/drivers/net/ehea/ehea.h
index b557bb4..4b4b74e 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0078"
+#define DRV_VERSION "EHEA_0079"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index fe5ffac..a8b05d2 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2329,7 +2329,7 @@ static void port_napi_disable(struct ehea_port *port)
{
int i;
- for (i = 0; i < port->num_def_qps; i++)
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
napi_disable(&port->port_res[i].napi);
}
@@ -2337,7 +2337,7 @@ static void port_napi_enable(struct ehea_port *port)
{
int i;
- for (i = 0; i < port->num_def_qps; i++)
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
napi_enable(&port->port_res[i].napi);
}
@@ -2373,8 +2373,6 @@ static int ehea_down(struct net_device *dev)
ehea_drop_multicast_list(dev);
ehea_free_interrupts(dev);
- port_napi_disable(port);
-
port->state = EHEA_PORT_DOWN;
ret = ehea_clean_all_portres(port);
@@ -2396,6 +2394,7 @@ static int ehea_stop(struct net_device *dev)
flush_scheduled_work();
down(&port->port_lock);
netif_stop_queue(dev);
+ port_napi_disable(port);
ret = ehea_down(dev);
up(&port->port_lock);
return ret;
--
1.5.2
^ permalink raw reply related
* [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 10:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
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 Geyser 1 doesn't respond to that. The patch description also
states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24 12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820 +0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-24 11:19 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071023214000.424.qmail@farnsworth.org>
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
> method of handling both types?
>
> -Dale
Yes, PCI controllers are LE, but do we really need user-selectable
USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
I think it's useless. We should always enable
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
and the real LE/BE implementation should be selected by the
corresponding properties in the device tree.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-24 12:07 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <4718B287.20306@ru.mvista.com>
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 hrtimer's event handlers not being able
> to call account_process_time() from arch/powerpc/kernel/time.c instead of
> update_process_timess()?
I've just realized that I've missed the call to account_process_time() in
the new timer_interrupt(). :-<
Anyway, this leads to each tick being accounted twice if the deterministic
accounting is not enabled -- first by timer_interrupt() and then by the
hrtimers core, doesn't it?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Dale Farnsworth @ 2007-10-24 12:08 UTC (permalink / raw)
To: Valentine Barshak; +Cc: Linuxppc-dev
In-Reply-To: <471F2A32.8030202@ru.mvista.com>
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 and the PCI
> >host controllers are LE. Or, do you have an alternative
> >method of handling both types?
>
> Yes, PCI controllers are LE, but do we really need user-selectable
> USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
> by default for USB_OHCI_HCD_PCI?
> The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
> I think it's useless. We should always enable
> USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
> and the real LE/BE implementation should be selected by the
> corresponding properties in the device tree.
I agree that they don't need to be user selectable. It is far preferable
to deduce their values from existing information, if possible.
-Dale
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Dmitry Torokhov @ 2007-10-24 12:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
Hi Johannes,
On 10/24/07, Johannes Berg <johannes@sipsolutions.net> 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 should not expect
other geysers respond to Geyser 3-specific commands.
> 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 Geyser 1 doesn't respond to that. The patch description also
> states:
>
> > if we see 10 empty packets the touchpad needs to be reset; good
> > touchpads should not send empty packets anyway.
>
> which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
> empty packets, the simply continuously send measurements. One look at
> the specification would have confirmed that.
>
Is there a way to "plug" these Geysers? Waking up the kernel
continuously is not nice.
--
Dmitry
^ permalink raw reply
* Re: libfdt: Rename and publish _fdt_check_header()
From: Jon Loeliger @ 2007-10-24 13:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071024002852.GG10595@localhost.localdomain>
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_check_header() to
> fdt_check_header() and makes it a published function, so it can now be
> used for this purpose.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 11:21 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071024092334.GM14671@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
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, 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.
>
> 0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it
> will break on IDE. I'm confident that a newer kernel will solve this
> issue.
It does indeed, 2.6.24-rc1 runs fine. Thanks.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* strataflash size and partitioning problem
From: Amin Farajian @ 2007-10-24 13:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 5317 bytes --]
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 11:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
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 rather a Fountain touchpad
on my powerbook.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH v2] appletouch: fix fountain touchpad breakage
From: Johannes Berg @ 2007-10-24 11:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linuxppc-dev list, Anton Ekblad, Sven Anders, Soeren Sonnenburg
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
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 that. The patch description
also states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since fountain touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit, a better solution for geyser 1
touchpads must be found.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
What I'd advocate for 2.6.25 is to split appletouch into two drivers:
"appletouch" for fountain touchpads and maybe "appletouch2" for geyser
touchpads, this will get rid of many of the huge if statements in the
packet processing path and make sure that the macbook crowd will no
longer have to workaround the powerbook touchpads seeing that we seem to
hardly talk to each other.
Or maybe Soeren Sonnenburg's rewrite could be used for Geyser touchpads.
drivers/input/mouse/appletouch.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24 12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820 +0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
^ permalink raw reply
* ioctl32 unknown cmds with 2.6.24-rc1
From: Johannes Berg @ 2007-10-24 12:30 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
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(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 13:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <d120d5000710240555m545a4f95v8bfc1ac790273001@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Dmitry Torokhov @ 2007-10-24 13:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193231110.4510.42.camel@johannes.berg>
On 10/24/07, Johannes Berg <johannes@sipsolutions.net> 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 instead of is_geyser_3?
>
Well, but what about fountains then? Regardless of the model, if there
is a way to stop "empty" meaurements, we should do it.
--
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox