Re: [RFC][PATCH 1/3] OMAP: DSS2: Do regulator stuff in dpi_init_display()
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
We don't want dpi_init() to fail in any case as it will prevent us
from using DSS2 if we don't have DSI in the system. This is because
dpi_init() is done unconditionally by the DSS2 core.
We will only need to do regulator initialization when DPI is actually
present in the system. So we do regulator init stuff in dpi_init_display()
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
drivers/video/omap2/dss/dpi.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 960e977..bcedafd 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -299,11 +299,6 @@ int dpi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG(init_display\n);
- return 0;
-}
-
-int dpi_init(struct platform_device *pdev)
-{
if (cpu_is_omap34xx()) {
dpi.vdds_dsi_reg = dss_get_vdds_dsi();
if (IS_ERR(dpi.vdds_dsi_reg)) {
@@ -315,6 +310,11 @@ int dpi_init(struct platform_device *pdev)
return 0;
}
+int dpi_init(struct platform_device *pdev)
+{
+ return 0;
+}
+
I don't think this is quite correct. dpi_init_display() will be called
for all DPI displays, which means that it may be called more than once.
dpi_init() is meant for global initializations.
Perhaps it would be best to have DPI compiled conditionally like
SDI/DSI/RFBI.
Tomi
Ps. Fixed the fbdev list address in the cc
--
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][PATCH 2/3] OMAP: DSS2: Prevent recursive Panel Enable/Disable calls from SDI
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: From: Roger Quadros roger.quad...@nokia.com Panel enable/disable is now done inside display manager, so don't need to do it again. This looks correct, thanks. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/3] OMAP: DSS2: Prevent recursive Panel Enable/Disable calls from SDI
On Mon, 2010-03-15 at 10:32 +0100, Tomi Valkeinen wrote: On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: From: Roger Quadros roger.quad...@nokia.com Panel enable/disable is now done inside display manager, so don't need to do it again. This looks correct, thanks. Actually, I take my word back =). This patch leaves the err3 label there, and you remove it in the next patch. It should be removed in this same patch. And the patch description is a bit strange. I think it should be something like: Panel enable/disable is now done via the panel driver, so we should not call the panel driver again. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/3] OMAP: DSS2: Use vdds_sdi regulator supply in SDI
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
This patch enables the use of vdds_sdi regulator in SDI subsystem.
We can disable the vdds_sdi voltage when not in use to save
power.
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 23 +--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 45aab89..e816e80 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -23,13 +23,16 @@
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
+#include linux/regulator/consumer.h
#include plat/display.h
+#include plat/cpu.h
#include dss.h
static struct {
bool skip_init;
bool update_enabled;
+ struct regulator *vdds_sdi_reg;
} sdi;
static void sdi_basic_init(void)
@@ -57,6 +60,12 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
goto err0;
}
+ if (cpu_is_omap34xx()) {
+ r = regulator_enable(sdi.vdds_sdi_reg);
+ if (r)
+ goto err1;
+ }
+
/* In case of skip_init sdi_init has already enabled the clocks */
if (!sdi.skip_init)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
@@ -118,10 +127,10 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
sdi.skip_init = 0;
return 0;
-err3:
- dssdev-manager-disable(dssdev-manager);
err2:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ if (cpu_is_omap34xx())
+ regulator_enable(sdi.vdds_sdi_reg);
err1:
omap_dss_stop_device(dssdev);
err0:
@@ -137,6 +146,9 @@ void omapdss_sdi_display_disable(struct omap_dss_device
*dssdev)
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ if (cpu_is_omap34xx())
+ regulator_enable(sdi.vdds_sdi_reg);
+
omap_dss_stop_device(dssdev);
}
EXPORT_SYMBOL(omapdss_sdi_display_disable);
@@ -144,6 +156,13 @@ EXPORT_SYMBOL(omapdss_sdi_display_disable);
int sdi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG(SDI init\n);
+ if (cpu_is_omap34xx()) {
+ sdi.vdds_sdi_reg = dss_get_vdds_sdi();
+ if (IS_ERR(sdi.vdds_sdi_reg)) {
+ DSSERR(can't get VDDS_SDI regulator\n);
+ return PTR_ERR(sdi.vdds_sdi_reg);
+ }
+ }
return 0;
}
Same comment here as to DPI patch, I think the regulator init should be
done in sdi_init().
And why do you test for omap34xx?
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/3] OMAP: DSS2: Do regulator stuff in dpi_init_display()
Hi, Valkeinen Tomi (Nokia-D/Helsinki) wrote: I don't think this is quite correct. dpi_init_display() will be called for all DPI displays, which means that it may be called more than once. dpi_init() is meant for global initializations. Perhaps it would be best to have DPI compiled conditionally like SDI/DSI/RFBI. OK, will do it this way. Compiled conditionally makes sense. -roger -- 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] USB: musb: add two states to handle vbus error
When the MUSB is configured as host mode or OTG mode, the xceiv-state
will be set to OTG_STATE_A_IDLE or OTG_STATE_B_IDLE unconditionally
during init process. These init states can change to other
states When the MUSB module detects id pin change, devices connect or
disconnect.
But on some platforms(omap2, omap3), the id pin change
can't raise IRQ request to the MUSB module, so on these platforms,
the init xceiv-state will be A_IDLE or B_IDLE. Under this condition,
when we want the MUSB to act as a host and hotplug a usb device in
mini-B side of the cable, the MUSB will have a possibility to suffer
power underrun under A_IDLE or B_IDLE state, So here adding these
two states under which we can handle VBUSERROR IRQ.
Signed-off-by: Wang Hui hui.w...@windriver.com
---
drivers/usb/musb/musb_core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b4bbf8f..655413c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -516,6 +516,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
* another reset is due (at least for high speed,
* to redo the chirp etc), it might work OK...
*/
+ case OTG_STATE_A_IDLE:
+ case OTG_STATE_B_IDLE:
case OTG_STATE_A_WAIT_BCON:
case OTG_STATE_A_WAIT_VRISE:
if (musb-vbuserr_retry) {
--
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
[PATCH 2/2] USB: musb: omap2430: add mode change from A to B
On omap2/3 series platforms, the musb can't raise id pin change
detection interrupt, so we must change otg mode through sysfs
interface manually. Currently when the musb is in B mode, if we
want musb to be changed to A mode, we should plug a mini-A cable
and then execute echo host /sys/devices/platform/musb_hdrc/mode.
But if the musb is in A mode, we can't change it to B mode through
this method.
To solve this problem, add a process for sending end session request.
This process works like this, if the musb is in A mode, it will send
an end session request first, then it will follow original routine:
start a new session, during this session, it will identify whether
A or B is plugging in the socket, then it will init controller to A
or B mode according to its identification.
Usage: change cable as you desired,
change musb mode by #echo host[peripheral] /sys/devices/\
platform/musb_hdrc/mode,
then you will get required musb mode.
Signed-off-by: Wang Hui hui.w...@windriver.com
---
drivers/usb/musb/omap2430.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3fe1686..b02897e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
{
u8 devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
+ if ((devctl MUSB_DEVCTL_BDEVICE) == 0x0) {
+ devctl = ~MUSB_DEVCTL_SESSION;
+ musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+ }
+
devctl |= MUSB_DEVCTL_SESSION;
musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
--
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
[PATCH RESEND] omap3: Fix EHCI port for IGEP v2 board.
From: Enric Balletbo i Serra eballe...@iseebcn.com
IGEP v2 uses EHCI port 1 instead of EHCI port 2.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/mach-omap2/board-igep0020.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 3c7789d..d55c57b 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -458,13 +458,13 @@ static struct omap_musb_board_data musb_board_data = {
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL,
};
--
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: [PATCH 2/2] USB: musb: omap2430: add mode change from A to B
Hello.
Wang Hui wrote:
On omap2/3 series platforms, the musb can't raise id pin change
detection interrupt, so we must change otg mode through sysfs
interface manually. Currently when the musb is in B mode, if we
want musb to be changed to A mode, we should plug a mini-A cable
and then execute echo host /sys/devices/platform/musb_hdrc/mode.
But if the musb is in A mode, we can't change it to B mode through
this method.
To solve this problem, add a process for sending end session request.
This process works like this, if the musb is in A mode, it will send
an end session request first, then it will follow original routine:
start a new session, during this session, it will identify whether
A or B is plugging in the socket, then it will init controller to A
or B mode according to its identification.
Usage: change cable as you desired,
change musb mode by #echo host[peripheral] /sys/devices/\
platform/musb_hdrc/mode,
then you will get required musb mode.
Signed-off-by: Wang Hui hui.w...@windriver.com
---
drivers/usb/musb/omap2430.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3fe1686..b02897e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
{
u8 devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
+ if ((devctl MUSB_DEVCTL_BDEVICE) == 0x0) {
+ devctl = ~MUSB_DEVCTL_SESSION;
+ musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+ }
+
devctl |= MUSB_DEVCTL_SESSION;
musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
The whole musb_platform_set_mode() seems to be implemented
incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This
function should control the ID pin override instead -- if the controller
supports it. SRP must be initiated thru other means, i.e. 'srp' file in
sysfs.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/3] OMAP: DSS2: Use vdds_sdi regulator supply in SDI
Hi,
Valkeinen Tomi (Nokia-D/Helsinki) wrote:
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
This patch enables the use of vdds_sdi regulator in SDI subsystem.
We can disable the vdds_sdi voltage when not in use to save
power.
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 23 +--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 45aab89..e816e80 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -23,13 +23,16 @@
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
+#include linux/regulator/consumer.h
#include plat/display.h
+#include plat/cpu.h
#include dss.h
static struct {
bool skip_init;
bool update_enabled;
+ struct regulator *vdds_sdi_reg;
} sdi;
static void sdi_basic_init(void)
@@ -57,6 +60,12 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
goto err0;
}
+ if (cpu_is_omap34xx()) {
+ r = regulator_enable(sdi.vdds_sdi_reg);
+ if (r)
+ goto err1;
+ }
+
/* In case of skip_init sdi_init has already enabled the clocks */
if (!sdi.skip_init)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
@@ -118,10 +127,10 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
sdi.skip_init = 0;
return 0;
-err3:
- dssdev-manager-disable(dssdev-manager);
err2:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ if (cpu_is_omap34xx())
+ regulator_enable(sdi.vdds_sdi_reg);
err1:
omap_dss_stop_device(dssdev);
err0:
@@ -137,6 +146,9 @@ void omapdss_sdi_display_disable(struct omap_dss_device
*dssdev)
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ if (cpu_is_omap34xx())
+ regulator_enable(sdi.vdds_sdi_reg);
+
omap_dss_stop_device(dssdev);
}
EXPORT_SYMBOL(omapdss_sdi_display_disable);
@@ -144,6 +156,13 @@ EXPORT_SYMBOL(omapdss_sdi_display_disable);
int sdi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG(SDI init\n);
+ if (cpu_is_omap34xx()) {
+ sdi.vdds_sdi_reg = dss_get_vdds_sdi();
+ if (IS_ERR(sdi.vdds_sdi_reg)) {
+ DSSERR(can't get VDDS_SDI regulator\n);
+ return PTR_ERR(sdi.vdds_sdi_reg);
+ }
+ }
return 0;
}
Same comment here as to DPI patch, I think the regulator init should be
done in sdi_init().
OK.
And why do you test for omap34xx?
I just assumed that, so i guess that was wrong. Will check the TRM and fix it.
-roger
--
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][PATCH 3/3] OMAP: DSS2: Use vdds_sdi regulator supply in SDI
On Mon, 2010-03-15 at 12:26 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: Hi, Valkeinen Tomi (Nokia-D/Helsinki) wrote: On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: From: Roger Quadros roger.quad...@nokia.com This patch enables the use of vdds_sdi regulator in SDI subsystem. We can disable the vdds_sdi voltage when not in use to save power. Signed-off-by: Roger Quadros roger.quad...@nokia.com --- drivers/video/omap2/dss/sdi.c | 23 +-- 1 files changed, 21 insertions(+), 2 deletions(-) snip And why do you test for omap34xx? I just assumed that, so i guess that was wrong. Will check the TRM and fix it. Well, SDI is only for omap34xx. But why do you test it inside sdi.c, and only for the regulator? I don't think SDI will work any better on OMAP3630 (which doesn't have the SDI block), even if you don't use the regulators ;). So I think it's safe to assume inside sdi.c that we are running on a device with SDI HW block. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SPI troubles
On 03/14/2010 10:44 PM, Ben Gamari wrote:
Hey all,
As I've mentioned here in the past, I am currently putting together a board for
doing analog data acquisition on the BeagleBoard platform. Unfortunately, I
have wasted nearly the entire weekend trying to accomplish the (one would
think) simple goal of recieving data with the McSPI controllers (in particular,
run a loop-back test on McSPI3 with spidev_test).
For some reason you need to set the clock pin as an input. Here is the
config for mcspi1 that is working for me:
MUX_VAL(CP(MCSPI1_CLK), (IEN | PTD | DIS | M0)) /*McSPI1_CLK*/\
(from u-boot)
Philip
While I can reliably see a signal sent on the SIMO line, I have not once been
able to recieve anything but zeros in return. I have verified that the the SOMI
ball works as expected as a GPIO input. I have tried every pinmux configuration
imaginable (using both the kernel and u-boot) and yet I have still met no
success. It seems like this has been an issue in the past[1] and it seems that
at one point SPI was working[2], yet I have been completely unable to reproduce
this result.
When measuring the SIMO signal on the expansion connector with my daughterboard
connected, I noticed that the daughterboard's level shifter appeared to be
driving the signal higher than it should, to ~2.9 Volts. I then checked the
1.8V rail voltage and found that it too was higher than expected, again at 2.9
volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its
expected value.
I'm both perplexed and concerned with this behavior. I completely fail to
see how my board is raising the voltage on the 1.8V rail (schematic available
at [3]). While the BeagleBoard seems quite stable, I'm very concerned that
perhaps the daughterboard over-drove the SIMO ball and burned out some subset
of the OMAP. Regardless, as mentioned earlier, I have verified the
functionality of the same ball as a GPIO input. Thus, I am thoroughly confused.
Is it possible that the ball's GPIO receiver could remain functional while the
McSPI receiver is burned out?
I am using a 2.6.32 kernel and can see in debugfs that the pinmux is configured
correct, with only the sdmmc2_dat0 pin exposing the McSPI3_SOMI signal. The
kernel patch I'm using to configure the muxes and spi controllers is included
below. As can be seen, I've also tried using the spi-gpio driver, but
unfortunately I wasn't even able to get it producing data on SIMO.
I've tried this using two daughterboards on two different Beagles (a B7 and a
new C4) with identical results on both. If anyone has any ideas at all, I would
love to hear them. I am really unsure of how to proceed at this point and I'm
quickly running out of time to devote to this project. I've included my kernel
patch below and the daughterboard design is available in Eagle format at [3].
Thanks,
- Ben
P.S. It seems to me that SPI is one of the more important interfaces on the
BoardBoard. As such, it would be really nice if there was a standard test of
SPI functionality. It seems many people have struggled to get SPI working on
the BeagleBoard and not too many have succeeded. A standard prescription would
be extremely useful.
P.P.S. Is it just me or does the omap_pinmux interface need some refinement.
Using it has been an exercise in frustration, between extremely sparse
documentation, quirky behavior (I still haven't figure out how to get gpio_130
configured. omap_mux_init_gpio fails with multiple paths for gpio130 whereas
omap_mux_init_signal fails to even recognize the signal name), and general
complexity. The idea behind the interface seems excellent, but it seems it
hasn't been used enough not to be a complete pain in the ass to figure out and
use.
[1]
http://markmail.org/message/2vbfuz7bltvrk6g3#query:beagle%20spi%20zeros+page:1+mid:wduqfhs4ur373ehp+state:results
[2]
http://groups.google.com/group/beagleboard/browse_thread/thread/42988f0e14db0f01/816397901ec999c4?lnk=gstq=Balister+pli=1
[3] http://goldnerlab.physics.umass.edu/git?p=tracker-board.git;a=summary
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 231cb4e..b23c5a5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -12,6 +12,10 @@
* published by the Free Software Foundation.
*/
+//#define BEAGLE_GPIO_SPI
+
+
+
#includelinux/kernel.h
#includelinux/init.h
#includelinux/platform_device.h
@@ -28,6 +32,7 @@
#includelinux/mtd/partitions.h
#includelinux/mtd/nand.h
+#includelinux/spi/spi.h
#includelinux/regulator/machine.h
#includelinux/i2c/twl.h
@@ -372,6 +377,159 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
keys_gpio,
};
+#ifndef BEAGLE_GPIO_SPI
+
+static void __init omap3_beagle_config_mcspi3_mux(void)
+{
+ omap_mux_init_signal(sdmmc2_clk.mcspi3_clk, OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(sdmmc2_dat3.mcspi3_cs0, OMAP_PIN_OUTPUT);
+
Multiple errors while compiling from master
Hi all, While trying to build kernel from master, I encounter many errors (pasted below). I believe the reason is missing headers - plat/resource.h and smartreflex.h ...but I couldn't find them in the tree. premi # ls -l arch/arm/plat-omap/include/plat/res* ls: No match. premi # ls -l arch/arm/mach-omap2/smart* ls: No match. premi # I am at commit: a842b5f9ce70e1b738eabb4d719860070180ed1c Best regards, Sanjeev arch/arm/mach-omap2/pm34xx.c:43:27: error: plat/resource.h: No such file or directory arch/arm/mach-omap2/pm34xx.c:51:25: error: smartreflex.h: No such file or directory arch/arm/mach-omap2/pm34xx.c:98: error: variable 'prm_setup' has initializer but incomplete type arch/arm/mach-omap2/pm34xx.c:99: error: unknown field 'clksetup' specified in initializer arch/arm/mach-omap2/pm34xx.c:99: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:99: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:100: error: unknown field 'voltsetup_time1' specified in initializer arch/arm/mach-omap2/pm34xx.c:100: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:100: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:101: error: unknown field 'voltsetup_time2' specified in initializer arch/arm/mach-omap2/pm34xx.c:101: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:101: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:102: error: unknown field 'voltoffset' specified in initializer arch/arm/mach-omap2/pm34xx.c:102: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:102: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:103: error: unknown field 'voltsetup2' specified in initializer arch/arm/mach-omap2/pm34xx.c:103: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:103: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:104: error: unknown field 'vdd0_on' specified in initializer arch/arm/mach-omap2/pm34xx.c:104: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:104: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:105: error: unknown field 'vdd0_onlp' specified in initializer arch/arm/mach-omap2/pm34xx.c:105: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:105: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:106: error: unknown field 'vdd0_ret' specified in initializer arch/arm/mach-omap2/pm34xx.c:106: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:106: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:107: error: unknown field 'vdd0_off' specified in initializer arch/arm/mach-omap2/pm34xx.c:107: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:107: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:108: error: unknown field 'vdd1_on' specified in initializer arch/arm/mach-omap2/pm34xx.c:108: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:108: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:109: error: unknown field 'vdd1_onlp' specified in initializer arch/arm/mach-omap2/pm34xx.c:109: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:109: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:110: error: unknown field 'vdd1_ret' specified in initializer arch/arm/mach-omap2/pm34xx.c:110: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:110: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c:111: error: unknown field 'vdd1_off' specified in initializer arch/arm/mach-omap2/pm34xx.c:111: warning: excess elements in struct initializer arch/arm/mach-omap2/pm34xx.c:111: warning: (near initialization for 'prm_setup') arch/arm/mach-omap2/pm34xx.c: In function 'omap_sram_idle': arch/arm/mach-omap2/pm34xx.c:411: error: implicit declaration of function 'omap2_gpio_prepare_for_idle' arch/arm/mach-omap2/pm34xx.c:431: error: implicit declaration of function 'disable_smartreflex' arch/arm/mach-omap2/pm34xx.c:431: error: 'SR1' undeclared (first use in this function) arch/arm/mach-omap2/pm34xx.c:431: error: (Each undeclared identifier is reported only once arch/arm/mach-omap2/pm34xx.c:431: error: for each function it appears in.) arch/arm/mach-omap2/pm34xx.c:433: error: 'SR2' undeclared (first use in this function) arch/arm/mach-omap2/pm34xx.c:508: error: implicit declaration of function 'usb_musb_disable_autoidle' arch/arm/mach-omap2/pm34xx.c:532: error: implicit declaration of function 'enable_smartreflex' arch/arm/mach-omap2/pm34xx.c:546: error: implicit declaration of function 'omap3_gpio_restore_pad_context' arch/arm/mach-omap2/pm34xx.c:551: error: implicit declaration of function
Re: [spi-devel-general] SPI troubles
On 03/14/2010 10:44 PM, Ben Gamari wrote: When measuring the SIMO signal on the expansion connector with my daughterboard connected, I noticed that the daughterboard's level shifter appeared to be driving the signal higher than it should, to ~2.9 Volts. I then checked the 1.8V rail voltage and found that it too was higher than expected, again at 2.9 volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its expected value. I'm both perplexed and concerned with this behavior. I completely fail to see how my board is raising the voltage on the 1.8V rail (schematic available at [3]). While the BeagleBoard seems quite stable, I'm very concerned that perhaps the daughterboard over-drove the SIMO ball and burned out some subset of the OMAP. Regardless, as mentioned earlier, I have verified the functionality of the same ball as a GPIO input. Thus, I am thoroughly confused. Is it possible that the ball's GPIO receiver could remain functional while the McSPI receiver is burned out? [3] http://goldnerlab.physics.umass.edu/git?p=tracker-board.git;a=summary I'd be happy to check your circuit for you, if it were posted in a more widely used format. How about a PDF of the schematic. -- Ned Forrester nforres...@whoi.edu Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 -- 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: [spi-devel-general] SPI troubles
On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester nforres...@whoi.edu wrote: I'd be happy to check your circuit for you, if it were posted in a more widely used format. How about a PDF of the schematic. Certainly, it's a available at http://goldnerlab.physics.umass.edu/~bgamari/schematic.png. - Ben -- 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: SPI troubles
On Mon, 15 Mar 2010 08:25:09 -0400, Philip Balister phi...@balister.org wrote: For some reason you need to set the clock pin as an input. Here is the config for mcspi1 that is working for me: MUX_VAL(CP(MCSPI1_CLK), (IEN | PTD | DIS | M0)) /*McSPI1_CLK*/\ (from u-boot) Are you sure? Is this to fix the clock or does this really affect the MISO signal? I have no problems with my clock at the moment. Everything appears to work except for MISO. Cheers, - Ben -- 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: Multiple errors while compiling from master
* Premi, Sanjeev pr...@ti.com [100315 07:30]: Hi all, While trying to build kernel from master, I encounter many errors (pasted below). I believe the reason is missing headers - plat/resource.h and smartreflex.h ...but I couldn't find them in the tree. premi # ls -l arch/arm/plat-omap/include/plat/res* ls: No match. premi # ls -l arch/arm/mach-omap2/smart* ls: No match. premi # I am at commit: a842b5f9ce70e1b738eabb4d719860070180ed1c It should build fine for all omaps now. Maybe do git status and see if you have something extra applied? Those files are currently only in Kevin's PM branch. 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 RESEND] omap3: Fix EHCI port for IGEP v2 board.
Hi,
On Mon, Mar 01, 2010 at 04:02:36PM +0100, Enric Balletbo i Serra wrote:
@@ -458,13 +458,13 @@ static struct omap_musb_board_data musb_board_data = {
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
no way to be backwards compatible ? Is it worth to be backwards
compatible ?
--
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 2/2] USB: musb: omap2430: add mode change from A to B
On Mon, Mar 15, 2010 at 02:22:38PM +0300, Sergei Shtylyov wrote: The whole musb_platform_set_mode() seems to be implemented incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This correct. It should be changing the id pin rules just like in tusb6010.c function should control the ID pin override instead -- if the controller supports it. SRP must be initiated thru other means, i.e. 'srp' file in sysfs. via musb_gadget_wakeup() -- 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 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Scott Ellis sc...@jumpnowtek.com [100314 10:22]:
The McSPI_CHxCONF.CLKD register field has different limits for
the OMAP3 then the OMAP24xx. New max_clk_div field added to
mcspi platform config structure to keep track of this.
Revised patch to not break multi-omap booting.
Signed-off-by: Scott Ellis sc...@jumpnowtek.com
arch/arm/mach-omap2/devices.c | 14 ++
arch/arm/plat-omap/include/plat/mcspi.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 23e4d77..200f382 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -415,6 +415,11 @@ static inline void omap4_mcspi_fixup(void)
defined(CONFIG_ARCH_OMAP4)
static inline void omap2_mcspi3_init(void)
{
+ if (cpu_is_omap343x() || cpu_is_omap44xx())
+ omap2_mcspi3_config.max_clk_div = 0x0c;
+ else
+ omap2_mcspi3_config.max_clk_div = 0x0f;
+
platform_device_register(omap2_mcspi3);
}
#else
Hmm now it looks like you're missing 3630 handling?
If the max_clk_div is 0x0f for 2420 and 2430, then you
can just check for cpu_is_omap24xx(). If it's only
different for 2420, then you can check for cpu_is_omap2420().
That way it should be more future proof, and you don't
need to change it for new processors.
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: SPI troubles
* Ben Gamari bgamari.f...@gmail.com [100314 19:41]: P.P.S. Is it just me or does the omap_pinmux interface need some refinement. Using it has been an exercise in frustration, between extremely sparse documentation, quirky behavior (I still haven't figure out how to get gpio_130 configured. omap_mux_init_gpio fails with multiple paths for gpio130 whereas omap_mux_init_signal fails to even recognize the signal name), and general complexity. The idea behind the interface seems excellent, but it seems it hasn't been used enough not to be a complete pain in the ass to figure out and use. Hopefully incrementally less frustrating now than earlier though :) So far the new mux code has been tested pretty much only with the existing mux settings, so I'm sure quite a some quirks still remain. The problem of omap_mux_init_gpio not recognizing full signal names is known. At least it correctly gives you warnings and refuses to do anything. The real fix probably in the long run is to change everything to use omap_mux_init_signal instead. But what's the issue of omap_mux_init_signal not recognizing the signal name? It should be just mode0_name.desired_mode. Is some entry maybe missing from mux34xx.c? Some of the complexity disappears once I get around to converting the 24xx muxing to the new code so we can get rid of the old code. Some complexity is caused by the need to support bootloader-only muxing while still dynamically muxing the GPIO pins for PM idle. Got some good ideas on how to cut down the complexity further? 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 RESEND] omap3: Fix EHCI port for IGEP v2 board.
Hello,
Felipe, sorry but I don't understand your questions,m maybe I'm
missing something.
All IGEP v2 boards uses USB1HS EHCI port. My mistake was suppose that
port_mode[1] -- EHCI USB1HS but this is not correct, the EHCI USB1HS
is port_mode[0]. This patch only fixes this.
Best regards,
Enric
2010/3/15 Felipe Balbi m...@felipebalbi.com
Hi,
On Mon, Mar 01, 2010 at 04:02:36PM +0100, Enric Balletbo i Serra wrote:
@@ -458,13 +458,13 @@ static struct omap_musb_board_data musb_board_data
= {
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst =
{
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
no way to be backwards compatible ? Is it worth to be backwards
compatible ?
--
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 RESEND] omap3: Fix EHCI port for IGEP v2 board.
Hi, please don't top-post. Read more at [1]. On Mon, Mar 15, 2010 at 06:07:48PM +0100, Enric Balletb? i Serra wrote: Felipe, sorry but I don't understand your questions,m maybe I'm missing something. is there a IGEP v1 board available ? Are there any developers around using it ? If true, you should try to be backwards compatible. [1] http://www.elinux.org/Netiquette -- 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 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
Hi, On Mon, Mar 15, 2010 at 09:32:46AM -0700, Tony Lindgren wrote: Hmm now it looks like you're missing 3630 handling? a bit unrelated but Tony, would you mind looking at patches splitting devices.c into something like dev34xx.c dev24xx.c and dev44xx.c ?? personally I think we should have mach-omap3 and mach-omap4 directories but that would be too intrusive IMO. -- 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 RESEND] omap3: Fix EHCI port for IGEP v2 board.
Hi, 2010/3/15 Felipe Balbi m...@felipebalbi.com: Hi, please don't top-post. Read more at [1]. Sorry is there a IGEP v1 board available ? Are there any developers around using it ? If true, you should try to be backwards compatible. Yes, IGEP v1 is available but it's a different platform with different processor and aren't compatible. See http://www.igep-platform.com. - IGEPv1 is low-power and fan-less single board computer based on ATMEL ARM9 processor. - IGEPv2 is low-power and fan-less single board computer based on OMAP35x processor. Regards, -- Enric -- 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: Commit 0c8219f0... breaks omap7xx support
* Cory Maccarrone darkstar6...@gmail.com [100309 15:38]: On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren t...@atomide.com wrote: Does your system boot without any patches if DEBUG_LL is not set in your .config? No, it doesn't. Seems like the debugging code is still trying to run, even disabled. If I add in that check, it'll boot with DEBUG_LL not set, but won't without that. Sorry for the delay on this. How about with the following patch with DEBUG_LL not set? Note that this is using the shift register now too. Regards, Tony From 240b34f7efbf26ad4f39438d055b0931e8e7496e Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 15 Mar 2010 10:47:08 -0700 Subject: [PATCH] omap: Add back UART MDR1 check into uncompress.h Recent DEBUG_LL and uncompress.h changes removed the check_port() as pointed out by Cory Maccarrone darkstar6...@gmail.com. This causes some boards to not boot, so add back the MDR1 register check. The MDR1 register tells the mode of omap uart. Based on an earlier patch by Cory Maccarrone darkstar6...@gmail.com. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h index 81d9ec5..dc37b2c 100644 --- a/arch/arm/plat-omap/include/plat/uncompress.h +++ b/arch/arm/plat-omap/include/plat/uncompress.h @@ -24,6 +24,8 @@ #include plat/serial.h +#define MDR1_MODE_MASK 0x07 + static volatile u8 *uart1_base; static int uart1_shift; @@ -48,6 +50,10 @@ static void putc(int c) if (!uart_base) return; + /* Check for UART 16x mode */ + if ((uart_base[UART_OMAP_MDR1 uart_shift] MDR1_MODE_MASK) != 0) + return; + while (!(uart_base[UART_LSR uart_shift] UART_LSR_THRE)) barrier(); uart_base[UART_TX uart_shift] = c;
Re: [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Felipe Balbi m...@felipebalbi.com [100315 10:59]:
Hi,
On Mon, Mar 15, 2010 at 09:32:46AM -0700, Tony Lindgren wrote:
Hmm now it looks like you're missing 3630 handling?
a bit unrelated but Tony, would you mind looking at patches splitting
devices.c into something like dev34xx.c dev24xx.c and dev44xx.c ??
Yeah I've been thinking about that too earlier. We could have common
devices.c with the init code, then dev24xx.c and dev34xx.c et al
would just call the common init functions with something like this:
static int __init dev34xx_init(void)
{
if (!cpu_is_omap34xx())
return -ENODEV;
omap_init_mbox(omap34xx_mbox_resources, omap34xx_mbox_nr_resources);
omap_init_sti(omap34xx_sti_resources, omap34xx_sti_nr_resources);
...
return 0;
}
subsys_initcall(emu_init);
Of course that needs to be coordinated with the pending hwmod patches.
personally I think we should have mach-omap3 and mach-omap4 directories
but that would be too intrusive IMO.
I think we can achieve most of that by right naming of the files and
with hwmod. Having separate directories typically means multiple copies
of almost the same code.
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 v2] [I2C-OMAP] Add support for 16-bit registers
Tony Lindgren t...@atomide.com writes:
[...]
Here's another one to add to omap-testing then.
This one has been submitted to linux-i2c a couple times and been in
the OMAP PM branch for a while.
OK, let's add that to omap-testing after we're done with the initial
fixes. This does not currently apply on top of omap-testing, BTW.
Here's an updated version that applies on omap-testing.
Kevin
From 5e5fcf4322b04e27698f1ae48d12ae788969ea49 Mon Sep 17 00:00:00 2001
From: Kalle Jokiniemi kalle.jokini...@digia.com
Date: Wed, 21 Oct 2009 14:51:21 +0300
Subject: [PATCH] i2c-omap: add mpu wake up latency constraint in i2c
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Created a mechanism for passing and using the
constraint setting function in driver code. The used
mpu wake up latency constraints are now set individually
per bus, and they are calculated based on clock rate
and fifo size.
Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley,
and Nishanth Menon for tuning out the details of
this patch.
Cc: Moiz Sonasath m-sonas...@ti.com
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/i2c.c | 55 -
drivers/i2c/busses/i2c-omap.c | 24 +++---
include/linux/i2c-omap.h |9 ++
3 files changed, 72 insertions(+), 16 deletions(-)
create mode 100644 include/linux/i2c-omap.h
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 624e262..36011a1 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,9 +26,12 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c.h
+#include linux/i2c-omap.h
+
#include mach/irqs.h
#include plat/mux.h
#include plat/i2c.h
+#include plat/omap-pm.h
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -70,19 +73,44 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], i2c_pdata[0]),
#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- I2C_DEV_BUILDER(2, i2c_resources[1], i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], i2c_pdata[1]),
#endif
#ifdefined(CONFIG_ARCH_OMAP3)
- I2C_DEV_BUILDER(3, i2c_resources[2], i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], i2c_pdata[2]),
#endif
};
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+#ifdef CONFIG_ARCH_OMAP3
+/*
+ * omap_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
+ * @dev: i2c bus device pointer
+ * @val: latency constraint to set, -1 to disable constraint
+ *
+ * When waiting for completion of a i2c transfer, we need to set a wake up
+ * latency constraint for the MPU. This is to ensure quick enough wakeup from
+ * idle, when transfer completes.
+ */
+static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int val)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, val);
+}
+#endif
+
+static void __init omap_set_i2c_constraint_func(
+ struct omap_i2c_bus_platform_data *pd)
+{
+ if (cpu_is_omap34xx())
+ pd-set_mpu_wkup_lat = omap_i2c_set_wfc_mpu_wkup_lat;
+ else
+ pd-set_mpu_wkup_lat = NULL;
+}
+
static int __init omap_i2c_nr_ports(void)
{
int ports = 0;
@@ -146,8 +174,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
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;
+ i2c_pdata[ints[1] - 1].clkrate = ints[2];
+ i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
@@ -161,9 +189,10 @@ 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;
+ for (i = 0; i ARRAY_SIZE(i2c_pdata); i++)
+ if (i2c_pdata[i].clkrate OMAP_I2C_CMDLINE_SETUP) {
+ i2c_pdata[i].clkrate = ~OMAP_I2C_CMDLINE_SETUP;
+ omap_set_i2c_constraint_func(i2c_pdata[i]);
err = omap_i2c_add_bus(i +
Re: [PATCH 03/16] OMAP3: PM: Convert smartreflex driver into a platform driver using hwmods and omap-device layer
* Kevin Hilman khil...@deeprootsystems.com [100312 16:38]: Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, March 02, 2010 11:58 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Menon, Nishanth; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH 03/16] OMAP3: PM: Convert smartreflex driver into a platform driver using hwmods and omap-device layer Thara Gopinath th...@ti.com writes: This patch converts the exisitng smartreflex library into a platform driver with device , driver registrations using hardware mods. As part of this Ntarget values are passed as platform data. Signed-off-by: Thara Gopinath th...@ti.com Nice work Thara. This is good. Some minor comments below, but some general comments first. As discussed, eventually (longer term) we'll want to move the driver parts of this to a regulator driver. To ease that transition, I think it would be nice to start now by separating the driver portions of this file from the device portions. You've already done a good job of keeping them separate in this file (most of the device stuff is at the end) but I think having a separate file is probably even better. Maybe move driver stuff to sr_driver.c and leave device stuff in smartreflex.c? I don't care much about the names at this point. Quick question.. If we are going to separate out smartreflex device portions from this file , can't we keep them in devices.c instead of going for a separate file? Ultimately, that's Tony's call, but I would prefer to see a separate specific file for SR device init. Yeah me too considering the amount of code. I also agree that most of the smartreflex code should be done under drivers/ to allow loading it as a module. 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: Commit 0c8219f0... breaks omap7xx support
* Tony Lindgren t...@atomide.com [100315 11:35]:
* Cory Maccarrone darkstar6...@gmail.com [100309 15:38]:
On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren t...@atomide.com wrote:
Does your system boot without any patches if DEBUG_LL is not set
in your .config?
No, it doesn't. Seems like the debugging code is still trying to run,
even disabled. If I add in that check, it'll boot with DEBUG_LL not
set, but won't without that.
Sorry for the delay on this. How about with the following patch with
DEBUG_LL not set?
Note that this is using the shift register now too.
Then we may want to do this too for the boards that don't have any UART.
Tony
From b33f67e61cc45558cfbda86b3e2032ffbcb2f99c Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 15 Mar 2010 10:47:08 -0700
Subject: [PATCH] omap: Fix uncompress code for boards with no UART
With the recent DEBUG_LL and uncompress code changes, boards
with no UART configured fail to boot as pointed out by
Cory Maccarrone darkstar6...@gmail.com.
Some boards may not have UARTs available at all, so add
DEBUG_LL_NONE option for that.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index dc37b2c..7d69d39 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -66,6 +66,13 @@ static inline void flush(void)
/*
* Macros to configure UART1 and debug UART
*/
+
+#define DEBUG_LL_NONE(mach) \
+ if (machine_is_##mach()) { \
+ uart_base = 0; \
+ break; \
+ }
+
#define _DEBUG_LL_ENTRY(mach, uart1_phys, uart1_shft, \
dbg_uart, dbg_shft, dbg_id) \
if (machine_is_##mach()) { \
Re: [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
Hi,
On Mon, Mar 15, 2010 at 11:52:13AM -0700, Tony Lindgren wrote:
Yeah I've been thinking about that too earlier. We could have common
devices.c with the init code, then dev24xx.c and dev34xx.c et al
would just call the common init functions with something like this:
static int __init dev34xx_init(void)
{
if (!cpu_is_omap34xx())
return -ENODEV;
omap_init_mbox(omap34xx_mbox_resources, omap34xx_mbox_nr_resources);
omap_init_sti(omap34xx_sti_resources, omap34xx_sti_nr_resources);
...
return 0;
}
subsys_initcall(emu_init);
Of course that needs to be coordinated with the pending hwmod patches.
sure. Exactly what I was thinking :-p
personally I think we should have mach-omap3 and mach-omap4 directories
but that would be too intrusive IMO.
I think we can achieve most of that by right naming of the files and
with hwmod. Having separate directories typically means multiple copies
of almost the same code.
could be, but we already have separated clk, pm, cpuidle, mux and soon
to become devices. So pretty much the base support is already splitted,
then why not completely avoiding ifdefs also with dma (which today is
full of ifdefs and could be converted to a platform_device also).
--
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 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Felipe Balbi m...@felipebalbi.com [100315 12:12]:
Hi,
On Mon, Mar 15, 2010 at 11:52:13AM -0700, Tony Lindgren wrote:
Yeah I've been thinking about that too earlier. We could have common
devices.c with the init code, then dev24xx.c and dev34xx.c et al
would just call the common init functions with something like this:
static int __init dev34xx_init(void)
{
if (!cpu_is_omap34xx())
return -ENODEV;
omap_init_mbox(omap34xx_mbox_resources, omap34xx_mbox_nr_resources);
omap_init_sti(omap34xx_sti_resources, omap34xx_sti_nr_resources);
...
return 0;
}
subsys_initcall(emu_init);
Of course that needs to be coordinated with the pending hwmod patches.
sure. Exactly what I was thinking :-p
personally I think we should have mach-omap3 and mach-omap4 directories
but that would be too intrusive IMO.
I think we can achieve most of that by right naming of the files and
with hwmod. Having separate directories typically means multiple copies
of almost the same code.
could be, but we already have separated clk, pm, cpuidle, mux and soon
to become devices. So pretty much the base support is already splitted,
then why not completely avoiding ifdefs also with dma (which today is
full of ifdefs and could be converted to a platform_device also).
Yeah there are tons of things that should be fixed and split into
platform_data and generic code. At least gpio.c, dma.c and i2c-omap.c
need some serious work.
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 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
Hi, On Mon, Mar 15, 2010 at 12:29:10PM -0700, Tony Lindgren wrote: could be, but we already have separated clk, pm, cpuidle, mux and soon to become devices. So pretty much the base support is already splitted, then why not completely avoiding ifdefs also with dma (which today is full of ifdefs and could be converted to a platform_device also). Yeah there are tons of things that should be fixed and split into platform_data and generic code. At least gpio.c, dma.c and i2c-omap.c need some serious work. problem with those guys is that they're used all over the place so any changes there would always be extremelly intrusive and are prone to cause regressions :-( I could try to allocate some time to play with dma.c but I can only test on omap3 since my n810 isn't mount root on mmc, maybe I screwed up something and can't remember what :-s if you happen to have tips, I'm all ears. The thing is rebooting with mbus bootreason. I'll have to dig up some legacy docs to figure out what's that. -- 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 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Felipe Balbi m...@felipebalbi.com [100315 12:30]: Hi, On Mon, Mar 15, 2010 at 12:29:10PM -0700, Tony Lindgren wrote: could be, but we already have separated clk, pm, cpuidle, mux and soon to become devices. So pretty much the base support is already splitted, then why not completely avoiding ifdefs also with dma (which today is full of ifdefs and could be converted to a platform_device also). Yeah there are tons of things that should be fixed and split into platform_data and generic code. At least gpio.c, dma.c and i2c-omap.c need some serious work. problem with those guys is that they're used all over the place so any changes there would always be extremelly intrusive and are prone to cause regressions :-( Well it's not too hard, just need to be careful and do it in small patches and test carefully between each patch :) I could try to allocate some time to play with dma.c but I can only test on omap3 since my n810 isn't mount root on mmc, maybe I screwed up something and can't remember what :-s if you happen to have tips, I'm all ears. The thing is rebooting with mbus bootreason. I'll have to dig up some legacy docs to figure out what's that. For some reason only one of the MMC slots works on both n800 and n810, maybe some menelaus slot switching issue. So you need to try mounting root on the external card on n810 for now until somebody figures out the problem. 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 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
Hmm now it looks like you're missing 3630 handling? If the max_clk_div is 0x0f for 2420 and 2430, then you can just check for cpu_is_omap24xx(). If it's only different for 2420, then you can check for cpu_is_omap2420(). That way it should be more future proof, and you don't need to change it for new processors. Anand Gadiyar gadiyar at ti.com verified 0x0f for the 2430. I think SWPU177D is the correct TRM for the omap3630 and if so then 0x0c is the correct value. I did not verify the omap44xx value and just assumed similar to the omap3's. My bad. Can you or someone point me to links for the omap2420 and the omap44xx TRMs? I'm not having any luck finding them. Then it can be verified whether a cpu_is_omap24xx() check is sufficient. It probably is. Or if someone with access to those manuals could do a quick check... It's the max value of the MCSPI_CHxCONF.CLKD register field. -- 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/7] omap3: serial code for 3630 and zoom2/3 fixes
Tony, Please find attached pull request for your convenience. Regards, Sergio -Original Message- From: Aguirre, Sergio Sent: Friday, March 12, 2010 2:00 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Kevin Hilman; Pandita, Vikram; Paul Walmsley; Felipe Balbi; Aguirre, Sergio Subject: [PATCH 0/7] omap3: serial code for 3630 and zoom2/3 fixes Hi, This series contains fixes for omap2/3/4 serial code, and are fixing: - Avoid doing ioremapp of a zero-based physical address. (causing a kernel panic during early init on 3630boards) - Unproper omap_revision check during uart globals setup. (omap_revision is not yet filled at that point) - Don't try to enable all uarts generically for zoom2/3 and 3630sdp. - Make zoom2/3 just register one serial port (ttyS0). This is a subset of the original series found here: [1] Thanks to: - Vikram Pandita - Paul Walmsley - Kevin Hilman - Manjunath Kondaiah - Felipe Balbi - Tony Lindgreen For all the feedback recieved so far. Regards, Sergio Sergio Aguirre (7): OMAP3: serial: Check for zero-based physical addr OMAP3: serial: Use dev_* macros instead of printk omap2/3/4: serial: Remove condition for getting uart4_phys omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/serial.c | 35 + 6 files changed, 22 insertions(+), 21 deletions(-) [1] http://marc.info/?l=linux-omapm=126826639903105w=2 The following changes since commit a842b5f9ce70e1b738eabb4d719860070180ed1c: Tony Lindgren (1): Revert omap: Add DSI regulator supply to OMAP3EVM board file are available in the git repository at: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-camera.git omap-fixes Sergio Aguirre (7): OMAP3: serial: Check for zero-based physical addr OMAP3: serial: Use dev_* macros instead of printk omap2/3/4: serial: Remove condition for getting uart4_phys omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/serial.c | 35 + 6 files changed, 22 insertions(+), 21 deletions(-)
Re: [spi-devel-general] SPI troubles
On 03/15/2010 11:57 AM, Ben Gamari wrote: When measuring the SIMO signal on the expansion connector with my daughterboard connected, I noticed that the daughterboard's level shifter appeared to be driving the signal higher than it should, to ~2.9 Volts. I then checked the 1.8V rail voltage and found that it too was higher than expected, again at 2.9 volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its expected value. On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester nforres...@whoi.edu wrote: I'd be happy to check your circuit for you, if it were posted in a more widely used format. How about a PDF of the schematic. Certainly, it's a available at http://goldnerlab.physics.umass.edu/~bgamari/schematic.png. Your problem is likely caused by pulling the THREE STATE pin to 5V. The spec sheet is explicit (in the Absolute Maximum ratings on page 2, and in the functional description on page 12 that this pin should be pulled to VL, not VCC to enable the outputs. Likely by pulling it to 5V the some part of the chip is biased wrong and may cause OVL1 to be pulled above VL. I can't exactly explain the symptoms you report above, based on the mis-connected pin, but most anything could be happening in the MAX3390 once the absolute maximum ratings have been exceeded. The 10K resistors on the THREE STATE lines may have saved the circuit from permanent damage, but they may not save it from improper operation. Other suggestions, nothing fatal... 1. The pinout of the MAX3390E on the drawing is for the TSSOP package. Hopefully that is the package you actually used. 2. All uncommitted inputs should be terminated high or low. This applies to: LS2 pins 4, 5 and 13; LS3 pin 13 and possibly unused pins on the A/Ds and D/A. 3. The MAX3390E family has extremely low drive capability and slow response. Is this device really fast enough for your intended clock rates? Note that the device can only pull down 1ma, and can only pull up 20ua. If there are any pull-downs or pull-ups on the BeagleBoard, the MAX3390E might not be able to drive them. 4. I find it curious that the AVDD to the A/D and D/A is fead through a 1ohm resistor that is paralleled by C11 and C12. Likely you meant to tie one side of each of C11 and C12 (the side now connected to C10 positive) to ground. That connection would make a filter to reduce the noise on AVDD rather than passing the noise along. 5. Is see on the Maxim site that this series of translators is not recommended for new design. Likely the suggested alternatives have much better specifications. -- Ned Forrester nforres...@whoi.edu Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Scott Ellis sc...@jumpnowtek.com [100315 13:27]: Hmm now it looks like you're missing 3630 handling? If the max_clk_div is 0x0f for 2420 and 2430, then you can just check for cpu_is_omap24xx(). If it's only different for 2420, then you can check for cpu_is_omap2420(). That way it should be more future proof, and you don't need to change it for new processors. Anand Gadiyar gadiyar at ti.com verified 0x0f for the 2430. I think SWPU177D is the correct TRM for the omap3630 and if so then 0x0c is the correct value. I did not verify the omap44xx value and just assumed similar to the omap3's. My bad. Can you or someone point me to links for the omap2420 and the omap44xx TRMs? I'm not having any luck finding them. I don't think those are publicly available yet for 4430 and still for 2420.. But looks like 2420, 2430 and 4430 TRMs says that 0xf = 32768 max divider for CLKD. Only 3430 and 3630 TRMs says 0xd, 0xe, 0xf = Division not supported. But then again, the TRMs can have errors. Then it can be verified whether a cpu_is_omap24xx() check is sufficient. It probably is. Then the 4430 TRM must have an error.. Can somebody from TI confirm the CLKD max value for 4430 please? Or if someone with access to those manuals could do a quick check... It's the max value of the MCSPI_CHxCONF.CLKD register field. 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 0/7] omap3: serial code for 3630 and zoom2/3 fixes
* Aguirre, Sergio saagui...@ti.com [100315 13:33]: Tony, Please find attached pull request for your convenience. snip The following changes since commit a842b5f9ce70e1b738eabb4d719860070180ed1c: Tony Lindgren (1): Revert omap: Add DSI regulator supply to OMAP3EVM board file are available in the git repository at: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-camera.git omap-fixes Please base all the branches against the recent tag in Linus' tree, in this case against v2.6.34-rc1. What we have in the linux-omap master branch is a merge of various development branches, and we don't want to merge that history to the mainline tree. If the recent mainline tag won't work as the base, then please rebase it on omap-fixes-for-linus or omap-for-linus. In this case, omap-fixes-for-linus at commit 29b2ee5af5f3a02846bd38a1e2121d62ee5f6aca. The omap-for-linus branch will contain things going into the next merge window, currently it's empty. In general, the commits ins omap-fixes-for-linus and omap-for-linus should stay around unless something goes wrong. But please use the recent mainline tag where possible, that's the most flexible option for merging. 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 0/7] omap3: serial code for 3630 and zoom2/3 fixes
* Aguirre, Sergio saagui...@ti.com [100315 14:47]: From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, March 15, 2010 4:15 PM * Aguirre, Sergio saagui...@ti.com [100315 13:33]: Tony, Please find attached pull request for your convenience. snip The following changes since commit a842b5f9ce70e1b738eabb4d719860070180ed1c: Tony Lindgren (1): Revert omap: Add DSI regulator supply to OMAP3EVM board file are available in the git repository at: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-camera.git omap- fixes Please base all the branches against the recent tag in Linus' tree, in this case against v2.6.34-rc1. What we have in the linux-omap master branch is a merge of various development branches, and we don't want to merge that history to the mainline tree. If the recent mainline tag won't work as the base, then please rebase it on omap-fixes-for-linus or omap-for-linus. In this case, omap-fixes-for-linus at commit 29b2ee5af5f3a02846bd38a1e2121d62ee5f6aca. The omap-for-linus branch will contain things going into the next merge window, currently it's empty. In general, the commits ins omap-fixes-for-linus and omap-for-linus should stay around unless something goes wrong. But please use the recent mainline tag where possible, that's the most flexible option for merging. Understood, Please find updated pull request, rebased on omap-fixes-for-linux. I tried it on master, but they don't apply clean, since OMAP2: serial.c: Fix number of uarts in early_init is not upstream, and there's a small cleanup change in it, which makes patch 0002 don't apply (printk to dev_* patch). OK, thanks. One more thing: Please repost your fixes one more time with LAKML Cc'd for review. Then assuming no more comments, I'll merge them into omap-fixes-for-linus. Meanwhile, I'll merge it into l-o master branch for testing. 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
[PATCH 1/7] OMAP3: serial: Check for zero-based physical addr
This is for protecting a wrong mapping attempt of a zero-based
physical address.
The result is that, no serial port will be attempted to be mapped.
Also add an additional protection for NULL clocks before attempting
to enable them (if above condition applies)
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index da77930..ef91fc0 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -664,6 +664,12 @@ void __init omap_serial_early_init(void)
struct device *dev = pdev-dev;
struct plat_serial8250_port *p = dev-platform_data;
+ /* Don't map zero-based physical address */
+ if (p-mapbase == 0) {
+ printk(KERN_WARNING omap serial: No physical address
+ for uart#%d, so skipping early_init...\n, i);
+ continue;
+ }
/*
* Module 4KB + L4 interconnect 4KB
* Static mapping, never released
@@ -727,6 +733,13 @@ void __init omap_serial_init_port(int port)
pdev = uart-pdev;
dev = pdev-dev;
+ /* Don't proceed if there's no clocks available */
+ if (unlikely(!uart-ick || !uart-fck)) {
+ WARN(1, %s: can't init uart%d, no clocks available\n,
+kobject_name(dev-kobj), port);
+ return;
+ }
+
omap_uart_enable_clocks(uart);
omap_uart_reset(uart);
--
1.6.3.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 0/7] omap3: serial code for 3630 and zoom2/3 fixes
Hi, This series contains fixes for omap2/3/4 serial code, and are fixing: - Avoid doing ioremap of a zero-based physical address. (causing a kernel panic during early init on 3630boards) - Unproper omap_revision check during uart globals setup. (omap_revision is not yet filled at that point) - Don't try to enable all uarts generically for zoom2/3 and 3630sdp. - Make zoom2/3 just register one serial port (ttyS0). This is a subset of the original series found here: [1] Thanks to: - Vikram Pandita - Paul Walmsley - Kevin Hilman - Manjunath Kondaiah - Felipe Balbi - Tony Lindgreen For all the feedback recieved so far. Regards, Sergio Detailed changelog: Sergio Aguirre (7): OMAP3: serial: Check for zero-based physical addr OMAP3: serial: Use dev_* macros instead of printk omap2/3/4: serial: Remove condition for getting uart4_phys omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/serial.c | 35 + 6 files changed, 22 insertions(+), 21 deletions(-) [1] http://marc.info/?l=linux-omapm=126826639903105w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] omap3: zoom2/3 / 3630sdp: Don't init always all uarts
This is useless, since in Zoom2/3 boards, the ports aren't even
physically accessible.
They must be explicitly initted in the board-zoom2.c, board-zoom3.c
and board-3630sdp.c files instead.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index ca95d8d..6b39849 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -280,7 +280,6 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
- omap_serial_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
}
--
1.6.3.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 6/7] omap3: zoom 2/3: Change debugboard serial port id
This is now changed to PLAT8250_DEV_PLATFORM (= 0), because
it's the only port that's going to be initialized in
Zoom 2/3 boards.
So, it doesn't make sense to keep the hardcoded 3 value anymore.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-zoom-debugboard.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index bb4018b..e15d2e8 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -96,7 +96,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
static struct platform_device zoom_debugboard_serial_device = {
.name = serial8250,
- .id = 3,
+ .id = PLAT8250_DEV_PLATFORM,
.dev= {
.platform_data = serial_platform_data,
},
--
1.6.3.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 5/7] omap3: 3630sdp: Explicitly enable all UARTs
All UARTs seem physically reachable, so, enable them all.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index a0a2a11..504d2bd 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -96,6 +96,7 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_serial_init();
zoom_peripherals_init();
board_smc91x_init();
enable_board_wakeup_source();
--
1.6.3.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 7/7] omap3: zoom2/3: Register only 1 8250 port
There's no more serial ports available, so, doesn't make sense to create 4 device nodes. Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/configs/omap_zoom2_defconfig |2 +- arch/arm/configs/omap_zoom3_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index f5c6e11..881faea 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -661,7 +661,7 @@ CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 -CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y diff --git a/arch/arm/configs/omap_zoom3_defconfig b/arch/arm/configs/omap_zoom3_defconfig index ea9a501..5e55b55 100644 --- a/arch/arm/configs/omap_zoom3_defconfig +++ b/arch/arm/configs/omap_zoom3_defconfig @@ -680,7 +680,7 @@ CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 -CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y -- 1.6.3.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 2/7] OMAP3: serial: Use dev_* macros instead of printk
As we have a struct device populated at the time we are
printing the errors, using dev_* macros makes more sense,
as could give a better idea where the error/warning came from.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ef91fc0..a55e6ae 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -550,7 +550,7 @@ static ssize_t sleep_timeout_store(struct device *dev,
unsigned int value;
if (sscanf(buf, %u, value) != 1) {
- printk(KERN_ERR sleep_timeout_store: Invalid value\n);
+ dev_err(dev, sleep_timeout_store: Invalid value\n);
return -EINVAL;
}
@@ -666,8 +666,8 @@ void __init omap_serial_early_init(void)
/* Don't map zero-based physical address */
if (p-mapbase == 0) {
- printk(KERN_WARNING omap serial: No physical address
- for uart#%d, so skipping early_init...\n, i);
+ dev_warn(dev, no physical address for uart#%d,
+ so skipping early_init...\n, i);
continue;
}
/*
@@ -676,21 +676,21 @@ void __init omap_serial_early_init(void)
*/
p-membase = ioremap(p-mapbase, SZ_8K);
if (!p-membase) {
- printk(KERN_ERR ioremap failed for uart%i\n, i + 1);
+ dev_err(dev, ioremap failed for uart%i\n, i + 1);
continue;
}
sprintf(name, uart%d_ick, i + 1);
uart-ick = clk_get(NULL, name);
if (IS_ERR(uart-ick)) {
- printk(KERN_ERR Could not get uart%d_ick\n, i + 1);
+ dev_err(dev, Could not get uart%d_ick\n, i + 1);
uart-ick = NULL;
}
sprintf(name, uart%d_fck, i+1);
uart-fck = clk_get(NULL, name);
if (IS_ERR(uart-fck)) {
- printk(KERN_ERR Could not get uart%d_fck\n, i + 1);
+ dev_err(dev, Could not get uart%d_fck\n, i + 1);
uart-fck = NULL;
}
--
1.6.3.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 3/7] omap2/3/4: serial: Remove condition for getting uart4_phys
This check is invalid, since we haven't filled the
omap_revision var at this point.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a55e6ae..3771254 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -128,23 +127,12 @@ static struct plat_serial8250_port
serial_platform_data3[] = {
}
};
-static inline void omap2_set_globals_uart4(struct omap_globals *omap2_globals)
-{
- serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
-}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals *omap2_globals)
-{
-}
-#endif
-
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
serial_platform_data0[0].mapbase = omap2_globals-uart1_phys;
serial_platform_data1[0].mapbase = omap2_globals-uart2_phys;
serial_platform_data2[0].mapbase = omap2_globals-uart3_phys;
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- omap2_set_globals_uart4(omap2_globals);
+ serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
static inline unsigned int __serial_read_reg(struct uart_port *up,
--
1.6.3.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: [PATCH 0/7] omap3: serial code for 3630 and zoom2/3 fixes
From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, March 15, 2010 5:49 PM snip OK, thanks. One more thing: Please repost your fixes one more time with LAKML Cc'd for review. Then assuming no more comments, I'll merge them into omap-fixes-for-linus. Done. Meanwhile, I'll merge it into l-o master branch for testing. Ok, thanks. Regards, Sergio 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: [spi-devel-general] SPI troubles
Thank you very much for your response. As you might have gathered, I seem to have it working but your feedback is really appreciated. I hope to do another run of these boards with these fixes. On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester nforres...@whoi.edu wrote: Your problem is likely caused by pulling the THREE STATE pin to 5V. The spec sheet is explicit (in the Absolute Maximum ratings on page 2, and in the functional description on page 12 that this pin should be pulled to VL, not VCC to enable the outputs. Likely by pulling it to 5V the some part of the chip is biased wrong and may cause OVL1 to be pulled above VL. You are absolutely right. I don't know how I missed that. I just reworked my existing board and it seems to be fine now. A very good find. Thanks a ton. I can't exactly explain the symptoms you report above, based on the mis-connected pin, but most anything could be happening in the MAX3390 once the absolute maximum ratings have been exceeded. The 10K resistors on the THREE STATE lines may have saved the circuit from permanent damage, but they may not save it from improper operation. Well, thankfully at least one of the channels works. Unfortunately, I somehow managed to replace one of the 10k resistors with a 1 ohm, so it's possible that one of the level shifters on this board is fried. Naturally, I've been sampling all of my parts thusfar and only now realized that the MAX1303 is unavailable through the traditional channels (e.g. Digikey, Newark). Other suggestions, nothing fatal... 1. The pinout of the MAX3390E on the drawing is for the TSSOP package. Hopefully that is the package you actually used. Yep, it is. 2. All uncommitted inputs should be terminated high or low. This applies to: LS2 pins 4, 5 and 13; LS3 pin 13 and possibly unused pins on the A/Ds and D/A. Very good point. I really should be a little more careful about this. 3. The MAX3390E family has extremely low drive capability and slow response. Is this device really fast enough for your intended clock rates? Note that the device can only pull down 1ma, and can only pull up 20ua. If there are any pull-downs or pull-ups on the BeagleBoard, the MAX3390E might not be able to drive them. You are right. I had a remarkably difficult time sourcing level shifters for this project at first because I wasn't intending on getting a PCB made. For this reason, I standardized on TSSOP packages, which I could easily get DIP adapters for. I've since realized that getting a PCB made is definitely worth it. 4. I find it curious that the AVDD to the A/D and D/A is fead through a 1ohm resistor that is paralleled by C11 and C12. Likely you meant to tie one side of each of C11 and C12 (the side now connected to C10 positive) to ground. That connection would make a filter to reduce the noise on AVDD rather than passing the noise along. Ouch, you are definitely right. Screwed that up. 5. Is see on the Maxim site that this series of translators is not recommended for new design. Likely the suggested alternatives have much better specifications. Yep, I went with these because they were available in TSSOP. All things considering, I think it might be time to start off with a clean slate. This was an interesting first draft, but I think the constraints it was designed within are largely inapplicable now. TI has some very nice converters that will operate directly on 1.8V signals, which would cut the chip count in half. Unfortunately they are in QFN packages, which seem difficult at best to solder by hand. On the other hand, there are also many higher-channel count TSSOP parts that look pretty enticing, although none of them seem to operate at 1.8V. I was hoping to finish this design up over the Spring break (now), but I guess our data-taking will just have to wait. Arg. Thanks a ton for your help. It's far too easy to overlook your own mistakes. - Ben -- 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: [spi-devel-general] SPI troubles
On 03/15/2010 09:06 PM, Ben Gamari wrote: Thank you very much for your response. As you might have gathered, I seem to have it working but your feedback is really appreciated. I hope to do another run of these boards with these fixes. On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester nforres...@whoi.edu wrote: Your problem is likely caused by pulling the THREE STATE pin to 5V. The spec sheet is explicit (in the Absolute Maximum ratings on page 2, and in the functional description on page 12 that this pin should be pulled to VL, not VCC to enable the outputs. Likely by pulling it to 5V the some part of the chip is biased wrong and may cause OVL1 to be pulled above VL. You are absolutely right. I don't know how I missed that. I just reworked my existing board and it seems to be fine now. A very good find. Thanks a ton. Glad I could help. I can't exactly explain the symptoms you report above, based on the mis-connected pin, but most anything could be happening in the MAX3390 once the absolute maximum ratings have been exceeded. The 10K resistors on the THREE STATE lines may have saved the circuit from permanent damage, but they may not save it from improper operation. Well, thankfully at least one of the channels works. Unfortunately, I somehow managed to replace one of the 10k resistors with a 1 ohm, so it's possible that one of the level shifters on this board is fried. Naturally, I've been sampling all of my parts thusfar and only now realized that the MAX1303 is unavailable through the traditional channels (e.g. Digikey, Newark). www.findchips.com covers most of the usual US distributors. It's not really restricted to chips, any part number works fine. Maxim encourages direct purchase from their web site, so sometimes that is the best place to find stock. There are 41 in stock at Avnet, in the TQFN package. Not what you would like to hand solder, but it can be done if the lands on the PCB are designed to stick out farther than usual, so that you can get the iron on the land (since you can't reach the pin itself). A flux pen helps, such as Kester #951 (but read the Material Safety Data Sheet). As someone said on the net years ago (and still true, except for things like ball grid arrays), They haven't yet invented a surface mount part that can't be hand soldered with a temperature controlled iron and $2000 worth of optics and lighting. Other suggestions, nothing fatal... 1. The pinout of the MAX3390E on the drawing is for the TSSOP package. Hopefully that is the package you actually used. Yep, it is. 2. All uncommitted inputs should be terminated high or low. This applies to: LS2 pins 4, 5 and 13; LS3 pin 13 and possibly unused pins on the A/Ds and D/A. Very good point. I really should be a little more careful about this. 3. The MAX3390E family has extremely low drive capability and slow response. Is this device really fast enough for your intended clock rates? Note that the device can only pull down 1ma, and can only pull up 20ua. If there are any pull-downs or pull-ups on the BeagleBoard, the MAX3390E might not be able to drive them. You are right. I had a remarkably difficult time sourcing level shifters for this project at first because I wasn't intending on getting a PCB made. For this reason, I standardized on TSSOP packages, which I could easily get DIP adapters for. I've since realized that getting a PCB made is definitely worth it. I don't have boards hand assembled any more. The parts are just too small, and you have to have a really good tech (or be one) to get a job as clean and reliable as with soldering in a oven. There are lots of assembly houses out there. 4. I find it curious that the AVDD to the A/D and D/A is fed through a 1ohm resistor that is paralleled by C11 and C12. Likely you meant to tie one side of each of C11 and C12 (the side now connected to C10 positive) to ground. That connection would make a filter to reduce the noise on AVDD rather than passing the noise along. Ouch, you are definitely right. Screwed that up. 5. I see on the Maxim site that this series of translators is not recommended for new design. Likely the suggested alternatives have much better specifications. Yep, I went with these because they were available in TSSOP. All things considering, I think it might be time to start off with a clean slate. This was an interesting first draft, but I think the constraints it was designed within are largely inapplicable now. TI has some very nice converters that will operate directly on 1.8V signals, which would cut the chip count in half. Unfortunately they are in QFN packages, which seem difficult at best to solder by hand. On the other hand, there are also many higher-channel count TSSOP parts that look pretty enticing, although none of them seem to operate at 1.8V. I have been using TI translators recently; that is, when I don't use a CPLD or FPGA (there's
