diff mbox

[1/6] ARM: OMAP2+: Remove board-4430sdp.c

Message ID 20130517191751.468.89202.stgit@localhost (mailing list archive)
State New, archived
Headers show

Commit Message

Tony Lindgren May 17, 2013, 7:17 p.m. UTC
We can now boot with device tree. If you don't want to update u-boot,
you can boot with appended DTB with the following instructions:

1. Make sure you have the appended DTB support in .config

   CONFIG_ARM_APPENDED_DTB=y
   CONFIG_ARM_ATAG_DTB_COMPAT=y
   CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y

2. Build the zImage

   $ ARCH=arm CROSS_COMPILE=... make zImage

3. Build the device tree blobs

   $ ARCH=arm CROSS_COMPILE=... make dtbs

4. Append the dtb to zImage

   $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended

5. Use mkimage to produce the appended device tree uImage

   $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
     -n "Linux" -d /tmp/appended /tmp/uImage

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/Kconfig         |    8 
 arch/arm/mach-omap2/Makefile        |    1 
 arch/arm/mach-omap2/board-4430sdp.c |  765 -----------------------------------
 3 files changed, 774 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-4430sdp.c

Comments

Russell King - ARM Linux May 20, 2013, 9:54 a.m. UTC | #1
On Fri, May 17, 2013 at 12:17:51PM -0700, Tony Lindgren wrote:
> We can now boot with device tree. If you don't want to update u-boot,
> you can boot with appended DTB with the following instructions:
> 
> 1. Make sure you have the appended DTB support in .config
> 
>    CONFIG_ARM_APPENDED_DTB=y
>    CONFIG_ARM_ATAG_DTB_COMPAT=y
>    CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
> 
> 2. Build the zImage
> 
>    $ ARCH=arm CROSS_COMPILE=... make zImage
> 
> 3. Build the device tree blobs
> 
>    $ ARCH=arm CROSS_COMPILE=... make dtbs
> 
> 4. Append the dtb to zImage
> 
>    $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended
> 
> 5. Use mkimage to produce the appended device tree uImage
> 
>    $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
>      -n "Linux" -d /tmp/appended /tmp/uImage
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Okay, I'm removing the 4430SDP from the boot test system once this goes
in, because this will mean rewriting the build system to cope with this
stuff.
Tony Lindgren May 20, 2013, 5:10 p.m. UTC | #2
* Russell King - ARM Linux <linux@arm.linux.org.uk> [130520 03:00]:
> On Fri, May 17, 2013 at 12:17:51PM -0700, Tony Lindgren wrote:
> > We can now boot with device tree. If you don't want to update u-boot,
> > you can boot with appended DTB with the following instructions:
> > 
> > 1. Make sure you have the appended DTB support in .config
> > 
> >    CONFIG_ARM_APPENDED_DTB=y
> >    CONFIG_ARM_ATAG_DTB_COMPAT=y
> >    CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
> > 
> > 2. Build the zImage
> > 
> >    $ ARCH=arm CROSS_COMPILE=... make zImage
> > 
> > 3. Build the device tree blobs
> > 
> >    $ ARCH=arm CROSS_COMPILE=... make dtbs
> > 
> > 4. Append the dtb to zImage
> > 
> >    $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended
> > 
> > 5. Use mkimage to produce the appended device tree uImage
> > 
> >    $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
> >      -n "Linux" -d /tmp/appended /tmp/uImage
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Okay, I'm removing the 4430SDP from the boot test system once this goes
> in, because this will mean rewriting the build system to cope with this
> stuff.

OK, up to you. At least I check the results of your build system
occasionally though.

I know people don't want to have more uImage handling in the kernel,
but maybe we could add handling for board specific uImage targets
for compability?

Maybe something like dtbname.uImage-dtba:

$ make omap4-sdp.uImage-dtba

And then that would take care of steps 3 - 5 automatically?

Of course the alternative is to update u-boot, but that's not always
possible for some legacy boards.

Regards,

Tony
Russell King - ARM Linux July 6, 2013, 1:10 p.m. UTC | #3
On Mon, May 20, 2013 at 10:54:47AM +0100, Russell King - ARM Linux wrote:
> On Fri, May 17, 2013 at 12:17:51PM -0700, Tony Lindgren wrote:
> > We can now boot with device tree. If you don't want to update u-boot,
> > you can boot with appended DTB with the following instructions:
> > 
> > 1. Make sure you have the appended DTB support in .config
> > 
> >    CONFIG_ARM_APPENDED_DTB=y
> >    CONFIG_ARM_ATAG_DTB_COMPAT=y
> >    CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
> > 
> > 2. Build the zImage
> > 
> >    $ ARCH=arm CROSS_COMPILE=... make zImage
> > 
> > 3. Build the device tree blobs
> > 
> >    $ ARCH=arm CROSS_COMPILE=... make dtbs
> > 
> > 4. Append the dtb to zImage
> > 
> >    $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended
> > 
> > 5. Use mkimage to produce the appended device tree uImage
> > 
> >    $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
> >      -n "Linux" -d /tmp/appended /tmp/uImage
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Okay, I'm removing the 4430SDP from the boot test system once this goes
> in, because this will mean rewriting the build system to cope with this
> stuff.

Well, this doesn't work.  I've tried several things, and I think I'm
generating a correct image, but it doesn't boot.

This could be that the current Linus tip plus my stuff plus arm-soc
is broken, but as it boots on the 3430LDP I suspect that isn't the
case.

I've tried with omap4-sdp.dtb and the other omap4-sdp DTB file with no
improvement.  No idea how to even begin to debug this, as there's no
way for the decompressor to produce output, and I've no idea which
OMAP uart to use for debug output (because that information has been
removed from the kernel source.)

And... WTF is the OMAP debug uart selection in its own separate menu
from the main "choice" statement?  This is totally unnecessary complexity
and is just making things more complicated for the hell of it.  Look at
what every other platform does - they put their stuff in the main choice
statement even if they have multiple UARTs.  The hint there is that these
depend on the appropriate support being selected, so in the case of a
kernel only targetting OMAP, as things stand you'll end up with a menu
which lists the OMAP2PLUS, none, icedcc, and semihosting entries followed
by another menu to select which OMAP port you want.  That's utterly
rediculous and broken.  And just think about the two titles for the
menus:

        prompt "Kernel low-level debugging port"
vs
        prompt "Low-level debug console UART"

Oh wait, why don't I get to choose my "debug console UART" on an AT91?
Maybe AT91 should move their debug uart selection into this menu as well,
and maybe the Versatile Express options too, because they're all to do
with selecting the UART to be used.  Please... some sane *thought* would
be *really* good here.

Oh my god, you're not the only ones.  Arnd/Olof, who started this madness
and _why_ haven't you already stepped on it?  Right, I'm fixing this in
this merge window.  Everything is moving under the original choice menu
as it was intended to be.

The attempts are all on the builder website against the (disabled)
omap4430-sdp entry.
Russell King - ARM Linux July 6, 2013, 1:36 p.m. UTC | #4
On Sat, Jul 06, 2013 at 02:10:57PM +0100, Russell King - ARM Linux wrote:
> Well, this doesn't work.  I've tried several things, and I think I'm
> generating a correct image, but it doesn't boot.
> 
> This could be that the current Linus tip plus my stuff plus arm-soc
> is broken, but as it boots on the 3430LDP I suspect that isn't the
> case.
> 
> I've tried with omap4-sdp.dtb and the other omap4-sdp DTB file with no
> improvement.  No idea how to even begin to debug this, as there's no
> way for the decompressor to produce output, and I've no idea which
> OMAP uart to use for debug output (because that information has been
> removed from the kernel source.)
> 
> And... WTF is the OMAP debug uart selection in its own separate menu
> from the main "choice" statement?  This is totally unnecessary complexity
> and is just making things more complicated for the hell of it.  Look at
> what every other platform does - they put their stuff in the main choice
> statement even if they have multiple UARTs.  The hint there is that these
> depend on the appropriate support being selected, so in the case of a
> kernel only targetting OMAP, as things stand you'll end up with a menu
> which lists the OMAP2PLUS, none, icedcc, and semihosting entries followed
> by another menu to select which OMAP port you want.  That's utterly
> rediculous and broken.  And just think about the two titles for the
> menus:
> 
>         prompt "Kernel low-level debugging port"
> vs
>         prompt "Low-level debug console UART"
> 
> Oh wait, why don't I get to choose my "debug console UART" on an AT91?
> Maybe AT91 should move their debug uart selection into this menu as well,
> and maybe the Versatile Express options too, because they're all to do
> with selecting the UART to be used.  Please... some sane *thought* would
> be *really* good here.
> 
> Oh my god, you're not the only ones.  Arnd/Olof, who started this madness
> and _why_ haven't you already stepped on it?  Right, I'm fixing this in
> this merge window.  Everything is moving under the original choice menu
> as it was intended to be.
> 
> The attempts are all on the builder website against the (disabled)
> omap4430-sdp entry.

Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to
use internal codenames for boards when they're known as "SDP" etc -
especially when they have stickers on them saying that they're "SDP".)

With that worked out, throwing my standard printascii() hack into the
kernel results in boot messages... up to the point where the timer is
calibrated.  So, it looks like either interrupts, clocks, or the OMAP
timers are non-functional with DT based kernels on the SDP board.

Any ideas?
Arnd Bergmann July 6, 2013, 9:36 p.m. UTC | #5
On Saturday 06 July 2013, Russell King - ARM Linux wrote:
> Oh wait, why don't I get to choose my "debug console UART" on an AT91?
> Maybe AT91 should move their debug uart selection into this menu as well,
> and maybe the Versatile Express options too, because they're all to do
> with selecting the UART to be used.  Please... some sane thought would
> be really good here.
> 
> Oh my god, you're not the only ones.  Arnd/Olof, who started this madness
> and why haven't you already stepped on it?  Right, I'm fixing this in
> this merge window.  Everything is moving under the original choice menu
> as it was intended to be.

Sorry, I missed that this was going on, and I absolutely agree with your
sentiment. From what I can tell from the git log, Tegra was the first
to have the separate choice statement, after it just move its
options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed
with the same method and I think from there people just copied it.

I can understand why one wants to have some more structure in the list,
given that i.MX alone has 37 options for UART addresses, but we first
need to have a consistent method of configuring the addresses.

	Arnd
Russell King - ARM Linux July 6, 2013, 11:37 p.m. UTC | #6
Apologies for the topic hijack.

On Sat, Jul 06, 2013 at 11:36:48PM +0200, Arnd Bergmann wrote:
> Sorry, I missed that this was going on, and I absolutely agree with your
> sentiment. From what I can tell from the git log, Tegra was the first
> to have the separate choice statement, after it just move its
> options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed
> with the same method and I think from there people just copied it.
> 
> I can understand why one wants to have some more structure in the list,
> given that i.MX alone has 37 options for UART addresses, but we first
> need to have a consistent method of configuring the addresses.

I don't have an option with an option after the choice or a set of
options afterwards asking for details about the selected option -
that is logical.

For example, if we were to reduce the 8250-uart based stuff down to
a single "8250-compatible uart" option, and then ask for the address,
register shift and register access size.

... and of course by this time I now have a patch set which does
exactly that... and it can do more by getting rid of that 8250_32.S
file as well with another config option.  The patch below tries
hard not to break anything or lose information as to the details of
the 8250 UART in any platform which they're already known to the
kernel, but they can be trivially overridden.  Eventually (maybe
tomorrow), I expect a load of the choice config statements in
arch/arm/Kconfig.debug to go away, replaced just with a generic
"Kernel low-level debugging messages via 8250 UART" option.

 arch/arm/Kconfig.debug                             |   92 ++++++++++++++++++--
 arch/arm/include/asm/hardware/debug-8250.S         |   29 ------
 arch/arm/include/debug/8250.S                      |   36 ++++++++
 arch/arm/include/debug/mvebu.S                     |   30 -------
 arch/arm/include/debug/nspire.S                    |    9 +--
 arch/arm/include/debug/pxa.S                       |   33 -------
 arch/arm/include/debug/rockchip.S                  |   42 ---------
 arch/arm/include/debug/sunxi.S                     |   27 ------
 arch/arm/mach-dove/include/mach/debug-macro.S      |   19 ----
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -----
 .../arm/mach-footbridge/include/mach/debug-macro.S |   15 ---
 arch/arm/mach-gemini/include/mach/debug-macro.S    |   21 -----
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -----
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |   21 -----
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |   22 -----
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   26 ------
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 ----
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 ------
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 ----
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -----
 arch/arm/mach-rpc/include/mach/debug-macro.S       |   23 -----
 21 files changed, 121 insertions(+), 458 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S
Tony Lindgren July 8, 2013, 9:34 a.m. UTC | #7
* Russell King - ARM Linux <linux@arm.linux.org.uk> [130706 06:42]:
> 
> Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to
> use internal codenames for boards when they're known as "SDP" etc -
> especially when they have stickers on them saying that they're "SDP".)

Agreed, let's update that.
 
> With that worked out, throwing my standard printascii() hack into the
> kernel results in boot messages... up to the point where the timer is
> calibrated.  So, it looks like either interrupts, clocks, or the OMAP
> timers are non-functional with DT based kernels on the SDP board.

Hey the good news is that you've updated your build system to support
also appended dtb images, thanks for doing that!
 
> Any ideas?

Looks like you need some things updated and added to your .config.

-# CONFIG_OMAP_MUX is not set
+CONFIG_MACH_OMAP_GENERIC=y

That we should nowadays always select though.

CONFIG_REGULATOR_FIXED_VOLTAGE=y

This you will need for Ethernet.

CONFIG_PINCTRL_SINGLE=y

This is good to have, will be needed especially for for UART
wake-up events with deeper idle modes enabled once the pending
pinctrl patches are merged.

Also, can you please add these for NFSroot:

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_ROOT_NFS=y

That way I can also boot test your .config on regular basis ;)

Then there's a pending patch to change drivers/i2c/busses/i2c-omap.c
to use just a regular module_init, that should remove the i2c timeout
errors as then deferred probe will work properly.

BTW, maybe add a link to your build system to www.arm.linux.org.uk
developer page too? At least I could not find a link to it.

Regards,

Tony
Russell King - ARM Linux July 8, 2013, 2:21 p.m. UTC | #8
On Mon, Jul 08, 2013 at 02:34:11AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [130706 06:42]:
> > 
> > Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to
> > use internal codenames for boards when they're known as "SDP" etc -
> > especially when they have stickers on them saying that they're "SDP".)
> 
> Agreed, let's update that.
>  
> > With that worked out, throwing my standard printascii() hack into the
> > kernel results in boot messages... up to the point where the timer is
> > calibrated.  So, it looks like either interrupts, clocks, or the OMAP
> > timers are non-functional with DT based kernels on the SDP board.
> 
> Hey the good news is that you've updated your build system to support
> also appended dtb images, thanks for doing that!

It was far from trivial - there's many places in the build process
which do things quite differently depending on whether it's a DTB
build or not.

> > Any ideas?
> 
> Looks like you need some things updated and added to your .config.
> 
> -# CONFIG_OMAP_MUX is not set
> +CONFIG_MACH_OMAP_GENERIC=y
> 
> That we should nowadays always select though.
> 
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> 
> This you will need for Ethernet.
> 
> CONFIG_PINCTRL_SINGLE=y
> 
> This is good to have, will be needed especially for for UART
> wake-up events with deeper idle modes enabled once the pending
> pinctrl patches are merged.

That probably explains why there was no output.

> Then there's a pending patch to change drivers/i2c/busses/i2c-omap.c
> to use just a regular module_init, that should remove the i2c timeout
> errors as then deferred probe will work properly.

It seems that - yet again - the mmc devices have swapped themselves.
Also looks like the nonfunctional video stuff is even more nonfunctional
than usual:

omapdss DSI error: can't get VDDS_DSI regulator
omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

ASoC looks dead too:

omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered
omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517

> BTW, maybe add a link to your build system to www.arm.linux.org.uk
> developer page too? At least I could not find a link to it.

Hmm, I thought I had, but it looks like I never pushed the change to
the main site.  I'll do that at some point.
Tony Lindgren July 9, 2013, 8:23 a.m. UTC | #9
* Russell King - ARM Linux <linux@arm.linux.org.uk> [130708 07:27]:
> On Mon, Jul 08, 2013 at 02:34:11AM -0700, Tony Lindgren wrote:
> > 
> > Hey the good news is that you've updated your build system to support
> > also appended dtb images, thanks for doing that!
> 
> It was far from trivial - there's many places in the build process
> which do things quite differently depending on whether it's a DTB
> build or not.

Yes that's too bad. We can make it slightly easier to update from custom
.config files by always building in support for board-generic.c.
 
> It seems that - yet again - the mmc devices have swapped themselves.

Hmm they also seem to swap depending if there's a card plugged in.

> Also looks like the nonfunctional video stuff is even more nonfunctional
> than usual:
> 
> omapdss DSI error: can't get VDDS_DSI regulator
> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

Tomi?
 
> ASoC looks dead too:
> 
> omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered
> omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517

Peter, I think you've had audio working with devicetree for at least
a year or something?

Regards,

Tony
Peter Ujfalusi July 12, 2013, 9:09 a.m. UTC | #10
On 07/09/2013 10:23 AM, Tony Lindgren wrote:
>> ASoC looks dead too:
>>
>> omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered
>> omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517
> 
> Peter, I think you've had audio working with devicetree for at least
> a year or something?

Yes it has been working and going to work soon again:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-July/063909.html

With the DMA devicetree bindings platform_get_resource_byname() stopped
working for DMA (it works for MEM resources) -> dai drivers were not probing.
Olof Johansson July 13, 2013, 2:31 a.m. UTC | #11
Hi,


On Sat, Jul 6, 2013 at 6:36 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> With that worked out, throwing my standard printascii() hack into the
> kernel results in boot messages... up to the point where the timer is
> calibrated.  So, it looks like either interrupts, clocks, or the OMAP
> timers are non-functional with DT based kernels on the SDP board.
>
> Any ideas?

I'm a bit late to the party due to travel and other things going on,
but I have the exact same thing happening with multi_v7_defconfig on
my Panda ES right now -- it gets stuck on calibrating delay loop. I
needed to enable DEBUG_LL and early printk to not just get a dead
system though.

What happened in my case was that MACH_OMAP4 was no longer enabled so
clocks weren't registered. I wonder if we can improve debugability of
that somehow.

Before Arnd's patch to flip the MACH_OMAP2PLUS option around, they got
enabled by default I think. So now I needed:

-CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_ARCH_OMAP3=y
+CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y
+CONFIG_SOC_AM33XX=y

...in the defconfig.

This is pretty painful, and I don't know if we want to rethink Arnd's
patch since it will break existing defconfigs out there that rely on
OMAP2PLUS enabling the socs instead of the other way around. Opinions?


-Olof
Olof Johansson July 13, 2013, 3:10 a.m. UTC | #12
On Fri, Jul 12, 2013 at 7:31 PM, Olof Johansson <olof@lixom.net> wrote:

> This is pretty painful, and I don't know if we want to rethink Arnd's
> patch since it will break existing defconfigs out there that rely on
> OMAP2PLUS enabling the socs instead of the other way around. Opinions?

(replying to myself, I know, I know...)

I think it's probably easiest to just select the OMAP{2,3,4} and
AM33XX options in multi_v7_defconfig just like Arnd did in the commit
that changed the dependencies for now. I've added a patch on top of
our current fixes branch to do so.

Note that you need to make corresponding changes to your seeds for
your build tests, Russell.


-Olof
Tony Lindgren July 15, 2013, 6:55 a.m. UTC | #13
* Olof Johansson <olof@lixom.net> [130712 20:16]:
> On Fri, Jul 12, 2013 at 7:31 PM, Olof Johansson <olof@lixom.net> wrote:
> 
> > This is pretty painful, and I don't know if we want to rethink Arnd's
> > patch since it will break existing defconfigs out there that rely on
> > OMAP2PLUS enabling the socs instead of the other way around. Opinions?
> 
> (replying to myself, I know, I know...)
> 
> I think it's probably easiest to just select the OMAP{2,3,4} and
> AM33XX options in multi_v7_defconfig just like Arnd did in the commit
> that changed the dependencies for now. I've added a patch on top of
> our current fixes branch to do so.

Well should select only omap 3 and later for multi_v7_defconfig as
omap2 is v6 :)
 
> Note that you need to make corresponding changes to your seeds for
> your build tests, Russell.

Eventually we could have them all selected based on the core type,
but I'd rather not do that until clocks and hwmod data come from DT.

Regards,

Tony
Tomi Valkeinen July 22, 2013, 9:40 a.m. UTC | #14
On 08/07/13 17:21, Russell King - ARM Linux wrote:

> Also looks like the nonfunctional video stuff is even more nonfunctional
> than usual:
> 
> omapdss DSI error: can't get VDDS_DSI regulator
> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

Those should be followed by "...requests probe deferral", and the driver
is probed again later.

The log
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=946
shows "taal display2: panel revision e3.83.7d" which hints that the
panel (and DSS) was initialized properly.

Those error prints should probably be tuned down a bit now that the
driver uses probe deferral.

 Tomi
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f49cd51..465edd1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -378,14 +378,6 @@  config MACH_TI8148EVM
 	depends on SOC_TI81XX
 	default y
 
-config MACH_OMAP_4430SDP
-	bool "OMAP 4430 SDP board"
-	default y
-	depends on ARCH_OMAP4
-	select OMAP_PACKAGE_CBL
-	select OMAP_PACKAGE_CBS
-	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-
 config MACH_OMAP4_PANDA
 	bool "OMAP4 Panda Board"
 	default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..875d61d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -251,7 +251,6 @@  obj-$(CONFIG_MACH_CM_T35)		+= board-cm-t35.o
 obj-$(CONFIG_MACH_CM_T3517)		+= board-cm-t3517.o
 obj-$(CONFIG_MACH_IGEP0020)		+= board-igep0020.o
 obj-$(CONFIG_MACH_TOUCHBOOK)		+= board-omap3touchbook.o
-obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o
 obj-$(CONFIG_MACH_OMAP4_PANDA)		+= board-omap4panda.o
 
 obj-$(CONFIG_MACH_OMAP3517EVM)		+= board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
deleted file mode 100644
index 56a9a4f..0000000
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ /dev/null
@@ -1,765 +0,0 @@ 
-/*
- * Board support file for OMAP4430 SDP.
- *
- * Copyright (C) 2009 Texas Instruments
- *
- * Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
- *
- * Based on mach-omap2/board-3430sdp.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-#include <linux/gpio.h>
-#include <linux/usb/otg.h>
-#include <linux/spi/spi.h>
-#include <linux/i2c/twl.h>
-#include <linux/mfd/twl6040.h>
-#include <linux/gpio_keys.h>
-#include <linux/regulator/machine.h>
-#include <linux/regulator/fixed.h>
-#include <linux/pwm.h>
-#include <linux/leds.h>
-#include <linux/leds_pwm.h>
-#include <linux/pwm_backlight.h>
-#include <linux/irqchip/arm-gic.h>
-#include <linux/platform_data/omap4-keypad.h>
-#include <linux/usb/musb.h>
-#include <linux/usb/phy.h>
-
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-
-#include "common.h"
-#include "omap4-keypad.h"
-#include <linux/wl12xx.h>
-#include <linux/platform_data/omap-abe-twl6040.h>
-
-#include "soc.h"
-#include "mux.h"
-#include "mmc.h"
-#include "hsmmc.h"
-#include "control.h"
-#include "common-board-devices.h"
-#include "dss-common.h"
-
-#define ETH_KS8851_IRQ			34
-#define ETH_KS8851_POWER_ON		48
-#define ETH_KS8851_QUART		138
-#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO	184
-#define OMAP4_SFH7741_ENABLE_GPIO		188
-
-#define GPIO_WIFI_PMENA		54
-#define GPIO_WIFI_IRQ		53
-
-static const int sdp4430_keymap[] = {
-	KEY(0, 0, KEY_E),
-	KEY(0, 1, KEY_R),
-	KEY(0, 2, KEY_T),
-	KEY(0, 3, KEY_HOME),
-	KEY(0, 4, KEY_F5),
-	KEY(0, 5, KEY_UNKNOWN),
-	KEY(0, 6, KEY_I),
-	KEY(0, 7, KEY_LEFTSHIFT),
-
-	KEY(1, 0, KEY_D),
-	KEY(1, 1, KEY_F),
-	KEY(1, 2, KEY_G),
-	KEY(1, 3, KEY_SEND),
-	KEY(1, 4, KEY_F6),
-	KEY(1, 5, KEY_UNKNOWN),
-	KEY(1, 6, KEY_K),
-	KEY(1, 7, KEY_ENTER),
-
-	KEY(2, 0, KEY_X),
-	KEY(2, 1, KEY_C),
-	KEY(2, 2, KEY_V),
-	KEY(2, 3, KEY_END),
-	KEY(2, 4, KEY_F7),
-	KEY(2, 5, KEY_UNKNOWN),
-	KEY(2, 6, KEY_DOT),
-	KEY(2, 7, KEY_CAPSLOCK),
-
-	KEY(3, 0, KEY_Z),
-	KEY(3, 1, KEY_KPPLUS),
-	KEY(3, 2, KEY_B),
-	KEY(3, 3, KEY_F1),
-	KEY(3, 4, KEY_F8),
-	KEY(3, 5, KEY_UNKNOWN),
-	KEY(3, 6, KEY_O),
-	KEY(3, 7, KEY_SPACE),
-
-	KEY(4, 0, KEY_W),
-	KEY(4, 1, KEY_Y),
-	KEY(4, 2, KEY_U),
-	KEY(4, 3, KEY_F2),
-	KEY(4, 4, KEY_VOLUMEUP),
-	KEY(4, 5, KEY_UNKNOWN),
-	KEY(4, 6, KEY_L),
-	KEY(4, 7, KEY_LEFT),
-
-	KEY(5, 0, KEY_S),
-	KEY(5, 1, KEY_H),
-	KEY(5, 2, KEY_J),
-	KEY(5, 3, KEY_F3),
-	KEY(5, 4, KEY_F9),
-	KEY(5, 5, KEY_VOLUMEDOWN),
-	KEY(5, 6, KEY_M),
-	KEY(5, 7, KEY_RIGHT),
-
-	KEY(6, 0, KEY_Q),
-	KEY(6, 1, KEY_A),
-	KEY(6, 2, KEY_N),
-	KEY(6, 3, KEY_BACK),
-	KEY(6, 4, KEY_BACKSPACE),
-	KEY(6, 5, KEY_UNKNOWN),
-	KEY(6, 6, KEY_P),
-	KEY(6, 7, KEY_UP),
-
-	KEY(7, 0, KEY_PROG1),
-	KEY(7, 1, KEY_PROG2),
-	KEY(7, 2, KEY_PROG3),
-	KEY(7, 3, KEY_PROG4),
-	KEY(7, 4, KEY_F4),
-	KEY(7, 5, KEY_UNKNOWN),
-	KEY(7, 6, KEY_OK),
-	KEY(7, 7, KEY_DOWN),
-};
-static struct omap_device_pad keypad_pads[] = {
-	{	.name   = "kpd_col1.kpd_col1",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "kpd_col1.kpd_col1",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "kpd_col2.kpd_col2",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "kpd_col3.kpd_col3",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "kpd_col4.kpd_col4",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "kpd_col5.kpd_col5",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "gpmc_a23.kpd_col7",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "gpmc_a22.kpd_col6",
-		.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
-	},
-	{	.name   = "kpd_row0.kpd_row0",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "kpd_row1.kpd_row1",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "kpd_row2.kpd_row2",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "kpd_row3.kpd_row3",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "kpd_row4.kpd_row4",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "kpd_row5.kpd_row5",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "gpmc_a18.kpd_row6",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-	{	.name   = "gpmc_a19.kpd_row7",
-		.enable = OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN |
-			OMAP_MUX_MODE1 | OMAP_INPUT_EN,
-	},
-};
-
-static struct matrix_keymap_data sdp4430_keymap_data = {
-	.keymap			= sdp4430_keymap,
-	.keymap_size		= ARRAY_SIZE(sdp4430_keymap),
-};
-
-static struct omap4_keypad_platform_data sdp4430_keypad_data = {
-	.keymap_data		= &sdp4430_keymap_data,
-	.rows			= 8,
-	.cols			= 8,
-};
-
-static struct omap_board_data keypad_data = {
-	.id	    		= 1,
-	.pads	 		= keypad_pads,
-	.pads_cnt       	= ARRAY_SIZE(keypad_pads),
-};
-
-static struct gpio_led sdp4430_gpio_leds[] = {
-	{
-		.name	= "omap4:green:debug0",
-		.gpio	= 61,
-	},
-	{
-		.name	= "omap4:green:debug1",
-		.gpio	= 30,
-	},
-	{
-		.name	= "omap4:green:debug2",
-		.gpio	= 7,
-	},
-	{
-		.name	= "omap4:green:debug3",
-		.gpio	= 8,
-	},
-	{
-		.name	= "omap4:green:debug4",
-		.gpio	= 50,
-	},
-	{
-		.name	= "omap4:blue:user",
-		.gpio	= 169,
-	},
-	{
-		.name	= "omap4:red:user",
-		.gpio	= 170,
-	},
-	{
-		.name	= "omap4:green:user",
-		.gpio	= 139,
-	},
-
-};
-
-static struct gpio_keys_button sdp4430_gpio_keys[] = {
-	{
-		.desc			= "Proximity Sensor",
-		.type			= EV_SW,
-		.code			= SW_FRONT_PROXIMITY,
-		.gpio			= OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
-		.active_low		= 0,
-	}
-};
-
-static struct gpio_led_platform_data sdp4430_led_data = {
-	.leds	= sdp4430_gpio_leds,
-	.num_leds	= ARRAY_SIZE(sdp4430_gpio_leds),
-};
-
-static struct pwm_lookup sdp4430_pwm_lookup[] = {
-	PWM_LOOKUP("twl-pwm", 0, "leds_pwm", "omap4::keypad"),
-	PWM_LOOKUP("twl-pwm", 1, "pwm-backlight", NULL),
-	PWM_LOOKUP("twl-pwmled", 0, "leds_pwm", "omap4:green:chrg"),
-};
-
-static struct led_pwm sdp4430_pwm_leds[] = {
-	{
-		.name		= "omap4::keypad",
-		.max_brightness	= 127,
-		.pwm_period_ns	= 7812500,
-	},
-	{
-		.name		= "omap4:green:chrg",
-		.max_brightness	= 255,
-		.pwm_period_ns	= 7812500,
-	},
-};
-
-static struct led_pwm_platform_data sdp4430_pwm_data = {
-	.num_leds	= ARRAY_SIZE(sdp4430_pwm_leds),
-	.leds		= sdp4430_pwm_leds,
-};
-
-static struct platform_device sdp4430_leds_pwm = {
-	.name	= "leds_pwm",
-	.id	= -1,
-	.dev	= {
-		.platform_data = &sdp4430_pwm_data,
-	},
-};
-
-/* Dummy regulator for pwm-backlight driver */
-static struct regulator_consumer_supply backlight_supply =
-	REGULATOR_SUPPLY("enable", "pwm-backlight");
-
-static struct platform_pwm_backlight_data sdp4430_backlight_data = {
-	.max_brightness = 127,
-	.dft_brightness = 127,
-	.pwm_period_ns = 7812500,
-};
-
-static struct platform_device sdp4430_backlight_pwm = {
-	.name   = "pwm-backlight",
-	.id     = -1,
-	.dev    = {
-		.platform_data = &sdp4430_backlight_data,
-	},
-};
-
-static int omap_prox_activate(struct device *dev)
-{
-	gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
-	return 0;
-}
-
-static void omap_prox_deactivate(struct device *dev)
-{
-	gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
-}
-
-static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
-	.buttons	= sdp4430_gpio_keys,
-	.nbuttons	= ARRAY_SIZE(sdp4430_gpio_keys),
-	.enable		= omap_prox_activate,
-	.disable	= omap_prox_deactivate,
-};
-
-static struct platform_device sdp4430_gpio_keys_device = {
-	.name	= "gpio-keys",
-	.id	= -1,
-	.dev	= {
-		.platform_data	= &sdp4430_gpio_keys_data,
-	},
-};
-
-static struct platform_device sdp4430_leds_gpio = {
-	.name	= "leds-gpio",
-	.id	= -1,
-	.dev	= {
-		.platform_data = &sdp4430_led_data,
-	},
-};
-static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
-	{
-		.modalias               = "ks8851",
-		.bus_num                = 1,
-		.chip_select            = 0,
-		.max_speed_hz           = 24000000,
-		/*
-		 * .irq is set to gpio_to_irq(ETH_KS8851_IRQ)
-		 * in omap_4430sdp_init
-		 */
-	},
-};
-
-static struct gpio sdp4430_eth_gpios[] __initdata = {
-	{ ETH_KS8851_POWER_ON,	GPIOF_OUT_INIT_HIGH,	"eth_power"	},
-	{ ETH_KS8851_QUART,	GPIOF_OUT_INIT_HIGH,	"quart"		},
-	{ ETH_KS8851_IRQ,	GPIOF_IN,		"eth_irq"	},
-};
-
-static int __init omap_ethernet_init(void)
-{
-	int status;
-
-	/* Request of GPIO lines */
-	status = gpio_request_array(sdp4430_eth_gpios,
-				    ARRAY_SIZE(sdp4430_eth_gpios));
-	if (status)
-		pr_err("Cannot request ETH GPIOs\n");
-
-	return status;
-}
-
-static struct regulator_consumer_supply sdp4430_vbat_supply[] = {
-	REGULATOR_SUPPLY("vddvibl", "twl6040-vibra"),
-	REGULATOR_SUPPLY("vddvibr", "twl6040-vibra"),
-};
-
-static struct regulator_init_data sdp4430_vbat_data = {
-	.constraints = {
-		.always_on	= 1,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(sdp4430_vbat_supply),
-	.consumer_supplies	= sdp4430_vbat_supply,
-};
-
-static struct fixed_voltage_config sdp4430_vbat_pdata = {
-	.supply_name	= "VBAT",
-	.microvolts	= 3750000,
-	.init_data	= &sdp4430_vbat_data,
-	.gpio		= -EINVAL,
-};
-
-static struct platform_device sdp4430_vbat = {
-	.name		= "reg-fixed-voltage",
-	.id		= -1,
-	.dev = {
-		.platform_data = &sdp4430_vbat_pdata,
-	},
-};
-
-static struct platform_device sdp4430_dmic_codec = {
-	.name	= "dmic-codec",
-	.id	= -1,
-};
-
-static struct platform_device sdp4430_hdmi_audio_codec = {
-	.name	= "hdmi-audio-codec",
-	.id	= -1,
-};
-
-static struct omap_abe_twl6040_data sdp4430_abe_audio_data = {
-	.card_name = "SDP4430",
-	.has_hs		= ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
-	.has_hf		= ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
-	.has_ep		= 1,
-	.has_aux	= ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
-	.has_vibra	= ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
-
-	.has_dmic	= 1,
-	.has_hsmic	= 1,
-	.has_mainmic	= 1,
-	.has_submic	= 1,
-	.has_afm	= ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
-
-	.jack_detection = 1,
-	/* MCLK input is 38.4MHz */
-	.mclk_freq	= 38400000,
-};
-
-static struct platform_device sdp4430_abe_audio = {
-	.name		= "omap-abe-twl6040",
-	.id		= -1,
-	.dev = {
-		.platform_data = &sdp4430_abe_audio_data,
-	},
-};
-
-static struct platform_device *sdp4430_devices[] __initdata = {
-	&sdp4430_gpio_keys_device,
-	&sdp4430_leds_gpio,
-	&sdp4430_leds_pwm,
-	&sdp4430_backlight_pwm,
-	&sdp4430_vbat,
-	&sdp4430_dmic_codec,
-	&sdp4430_abe_audio,
-	&sdp4430_hdmi_audio_codec,
-};
-
-static struct omap_musb_board_data musb_board_data = {
-	.interface_type		= MUSB_INTERFACE_UTMI,
-	.mode			= MUSB_OTG,
-	.power			= 100,
-};
-
-static struct omap2_hsmmc_info mmc[] = {
-	{
-		.mmc		= 2,
-		.caps		=  MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
-		.gpio_cd	= -EINVAL,
-		.gpio_wp	= -EINVAL,
-		.nonremovable   = true,
-		.ocr_mask	= MMC_VDD_29_30,
-		.no_off_init	= true,
-	},
-	{
-		.mmc		= 1,
-		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
-		.gpio_cd	= -EINVAL,
-		.gpio_wp	= -EINVAL,
-	},
-	{
-		.mmc		= 5,
-		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
-		.pm_caps	= MMC_PM_KEEP_POWER,
-		.gpio_cd	= -EINVAL,
-		.gpio_wp	= -EINVAL,
-		.ocr_mask	= MMC_VDD_165_195,
-		.nonremovable	= true,
-	},
-	{}	/* Terminator */
-};
-
-static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
-	REGULATOR_SUPPLY("vmmc", "omap_hsmmc.1"),
-};
-
-static struct regulator_consumer_supply omap4_sdp4430_vmmc5_supply = {
-	.supply = "vmmc",
-	.dev_name = "omap_hsmmc.4",
-};
-
-static struct regulator_init_data sdp4430_vmmc5 = {
-	.constraints = {
-		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies = 1,
-	.consumer_supplies = &omap4_sdp4430_vmmc5_supply,
-};
-
-static struct fixed_voltage_config sdp4430_vwlan = {
-	.supply_name		= "vwl1271",
-	.microvolts		= 1800000, /* 1.8V */
-	.gpio			= GPIO_WIFI_PMENA,
-	.startup_delay		= 70000, /* 70msec */
-	.enable_high		= 1,
-	.enabled_at_boot	= 0,
-	.init_data		= &sdp4430_vmmc5,
-};
-
-static struct platform_device omap_vwlan_device = {
-	.name		= "reg-fixed-voltage",
-	.id		= 1,
-	.dev = {
-		.platform_data = &sdp4430_vwlan,
-	},
-};
-
-static struct regulator_init_data sdp4430_vaux1 = {
-	.constraints = {
-		.min_uV			= 1000000,
-		.max_uV			= 3000000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask	 = REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies  = ARRAY_SIZE(sdp4430_vaux_supply),
-	.consumer_supplies      = sdp4430_vaux_supply,
-};
-
-static struct regulator_init_data sdp4430_vusim = {
-	.constraints = {
-		.min_uV			= 1200000,
-		.max_uV			= 2900000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask	 = REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct twl6040_codec_data twl6040_codec = {
-	/* single-step ramp for headset and handsfree */
-	.hs_left_step	= 0x0f,
-	.hs_right_step	= 0x0f,
-	.hf_left_step	= 0x1d,
-	.hf_right_step	= 0x1d,
-};
-
-static struct twl6040_vibra_data twl6040_vibra = {
-	.vibldrv_res = 8,
-	.vibrdrv_res = 3,
-	.viblmotor_res = 10,
-	.vibrmotor_res = 10,
-	.vddvibl_uV = 0,	/* fixed volt supply - VBAT */
-	.vddvibr_uV = 0,	/* fixed volt supply - VBAT */
-};
-
-static struct twl6040_platform_data twl6040_data = {
-	.codec		= &twl6040_codec,
-	.vibra		= &twl6040_vibra,
-	.audpwron_gpio	= 127,
-};
-
-static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
-	{
-		I2C_BOARD_INFO("twl6040", 0x4b),
-		.irq = 119 + OMAP44XX_IRQ_GIC_START,
-		.platform_data = &twl6040_data,
-	},
-};
-
-static struct twl4030_platform_data sdp4430_twldata = {
-	/* Regulators */
-	.vusim		= &sdp4430_vusim,
-	.vaux1		= &sdp4430_vaux1,
-};
-
-static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
-	{
-		I2C_BOARD_INFO("tmp105", 0x48),
-	},
-	{
-		I2C_BOARD_INFO("bh1780", 0x29),
-	},
-};
-static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
-	{
-		I2C_BOARD_INFO("hmc5843", 0x1e),
-	},
-};
-static int __init omap4_i2c_init(void)
-{
-	omap4_pmic_get_config(&sdp4430_twldata, TWL_COMMON_PDATA_USB,
-			TWL_COMMON_REGULATOR_VDAC |
-			TWL_COMMON_REGULATOR_VAUX2 |
-			TWL_COMMON_REGULATOR_VAUX3 |
-			TWL_COMMON_REGULATOR_VMMC |
-			TWL_COMMON_REGULATOR_VPP |
-			TWL_COMMON_REGULATOR_VANA |
-			TWL_COMMON_REGULATOR_VCXIO |
-			TWL_COMMON_REGULATOR_VUSB |
-			TWL_COMMON_REGULATOR_CLK32KG |
-			TWL_COMMON_REGULATOR_V1V8 |
-			TWL_COMMON_REGULATOR_V2V1);
-	omap4_pmic_init("twl6030", &sdp4430_twldata, sdp4430_i2c_1_boardinfo,
-			ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
-	omap_register_i2c_bus(2, 400, NULL, 0);
-	omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
-				ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
-	omap_register_i2c_bus(4, 400, sdp4430_i2c_4_boardinfo,
-				ARRAY_SIZE(sdp4430_i2c_4_boardinfo));
-	return 0;
-}
-
-static void __init omap_sfh7741prox_init(void)
-{
-	int error;
-
-	error = gpio_request_one(OMAP4_SFH7741_ENABLE_GPIO,
-				 GPIOF_OUT_INIT_LOW, "sfh7741");
-	if (error < 0)
-		pr_err("%s:failed to request GPIO %d, error %d\n",
-			__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
-}
-
-#ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
-	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
-	/* NIRQ2 for twl6040 */
-	OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
-		  OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
-	/* GPIO_127 for twl6040 */
-	OMAP4_MUX(HDQ_SIO, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
-	/* McPDM */
-	OMAP4_MUX(ABE_PDM_UL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
-	OMAP4_MUX(ABE_PDM_DL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
-	OMAP4_MUX(ABE_PDM_FRAME, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
-	OMAP4_MUX(ABE_PDM_LB_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
-	OMAP4_MUX(ABE_CLKS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
-	/* DMIC */
-	OMAP4_MUX(ABE_DMIC_CLK1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-	OMAP4_MUX(ABE_DMIC_DIN1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-	OMAP4_MUX(ABE_DMIC_DIN2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-	OMAP4_MUX(ABE_DMIC_DIN3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-	/* McBSP1 */
-	OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-	OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
-	OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
-		  OMAP_PULL_ENA),
-	OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-	/* McBSP2 */
-	OMAP4_MUX(ABE_MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-	OMAP4_MUX(ABE_MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
-	OMAP4_MUX(ABE_MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
-		  OMAP_PULL_ENA),
-	OMAP4_MUX(ABE_MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
-
-	{ .reg_offset = OMAP_MUX_TERMINATOR },
-};
-
-#else
-#define board_mux	NULL
- #endif
-
-static void __init omap4_sdp4430_wifi_mux_init(void)
-{
-	omap_mux_init_gpio(GPIO_WIFI_IRQ, OMAP_PIN_INPUT |
-				OMAP_PIN_OFF_WAKEUPENABLE);
-	omap_mux_init_gpio(GPIO_WIFI_PMENA, OMAP_PIN_OUTPUT);
-
-	omap_mux_init_signal("sdmmc5_cmd.sdmmc5_cmd",
-				OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("sdmmc5_clk.sdmmc5_clk",
-				OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("sdmmc5_dat0.sdmmc5_dat0",
-				OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("sdmmc5_dat1.sdmmc5_dat1",
-				OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("sdmmc5_dat2.sdmmc5_dat2",
-				OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("sdmmc5_dat3.sdmmc5_dat3",
-				OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP);
-
-}
-
-static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_26,
-	.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
-};
-
-static void __init omap4_sdp4430_wifi_init(void)
-{
-	int ret;
-
-	omap4_sdp4430_wifi_mux_init();
-	omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
-	ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
-	if (ret)
-		pr_err("Error setting wl12xx data: %d\n", ret);
-	ret = platform_device_register(&omap_vwlan_device);
-	if (ret)
-		pr_err("Error registering wl12xx device: %d\n", ret);
-}
-
-static void __init omap_4430sdp_init(void)
-{
-	int status;
-	int package = OMAP_PACKAGE_CBS;
-
-	if (omap_rev() == OMAP4430_REV_ES1_0)
-		package = OMAP_PACKAGE_CBL;
-	omap4_mux_init(board_mux, NULL, package);
-
-	omap4_i2c_init();
-	omap_sfh7741prox_init();
-	regulator_register_always_on(0, "backlight-enable",
-				     &backlight_supply, 1, 0);
-	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
-	omap_serial_init();
-	omap_sdrc_init(NULL, NULL);
-	omap4_sdp4430_wifi_init();
-	omap4_twl6030_hsmmc_init(mmc);
-
-	usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
-	usb_musb_init(&musb_board_data);
-
-	status = omap_ethernet_init();
-	if (status) {
-		pr_err("Ethernet initialization failed: %d\n", status);
-	} else {
-		sdp4430_spi_board_info[0].irq = gpio_to_irq(ETH_KS8851_IRQ);
-		spi_register_board_info(sdp4430_spi_board_info,
-				ARRAY_SIZE(sdp4430_spi_board_info));
-	}
-
-	pwm_add_table(sdp4430_pwm_lookup, ARRAY_SIZE(sdp4430_pwm_lookup));
-	status = omap4_keyboard_init(&sdp4430_keypad_data, &keypad_data);
-	if (status)
-		pr_err("Keypad initialization failed: %d\n", status);
-
-	omap_4430sdp_display_init();
-}
-
-MACHINE_START(OMAP_4430SDP, "OMAP4430 4430SDP board")
-	/* Maintainer: Santosh Shilimkar - Texas Instruments Inc */
-	.atag_offset	= 0x100,
-	.smp		= smp_ops(omap4_smp_ops),
-	.reserve	= omap_reserve,
-	.map_io		= omap4_map_io,
-	.init_early	= omap4430_init_early,
-	.init_irq	= gic_init_irq,
-	.init_machine	= omap_4430sdp_init,
-	.init_late	= omap4430_init_late,
-	.init_time	= omap4_local_timer_init,
-	.restart	= omap44xx_restart,
-MACHINE_END