Re: [PATCH 1/8] omap_hsmmc: move gpio and regulator control from board file
ext Tony Lindgren wrote:
* Adrian Hunter adrian.hun...@nokia.com [100113 03:38]:
From c2ed3074a73fc13d088c53193af546c01d1061b1 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Mon, 4 Jan 2010 13:44:36 +0200
Subject: [PATCH] omap_hsmmc: move gpio and regulator control from board file
This patch moves the setup code for GPIO's and Voltage
Regulators from the board file mmc-twl4030.c to the
driver omap_hsmmc.c.
Moving GPIO code to the driver makes the board initialisation
code independent of when GPIO's are defined. That makes the
board initialisation now entirely independent of its original
twl4030 roots.
Moving Voltage Regulator code to the driver allows for further
development of regulator support in the core MMC code. It also
permits the MMC core to be compiled as a module, because the
board code no longer calls MMC core functions.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/configs/rx51_defconfig |4 +-
arch/arm/mach-omap2/control.c |2 +
arch/arm/mach-omap2/mmc-twl4030.c | 419 +
arch/arm/mach-omap2/mmc-twl4030.h |4 +-
arch/arm/plat-omap/include/plat/mmc.h |2 +-
drivers/mmc/host/omap_hsmmc.c | 417 +++-
6 files changed, 419 insertions(+), 429 deletions(-)
snip
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index cdd1f35..f3e31dc 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -162,6 +162,7 @@ u32 omap_ctrl_readl(u16 offset)
{
return __raw_readl(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readl);
void omap_ctrl_writeb(u8 val, u16 offset)
{
@@ -177,6 +178,7 @@ void omap_ctrl_writel(u32 val, u16 offset)
{
__raw_writel(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writel);
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
/*
NAK, we don't want to export omap_ctrl_read/write. That will
lead into a horrible mess again of all the drivers tinkering
with the omap hardware registers directly.
OK
All code like that needs to stay under mach-omap2. This same
mmc controller could in theory be used on other hardware too,
not just omaps. The ctrl registers are omap specific, not
mmc controller specific.
Regards,
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: [PATCH 1/8] omap_hsmmc: move gpio and regulator control from board file
ext Madhusudhan wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Wednesday, January 13, 2010 5:40 AM
To: Tony Lindgren
Cc: linux-mmc Mailing List; Adrian Hunter; Andrew Morton; linux-omap
Mailing List; Madhusudhan Chikkature
Subject: [PATCH 1/8] omap_hsmmc: move gpio and regulator control from
board file
From c2ed3074a73fc13d088c53193af546c01d1061b1 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Mon, 4 Jan 2010 13:44:36 +0200
Subject: [PATCH] omap_hsmmc: move gpio and regulator control from board
file
This patch moves the setup code for GPIO's and Voltage
Regulators from the board file mmc-twl4030.c to the
driver omap_hsmmc.c.
Moving GPIO code to the driver makes the board initialisation
code independent of when GPIO's are defined. That makes the
board initialisation now entirely independent of its original
twl4030 roots.
Moving Voltage Regulator code to the driver allows for further
development of regulator support in the core MMC code. It also
permits the MMC core to be compiled as a module, because the
board code no longer calls MMC core functions.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/configs/rx51_defconfig |4 +-
arch/arm/mach-omap2/control.c |2 +
arch/arm/mach-omap2/mmc-twl4030.c | 419 +---
-
arch/arm/mach-omap2/mmc-twl4030.h |4 +-
arch/arm/plat-omap/include/plat/mmc.h |2 +-
drivers/mmc/host/omap_hsmmc.c | 417
+++-
6 files changed, 419 insertions(+), 429 deletions(-)
diff --git a/arch/arm/configs/rx51_defconfig
b/arch/arm/configs/rx51_defconfig
index b6eeebb..426ae94 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -1354,7 +1354,7 @@ CONFIG_USB_OTG_UTILS=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_ISP1301_OMAP is not set
CONFIG_TWL4030_USB=y
-CONFIG_MMC=y
+CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
@@ -1362,7 +1362,7 @@ CONFIG_MMC=y
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
-CONFIG_MMC_BLOCK_BOUNCE=y
+# CONFIG_MMC_BLOCK_BOUNCE is not set
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index cdd1f35..f3e31dc 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -162,6 +162,7 @@ u32 omap_ctrl_readl(u16 offset)
{
return __raw_readl(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readl);
void omap_ctrl_writeb(u8 val, u16 offset)
{
@@ -177,6 +178,7 @@ void omap_ctrl_writel(u32 val, u16 offset)
{
__raw_writel(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writel);
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
/*
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-omap2/mmc-
twl4030.c
index 0c3c72d..e846d56 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -9,195 +9,22 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include linux/err.h
-#include linux/io.h
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/delay.h
-#include linux/gpio.h
-#include linux/mmc/host.h
-#include linux/regulator/consumer.h
-
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/string.h
#include mach/hardware.h
-#include plat/control.h
#include plat/mmc.h
-#include plat/board.h
#include mmc-twl4030.h
-
-#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;
+#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
#define HSMMC_NAME_LEN 9
static struct twl_mmc_controller {
- struct omap_mmc_platform_data *mmc;
- /* 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)
-{
- unsigned i;
-
- for (i = 0; i ARRAY_SIZE(hsmmc); i++) {
- struct omap_mmc_platform_data *mmc;
-
- mmc = hsmmc[i].mmc;
- if (!mmc)
- continue;
- if (irq != mmc-slots[0].card_detect_irq)
- continue;
-
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
- }
- return -ENOSYS;
-}
-
-static int twl_mmc_get_ro(struct device *dev, int slot)
-{
- struct
Re: [PATCH 4/8] omap_hsmmc: set DVFS/PM constraints
Paul Walmsley wrote:
(added Denis and Kevin)
Hello Denis, Adrian,
On Wed, 13 Jan 2010, Adrian Hunter wrote:
From afab8b432b37ae1f42b281e58989c8d607ed7183 Mon Sep 17 00:00:00 2001
From: Denis Karpov ext-denis.2.kar...@nokia.com
Date: Wed, 8 Jul 2009 16:15:08 +0200
Subject: [PATCH] omap_hsmmc: set DVFS/PM constraints
Set constraint for MPU minimal frequency to maintain good
I/O performance.
The constraint is set in MMC host 'ENABLED' state and dropped
when MMC host enters 'DISABLED' state which currently happens
upon 100ms of inactivity.
Signed-off-by: Denis Karpov ext-denis.2.kar...@nokia.com
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 18 ++
arch/arm/mach-omap2/hsmmc.c |2 ++
arch/arm/mach-omap2/hsmmc.h |2 ++
arch/arm/plat-omap/include/plat/mmc.h|3 +++
drivers/mmc/host/omap_hsmmc.c| 17 +
5 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ab07ca2..b6318b1 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -209,6 +209,22 @@ static struct twl4030_madc_platform_data rx51_madc_data = {
.irq_line = 1,
};
+#if defined(CONFIG_BRIDGE_DVFS)
+/*
+ * This handler can be used for setting other DVFS/PM constraints:
+ * intr latency, wakeup latency, DMA start latency, bus throughput
+ * according to API in mach/omap-pm.h. Currently we only set constraints
+ * for MPU frequency.
+ */
+#define MMC_MIN_MPU_FREQUENCY 5 /* S500M at OPP3 */
+static void rx51_mmc_set_pm_constraints(struct device *dev, int on)
+{
+ omap_pm_set_min_mpu_freq(dev, (on ? MMC_MIN_MPU_FREQUENCY : 0));
+}
NAK. The MMC driver (or any other driver, for that matter) must not set
MPU frequency constraints merely to boost performance. Drivers have no
way of knowing what the power vs. performance policy is for a given device
or use case.
The driver doesn't but RX-51 does, which is why the code is in the RX-51
board file. We know exactly the use cases and the effect on performance.
If the system is not upscaling MPU frequency quickly enough, then the
power management policy code -- CPUFreq, in the MPU case -- or the
parameters for that code -- need to be adjusted. (Of course, integrators
can always dump hacks like this in their own trees if they get lazy, but
these should be kept far, far away from mainline.)
It is unreasonable to override the policy decisions of the board maker
as defined in their board files.
Instead you must remove the omap_pm_set_min_mpu_freq() function entirely
or suffer the consequence that it can be used. i.e. it should not exist
if you don't want anyone to use it.
N.B. As a separate matter, the MMC driver should call
omap_pm_set_min_bus_tput() with the maximum throughput that the current
MMC card can sustain to memory. A reasonable upper bound should be easy
to calculate based on the MMC clock speed and the width of the MMC
transfers. This will allow the kernel to adjust the bus frequency
appropriately as the OMAP PM core's bus utilization model improves.
Many different constraints were tried. min_mpu_freq was the only one that
worked.
In the future, improvements to DMA and changes to PM may be able to get the
same performance without the min_mpu_freq constraint.
- Paul
--
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: Missing help texts
On Wed, 2010-01-13 at 18:24 +0100, ext Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100113 04:52]: Can you guys _please_ ensure that Kconfig entries have help texts before they hit Linus' tree please? Eg, without help texts, options such as DSS_RFBI make precisely zero sense to people who don't know what DSS_RFBI is... Tomi, can you fix this please? Yes, I'll fix them. Tomi -- 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
Warning: E-mail error detected
Our virus detector failed to completely analyse a message you sent:- To: Subject: Mail System Error - Returned Mail Date: Thu Jan 14 19:22:25 2010 Any parts of the message that could not be analysed will not have been delivered. If you are using Microsoft Outlook, we strongly recommend you change your outgoing message format from Rich Text to HTML or Plain Text. 1) Click on the Tools menu and choose Options... 2) Go to the Mail Format tab 3) For message format, select HTML or Plain text 4) Click OK The virus detector said this about the message: Report: Report: MailScanner: Message attempted to kill MailScanner -- MailScanner Email Virus Scanner Oriental Logistics Group www.olc-group.com For all your IT requirements visit: http://www.transtec.co.uk -- 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] USB: musb: allow unaligned memory data transfers
Hi,
On Tue, Jan 12, 2010 at 04:42:17PM +0100, ext Vikram Pandita wrote:
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index a237550..f118ae2 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -166,6 +166,8 @@ static int dma_channel_program(struct dma_channel *channel,
dma_addr_t dma_addr, u32 len)
{
struct musb_dma_channel *musb_channel = channel-private_data;
+ struct musb_dma_controller *controller = musb_channel-controller;
+ struct musb *musb = controller-private_data;
DBG(2, ep%d-%s pkt_sz %d, dma_addr 0x%x length %d, mode %d\n,
musb_channel-epnum,
@@ -175,6 +177,15 @@ static int dma_channel_program(struct dma_channel *channel,
BUG_ON(channel-status == MUSB_DMA_STATUS_UNKNOWN ||
channel-status == MUSB_DMA_STATUS_BUSY);
+ /* On MUSB:RTL1.8 and above, DMA has to be word aligned */
+ if ((dma_addr % 4)
+ (musb-hwvers = MUSB_HWVERS_1800)) {
is it only inventra dma that suffers from this ? If not, we could move
this check before even calling the dma routine.
--
balbi
--
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] USB: musb: allow unaligned memory data transfers
Sergei Shtylyov wrote:
Gadiyar, Anand wrote:
From: Felipe Balbi wrote:
+ /* On MUSB:RTL1.8 and above, DMA has to be word aligned */
+ if ((dma_addr % 4)
+ (musb-hwvers = MUSB_HWVERS_1800)) {
is it only inventra dma that suffers from this ? If not, we could move
this check before even calling the dma routine.
Yes, it's only the integrated Inventra DMA that behaves like this.
Anyway, I don't think newer versions of the IP are being used by
anyone without the Inventra DMA. The older versions though are
sometimes used with external DMA controllers.
DA8xx/OMAP-L1x has MUSB version 1.800 and external, CPPI 4.1 DMA
controller.
Ah, okay. Thanks for the info - I did not know this.
- Anand
--
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: pandora: add DSS2 support and related regulators
On Wed, 2010-01-13 at 22:01 +0100, ext Grazvydas Ignotas wrote:
On Wed, Jan 13, 2010 at 5:02 PM, Tomi Valkeinen
tomi.valkei...@nokia.com wrote:
Hi,
This doesn't apply, can you resend based on Linus' tree or my DSS2 tree?
ok, will resend shortly.
BTW, what about enabling vdds_dsi/vdds_sdi regulators we talked about
earlier? This patch already sets up those regulators in the board file
for DSS2 to get and enable them. I can come up with a patch for that
if you want (perhaps doing it somewhere in dss_init()).
It would be nice to get this clarified from TI's HW side, but I haven't
had time to do that.
However, it sure looks like your theory is correct, so a patch would be
ok.
I don't think dss_init is a proper place for it. The power only needs to
be enabled when the display is on, so perhaps
dpi_display_enable/disable() would be better place to turn it on and off
(and suspend/resume). Below is a quick patch I made to test this.
But is the same code needed by RFBI and SDI also? And is it needed only
when certain pins are in use? And only on OMAP3. I'm not sure what would
be the most elegant way for this, but perhaps for now it's good enough
if we enable the power in dpi.c's enable/disable.
Tomi
From 839626c3cb47ab209876fe6a67606529a770dd53 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@nokia.com
Date: Thu, 14 Jan 2010 15:57:06 +0200
Subject: [PATCH] test for vdds_sdi
---
arch/arm/mach-omap2/board-3430sdp.c|4 --
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 35
drivers/video/omap2/dss/core.c |2 +-
drivers/video/omap2/dss/dpi.c | 58
+---
drivers/video/omap2/dss/dss.h |2 +-
5 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c90b0d0..964c390 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -520,10 +520,6 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
{
- .supply = vdvi,
- .dev= sdp3430_lcd_device.dev,
- },
- {
.supply = vdds_dsi,
.dev= sdp3430_dss_device.dev,
}
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index bbe880b..e207d66 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -25,14 +25,6 @@
#include plat/display.h
-struct sharp_data {
- /* XXX This regulator should actually be in SDP board file, not here,
-* as it doesn't actually power the LCD, but something else that
-* affects the output to LCD (I think. Somebody clarify). It doesn't
do
-* harm here, as SDP is the only board using this currently */
- struct regulator *vdvi_reg;
-};
-
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
.y_res = 640,
@@ -50,48 +42,25 @@ static struct omap_video_timings sharp_ls_timings =
{
static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd;
-
dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
OMAP_DSS_LCD_IHS;
dssdev-panel.acb = 0x28;
dssdev-panel.timings = sharp_ls_timings;
- sd = kzalloc(sizeof(*sd), GFP_KERNEL);
- if (!sd)
- return -ENOMEM;
-
- dev_set_drvdata(dssdev-dev, sd);
-
- sd-vdvi_reg = regulator_get(dssdev-dev, vdvi);
- if (IS_ERR(sd-vdvi_reg)) {
- kfree(sd);
- pr_err(failed to get VDVI regulator\n);
- return PTR_ERR(sd-vdvi_reg);
- }
-
return 0;
}
static void sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd = dev_get_drvdata(dssdev-dev);
-
- regulator_put(sd-vdvi_reg);
-
- kfree(sd);
}
static int sharp_ls_panel_enable(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd = dev_get_drvdata(dssdev-dev);
int r = 0;
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- regulator_enable(sd-vdvi_reg);
-
if (dssdev-platform_enable)
r = dssdev-platform_enable(dssdev);
@@ -100,13 +69,9 @@ static int sharp_ls_panel_enable(struct
omap_dss_device *dssdev)
static void sharp_ls_panel_disable(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd = dev_get_drvdata(dssdev-dev);
-
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
- regulator_disable(sd-vdvi_reg);
-
/* wait at least 5 vsyncs after disabling the LCD */
msleep(100);
diff --git
Re: [PATCH 0/2] omap3: cm-t35: enable display subsystem
Hi, On Mon, 2009-12-14 at 09:01 +0100, ext Mike Rapoport wrote: The below patches add display support for CM-T35 board. The following changes since commit f40542532e96dda5506eb76badea322f2ae4731c: Linus Torvalds (1): Merge branch 'ixp4xx' of git://git.kernel.org/.../chris/linux-2.6 Mike Rapoport (2): OMAP: DSS2: add Toppoly TDO35S panel omap3: cm-t35: add DSS2 display support Thanks, I've applied these to my DSS2 tree. Tomi -- 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] USB: musb: allow unaligned memory data transfers
Hello.
Gadiyar, Anand wrote:
From: Felipe Balbi wrote:
+ /* On MUSB:RTL1.8 and above, DMA has to be word aligned */
+ if ((dma_addr % 4)
+ (musb-hwvers = MUSB_HWVERS_1800)) {
is it only inventra dma that suffers from this ? If not, we could move
this check before even calling the dma routine.
Yes, it's only the integrated Inventra DMA that behaves like this.
Anyway, I don't think newer versions of the IP are being used by
anyone without the Inventra DMA. The older versions though are
sometimes used with external DMA controllers.
DA8xx/OMAP-L1x has MUSB version 1.800 and external, CPPI 4.1 DMA
controller.
WBR, Sergei
--
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 1/4] Add minimal support for DEVKIT8000
Hello,
I use Kims patches and I have done some work on it over the time and
after the comments from Felipe, so I want to submit them one more time.
Thomas
From fb89dd25e77401d42d7216d5adadb94b1c2298fe Mon Sep 17 00:00:00 2001
From: Kim Botherway kbother...@djdvant.com
Date: Thu, 12 Nov 2009 21:17:42 +1100
Subject: [PATCH 1/4] Add minimal support for DEVKIT8000
These patches add omap3 board support for the Timll DEVKIT8000
Signed-off-by: Thomas Weber we...@corscience.de
rework after comments from mailing list.
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile|2 +
arch/arm/mach-omap2/board-omap3devkit8000.c | 616
+++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3devkit8000.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 606bf04..94e3ef5 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -67,6 +67,10 @@ config MACH_OMAP3_BEAGLE
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CBB
+config MACH_OMAP3_DEVKIT8000
+bool OMAP3 DEVKIT8000 board
+depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..083236b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -75,6 +75,8 @@ obj-$(CONFIG_MACH_OMAP_2430SDP)+=
board-2430sdp.o \
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
+obj-$(CONFIG_MACH_OMAP3_DEVKIT8000) += board-omap3devkit8000.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO)+= board-overo.o \
diff --git a/arch/arm/mach-omap2/board-omap3devkit8000.c
b/arch/arm/mach-omap2/board-omap3devkit8000.c
new file mode 100644
index 000..5f85dc6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3devkit8000.c
@@ -0,0 +1,616 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3devkit8000.c
+ *
+ * Copyright (C) 2008 Texas Instruments
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+#include plat/timer-gp.h
+
+#include plat/mcspi.h
+#include linux/input/matrix_keypad.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
+#include linux/usb/otg.h
+#include linux/dm9000.h
+#include linux/interrupt.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+#include mux.h
+#include mmc-twl4030.h
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+#define NAND_BLOCK_SIZESZ_128K
+
+#define OMAP_DM9000_GPIO_IRQ25
+#define OMAP3_DEVKIT_TS_GPIO27
+
+static struct mtd_partition omap3devkit8000_nand_partitions[] = {
+/* All the partition sizes are listed in terms of NAND block size */
+{
+.name= X-Loader,
+.offset= 0,
+.size= 4 * NAND_BLOCK_SIZE,
+.mask_flags= MTD_WRITEABLE,/* force read-only */
+},
+{
+.name= U-Boot,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x8 */
+.size= 15 * NAND_BLOCK_SIZE,
+.mask_flags= MTD_WRITEABLE,/* force read-only */
+},
+{
+.name= U-Boot Env,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x26 */
+.size= 1 * NAND_BLOCK_SIZE,
+},
+{
+.name= Kernel,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x28 */
+.size= 32 * NAND_BLOCK_SIZE,
+},
+{
+.name= File System,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x68 */
+.size= MTDPART_SIZ_FULL,
+},
+};
+
+static struct omap_nand_platform_data omap3devkit8000_nand_data = {
+.options= NAND_BUSWIDTH_16,
+.parts=
[PATCH 1/4] Add minimal support for DEVKIT8000
From: Kim Botherway kbother...@djdvant.com
These patches add omap3 board support for the Timll DEVKIT8000
Signed-off-by: Thomas Weber we...@corscience.de
rework after comments from mailing list.
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile|2 +
arch/arm/mach-omap2/board-omap3devkit8000.c | 616 +++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3devkit8000.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 606bf04..94e3ef5 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -67,6 +67,10 @@ config MACH_OMAP3_BEAGLE
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CBB
+config MACH_OMAP3_DEVKIT8000
+bool OMAP3 DEVKIT8000 board
+depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..083236b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -75,6 +75,8 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
+obj-$(CONFIG_MACH_OMAP3_DEVKIT8000) += board-omap3devkit8000.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
diff --git a/arch/arm/mach-omap2/board-omap3devkit8000.c
b/arch/arm/mach-omap2/board-omap3devkit8000.c
new file mode 100644
index 000..5f85dc6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3devkit8000.c
@@ -0,0 +1,616 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3devkit8000.c
+ *
+ * Copyright (C) 2008 Texas Instruments
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+#include plat/timer-gp.h
+
+#include plat/mcspi.h
+#include linux/input/matrix_keypad.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
+#include linux/usb/otg.h
+#include linux/dm9000.h
+#include linux/interrupt.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+#include mux.h
+#include mmc-twl4030.h
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+#define NAND_BLOCK_SIZESZ_128K
+
+#define OMAP_DM9000_GPIO_IRQ 25
+#define OMAP3_DEVKIT_TS_GPIO 27
+
+static struct mtd_partition omap3devkit8000_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader,
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot Env,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = Kernel,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = File System,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data omap3devkit8000_nand_data = {
+ .options= NAND_BUSWIDTH_16,
+ .parts = omap3devkit8000_nand_partitions,
+
Re: [PATCH 1/4] Add minimal support for DEVKIT8000
Sorry, because the patch is line wrapped, I resent it, but with original
subject.
Thanks Nishanth.
Thomas
Thomas Weber schrieb:
Hello,
I use Kims patches and I have done some work on it over the time and
after the comments from Felipe, so I want to submit them one more time.
Thomas
From fb89dd25e77401d42d7216d5adadb94b1c2298fe Mon Sep 17 00:00:00 2001
From: Kim Botherway kbother...@djdvant.com
Date: Thu, 12 Nov 2009 21:17:42 +1100
Subject: [PATCH 1/4] Add minimal support for DEVKIT8000
These patches add omap3 board support for the Timll DEVKIT8000
Signed-off-by: Thomas Weber we...@corscience.de
rework after comments from mailing list.
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile|2 +
arch/arm/mach-omap2/board-omap3devkit8000.c | 616
+++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3devkit8000.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 606bf04..94e3ef5 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -67,6 +67,10 @@ config MACH_OMAP3_BEAGLE
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CBB
+config MACH_OMAP3_DEVKIT8000
+bool OMAP3 DEVKIT8000 board
+depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..083236b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -75,6 +75,8 @@ obj-$(CONFIG_MACH_OMAP_2430SDP)+=
board-2430sdp.o \
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
+obj-$(CONFIG_MACH_OMAP3_DEVKIT8000) += board-omap3devkit8000.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO)+= board-overo.o \
diff --git a/arch/arm/mach-omap2/board-omap3devkit8000.c
b/arch/arm/mach-omap2/board-omap3devkit8000.c
new file mode 100644
index 000..5f85dc6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3devkit8000.c
@@ -0,0 +1,616 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3devkit8000.c
+ *
+ * Copyright (C) 2008 Texas Instruments
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+#include plat/timer-gp.h
+
+#include plat/mcspi.h
+#include linux/input/matrix_keypad.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
+#include linux/usb/otg.h
+#include linux/dm9000.h
+#include linux/interrupt.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+#include mux.h
+#include mmc-twl4030.h
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+#define NAND_BLOCK_SIZESZ_128K
+
+#define OMAP_DM9000_GPIO_IRQ25
+#define OMAP3_DEVKIT_TS_GPIO27
+
+static struct mtd_partition omap3devkit8000_nand_partitions[] = {
+/* All the partition sizes are listed in terms of NAND block size */
+{
+.name= X-Loader,
+.offset= 0,
+.size= 4 * NAND_BLOCK_SIZE,
+.mask_flags= MTD_WRITEABLE,/* force read-only */
+},
+{
+.name= U-Boot,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x8 */
+.size= 15 * NAND_BLOCK_SIZE,
+.mask_flags= MTD_WRITEABLE,/* force read-only */
+},
+{
+.name= U-Boot Env,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x26 */
+.size= 1 * NAND_BLOCK_SIZE,
+},
+{
+.name= Kernel,
+.offset= MTDPART_OFS_APPEND,/* Offset = 0x28 */
+.size= 32 * NAND_BLOCK_SIZE,
+},
+{
+.name= File
[PATCH v9 0/4] OMAP: McBSP: Use register cache
Change the way McBSP registers are maintained: store values written to the device in a cache in order to make use of those cached values when convenient. This could help for developing the McBSP context save/restore features, as well as solve the problem of possible register corruption, experienced on OMAP1510 based Amstrad Delta board at least. Series created against linux-omap for-next, commit fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11). All patches tested on OMAP1510 based Amstrad Delta and compile-tested using omap_3430sdp_defconfig at least. Latest changes: - patch 3: allow for using the mcbsp-free as a guard for cache access, adpot for fixed error handling in omap_mcbsp_request(). - patch 5: dropped - all: refresh against latest l-o for-next tree. Janusz Krzysztofik (4): OMAP: McBSP: Use macros for all register read/write operations OMAP: McBSP: Modify macros/functions API for easy cache access OMAP: McBSP: Introduce caching in register write operations OMAP: McBSP: Use cache when modifying individual register bits arch/arm/mach-omap1/mcbsp.c | 16 - arch/arm/mach-omap2/mcbsp.c | 20 + arch/arm/plat-omap/include/plat/mcbsp.h |3 arch/arm/plat-omap/mcbsp.c | 480 4 files changed, 278 insertions(+), 241 deletions(-) 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 v9 1/4] OMAP: McBSP: Use macros for all register read/write operations
There are several places where readw()/writew() functions are used instead of
OMAP_MCBSP_READ()/WRITE() macros for manipulating McBSP registers. Replace
them with macros to ensure consistent behaviour after caching is introduced.
Created against linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Tested on OMAP1510 based Amstrad Delta.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes since v3.
Charu,
After a week has passed with no answer from you to my proposal, I'm no longer
waiting for you to submit your version, sorry.
arch/arm/plat-omap/mcbsp.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
--- git/arch/arm/plat-omap/mcbsp.c.orig 2010-01-13 12:56:42.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2010-01-13 23:43:13.0 +0100
@@ -636,26 +636,26 @@ int omap_mcbsp_pollwrite(unsigned int id
mcbsp = id_to_mcbsp_ptr(id);
base = mcbsp-io_base;
- writew(buf, base + OMAP_MCBSP_REG_DXR1);
+ OMAP_MCBSP_WRITE(base, DXR1, buf);
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR2) XSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR2) XSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) (~XSYNC_ERR),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) (~XSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for transmit confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR2) XRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR2) XRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR2)
- (~XRST),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2)
+ (~XRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) |
- (XRST),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) |
+ (XRST));
udelay(10);
dev_err(mcbsp-dev, Could not write to
McBSP%d Register\n, mcbsp-id);
@@ -681,24 +681,24 @@ int omap_mcbsp_pollread(unsigned int id,
base = mcbsp-io_base;
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR1) RSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR1) RSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR1) (~RSYNC_ERR),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) (~RSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for recieve confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR1) RRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR1) RRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR1)
- (~RRST),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1)
+ (~RRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR1) |
- (RRST),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) |
+ (RRST));
udelay(10);
dev_err(mcbsp-dev, Could not read from
McBSP%d Register\n, mcbsp-id);
@@ -706,7 +706,7 @@ int omap_mcbsp_pollread(unsigned int id,
}
}
}
- *buf =
[PATCH v9 2/4] OMAP: McBSP: Modify macros/functions API for easy cache access
OMAP_MCBSP_READ()/_WRITE() macros and omap_mcbsp_read()/_write() functions
accept McBSP register base address as an argument. In order to support
caching, that must be replaced with an address of the omap_mcbsp structure
that would provide addresses for both register AND cache access.
Since OMAP_ prefix seems obvious in macro names, drop it off in order to
minimize line wrapping throughout the file.
Applies on top of patch 1 from this series:
[PATCH v9 1/4] OMAP: McBSP: Use macros for all register read/write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes since v7.
v7 changes:
- modify API of omap_mcbsp_read()/_write() functions as well, since those will
actually provide caching operations, not macros like before.
arch/arm/plat-omap/mcbsp.c | 281 -
1 file changed, 125 insertions(+), 156 deletions(-)
--- git/arch/arm/plat-omap/mcbsp.c.orig 2010-01-13 23:43:13.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2010-01-13 23:51:13.0 +0100
@@ -30,26 +30,26 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
-void omap_mcbsp_write(void __iomem *io_base, u16 reg, u32 val)
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- __raw_writew((u16)val, io_base + reg);
+ __raw_writew((u16)val, mcbsp-io_base + reg);
else
- __raw_writel(val, io_base + reg);
+ __raw_writel(val, mcbsp-io_base + reg);
}
-int omap_mcbsp_read(void __iomem *io_base, u16 reg)
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- return __raw_readw(io_base + reg);
+ return __raw_readw(mcbsp-io_base + reg);
else
- return __raw_readl(io_base + reg);
+ return __raw_readl(mcbsp-io_base + reg);
}
-#define OMAP_MCBSP_READ(base, reg) \
- omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
-#define OMAP_MCBSP_WRITE(base, reg, val) \
- omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
+#define MCBSP_READ(mcbsp, reg) \
+ omap_mcbsp_read(mcbsp, OMAP_MCBSP_REG_##reg)
+#define MCBSP_WRITE(mcbsp, reg, val) \
+ omap_mcbsp_write(mcbsp, OMAP_MCBSP_REG_##reg, val)
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
#define id_to_mcbsp_ptr(id)mcbsp_ptr[id];
@@ -60,31 +60,31 @@ static void omap_mcbsp_dump_reg(u8 id)
dev_dbg(mcbsp-dev, McBSP%d regs \n, mcbsp-id);
dev_dbg(mcbsp-dev, DRR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR2));
+ MCBSP_READ(mcbsp, DRR2));
dev_dbg(mcbsp-dev, DRR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR1));
+ MCBSP_READ(mcbsp, DRR1));
dev_dbg(mcbsp-dev, DXR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR2));
+ MCBSP_READ(mcbsp, DXR2));
dev_dbg(mcbsp-dev, DXR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR1));
+ MCBSP_READ(mcbsp, DXR1));
dev_dbg(mcbsp-dev, SPCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR2));
+ MCBSP_READ(mcbsp, SPCR2));
dev_dbg(mcbsp-dev, SPCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR1));
+ MCBSP_READ(mcbsp, SPCR1));
dev_dbg(mcbsp-dev, RCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR2));
+ MCBSP_READ(mcbsp, RCR2));
dev_dbg(mcbsp-dev, RCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR1));
+ MCBSP_READ(mcbsp, RCR1));
dev_dbg(mcbsp-dev, XCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR2));
+ MCBSP_READ(mcbsp, XCR2));
dev_dbg(mcbsp-dev, XCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR1));
+ MCBSP_READ(mcbsp, XCR1));
dev_dbg(mcbsp-dev, SRGR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR2));
+ MCBSP_READ(mcbsp, SRGR2));
dev_dbg(mcbsp-dev, SRGR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR1));
+ MCBSP_READ(mcbsp, SRGR1));
dev_dbg(mcbsp-dev, PCR0: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, PCR0));
+ MCBSP_READ(mcbsp, PCR0));
dev_dbg(mcbsp-dev, ***\n);
}
@@ -93,15 +93,14 @@ static irqreturn_t
[PATCH v9 3/4] OMAP: McBSP: Introduce caching in register write operations
Determine cache size required per McBSP port at init time, based on processor
type running on.
Allocate space for storing cached copies of McBSP register values at port
request.
Modify omap_msbcp_write() function to update the cache with every register
write operation.
Modify omap_mcbsp_read() to support reading from cache or hardware.
Update MCBSP_READ() macro for modified omap_mcbsp_read() function API.
Introduce a new macro that reads from the cache.
Applies on top of patch 2 from this series:
[PATCH v9 2/4] OMAP: McBSP: Modify macros/functions API for easy cache access
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with: omap_perseus2_730_defconfig, omap_generic_1610_defconfig,
omap_generic_2420_defconfig, omap_2430sdp_defconfig, omap_3430sdp_defconfig,
omap_4430sdp_defconfig with CONFIG_OMAP_MCBSP=y selected.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v9 changes:
- allow for using the mcbsp-free as a guard for cache access,
- adpot for fixed error handling in omap_mcbsp_request(),
- fix style issues introduced with that error handling fix.
v8 changes:
- move the cache allocation after the mcbsp-free test lines, memory leak
and other badness would happen otherwise.
v7 changes:
- replace cache table with cache pointer inside omap_mcbsp structure,
- determine cache size at runtime, allocate dynamically when port requested,
- get rid of ifdef...else by placing processor dependent snippets of new code
correctly in respective source files.
arch/arm/mach-omap1/mcbsp.c | 16 +-
arch/arm/mach-omap2/mcbsp.c | 20 ++--
arch/arm/plat-omap/include/plat/mcbsp.h |3 -
arch/arm/plat-omap/mcbsp.c | 77 ++--
4 files changed, 84 insertions(+), 32 deletions(-)
diff -upr git.orig/arch/arm/mach-omap1/mcbsp.c git/arch/arm/mach-omap1/mcbsp.c
--- git.orig/arch/arm/mach-omap1/mcbsp.c2010-01-13 12:56:29.0
+0100
+++ git/arch/arm/mach-omap1/mcbsp.c 2010-01-13 23:55:55.0 +0100
@@ -99,9 +99,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP7XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap7xx_mcbsp_pdata)
+#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap7xx_mcbsp_pdataNULL
#define OMAP7XX_MCBSP_PDATA_SZ 0
+#define OMAP7XX_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP15XX
@@ -132,9 +134,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP15XX_MCBSP_PDATA_SZARRAY_SIZE(omap15xx_mcbsp_pdata)
+#define OMAP15XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap15xx_mcbsp_pdata NULL
#define OMAP15XX_MCBSP_PDATA_SZ0
+#define OMAP15XX_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP16XX
@@ -165,19 +169,25 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP16XX_MCBSP_PDATA_SZARRAY_SIZE(omap16xx_mcbsp_pdata)
+#define OMAP16XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap16xx_mcbsp_pdata NULL
#define OMAP16XX_MCBSP_PDATA_SZ0
+#define OMAP16XX_MCBSP_REG_NUM 0
#endif
int __init omap1_mcbsp_init(void)
{
- if (cpu_is_omap7xx())
+ if (cpu_is_omap7xx()) {
omap_mcbsp_count = OMAP7XX_MCBSP_PDATA_SZ;
- if (cpu_is_omap15xx())
+ omap_mcbsp_cache_size = OMAP7XX_MCBSP_REG_NUM * sizeof(u16);
+ } else if (cpu_is_omap15xx()) {
omap_mcbsp_count = OMAP15XX_MCBSP_PDATA_SZ;
- if (cpu_is_omap16xx())
+ omap_mcbsp_cache_size = OMAP15XX_MCBSP_REG_NUM * sizeof(u16);
+ } else if (cpu_is_omap16xx()) {
omap_mcbsp_count = OMAP16XX_MCBSP_PDATA_SZ;
+ omap_mcbsp_cache_size = OMAP16XX_MCBSP_REG_NUM * sizeof(u16);
+ }
mcbsp_ptr = kzalloc(omap_mcbsp_count * sizeof(struct omap_mcbsp *),
GFP_KERNEL);
diff -upr git.orig/arch/arm/mach-omap2/mcbsp.c git/arch/arm/mach-omap2/mcbsp.c
--- git.orig/arch/arm/mach-omap2/mcbsp.c2010-01-13 12:56:30.0
+0100
+++ git/arch/arm/mach-omap2/mcbsp.c 2010-01-13 23:55:55.0 +0100
@@ -65,9 +65,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
+#define OMAP2420_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
#else
#define omap2420_mcbsp_pdata NULL
#define OMAP2420_MCBSP_PDATA_SZ0
+#define OMAP2420_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP2430
@@ -114,9 +116,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
[PATCH v9 4/4] OMAP: McBSP: Use cache when modifying individual register bits
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP registers to be used for updating them
happened to be errornous.
From the hardware side, the issue appeared to be caused by a relatively high
power requirements of an external USB adapter connected to the board's printer
dedicated USB port.
I think there is one important point that makes this patch worth of applying,
apart from my hardware quality. With the current code, if it ever happens to
any machine, no matter if OMAP1510 or newer, to read incorrect value from a
McBSP register, this wrong value will get written back without any checking.
That can lead to hardware damage if, for example, an input pin is turned into
output as a result.
Applies on top of patch 3 from this series:
[PATCH v9 3/4] OMAP: McBSP: Introduce caching in register write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes since v3.
arch/arm/plat-omap/mcbsp.c | 78 +++--
1 file changed, 47 insertions(+), 31 deletions(-)
--- git/arch/arm/plat-omap/mcbsp.c.orig 2010-01-14 00:36:14.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2010-01-14 02:05:23.0 +0100
@@ -114,7 +114,8 @@ static irqreturn_t omap_mcbsp_tx_irq_han
dev_err(mcbsp_tx-dev, TX Frame Sync Error! : 0x%x\n,
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_tx, SPCR2, irqst_spcr2 ~(XSYNC_ERR));
+ MCBSP_WRITE(mcbsp_tx, SPCR2,
+ MCBSP_READ_CACHE(mcbsp_tx, SPCR2) ~(XSYNC_ERR));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -134,7 +135,8 @@ static irqreturn_t omap_mcbsp_rx_irq_han
dev_err(mcbsp_rx-dev, RX Frame Sync Error! : 0x%x\n,
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_rx, SPCR1, irqst_spcr1 ~(RSYNC_ERR));
+ MCBSP_WRITE(mcbsp_rx, SPCR1,
+ MCBSP_READ_CACHE(mcbsp_rx, SPCR1) ~(RSYNC_ERR));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -544,24 +546,25 @@ void omap_mcbsp_start(unsigned int id, i
}
mcbsp = id_to_mcbsp_ptr(id);
- mcbsp-rx_word_length = (MCBSP_READ(mcbsp, RCR1) 5) 0x7;
- mcbsp-tx_word_length = (MCBSP_READ(mcbsp, XCR1) 5) 0x7;
+ mcbsp-rx_word_length = (MCBSP_READ_CACHE(mcbsp, RCR1) 5) 0x7;
+ mcbsp-tx_word_length = (MCBSP_READ_CACHE(mcbsp, XCR1) 5) 0x7;
- idle = !((MCBSP_READ(mcbsp, SPCR2) | MCBSP_READ(mcbsp, SPCR1)) 1);
+ idle = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
+ MCBSP_READ_CACHE(mcbsp, SPCR1)) 1);
if (idle) {
/* Start the sample generator */
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 6));
}
/* Enable transmitter and receiver */
tx = 1;
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | tx);
rx = 1;
- w = MCBSP_READ(mcbsp, SPCR1);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR1);
MCBSP_WRITE(mcbsp, SPCR1, w | rx);
/*
@@ -574,16 +577,16 @@ void omap_mcbsp_start(unsigned int id, i
if (idle) {
/* Start frame sync */
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 7));
}
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* Release the transmitter and receiver */
- w = MCBSP_READ(mcbsp, XCCR);
+ w = MCBSP_READ_CACHE(mcbsp, XCCR);
w = ~(tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
- w = MCBSP_READ(mcbsp, RCCR);
+ w = MCBSP_READ_CACHE(mcbsp, RCCR);
w = ~(rx ? RDISABLE : 0);
MCBSP_WRITE(mcbsp, RCCR, w);
}
@@ -609,28 +612,29 @@ void omap_mcbsp_stop(unsigned int id, in
/* Reset transmitter */
tx = 1;
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- w = MCBSP_READ(mcbsp, XCCR);
+ w = MCBSP_READ_CACHE(mcbsp, XCCR);
w |= (tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
}
- w = MCBSP_READ(mcbsp, SPCR2);
+ w =
[PATCH] PM debug: Fix warning when no CONFIG_DEBUG_FS
From ec3f04ec8cf4851fceb249acf832755b7aad1766 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Thu, 14 Jan 2010 11:01:15 -0600
Subject: [PATCH] PM debug: Fix warning when no CONFIG_DEBUG_FS
Fix following warning when CONFIG_DEBUG_FS wasn't selected:
arch/arm/mach-omap2/pm-debug.c:57: warning: 'pm_dbg_init' declared 'static' but
never defined
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/pm-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 860b755..9727484 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -54,8 +54,6 @@ int omap2_pm_debug;
regs[reg_count++].val = \
__raw_readl(OMAP2_L4_IO_ADDRESS(0x480fe000 + (off)))
-static int __init pm_dbg_init(void);
-
void omap2_pm_dump(int mode, int resume, unsigned int us)
{
struct reg {
@@ -167,6 +165,8 @@ struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
+static int __init pm_dbg_init(void);
+
enum {
DEBUG_FILE_COUNTERS = 0,
DEBUG_FILE_TIMERS,
--
1.6.5.3
0001-PM-debug-Fix-warning-when-no-CONFIG_DEBUG_FS.patch
Description: 0001-PM-debug-Fix-warning-when-no-CONFIG_DEBUG_FS.patch
Re: [PATCH 2/3] OMAP: hwmod: add read/write API for SYSCONFIG
Paul Walmsley p...@pwsan.com writes: Hi Kevin, On Fri, 8 Jan 2010, Kevin Hilman wrote: Some HW blocks have errata which requires selective enabling/disabling of SYSCONFIG bits. In particular, some blocks have known issues with smart-idle so smart-idle has to be disabled under certain conditions. ... RFC: would an API to only touch smart-idle be more appropriate? Maybe omap_hwmod_smart_idle_enable(oh, bool enable)? This idea sounds good. Since the SYSCONFIG bit fields can change and move around depending on the chip and IP, some type of higher-level API seems necessary to preserve sanity. Maybe omap_hwmod_smart_idle_enable() and omap_hwmod_smart_idle_disable(), mimicking API styles like clk_enable()/clk_disable(), etc.? Care to spin something like that? Sounds good, Coming right up Kevin -- 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] PM debug: Fix warning when no CONFIG_DEBUG_FS
Aguirre, Sergio saagui...@ti.com writes:
From ec3f04ec8cf4851fceb249acf832755b7aad1766 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Thu, 14 Jan 2010 11:01:15 -0600
Subject: [PATCH] PM debug: Fix warning when no CONFIG_DEBUG_FS
Fix following warning when CONFIG_DEBUG_FS wasn't selected:
arch/arm/mach-omap2/pm-debug.c:57: warning: 'pm_dbg_init' declared 'static'
but never defined
Signed-off-by: Sergio Aguirre saagui...@ti.com
Thanks, adding to PM branch and queuing in pm-fixes for 2.6.33-rc.
Kevin
---
arch/arm/mach-omap2/pm-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 860b755..9727484 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -54,8 +54,6 @@ int omap2_pm_debug;
regs[reg_count++].val = \
__raw_readl(OMAP2_L4_IO_ADDRESS(0x480fe000 + (off)))
-static int __init pm_dbg_init(void);
-
void omap2_pm_dump(int mode, int resume, unsigned int us)
{
struct reg {
@@ -167,6 +165,8 @@ struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
+static int __init pm_dbg_init(void);
+
enum {
DEBUG_FILE_COUNTERS = 0,
DEBUG_FILE_TIMERS,
--
1.6.5.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 15/13] PM debug: Fix warning when no CONFIG_DEBUG_FS
From: Aguirre, Sergio saagui...@ti.com
From ec3f04ec8cf4851fceb249acf832755b7aad1766 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Thu, 14 Jan 2010 11:01:15 -0600
Subject: [PATCH] PM debug: Fix warning when no CONFIG_DEBUG_FS
Fix following warning when CONFIG_DEBUG_FS wasn't selected:
arch/arm/mach-omap2/pm-debug.c:57: warning: 'pm_dbg_init' declared 'static' but
never defined
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
OK, this should be the last of the PM fixes for this round.
arch/arm/mach-omap2/pm-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 562d190..a086626 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -54,8 +54,6 @@ int omap2_pm_debug;
regs[reg_count++].val = \
__raw_readl(OMAP2_L4_IO_ADDRESS(0x480fe000 + (off)))
-static int __init pm_dbg_init(void);
-
void omap2_pm_dump(int mode, int resume, unsigned int us)
{
struct reg {
@@ -167,6 +165,8 @@ struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
+static int __init pm_dbg_init(void);
+
enum {
DEBUG_FILE_COUNTERS = 0,
DEBUG_FILE_TIMERS,
--
1.6.6
--
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: [PATCHv2 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3- board-evms
On Wed, 2010-01-13 at 22:25 +0530, Aggarwal, Anuj wrote: Any comments on this version? Just had a quick scan, looks fine. Acked-by: Liam Girdwood l...@slimlogic.co.uk -- 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 4/8] omap_hsmmc: set DVFS/PM constraints
Hello Adrian,
On Thu, 14 Jan 2010, Adrian Hunter wrote:
Paul Walmsley wrote:
(added Denis and Kevin)
Hello Denis, Adrian,
On Wed, 13 Jan 2010, Adrian Hunter wrote:
From afab8b432b37ae1f42b281e58989c8d607ed7183 Mon Sep 17 00:00:00 2001
From: Denis Karpov ext-denis.2.kar...@nokia.com
Date: Wed, 8 Jul 2009 16:15:08 +0200
Subject: [PATCH] omap_hsmmc: set DVFS/PM constraints
Set constraint for MPU minimal frequency to maintain good
I/O performance.
The constraint is set in MMC host 'ENABLED' state and dropped
when MMC host enters 'DISABLED' state which currently happens
upon 100ms of inactivity.
Signed-off-by: Denis Karpov ext-denis.2.kar...@nokia.com
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 18 ++
arch/arm/mach-omap2/hsmmc.c |2 ++
arch/arm/mach-omap2/hsmmc.h |2 ++
arch/arm/plat-omap/include/plat/mmc.h|3 +++
drivers/mmc/host/omap_hsmmc.c| 17 +
5 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ab07ca2..b6318b1 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -209,6 +209,22 @@ static struct twl4030_madc_platform_data
rx51_madc_data = {
.irq_line = 1,
};
+#if defined(CONFIG_BRIDGE_DVFS)
+/*
+ * This handler can be used for setting other DVFS/PM constraints:
+ * intr latency, wakeup latency, DMA start latency, bus throughput
+ * according to API in mach/omap-pm.h. Currently we only set constraints
+ * for MPU frequency.
+ */
+#define MMC_MIN_MPU_FREQUENCY5 /* S500M at OPP3 */
+static void rx51_mmc_set_pm_constraints(struct device *dev, int on)
+{
+ omap_pm_set_min_mpu_freq(dev, (on ? MMC_MIN_MPU_FREQUENCY : 0));
+}
NAK. The MMC driver (or any other driver, for that matter) must not set MPU
frequency constraints merely to boost performance. Drivers have no way of
knowing what the power vs. performance policy is for a given device or use
case.
The driver doesn't but RX-51 does, which is why the code is in the RX-51
board file.
I don't think that changes the situation. The RX-51 board file represents
the hardware integration on the device, not MPU power policy. That's the
CPUFreq governor's responsibility. It shouldn't be necessary to hack a
board file to change the CPU power management policy. Maybe that is
acceptable on a device that has been locked down by the manufacturer to
only boot kernels signed by them, but that's not the case for RX-51.
Denis didn't go into detail on the performance problem that you and he
observed. Further info would be welcome. Hypothesizing, if the problem
is that MMC does a lot of MPU work before the CPUFreq timer fires to
re-evaluate performance, then maybe some CPUFreq function call needs to
exist to ask the CPUFreq governor to elevate MPU speed in advance. But
it's hard to say without knowing more about the problem you observed.
We know exactly the use cases and the effect on performance.
Certainly for Maemo 5 Harmattan as shipped that is true. It's not
necessarily true if someone wants to boot another distribution like Debian
and use (for example) a userspace CPUFreq governor on the device.
If the system is not upscaling MPU frequency quickly enough, then the power
management policy code -- CPUFreq, in the MPU case -- or the parameters for
that code -- need to be adjusted. (Of course, integrators can always dump
hacks like this in their own trees if they get lazy, but these should be
kept far, far away from mainline.)
It is unreasonable to override the policy decisions of the board maker
as defined in their board files.
Could you explain why? MPU power management policy for an on-chip device
such as MMC, which is located internally in the OMAP SoC, is board
hardware-invariant, and so doesn't belong in the board file. I agree that
this is dependent on the software distribution. So we either need to
understand the problem and come up with a clean way to resolve it, or keep
hacks like this distribution-specific.
Instead you must remove the omap_pm_set_min_mpu_freq() function entirely
or suffer the consequence that it can be used. i.e. it should not exist
if you don't want anyone to use it.
This function, omap_pm_set_min_mpu_freq(), does not even exist in
mainline, Tony's kernel, or the current PM branch. Nor does
CONFIG_BRIDGE_DVFS. When you look at the file that defines the interface
for these functions, arch/arm/plat-omap/include/plat/omap-pm.h, you'll
find this:
/*
* CPUFreq-originated constraint
*
* In the future, this should be handled by custom OPP clocktype
Re: [PATCH 3/8] OMAP: reconnect hsmmc context loss count
On Wed, 13 Jan 2010, Adrian Hunter wrote: From 840e68745248b4d302429380aa5b1ea944c13024 Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Tue, 5 Jan 2010 10:06:58 +0200 Subject: [PATCH] OMAP: reconnect hsmmc context loss count Call the PM context-loss count function, now that there is a prototype for it. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com Reviewed-by: Paul Walmsley p...@pwsan.com - Paul -- 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
[RFC] [PATCH] omapfb: Fix 12-bit display (RGB444 color mode) handling
Support for RGB444 (12-bit) pixel format has been introduced into omapfb/lcdc by Mark Underwood on 2006-05-26 (commit f74edb6668aad9fc8e81585861b18f996c78a574) in preparation for Amstrad Delta (E3) videophone LCD display support. Before the Amstrad Delta LCD patch by Jonathan McDowell was applied (on 2006-08-04, commit 8d22fb2ea004cdb6379b54c1a8fd1546cfe40ed7), omapfb and lcdc code was changed substantially (commit e563dc81aa01bd8bbb01bc53975a15c398715f62 dated 2006-06-26) in a way that broke Mark's 12-bit display support. Than, a patch by Jonathan, that supposed to correct the problem, was introduced immediatelly (on 2006-08-04, commit e10a75b49e7a57ae17c28b705153c70eba15a8ef). As a result, the Amstrad Delta display was working correctly at boot time, with fbset reporting: geometry 480 320 480 320 16 ... rgba 4/8,4/4,4/0,0/0 However, after first framebuffer reinitialization, colors were no longer being displayed correctly and fbset was reporting: rgba 5/11,6/5,5/0,0/0 The patch tries to correct the issue by setting plane-color_mode depending on panel-bpp, not var-bits_per_pixel. Created and tested on Amstrad Delta against linux-2.6.33-rc3. Signed-off-by: Janusz Krzysztofik jkrz...@tis.icnet.pl --- --- git/drivers/video/omap/omapfb_main.c.orig 2010-01-14 19:30:23.0 +0100 +++ git/drivers/video/omap/omapfb_main.c2010-01-14 20:31:18.0 +0100 @@ -473,10 +473,11 @@ static int set_color_mode(struct omapfb_ return 0; case 12: var-bits_per_pixel = 16; - plane-color_mode = OMAPFB_COLOR_RGB444; - return 0; case 16: - plane-color_mode = OMAPFB_COLOR_RGB565; + if (plane-fbdev-panel-bpp == 12) + plane-color_mode = OMAPFB_COLOR_RGB444; + else + plane-color_mode = OMAPFB_COLOR_RGB565; return 0; default: return -EINVAL; -- 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: pandora: add DSS2 support and related regulators
On Thu, Jan 14, 2010 at 4:05 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: On Wed, 2010-01-13 at 22:01 +0100, ext Grazvydas Ignotas wrote: On Wed, Jan 13, 2010 at 5:02 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, This doesn't apply, can you resend based on Linus' tree or my DSS2 tree? ok, will resend shortly. BTW, what about enabling vdds_dsi/vdds_sdi regulators we talked about earlier? This patch already sets up those regulators in the board file for DSS2 to get and enable them. I can come up with a patch for that if you want (perhaps doing it somewhere in dss_init()). It would be nice to get this clarified from TI's HW side, but I haven't had time to do that. However, it sure looks like your theory is correct, so a patch would be ok. I don't think dss_init is a proper place for it. The power only needs to be enabled when the display is on, so perhaps dpi_display_enable/disable() would be better place to turn it on and off (and suspend/resume). Below is a quick patch I made to test this. But is the same code needed by RFBI and SDI also? And is it needed only when certain pins are in use? And only on OMAP3. I'm not sure what would be the most elegant way for this, but perhaps for now it's good enough if we enable the power in dpi.c's enable/disable. I can only test this on pandora (24bit parallel display), and your patch works fine there. GraÅžvydas PS: I see some author names got mangled in your GIT (got prefixed with 'ext'). -- 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
issue with panel drivers in DSS2
Hi, there is an issue related to panel drivers: even if panel driver provides get_rotate/set_rotate and/or get_mirror/set_mirror functions, those cannot be accessed over sysfs, even though corresponding entries are created in omapdss/displayX. This is because panel driver fills omap_dss_driver structure, but sysfs entries are created for omap_dss_device when it probes. So perhaps those pointers need to be copied from omap_dss_driver to omap_dss_device somewhere in dss_driver_probe(). -- 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 2/3] OMAP: hwmod: add read/write API for SYSCONFIG
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
On Fri, 8 Jan 2010, Kevin Hilman wrote:
Some HW blocks have errata which requires selective enabling/disabling
of SYSCONFIG bits. In particular, some blocks have known issues with
smart-idle so smart-idle has to be disabled under certain conditions.
...
RFC: would an API to only touch smart-idle be more appropriate? Maybe
omap_hwmod_smart_idle_enable(oh, bool enable)?
This idea sounds good. Since the SYSCONFIG bit fields can change and move
around depending on the chip and IP, some type of higher-level API seems
necessary to preserve sanity.
Maybe omap_hwmod_smart_idle_enable() and omap_hwmod_smart_idle_disable(),
mimicking API styles like clk_enable()/clk_disable(), etc.? Care to spin
something like that?
Turns out I needed more than just smart-idle enable/disable. There
are UART errata that also require force-idle (when DMA is in use.)
So, instead I added an API for simply setting slave idle mode (patch
below.)
Here's the UART code that is using this function:
{
u8 idlemode;
if (enable) {
/**
* Errata 2.15: [UART]:Cannot Acknowledge Idle Requests
* in Smartidle Mode When Configured for DMA Operations.
*/
if (uart-dma_enabled)
idlemode = HWMOD_IDLEMODE_FORCE;
else
idlemode = HWMOD_IDLEMODE_SMART;
} else {
idlemode = HWMOD_IDLEMODE_NO;
}
omap_hwmod_set_slave_idlemode(uart-oh, idlemode);
}
From fb0387e2747e2c0b1eff99bc842cad5026e96283 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Mon, 23 Nov 2009 09:41:54 -0800
Subject: [PATCH 2/2] OMAP: hwmod: add API for slave idlemode setting
Some HW blocks have errata which requires specific slave idle mode
under certain conditions.
This patch adds an hwmod API to allow setting slave idlemode
ensuring that any SYSCONFIG register updates go through hwmod.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 17 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d8c8545..3bc47dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -993,6 +993,23 @@ void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16
reg_offs)
__raw_writel(v, oh-_rt_va + reg_offs);
}
+int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ retval = _set_slave_idlemode(oh, idlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
/**
* omap_hwmod_register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 007935a..1f57330 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -440,6 +440,8 @@ int omap_hwmod_shutdown(struct omap_hwmod *oh);
int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
+int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
+
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
--
1.6.6
--
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] DSPBRIDGE: remove unused macros
A tiny step in cleaning up the bridge - removed unused macros I used ctags to generate tags for all dspbridge relevant files grep ' d$' tags gives a list of all defines. then, the following script searched and listed all defines which were unused in dspbridge files: for i in `grep ' d$' tags|cut -d ' ' -f1` do # search for more than a single occurance of the define==usage k=`cat dsp_bridge_files |xargs grep $i|wc -l` # if only a single usage(#define, it is unused) - list it if [ $k -eq 1 ]; then echo $iunused_defines; fi; done the defines in unused_defines where then removed from the files Cc: Ameya Palande ameya.pala...@nokia.com Cc: Felipe Contreras felipe.contre...@nokia.com Cc: Hiroshi Doyu hiroshi.d...@nokia.com Cc: Omar Ramirez Luna omar.rami...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/plat-omap/include/dspbridge/brddefs.h |1 - arch/arm/plat-omap/include/dspbridge/cfgdefs.h |5 -- arch/arm/plat-omap/include/dspbridge/chnldefs.h|2 - arch/arm/plat-omap/include/dspbridge/chnlpriv.h|3 - arch/arm/plat-omap/include/dspbridge/cod.h |3 - arch/arm/plat-omap/include/dspbridge/dbdefs.h | 17 - arch/arm/plat-omap/include/dspbridge/dbg.h |1 - arch/arm/plat-omap/include/dspbridge/dbldefs.h |4 - arch/arm/plat-omap/include/dspbridge/dbtype.h |3 - arch/arm/plat-omap/include/dspbridge/drv.h |5 -- .../plat-omap/include/dspbridge/dynamic_loader.h |1 - arch/arm/plat-omap/include/dspbridge/errbase.h | 36 --- arch/arm/plat-omap/include/dspbridge/io_sm.h |4 - arch/arm/plat-omap/include/dspbridge/iodefs.h |1 - arch/arm/plat-omap/include/dspbridge/mbx_sh.h | 28 - arch/arm/plat-omap/include/dspbridge/memdefs.h |1 - arch/arm/plat-omap/include/dspbridge/pwr_sh.h |4 - arch/arm/plat-omap/include/dspbridge/rms_sh.h |4 - arch/arm/plat-omap/include/dspbridge/strmdefs.h|1 - arch/arm/plat-omap/include/dspbridge/utildefs.h|5 -- arch/arm/plat-omap/include/dspbridge/wmd.h |1 - arch/arm/plat-omap/include/dspbridge/wmdioctl.h|5 -- drivers/dsp/bridge/dynload/dload_internal.h|3 - drivers/dsp/bridge/dynload/doff.h |2 - drivers/dsp/bridge/dynload/header.h|2 - drivers/dsp/bridge/dynload/module_list.h |1 - drivers/dsp/bridge/dynload/params.h|3 - drivers/dsp/bridge/dynload/reloc_table.h |7 -- drivers/dsp/bridge/hw/GlobalTypes.h| 27 drivers/dsp/bridge/hw/MMUAccInt.h |1 - drivers/dsp/bridge/hw/PRCMAccInt.h |2 - drivers/dsp/bridge/hw/PRCMRegAcM.h | 64 drivers/dsp/bridge/hw/hw_dspssC64P.h |1 - drivers/dsp/bridge/hw/hw_mbox.h|3 - drivers/dsp/bridge/pmgr/chnlobj.h |3 - drivers/dsp/bridge/wmd/_tiomap.h | 31 -- drivers/dsp/bridge/wmd/_tiomap_util.h |1 - drivers/dsp/bridge/wmd/tiomap_io.h |4 - 38 files changed, 0 insertions(+), 290 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/brddefs.h b/arch/arm/plat-omap/include/dspbridge/brddefs.h index c62388c..d86da21 100644 --- a/arch/arm/plat-omap/include/dspbridge/brddefs.h +++ b/arch/arm/plat-omap/include/dspbridge/brddefs.h @@ -41,7 +41,6 @@ #define BRD_SYNCINIT0x4 #define BRD_LOADED 0x5 #define BRD_LASTSTATE BRD_LOADED /* Set to highest legal board state. */ -#define BRD_SLEEP_TRANSITION 0x6 /* Sleep transition in progress */ #define BRD_HIBERNATION 0x7/* MPU initiated hibernation */ #define BRD_RETENTION 0x8 /* Retention mode */ #define BRD_DSP_HIBERNATION 0x9 /* DSP initiated hibernation */ diff --git a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h index 0155e13..854a56e 100644 --- a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h +++ b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h @@ -46,20 +46,15 @@ #define CFG_MAXSEARCHPATHLEN255 /* Maximum length of general paths. */ -#define CFG_MAXPATH 255 /* Host Resources: */ #define CFG_MAXMEMREGISTERS 9 -#define CFG_MAXIOPORTS 20 -#define CFG_MAXIRQS 7 -#define CFG_MAXDMACHANNELS 7 /* IRQ flag */ #define CFG_IRQSHARED 0x01 /* IRQ can be shared */ /* DSP Resources: */ #define CFG_DSPMAXMEMTYPES 10 -#define CFG_DEFAULT_NUM_WINDOWS 1 /* We support only one window. */ /* A platform-related device handle: */ struct CFG_DEVNODE; diff --git a/arch/arm/plat-omap/include/dspbridge/chnldefs.h b/arch/arm/plat-omap/include/dspbridge/chnldefs.h index 9f59229..c2ba4fe 100644 --- a/arch/arm/plat-omap/include/dspbridge/chnldefs.h +++
Re: [PATCH v9 0/4] OMAP: McBSP: Use register cache
On Thu, 14 Jan 2010 16:58:29 +0100 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Change the way McBSP registers are maintained: store values written to the device in a cache in order to make use of those cached values when convenient. This could help for developing the McBSP context save/restore features, as well as solve the problem of possible register corruption, experienced on OMAP1510 based Amstrad Delta board at least. Looks good. I tested the set by running following loop for some time on BeagleBoard without any problems: while [ 1 ]; do (arecord -f dat -d 3 |aplay); sleep 7; done Acked-by: Jarkko Nikula jhnik...@gmail.com -- 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
