Re: Please help in adding ams-delta support to ASoC
Hi On Tue, 26 May 2009 15:17:23 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Grr, these McBSP bits are always almost un-readable :-) 4. the following McBSP register settings changes: - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), XFIG is only difference (OMAP_MCBSP_WORD_8 = 0) - transfer is aborted in case of unexpected frame sync. - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), + .srgr1 = CLKGDV(0), Width of frame sync signal set to 1 here - DSP_B format because no data delay set. - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), + .srgr2 = GSYNC, - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ No CLKXM, CLKRM and FSGM set - codec is providing the frame sync and bit-clock signals - SND_SOC_DAIFMT_CBM_CFM. CLKXP and CLKRP not set - rising edge of bit clock drives the transitions. This with DSP_B indicates inverted bit clock so SND_SOC_DAIFMT_IB_NF. I wonder why the frame sync period (FWID) wasn't set in that original patch but probably McBSP is able to work without :-) safely access the device, however it does not work as expected. aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae. DMA interrput counters stay at 0. However, codec Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. Do you have any way to measure is the codec sending those? Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls. First of all, I'd like to make sure if my problem is related to my code only. As I am new in these areas, I would like to ask you if the omap asoc framework is stable enough to relay on. If yes, could you please look at my dirty code (attached) an give me some hints? I can provide you with more information if necessary. I hope it's stable enough for you to get going. It would be nice to get this working since it would be the first OMAP5910 == OMAP1510 based machine driver. OMAP1510 doesn't support DMA chaining so there are few cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I think I have only simulated using OMAP2420. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Host on OMAP3 EVM, 2.6.29
Hi Eikka. Am not familiar with OMAP35xx. Also don't know, what's the config of EVM (if it uses twl4030 tranceiver or external). Can it play as a HOST which is the case to supply VBUS ? Otherwise external self-powered hub might be needed. -niilo- On Wed, 2009-05-27 at 02:59 +0200, ext Eino-Ville Talvala wrote: Hi, We're trying to get basic USB host mode up and running on a OMAP3530 EVM, with no success. We're (now, after many permutations of kernels and .config settings) using the vanilla 2.6.29-omap1 kernel plus the AUTOIDLE fix from Niilo Minkkinen), with slight additions to board-omap3evm to allow the MMC slot to work since it hosts the rootfs (missing regulator setup, as per dfoley's mail on 3/25). All we've done with configuration past omap3_evm_defconfig, is to compile in the MMC driver (to allow boot from it), enabling the EHCI host driver (doesn't work with it off, either), and setting the integrated USB driver to Host mode. Listed below is the resulting .config file. We've tried many other configurations, but nothing has worked any better. I'd very much appreciate it if anyone knows what magic sauce might be missing here - the USB bus debug messages indicate that the bus is being discovered, and powered up, but no voltage appears on the USB VBus line, and no devices are detected when they're plugged in. Sometimes we've seen auto-suspend messages indicating that the bus is auto-suspending, and other times we've seen nothing - but no matter what, it doesn't seem to work. Below is the output of dmesg | grep 'usb\|hub' for the above configuration with a USB keyboard plugged in, followed by the .config file: Thanks, Eino-Ville Talvala Graduate Research Assistant Computer Graphics Laboratory Stanford University -- twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80; link 1 twl4030_usb twl4030_usb: Initialized TWL4030 USB module usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb musb_hdrc: version 6.0, musb-dma, host, debug=0 musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx (X), HB-ISO Tx (X), SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_hdrc: setup fifo_mode 4 musb_hdrc: 29/31 max ep, 15424/16384 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3tx, max 512 musb_hdrc: hw_ep 3rx, max 512 musb_hdrc: hw_ep 4tx, max 512 musb_hdrc: hw_ep 4rx, max 512 musb_hdrc: hw_ep 5tx, max 512 musb_hdrc: hw_ep 5rx, max 512 musb_hdrc: hw_ep 6tx, max 512 musb_hdrc: hw_ep 6rx, max 512 musb_hdrc: hw_ep 7tx, max 512 musb_hdrc: hw_ep 7rx, max 512 musb_hdrc: hw_ep 8tx, max 512 musb_hdrc: hw_ep 8rx, max 512 musb_hdrc: hw_ep 9tx, max 512 musb_hdrc: hw_ep 9rx, max 512 musb_hdrc: hw_ep 10tx, max 512 musb_hdrc: hw_ep 10rx, max 512 musb_hdrc: hw_ep 11tx, max 512 musb_hdrc: hw_ep 11rx, max 512 musb_hdrc: hw_ep 12tx, max 512 musb_hdrc: hw_ep 12rx, max 512 musb_hdrc: hw_ep 13tx, max 512 musb_hdrc: hw_ep 13rx, max 512 musb_hdrc: hw_ep 14shared, max 1024 musb_hdrc: hw_ep 15shared, max 1024 musb_hdrc: USB Host mode controller at d80ab000 using DMA, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver drivers/usb/core/inode.c: creating file 'devices' drivers/usb/core/inode.c: creating file '001' musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: default language 0x0409 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 2.6.29-omap1-05531-g0dfe43a-dirty musb-hcd usb usb1: SerialNumber: musb_hdrc usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected hub 1-0:1.0: standalone hub hub 1-0:1.0: individual port power switching hub 1-0:1.0: no over-current protection hub 1-0:1.0: power on to power good time: 10ms hub 1-0:1.0: 100mA bus power budget for each child hub 1-0:1.0: local power source is good hub 1-0:1.0: enabling power on all ports drivers/usb/core/inode.c: creating file '001' hub 1-0:1.0: state 7 ports 1 chg evt usbmon: debugfs is not available drivers/usb/core/inode.c: creating file '002' usb usb2: default language 0x0409 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: OMAP-EHCI Host
[PATCH] OMAP3: Re-program also chipselect 1 when changing SDRAM timing
From: Tero Kristo tero.kri...@nokia.com Previously only chipselect 0 was controlled, which would result in the chipselect 1 running on too low rate during low core OPPs. Applies on top of PM branch. Signed-off-by: Tero Kristo tero.kri...@nokia.com --- arch/arm/mach-omap2/sram34xx.S | 29 +++-- 1 files changed, 23 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index f41f8d9..bcfe9eb 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -187,15 +187,24 @@ wait_dll_unlock: bne wait_dll_unlock bx lr configure_sdrc: - ldr r11, omap3_sdrc_rfr_ctrl + ldr r11, omap3_sdrc_rfr_ctrl_0 str r0, [r11] - ldr r11, omap3_sdrc_actim_ctrla + ldr r11, omap3_sdrc_rfr_ctrl_1 + str r0, [r11] + ldr r11, omap3_sdrc_actim_ctrla_0 + str r1, [r11] + ldr r11, omap3_sdrc_actim_ctrla_1 str r1, [r11] - ldr r11, omap3_sdrc_actim_ctrlb + ldr r11, omap3_sdrc_actim_ctrlb_0 + str r2, [r11] + ldr r11, omap3_sdrc_actim_ctrlb_1 str r2, [r11] ldr r11, omap3_sdrc_mr_0 str r6, [r11] ldr r6, [r11] @ posted-write barrier for SDRC + ldr r11, omap3_sdrc_mr_1 + str r6, [r11] + ldr r6, [r11] @ posted-write barrier for SDRC bx lr omap3_sdrc_power: @@ -206,14 +215,22 @@ omap3_cm_idlest1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST) omap3_cm_iclken1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1) -omap3_sdrc_rfr_ctrl: +omap3_sdrc_rfr_ctrl_0: .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_0) -omap3_sdrc_actim_ctrla: +omap3_sdrc_rfr_ctrl_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_1) +omap3_sdrc_actim_ctrla_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_0) -omap3_sdrc_actim_ctrlb: +omap3_sdrc_actim_ctrla_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_1) +omap3_sdrc_actim_ctrlb_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_0) +omap3_sdrc_actim_ctrlb_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_1) omap3_sdrc_mr_0: .word OMAP34XX_SDRC_REGADDR(SDRC_MR_0) +omap3_sdrc_mr_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_MR_1) omap3_sdrc_dlla_status: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) omap3_sdrc_dlla_ctrl: -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
Hi Peter,
On Wuesday 27 May 2009 07:57 Peter Ujfalusi wrote:
On Tuesday 26 May 2009 16:17:23 ext Janusz Krzysztofik wrote:
4. the following McBSP register settings changes:
- .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
- XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
+ .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
- .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
+ .srgr1 = CLKGDV(0),
- .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1),
+ .srgr2 = GSYNC,
- .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */
Since I don't have the original osk/aic23 thing, this does not mean to much...
Just a bit confusing.
OK, once again then.
original omap-alsa mcbsp register settings for osk board, as found in
linux-2.6.16/arch/arm/mach-omap1/board-osk.c:
-
#define DEFAULT_BITPERSAMPLE 16
static struct omap_mcbsp_reg_cfg mcbsp_regs = {
.spcr2 = FREE | FRST | GRST | XRST | XINTM(3),
.spcr1 = RINTM(3) | RRST,
.rcr2 = RPHASE | RFRLEN2(OMAP_MCBSP_WORD_8) |
RWDLEN2(OMAP_MCBSP_WORD_16) | RDATDLY(0),
.rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_16),
.xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
.xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_16),
.srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1),
/*.pcr0 = FSXM | FSRM | CLKXM | CLKRM | CLKXP | CLKRP,*/ /*
mcbsp: master */
.pcr0 = CLKXP | CLKRP, /* mcbsp: slave */
};
-
the same for ams-delta, as found in Mark Underwood patch:
-
static struct omap_mcbsp_reg_cfg mcbsp_regs = {
.spcr2 = FREE | XRST | GRST | XINTM(3) | FRST,
.spcr1 = RINTM(3) | RRST,
.rcr2 = RPHASE | RWDLEN2(OMAP_MCBSP_WORD_16) | RFRLEN2(0),
.rcr1 = RWDLEN1(OMAP_MCBSP_WORD_16) | RFRLEN1(0),
.xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
.xcr1 = XWDLEN1(OMAP_MCBSP_WORD_16) | XFRLEN1(0),
.srgr1 = CLKGDV(0),
.srgr2 = GSYNC,
};
-
currnet soc-audio mcbsp config for osk, as found in
linux-2.6.29/sound/soc/omap/osk5912.c:
-
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B |
SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBM_CFM);
-
Using exactly the same does not work on my ams-delta.
The configuration suggest slave McBSP with NB_IF
polarity, dual phase format, 16 bit words, 16*2 long frames, the FS pulse is
probably a pulse... Suggesting kind of DSP mode, but with not so correct
configuration, which happens to be working.
So I will try the following then:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B |
SND_SOC_DAIFMT_NB_IF |
SND_SOC_DAIFMT_CBM_CFM);
and this:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_A |
SND_SOC_DAIFMT_NB_IF |
SND_SOC_DAIFMT_CBM_CFM);
and give you a feedback.
... aplay
and arecord wait forever, cat to/from /dev/dsp breaks with hardware
error messgae.
DMA interrput counters stay at 0.
This means that the McBSP module is not transmitting/receiving any data.
Which suggests that the clocking is not working in your setup. Check the slave
master mode for the codec.
Do you mean trying with codec as slave and McBSP as master, like this?
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B |
SND_SOC_DAIFMT_NB_IF |
SND_SOC_DAIFMT_CBS_CFS);
I'll give it a try as well.
Also worth checking the PIN configuration for the McBSP1 module, just in case
it is correct.
Do you mean mux setup? Reading OMAP5910 Data Manual I found only 2
relevant signals, MCBSP1.FSX and MCBSP1.DX, that could be swapped from
pin H15 to H18 and vice versa. However, there is no pin configuration
entry for neither, both in 2.6.16 and 2.6.29 arch/arm/mach-omap1/mux.c,
so I assume default setup should just work.
I keep on digging.
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
Hi Jarkko,
On Wed, 27 May 2009 08:59 Jarkko Nikula wrote:
On Tue, 26 May 2009 15:17:23 +0200
Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
- .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
- XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
+ .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
XFIG is only difference (OMAP_MCBSP_WORD_8 = 0) - transfer is aborted
in case of unexpected frame sync.
I tried commenting out RFIG and XFIG bits settings in
sound/soc/omap/omap-mcbsp.c - did not help.
- .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
+ .srgr1 = CLKGDV(0),
Width of frame sync signal set to 1 here - DSP_B format because no
data delay set.
That's what I have tried mostly.
- .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE *
2 - 1),
+ .srgr2 = GSYNC,
- .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */
No CLKXM, CLKRM and FSGM set - codec is providing the frame sync and
bit-clock signals - SND_SOC_DAIFMT_CBM_CFM.
This is my primary choice as well.
CLKXP and CLKRP not set - rising edge of bit clock drives the
transitions. This with DSP_B indicates inverted bit clock so
SND_SOC_DAIFMT_IB_NF.
I have given it a try this morning - no go.
I wonder why the frame sync period (FWID) wasn't set in that original
patch but probably McBSP is able to work without :-)
from linux-2.6.29/sound/soc/omap/omap-mcbsp.c:
switch (mcbsp_data-fmt SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
regs-srgr2 |= FPER(wlen * 2 - 1);
regs-srgr1 |= FWID(wlen - 1);
break;
case SND_SOC_DAIFMT_DSP_B:
regs-srgr2 |= FPER(wlen * channels - 1);
regs-srgr1 |= FWID(0);
break;
}
So it looks like in case of SND_SOC_DAIFMT_DSP_B, FWID is not set, only
FPER. However, in the original patch, FPER was not set either.
... aplay
and arecord wait forever, cat to/from /dev/dsp breaks with hardware
error messgae. DMA interrput counters stay at 0. However, codec
Looks like McBSP is not getting bit-clock and frame-sync signals from
the codec. Do you have any way to measure is the codec sending those?
Well, I am not sure, but I'll try if nothing helps.
Another possibility are the OMAP pins muxed for McBSP? I assume they
are if the bootloader is still the same
I boot both kernels, working 2.6.16 and not working 2.6.30-rc5, with the
same u-boot.bin.
but worth to find check was
previous kernel doing any runtime remuxing for those pins with
omap_cfg_reg calls.
I was not able to find anything relevant.
... OMAP1510 doesn't support DMA chaining so there are few
cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I
think I have only simulated using OMAP2420.
I hope DMA chaining is not an issue here. If I remove the DMA chaining
workaround from the original patch, I get signle DMA interrupts, so that
is better than none that I get with my patch.
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] I2C: OMAP3: Better noise suppression for fast/standard modes
Use longer noise filter period for fast and standard mode. Based on an
earlier patch by Eero Nurkkala.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
drivers/i2c/busses/i2c-omap.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d9880c..8c76cea 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -333,8 +333,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- /* HSI2C controller internal clk rate should be 19.2 Mhz */
- internal_clk = 19200;
+ /*
+* HSI2C controller internal clk rate should be 19.2 Mhz for
+* HS and for all modes on 2430. On 34xx we can use lower rate
+* to get longer filter period for better noise suppression.
+* The filter is iclk (fclk for HS) period.
+*/
+ if (dev-speed 400 || cpu_is_omap_2430())
+ internal_clk = 19200;
+ else if (dev-speed 100)
+ internal_clk = 9600;
+ else
+ internal_clk = 4000;
fclk_rate = clk_get_rate(dev-fclk) / 1000;
/* Compute prescaler divisor */
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] I2C: OMAP2/3: Fix scll/sclh calculations
Fix scll/sclh calculations for HS and fast modes. Currently the driver
uses equal (roughly) low/high times which will result in too short
low time.
OMAP3430 TRM gives the following equations:
F/S: tLow = (scll + 7) * internal_clk
tHigh = (sclh + 5) * internal_clk
HS: tLow = (scll + 7) * fclk
tHigh = (sclh + 5) * fclk
Furthermore, the I2C specification sets the following minimum values
for HS tLow/tHigh for capacitive bus loads 100 pF (maximum speed 3400)
and 400 pF (maximum speed 1700):
speed tLowtHigh
3400160 ns 60 ns
1700320 ns 120 ns
and for F/S:
speed tLowtHigh
400 1300 ns 600 ns
100 4700 ns 4000 ns
By using duty cycles 33/66 (HS, F) and 50/50 (S) we stay above these
minimum values.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
drivers/i2c/busses/i2c-omap.c | 25 ++---
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9919c08..5d9880c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -343,17 +343,28 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* If configured for High Speed */
if (dev-speed 400) {
+ unsigned long scl;
+
/* For first phase of HS mode */
- fsscll = internal_clk / (400 * 2) - 6;
- fssclh = internal_clk / (400 * 2) - 6;
+ scl = internal_clk / 400;
+ fsscll = scl - (scl / 3) - 7;
+ fssclh = (scl / 3) - 5;
/* For second phase of HS mode */
- hsscll = fclk_rate / (dev-speed * 2) - 6;
- hssclh = fclk_rate / (dev-speed * 2) - 6;
+ scl = fclk_rate / dev-speed;
+ hsscll = scl - (scl / 3) - 7;
+ hssclh = (scl / 3) - 5;
+ } else if (dev-speed 100) {
+ unsigned long scl;
+
+ /* Fast mode */
+ scl = internal_clk / dev-speed;
+ fsscll = scl - (scl / 3) - 7;
+ fssclh = (scl / 3) - 5;
} else {
- /* To handle F/S modes */
- fsscll = internal_clk / (dev-speed * 2) - 6;
- fssclh = internal_clk / (dev-speed * 2) - 6;
+ /* Standard mode */
+ fsscll = internal_clk / (dev-speed * 2) - 7;
+ fssclh = internal_clk / (dev-speed * 2) - 5;
}
scll = (hsscll OMAP_I2C_SCLL_HSSCLL) | fsscll;
sclh = (hssclh OMAP_I2C_SCLH_HSSCLH) | fssclh;
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
On Wed, 27 May 2009 16:33:22 +0200
Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
- .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE
* 2 - 1),
+ .srgr2 = GSYNC,
- .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */
...
I wonder why the frame sync period (FWID) wasn't set in that
original patch but probably McBSP is able to work without :-)
from linux-2.6.29/sound/soc/omap/omap-mcbsp.c:
switch (mcbsp_data-fmt SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
regs-srgr2 |= FPER(wlen * 2 - 1);
regs-srgr1 |= FWID(wlen - 1);
break;
case SND_SOC_DAIFMT_DSP_B:
regs-srgr2 |= FPER(wlen * channels - 1);
regs-srgr1 |= FWID(0);
break;
}
So it looks like in case of SND_SOC_DAIFMT_DSP_B, FWID is not set,
only FPER. However, in the original patch, FPER was not set either.
Sorry, my short above. Obviously I was wondering missing FPER setting
in original patch which defines the length of frame sync period. FWID
defines the length of frame sync pulse (n.o. bit clock pulses - 1).
Frame sync pulse length is half of the period in I2S and 1-bit clock
cycle in DSP_B. WM9713 has nice drawings about different formats. Look
pages 29 and 30.
http://www.wolfsonmicro.com/uploads/documents/en/WM9713.pdf
I hope DMA chaining is not an issue here. If I remove the DMA
chaining workaround from the original patch, I get signle DMA
interrupts, so that is better than none that I get with my patch.
I think chaining is not issue if you are not getting any interrupt.
Basically if DMA transfer is working but DMA restarting is not then
there should be one completed buffer transfer and = 2 interrupts from
completed periods.
--
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to configure android-2.6.27 kernel for an LCD display other than Zoom2 display
On Tue, May 19, 2009 at 8:17 AM, twebb taliaferr...@gmail.com wrote: On Fri, May 15, 2009 at 3:18 PM, twebb taliaferr...@gmail.com wrote: I'm using the L25.6/android-2.6.27 kernel and am adapting it as necessary to OMAP3530-based hardware. However, I don't see how to configure the kernel for an LCD display other than the NEC display defined for ZOOM2 (which is an SPI-based display?). I'm using an LG display via the dss_data[17:0] interface of the 35xx - and this is working with a slightly modified version of lcd_omap3evm.c on the linux-omap-2.6.27-omap1 kernel. I'm not familiar with the new DSS that appears to be in android-2.6.27. The LG display is WSVGA, but I'd be happy getting WVGA or VGA working on it for now. How can I configure the kernel to support a non-SPI-based LCD panel? How does this DSS differ with what appears in android-2.6.29/drivers/video/omap2 ? Any help here would be appreciated. Thanks, twebb Am I off base with these questions? I'd appreciate any feedback. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Re-program also chipselect 1 when changing SDRAM timing
Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com Previously only chipselect 0 was controlled, which would result in the chipselect 1 running on too low rate during low core OPPs. Applies on top of PM branch. Signed-off-by: Tero Kristo tero.kri...@nokia.com Hi Tero, This does part of what Jean Pihet does in his recent patch[1] to add support for 2 CSs. Your version assumes the same parameters for both SDRAM parts, and Jean has expanded that so board code can configure different paramaters for the different CSes. I have yet to fully review Jean's patch, but will probably take his version so that two different SDRAM parts could be used. Kevin [1] See hist post from 26 May: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings suspend/resume) --- arch/arm/mach-omap2/sram34xx.S | 29 +++-- 1 files changed, 23 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index f41f8d9..bcfe9eb 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -187,15 +187,24 @@ wait_dll_unlock: bne wait_dll_unlock bx lr configure_sdrc: - ldr r11, omap3_sdrc_rfr_ctrl + ldr r11, omap3_sdrc_rfr_ctrl_0 str r0, [r11] - ldr r11, omap3_sdrc_actim_ctrla + ldr r11, omap3_sdrc_rfr_ctrl_1 + str r0, [r11] + ldr r11, omap3_sdrc_actim_ctrla_0 + str r1, [r11] + ldr r11, omap3_sdrc_actim_ctrla_1 str r1, [r11] - ldr r11, omap3_sdrc_actim_ctrlb + ldr r11, omap3_sdrc_actim_ctrlb_0 + str r2, [r11] + ldr r11, omap3_sdrc_actim_ctrlb_1 str r2, [r11] ldr r11, omap3_sdrc_mr_0 str r6, [r11] ldr r6, [r11] @ posted-write barrier for SDRC + ldr r11, omap3_sdrc_mr_1 + str r6, [r11] + ldr r6, [r11] @ posted-write barrier for SDRC bx lr omap3_sdrc_power: @@ -206,14 +215,22 @@ omap3_cm_idlest1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST) omap3_cm_iclken1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1) -omap3_sdrc_rfr_ctrl: +omap3_sdrc_rfr_ctrl_0: .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_0) -omap3_sdrc_actim_ctrla: +omap3_sdrc_rfr_ctrl_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_1) +omap3_sdrc_actim_ctrla_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_0) -omap3_sdrc_actim_ctrlb: +omap3_sdrc_actim_ctrla_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_1) +omap3_sdrc_actim_ctrlb_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_0) +omap3_sdrc_actim_ctrlb_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_1) omap3_sdrc_mr_0: .word OMAP34XX_SDRC_REGADDR(SDRC_MR_0) +omap3_sdrc_mr_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_MR_1) omap3_sdrc_dlla_status: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) omap3_sdrc_dlla_ctrl: -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4]ARM: OMAP4: SMP: Patch series
Russell, I have rebased this series on top of your arm-smp patches and my earlier basic omap4 patches. Series is based of kernel.org 2.6.30-rc6 ( commit:1406de8e11eb043681297adf86d6892ff8efc27a). This series have dependency on [1],[2],[3],[4] and latest mach-types The series contains: [PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files [PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 [PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430 [PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430 Regards, Santosh [1]:Russell's arm-smp patch series + one of my patch http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/arm:smp.diff [2]:Tony's : [PATCH 0/5] More header clean-up http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12231.html [3]:Mine [PATCH 0/4] OMAP: Cleanup series. http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html [4]:Mine [PATCH 0/4] ARM: OMPA4: Basic boot patch series based on linux-omap http://lists.arm.linux.org.uk/lurker/message/20090520.125900.9209eb81.en.html Regards, Santosh-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430
This patch adds SMP platform specific parts for local(mpu) timer support
for OMAP4430 platform. Each Cortex-a9 core has it's own local timer in the
MPU domain. These timers are not in wakeup domain.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer-gp.c|4 +++
arch/arm/mach-omap2/timer-mpu.c | 34 +
arch/arm/plat-omap/include/mach/entry-macro.S | 28
arch/arm/plat-omap/include/mach/irqs.h|2 +
4 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/timer-mpu.c
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 2ce474a..97b 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -38,6 +38,7 @@
#include asm/mach/time.h
#include mach/dmtimer.h
+#include asm/localtimer.h
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -229,6 +230,9 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
+#ifdef CONFIG_LOCAL_TIMERS
+ twd_base = IO_ADDRESS(OMAP44XX_LOCAL_TWD_BASE);
+#endif
omap_dm_timer_init();
omap2_gp_clockevent_init();
diff --git a/arch/arm/mach-omap2/timer-mpu.c b/arch/arm/mach-omap2/timer-mpu.c
new file mode 100644
index 000..c1a650a
--- /dev/null
+++ b/arch/arm/mach-omap2/timer-mpu.c
@@ -0,0 +1,34 @@
+/*
+ * The MPU local timer source file. In OMAP4, both cortex-a9 cores have
+ * own timer in it's MPU domain. These timers will be driving the
+ * linux kernel SMP tick framework when active. These timers are not
+ * part of the wake up domain.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This file is based on arm realview smp platform file.
+ * Copyright (C) 2002 ARM Ltd.
+ *
+ * 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/init.h
+#include linux/smp.h
+#include linux/clockchips.h
+#include asm/irq.h
+#include asm/smp_twd.h
+#include asm/localtimer.h
+
+/*
+ * Setup the local clock events for a CPU.
+ */
+void __cpuinit local_timer_setup(struct clock_event_device *evt)
+{
+ evt-irq = INT_44XX_LOCALTIMER_IRQ;
+ twd_timer_setup(evt);
+}
+
diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S
b/arch/arm/plat-omap/include/mach/entry-macro.S
index 00f45c0..56426ed 100644
--- a/arch/arm/plat-omap/include/mach/entry-macro.S
+++ b/arch/arm/plat-omap/include/mach/entry-macro.S
@@ -136,6 +136,34 @@
cmpne \irqnr, \tmp
cmpcs \irqnr, \irqnr
.endm
+
+ /* We assume that irqstat (the raw value of the IRQ acknowledge
+* register) is preserved from the macro above.
+* If there is an IPI, we immediately signal end of interrupt
+* on the controller, since this requires the original irqstat
+* value which we won't easily be able to recreate later.
+*/
+
+ .macro test_for_ipi, irqnr, irqstat, base, tmp
+ bic \irqnr, \irqstat, #0x1c00
+ cmp \irqnr, #16
+ it cc
+ strcc \irqstat, [\base, #GIC_CPU_EOI]
+ it cs
+ cmpcs \irqnr, \irqnr
+ .endm
+
+ /* As above, this assumes that irqstat and base are preserved */
+
+ .macro test_for_ltirq, irqnr, irqstat, base, tmp
+ bic \irqnr, \irqstat, #0x1c00
+ mov \tmp, #0
+ cmp \irqnr, #29
+ itt eq
+ moveq \tmp, #1
+ streq \irqstat, [\base, #GIC_CPU_EOI]
+ cmp \tmp, #0
+ .endm
#endif
.macro irq_prio_table
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
b/arch/arm/plat-omap/include/mach/irqs.h
index 5bc331e..e8f84a0 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -427,6 +427,8 @@
#define IRQ_GIC_START 32
+#define INT_44XX_LOCALTIMER_IRQ29
+#define INT_44XX_LOCALWDT_IRQ 30
#define INT_44XX_BENCH_MPU_EMUL(3 + IRQ_GIC_START)
#define INT_44XX_SSM_ABORT_IRQ (6 + IRQ_GIC_START)
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files
This patch adds SMP platform files support for OMAP4430SDP. TI's OMAP4430
SOC is based on ARM Cortex-A9 SMP architecture. It's a dual core SOC
with GIC used for interrupt handling and SCU for cache coherency.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S| 46 +
arch/arm/mach-omap2/omap-smp.c| 178 +
arch/arm/plat-omap/include/mach/smp.h | 51 ++
3 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-headsmp.S
create mode 100644 arch/arm/mach-omap2/omap-smp.c
create mode 100644 arch/arm/plat-omap/include/mach/smp.h
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
new file mode 100644
index 000..4afadba
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -0,0 +1,46 @@
+/*
+ * Secondary CPU startup routine source file.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Interface functions needed for the SMP. This file is based on arm
+ * realview smp platform.
+ * Copyright (c) 2003 ARM Limited.
+ *
+ * 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/linkage.h
+#include linux/init.h
+
+/* Physical address needed since MMU not enabled yet on secondary core */
+#define OMAP4_AUX_CORE_BOOT1_PA0x48281804
+
+ __INIT
+
+/*
+ * OMAP4 specific entry point for secondary CPU to jump from ROM
+ * code. This routine also provides a holding flag into which
+ * secondary core is held until we're ready for it to initialise.
+ * The primary core will update the this flag using a hardware
+ * register AuxCoreBoot1.
+ */
+ENTRY(omap_secondary_startup)
+ mrc p15, 0, r0, c0, c0, 5
+ and r0, r0, #0x0f
+hold: ldr r1, =OMAP4_AUX_CORE_BOOT1_PA@ read from AuxCoreBoot1
+ ldr r2, [r1]
+ cmp r2, r0
+ bne hold
+
+ /*
+* we've been released from the cpu_release,secondary_stack
+* should now contain the SVC stack for this core
+*/
+ b secondary_startup
+
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
new file mode 100644
index 000..e6a871f
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -0,0 +1,178 @@
+/*
+ * OMAP4 SMP source file. It contains platform specific fucntions
+ * needed for the linux smp kernel.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Platform file needed for the OMAP4 SMP. This file is based on arm
+ * realview smp platform.
+ * * Copyright (c) 2002 ARM Limited.
+ *
+ * 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/init.h
+#include linux/device.h
+#include linux/jiffies.h
+#include linux/smp.h
+#include linux/io.h
+
+#include asm/localtimer.h
+#include asm/smp_scu.h
+#include mach/hardware.h
+
+/* Registers used for communicating startup information */
+#define OMAP4_AUXCOREBOOT_REG0 (OMAP44XX_VA_WKUPGEN_BASE + 0x800)
+#define OMAP4_AUXCOREBOOT_REG1 (OMAP44XX_VA_WKUPGEN_BASE + 0x804)
+
+/* SCU base address */
+static void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+
+/*
+ * Use SCU config register to count number of cores
+ */
+static inline unsigned int get_core_count(void)
+{
+ if (scu_base)
+ return scu_get_core_count(scu_base);
+ return 1;
+}
+
+static DEFINE_SPINLOCK(boot_lock);
+
+void __cpuinit platform_secondary_init(unsigned int cpu)
+{
+ trace_hardirqs_off();
+
+ /*
+* If any interrupts are already enabled for the primary
+* core (e.g. timer irq), then they will not have been enabled
+* for us: do so
+*/
+
+ gic_cpu_init(0, IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
+
+ /*
+* Synchronise with the boot thread.
+*/
+ spin_lock(boot_lock);
+ spin_unlock(boot_lock);
+}
+
+int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ unsigned long timeout;
+
+ /*
+* Set synchronisation state between this boot processor
+* and the secondary one
+*/
+ spin_lock(boot_lock);
+
+ /*
+* Update the AuxCoreBoot1 with boot state for secondary core.
+* omap_secondary_startup() routine will hold the secondary core till
+* the AuxCoreBoot1 register is updated with cpu state
+* A barrier is added to ensure that write buffer is drained
+*/
+ __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1);
+ smp_wmb();
+
+ timeout = jiffies + (1 * HZ);
+ while
[PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430
This patch enables SMP on OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/Kconfig |8 arch/arm/mach-omap2/Makefile |4 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 93d63bf..5468a32 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -858,10 +858,10 @@ source kernel/time/Kconfig config SMP bool Symmetric Multi-Processing (EXPERIMENTAL) - depends on EXPERIMENTAL (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP) + depends on EXPERIMENTAL (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP ||ARCH_OMAP4) depends on GENERIC_CLOCKEVENTS select USE_GENERIC_SMP_HELPERS - select HAVE_ARM_SCU if ARCH_REALVIEW + select HAVE_ARM_SCU if (ARCH_REALVIEW || ARCH_OMAP4) help This enables support for systems with more than one CPU. If you have a system with only one CPU, like most personal computers, say N. If @@ -929,9 +929,9 @@ config HOTPLUG_CPU config LOCAL_TIMERS bool Use local timer interrupts - depends on SMP (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP) + depends on SMP (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP || ARCH_OMAP4) default y - select HAVE_ARM_TWD if ARCH_REALVIEW + select HAVE_ARM_TWD if (ARCH_REALVIEW || ARCH_OMAP4) help Enable support for local timers on SMP platforms, rather then the legacy IPI broadcast method. Local timers allows the system diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index a51d811..d9175d4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -14,6 +14,10 @@ obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +# SMP support ONLY available for OMAP4 +obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o +obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o + # Functions loaded to SRAM obj-$(CONFIG_ARCH_OMAP2420)+= sram242x.o obj-$(CONFIG_ARCH_OMAP2430)+= sram243x.o -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: OMAP4: SMP: Update defconfig for OMAP4430
This patch updates omap_4430sdp_defconfig to add SMP and LOCAL_TIMER support for OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 67a3a77..99c5d1a 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -30,7 +30,7 @@ CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # General setup # CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y @@ -104,6 +104,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set @@ -244,6 +245,9 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_LOCAL_TIMERS=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y @@ -695,6 +699,7 @@ CONFIG_HAVE_FUNCTION_TRACER=y # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set +# CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430
This patch updates omap_4430sdp_defconfig to add SMP and LOCAL_TIMER support for OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 67a3a77..99c5d1a 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -30,7 +30,7 @@ CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # General setup # CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y @@ -104,6 +104,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set @@ -244,6 +245,9 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_LOCAL_TIMERS=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y @@ -695,6 +699,7 @@ CONFIG_HAVE_FUNCTION_TRACER=y # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set +# CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RFC] OMAP4: McSPI Register Offset Changes For OMAP_4430SDP
This patch updates McSPI register offset addresses with respect to OMAP4
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/devices.c | 10
drivers/spi/omap2_mcspi.c | 51 --
2 files changed, 41 insertions(+), 20 deletions(-)
Index: omap4_dev/arch/arm/mach-omap2/devices.c
===
--- omap4_dev.orig/arch/arm/mach-omap2/devices.c
+++ omap4_dev/arch/arm/mach-omap2/devices.c
@@ -301,7 +301,8 @@ static struct platform_device omap2_mcsp
},
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
.num_cs = 2,
};
@@ -325,7 +326,7 @@ static struct platform_device omap2_mcsp
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
.num_cs = 1,
};
@@ -353,10 +354,11 @@ static void omap_init_mcspi(void)
{
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi3);
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi4);
#endif
}
Index: omap4_dev/drivers/spi/omap2_mcspi.c
===
--- omap4_dev.orig/drivers/spi/omap2_mcspi.c
+++ omap4_dev/drivers/spi/omap2_mcspi.c
@@ -42,21 +42,38 @@
#define OMAP2_MCSPI_MAX_FREQ 4800
#define OMAP2_MCSPI_REVISION 0x00
-#define OMAP2_MCSPI_SYSCONFIG 0x10
-#define OMAP2_MCSPI_SYSSTATUS 0x14
-#define OMAP2_MCSPI_IRQSTATUS 0x18
-#define OMAP2_MCSPI_IRQENABLE 0x1c
-#define OMAP2_MCSPI_WAKEUPENABLE 0x20
-#define OMAP2_MCSPI_SYST 0x24
-#define OMAP2_MCSPI_MODULCTRL 0x28
+#ifdef CONFIG_ARCH_OMAP4
+#define OMAP2_MCSPI_SYSCONFIG 0x110
+#define OMAP2_MCSPI_SYSSTATUS 0x114
+#define OMAP2_MCSPI_IRQSTATUS 0x118
+#define OMAP2_MCSPI_IRQENABLE 0x11c
+#define OMAP2_MCSPI_WAKEUPENABLE 0x120
+#define OMAP2_MCSPI_SYST 0x124
+#define OMAP2_MCSPI_MODULCTRL 0x128
/* per-channel banks, 0x14 bytes each, first is: */
-#define OMAP2_MCSPI_CHCONF00x2c
-#define OMAP2_MCSPI_CHSTAT00x30
-#define OMAP2_MCSPI_CHCTRL00x34
-#define OMAP2_MCSPI_TX00x38
-#define OMAP2_MCSPI_RX00x3c
+#define OMAP2_MCSPI_CHCONF00x12c
+#define OMAP2_MCSPI_CHSTAT00x130
+#define OMAP2_MCSPI_CHCTRL00x134
+#define OMAP2_MCSPI_TX00x138
+#define OMAP2_MCSPI_RX00x13c
+#else
+#define OMAP2_MCSPI_REVISION0x00
+#define OMAP2_MCSPI_SYSCONFIG 0x10
+#define OMAP2_MCSPI_SYSSTATUS 0x14
+#define OMAP2_MCSPI_IRQSTATUS 0x18
+#define OMAP2_MCSPI_IRQENABLE 0x1c
+#define OMAP2_MCSPI_WAKEUPENABLE0x20
+#define OMAP2_MCSPI_SYST0x24
+#define OMAP2_MCSPI_MODULCTRL 0x28
+/* per-channel banks, 0x14 bytes each, first is: */
+#define OMAP2_MCSPI_CHCONF0 0x2c
+#define OMAP2_MCSPI_CHSTAT0 0x30
+#define OMAP2_MCSPI_CHCTRL0 0x34
+#define OMAP2_MCSPI_TX0 0x38
+#define OMAP2_MCSPI_RX0 0x3c
+#endif
/* per-register bitmasks: */
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 0)
@@ -918,7 +935,8 @@ static u8 __initdata spi2_txdma_id[] = {
OMAP24XX_DMA_SPI2_TX1,
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) ||\
+defined(CONFIG_ARCH_OMAP44XX)
static u8 __initdata spi3_rxdma_id[] = {
OMAP24XX_DMA_SPI3_RX0,
OMAP24XX_DMA_SPI3_RX1,
@@ -930,7 +948,7 @@ static u8 __initdata spi3_txdma_id[] = {
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static u8 __initdata spi4_rxdma_id[] = {
OMAP34XX_DMA_SPI4_RX0,
};
@@ -960,14 +978,15 @@ static int __init omap2_mcspi_probe(stru
txdma_id = spi2_txdma_id;
num_chipselect = 2;
break;
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) ||\
+defined(CONFIG_ARCH_OMAP4)
case 3:
rxdma_id = spi3_rxdma_id;
txdma_id = spi3_txdma_id;
num_chipselect = 2;
break;
Re: [PATCH 1/8] ARM: OMAP3: mmc-twl4030 uses regulator framework, v2
* Daniel Ribeiro drw...@gmail.com [090525 15:47]:
Em Seg, 2009-05-25 às 10:48 -0700, Tony Lindgren escreveu:
+ /* UGLY HACK: workaround regulator framework bugs.
+* When the bootloader leaves a supply active, it's
+* initialized with zero usecount ... and we can't
+* disable it without first disabling it. Until the
+* framework is fixed, we need a workaround like this
+* (which is safe for MMC, but not in general).
+*/
+ if (regulator_is_enabled(hsmmc[i].vcc) 0) {
+ regulator_enable(hsmmc[i].vcc);
+ regulator_disable(hsmmc[i].vcc);
+ }
+ if (hsmmc[i].vcc_aux) {
+ if (regulator_is_enabled(reg) 0) {
+ regulator_enable(reg);
+ regulator_disable(reg);
+ }
+ }
+
This hack would look less ugly on twl4030reg_probe(). There you can
disable the regulator without first enabling it.
Based on Mark's comments let's do that with machine constraints
later on.
(btw, there is a typo in the comment: disable it without first
disabling it).
Thanks, updated patch below.
Tony
From 354cb21a0267230f27d60e1d2b054275274e6dd9 Mon Sep 17 00:00:00 2001
From: David Brownell dbrown...@users.sourceforge.net
Date: Mon, 25 May 2009 11:09:04 -0700
Subject: [PATCH] ARM: OMAP3: mmc-twl4030 uses regulator framework
Decouple the HSMMC glue from the twl4030 as the only
regulator provider, using the regulator framework instead.
This makes the glue's mmc-twl4030 name become a complete
misnomer ... this code could probably all migrate into the
HSMMC driver now.
Tested on 3430SDP (SD and low-voltage MMC) and Beagle (SD),
plus some other boards (including Overo) after they were
converted to set up MMC regulators properly.
Eventually all boards should just associate a regulator with
each MMC controller they use. In some cases (Overo MMC2 and
Pandora MMC3, at least) that would be a fixed-voltage regulator
with no real software control. As a temporary hack (pending
regulator-next updates to make the fixed.c regulator become
usable) there's a new ocr_mask field for those boards.
Patch updated with a fix for disabling vcc_aux by
Adrian Hunter adrian.hun...@nokia.com
Cc: Pierre Ossman drzeus-l...@drzeus.cx
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-omap2/mmc-twl4030.c
index dc40b3e..9756a87 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -16,8 +16,8 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/gpio.h
-#include linux/i2c/twl4030.h
-#include linux/regulator/machine.h
+#include linux/mmc/host.h
+#include linux/regulator/consumer.h
#include mach/hardware.h
#include mach/control.h
@@ -26,31 +26,9 @@
#include mmc-twl4030.h
-#if defined(CONFIG_TWL4030_CORE) \
- (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
-#define LDO_CLR 0x00
-#define VSEL_S2_CLR 0x40
-
-#define VMMC1_DEV_GRP 0x27
-#define VMMC1_CLR 0x00
-#define VMMC1_315V 0x03
-#define VMMC1_300V 0x02
-#define VMMC1_285V 0x01
-#define VMMC1_185V 0x00
-#define VMMC1_DEDICATED 0x2A
-
-#define VMMC2_DEV_GRP 0x2B
-#define VMMC2_CLR 0x40
-#define VMMC2_315V 0x0c
-#define VMMC2_300V 0x0b
-#define VMMC2_285V 0x0a
-#define VMMC2_280V 0x09
-#define VMMC2_260V 0x08
-#define VMMC2_185V 0x06
-#define VMMC2_DEDICATED 0x2E
-
-#define VMMC_DEV_GRP_P1 0x20
+#if defined(CONFIG_REGULATOR) \
+ (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
@@ -59,19 +37,16 @@ static u16 control_devconf1_offset;
static struct twl_mmc_controller {
struct omap_mmc_platform_data *mmc;
- u8 twl_vmmc_dev_grp;
- u8 twl_mmc_dedicated;
- char name[HSMMC_NAME_LEN + 1];
-} hsmmc[OMAP34XX_NR_MMC] = {
- {
- .twl_vmmc_dev_grp = VMMC1_DEV_GRP,
- .twl_mmc_dedicated = VMMC1_DEDICATED,
- },
- {
- .twl_vmmc_dev_grp = VMMC2_DEV_GRP,
- .twl_mmc_dedicated = VMMC2_DEDICATED,
- },
-};
+ /* Vcc == configured supply
+ * Vcc_alt == optional
+ * - MMC1, supply for DAT4..DAT7
+ * - MMC2/MMC2, external level shifter voltage supply, for
+ * chip (SDIO, eMMC, etc) or transceiver (MMC2 only)
+ */
+ struct regulator *vcc;
+ struct regulator *vcc_aux;
+ charname[HSMMC_NAME_LEN + 1];
+} hsmmc[OMAP34XX_NR_MMC];
static int twl_mmc_card_detect(int irq)
{
@@ -117,16 +92,60 @@ static int twl_mmc_late_init(struct device *dev)
int ret = 0;
int i;
- ret = gpio_request(mmc-slots[0].switch_pin, mmc_cd);
- if (ret)
- goto done;
- ret =
Re: [PATCH][RFC] OMAP4: McSPI Register Offset Changes For OMAP_4430SDP
Syed Rafiuddin rafiuddin.s...@ti.com writes:
This patch updates McSPI register offset addresses with respect to OMAP4
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/devices.c | 10
drivers/spi/omap2_mcspi.c | 51
--
2 files changed, 41 insertions(+), 20 deletions(-)
Index: omap4_dev/arch/arm/mach-omap2/devices.c
===
--- omap4_dev.orig/arch/arm/mach-omap2/devices.c
+++ omap4_dev/arch/arm/mach-omap2/devices.c
@@ -301,7 +301,8 @@ static struct platform_device omap2_mcsp
},
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
.num_cs = 2,
};
@@ -325,7 +326,7 @@ static struct platform_device omap2_mcsp
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
.num_cs = 1,
};
@@ -353,10 +354,11 @@ static void omap_init_mcspi(void)
{
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi3);
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi4);
#endif
}
Index: omap4_dev/drivers/spi/omap2_mcspi.c
===
--- omap4_dev.orig/drivers/spi/omap2_mcspi.c
+++ omap4_dev/drivers/spi/omap2_mcspi.c
@@ -42,21 +42,38 @@
#define OMAP2_MCSPI_MAX_FREQ 4800
#define OMAP2_MCSPI_REVISION 0x00
-#define OMAP2_MCSPI_SYSCONFIG0x10
-#define OMAP2_MCSPI_SYSSTATUS0x14
-#define OMAP2_MCSPI_IRQSTATUS0x18
-#define OMAP2_MCSPI_IRQENABLE0x1c
-#define OMAP2_MCSPI_WAKEUPENABLE 0x20
-#define OMAP2_MCSPI_SYST 0x24
-#define OMAP2_MCSPI_MODULCTRL0x28
+#ifdef CONFIG_ARCH_OMAP4
Why do you need an #ifdef for OMAP4. This breaks multi-omap.
+#define OMAP2_MCSPI_SYSCONFIG0x110
+#define OMAP2_MCSPI_SYSSTATUS0x114
+#define OMAP2_MCSPI_IRQSTATUS0x118
+#define OMAP2_MCSPI_IRQENABLE0x11c
+#define OMAP2_MCSPI_WAKEUPENABLE 0x120
+#define OMAP2_MCSPI_SYST 0x124
+#define OMAP2_MCSPI_MODULCTRL0x128
Looking closer, these are all the same register offsets as OMAP2/3,
except you are adding 0x100.
Instead of changing these register defines, you should just be
updating the base address for OMAP4.
The rest of the patch suggests that this is indeed an identical HW
block to what is on OMAP2/3.
Kevin
/* per-channel banks, 0x14 bytes each, first is: */
-#define OMAP2_MCSPI_CHCONF0 0x2c
-#define OMAP2_MCSPI_CHSTAT0 0x30
-#define OMAP2_MCSPI_CHCTRL0 0x34
-#define OMAP2_MCSPI_TX0 0x38
-#define OMAP2_MCSPI_RX0 0x3c
+#define OMAP2_MCSPI_CHCONF0 0x12c
+#define OMAP2_MCSPI_CHSTAT0 0x130
+#define OMAP2_MCSPI_CHCTRL0 0x134
+#define OMAP2_MCSPI_TX0 0x138
+#define OMAP2_MCSPI_RX0 0x13c
+#else
+#define OMAP2_MCSPI_REVISION0x00
+#define OMAP2_MCSPI_SYSCONFIG 0x10
+#define OMAP2_MCSPI_SYSSTATUS 0x14
+#define OMAP2_MCSPI_IRQSTATUS 0x18
+#define OMAP2_MCSPI_IRQENABLE 0x1c
+#define OMAP2_MCSPI_WAKEUPENABLE0x20
+#define OMAP2_MCSPI_SYST0x24
+#define OMAP2_MCSPI_MODULCTRL 0x28
+/* per-channel banks, 0x14 bytes each, first is: */
+#define OMAP2_MCSPI_CHCONF0 0x2c
+#define OMAP2_MCSPI_CHSTAT0 0x30
+#define OMAP2_MCSPI_CHCTRL0 0x34
+#define OMAP2_MCSPI_TX0 0x38
+#define OMAP2_MCSPI_RX0 0x3c
+#endif
/* per-register bitmasks: */
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 0)
@@ -918,7 +935,8 @@ static u8 __initdata spi2_txdma_id[] = {
OMAP24XX_DMA_SPI2_TX1,
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) ||\
+defined(CONFIG_ARCH_OMAP44XX)
static u8 __initdata spi3_rxdma_id[] = {
OMAP24XX_DMA_SPI3_RX0,
OMAP24XX_DMA_SPI3_RX1,
@@ -930,7 +948,7 @@ static u8 __initdata spi3_txdma_id[] = {
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static u8 __initdata
Re: [PATCH 0/4]ARM: OMAP4: SMP: Patch series
* Shilimkar, Santosh santosh.shilim...@ti.com [090527 09:22]: Russell, I have rebased this series on top of your arm-smp patches and my earlier basic omap4 patches. Series is based of kernel.org 2.6.30-rc6 ( commit:1406de8e11eb043681297adf86d6892ff8efc27a). This series have dependency on [1],[2],[3],[4] and latest mach-types The series contains: [PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files [PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 [PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430 [PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430 Regards, Santosh [1]: Russell's arm-smp patch series + one of my patch http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/arm:smp.diff [2]: Tony's : [PATCH 0/5] More header clean-up http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12231.html [3]: Mine [PATCH 0/4] OMAP: Cleanup series. http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html [4]: Mine [PATCH 0/4] ARM: OMPA4: Basic boot patch series based on linux-omap http://lists.arm.linux.org.uk/lurker/message/20090520.125900.9209eb81.en.html Just to summarize, I have pretty much things ready for Russell to merge for all the posted omap stuff. That includes sets 2 + 3 + 4 above, but not this series. That should remove any remaining merge dependencies for this series. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
Hi, Tired with hopeless looking for the correct mcbsp dai format, I took the oposite direciton, trying to break what Mark Underwood had managed to get working. Step by step, I got to exactly the same mcbsp register configuration as used in the reference osk board, reverting all changes that Mark could introduce, and the driver still worked as before. So it looks like playing with mcbsp dai format is not the way to solve the problem. Wednesday 27 May 2009 07:57:27 Peter Ujfalusi wrote: This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec. Now I think I understand better what you mean. However, I don't know any way of configuring the codec except for switching its pin connections from msbcp to modem chip and back. I can find nothing relevant in the original patch that could help. Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct. Wednesday 27 May 2009 08:59:49 Jarkko Nikula wrote: Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. Do you have any way to measure is the codec sending those? Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls. So I am going to restart with checking if the original patch still works with the latest kernel version supporting omap-alsa. Thanks for your help so far. Any hints are still welcome. Cheers, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gumstix Overo Low Power Standby?
Blazej Kot wrote: On May 20, 2009, at 1:55 PM, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Blazej Kot bj...@cornell.edu writes: I have been working with the linux-pm kernel on the Gumstix Overo, seeing how low it's power consumption can go, both during the cpu on and especially while the CPU is suspended. Thus far, I've had some disappointing results, the best I could get is about 500mW while on, and 250mW while suspended (ie by running echo mem /sys/power/ state). I am led to believe that the OMAP processor is capable of much lower power consumption during standby. I am wondering if anybody in the gumstix community is looking into the software support for very-low-power modes on the overo. If so, I am wondering what the lowest power levels are which you have reached during standby are. I have seen this: http://markmail.org/message/ge5hec5f5asp7a67#query:omap%20linux %2080%20ma+page:1+mid:t2erlwweknakm767+state:results Which seems to indicate the lowest power reached is 80mA at 3.3V - 0.264 W, which is about what I'm seeing. Is it really true that the overo draws a quarter of a watt when doing absolutely nothing? There are lots of factors involved. The current OMAP PM branch is focused on minimizing power consumed by the OMAP SoC itself. However, there are lots of other things on-board (audio codecs, regulators, WiFi chipsets etc.) that can consume power that we may not be currently managing in the omap kernel. I don't have an Overo so am not familiar with all the on board peripherals, but you should probably do some experiments where you can put all the on-board devices into low-power/off states and run some experiments as well. In the case of the Beagle results you referenced, I'm pretty sure it is something on board that is drawing the ~80mA and not on-chip. I assume this because setting the OMAP to use OFF-mode in suspend or idle results in the drop of a few mA reflecting an expected drop in power consumed by OMAP itself, but still leaving lots of power consumed. For example, testing today's PM branch on Beagle gives me roughly the same numbers as the post you referenced, but slightly better: - boot idle: 323 mA - screen blank: 216 mA # echo 3 /sys/class/graphics/fb0/blank - suspend (OMAP retention): 75 mA # echo mem /sys/power/state - sleep-while-idle: 75 mA - this same power state as suspend, but happens in idle # echo 1 /sys/power/sleep_while_idle - suspend (OMAP off): 72 mA # echo 1 /sys/power/enable_off_mode # echo 1 /sys/power/voltage_off_while_idle Ultimitately the answer is that more work needs to be done with the using the regulator framework and/or the drivers for the on-chip peripherals to be sure they can be powered off when needed. After digging a little more in the beagle forums, someone has already done the work to confirm that it is indeed board level design and issues that are drawing the rest of the power on Beagle. There's a thread[1] in the beagleboard list about how to get down to 8mW power on Beagle, but it does require hardware changes. This should shed some light on the types of things you'd probably have to do for Overo. Kevin [1] http://groups.google.com/group/beagleboard/browse_thread/thread/197a8ef6b46cc828/6e98db4cbe2cebaa?# Thanks for that, it is an interesting link. I have now reached the new low of around 170mW (at 3.28V), but this is high. I basically used the TWL (PMC) scripts in the linked post, and also turned off the U6 chip on the gumstix, which is the USB PHY layer driver. Also, I noticed that my systems becomes unusable after suspending for more than abut a minute, and it will not wake from sleep. I will try to troubleshot and narrow this down. I think to remember there was some discussion about SDRAM self refresh. Look for thread OMAP3: PM: SDRC: ensure mux of SDRC clock enable pins for self-refresh and http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=4025cfbde3611b14c0d4831a5524e5e061128e30 Just guessing, though. Dirk I am wondering, is there anyone out there working on PM issues on the Gumstix? Perhaps if there are some gumstix company people here they can answer what their status is. I will ask around on the gumstix emailing list also. thanks, Blazej -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gumstix Overo Low Power Standby?
On May 27, 2009, at 2:59 PM, Dirk Behme wrote: Blazej Kot wrote: Thanks for that, it is an interesting link. I have now reached the new low of around 170mW (at 3.28V), but this is high. I basically used the TWL (PMC) scripts in the linked post, and also turned off the U6 chip on the gumstix, which is the USB PHY layer driver. Also, I noticed that my systems becomes unusable after suspending for more than abut a minute, and it will not wake from sleep. I will try to troubleshot and narrow this down. I think to remember there was some discussion about SDRAM self refresh. Look for thread OMAP3: PM: SDRC: ensure mux of SDRC clock enable pins for self-refresh and http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=4025cfbde3611b14c0d4831a5524e5e061128e30 Just guessing, though. Dirk Yes, you are quite right. Kevin Hilman pointed out the patch [1] to me, I just applied it and suspend/resume works for at least 5-10 minutes. I'll try it overnight next :) One small thing is I had to manually insert and include for mach/ mux.c to the top of sdrc.c for it to compile. Thanks! Blazej PS: I'm now down to 141mW in suspend :) I know a lot of the rest must be getting used up in the TPS/TWL PM chip, as it is slightly warm to the touch while the OMAP/RAM stack and the only other chip on the overo, the USB PHY chip, are stone cold to the touch. [1] http://marc.info/?l=linux-omapm=124283570910883w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Touchscreen getting stuck on resume or blanking briefly
Hi, Is there a fix for the touchscreen getting stuck on resume or going back to resume if you touch the screen lightly? I am using a gumstix overo earth (TI OMAP 3503) with the gumstix Palo43 board which has a Samsung LCD display connected, and it uses an ADS7846 touchscreen controller. I have a situation where the screen goes to suspend mode, and if I press the touchscreen once it briefly comes on and goes back to suspend mode. Now two things can happen at this stage. a. if you leave it to go off for just a second, and touch the screen lightly, it will come out of suspend and go back into suspend. So, a brief light touch is not enough to bring it out of suspend mode. b. if you leave it off for more than 15 second, the system briefly comes on, blanks out once, and if you touch it once mode, comes out of suspend. the GPIO Led connected to the heartbeat, beats normally, something like a human heart lub-dub pace. :-) In all this, once in a while, the system doesn't wake up at all a and the touchscreen input doesnt work at all and the system is un-usable, and gets stuck completely. Sometime, if it comes back on, the system heartbeat beats at a much faster pace, after coming out of suspend mode. Has anyone else noticed this type of behavior and is there a patch available to fix it? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Touchscreen getting stuck on resume or blanking briefly
Hi, A quick update, I've been informed that DSS2 does not support off mode. So perhaps if someone has a solution as to why the GPIO Led that is connected to the system heartbeat varies upon resume, it would be one small step towarding fixing these issues. Also, application of the full set of pm patches (191 in total) renders my touchscreen inoperable. Any ideas why that might happen? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: pandora: add support for mode devices
Add support for keypad, GPIO keys and LEDs. Also enable hardware
debounce feature for GPIO keys.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
This patch was somehow left out, so Tony suggested posting it directly here.
arch/arm/mach-omap2/board-omap3pandora.c | 149 ++
1 files changed, 149 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 2ab2497..e32aa23 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -25,6 +25,9 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
+#include linux/leds.h
+#include linux/input.h
+#include linux/gpio_keys.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -36,12 +39,154 @@
#include mach/hardware.h
#include mach/mcspi.h
#include mach/usb.h
+#include mach/keypad.h
#include sdram-micron-mt46h32m32lf-6.h
#include mmc-twl4030.h
#define OMAP3_PANDORA_TS_GPIO 94
+/* hardware debounce: (value + 1) * 31us */
+#define GPIO_DEBOUNCE_TIME 127
+
+static struct gpio_led pandora_gpio_leds[] = {
+ {
+ .name = pandora::sd1,
+ .default_trigger= mmc0,
+ .gpio = 128,
+ }, {
+ .name = pandora::sd2,
+ .default_trigger= mmc1,
+ .gpio = 129,
+ }, {
+ .name = pandora::bluetooth,
+ .gpio = 158,
+ }, {
+ .name = pandora::wifi,
+ .gpio = 159,
+ },
+};
+
+static struct gpio_led_platform_data pandora_gpio_led_data = {
+ .leds = pandora_gpio_leds,
+ .num_leds = ARRAY_SIZE(pandora_gpio_leds),
+};
+
+static struct platform_device pandora_leds_gpio = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = pandora_gpio_led_data,
+ },
+};
+
+#define GPIO_BUTTON(gpio_num, ev_type, ev_code, act_low, descr)\
+{ \
+ .gpio = gpio_num, \
+ .type = ev_type, \
+ .code = ev_code, \
+ .active_low = act_low, \
+ .desc = btn descr, \
+}
+
+#define GPIO_BUTTON_LOW(gpio_num, event_code, description) \
+ GPIO_BUTTON(gpio_num, EV_KEY, event_code, 1, description)
+
+static struct gpio_keys_button pandora_gpio_keys[] = {
+ GPIO_BUTTON_LOW(110,KEY_UP, up),
+ GPIO_BUTTON_LOW(103,KEY_DOWN, down),
+ GPIO_BUTTON_LOW(96, KEY_LEFT, left),
+ GPIO_BUTTON_LOW(98, KEY_RIGHT, right),
+ GPIO_BUTTON_LOW(111,BTN_A, a),
+ GPIO_BUTTON_LOW(106,BTN_B, b),
+ GPIO_BUTTON_LOW(109,BTN_X, x),
+ GPIO_BUTTON_LOW(101,BTN_Y, y),
+ GPIO_BUTTON_LOW(102,BTN_TL, l),
+ GPIO_BUTTON_LOW(97, BTN_TL2,l2),
+ GPIO_BUTTON_LOW(105,BTN_TR, r),
+ GPIO_BUTTON_LOW(107,BTN_TR2,r2),
+ GPIO_BUTTON_LOW(104,KEY_LEFTCTRL, ctrl),
+ GPIO_BUTTON_LOW(99, KEY_MENU, menu),
+ GPIO_BUTTON_LOW(176,KEY_COFFEE, hold),
+ GPIO_BUTTON(100, EV_KEY, KEY_LEFTALT, 0, alt),
+ GPIO_BUTTON(108, EV_SW, SW_LID, 1, lid),
+};
+
+static struct gpio_keys_platform_data pandora_gpio_key_info = {
+ .buttons= pandora_gpio_keys,
+ .nbuttons = ARRAY_SIZE(pandora_gpio_keys),
+};
+
+static struct platform_device pandora_keys_gpio = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = pandora_gpio_key_info,
+ },
+};
+
+static void __init pandora_keys_gpio_init(void)
+{
+ /* set debounce time for GPIO banks 4 and 6 */
+ omap_set_gpio_debounce_time(32 * 3, GPIO_DEBOUNCE_TIME);
+ omap_set_gpio_debounce_time(32 * 5, GPIO_DEBOUNCE_TIME);
+}
+
+static int pandora_keypad_map[] = {
+ /* col, row, code */
+ KEY(0, 0, KEY_9),
+ KEY(0, 1, KEY_0),
+ KEY(0, 2, KEY_BACKSPACE),
+ KEY(0, 3, KEY_O),
+ KEY(0, 4, KEY_P),
+ KEY(0, 5, KEY_K),
+ KEY(0, 6, KEY_L),
+ KEY(0, 7, KEY_ENTER),
+ KEY(1, 0, KEY_8),
+ KEY(1, 1, KEY_7),
+ KEY(1, 2, KEY_6),
+ KEY(1, 3, KEY_5),
+ KEY(1, 4, KEY_4),
+ KEY(1, 5, KEY_3),
+ KEY(1, 6, KEY_2),
+ KEY(1, 7, KEY_1),
+ KEY(2, 0, KEY_I),
+ KEY(2, 1, KEY_U),
+ KEY(2, 2, KEY_Y),
+ KEY(2, 3, KEY_T),
+ KEY(2, 4, KEY_R),
+ KEY(2, 5, KEY_E),
+
Re: [PATCH] ARM: OMAP3: pandora: add support for mode devices
* Grazvydas Ignotas nota...@gmail.com [090527 12:48]:
Add support for keypad, GPIO keys and LEDs. Also enable hardware
debounce feature for GPIO keys.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
This patch was somehow left out, so Tony suggested posting it directly here.
Thanks, I've added this patch to my queue.
Tony
arch/arm/mach-omap2/board-omap3pandora.c | 149
++
1 files changed, 149 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 2ab2497..e32aa23 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -25,6 +25,9 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
+#include linux/leds.h
+#include linux/input.h
+#include linux/gpio_keys.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -36,12 +39,154 @@
#include mach/hardware.h
#include mach/mcspi.h
#include mach/usb.h
+#include mach/keypad.h
#include sdram-micron-mt46h32m32lf-6.h
#include mmc-twl4030.h
#define OMAP3_PANDORA_TS_GPIO94
+/* hardware debounce: (value + 1) * 31us */
+#define GPIO_DEBOUNCE_TIME 127
+
+static struct gpio_led pandora_gpio_leds[] = {
+ {
+ .name = pandora::sd1,
+ .default_trigger= mmc0,
+ .gpio = 128,
+ }, {
+ .name = pandora::sd2,
+ .default_trigger= mmc1,
+ .gpio = 129,
+ }, {
+ .name = pandora::bluetooth,
+ .gpio = 158,
+ }, {
+ .name = pandora::wifi,
+ .gpio = 159,
+ },
+};
+
+static struct gpio_led_platform_data pandora_gpio_led_data = {
+ .leds = pandora_gpio_leds,
+ .num_leds = ARRAY_SIZE(pandora_gpio_leds),
+};
+
+static struct platform_device pandora_leds_gpio = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = pandora_gpio_led_data,
+ },
+};
+
+#define GPIO_BUTTON(gpio_num, ev_type, ev_code, act_low, descr) \
+{\
+ .gpio = gpio_num, \
+ .type = ev_type, \
+ .code = ev_code, \
+ .active_low = act_low, \
+ .desc = btn descr, \
+}
+
+#define GPIO_BUTTON_LOW(gpio_num, event_code, description) \
+ GPIO_BUTTON(gpio_num, EV_KEY, event_code, 1, description)
+
+static struct gpio_keys_button pandora_gpio_keys[] = {
+ GPIO_BUTTON_LOW(110,KEY_UP, up),
+ GPIO_BUTTON_LOW(103,KEY_DOWN, down),
+ GPIO_BUTTON_LOW(96, KEY_LEFT, left),
+ GPIO_BUTTON_LOW(98, KEY_RIGHT, right),
+ GPIO_BUTTON_LOW(111,BTN_A, a),
+ GPIO_BUTTON_LOW(106,BTN_B, b),
+ GPIO_BUTTON_LOW(109,BTN_X, x),
+ GPIO_BUTTON_LOW(101,BTN_Y, y),
+ GPIO_BUTTON_LOW(102,BTN_TL, l),
+ GPIO_BUTTON_LOW(97, BTN_TL2,l2),
+ GPIO_BUTTON_LOW(105,BTN_TR, r),
+ GPIO_BUTTON_LOW(107,BTN_TR2,r2),
+ GPIO_BUTTON_LOW(104,KEY_LEFTCTRL, ctrl),
+ GPIO_BUTTON_LOW(99, KEY_MENU, menu),
+ GPIO_BUTTON_LOW(176,KEY_COFFEE, hold),
+ GPIO_BUTTON(100, EV_KEY, KEY_LEFTALT, 0, alt),
+ GPIO_BUTTON(108, EV_SW, SW_LID, 1, lid),
+};
+
+static struct gpio_keys_platform_data pandora_gpio_key_info = {
+ .buttons= pandora_gpio_keys,
+ .nbuttons = ARRAY_SIZE(pandora_gpio_keys),
+};
+
+static struct platform_device pandora_keys_gpio = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = pandora_gpio_key_info,
+ },
+};
+
+static void __init pandora_keys_gpio_init(void)
+{
+ /* set debounce time for GPIO banks 4 and 6 */
+ omap_set_gpio_debounce_time(32 * 3, GPIO_DEBOUNCE_TIME);
+ omap_set_gpio_debounce_time(32 * 5, GPIO_DEBOUNCE_TIME);
+}
+
+static int pandora_keypad_map[] = {
+ /* col, row, code */
+ KEY(0, 0, KEY_9),
+ KEY(0, 1, KEY_0),
+ KEY(0, 2, KEY_BACKSPACE),
+ KEY(0, 3, KEY_O),
+ KEY(0, 4, KEY_P),
+ KEY(0, 5, KEY_K),
+ KEY(0, 6, KEY_L),
+ KEY(0, 7, KEY_ENTER),
+ KEY(1, 0, KEY_8),
+ KEY(1, 1, KEY_7),
+ KEY(1, 2, KEY_6),
+ KEY(1, 3, KEY_5),
+ KEY(1, 4, KEY_4),
+ KEY(1, 5, KEY_3),
+ KEY(1, 6, KEY_2),
+ KEY(1, 7, KEY_1),
+ KEY(2, 0, KEY_I),
+ KEY(2, 1, KEY_U),
+ KEY(2, 2,
[PATCH] OMAP1: PM: update and decouple from OMAP2/3 PM core
Update OMAP1-specific PM infrastructure. This is a sync of what is in
linux-omap for OMAP1.
This mostly de-couples OMAP1 PM from OMAP2/3 PM and renames things
accordingly, and removes omap2/3 specific code from OMAP1 specific
headers.
Original OMAP1 decoupling patch for OMAP PM branch by Paul Walmsley.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap1/pm.c | 11 +++--
arch/arm/mach-omap1/pm.h | 85 +-
arch/arm/mach-omap1/serial.c |3 -
arch/arm/mach-omap1/sleep.S |2 +-
4 files changed, 17 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 9774c1f..5218943 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -53,11 +53,12 @@
#include mach/clock.h
#include mach/sram.h
#include mach/tc.h
-#include mach/pm.h
#include mach/mux.h
#include mach/dma.h
#include mach/dmtimer.h
+#include pm.h
+
static unsigned int arm_sleep_save[ARM_SLEEP_SAVE_SIZE];
static unsigned short dsp_sleep_save[DSP_SLEEP_SAVE_SIZE];
static unsigned short ulpd_sleep_save[ULPD_SLEEP_SAVE_SIZE];
@@ -101,7 +102,7 @@ static void (*omap_sram_suspend)(unsigned long r0, unsigned
long r1) = NULL;
* going idle we continue to do idle even if we get
* a clock tick interrupt . .
*/
-void omap_pm_idle(void)
+void omap1_pm_idle(void)
{
extern __u32 arm_idlect1_mask;
__u32 use_idlect1 = arm_idlect1_mask;
@@ -222,7 +223,7 @@ static void omap_pm_wakeup_setup(void)
#define EN_APICK 6 /* ARM_IDLECT2 */
#define DSP_EN 1 /* ARM_RSTCT1 */
-void omap_pm_suspend(void)
+void omap1_pm_suspend(void)
{
unsigned long arg0 = 0, arg1 = 0;
@@ -610,7 +611,7 @@ static int omap_pm_enter(suspend_state_t state)
{
case PM_SUSPEND_STANDBY:
case PM_SUSPEND_MEM:
- omap_pm_suspend();
+ omap1_pm_suspend();
break;
default:
return -EINVAL;
@@ -683,7 +684,7 @@ static int __init omap_pm_init(void)
return -ENODEV;
}
- pm_idle = omap_pm_idle;
+ pm_idle = omap1_pm_idle;
if (cpu_is_omap730())
setup_irq(INT_730_WAKE_UP_REQ, omap_wakeup_irq);
diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
index ce6ee79..9ed5e2c 100644
--- a/arch/arm/mach-omap1/pm.h
+++ b/arch/arm/mach-omap1/pm.h
@@ -1,7 +1,7 @@
/*
- * arch/arm/plat-omap/include/mach/pm.h
+ * arch/arm/mach-omap1/pm.h
*
- * Header file for OMAP Power Management Routines
+ * Header file for OMAP1 Power Management Routines
*
* Author: MontaVista Software, Inc.
*supp...@mvista.com
@@ -31,8 +31,8 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#ifndef __ASM_ARCH_OMAP_PM_H
-#define __ASM_ARCH_OMAP_PM_H
+#ifndef __ARCH_ARM_MACH_OMAP1_PM_H
+#define __ARCH_ARM_MACH_OMAP1_PM_H
/*
*
@@ -106,8 +106,7 @@
#if !defined(CONFIG_ARCH_OMAP730) \
!defined(CONFIG_ARCH_OMAP15XX) \
- !defined(CONFIG_ARCH_OMAP16XX) \
- !defined(CONFIG_ARCH_OMAP24XX)
+ !defined(CONFIG_ARCH_OMAP16XX)
#warning Power management for this processor not implemented yet
#endif
@@ -115,29 +114,27 @@
#include linux/clk.h
+extern struct kset power_subsys;
+
extern void prevent_idle_sleep(void);
extern void allow_idle_sleep(void);
-extern void omap_pm_idle(void);
-extern void omap_pm_suspend(void);
+extern void omap1_pm_idle(void);
+extern void omap1_pm_suspend(void);
+
extern void omap730_cpu_suspend(unsigned short, unsigned short);
extern void omap1510_cpu_suspend(unsigned short, unsigned short);
extern void omap1610_cpu_suspend(unsigned short, unsigned short);
-extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
- void __iomem *sdrc_power);
extern void omap730_idle_loop_suspend(void);
extern void omap1510_idle_loop_suspend(void);
extern void omap1610_idle_loop_suspend(void);
-extern void omap24xx_idle_loop_suspend(void);
extern unsigned int omap730_cpu_suspend_sz;
extern unsigned int omap1510_cpu_suspend_sz;
extern unsigned int omap1610_cpu_suspend_sz;
-extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap730_idle_loop_suspend_sz;
extern unsigned int omap1510_idle_loop_suspend_sz;
extern unsigned int omap1610_idle_loop_suspend_sz;
-extern unsigned int omap24xx_idle_loop_suspend_sz;
#ifdef CONFIG_OMAP_SERIAL_WAKE
extern void omap_serial_wake_trigger(int enable);
@@ -170,10 +167,6 @@ extern void omap_serial_wake_trigger(int enable);
#define MPUI1610_RESTORE(x)
omap_writel((mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_##x]), (x))
#define MPUI1610_SHOW(x) mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_##x]
-#define OMAP24XX_SAVE(x) omap24xx_sleep_save[OMAP24XX_SLEEP_SAVE_##x] = x
-#define OMAP24XX_RESTORE(x) x =
Re: [PATCH] OMAP1: PM: update and decouple from OMAP2/3 PM core
* Kevin Hilman khil...@deeprootsystems.com [090527 16:35]:
Update OMAP1-specific PM infrastructure. This is a sync of what is in
linux-omap for OMAP1.
This mostly de-couples OMAP1 PM from OMAP2/3 PM and renames things
accordingly, and removes omap2/3 specific code from OMAP1 specific
headers.
Original OMAP1 decoupling patch for OMAP PM branch by Paul Walmsley.
Thanks, I've pulled your updated pm-upstream with this into omap
for-next branch.
Tony
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap1/pm.c | 11 +++--
arch/arm/mach-omap1/pm.h | 85
+-
arch/arm/mach-omap1/serial.c |3 -
arch/arm/mach-omap1/sleep.S |2 +-
4 files changed, 17 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 9774c1f..5218943 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -53,11 +53,12 @@
#include mach/clock.h
#include mach/sram.h
#include mach/tc.h
-#include mach/pm.h
#include mach/mux.h
#include mach/dma.h
#include mach/dmtimer.h
+#include pm.h
+
static unsigned int arm_sleep_save[ARM_SLEEP_SAVE_SIZE];
static unsigned short dsp_sleep_save[DSP_SLEEP_SAVE_SIZE];
static unsigned short ulpd_sleep_save[ULPD_SLEEP_SAVE_SIZE];
@@ -101,7 +102,7 @@ static void (*omap_sram_suspend)(unsigned long r0,
unsigned long r1) = NULL;
* going idle we continue to do idle even if we get
* a clock tick interrupt . .
*/
-void omap_pm_idle(void)
+void omap1_pm_idle(void)
{
extern __u32 arm_idlect1_mask;
__u32 use_idlect1 = arm_idlect1_mask;
@@ -222,7 +223,7 @@ static void omap_pm_wakeup_setup(void)
#define EN_APICK 6 /* ARM_IDLECT2 */
#define DSP_EN 1 /* ARM_RSTCT1 */
-void omap_pm_suspend(void)
+void omap1_pm_suspend(void)
{
unsigned long arg0 = 0, arg1 = 0;
@@ -610,7 +611,7 @@ static int omap_pm_enter(suspend_state_t state)
{
case PM_SUSPEND_STANDBY:
case PM_SUSPEND_MEM:
- omap_pm_suspend();
+ omap1_pm_suspend();
break;
default:
return -EINVAL;
@@ -683,7 +684,7 @@ static int __init omap_pm_init(void)
return -ENODEV;
}
- pm_idle = omap_pm_idle;
+ pm_idle = omap1_pm_idle;
if (cpu_is_omap730())
setup_irq(INT_730_WAKE_UP_REQ, omap_wakeup_irq);
diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
index ce6ee79..9ed5e2c 100644
--- a/arch/arm/mach-omap1/pm.h
+++ b/arch/arm/mach-omap1/pm.h
@@ -1,7 +1,7 @@
/*
- * arch/arm/plat-omap/include/mach/pm.h
+ * arch/arm/mach-omap1/pm.h
*
- * Header file for OMAP Power Management Routines
+ * Header file for OMAP1 Power Management Routines
*
* Author: MontaVista Software, Inc.
* supp...@mvista.com
@@ -31,8 +31,8 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#ifndef __ASM_ARCH_OMAP_PM_H
-#define __ASM_ARCH_OMAP_PM_H
+#ifndef __ARCH_ARM_MACH_OMAP1_PM_H
+#define __ARCH_ARM_MACH_OMAP1_PM_H
/*
*
@@ -106,8 +106,7 @@
#if !defined(CONFIG_ARCH_OMAP730) \
!defined(CONFIG_ARCH_OMAP15XX) \
- !defined(CONFIG_ARCH_OMAP16XX) \
- !defined(CONFIG_ARCH_OMAP24XX)
+ !defined(CONFIG_ARCH_OMAP16XX)
#warning Power management for this processor not implemented yet
#endif
@@ -115,29 +114,27 @@
#include linux/clk.h
+extern struct kset power_subsys;
+
extern void prevent_idle_sleep(void);
extern void allow_idle_sleep(void);
-extern void omap_pm_idle(void);
-extern void omap_pm_suspend(void);
+extern void omap1_pm_idle(void);
+extern void omap1_pm_suspend(void);
+
extern void omap730_cpu_suspend(unsigned short, unsigned short);
extern void omap1510_cpu_suspend(unsigned short, unsigned short);
extern void omap1610_cpu_suspend(unsigned short, unsigned short);
-extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
- void __iomem *sdrc_power);
extern void omap730_idle_loop_suspend(void);
extern void omap1510_idle_loop_suspend(void);
extern void omap1610_idle_loop_suspend(void);
-extern void omap24xx_idle_loop_suspend(void);
extern unsigned int omap730_cpu_suspend_sz;
extern unsigned int omap1510_cpu_suspend_sz;
extern unsigned int omap1610_cpu_suspend_sz;
-extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap730_idle_loop_suspend_sz;
extern unsigned int omap1510_idle_loop_suspend_sz;
extern unsigned int omap1610_idle_loop_suspend_sz;
-extern unsigned int omap24xx_idle_loop_suspend_sz;
#ifdef CONFIG_OMAP_SERIAL_WAKE
extern void omap_serial_wake_trigger(int enable);
@@ -170,10 +167,6 @@ extern void omap_serial_wake_trigger(int enable);
#define
Re: [PATCH 0/8] omap3 board updates for merge window after 2.6.30
* Tony Lindgren t...@atomide.com [090525 10:47]: Hi all, Here are some omap3 board specific patches for the upcoming merge window. It adds two new boards, and starts converting MMC to use the regulator framework. Merged this series into omap for-next branch. Regards, Tony --- Adrian Hunter (1): ARM: OMAP3: RX51: Connect VAUX3 to MMC2 David Brownell (2): ARM: OMAP3: Initialize regulators for Beagle and Overo ARM: OMAP3: mmc-twl4030 uses regulator framework Grazvydas Ignotas (1): ARM: OMAP3: pandora: setup regulator framework for MMC Syed Mohammed Khasim (2): ARM: OMAP3: Add omap3 EVM defconfig ARM: OMAP3: Add omap3 EVM support Vikram Pandita (2): ARM: OMAP3: Defconfig for Zoom2 board ARM: OMAP3: Add support for OMAP3 Zoom2 board arch/arm/configs/omap3_evm_defconfig | 1528 ++ arch/arm/configs/omap_zoom2_defconfig| 1211 + arch/arm/mach-omap2/Kconfig |8 arch/arm/mach-omap2/Makefile |6 arch/arm/mach-omap2/board-omap3beagle.c | 104 ++ arch/arm/mach-omap2/board-omap3evm.c | 329 ++ arch/arm/mach-omap2/board-omap3pandora.c | 45 + arch/arm/mach-omap2/board-overo.c| 76 + arch/arm/mach-omap2/board-rx51-peripherals.c | 30 - arch/arm/mach-omap2/board-zoom-debugboard.c | 160 +++ arch/arm/mach-omap2/board-zoom2.c| 110 ++ arch/arm/mach-omap2/mmc-twl4030.c| 280 ++--- arch/arm/mach-omap2/mmc-twl4030.h|3 drivers/mmc/host/omap_hsmmc.c|6 14 files changed, 3693 insertions(+), 203 deletions(-) create mode 100644 arch/arm/configs/omap3_evm_defconfig create mode 100644 arch/arm/configs/omap_zoom2_defconfig create mode 100644 arch/arm/mach-omap2/board-omap3evm.c create mode 100644 arch/arm/mach-omap2/board-zoom-debugboard.c create mode 100644 arch/arm/mach-omap2/board-zoom2.c -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git pull request for omap patches for merge window after 2.6.30
Hi Russell, Assuming you have had a chance to look at all the patches posted, please pull them from the request below. Will refresh the patches as needed if you have more comments. I've merged all the omap patches, except Santosh' omap4 SMP set, and Paul's second clock updates. This should remove any dependencies for Santosh' SMP series. Merging this will cause a trivial merge conflict in arch/arm/Makefile with the omap4 line, so let me know if you want me to rebase on something else other than v2.6.30-rc7. Regards, Tony Summary of patch sets merged: [PATCH 0/5] More omap header clean-up for the merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/19727 [PATCH 0/4] OMAP: Cleanup series http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html [PATCH 00/10] OMAP clock/SDRC patches on v2.6.30-rc5 http://article.gmane.org/gmane.linux.ports.arm.omap/19589 [PATCH v2 00/13] OMAP2/3: PM sync-up http://article.gmane.org/gmane.linux.ports.arm.omap/20073 [PATCH 00/10] Omap updates for merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/19979 [PATCH 0/6] Updates for omap3 for merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/20123 PATCH 0/8] omap3 board updates for merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/20188 [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12819.html Pull request: The following changes since commit 59a3759d0fe8d969888c741bb33f4946e4d3750d: Linus Torvalds (1): Linux 2.6.30-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git for-next Adrian Hunter (1): ARM: OMAP3: RX51: Connect VAUX3 to MMC2 Artem Bityutskiy (1): OMAP3 clock: lessen amount of noisy messages David Brownell (2): ARM: OMAP3: mmc-twl4030 uses regulator framework ARM: OMAP3: Initialize regulators for Beagle and Overo Eero Nurkkala (1): ARM: OMAP: McBSP: Fix legacy interrupts to clear their status Grazvydas Ignotas (2): ARM: OMAP3: pandora: setup regulator framework for MMC ARM: OMAP3: pandora: add support for mode devices Imre Deak (2): ARM: OMAP2: 2430SDP: Add FB support to board file ARM: OMAP3: ZOOM MDK: Add FB support to board file Jarkko Nikula (1): ARM: OMAP: Update contact address of I2C registration helper Jouni Hogander (2): OMAP: Add new function to check wether there is irq pending OMAP: UART: Add sysfs interface for adjusting UART sleep timeout Juha Yrjola (1): ARM: OMAP2/3: Add generic onenand support when connected to GPMC Kevin Hilman (11): Revert ARM: OMAP: Mask interrupts when disabling interrupts, v2 OMAP2/3: PM: push core PM code from linux-omap OMAP3: PM: Force IVA2 into idle during bootup OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X OMAP3: PM: UART: disable clocks when idle and off-mode support OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init OMAP3: PM: D2D clockdomain supports SW supervised transitions OMAP3: PM: Ensure PRCM interrupts are cleared at boot OMAP3: PM: Clear pending PRCM reset flags on init OMAP3: PM: prevent module wakeups from waking IVA2 OMAP1: PM: update and decouple from OMAP2/3 PM core Mans Rullgard (1): ARM: OMAP: Increase VMALLOC_END to allow 256MB RAM Paul Walmsley (11): OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpll OMAP3 clock: add interconnect barriers to CORE DPLL M2 change OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency change OMAP3 SDRC: initialize SDRC_POWER at boot OMAP3 SRAM: renumber registers to make space for argument passing OMAP3 clock: only unlock SDRC DLL if SDRC clk 83MHz OMAP3 clock: use pr_debug() rather than pr_info() in some clock change code OMAP2xxx clock: rename clk_init_one() to clk_preinit() ARM: OMAP3: SDRC: add timing data for Micron MT46H32M32LF-6, v2 ARM: OMAP3: SDRC: add timing data for Qimonda HYB18M512160AF-6 Peter 'p2' De Schrijver (1): OMAP3: PM: Ensure MUSB block can idle when driver not loaded Santosh Shilimkar (11): ARM: OMAP: Remove unwanted type casts and fix the compiler warning. ARM: OMAP: Remove useless omap_sram_error function. ARM: OMAP: Remove unnecessary omap2_globals. ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain(), v2 ARM: OMAP: Remove unwanted type casts and fix the compiler warning. ARM: OMAP: Remove useless omap_sram_error function. ARM: OMAP: Remove unnecessary omap2_globals. ARM: OMAP4: Add minimal support for omap4 ARM: OMAP4: Clock stubs since CLKDEV not in yet. ARM: OMAP4: Add support for 4430 SDP ARM: OMAP4: Add defconfig for 4430 SDP
RE: [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, May 28, 2009 5:07 AM To: Shilimkar, Santosh Cc: li...@arm.linux.org.uk; linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org Subject: Re: [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4 * Santosh Shilimkar santosh.shilim...@ti.com [090520 05:59]: This patch adds the support for OMAP4. The platform and machine specific headers and sources updated for OMAP4430 SDP platform. OMAP4430 is Texas Instrument's SOC based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. I've added these to omap for-next branch. Thanks Tony !! Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: manual merge of the omap tree with the arm tree
Hi all, Today's linux-next merge of the omap tree got a conflict in arch/arm/Makefile between commit b4175b89921fefb2f352472fa6dccb0fc4fb37d9 ([ARM] sort machine- and plat- by CONFIG* name) from the arm tree and commit 68394eae0fc4e801fc2ae33055b24a9754669a7b (ARM: OMAP4: Add support for 4430 SDP) from the omap tree. I fixed it up (see below) and can carry the fix as necessary. -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/Makefile index e97c21b,676d10d..000 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@@ -99,72 -99,65 +99,73 @@@ CHECKFLAGS += -D__arm_ #Default value head-y:= arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o textofs-y := 0x8000 - - machine-$(CONFIG_ARCH_RPC) := rpc - machine-$(CONFIG_ARCH_EBSA110) := ebsa110 - machine-$(CONFIG_FOOTBRIDGE):= footbridge - machine-$(CONFIG_ARCH_SHARK):= shark - machine-$(CONFIG_ARCH_SA1100) := sa1100 -ifeq ($(CONFIG_ARCH_SA1100),y) +textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000 # SA DMA bug: we don't want the kernel to live in precious DMA-able memory - textofs-$(CONFIG_SA):= 0x00208000 +ifeq ($(CONFIG_ARCH_SA1100),y) +textofs-$(CONFIG_SA) := 0x00208000 endif - machine-$(CONFIG_ARCH_PXA) := pxa - machine-$(CONFIG_ARCH_MMP) := mmp -plat-$(CONFIG_PLAT_PXA) := pxa - machine-$(CONFIG_ARCH_L7200):= l7200 - machine-$(CONFIG_ARCH_INTEGRATOR) := integrator - machine-$(CONFIG_ARCH_GEMINI) := gemini - textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000 - machine-$(CONFIG_ARCH_CLPS711X) := clps711x - machine-$(CONFIG_ARCH_IOP32X) := iop32x - machine-$(CONFIG_ARCH_IOP33X) := iop33x - machine-$(CONFIG_ARCH_IOP13XX) := iop13xx -plat-$(CONFIG_PLAT_IOP) := iop - machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx - machine-$(CONFIG_ARCH_IXP2000):= ixp2000 - machine-$(CONFIG_ARCH_IXP23XX):= ixp23xx - machine-$(CONFIG_ARCH_OMAP1):= omap1 - machine-$(CONFIG_ARCH_OMAP2):= omap2 - machine-$(CONFIG_ARCH_OMAP3):= omap2 - machine-$(CONFIG_ARCH_OMAP4):= omap2 -plat-$(CONFIG_ARCH_OMAP) := omap - machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443 - machine-$(CONFIG_ARCH_S3C24A0) := s3c24a0 -plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx s3c - machine-$(CONFIG_ARCH_S3C64XX) := s3c6400 s3c6410 -plat-$(CONFIG_PLAT_S3C64XX) := s3c64xx s3c - machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x - machine-$(CONFIG_ARCH_VERSATILE) := versatile - machine-$(CONFIG_ARCH_IMX) := imx - machine-$(CONFIG_ARCH_H720X):= h720x - machine-$(CONFIG_ARCH_AAEC2000) := aaec2000 - machine-$(CONFIG_ARCH_REALVIEW) := realview - machine-$(CONFIG_ARCH_AT91) := at91 - machine-$(CONFIG_ARCH_EP93XX) := ep93xx - machine-$(CONFIG_ARCH_PNX4008) := pnx4008 - machine-$(CONFIG_ARCH_NETX) := netx - machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx - machine-$(CONFIG_ARCH_DAVINCI) := davinci - machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood - machine-$(CONFIG_ARCH_KS8695) := ks8695 -plat-$(CONFIG_ARCH_MXC) := mxc - machine-$(CONFIG_ARCH_MX2) := mx2 - machine-$(CONFIG_ARCH_MX3) := mx3 - machine-$(CONFIG_ARCH_MX1) := mx1 - machine-$(CONFIG_ARCH_ORION5X) := orion5x -plat-$(CONFIG_PLAT_ORION):= orion - machine-$(CONFIG_ARCH_MSM) := msm - machine-$(CONFIG_ARCH_LOKI) := loki - machine-$(CONFIG_ARCH_MV78XX0):= mv78xx0 - machine-$(CONFIG_ARCH_W90X900):= w90x900 + +# Machine directory name. This list is sorted alphanumerically +# by CONFIG_* macro name. +machine-$(CONFIG_ARCH_AAEC2000) := aaec2000 +machine-$(CONFIG_ARCH_AT91) := at91 +machine-$(CONFIG_ARCH_CLPS711X) := clps711x +machine-$(CONFIG_ARCH_DAVINCI):= davinci +machine-$(CONFIG_ARCH_EBSA110):= ebsa110 +machine-$(CONFIG_ARCH_EP93XX) := ep93xx +machine-$(CONFIG_ARCH_GEMINI) := gemini +machine-$(CONFIG_ARCH_H720X) := h720x +machine-$(CONFIG_ARCH_INTEGRATOR) := integrator +machine-$(CONFIG_ARCH_IOP13XX):= iop13xx +machine-$(CONFIG_ARCH_IOP32X) := iop32x +machine-$(CONFIG_ARCH_IOP33X) := iop33x +machine-$(CONFIG_ARCH_IXP2000):= ixp2000 +machine-$(CONFIG_ARCH_IXP23XX):= ixp23xx +machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx +machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood +machine-$(CONFIG_ARCH_KS8695) := ks8695 +machine-$(CONFIG_ARCH_L7200) := l7200 +machine-$(CONFIG_ARCH_LH7A40X):= lh7a40x +machine-$(CONFIG_ARCH_LOKI) := loki +machine-$(CONFIG_ARCH_MMP):= mmp +machine-$(CONFIG_ARCH_MSM):= msm +machine-$(CONFIG_ARCH_MV78XX0)
