Prev: msm_sdcc.c: remove references to htc_pwrsink
Next: [PATCH] sh: Build fix: define more __movmem* symbols
From: Pavel Machek on 27 Oct 2009 19:30
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.

I should get some sleep now, I'll take closer look tommorow.

Pavel

diff --git a/arch/arm/mach-msm/include/mach/board.h b/arch/arm/mach-msm/include/mach/board.h
index 264d62e..9e68db2 100644
--- a/arch/arm/mach-msm/include/mach/board.h
+++ b/arch/arm/mach-msm/include/mach/board.h
@@ -35,4 +61,50 @@ void __init msm_init_irq(void);
void __init msm_init_gpio(void);
void __init msm_clock_init(void);

+struct msm_camera_io_ext {
+ uint32_t mdcphy;
+ uint32_t mdcsz;
+ uint32_t appphy;
+ uint32_t appsz;
+};
+
+struct msm_camera_device_platform_data {
+ void (*camera_gpio_on) (void);
+ void (*camera_gpio_off)(void);
+ struct msm_camera_io_ext ioext;
+};
+
+#ifdef CONFIG_SENSORS_MT9T013
+struct msm_camera_legacy_device_platform_data {
+ int sensor_reset;
+ int sensor_pwd;
+ int vcm_pwd;
+ void (*config_gpio_on) (void);
+ void (*config_gpio_off)(void);
+};
+#endif
+
+#define MSM_CAMERA_FLASH_NONE 0
+#define MSM_CAMERA_FLASH_LED 1
+
+struct msm_camera_sensor_info {
+ const char *sensor_name;
+ int sensor_reset;
+ int sensor_pwd;
+ int vcm_pwd;
+ int mclk;
+ int flash_type;
+ struct msm_camera_device_platform_data *pdata;
+};
+
+struct snd_endpoint {
+ int id;
+ const char *name;
+};
+
+struct msm_snd_endpoints {
+ struct snd_endpoint *endpoints;
+ unsigned num;
+};
+
#endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap.h b/arch/arm/mach-msm/include/mach/msm_iomap.h
index 2f7b4c8..8b88e4a 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap.h
@@ -116,6 +116,7 @@

#define MSM_AD5_PHYS 0xAC000000
#define MSM_AD5_SIZE (SZ_1M*13)
+#define MSM_AD5_BASE IOMEM(0xE0300000)


#endif


Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 28 Oct 2009 05:10
On Wed 2009-10-28 10:59:36, Paulius Zaleckas wrote:
> On 10/22/2009 12:13 PM, Pavel Machek wrote:
> >
> >This adds generic_gpio and pmem support, both are needed for other
> >dream drivers.
>
> Why you are not using existing gpiolib? That would make your driver a
> lot smaller and cleaner... and possibly with less bugs...

That can be cleaned up later.

> Why not split gpio and pmem into separate patches?

General overload? Can you help?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paulius Zaleckas on 28 Oct 2009 05:20
On 10/22/2009 12:13 PM, Pavel Machek wrote:
>
> This adds generic_gpio and pmem support, both are needed for other
> dream drivers.

Why you are not using existing gpiolib? That would make your driver a
lot smaller and cleaner... and possibly with less bugs...

Why not split gpio and pmem into separate patches?

> Signed-off-by: Pavel Machek<pavel(a)ucw.cz>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 28 Oct 2009 12:00
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 28 Oct 2009 17:30
On Tue 2009-10-27 15:03:08, Brian Swetland wrote:
> On Tue, Oct 27, 2009 at 12:33 PM, Pavel Machek <pavel(a)ucw.cz> wrote:
> >
> > (Plus, of course I'd like some help, but google people seem very
> > silent :-( ).
>
> Hi Pavel,
>
> The Android kernel team is completely buried in issues related to fall
> 09 devices -- we're just not going to have cycles for sorting out

Given how Android is spreading between phones -- like a wildfire --
I'm not surprised. But it is very unfortunate -- exactly because
Android is extremely important mobile platform :-(.

I can still hope that Google opens developer centre in Prague and
starts hiring :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: msm_sdcc.c: remove references to htc_pwrsink
Next: [PATCH] sh: Build fix: define more __movmem* symbols