From: Jarkko Nikula <hidden> Date: 2011-02-20 20:04:08
There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
set. This can be triggered on OMAP2 builds where OMAP3 or OMAP4 are not set.
drivers/built-in.o: In function `sdp2430_panel_disable':
drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
drivers/video/omap/lcd_2430sdp.c:124: undefined reference to `twl_i2c_write_u8'
drivers/built-in.o: In function `sdp2430_panel_enable':
drivers/video/omap/lcd_2430sdp.c:110: undefined reference to `twl_i2c_write_u8'
drivers/video/omap/lcd_2430sdp.c:112: undefined reference to `twl_i2c_write_u8'
Fix this by adding TWL4030_CORE dependency to CONFIG_MACH_OMAP_2430SDP as
there is no own entry in drivers/video/omap/Kconfig.
Signed-off-by: Jarkko Nikula <redacted>
Cc: Tomi Valkeinen <redacted>
---
Resend = forgot to cc LAKML.
Quite old issue most probably. Can be triggered in mainline anyway.
---
arch/arm/mach-omap2/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Hi,
* Jarkko Nikula [off-list ref] [110220 12:13]:
quoted hunk
There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
set. This can be triggered on OMAP2 builds where OMAP3 or OMAP4 are not set.
drivers/built-in.o: In function `sdp2430_panel_disable':
drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
drivers/video/omap/lcd_2430sdp.c:124: undefined reference to `twl_i2c_write_u8'
drivers/built-in.o: In function `sdp2430_panel_enable':
drivers/video/omap/lcd_2430sdp.c:110: undefined reference to `twl_i2c_write_u8'
drivers/video/omap/lcd_2430sdp.c:112: undefined reference to `twl_i2c_write_u8'
Fix this by adding TWL4030_CORE dependency to CONFIG_MACH_OMAP_2430SDP as
there is no own entry in drivers/video/omap/Kconfig.
Signed-off-by: Jarkko Nikula <redacted>
Cc: Tomi Valkeinen <redacted>
---
Resend = forgot to cc LAKML.
Quite old issue most probably. Can be triggered in mainline anyway.
---
arch/arm/mach-omap2/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
We should avoid selecting driver related things, otherwise we can never
build a tiny kernel with initramfs with everything as modules.
Can you see if adding depends to the LCD panel option does the trick
instead?
Thanks,
Tony
From: Jarkko Nikula <hidden> Date: 2011-02-28 14:47:15
On Thu, 24 Feb 2011 13:26:44 -0800
Tony Lindgren [off-list ref] wrote:
We should avoid selecting driver related things, otherwise we can never
build a tiny kernel with initramfs with everything as modules.
Can you see if adding depends to the LCD panel option does the trick
instead?
True and as lcd_2430sdp.c is not compiled without CONFIG_FB_OMAP a hack
below should work a bit better.
What would you think Tomi?
From: Tomi Valkeinen <hidden> Date: 2011-02-28 15:09:17
On Mon, 2011-02-28 at 08:47 -0600, Jarkko Nikula wrote:
quoted hunk
On Thu, 24 Feb 2011 13:26:44 -0800
Tony Lindgren [off-list ref] wrote:
quoted
We should avoid selecting driver related things, otherwise we can never
build a tiny kernel with initramfs with everything as modules.
Can you see if adding depends to the LCD panel option does the trick
instead?
True and as lcd_2430sdp.c is not compiled without CONFIG_FB_OMAP a hack
below should work a bit better.
What would you think Tomi?
Well, it's a bit ugly, but I'm fine with it. It's for the old omapfb,
which hopefully nobody uses anymore (right =), and there's no simple way
to make it modular and neat.
The old omapfb compiles lcd_2430sdp always into the kernel if
MACH_OMAP_2430SDP is defined, so this looks like a correct fix to me.
Heh, interestingly, the old omapfb Makefile says: "Makefile for the new
OMAP framebuffer device driver". Things are relative =).
Tomi
Well, it's a bit ugly, but I'm fine with it. It's for the old omapfb,
which hopefully nobody uses anymore (right =), and there's no simple way
to make it modular and neat.
How about let's make mach-omap2 boards all use the new code?
That way the old code can be omap1 only.
Regards,
Tony
From: Tomi Valkeinen <hidden> Date: 2011-03-01 06:29:22
On Mon, 2011-02-28 at 19:39 -0600, Tony Lindgren wrote:
* Tomi Valkeinen [off-list ref] [110228 07:07]:
quoted
Well, it's a bit ugly, but I'm fine with it. It's for the old omapfb,
which hopefully nobody uses anymore (right =), and there's no simple way
to make it modular and neat.
How about let's make mach-omap2 boards all use the new code?
That way the old code can be omap1 only.
That has been my long term plan, but I've never had time to start
working on it. Some (many?) of the old panel drivers are trivial to
port, needs just copying the panel timings.
Some are much more complex, and porting them without having the hardware
may be a bit of a guesswork. But perhaps we can find testers for those
after the code has been ported.
Tomi
On Mon, 2011-02-28 at 19:39 -0600, Tony Lindgren wrote:
quoted
* Tomi Valkeinen [off-list ref] [110228 07:07]:
quoted
Well, it's a bit ugly, but I'm fine with it. It's for the old omapfb,
which hopefully nobody uses anymore (right =), and there's no simple way
to make it modular and neat.
How about let's make mach-omap2 boards all use the new code?
That way the old code can be omap1 only.
That has been my long term plan, but I've never had time to start
working on it. Some (many?) of the old panel drivers are trivial to
port, needs just copying the panel timings.
OK, that will probably make things a lot easier in the long run.
Some are much more complex, and porting them without having the hardware
may be a bit of a guesswork. But perhaps we can find testers for those
after the code has been ported.
Sure, once we get one working others should be easy..
Tony