Re: McSPI3 on the BeagleBoard
Philip, I found the patch. Thanks. SPI3 is working for me too but I think that there are a couple of errors: - first, in the patch you posted on the beagleboard mailing list, you don't setup CS0 and CS1 pins in u-boot. I think that you should do it. - secondly, you have added more mux configuration in the kernel for SPI3 that should not be SPI3 but those new ones are wrong as they are competing with some USB pins. It's the same error as David pointed you for MMC2. Nevertheless, it's still working. Why? Because I have now a strong feeling that mux configuration is not working in the kernel (at least for the beagleboard). Here are a few facts that would confirm this statement: - MUX setup for USB ehci has never worked in the kernel. It's why the beagleaboard rev-C ehci patch has been transfered to u-boot. - the difference between your patch before and after it was working, is really the u-boot configuration. You haven't really changed anything in the kernel (especially in the spi driver) and as mentioned above, you have even introduced some competing muxes that should have created more trouble if the kernel mux config were working correctly. - I had two other areas where I configured the pins in kernel and it was not working. Only when I eventually did it in u-boot, it started to work. I don't know what's wrong with the pin configuration in the kernel, Grégoire On Thu, 2009-02-19 at 09:14 -0500, Philip Balister wrote: Gregoire Gentil wrote: Philip, Can you please post here or on the Beagleboard mailing list the u-boot patch? This muxpin is very tricky and I have experienced many problems when set up in the kernel while it seems to work better from u-boot - don't know why, I posted it to the Beagle group. Let me know if you are having trouble finding it. If we come up with a better config for the expansion port, we'll clean it up and submit here. My gut feeling is having SPI interfaces on the expansion connector will be more useful then the MMC interface. Philip -- 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 0/2] TWL: USB: Start using twl4030/5030 regulator driver
On Fri, 2009-02-13 at 14:35 -0800, David Brownell wrote: On Friday 13 February 2009, Kalle Jokiniemi wrote: I ran into some trouble with the merged fix. For some reason clearing the VUSB3V1_DEV_GRP register causes VUSB_DEDICATED2.VUSB3V1_SLEEP bit to be enabled. This means that once VUSB3V1_DEV_GRP is put back to enabled state (VUSB3V1 changed to be part of P1 group again), VUSB3V1 does not go ACTIVE, but SLEEP state instead. Anyone have a clue what might cause this? Curious. No ... is that specific to some TWL revision? TWL5030, I think the revision is ES1.0. I got additional info from TI that when the LDO goes into off state, the sleep bit indeed resets back to default value of 1. Which is to remap active state to sleep. So I have a patch that takes this into account by clearing the remap bit every time we wake up the VUSB3V1 regulator. - Kalle I'll poke around after I get this new board working better for me. - Dave -- 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Friday Feb 20, 2009 Grazvydas Ignotas wrote: On Fri, Feb 20, 2009 at 12:46 AM, Felipe Balbi m...@felipebalbi.com wrote: On Thu, Feb 19, 2009 at 02:43:36PM -0800, Steve Sakoman wrote: EHCI omap driver definitely needs some work - there is machine specific stuff in there that rightfully belongs in platform data. I haven't had time to work on it :-( For sure, and there's still workaround for clk framework stuff that should already move there. I'll try to start with some cleanups already during this weekend (yeah, I've got no life :-p) and post as RFT asap. After the cleanups are ok, then I'll start moving platform code out of there and for the clock workarounds I'll need help from Paul Walmsley, probably :-) Great, I'll be watching the list and gladly test them on pandora too. It would be nice to have those remote wakeup issues [1] sorted out too. 1: http://marc.info/?l=linux-omapm=122911571519657w=2 Sorry, that is not something that will be fixed in ES3.1. It also affects suspend-resume, not just remote-wakeup. However, there is a software workaround that is being tested right now - the one mentioned in the link does not work reliably. The new workaround should be ready shortly (maybe after Felipe is done with the cleanups he plans). - 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: McSPI3 on the BeagleBoard
- MUX setup for USB ehci has never worked in the kernel. It's why the beagleaboard rev-C ehci patch has been transfered to u-boot. Do you have CONFIG_OMAP_MUX enabled? It's disabled in beagle's defconfig. -- 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/1] OMAP3: CLOCK: Remove few unnecessary clocks
dpllx_m2x2_ck parent is dpllx_m2_ck. So remove few useless clocks and
and use right parent for dpllx_m2x2_ck.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/clock34xx.h | 31 ++-
1 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 179ea17..4f462ea 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -427,18 +427,6 @@ static struct clk dpll3_ck = {
.recalc = omap3_dpll_recalc,
};
-/*
- * This virtual clock provides the CLKOUTX2 output from the DPLL if the
- * DPLL isn't bypassed
- */
-static struct clk dpll3_x2_ck = {
- .name = dpll3_x2_ck,
- .parent = dpll3_ck,
- .flags = CLOCK_IN_OMAP343X | PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = dpll3_clkdm },
- .recalc = omap3_clkoutx2_recalc,
-};
-
static const struct clksel_rate div31_dpll3_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_343X | DEFAULT_RATE },
{ .div = 2, .val = 2, .flags = RATE_IN_343X },
@@ -505,10 +493,10 @@ static struct clk core_ck = {
static struct clk dpll3_m2x2_ck = {
.name = dpll3_m2x2_ck,
- .parent = dpll3_x2_ck,
+ .parent = dpll3_m2_ck,
.flags = CLOCK_IN_OMAP343X | PARENT_CONTROLS_CLOCK,
.clkdm = { .name = dpll3_clkdm },
- .recalc = followparent_recalc,
+ .recalc = omap3_clkoutx2_recalc,
};
/* The PWRDN bit is apparently only available on 3430ES2 and above */
@@ -590,19 +578,6 @@ static struct clk dpll4_ck = {
.recalc = omap3_dpll_recalc,
};
-/*
- * This virtual clock provides the CLKOUTX2 output from the DPLL if the
- * DPLL isn't bypassed --
- * XXX does this serve any downstream clocks?
- */
-static struct clk dpll4_x2_ck = {
- .name = dpll4_x2_ck,
- .parent = dpll4_ck,
- .flags = CLOCK_IN_OMAP343X | PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = dpll4_clkdm },
- .recalc = omap3_clkoutx2_recalc,
-};
-
static const struct clksel div16_dpll4_clksel[] = {
{ .parent = dpll4_ck, .rates = div16_dpll_rates },
{ .parent = NULL }
@@ -3355,14 +3330,12 @@ static struct clk *onchip_34xx_clks[] __initdata = {
dpll2_m2_ck,
dpll3_ck,
core_ck,
- dpll3_x2_ck,
dpll3_m2_ck,
dpll3_m2x2_ck,
dpll3_m3_ck,
dpll3_m3x2_ck,
emu_core_alwon_ck,
dpll4_ck,
- dpll4_x2_ck,
omap_96m_alwon_fck,
omap_96m_fck,
cm_96m_fck,
--
1.6.0.1
--
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] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
Most registers lose its state when the processor wakes up from sleep state.
Thus registers should be initialized, when the processor wakes up. However the
current hsmmc 'resume' function doesn't consider this issue and finally makes
deadlock. So this patch fixes this problem.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 155 +
1 files changed, 79 insertions(+), 76 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 56363c5..5a73fa6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -55,6 +55,7 @@
#define VS30 (1 25)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
+#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
#define AUTOIDLE 0x1
@@ -861,6 +862,34 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return pdata-slots[0].get_ro(host-dev, 0);
}
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id == OMAP_MMC1_DEVID) {
+ hctl = SDVS30;
+ capa = VS30 | VS18;
+ } else {
+ hctl = SDVS18;
+ capa = VS18;
+ }
+
+ value = OMAP_HSMMC_READ(host-base, HCTL) ~SDVS_MASK;
+ OMAP_HSMMC_WRITE(host-base, HCTL, value | hctl);
+
+ value = OMAP_HSMMC_READ(host-base, CAPA);
+ OMAP_HSMMC_WRITE(host-base, CAPA, value | capa);
+
+ /* Set the controller to AUTO IDLE mode */
+ value = OMAP_HSMMC_READ(host-base, SYSCONFIG);
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, value | AUTOIDLE);
+
+ /* Set SD bus power bit */
+ value = OMAP_HSMMC_READ(host-base, HCTL);
+ OMAP_HSMMC_WRITE(host-base, HCTL, value | SDBP);
+}
+
static struct mmc_host_ops mmc_omap_ops = {
.request = omap_mmc_request,
.set_ios = omap_mmc_set_ios,
@@ -876,7 +905,6 @@ static int __init omap_mmc_probe(struct
platform_device *pdev)
struct mmc_omap_host *host = NULL;
struct resource *res;
int ret = 0, irq;
- u32 hctl, capa;
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -981,28 +1009,7 @@ static int __init omap_mmc_probe(struct
platform_device *pdev)
if (pdata-slots[host-slot_id].wires = 4)
mmc-caps |= MMC_CAP_4_BIT_DATA;
- /* Only MMC1 supports 3.0V */
- if (host-id == OMAP_MMC1_DEVID) {
- hctl = SDVS30;
- capa = VS30 | VS18;
- } else {
- hctl = SDVS18;
- capa = VS18;
- }
-
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
-
- OMAP_HSMMC_WRITE(host-base, CAPA,
- OMAP_HSMMC_READ(host-base, CAPA) | capa);
-
- /* Set the controller to AUTO IDLE mode */
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
-
- /* Set SD bus power bit */
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | SDBP);
+ omap_hsmmc_init(host);
/* Request IRQ for MMC operations */
ret = request_irq(host-irq, mmc_omap_irq, IRQF_DISABLED,
@@ -1127,41 +1134,38 @@ static int omap_mmc_suspend(struct
platform_device *pdev, pm_message_t state)
if (host host-suspended)
return 0;
- if (host) {
- ret = mmc_suspend_host(host-mmc, state);
- if (ret == 0) {
- host-suspended = 1;
-
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ ret = mmc_suspend_host(host-mmc, state);
+ if (ret == 0) {
+ host-suspended = 1;
- if (host-pdata-suspend) {
- ret = host-pdata-suspend(pdev-dev,
- host-slot_id);
- if (ret)
- dev_dbg(mmc_dev(host-mmc),
- Unable to handle MMC board
-level suspend\n);
- }
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
- if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL)
-SDVSCLR);
- OMAP_HSMMC_WRITE(host-base, HCTL,
-
[PATCH 1/1] TWL: USB: disable VUSB regulators when cable unplugged
From: Jouni Hogander jouni.hogan...@nokia.com
This patch disables USB regulators VUSB1V5, VUSB1V8, and VUSB3V1
when the USB cable is unplugged to reduce power consumption.
Added a depencency from twl4030 usb driver to TWL_REGULATOR.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
drivers/usb/otg/Kconfig |2 +-
drivers/usb/otg/twl4030-usb.c | 73 -
2 files changed, 65 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index ee55b44..5790a5b 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -43,7 +43,7 @@ config ISP1301_OMAP
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
- depends on TWL4030_CORE
+ depends on TWL4030_CORE REGULATOR_TWL4030
select USB_OTG_UTILS
help
Enable this to support the USB OTG transceiver on TWL4030
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..d9478d0 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -34,6 +34,8 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/i2c/twl4030.h
+#include linux/regulator/consumer.h
+#include linux/err.h
/* Register defines */
@@ -246,6 +248,11 @@ struct twl4030_usb {
struct otg_transceiver otg;
struct device *dev;
+ /* TWL4030 internal USB regulator supplies */
+ struct regulator*usb1v5;
+ struct regulator*usb1v8;
+ struct regulator*usb3v1;
+
/* for vbus reporting with irqs disabled */
spinlock_t lock;
@@ -434,6 +441,18 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int
on)
pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
if (on) {
+ regulator_enable(twl-usb3v1);
+ regulator_enable(twl-usb1v8);
+ /*
+* Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
+* in twl4030) resets the VUSB_DEDICATED2 register. This reset
+* enables VUSB3V1_SLEEP bit that remaps usb3v1 ACTIVE state to
+* SLEEP. We work around this by clearing the bit after usv3v1
+* is re-activated. This ensures that VUSB3V1 is really active.
+*/
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0,
+ VUSB_DEDICATED2);
+ regulator_enable(twl-usb1v5);
pwr = ~PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
twl4030_usb_write(twl, PHY_CLK_CTRL,
@@ -443,6 +462,9 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int
on)
} else {
pwr |= PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ regulator_disable(twl-usb1v5);
+ regulator_disable(twl-usb1v8);
+ regulator_disable(twl-usb3v1);
}
}
@@ -468,7 +490,7 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
twl-asleep = 0;
}
-static void twl4030_usb_ldo_init(struct twl4030_usb *twl)
+static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
{
/* Enable writing to power configuration registers */
twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0xC0, PROTECT_KEY);
@@ -480,20 +502,45 @@ static void twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* input to VUSB3V1 LDO is from VBAT, not VBUS */
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x14, VUSB_DEDICATED1);
- /* turn on 3.1V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB3V1_DEV_GRP);
+ /* Initialize 3.1V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
+
+ twl-usb3v1 = regulator_get(twl-dev, usb3v1);
+ if (IS_ERR(twl-usb3v1))
+ return -ENODEV;
+
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_TYPE);
- /* turn on 1.5V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V5_DEV_GRP);
+ /* Initialize 1.5V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
+
+ twl-usb1v5 = regulator_get(twl-dev, usb1v5);
+ if (IS_ERR(twl-usb1v5))
+ goto fail1;
+
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
- /* turn on 1.8V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V8_DEV_GRP);
+ /* Initialize 1.8V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
+
+ twl-usb1v8 = regulator_get(twl-dev, usb1v8);
+ if (IS_ERR(twl-usb1v8))
+ goto fail2;
+
[PATCH 0/1] USB: disable twl4030 usb regulators
This patch combines the two patches TWL: USB: disable VUSB regulators when cable unplugged and USB: OTG: Twl4030 depends on REGULATOR_TWL4030 sent earlier by me. New thing is that the patch now handles situations where disabling of VUSB3V1 regulator resets the ACTIVE state remapping to SLEEP to be enabled. Thanks to Jouni Hogander and David Brownell for helping out with the patch. drivers/usb/otg/Kconfig |2 +- drivers/usb/otg/twl4030-usb.c | 73 - 2 files changed, 65 insertions(+), 10 deletions(-) -- 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Fri, Feb 20, 2009 at 11:44:25AM +0100, Anand Gadiyar wrote: On Friday Feb 20, 2009 Grazvydas Ignotas wrote: On Fri, Feb 20, 2009 at 12:46 AM, Felipe Balbi m...@felipebalbi.com wrote: On Thu, Feb 19, 2009 at 02:43:36PM -0800, Steve Sakoman wrote: EHCI omap driver definitely needs some work - there is machine specific stuff in there that rightfully belongs in platform data. I haven't had time to work on it :-( For sure, and there's still workaround for clk framework stuff that should already move there. I'll try to start with some cleanups already during this weekend (yeah, I've got no life :-p) and post as RFT asap. After the cleanups are ok, then I'll start moving platform code out of there and for the clock workarounds I'll need help from Paul Walmsley, probably :-) Great, I'll be watching the list and gladly test them on pandora too. It would be nice to have those remote wakeup issues [1] sorted out too. 1: http://marc.info/?l=linux-omapm=122911571519657w=2 Sorry, that is not something that will be fixed in ES3.1. It also affects suspend-resume, not just remote-wakeup. However, there is a software workaround that is being tested right now - the one mentioned in the link does not work reliably. The new workaround should be ready shortly (maybe after Felipe is done with the cleanups he plans). well, it's been about 5 months since you said TI would be doing such cleanups, I've even had my patches dropped at that time because of that and till now nothing happened. About the workaround, I'd rather read the errata myself and implement it. -- 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
snip well, it's been about 5 months since you said TI would be doing such cleanups, I've even had my patches dropped at that time because of that and till now nothing happened. About the workaround, I'd rather read the errata myself and implement it. Well, I've said time and again that I haven't been able to get around to it. You can read the errata yourself and implement it if you wish. Frankly, I don't give a damn. I've spent the last five months finding the workarounds for all the erratas affecting EHCI, which is __the whole reason__ why I have not been able to fix up the EHCI driver. - 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Fri, Feb 20, 2009 at 01:40:32PM +0100, Anand Gadiyar wrote: snip well, it's been about 5 months since you said TI would be doing such cleanups, I've even had my patches dropped at that time because of that and till now nothing happened. About the workaround, I'd rather read the errata myself and implement it. Well, I've said time and again that I haven't been able to get around to it. You can read the errata yourself and implement it if you wish. Frankly, I don't give a damn. I've spent the last five months finding the workarounds for all the erratas affecting EHCI, which is __the whole reason__ why I have not been able to fix up the EHCI driver. A quick mail explaining that you wouldn't be able to fix ehci at that time would've been enough to avoid it. Then we could have gotten it cleaned up and then just integrate your latest workarounds. Still, the driver will need lots of cleanups before we think about adding workarounds and we have to think about how to integrate the workarounds for different ehci/omap silicon revisions, etc... Anyways, I'll keep going with my cleanups and when I get a platform to test ehci, I'll try to test the patches and keep going with the workarounds. -- 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Fri, Feb 20, 2009 at 01:40:32PM +0100, Anand Gadiyar wrote: snip well, it's been about 5 months since you said TI would be doing such cleanups, I've even had my patches dropped at that time because of that and till now nothing happened. About the workaround, I'd rather read the errata myself and implement it. Well, I've said time and again that I haven't been able to get around to it. You can read the errata yourself and implement it if you wish. Frankly, I don't give a damn. I've spent the last five months finding the workarounds for all the erratas affecting EHCI, which is __the whole reason__ why I have not been able to fix up the EHCI driver. A quick mail explaining that you wouldn't be able to fix ehci at that time would've been enough to avoid it. Then we could have gotten it cleaned up and then just integrate your latest workarounds. Still, the driver will need lots of cleanups before we think about adding workarounds and we have to think about how to integrate the workarounds for different ehci/omap silicon revisions, etc... Well, the way it went was I discovered errata after errata. Everytime I thought this is the last one and I can finally get around to that cleanup, three days later I would end up working on the next failure. I've spent so much time on it, I'm sick of it. So here's the quick mail you want: I may or may not be able to clean up this driver in the near future. Felipe Balbi graciously agress to do it for us. So I am pleased to announce he will clean up this driver and send it upstream. If he needs any help with this, I will try to provide it to him (or anyone else for that matter) on a best-effort basis. Good luck. Anyways, I'll keep going with my cleanups and when I get a platform to test ehci, I'll try to test the patches and keep going with the workarounds. If you want help with testing, I can give it to you. If not, you can test it yourself - I couldn't care less. - 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Fri, Feb 20, 2009 at 01:57:14PM +0100, Anand Gadiyar wrote: On Fri, Feb 20, 2009 at 01:40:32PM +0100, Anand Gadiyar wrote: snip well, it's been about 5 months since you said TI would be doing such cleanups, I've even had my patches dropped at that time because of that and till now nothing happened. About the workaround, I'd rather read the errata myself and implement it. Well, I've said time and again that I haven't been able to get around to it. You can read the errata yourself and implement it if you wish. Frankly, I don't give a damn. I've spent the last five months finding the workarounds for all the erratas affecting EHCI, which is __the whole reason__ why I have not been able to fix up the EHCI driver. A quick mail explaining that you wouldn't be able to fix ehci at that time would've been enough to avoid it. Then we could have gotten it cleaned up and then just integrate your latest workarounds. Still, the driver will need lots of cleanups before we think about adding workarounds and we have to think about how to integrate the workarounds for different ehci/omap silicon revisions, etc... Well, the way it went was I discovered errata after errata. Everytime I thought this is the last one and I can finally get around to that cleanup, three days later I would end up working on the next failure. I've spent so much time on it, I'm sick of it. Don't worry, you're not the only one TIred here... So here's the quick mail you want: I may or may not be able to clean up this driver in the near future. Felipe Balbi graciously agress to do it for us. So I am pleased to announce he will clean up this driver and send it upstream. If he needs any help with this, I will try to provide it to him (or anyone else for that matter) on a best-effort basis. Good luck. Anyways, I'll keep going with my cleanups and when I get a platform to test ehci, I'll try to test the patches and keep going with the workarounds. If you want help with testing, I can give it to you. If not, you can test it yourself - I couldn't care less. And you want me to agree with it ? I really was hoping we could work together with TI but seems I'm the only one who still believes in that. As you said yourself, you couldn't care less right ? You couldn't care less if the driver works or not, you couldn't care less if we have good omap support out of mainline kernel, you couldn't care less if the driver is readable or not, etc etc etc. I imagine if all of us would be taking the same behavior as you are... Well, I'm not here to flood the list discussing this kinds of issues with you. -- 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
Don't worry, you're not the only one TIred here... Grrr. I'm in no mood to take any TI puns right now. That was unwarranted. So here's the quick mail you want: I may or may not be able to clean up this driver in the near future. Felipe Balbi graciously agress to do it for us. So I am pleased to announce he will clean up this driver and send it upstream. If he needs any help with this, I will try to provide it to him (or anyone else for that matter) on a best-effort basis. Good luck. Anyways, I'll keep going with my cleanups and when I get a platform to test ehci, I'll try to test the patches and keep going with the workarounds. If you want help with testing, I can give it to you. If not, you can test it yourself - I couldn't care less. And you want me to agree with it ? I really was hoping we could work together with TI but seems I'm the only one who still believes in that. I made that offer - so there is at least one other believer of working together. You're the one that wants to do this on your own - and I'm okay with that. As you said yourself, you couldn't care less right ? You couldn't care less if the driver works or not, you couldn't care less if we have good omap support out of mainline kernel, you couldn't care less if the driver is readable or not, etc etc etc. That's not true. I do care. It __is__ important to me that OMAP support goes to mainline. And I do not like it that it hasn't happened yet. Sorry. What happened with EHCI here is kind of similar to what you've done with MUSB patches recently anyway. I imagine if all of us would be taking the same behavior as you are... I don't understand what you mean, but I'm guessing it doesn't matter. Well, I'm not here to flood the list discussing this kinds of issues with you. Standard behavior for you. That's the way you end all discussions that go beyond 5 mails!-- 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
OMAP3: PM : Timer to turn LCD off
While testing cpuidle (from Kevin's PM beanch) with default configuration for OMAP3EVM, the c-state never transitions from C0. Even compiling with minimal drivers did not help. fck_core1 continues to be active. Also, the LCD continues to be powered on... Despite compiling out V4L and FB drivers. A simple way to turn LCD off would be to implement an inactivity timer. (e.g. serial.c on the pm branch) The question is - where should this timer be implemented? - As part of the backlight driver? OR - As part of the fb driver? OR - Should it be tied to the board initialization? Best regards, Sanjeev -- 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: OMAP3: PM : Timer to turn LCD off
On Fri, Feb 20, 2009 at 02:24:50PM +0100, ext Premi, Sanjeev wrote: While testing cpuidle (from Kevin's PM beanch) with default configuration for OMAP3EVM, the c-state never transitions from C0. Even compiling with minimal drivers did not help. fck_core1 continues to be active. Also, the LCD continues to be powered on... Despite compiling out V4L and FB drivers. A simple way to turn LCD off would be to implement an inactivity timer. (e.g. serial.c on the pm branch) Blanking seems to me more of a user space policy. You could turn off the LCD backlight from the board file if the FB driver is not configured. --Imre The question is - where should this timer be implemented? - As part of the backlight driver? OR - As part of the fb driver? OR - Should it be tied to the board initialization? Best regards, Sanjeev -- 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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Fri, Feb 20, 2009 at 02:23:33PM +0100, Anand Gadiyar wrote: That's not true. I do care. It __is__ important to me that OMAP support goes to mainline. And I do not like it that it hasn't happened yet. Sorry. What happened with EHCI here is kind of similar to what you've done with MUSB patches recently anyway. sure... but then Dave helped right... We had some discussions off list in order for that to happen. Well, I'm not here to flood the list discussing this kinds of issues with you. Standard behavior for you. That's the way you end all discussions that go beyond 5 mails! yeah... for sure. If you wanna keep discussing it, just keep sending your mails... -- 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
[PATCH 0/2] twl4030-madc fixes
Hello, Two fixes for twl4030-madc: - The first one converts the ioctl to unlocked one. - The second one should return the conversion status to user quicker, both in OK and timeout cases. There's also fix for the timeout case (currently the request remains active) and some cleanup. A. -- 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] twl4030-madc: Let the operation complete faster
No need to wait before the first read, as the operation is likely
completed already. For timeout 50 milliseconds is an overkill, poll the
register for the duration of 5 milliseconds at maximum.
Also, clear the active flag in case of timeout.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
drivers/i2c/chips/twl4030-madc.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-madc.c b/drivers/i2c/chips/twl4030-madc.c
index 8997381..d3e0a7f 100644
--- a/drivers/i2c/chips/twl4030-madc.c
+++ b/drivers/i2c/chips/twl4030-madc.c
@@ -246,24 +246,28 @@ static inline void twl4030_madc_start_conversion(struct
twl4030_madc_data *madc,
}
}
-static void twl4030_madc_wait_conversion_ready_ms(
+static int twl4030_madc_wait_conversion_ready(
struct twl4030_madc_data *madc,
- u8 *time, u8 status_reg)
+ unsigned int timeout_ms, u8 status_reg)
{
- u8 reg = 0;
+ unsigned long timeout;
+ timeout = jiffies + msecs_to_jiffies(timeout_ms);
do {
- msleep(1);
- (*time)--;
+ u8 reg;
+
reg = twl4030_madc_read(madc, status_reg);
- } while (((reg TWL4030_MADC_BUSY) !(reg TWL4030_MADC_EOC_SW))
- (*time != 0));
+ if (!(reg TWL4030_MADC_BUSY) (reg TWL4030_MADC_EOC_SW))
+ return 0;
+ } while (!time_after(jiffies, timeout));
+
+ return -EAGAIN;
}
int twl4030_madc_conversion(struct twl4030_madc_request *req)
{
const struct twl4030_madc_conversion_method *method;
- u8 wait_time, ch_msb, ch_lsb;
+ u8 ch_msb, ch_lsb;
int ret;
if (unlikely(!req))
@@ -310,12 +314,10 @@ int twl4030_madc_conversion(struct twl4030_madc_request
*req)
the_madc-requests[req-method].active = 1;
/* Wait until conversion is ready (ctrl register returns EOC) */
- wait_time = 50;
- twl4030_madc_wait_conversion_ready_ms(the_madc,
- wait_time, method-ctrl);
- if (wait_time == 0) {
+ ret = twl4030_madc_wait_conversion_ready(the_madc, 5, method-ctrl);
+ if (ret) {
dev_dbg(the_madc-dev, conversion timeout!\n);
- ret = -EAGAIN;
+ the_madc-requests[req-method].active = 0;
goto out;
}
--
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] twl4030-madc: Convert ioctl to unlocked
Use unlocked ioctl instead of taking the BKL for an operation that can
take some milliseconds. The driver mutex is now taken before the active
status check, so that the concurrent users of this ioctl won't start
seeing EBUSY (previously guaranteed by the BKL).
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
drivers/i2c/chips/twl4030-madc.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-madc.c b/drivers/i2c/chips/twl4030-madc.c
index 19dacf5..8997381 100644
--- a/drivers/i2c/chips/twl4030-madc.c
+++ b/drivers/i2c/chips/twl4030-madc.c
@@ -269,17 +269,19 @@ int twl4030_madc_conversion(struct twl4030_madc_request
*req)
if (unlikely(!req))
return -EINVAL;
+ mutex_lock(the_madc-lock);
+
/* Do we have a conversion request ongoing */
- if (the_madc-requests[req-method].active)
- return -EBUSY;
+ if (the_madc-requests[req-method].active) {
+ ret = -EBUSY;
+ goto out;
+ }
ch_msb = (req-channels 8) 0xff;
ch_lsb = req-channels 0xff;
method = twl4030_conversion_methods[req-method];
- mutex_lock(the_madc-lock);
-
/* Select channels to be converted */
twl4030_madc_write(the_madc, method-sel + 1, ch_msb);
twl4030_madc_write(the_madc, method-sel, ch_lsb);
@@ -366,8 +368,8 @@ static int twl4030_madc_set_power(struct twl4030_madc_data
*madc, int on)
return 0;
}
-static int twl4030_madc_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+static long twl4030_madc_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
{
struct twl4030_madc_user_parms par;
int val, ret;
@@ -413,7 +415,7 @@ static int twl4030_madc_ioctl(struct inode *inode, struct
file *filp,
static struct file_operations twl4030_madc_fileops = {
.owner = THIS_MODULE,
- .ioctl = twl4030_madc_ioctl
+ .unlocked_ioctl = twl4030_madc_ioctl
};
static struct miscdevice twl4030_madc_device = {
--
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: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)
On Fri, Feb 20, 2009 at 06:27:14PM +0530, Gadiyar, Anand wrote: ... If you want help with testing, I can give it to you. If not, you can test it yourself - I couldn't care less. It would be nice to know if your venerable employer (TI) share your opinion?... -otto -- 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: SDIO broken in 2.6.29?
* Steve Sakoman sako...@gmail.com [090219 22:38]: Overo has a wifi chip on mmc2 that uses the libertas_sdio driver. I've had my head down working in other areas and failed to noticed that at some point in the 2.6.29 rc cycle SDIO stopped working. I'll start bisecting tomorrow morning, but thought I would ask first to see if anyone else has noticed issues in this area. I wonder if it happened when we switched to the mainline version of omap_hsmmc.c? Anyways at least now most of the code is in the mainline :) So hopefully we can get that fix in too during the -rc cycle. 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: Fix for Zero sized arch/arm/mach-integrator/clock.h on distclean
* Aguirre Rodriguez, Sergio Alberto saagui...@ti.com [090126 15:14]: Hi Tony, I noticed that when doing distclean on the tree, I keep receiving a changed file when I request a distclean: Sorry for the delay in replying.. Looks like this is no longer a problem. Regards, Tony saagui...@x0091359-linux:~/linux-omap-2.6$ git status # On branch camera-submit-6-nokiafixes # Changed but not updated: # (use git add/rm file... to update what will be committed) # # deleted:arch/arm/mach-integrator/clock.h # no changes added to commit (use git add and/or git commit -a) I noticed that this is because a zero sized file existed in mainline, instead of being adequately deleted. But I also noticed that there is a fix for this already by Andrew Price: http://marc.info/?l=linux-kernelm=123134235028543w=2 Is it possible to pull this fix into the l-o tree? Thanks and regards, Sergio -- 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: Fix for Zero sized arch/arm/mach-integrator/clock.h on distclean
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, February 20, 2009 10:18 AM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-omap@vger.kernel.org Subject: Re: Fix for Zero sized arch/arm/mach-integrator/clock.h on distclean * Aguirre Rodriguez, Sergio Alberto saagui...@ti.com [090126 15:14]: Hi Tony, I noticed that when doing distclean on the tree, I keep receiving a changed file when I request a distclean: Sorry for the delay in replying.. Looks like this is no longer a problem. ... That's ok. This problem was present a month ago, so pulling from mainline fixed this. Regards, Tony saagui...@x0091359-linux:~/linux-omap-2.6$ git status # On branch camera-submit-6-nokiafixes # Changed but not updated: # (use git add/rm file... to update what will be committed) # # deleted:arch/arm/mach-integrator/clock.h # no changes added to commit (use git add and/or git commit -a) I noticed that this is because a zero sized file existed in mainline, instead of being adequately deleted. But I also noticed that there is a fix for this already by Andrew Price: http://marc.info/?l=linux-kernelm=123134235028543w=2 Is it possible to pull this fix into the l-o tree? Thanks and regards, Sergio -- 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: [PATCH v2] board-omap3beagle: set i2c-3 to 100kHz
* Tony Lindgren t...@atomide.com [090206 14:56]: * Koen Kooi k.k...@student.utwente.nl [090206 06:16]: Op 4 feb 2009, om 20:58 heeft Koen Kooi het volgende geschreven: Op 25 jan 2009, om 13:04 heeft David Brownell het volgende geschreven: On Sunday 25 January 2009, Koen Kooi wrote: From: Koen Kooi k...@beagleboard.org Changing it do 100kHz is needed to make more devices works properly. Controlling the TI DLP Pico projector[1] doesn't work properly at 400kHz, 100kHz and lower work fine. EDID readout is unaffected by this change. [1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60tabId=2234 Signed-off-by: Koen Kooi k...@beagleboard.org Acked-by: David Brownell dbrown...@users.sourceforge.net ping Any more changes needed before this can go in? Just few more days, I'll need to get my upstream queues ready.. Otherwise I'll forget to apply it somewhere :) OK, adding to omap-fixes and pushing to linux-omap. 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] usb: musb: adding support for registering nop xceiv
* Gupta, Ajay Kumar ajay.gu...@ti.com [090119 02:39]:
-Original Message-
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Tuesday, January 13, 2009 4:00 AM
To: Gupta, Ajay Kumar
Cc: linux-omap@vger.kernel.org; davi...@pacbell.net; felipe.ba...@nokia.com
Subject: Re: [PATCH] usb: musb: adding support for registering nop xceiv
On Thu, Jan 08, 2009 at 04:23:56PM +0530, Ajay Kumar Gupta wrote:
Adding support for registering nop usb transceiver for musb
platforms. Tested with OMAP35xx EVM having OTG phy ISP1504
which is autonomous and doesn't require any phy programming.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Tony, if Dave is ok with the nop-xceiv, we can apply this to l-o and
people who doesn't use twl4030/tlw5030 xceiv will have to select this
driver.
Hi David,
Please review this one too.
According to Felipe this is in Greg's queue, so I'll apply this to
linux-omap to wait for it to fall down from mainline.
Tony
Regards,
Ajay
---
arch/arm/mach-omap2/usb-musb.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c
b/arch/arm/mach-omap2/usb-musb.c
index 61c5709..c202256 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -155,10 +155,29 @@ static struct platform_device musb_device = {
};
#endif
+#ifdef CONFIG_NOP_USB_XCEIV
+static u64 nop_xceiv_dmamask = DMA_32BIT_MASK;
+
+static struct platform_device nop_xceiv_device = {
+ .name = nop_usb_xceiv,
+ .id = -1,
+ .dev = {
+ .dma_mask = nop_xceiv_dmamask,
+ .coherent_dma_mask = DMA_32BIT_MASK,
+ .platform_data = NULL,
+ },
+};
+#endif
void __init usb_musb_init(void)
{
#ifdef CONFIG_USB_MUSB_SOC
+#ifdef CONFIG_NOP_USB_XCEIV
+ if (platform_device_register(nop_xceiv_device) 0) {
+ printk(KERN_ERR Unable to register NOP-XCEIV device\n);
+ return;
+ }
+#endif
if (platform_device_register(musb_device) 0) {
printk(KERN_ERR Unable to register HS-USB (MUSB) device\n);
return;
--
1.5.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
--
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
--
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: adding support for registering nop xceiv
On Fri, Feb 20, 2009 at 08:41:40AM -0800, Tony Lindgren wrote: * Gupta, Ajay Kumar ajay.gu...@ti.com [090119 02:39]: -Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Tuesday, January 13, 2009 4:00 AM To: Gupta, Ajay Kumar Cc: linux-omap@vger.kernel.org; davi...@pacbell.net; felipe.ba...@nokia.com Subject: Re: [PATCH] usb: musb: adding support for registering nop xceiv On Thu, Jan 08, 2009 at 04:23:56PM +0530, Ajay Kumar Gupta wrote: Adding support for registering nop usb transceiver for musb platforms. Tested with OMAP35xx EVM having OTG phy ISP1504 which is autonomous and doesn't require any phy programming. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Tony, if Dave is ok with the nop-xceiv, we can apply this to l-o and people who doesn't use twl4030/tlw5030 xceiv will have to select this driver. Hi David, Please review this one too. According to Felipe this is in Greg's queue, so I'll apply this to linux-omap to wait for it to fall down from mainline. well, the driver itself, not the usb-musb.c part. Well, this will help boards with use isp transceivers to work :-) -- 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 v2] board-omap3beagle: set i2c-3 to 100kHz
Op 20 feb 2009, om 17:25 heeft Tony Lindgren het volgende geschreven: * Tony Lindgren t...@atomide.com [090206 14:56]: * Koen Kooi k.k...@student.utwente.nl [090206 06:16]: Op 4 feb 2009, om 20:58 heeft Koen Kooi het volgende geschreven: Op 25 jan 2009, om 13:04 heeft David Brownell het volgende geschreven: On Sunday 25 January 2009, Koen Kooi wrote: From: Koen Kooi k...@beagleboard.org Changing it do 100kHz is needed to make more devices works properly. Controlling the TI DLP Pico projector[1] doesn't work properly at 400kHz, 100kHz and lower work fine. EDID readout is unaffected by this change. [1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60tabId=2234 Signed-off-by: Koen Kooi k...@beagleboard.org Acked-by: David Brownell dbrown...@users.sourceforge.net ping Any more changes needed before this can go in? Just few more days, I'll need to get my upstream queues ready.. Otherwise I'll forget to apply it somewhere :) OK, adding to omap-fixes and pushing to linux-omap. Thanks! PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: ohci patches sitting in linux-omap only
* Felipe Balbi m...@felipebalbi.com [090219 13:43]: Hi Tony, all, if you don't have any objections, I'll send the following patches to linux-usb as soon as possible, they've being sitting in linux-omap only for a while already (they're all to ohci-omap.c): David Brownell (1): ARM: OMAP: switch to gpio_direction_input Jarkko Nikula (1): ARM: OMAP: Switch ohci-omap to gpio_request/free calls Russell King (2): [ARM] omap: convert OMAP drivers to use ioremap() [ARM] omap: ensure OMAP drivers pass a struct device to clk_get() Tony Lindgren (1): USB: ohci-omap: handle other omap15xx chips Hmm, yeah I thought some of these were already getting queued up.. If not, sure please try to get them merged. 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/1] Export dmtimer functions
* Timo Kokkonen timo.t.kokko...@nokia.com [090130 01:23]:
Make the dmtimer function symbols available so modules can take use of
them.
Adding to omap-upstream for next merge window pushing to linux-omap.
Tony
Signed-off-by: Timo Kokkonen timo.t.kokko...@nokia.com
---
arch/arm/plat-omap/dmtimer.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index ed397f0..a05205c 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -33,6 +33,7 @@
#include linux/clk.h
#include linux/delay.h
#include linux/io.h
+#include linux/module.h
#include mach/hardware.h
#include mach/dmtimer.h
#include mach/irqs.h
@@ -360,6 +361,7 @@ struct omap_dm_timer *omap_dm_timer_request(void)
return timer;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_request);
struct omap_dm_timer *omap_dm_timer_request_specific(int id)
{
@@ -383,6 +385,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int
id)
return timer;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
void omap_dm_timer_free(struct omap_dm_timer *timer)
{
@@ -393,6 +396,7 @@ void omap_dm_timer_free(struct omap_dm_timer *timer)
WARN_ON(!timer-reserved);
timer-reserved = 0;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_free);
void omap_dm_timer_enable(struct omap_dm_timer *timer)
{
@@ -404,6 +408,7 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
timer-enabled = 1;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
void omap_dm_timer_disable(struct omap_dm_timer *timer)
{
@@ -415,11 +420,13 @@ void omap_dm_timer_disable(struct omap_dm_timer *timer)
timer-enabled = 0;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
{
return timer-irq;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
#if defined(CONFIG_ARCH_OMAP1)
@@ -450,6 +457,7 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
return inputmask;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
#elif defined(CONFIG_ARCH_OMAP2) || defined (CONFIG_ARCH_OMAP3)
@@ -457,6 +465,7 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer
*timer)
{
return timer-fclk;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
__u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
{
@@ -464,6 +473,7 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
return 0;
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
#endif
@@ -471,6 +481,7 @@ void omap_dm_timer_trigger(struct omap_dm_timer *timer)
{
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
void omap_dm_timer_start(struct omap_dm_timer *timer)
{
@@ -482,6 +493,7 @@ void omap_dm_timer_start(struct omap_dm_timer *timer)
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
}
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_start);
void omap_dm_timer_stop(struct omap_dm_timer *timer)
{
@@ -493,6 +505,7 @@ void omap_dm_timer_stop(struct omap_dm_timer *timer)
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
}
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
#ifdef CONFIG_ARCH_OMAP1
@@ -505,6 +518,7 @@ void omap_dm_timer_set_source(struct omap_dm_timer
*timer, int source)
l |= source n;
omap_writel(l, MOD_CONF_CTRL_1);
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
#else
@@ -521,6 +535,7 @@ void omap_dm_timer_set_source(struct omap_dm_timer
*timer, int source)
* cause an abort. */
__delay(15);
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
#endif
@@ -539,6 +554,7 @@ void omap_dm_timer_set_load(struct omap_dm_timer *timer,
int autoreload,
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_load);
/* Optimized set_load which removes costly spin wait in timer_start */
void omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int
autoreload,
@@ -558,6 +574,7 @@ void omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load);
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_load_start);
void omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
unsigned int match)
@@ -572,6 +589,7 @@ void omap_dm_timer_set_match(struct omap_dm_timer *timer,
int enable,
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG, match);
}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_match);
void omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
int toggle, int
OMAP3530 USB host problems
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP3530 USB host problems
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
--
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] I2C: OMAP: Add missing wakeup events
* Pakaravoor, Jagadeesh j-pakarav...@ti.com [090202 07:28]: Hi, Is it a necesary bugfix, or should it wait for the next merge window? You can line it up for the next merge window. Just for references, I'm assuming that Ben has picked up this for his queue, so not adding it to any of my ustream queues. Acked-by: Tony Lindgren t...@atomide.com 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: OMAP3530 USB host problems
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP3530 USB host problems
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
--
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: [RFC 3/3] ARM: OMAP: Add method to register additional I2C busses on the command line
* Jarkko Nikula jarkko.nik...@nokia.com [090209 00:00]:
This patch extends command line option i2c_bus=bus_id,clkrate so that
it allow to register additional I2C busses that are not registered with
omap_register_i2c_bus from board initialization code.
Purpose of this is to register additional board busses which are routed
to external connectors only without any on board I2C devices.
Adding all three to omap-upstream and pushing to linux-omap.
Tony
Signed-off-by: Jarkko Nikula jarkko.nik...@nokia.com
---
arch/arm/plat-omap/i2c.c | 73 -
1 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index aa70e43..a303071 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -98,6 +98,8 @@ static const int omap34xx_pins[][2] = {
static const int omap34xx_pins[][2] = {};
#endif
+#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -133,6 +135,31 @@ static int __init omap_i2c_nr_ports(void)
return ports;
}
+static int __init omap_i2c_add_bus(int bus_id)
+{
+ struct platform_device *pdev;
+ struct resource *res;
+ resource_size_t base, irq;
+
+ pdev = omap_i2c_devices[bus_id - 1];
+ if (bus_id == 1) {
+ res = pdev-resource;
+ if (cpu_class_is_omap1()) {
+ base = OMAP1_I2C_BASE;
+ irq = INT_I2C;
+ } else {
+ base = OMAP2_I2C_BASE1;
+ irq = INT_24XX_I2C1_IRQ;
+ }
+ res[0].start = base;
+ res[0].end = base + OMAP_I2C_SIZE;
+ res[1].start = irq;
+ }
+
+ omap_i2c_mux_pins(bus_id - 1);
+ return platform_device_register(pdev);
+}
+
/**
* omap_i2c_bus_setup - Process command line options for the I2C bus speed
* @str: String of options
@@ -154,11 +181,33 @@ static int __init omap_i2c_bus_setup(char *str)
if (ints[0] 2 || ints[1] 1 || ints[1] ports)
return 0;
i2c_rate[ints[1] - 1] = ints[2];
+ i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
__setup(i2c_bus=, omap_i2c_bus_setup);
+/*
+ * Register busses defined in command line but that are not registered with
+ * omap_register_i2c_bus from board initialization code.
+ */
+static int __init omap_register_i2c_bus_cmdline(void)
+{
+ int i, err = 0;
+
+ for (i = 0; i ARRAY_SIZE(i2c_rate); i++)
+ if (i2c_rate[i] OMAP_I2C_CMDLINE_SETUP) {
+ i2c_rate[i] = ~OMAP_I2C_CMDLINE_SETUP;
+ err = omap_i2c_add_bus(i + 1);
+ if (err)
+ goto out;
+ }
+
+out:
+ return err;
+}
+subsys_initcall(omap_register_i2c_bus_cmdline);
+
/**
* omap_register_i2c_bus - register I2C bus with device descriptors
* @bus_id: bus id counting from number 1
@@ -173,9 +222,6 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
unsigned len)
{
int err;
- struct platform_device *pdev;
- struct resource *res;
- resource_size_t base, irq;
BUG_ON(bus_id 1 || bus_id omap_i2c_nr_ports());
@@ -185,24 +231,9 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- pdev = omap_i2c_devices[bus_id - 1];
- if (i2c_rate[bus_id - 1] == 0)
+ if (!i2c_rate[bus_id - 1])
i2c_rate[bus_id - 1] = clkrate;
+ i2c_rate[bus_id - 1] = ~OMAP_I2C_CMDLINE_SETUP;
- if (bus_id == 1) {
- res = pdev-resource;
- if (cpu_class_is_omap1()) {
- base = OMAP1_I2C_BASE;
- irq = INT_I2C;
- } else {
- base = OMAP2_I2C_BASE1;
- irq = INT_24XX_I2C1_IRQ;
- }
- res[0].start = base;
- res[0].end = base + OMAP_I2C_SIZE;
- res[1].start = irq;
- }
-
- omap_i2c_mux_pins(bus_id - 1);
- return platform_device_register(pdev);
+ return omap_i2c_add_bus(bus_id);
}
--
1.5.6.5
--
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: OMAP3530 USB host problems
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: McSPI3 on the BeagleBoard
Gregoire Gentil wrote: Philip, I found the patch. Thanks. SPI3 is working for me too but I think that there are a couple of errors: - first, in the patch you posted on the beagleboard mailing list, you don't setup CS0 and CS1 pins in u-boot. I think that you should do it. Yeah. I wanted to get the info out quickly since there are a couple of longish threads on the Beagle list over the problem. - secondly, you have added more mux configuration in the kernel for SPI3 that should not be SPI3 but those new ones are wrong as they are competing with some USB pins. It's the same error as David pointed you for MMC2. Nevertheless, it's still working. Why? Because I have now a strong feeling that mux configuration is not working in the kernel (at least for the beagleboard). Here are a few facts that would confirm this statement: I thought I #if 0 ... #endif the kernel mux code? I'll double check. I should try it with un patched u-boot and only the specific pins set in the kernel. I'm juggling too many different things atm :( I also changed the PIN MUX config option in the flag per another question. Philip - MUX setup for USB ehci has never worked in the kernel. It's why the beagleaboard rev-C ehci patch has been transfered to u-boot. - the difference between your patch before and after it was working, is really the u-boot configuration. You haven't really changed anything in the kernel (especially in the spi driver) and as mentioned above, you have even introduced some competing muxes that should have created more trouble if the kernel mux config were working correctly. - I had two other areas where I configured the pins in kernel and it was not working. Only when I eventually did it in u-boot, it started to work. I don't know what's wrong with the pin configuration in the kernel, Grégoire On Thu, 2009-02-19 at 09:14 -0500, Philip Balister wrote: Gregoire Gentil wrote: Philip, Can you please post here or on the Beagleboard mailing list the u-boot patch? This muxpin is very tricky and I have experienced many problems when set up in the kernel while it seems to work better from u-boot - don't know why, I posted it to the Beagle group. Let me know if you are having trouble finding it. If we come up with a better config for the expansion port, we'll clean it up and submit here. My gut feeling is having SPI interfaces on the expansion connector will be more useful then the MMC interface. Philip -- 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: OMAP3530 USB host problems
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
--
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: OMAP3530 USB host problems
On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
Sadly, I've already tried this and things just continue to fall apart.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
Internal error: : 1008 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-omap1-svn4799-dirty14 #60)
PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
LR is at release_console_sem+0x1a8/0x1d8
Hence, my desired to figure out the TLL timeout...
keep TLL as is, the problem now seems to be a clock that should be on
and is off. Try to figure (with printk() for example) at which line the
code stops, put printk() before and after register read/write operations
during probe and omap_start_ehc(), let's see where does it dies.
--
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 omap-fixes] OMAP2/3: GPIO: remove recursion in IRQ wakeup path
* Kevin Hilman khil...@deeprootsystems.com [090210 16:42]: David Brownell davi...@pacbell.net writes: On Wednesday 28 January 2009, Kevin Hilman wrote: Now that the generic IRQ and GPIO frameworks are used for enabling and disabling GPIO IRQ wakeup sources, there is no longer a need to call [enable|disable]_irq_wake() in the low-level code. Doing so results in recursive calls to [enable|disable]_irq_wake(). Could you clarify what actually made that requirement go away? The recursion was introduced -- using the generic IRQ framework! -- as a simple way to ensure the parent IRQ was properly wake-enabled. Is the issue that something changed, so that something else wake-enables the parent? My description was not very descriptive... sorry... From what I can understand here, I don't see the point in wake-enabling the parent IRQ since there is no wakeup glue for the bank IRQs, thus these calls are actually failing and causing 'unbalanced IRQ disable' noise in the generic IRQ layer. Here is what is happening. Consider the gpio-keys driver. Upon suspend, it enables the IRQ wake for its GPIO. The OMAP GPIO code then calls enable_wake_irq() for the parent irq (the GPIO bank IRQ). This call is actually failing because the bank IRQ has no 'set_wake' method. Because of this failure, the generic IRQ code doesn't actually do anything, and sets the 'disable_depth' to zero for the bank IRQ. Then, upon resume, the resume path disables IRQ wakeups for the GPIO. The OMAP GPIO code then tries to call disable_irq_wake() for the bank IRQ and you get noisy 'unbalanced IRQ disable' warnings from the generic IRQ layere because of the attempt to disable the IRQ wake of an IRQ that was never enabled. So the options that I see are: 1) fix the OMAP GPIO code to check the return code of the parent enable, or 2) drop the parent enable/disable I prefer (1) since those calls will always fail AFAICT. Does that make any sense? If you're OK with (1), I will re-issue the patch with a better discription. Ignoring this for now, please let me know if you want me to queue this for omap-upstream with the updates mentioned above. 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] OMAP: McBSP: Wakeups utilized
* ext-eero.nurkk...@nokia.com ext-eero.nurkk...@nokia.com [090122 22:49]:
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
This patch enables the smart idle mode while
McBPS is being utilized. Once it's done,
force idle mode is taken instead.
Adding to omap-upstream and pushing to linux-omap.
Tony
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h | 16
arch/arm/plat-omap/mcbsp.c | 28
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 113c246..7232950 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -249,8 +249,24 @@
#define RDISABLE 0x0001
/** McBSP SYSCONFIG bit definitions /
+#define SIDLEMODE(value) ((value)3)
+#define ENAWAKEUP0x0004
#define SOFTRST 0x0002
+/** McBSP WAKEUPEN bit definitions */
+#define XEMPTYEOFEN 0x4000
+#define XRDYEN 0x0400
+#define XEOFEN 0x0200
+#define XFSXEN 0x0100
+#define XSYNCERREN 0x0080
+#define RRDYEN 0x0008
+#define REOFEN 0x0004
+#define RFSREN 0x0002
+#define RSYNCERREN 0x0001
+#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
+ XSYNCERREN | RRDYEN | REOFEN | RFSREN | \
+ RSYNCERREN)
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e5842e3..ce9d09f 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -216,6 +216,7 @@ int omap_mcbsp_request(unsigned int id)
struct omap_mcbsp *mcbsp;
int i;
int err;
+ u16 syscon;
if (!omap_mcbsp_check_valid_id(id)) {
printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
@@ -241,6 +242,19 @@ int omap_mcbsp_request(unsigned int id)
spin_unlock(mcbsp-lock);
/*
+ * Enable wakup behavior, smart idle and all wakeups
+ * REVISIT: some wakeups may be unnecessary
+ */
+ if (cpu_is_omap34xx()) {
+ syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
+ syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
+ syscon |= (ENAWAKEUP | SIDLEMODE(0x02));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
+
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, WAKEUPEN_ALL);
+ }
+
+ /*
* Make sure that transmitter, receiver and sample-rate generator are
* not running before activating IRQs.
*/
@@ -278,6 +292,7 @@ EXPORT_SYMBOL(omap_mcbsp_request);
void omap_mcbsp_free(unsigned int id)
{
struct omap_mcbsp *mcbsp;
+ u16 syscon, wakeupen;
int i;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -286,6 +301,19 @@ void omap_mcbsp_free(unsigned int id)
}
mcbsp = id_to_mcbsp_ptr(id);
+ /*
+ * Disable wakup behavior, smart idle and all wakeups
+ */
+ if (cpu_is_omap34xx()) {
+ syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
+ syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
+
+ wakeupen = OMAP_MCBSP_READ(mcbsp-io_base, WAKEUPEN);
+ wakeupen = ~WAKEUPEN_ALL;
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, wakeupen);
+ }
+
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-free)
mcbsp-pdata-ops-free(id);
--
1.6.0
--
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: [PATCH] hsmmc: Add MMC3 support
* David Brownell davi...@pacbell.net [090208 11:42]: On Tuesday 27 January 2009, Grazvydas Ignotas wrote: Device connected to MMC3 is assumed to be self-powered, so set_power() function is empty. It can't be omited because host driver requires it. Array size for hsmmc[] is specified because hsmmc[2].name is needed for MMC3 name. Just for the record ... this should eventually be handled using the regulator framework, which will also help with the decoupling of hsmmc setup from twl4030 setup. So for example if a given slot is hooked up to an SDIO chip with a hard-wired 3v3 supply (Pandora MMC3, and Overo MMC2) then it'd have a fixed voltage regulator; and the HSMMC driver would just use that. (It would get a can't do that error on disable though.) Adding to omap3-upstream and pushing to linux-omap. 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] ARM: Add SMSC911X support to Overo platform (V2)
* Steve Sakoman sako...@gmail.com [090201 22:28]:
Gumstix will soon be shipping a variant of their Summit board that
includes an SMSC LAN9221 ethernet interface. This patch provides
support via the smsc911x driver when enabled in kernel config.
The Overo defconfig is not updated since the LAN9221 is an option
not present on all systems.
Adding this to omap3-upstream and pushing to linux-omap.
Tony
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/mach-omap2/board-overo.c | 62
+
arch/arm/plat-omap/include/mach/board-overo.h |3 +
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 9995ac2..032a2c9 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -55,6 +55,67 @@
#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+
+#include linux/smsc911x.h
+
+static struct resource overo_smsc911x_resources[] = {
+ {
+ .name = smsc911x-memory,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+static struct smsc911x_platform_config overo_smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT ,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device overo_smsc911x_device = {
+ .name = smsc911x,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(overo_smsc911x_resources),
+ .resource = overo_smsc911x_resources,
+ .dev= {
+ .platform_data = overo_smsc911x_config,
+ },
+};
+
+static inline void __init overo_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(OVERO_SMSC911X_CS, SZ_16M, cs_mem_base) 0) {
+ printk(KERN_ERR Failed request for GPMC mem for smsc911x\n);
+ return;
+ }
+
+ overo_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ overo_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(OVERO_SMSC911X_GPIO, SMSC911X IRQ) == 0)
+ (gpio_direction_input(OVERO_SMSC911X_GPIO) == 0)) {
+ gpio_export(OVERO_SMSC911X_GPIO, 0);
+ } else {
+ printk(KERN_ERR could not obtain gpio for SMSC911X IRQ\n);
+ return;
+ }
+
+ overo_smsc911x_resources[1].start = OMAP_GPIO_IRQ(OVERO_SMSC911X_GPIO);
+ overo_smsc911x_resources[1].end = 0;
+
+ platform_device_register(overo_smsc911x_device);
+}
+
+#else
+static inline void __init overo_init_smsc911x(void) { return; }
+#endif
+
static struct mtd_partition overo_nand_partitions[] = {
{
.name = xloader,
@@ -234,6 +295,7 @@ static void __init overo_init(void)
usb_musb_init();
usb_ehci_init();
overo_flash_init();
+ overo_init_smsc911x();
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
OVERO_GPIO_W2W_NRESET) == 0)
diff --git a/arch/arm/plat-omap/include/mach/board-overo.h
b/arch/arm/plat-omap/include/mach/board-overo.h
index 7ecae66..8635171 100644
--- a/arch/arm/plat-omap/include/mach/board-overo.h
+++ b/arch/arm/plat-omap/include/mach/board-overo.h
@@ -22,5 +22,8 @@
#define OVERO_GPIO_USBH_CPEN 168
#define OVERO_GPIO_USBH_NRESET 183
+#define OVERO_SMSC911X_CS5
+#define OVERO_SMSC911X_GPIO 176
+
#endif /* ASM_ARCH_OVERO_H */
--
1.5.6.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
Re: [PATCH/RFC] ARM: Add ADS7846 touchscreen support to Overo platform
* Steve Sakoman sako...@gmail.com [090201 22:42]:
An upcoming Overo expansion board includes an ADS7846 touchscreen controller.
This patch adds support via the ads7846 driver when enabled in the
kernel config.
Adding this also to omap3-upstream and linux-omap.
Tony
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/mach-omap2/board-overo.c | 61
+
arch/arm/plat-omap/include/mach/board-overo.h |1 +
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 032a2c9..2521b21 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -116,6 +116,66 @@ static inline void __init overo_init_smsc911x(void)
static inline void __init overo_init_smsc911x(void) { return; }
#endif
+#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
+ defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
+
+#include mach/mcspi.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
+
+static struct omap2_mcspi_device_config ads7846_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,/* 0: slave, 1: master */
+};
+
+
+static int ads7846_get_pendown_state(void)
+{
+ return !gpio_get_value(OVERO_GPIO_PENDOWN);
+}
+
+static struct ads7846_platform_data ads7846_config = {
+ .x_max = 0x0fff,
+ .y_max = 0x0fff,
+ .x_plate_ohms = 180,
+ .pressure_max = 255,
+ .debounce_max = 10,
+ .debounce_tol = 3,
+ .debounce_rep = 1,
+ .get_pendown_state = ads7846_get_pendown_state,
+ .keep_vref_on = 1,
+};
+
+static struct spi_board_info overo_spi_board_info[] __initdata = {
+ {
+ .modalias = ads7846,
+ .bus_num= 1,
+ .chip_select= 0,
+ .max_speed_hz = 150,
+ .controller_data= ads7846_mcspi_config,
+ .irq= OMAP_GPIO_IRQ(OVERO_GPIO_PENDOWN),
+ .platform_data = ads7846_config,
+ }
+};
+
+static void __init overo_ads7846_init(void)
+{
+ if ((gpio_request(OVERO_GPIO_PENDOWN, ADS7846_PENDOWN) == 0)
+ (gpio_direction_input(OVERO_GPIO_PENDOWN) == 0)) {
+ gpio_export(OVERO_GPIO_PENDOWN, 0);
+ } else {
+ printk(KERN_ERR could not obtain gpio for ADS7846_PENDOWN\n);
+ return;
+ }
+
+ spi_register_board_info(overo_spi_board_info,
+ ARRAY_SIZE(overo_spi_board_info));
+}
+
+#else
+static inline void __init overo_ads7846_init(void) { return; }
+#endif
+
static struct mtd_partition overo_nand_partitions[] = {
{
.name = xloader,
@@ -296,6 +356,7 @@ static void __init overo_init(void)
usb_ehci_init();
overo_flash_init();
overo_init_smsc911x();
+ overo_ads7846_init();
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
OVERO_GPIO_W2W_NRESET) == 0)
diff --git a/arch/arm/plat-omap/include/mach/board-overo.h
b/arch/arm/plat-omap/include/mach/board-overo.h
index 8635171..aca717d 100644
--- a/arch/arm/plat-omap/include/mach/board-overo.h
+++ b/arch/arm/plat-omap/include/mach/board-overo.h
@@ -18,6 +18,7 @@
#define OVERO_GPIO_BT_XGATE 15
#define OVERO_GPIO_W2W_NRESET16
+#define OVERO_GPIO_PENDOWN 114
#define OVERO_GPIO_BT_NRESET 164
#define OVERO_GPIO_USBH_CPEN 168
#define OVERO_GPIO_USBH_NRESET 183
--
1.5.6.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
Re: omap_apollon_2420_defconfig
On Tue, Feb 10, 2009 at 10:54:25AM +0900, Kyungmin Park wrote: In the previous patch, it's only fixed host side. But apollon case, it only used udc, so udc configuration should select USB_OTG_UTILS also. So, it's 10 days later, mainline is still broken. In fact, this is now the only ARM defconfig which is failing. What's happening? Is someone going to ack this patch? Is it going to be submitted to me or is it going to be submitted via some USB tree? Sick of chasing people about build errors. People here need to get off their lazy backsides, check kautobuild regularly and submit build fixes. -- 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: [pacth] I2C bug fixes for L-O and L-Z
Eero, From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com] On Mon, 2009-02-16 at 15:19 +0100, ext Woodruff, Richard wrote: Hi, Could you please also address the question of the load on the SCL line? Are you talking about rise/fall time? Sorry for being unclear; The I2C standard addresses also rise/fall times, but more interesting, the tLow and tHigh (and a number of other parameters). It seems with the open source drivers, that somehow they're after a balanced I2C clock meaning tLow == tHigh, which is very, very dangerous. Oh, I see. I didn't look at that angle. I can inquire/look. For sure wave forms on O-Scope and LA showed variable data line times, sometimes longer then one would expect (for stop/start/ack). But yes, clocks were pretty even iirc. I received the following comment from a HW Apps person whom has dealt with this at the board level. comment start Attached is the I2C spec that I have. As I understand it, the I2C only specify the minimum tLow and tHigh (which is not balanced). However what is more important is that the appropriate setup and hold time are followed. If the equal time still meets the setup/hold time then there should not be any issue from a compliance standpoint. comment end Regards, Richard W. -- 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: omap_apollon_2420_defconfig
* Russell King - ARM Linux li...@arm.linux.org.uk [090220 12:58]: On Tue, Feb 10, 2009 at 10:54:25AM +0900, Kyungmin Park wrote: In the previous patch, it's only fixed host side. But apollon case, it only used udc, so udc configuration should select USB_OTG_UTILS also. So, it's 10 days later, mainline is still broken. In fact, this is now the only ARM defconfig which is failing. What's happening? Is someone going to ack this patch? Is it going to be submitted to me or is it going to be submitted via some USB tree? Well it would be nice to get an ack from the USB people, here's mine: Acked-by: Tony Lindgren t...@atomide.com Sick of chasing people about build errors. People here need to get off their lazy backsides, check kautobuild regularly and submit build fixes. How about automatic notifications on the failing omap builds sent to to linux-omap list? The 34xx builds failing because of the compiler should be filtered out until the compiler is updated though. 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] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id == OMAP_MMC1_DEVID) {
+ hctl = SDVS30;
Shouldn't it be remembering what voltage it was using,
and then restore that, instead of always making MMC1
restart at a 3.0V level? That's pretty awkward to test
unless you have a 1.8V-capable card in MMC1...
Somewhat related: I think the PBIAS register updates
should be moved out of mach-omap2/mmc-twl4030.c into
this driver. They're needed no matter what flavor
regulator is used to with MMC1 voltage over 1.8V,
and it's a bit odd to split the state machine for
1.8V -vs- 3.0V I/O voltages the way it's now done.
- Dave
--
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 omap-fixes] OMAP2/3: GPIO: remove recursion in IRQ wakeup path
Tony Lindgren wrote: * Kevin Hilman khil...@deeprootsystems.com [090210 16:42]: David Brownell davi...@pacbell.net writes: On Wednesday 28 January 2009, Kevin Hilman wrote: Now that the generic IRQ and GPIO frameworks are used for enabling and disabling GPIO IRQ wakeup sources, there is no longer a need to call [enable|disable]_irq_wake() in the low-level code. Doing so results in recursive calls to [enable|disable]_irq_wake(). Could you clarify what actually made that requirement go away? The recursion was introduced -- using the generic IRQ framework! -- as a simple way to ensure the parent IRQ was properly wake-enabled. Is the issue that something changed, so that something else wake-enables the parent? My description was not very descriptive... sorry... From what I can understand here, I don't see the point in wake-enabling the parent IRQ since there is no wakeup glue for the bank IRQs, thus these calls are actually failing and causing 'unbalanced IRQ disable' noise in the generic IRQ layer. Here is what is happening. Consider the gpio-keys driver. Upon suspend, it enables the IRQ wake for its GPIO. The OMAP GPIO code then calls enable_wake_irq() for the parent irq (the GPIO bank IRQ). This call is actually failing because the bank IRQ has no 'set_wake' method. Because of this failure, the generic IRQ code doesn't actually do anything, and sets the 'disable_depth' to zero for the bank IRQ. Then, upon resume, the resume path disables IRQ wakeups for the GPIO. The OMAP GPIO code then tries to call disable_irq_wake() for the bank IRQ and you get noisy 'unbalanced IRQ disable' warnings from the generic IRQ layere because of the attempt to disable the IRQ wake of an IRQ that was never enabled. So the options that I see are: 1) fix the OMAP GPIO code to check the return code of the parent enable, or 2) drop the parent enable/disable I prefer (1) since those calls will always fail AFAICT. Does that make any sense? If you're OK with (1), I will re-issue the patch with a better discription. Ignoring this for now, please let me know if you want me to queue this for omap-upstream with the updates mentioned above. OK. I'll re-send with updated description if above is OK with Dave. 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: omap_apollon_2420_defconfig
On Fri, Feb 20, 2009 at 01:06:44PM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090220 12:58]: On Tue, Feb 10, 2009 at 10:54:25AM +0900, Kyungmin Park wrote: In the previous patch, it's only fixed host side. But apollon case, it only used udc, so udc configuration should select USB_OTG_UTILS also. So, it's 10 days later, mainline is still broken. In fact, this is now the only ARM defconfig which is failing. Really, it's actually almost one month later. I checked. I brought this issue up 27th January and then again on 9th February and here we are *three* *and* *a* *half* *weeks* later no further forward. This is plain and simple not acceptable. What's happening? Is someone going to ack this patch? Is it going to be submitted to me or is it going to be submitted via some USB tree? Well it would be nice to get an ack from the USB people, here's mine: Acked-by: Tony Lindgren t...@atomide.com Right, so one ack which is progress. That still leaves the question about how the patch gets into mainline. Sick of chasing people about build errors. People here need to get off their lazy backsides, check kautobuild regularly and submit build fixes. How about automatic notifications on the failing omap builds sent to to linux-omap list? The 34xx builds failing because of the compiler should be filtered out until the compiler is updated though. Well, 17 days ago, the compiler was upgraded and the OMAP34xx builds started to complete. So your statement tells me that you've not looked at kautobuild for at least the last 17 days. If you want any features, please talk to the kautobuild people. I've nothing to do with kautobuild other than seemingly being the *sole* person who checks the kautobuild website and chases people when things get broken. Having done some research by reading through the kautobuild site, if you want to be mailed the results, kautobuild has its own mailing list. See http://armlinux.simtec.co.uk/kautobuild/ -- 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: omap_apollon_2420_defconfig
On Friday 20 February 2009, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090220 12:58]: On Tue, Feb 10, 2009 at 10:54:25AM +0900, Kyungmin Park wrote: In the previous patch, it's only fixed host side. But apollon case, it only used udc, so udc configuration should select USB_OTG_UTILS also. So, it's 10 days later, mainline is still broken. In fact, this is now the only ARM defconfig which is failing. What's happening? Is someone going to ack this patch? Is it going to be submitted to me or is it going to be submitted via some USB tree? Well it would be nice to get an ack from the USB people, here's mine: Acked-by: Tony Lindgren t...@atomide.com I thought this was already handled ... evidently not, so I just sent it to Greg as a buildfix. Sick of chasing people about build errors. People here need to get off their lazy backsides, check kautobuild regularly and submit build fixes. Actually the *standard* practice involves (a) bugs getting reported (b) patches getting provided (c) nagging until the patches merge I can't fault anyone for sticking to that process and not going out of their way to seek out kautobuild issues; there's already *way* too much to do. How about automatic notifications on the failing omap builds sent to to linux-omap list? The 34xx builds failing because of the compiler should be filtered out until the compiler is updated though. That's a much better solution. I'd suggest no more than one such nag message a week though. 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] usb: musb: adding support for registering nop xceiv
On Friday 20 February 2009, Tony Lindgren wrote: Please review this one too. According to Felipe this is in Greg's queue, so I'll apply this to linux-omap to wait for it to fall down from mainline. Yeah, I had some issues with it but it looks like the simplest approach for now is to add patches on top of this. - Dave -- 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] input: lm8323: apply comments from mainline
In order to avoid conflicts later, let's sync omap
version with the version accepted by mainline after
fixing a few comments.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
lm8323 was recently added to -mm tree, so I'm sending this patch
to avoid conflicts with this driver later
The patch titled
input: keyboard: introduce lm8323 driver
has been added to the -mm tree. Its filename is
input-keyboard-introduce-lm8323-driver.patch
drivers/input/keyboard/Kconfig |1 +
drivers/input/keyboard/lm8323.c | 47 +-
include/linux/i2c/lm8323.h | 15 ++-
3 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4d64652..2c5b7bc 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -289,6 +289,7 @@ config KEYBOARD_TSC2301
config KEYBOARD_LM8323
tristate LM8323 keypad chip
depends on I2C
+ depends on LEDS
help
If you say yes here you get support for the National Semiconductor
LM8323 keypad controller.
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 27da93c..a796680 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -1,11 +1,13 @@
/*
* drivers/i2c/chips/lm8323.c
*
- * Copyright (C) 2007 Nokia Corporation
+ * Copyright (C) 2007-2009 Nokia Corporation
*
* Written by Daniel Stone daniel.st...@nokia.com
*Timo O. Karjalainen timo.o.karjalai...@nokia.com
*
+ * Updated by Felipe Balbi felipe.ba...@nokia.com
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation (version 2 of the License only).
@@ -131,18 +133,20 @@ struct lm8323_pwm {
int brightness;
int desired_brightness;
int running;
+ /* pwm lock */
struct mutexlock;
struct work_struct work;
struct led_classdev cdev;
};
struct lm8323_chip {
+ /* device lock */
struct mutexlock;
struct i2c_client *client;
struct work_struct work;
struct input_dev*idev;
- unsignedkp_enabled : 1;
- unsignedpm_suspend : 1;
+ unsignedkp_enabled:1;
+ unsignedpm_suspend:1;
unsignedkeys_down;
charphys[32];
s16 keymap[LM8323_KEYMAP_SIZE];
@@ -328,9 +332,11 @@ static void lm8323_process_error(struct lm8323_chip *lm)
if (error ERR_FIFOOVER)
dev_vdbg(lm-client-dev, fifo overflow!\n);
if (error ERR_KEYOVR)
- dev_vdbg(lm-client-dev, more than two keys
pressed\n);
+ dev_vdbg(lm-client-dev,
+ more than two keys pressed\n);
if (error ERR_CMDUNK)
- dev_vdbg(lm-client-dev, unknown command
submitted\n);
+ dev_vdbg(lm-client-dev,
+ unknown command submitted\n);
if (error ERR_BADPAR)
dev_vdbg(lm-client-dev, bad command parameter\n);
}
@@ -510,8 +516,7 @@ static void lm8323_pwm_work(struct work_struct *work)
if ((pwm-fade_time / steps) (32768 / 512)) {
div512 = 1;
hz = 32768 / 512;
- }
- else {
+ } else {
div512 = 0;
hz = 32768 / 16;
}
@@ -579,7 +584,7 @@ static ssize_t lm8323_pwm_store_time(struct device *dev,
int ret;
int time;
- ret = sscanf(buf, %d, time);
+ ret = strict_strtoul(buf, 10, time);
/* Numbers only, please. */
if (ret)
return -EINVAL;
@@ -655,7 +660,7 @@ static ssize_t lm8323_set_disable(struct device *dev,
int ret;
int i;
- i = sscanf(buf, %d, ret);
+ ret = strict_strtoul(buf, 10, i);
mutex_lock(lm-lock);
lm-kp_enabled = !i;
@@ -704,7 +709,8 @@ static int lm8323_probe(struct i2c_client *client,
goto fail2;
}
- dev_vdbg(client-dev, Keypad size: %d x %d\n, lm-size_x,
lm-size_y);
+ dev_vdbg(client-dev, Keypad size: %d x %d\n,
+ lm-size_x, lm-size_y);
lm-debounce_time = pdata-debounce_time;
lm-active_time = pdata-active_time;
@@ -746,14 +752,15 @@ static int lm8323_probe(struct i2c_client *client,
INIT_WORK(lm-work, lm8323_work);
err = request_irq(client-irq, lm8323_irq,
- IRQF_TRIGGER_FALLING | IRQF_DISABLED |
- IRQF_SAMPLE_RANDOM, lm8323, lm);
+
Re: [PATCH] input: lm8323: apply comments from mainline
On Sat, Feb 21, 2009 at 12:21:34AM +0200, Felipe Balbi wrote:
In order to avoid conflicts later, let's sync omap
version with the version accepted by mainline after
fixing a few comments.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
Wait a minute, I forgot one hunk, here's an updated version:
== cut here ==
From 370931163e963de1b3cd38d25c1233adebabd103 Mon Sep 17 00:00:00 2001
From: Felipe Balbi m...@felipebalbi.com
Date: Thu, 19 Feb 2009 19:53:59 +0200
Subject: [PATCH] input: lm8323: apply comments from mainline
In order to avoid conflicts later, let's sync omap
version with the version accepted by mainline after
fixing a few comments.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/input/keyboard/Kconfig |1 +
drivers/input/keyboard/lm8323.c | 47 +-
include/linux/i2c/lm8323.h | 17 +++--
3 files changed, 46 insertions(+), 19 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4d64652..2c5b7bc 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -289,6 +289,7 @@ config KEYBOARD_TSC2301
config KEYBOARD_LM8323
tristate LM8323 keypad chip
depends on I2C
+ depends on LEDS
help
If you say yes here you get support for the National Semiconductor
LM8323 keypad controller.
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 27da93c..a796680 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -1,11 +1,13 @@
/*
* drivers/i2c/chips/lm8323.c
*
- * Copyright (C) 2007 Nokia Corporation
+ * Copyright (C) 2007-2009 Nokia Corporation
*
* Written by Daniel Stone daniel.st...@nokia.com
*Timo O. Karjalainen timo.o.karjalai...@nokia.com
*
+ * Updated by Felipe Balbi felipe.ba...@nokia.com
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation (version 2 of the License only).
@@ -131,18 +133,20 @@ struct lm8323_pwm {
int brightness;
int desired_brightness;
int running;
+ /* pwm lock */
struct mutexlock;
struct work_struct work;
struct led_classdev cdev;
};
struct lm8323_chip {
+ /* device lock */
struct mutexlock;
struct i2c_client *client;
struct work_struct work;
struct input_dev*idev;
- unsignedkp_enabled : 1;
- unsignedpm_suspend : 1;
+ unsignedkp_enabled:1;
+ unsignedpm_suspend:1;
unsignedkeys_down;
charphys[32];
s16 keymap[LM8323_KEYMAP_SIZE];
@@ -328,9 +332,11 @@ static void lm8323_process_error(struct lm8323_chip *lm)
if (error ERR_FIFOOVER)
dev_vdbg(lm-client-dev, fifo overflow!\n);
if (error ERR_KEYOVR)
- dev_vdbg(lm-client-dev, more than two keys
pressed\n);
+ dev_vdbg(lm-client-dev,
+ more than two keys pressed\n);
if (error ERR_CMDUNK)
- dev_vdbg(lm-client-dev, unknown command
submitted\n);
+ dev_vdbg(lm-client-dev,
+ unknown command submitted\n);
if (error ERR_BADPAR)
dev_vdbg(lm-client-dev, bad command parameter\n);
}
@@ -510,8 +516,7 @@ static void lm8323_pwm_work(struct work_struct *work)
if ((pwm-fade_time / steps) (32768 / 512)) {
div512 = 1;
hz = 32768 / 512;
- }
- else {
+ } else {
div512 = 0;
hz = 32768 / 16;
}
@@ -579,7 +584,7 @@ static ssize_t lm8323_pwm_store_time(struct device *dev,
int ret;
int time;
- ret = sscanf(buf, %d, time);
+ ret = strict_strtoul(buf, 10, time);
/* Numbers only, please. */
if (ret)
return -EINVAL;
@@ -655,7 +660,7 @@ static ssize_t lm8323_set_disable(struct device *dev,
int ret;
int i;
- i = sscanf(buf, %d, ret);
+ ret = strict_strtoul(buf, 10, i);
mutex_lock(lm-lock);
lm-kp_enabled = !i;
@@ -704,7 +709,8 @@ static int lm8323_probe(struct i2c_client *client,
goto fail2;
}
- dev_vdbg(client-dev, Keypad size: %d x %d\n, lm-size_x,
lm-size_y);
+ dev_vdbg(client-dev, Keypad size: %d x %d\n,
+ lm-size_x, lm-size_y);
lm-debounce_time = pdata-debounce_time;
lm-active_time = pdata-active_time;
@@ -746,14
[PATCH] dspbridge: wait less and check the mailbox more
From: Felipe Contreras felipe.contr...@nokia.com
Profiling showed the __delay function is called a lot; checking the mbox
more often seems to decrease the usage by 2/3 according to OProfile.
The changes are based on 'arch/arm/plat-omap/mailbox.c'. Tested on OMAP3430.
Also, remove HW_MBOX_IsFull since it's not used by anybody.
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/dsp/bridge/hw/hw_mbox.c| 25 -
drivers/dsp/bridge/hw/hw_mbox.h| 35 ---
drivers/dsp/bridge/wmd/tiomap_sm.c | 17 ++---
3 files changed, 10 insertions(+), 67 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index 2c14ade..31b890a 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -104,31 +104,6 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress, const
HW_MBOX_Id_t mailBoxId,
return status;
}
-/* Reads the full status register for mailbox. */
-HW_STATUS HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t mailBoxId,
- u32 *const pIsFull)
-{
- HW_STATUS status = RET_OK;
- u32 fullStatus;
-
- /* Check input parameters */
- CHECK_INPUT_PARAM(baseAddress, 0, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_PARAM(pIsFull, NULL, RET_BAD_NULL_PARAM, RES_MBOX_BASE +
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_RANGE_MIN0(mailBoxId, HW_MBOX_ID_MAX, RET_INVALID_ID,
- RES_MBOX_BASE + RES_INVALID_INPUT_PARAM);
-
- /* read the is full status parameter for Mailbox */
- fullStatus = MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
- (u32)mailBoxId);
-
- /* fill in return parameter */
- *pIsFull = (fullStatus 0xFF);
-
- return status;
-}
-
/* Gets number of messages in a specified mailbox. */
HW_STATUS HW_MBOX_NumMsgGet(const u32 baseAddress, const HW_MBOX_Id_t
mailBoxId,
u32 *const pNumMsg)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h b/drivers/dsp/bridge/hw/hw_mbox.h
index 225fb40..d2981d3 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -130,41 +130,6 @@ extern HW_STATUS HW_MBOX_MsgWrite(
);
/*
-* FUNCTION : HW_MBOX_IsFull
-*
-* INPUTS:
-*
-* Identifier : baseAddress
-* Type : const u32
-* Description : Base Address of instance of Mailbox module
-*
-* Identifier : mailBoxId
-* Type : const HW_MBOX_Id_t
-* Description : Mail Box Sub module Id to check
-*
-* OUTPUTS:
-*
-* Identifier : pIsFull
-* Type : u32 *const
-* Description : false means mail box not Full
-* true means mailbox full.
-*
-* RETURNS:
-*
-* Type : ReturnCode_t
-* Description : RET_OK No errors occured
-* RET_BAD_NULL_PARAM Address/pointer Paramater was set to 0/NULL
-* RET_INVALID_ID Invalid Id used
-*
-* PURPOSE: : this function reads the full status register for mailbox.
-*/
-extern HW_STATUS HW_MBOX_IsFull(
- const u32 baseAddress,
- const HW_MBOX_Id_t mailBoxId,
- u32 *constpIsFull
- );
-
-/*
* FUNCTION : HW_MBOX_NumMsgGet
*
* INPUTS:
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index 9bc5b54..0653f40 100644
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -156,6 +156,13 @@ DSP_STATUS CHNLSM_DisableInterrupt(struct WMD_DEV_CONTEXT
*hDevContext)
return status;
}
+#define MAILBOX_FIFOSTATUS(m) (0x80 + 4 * (m))
+
+static inline unsigned int fifo_full(void __iomem *mbox_base, int mbox_id)
+{
+ return __raw_readl(mbox_base + MAILBOX_FIFOSTATUS(mbox_id)) 0x1;
+}
+
/*
* CHNLSM_InterruptDSP
* Send an interrupt to the DSP processor(s).
@@ -171,9 +178,8 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
u32 opplevel = 0;
#endif
HW_STATUS hwStatus;
- u32 mbxFull;
struct CFG_HOSTRES resources;
- u16 cnt = 10;
+ u16 cnt = 1000;
u32 temp;
/* We are waiting indefinitely here. This needs to be fixed in the
* second phase */
@@ -214,12 +220,9 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
pDevContext-dwBrdState = BRD_RUNNING;
}
while (--cnt) {
- hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
- MBOX_ARM2DSP, mbxFull);
- if (mbxFull)
- UTIL_Wait(1000);/* wait for 1 ms) */
- else
+ if (!fifo_full((void __iomem *) resources.dwMboxBase, 0))
Re: [patch 11/12] usb: musb: adding high bandwidth support
On Wednesday 18 February 2009, g...@kroah.com wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Tested with Creative (Live! Cam Optia) USB camera which uses
high bandwidth isochronous interface.FIFO table has been updated
for Rx high bandwidth case.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: David Brownell dbrown...@users.sourceforge.net
NAK on this one ... Ajay, please re-issue with udpates
to verify that the silicon supports high bandwith ISO!
There's code in musb_core_init():
if (reg MUSB_CONFIGDATA_HBRXE) {
strcat(aInfo, , HB-ISO Rx);
strcat(aInfo, (X)); /* no driver support */
}
if (reg MUSB_CONFIGDATA_HBTXE) {
strcat(aInfo, , HB-ISO Tx);
strcat(aInfo, (X)); /* no driver support */
}
What it needs to do is save a flag instead of
printing the (X) ... and test that flag later,
instead of assuming it's set.
Examples:
- DaVinci DM6446 and DM355 don't support high bandwidth
for either RX or TX.
- Neither does TUSB6010 (and presumably TUSB6020), which
was sort of extracted from the DM6446 (adding more RAM,
splitting out the fibula and tibula chips, etc)
- OMAP3 ES2.1 and ES3.1 support it for RX and TX ... but
the ES3.0 chips only support it for RX (goofage?)
I don't know what the Blackfin or ST-Micro parts do, but
one shouldn't assume they always support it either.
Also, I suspect you should probably create a new fifo_mode
table to support this. These changes will break some
composite gadget code I've seen ... and I'm curious why
you didn't just configure that endpoint in shared-FIFO mode,
so that it'd support both RX and TX in high bandwidth.
- Dave
--
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: Configuring a TWL GPIO pin as an interrupt
On Fri, Feb 20, 2009 at 08:27:54PM -0600, Lopez Cruz, Misael wrote: Hi, I'm interested in bringing headset detection feature for audio. The detection is done through TWL GPIO_2. How can I configure a GPIO pin to generate an interrupt? Is there any API? Could you please point out another driver using that functionality so I can use as reference? gpio_request(GPIO_NUMBER, Headset IRQ); gpio_direction_input(GPIO_NUMBER); request_irq(client-irq, lm8323_irq, flags | IRQF_SHARED, DRIVER_NAME, dev); that should do it :-) see that GPIO_NUMBER will be gpio_base + 2, base is board-specific -- 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: Configuring a TWL GPIO pin as an interrupt
On Friday 20 February 2009, Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 08:27:54PM -0600, Lopez Cruz, Misael wrote:
Hi,
I'm interested in bringing headset detection feature for audio. The
detection is done through TWL GPIO_2. How can I configure a GPIO pin
to generate an interrupt? Is there any API? Could you please point
out another driver using that functionality so I can use as reference?
I don't think there is one. I hacked my Beagleboard to test
those ... Rev B boards don't have EHCI, so GPIO-1 is easily
available.
In the setup() callback for the TWL4030 GPIOs:
{
int GPIO_NUMBER = gpio_base + 2;
gpio_request(GPIO_NUMBER, Headset IRQ);
gpio_direction_input(GPIO_NUMBER);
lm8323_board_info.irq = gpio_to_irq(GPIO_NUMBER);
... something registers this board_info ...
...
return 0;
}
and then later the lm8323 driver will use that IRQ:
request_irq(client-irq, lm8323_irq, flags | IRQF_SHARED, DRIVER_NAME, dev);
that should do it :-)
see that GPIO_NUMBER will be gpio_base + 2, base is board-specific
. and hence client-irq is also board-specific,
which is why it needs to be set up
--
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
