linux-mips
[Top] [All Lists]

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

To: Manuel Lauss <mlau@msc-ge.com>
Subject: Re: [PATCH v4 0/10] Alchemy updates.
From: Kevin Hickey <khickey@rmicorp.com>
Date: Wed, 30 Jul 2008 21:36:59 +0000
Cc: Manuel Lauss <mano@roarinelk.homelinux.net>, linux-mips@linux-mips.org
In-reply-to: <48904264.8040600@msc-ge.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20080729165853.GB8784@roarinelk.homelinux.net> <1217367234.13597.11.camel@kh-ubuntu.razamicroelectronics.com> <48904264.8040600@msc-ge.com>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 2008-07-30 at 12:28 +0200, Manuel Lauss wrote:
> 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.
> 
I agree - what I should have said is that the current method is good for
this patch set.  It should be enhanced but that should not block the
acceptance of these patches.
> 
> > 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
> > wrong.
> 
> 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).
> 
Sounds good.  Looking forward to it.

> IDE I can't use so didn't test.
We have it on our board so I'll take care of it.  I have a partial
solution working already.

> 
> 
> > 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
> 
-- 
Kevin Hickey
Alchemy Solutions
RMI Corporation
khickey@RMICorp.com
P: 512.691.8044

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