staging/dream: add gpio and pmem support

[greg@kroah.com (Greg KH)]

On Wed, Oct 28, 2009 at 12:25:22AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > What is so wrong with wakelocks? They are just nops in this case.
> > 
> > Are they really?  Then why is the whole large file needed?
> 
> It is probably not, I went to "submit vendor code, then clean it up"
> mode. CONFIG_HAS_WAKELOCK should be disabled, so it basically stubs
> itself out.
> 
> > > 2) you submit it
> > 
> > Wait, it has to BUILD!  This code has never been able to be built.  Only
> > after I disabled it from the CONFIG_ANDROID have I noticed this, which
> > is my fault.  But it needs to get fixed, and taking a bunch of code in
> > addition to the mess we have now, seems like the wrong way to do it.
> 
> It seems to be the only reasonable way. gpio is used from all the
> other stuff, and removing it is not really an option.
> 
> > > Now, I see that wakelocks are show-stopper for merging into kernel
> > > proper, but what is the problem for staging? We merged drivers with
> > > OS_MEMORY_ALLOCATE(); wakelocks are just nops in this case.
> > > 
> > > Could we please clean this driver in-tree? (Wakelocks are already nops
> > > due to #ifdef magic, cleaning them incrementally is easy.)
> > 
> > With this patch, will it build properly?
> 
> Its certainly way closer to building... it builds for me, with
> something like below; platform devices really are initialized from
> board-* files and get passed parameters.

Ick.  This isn't ok, we can't take patches for staging stuff in files
outside of drivers/staging/

So for now, I've deleted the drivers/staging/dream/ directory from my
tree, which will get pushed for 2.6.33.  Please clean the code up and
get it into buildable shape and I will be glad to add the drivers back
into the staging directory at that time.

thanks,

greg k-h