[Top] [All Lists]

Re: [PATCH v4 0/10] Alchemy updates.

To: Kevin Hickey <>
Subject: Re: [PATCH v4 0/10] Alchemy updates.
From: Manuel Lauss <>
Date: Wed, 30 Jul 2008 12:28:52 +0200
Cc: Manuel Lauss <>,
In-reply-to: <>
Organization: MSC Vertriebsges.m.b.H.
Original-recipient: rfc822;
References: <> <>
User-agent: Thunderbird (X11/20080725)
Hi Kevin,

1.  I like the interface you added in patch #10.  Much better than the
old /proc one and flexible enough for a lot of different boards.  I
agree with your own comment that maybe it should be in the
board-specific directories so that people can name the nodes better, but
for now I think this is great.

Thinking about my board here in particular: I need to save/restore a
few bytes in an FPGA (in the ->enter() callback) and call a few other
pm related callbacks; the gpio nodes are set internally by or'ing together
other wake sources (think carddetects, Wake on lan, GSM modem irq, ...).

So if we want to keep it the way it is now, we should give boards a means
to disable exposure of each of the "standard" wakesources of the Au1000 chip,
to provide their own nodes and suspend_ops_t callbacks.

2.  If I use the db1200_defconfig and enable Power Management
(CONFIG_PM), the build fails on the Au1xxx IDE and fb drivers.  Are you
seeing this too?  I see no reason to reject this patch if they don't
build with CONFIG_PM, I just want to make sure I'm not doing something

The au1200fb failure, yes. I also have a patch to fix it, but it needs
a bit more love: X for example does not always survive the framebuffer
suspend/resume cycle (it complains about changed parameters after resume).

IDE I can't use so didn't test.

3.  In my preliminary testing, the system was able to suspend and resume
correctly on a DB1200 board.  I will do some stress testing in the next
couple of days to make sure that it is stable in the long term.

Very much appreciated!

Thanks Kevin,
        Manuel Lauss

<Prev in Thread] Current Thread [Next in Thread>