Re: [PATCH 3/5] usb: ehci: relocate PHY reset code
On Wed, Aug 18, 2010 at 04:55:43AM +0200, ext Keshava Munegowda wrote:
The PHY reset code is moved at the begining and end of the function
omap_start_ehc. This simplfies the writing clocks enabling code for
OMAP4 later.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c | 52 +--
1 file changed, 26 insertions(+), 26 deletions(-)
Index: linux-2.6/drivers/usb/host/ehci-omap.c
===
--- linux-2.6.orig/drivers/usb/host/ehci-omap.c
+++ linux-2.6/drivers/usb/host/ehci-omap.c
@@ -279,6 +279,24 @@ static int omap_start_ehc(struct ehci_hc
dev_dbg(omap-dev, starting TI EHCI USB Controller\n);
+ if (omap-phy_reset) {
+ /* Refer: ISSUE1 */
+ if (gpio_is_valid(omap-reset_gpio_port[0])) {
+ gpio_request(omap-reset_gpio_port[0],
+ USB1 PHY reset);
+ gpio_direction_output(omap-reset_gpio_port[0], 0);
+ }
+
+ if (gpio_is_valid(omap-reset_gpio_port[1])) {
+ gpio_request(omap-reset_gpio_port[1],
+ USB2 PHY reset);
+ gpio_direction_output(omap-reset_gpio_port[1], 0);
+ }
+
+ /* Hold the PHY in RESET for enough time till DIR is high */
+ udelay(10);
+ }
there was another patch doing this with ulpi messages and that's more
portable as every board will have support for softreset but we can't
guarantee all of them will have these gpio routed correctly, right ?
--
balbi
DefectiveByDesign.org
--
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 5/6] usb: ohci: don't hard-code TLL channel count
Hi,
On Wed, Aug 18, 2010 at 04:55:45AM +0200, ext Keshava Munegowda wrote:
@@ -245,7 +245,8 @@ static unsigned ohci_omap3_fslsmode(enum
}
}
-static void ohci_omap3_tll_config(struct ohci_hcd_omap3 *omap)
+static void ohci_omap3_tll_config(struct ohci_hcd_omap3 *omap,
+ u8 tll_channel_count)
{
u32 reg;
int i;
@@ -263,7 +264,7 @@ static void ohci_omap3_tll_config(struct
* REVISIT: Only the 3-pin and 4-pin PHY modes have
* actually been tested.
*/
- for (i = 0; i OMAP_TLL_CHANNEL_COUNT; i++) {
+ for (i = 0; i tll_channel_count; i++) {
/* Enable only those channels that are actually used */
if (omap-port_mode[i] == OMAP_OHCI_PORT_MODE_UNUSED)
@@ -422,7 +423,7 @@ static int omap3_start_ohci(struct ohci_
ohci_omap_writel(omap-uhh_base, OMAP_UHH_HOSTCONFIG, reg);
dev_dbg(omap-dev, UHH setup done, uhh_hostconfig=%x\n, reg);
- ohci_omap3_tll_config(omap);
+ ohci_omap3_tll_config(omap, OMAP_TLL_CHANNEL_COUNT);
it's still hardcoded, are you planning to change this in any way ?
Otherwise I don't see the point for this patch.
--
balbi
DefectiveByDesign.org
--
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 5/6] usb: ohci: don't hard-code TLL channel count
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Thursday, August 19, 2010 11:33 AM
To: Munegowda, Keshava
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gadiyar, Anand
Subject: Re: [PATCH 5/6] usb: ohci: don't hard-code TLL channel count
Hi,
On Wed, Aug 18, 2010 at 04:55:45AM +0200, ext Keshava Munegowda wrote:
@@ -245,7 +245,8 @@ static unsigned ohci_omap3_fslsmode(enum
}
}
-static void ohci_omap3_tll_config(struct ohci_hcd_omap3 *omap)
+static void ohci_omap3_tll_config(struct ohci_hcd_omap3 *omap,
+u8 tll_channel_count)
{
u32 reg;
int i;
@@ -263,7 +264,7 @@ static void ohci_omap3_tll_config(struct
* REVISIT: Only the 3-pin and 4-pin PHY modes have
* actually been tested.
*/
-for (i = 0; i OMAP_TLL_CHANNEL_COUNT; i++) {
+for (i = 0; i tll_channel_count; i++) {
/* Enable only those channels that are actually used */
if (omap-port_mode[i] == OMAP_OHCI_PORT_MODE_UNUSED)
@@ -422,7 +423,7 @@ static int omap3_start_ohci(struct ohci_
ohci_omap_writel(omap-uhh_base, OMAP_UHH_HOSTCONFIG, reg);
dev_dbg(omap-dev, UHH setup done, uhh_hostconfig=%x\n, reg);
-ohci_omap3_tll_config(omap);
+ohci_omap3_tll_config(omap, OMAP_TLL_CHANNEL_COUNT);
it's still hardcoded, are you planning to change this in any way ?
Otherwise I don't see the point for this patch.
--
balbi
The function ohci_omap3_tll_config will be used with different tll channel
count in case of OMAP4 support soon, hence this change is required. We have
removed only the hardcoded values used by this function.
Keshava Munegowda
DefectiveByDesign.org
--
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 v5 1/3] ARM: OMAP: Beagle: revision detection
On Wed, 18 Aug 2010 10:56:51 -0500 Robert Nelson robertcnel...@gmail.com wrote: + ret = gpio_request(171, rev_id_0); + if (ret 0) + goto fail0; + + ret = gpio_request(172, rev_id_1); + if (ret 0) + goto fail1; + + ret = gpio_request(173, rev_id_2); + if (ret 0) + goto fail2; ... +fail2: + gpio_free(173); +fail1: + gpio_free(172); +fail0: + gpio_free(171); This must be: +fail2: + gpio_free(172); +fail1: + gpio_free(171); +fail0: Otherwise the set looks good to me. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] power_supply: add isp1704 charger detection driver
Hi,
On Wed, Aug 18, 2010 at 03:42:37PM +0200, ext Anton Vorontsov wrote:
On Wed, Aug 18, 2010 at 04:01:05PM +0300, Krogerus Heikki
(EXT-Teleca/Helsinki) wrote:
NXP ISP1704 is Battery Charging Specification 1.0 compliant USB
transceiver. This adds a power supply driver for ISP1704 and
ISP1707 USB transceivers.
Signed-off-by: Heikki Krogerus ext-heikki.kroge...@nokia.com
---
I like this driver (very). A few, mostly cosmetic comments down
below.
[...]
+config CHARGER_ISP1704
+ tristate ISP1704 USB Charger Detection
+ select NOP_USB_XCEIV if ! MACH_NOKIA_RX51
+ help
! MACH_NOKIA_RX51 looks wrong here. You probably don't actually
need this if you fix platform device registration issue (see the
very bottom of this email).
[...]
+/*
+ * ISP1704 detects PS/2 adapters as charger. To make sure the detected
charger
+ * is actually a dedicated charger, the following steps need to be taken.
+ */
+static inline int isp1704_charger_verify(struct isp1704_charger *isp)
+{
+u8 r, ret = 0;
Please put variable declarations on separate lines, plus,
'ret' should probably be int, i.e.
int ret;
u8 r;
OK
+
+/* Reset the transceiver */
+r = otg_io_read(isp-otg, ULPI_FUNC_CTRL);
+r |= ULPI_FUNC_CTRL_RESET;
+otg_io_write(isp-otg, ULPI_FUNC_CTRL, r);
+usleep_range(1000, 2000);
+
+/* Set normal mode */
+r = ~(ULPI_FUNC_CTRL_RESET | ULPI_FUNC_CTRL_OPMODE_MASK);
+otg_io_write(isp-otg, ULPI_FUNC_CTRL, r);
+
+/* Clear the DP and DM pull-down bits */
+r = ULPI_OTG_CTRL_DP_PULLDOWN | ULPI_OTG_CTRL_DM_PULLDOWN;
+otg_io_write(isp-otg, ULPI_CLR(ULPI_OTG_CTRL), r);
+
+/* Enable strong pull-up on DP (1.5K) and reset */
+r = ULPI_FUNC_CTRL_TERMSELECT | ULPI_FUNC_CTRL_RESET;
+otg_io_write(isp-otg, ULPI_SET(ULPI_FUNC_CTRL), r);
+usleep_range(1000, 2000);
+
+/* Read the line state */
+if (otg_io_read(isp-otg, ULPI_DEBUG)) {
+/* Is it a charger or PS/2 connection */
+
+/* Enable weak pull-up resistor on DP */
+otg_io_write(isp-otg, ULPI_SET(ISP1704_PWR_CTRL),
+ISP1704_PWR_CTRL_DP_WKPU_EN);
+
+/* Disable strong pull-up on DP (1.5K) */
+otg_io_write(isp-otg, ULPI_CLR(ULPI_FUNC_CTRL),
+ULPI_FUNC_CTRL_TERMSELECT);
+
+/* Enable weak pull-down resistor on DM */
+otg_io_write(isp-otg, ULPI_SET(ULPI_OTG_CTRL),
+ULPI_OTG_CTRL_DM_PULLDOWN);
+
+/* It's a charger if the line states are clear */
+if (!(otg_io_read(isp-otg, ULPI_DEBUG)))
+ret = 1;
+
+/* Disable weak pull-up resistor on DP */
+otg_io_write(isp-otg, ULPI_CLR(ISP1704_PWR_CTRL),
+ISP1704_PWR_CTRL_DP_WKPU_EN);
+} else {
+ret = 1;
+
+/* Disable strong pull-up on DP (1.5K) */
+otg_io_write(isp-otg, ULPI_CLR(ULPI_FUNC_CTRL),
+ULPI_FUNC_CTRL_TERMSELECT);
+}
How about
if (!otg_io_read(isp-otg, ULPI_DEBUG)) {
/* Disable strong pull-up on DP (1.5K) */
otg_io_write(isp-otg, ULPI_CLR(ULPI_FUNC_CTRL),
ULPI_FUNC_CTRL_TERMSELECT);
return 1;
}
the rest
Saves indentation level.
Yes, makes sense.
+return ret;
+}
+
+static inline int isp1704_charger_detect(struct isp1704_charger *isp)
+{
+unsigned long timeout;
+u8 r;
+int vdat;
+
+/* set SW control bit in PWR_CTRL register */
+otg_io_write(isp-otg, ISP1704_PWR_CTRL,
+ISP1704_PWR_CTRL_SWCTRL);
+
+/* enable manual charger detection */
+r = (ISP1704_PWR_CTRL_SWCTRL | ISP1704_PWR_CTRL_DPVSRC_EN);
+otg_io_write(isp-otg, ULPI_SET(ISP1704_PWR_CTRL), r);
+usleep_range(1000, 2000);
+
+timeout = jiffies + msecs_to_jiffies(300);
+while (!time_after(jiffies, timeout)) {
I guess it is possible that vdat might become uninitialized
if the code never hits the loop. The time between
timeout = jiffies + msecs_to_jiffies(300);
and
while (!time_after(jiffies, timeout)) {
is undefined.
So do while loop it is.
+/* Check if there is a charger */
+vdat = !!(otg_io_read(isp-otg, ISP1704_PWR_CTRL)
+ ISP1704_PWR_CTRL_VDAT_DET);
Technically, there is no need for !!.
VDAT_DET is the fifth bit, and since vdat is returned, it would end up
being the value for isp-present. However..
+if (vdat)
+break;
+}
+return vdat;
+}
+
+static void isp1704_charger_work(struct work_struct *data)
+{
+struct isp1704_charger *isp =
+container_of(data, struct isp1704_charger, work);
+
+/* FIXME Only supporting dedicated chargers even though isp1704 can
+ * detect HUB
RE: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Saturday, August 14, 2010 4:15 AM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; t...@atomide.com; dbrown...@users.sourceforge.net; spi-devel-gene...@lists.sourceforge.net; Nayak, Rajendra; Basak, Partha; Raja, Govindraj Subject: Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com wrote: This patch series implements McSPI Module in HWMOD FW way and use the runtime PM layer. Hi Charulatha, I'll go through and review the patches, but I'm unfamiliar with HWMOD. Is there a description of HWMOD that you can point me at? The following link could be of some help: http://omappedia.org/wiki/HWMOD#Steps_involved_in_HWMOD Thanks, g. This patch series is created on origin/pm-wip/hwmods-omap4 with McSPI slave mode patches (url given below) on top of it. https://patchwork.kernel.org/patch/79677/ Updated McSPI slave mode patches will be posted shortly by Govindraj. McSPI slave mode patches were already discussed on open source mailing list and they are almost towards the end of final rebased version. Hence hwmod patches are created on top of McSPI slave mode patch series to avoid major rework later on. Benoit Cousson (1): OMAP4 HWMOD: Add mcspi hwmods. Charulatha V (3): OMAP2420: McSPI: Add mcspi hwmod OMAP2430 : McSPI: Add mcspi hwmod data OMAP3 HWMOD: Add mcspi hwmods. Govindraj.R (1): OMAP McSPI: Adapt McSPI driver to use omap hwmod arch/arm/mach-omap2/clock3xxx_data.c | 4 + arch/arm/mach-omap2/devices.c | 233 + --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 138 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 196 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 252 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244 + arch/arm/plat-omap/include/plat/mcspi.h | 27 +++ drivers/spi/omap2_mcspi.c | 273 + --- 8 files changed, 1034 insertions(+), 333 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] power_supply: add isp1704 charger detection driver
Hi,
On Wed, Aug 18, 2010 at 04:55:28PM +0200, Quadros Roger (Nokia-MS/Helsinki)
wrote:
On 08/18/2010 04:01 PM, Krogerus Heikki (EXT-Teleca/Helsinki) wrote:
NXP ISP1704 is Battery Charging Specification 1.0 compliant USB
transceiver. This adds a power supply driver for ISP1704 and
ISP1707 USB transceivers.
snip
+static inline int isp1704_test_ulpi(struct isp1704_charger *isp)
+{
+ int vendor, product, i;
+ int ret = -ENODEV;
+
+ /* Test ULPI interface */
+ ret = otg_io_write(isp-otg, ULPI_SCRATCH, 0xaa);
+ if (ret 0)
+ return ret;
+ ret = otg_io_read(isp-otg, ULPI_SCRATCH);
+ if (ret 0)
+ return ret;
+ if (ret != 0xaa)
+ return -ENODEV;
+ /* Verify the product and vendor id matches */
+ vendor = otg_io_read(isp-otg, ULPI_VENDOR_ID_LOW);
+ vendor |= otg_io_read(isp-otg, ULPI_VENDOR_ID_HIGH) 8;
+ if (vendor != NXP_VENDOR_ID)
+ return -ENODEV;
+ for (i = 0; i ARRAY_SIZE(isp170x_id); i++) {
+ product = otg_io_read(isp-otg, ULPI_PRODUCT_ID_LOW);
+ product |= otg_io_read(isp-otg, ULPI_PRODUCT_ID_HIGH) 8;
product id should be read outside the for loop. This way you will save
unnecessary otg_io_reads. product id won't change anyways.
Good point. Fixing.
+ if (product == isp170x_id[i]) {
+ sprintf(isp-model, isp%x, product);
+ return product;
+ }
+ }
+
+ dev_err(isp-dev, product id %x not matching known ids, product);
+
+ return -ENODEV;
+}
snip
+static struct platform_driver isp1704_charger_driver = {
+ .driver = {
+ .name = isp1704_charger,
+ },
+ .probe = isp1704_charger_probe,
+ .remove = __devexit_p(isp1704_charger_remove),
+};
+
+static struct platform_device *isp1704_device;
+
+static int __init isp1704_charger_init(void)
+{
+ int ret = 0;
+
+ ret = platform_driver_register(isp1704_charger_driver);
+ if (ret)
+ return ret;
+
+ isp1704_device = platform_device_register_simple(isp1704_charger,
+ 0, NULL, 0);
This platform_device_register should be done in the rx51 board file. i.e.
board-rx51-peripherals.c
OK. I'll fix this.
Thanks,
--
heikki
--
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 5/6] usb: ohci: don't hard-code TLL channel count
Hi, please teach your mailer to break the lines at 80 characters. On Thu, Aug 19, 2010 at 08:26:06AM +0200, ext Munegowda, Keshava wrote: The function ohci_omap3_tll_config will be used with different tll channel count in case of OMAP4 support soon, hence this change is required. We have removed only the hardcoded values used by this function. ok then. That's what I expected to hear. -- balbi DefectiveByDesign.org -- 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 5/6] usb: ohci: don't hard-code TLL channel count
-Original Message- From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Thursday, August 19, 2010 12:53 PM To: Munegowda, Keshava Cc: Balbi Felipe (Nokia-MS/Helsinki); linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gadiyar, Anand Subject: Re: [PATCH 5/6] usb: ohci: don't hard-code TLL channel count Hi, please teach your mailer to break the lines at 80 characters. On Thu, Aug 19, 2010 at 08:26:06AM +0200, ext Munegowda, Keshava wrote: The function ohci_omap3_tll_config will be used with different tll channel count in case of OMAP4 support soon, hence this change is required. We have removed only the hardcoded values used by this function. ok then. That's what I expected to hear. -- balbi DefectiveByDesign.org Thanks balbi, sure I take care this in future. Keshava Munegowda -- 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/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Russell King - ARM Linux li...@arm.linux.org.uk [100817 18:33]: On Tue, Aug 17, 2010 at 05:12:11PM +0300, Tony Lindgren wrote: Great, will give it a try hopefully tomorrow. Sounds like that's the way to deal with fixing up things when booting up older UP ARMv6 without the 32v6 support :) What I've also been debating about is adding another word to the smpalt structure, that being a set of flags which denote the situation where the alternative should be used. That means we can use it to do individual word replacements for SMP vs UP, ARMv6 vs ARMv6k etc. Sounds good to me. Maybe it should then be called cpualt instead of smpalt? Tried booting your patch and needed the following fix for Cortex-A8 UP. Now it boots to the following error: Machine configuration botched (nr -1073741824), unable to continue. Does some struct size need to be changed or something? Regards, Tony From: Tony Lindgren t...@atomide.com Date: Thu, 19 Aug 2010 10:22:23 +0300 Subject: [PATCH] Fix smp_on_up detection This is needed to detect UP properly on older ARMv7 like Cortex-A8. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -346,8 +346,10 @@ __fixup_smp: bne smp_on_up @ no, assume UP mrc p15, 0, r0, c0, c0, 5 @ read MIDR movs r0, r0, lsr #30 - teqne r0, #3 @ check top two bits 00 or 11 - moveq pc, lr + teq r0, #0 @ check two top bits 00 + beq smp_on_up @ yes, assume UP + teq r0, #3 @ check top two bits 11 + movne pc, lr @ no, running on SMP hw smp_on_up: adr r0, 1f
Re: [PATCH 12/14] omap2/3: Fix initcalls for multi-omap
On Tue, Jan 26, 2010 at 12:13:04 -0800, Tony Lindgren wrote:
Otherwise the wrong initcalls can run.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock2xxx.c |2 +-
arch/arm/mach-omap2/clock34xx.c |2 +-
arch/arm/mach-omap2/emu.c |3 +++
May I ask what stopped you from CCing me on this patch?
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index 43e7404..1a31b72 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -598,7 +598,7 @@ static int __init omap2_clk_arch_init(void)
struct clk *virt_prcm_set, *sys_ck, *dpll_ck, *mpu_ck;
unsigned long sys_ck_rate;
- if (!mpurate)
+ if (!(cpu_is_omap24xx() mpurate))
return -EINVAL;
virt_prcm_set = clk_get(NULL, virt_prcm_set);
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index f485a89..03720bc 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -317,7 +317,7 @@ static int __init omap2_clk_arch_init(void)
struct clk *osc_sys_ck, *dpll1_ck, *arm_fck, *core_ck;
unsigned long osc_sys_rate;
- if (!mpurate)
+ if (!(cpu_is_omap34xx() mpurate))
return -EINVAL;
/* XXX test these for success */
diff --git a/arch/arm/mach-omap2/emu.c b/arch/arm/mach-omap2/emu.c
index ec0d984..9c442e2 100644
--- a/arch/arm/mach-omap2/emu.c
+++ b/arch/arm/mach-omap2/emu.c
@@ -56,6 +56,9 @@ static struct amba_device omap3_etm_device = {
static int __init emu_init(void)
{
+ if (!cpu_is_omap34xx())
+ return -ENODEV;
+
amba_device_register(omap3_etb_device, iomem_resource);
amba_device_register(omap3_etm_device, iomem_resource);
Regards,
--
Alex
--
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 12/14] omap2/3: Fix initcalls for multi-omap
* Alexander Shishkin virtu...@slind.org [100819 12:04]:
On Tue, Jan 26, 2010 at 12:13:04 -0800, Tony Lindgren wrote:
Otherwise the wrong initcalls can run.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock2xxx.c |2 +-
arch/arm/mach-omap2/clock34xx.c |2 +-
arch/arm/mach-omap2/emu.c |3 +++
May I ask what stopped you from CCing me on this patch?
Hmm, sorry I don't follow you. Did I accidentally leave out something?
Regards,
Tony
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx.c
b/arch/arm/mach-omap2/clock2xxx.c
index 43e7404..1a31b72 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -598,7 +598,7 @@ static int __init omap2_clk_arch_init(void)
struct clk *virt_prcm_set, *sys_ck, *dpll_ck, *mpu_ck;
unsigned long sys_ck_rate;
- if (!mpurate)
+ if (!(cpu_is_omap24xx() mpurate))
return -EINVAL;
virt_prcm_set = clk_get(NULL, virt_prcm_set);
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index f485a89..03720bc 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -317,7 +317,7 @@ static int __init omap2_clk_arch_init(void)
struct clk *osc_sys_ck, *dpll1_ck, *arm_fck, *core_ck;
unsigned long osc_sys_rate;
- if (!mpurate)
+ if (!(cpu_is_omap34xx() mpurate))
return -EINVAL;
/* XXX test these for success */
diff --git a/arch/arm/mach-omap2/emu.c b/arch/arm/mach-omap2/emu.c
index ec0d984..9c442e2 100644
--- a/arch/arm/mach-omap2/emu.c
+++ b/arch/arm/mach-omap2/emu.c
@@ -56,6 +56,9 @@ static struct amba_device omap3_etm_device = {
static int __init emu_init(void)
{
+ if (!cpu_is_omap34xx())
+ return -ENODEV;
+
amba_device_register(omap3_etb_device, iomem_resource);
amba_device_register(omap3_etm_device, iomem_resource);
Regards,
--
Alex
--
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-udc stressed full duplex usb communication.
Hello
I'm working on an Omap target:
CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177
Machine: TI OMAP1710 HW20acq board
Memory policy: ECC disabled, Data cache writeback
OMAP1710 revision 8 handled as 16xx id: 8b5f702f03330200
I use the usb as cdc_acm and the communication in the both ways is very
stressed.
Some time the device receives a strange IRQ from EP0, which stop all
data reception from USB.
The usb registers during this IRQ are:
IRQ_SRC : 0xB0
EPN_STAT : 0x01
EP_NUM : 0x11
STAT_FLG : 0x00
The TI inc. documentation explains that the IRQ_SRC is TX and RX in the
same time. (the irq callback can manage only one). But EPN_STAT gives
only the EP number of the TX request.
In the same documentation we can read p15-67:
11:8 EPn_RX_IT_SRC The receive endpoint interrupt source (non-ISO) bit
only concerns non-ISO enpoints...
000: No receive endpoint interrupt is pending
I send you my patch. I hope that it will be usefull.
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index f81e4f0..863f692 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -1948,7 +1948,7 @@ static irqreturn_t omap_udc_pio_irq(int irq, void
*_dev)
u16 epn_stat, irq_src;
irqreturn_t status = IRQ_NONE;
struct omap_ep *ep;
- int epnum;
+ int epnum, epnumrx, epnumtx;
struct omap_udc *udc = _dev;
struct omap_req *req;
unsigned long flags;
@@ -1957,9 +1957,11 @@ static irqreturn_t omap_udc_pio_irq(int irq, void
*_dev)
epn_stat = omap_readw(UDC_EPN_STAT);
irq_src = omap_readw(UDC_IRQ_SRC);
+ epnumrx = (epn_stat 8) 0x0f;
+ epnumtx = epn_stat 0x0f;
/* handle OUT first, to avoid some wasteful NAKs */
- if (irq_src UDC_EPN_RX) {
- epnum = (epn_stat 8) 0x0f;
+ if ((irq_src UDC_EPN_RX) epnumrx) {
+ epnum = epnumrx;
omap_writew(UDC_EPN_RX, UDC_IRQ_SRC);
status = IRQ_HANDLED;
ep = udc-ep[epnum];
@@ -1994,8 +1996,8 @@ static irqreturn_t omap_udc_pio_irq(int irq, void
*_dev)
}
/* then IN transfers */
- else if (irq_src UDC_EPN_TX) {
- epnum = epn_stat 0x0f;
+ else if ((irq_src UDC_EPN_TX) epnumtx){
+ epnum = epnumtx;
omap_writew(UDC_EPN_TX, UDC_IRQ_SRC);
status = IRQ_HANDLED;
ep = udc-ep[16 + epnum];
This message, including attachments, is intended solely for the addressee
indicated in this message and is strictly confidential or otherwise privileged.
If you are not the intended recipient (or responsible for delivery of the
message to such person) : - (1) please immediately (i) notify the sender by
reply email and (ii) delete this message and attachments, - (2) any use, copy
or dissemination of this transmission is strictly prohibited. If you or your
employer does not consent to Internet email messages of this kind, please
advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and
other information expressed in this message are not given or endorsed by Myriad
Group AG unless otherwise indicated by an authorized representative independent
of this message.
--
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/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
On 08/19/2010 03:38 PM, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100817 18:33]: On Tue, Aug 17, 2010 at 05:12:11PM +0300, Tony Lindgren wrote: Great, will give it a try hopefully tomorrow. Sounds like that's the way to deal with fixing up things when booting up older UP ARMv6 without the 32v6 support :) What I've also been debating about is adding another word to the smpalt structure, that being a set of flags which denote the situation where the alternative should be used. That means we can use it to do individual word replacements for SMP vs UP, ARMv6 vs ARMv6k etc. Sounds good to me. Maybe it should then be called cpualt instead of smpalt? Tried booting your patch and needed the following fix for Cortex-A8 UP. Now it boots to the following error: Machine configuration botched (nr -1073741824), unable to continue. Does some struct size need to be changed or something? I also tested these 2 patches on my beagle board based on -for-next branch for linux-omap tree. I don't have debug hardware to find the kernel boot failure. It looks like it stops at very early stage. Do you know where is the message (nr -1073741824) coming from? Thanks, -- Bryan Wu bryan...@canonical.com Kernel Developer+86.138-1617-6545 Mobile Ubuntu Kernel Team | Hardware Enablement Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] : omap-udc stressed full duplex usb communication.
Hello again,
This is another patch for the same file. I send two patches because the
first one is really a bug correction for all target.
I tested this one with only mine and I'm not sure that there is not
trouble with other targets.
The IRQ callback (omap_udc_pio_irq) starts a timer (ep-timer,
PIO_OUT_TIMEOUT) which starts again itself. Then this callback is called
repeatly and uses ressources all the time. When I read the code, I
understand that this timer callback (pio_out_timer) does the same work
that the IRQ callback, if the treatement is not complete.
On my target we have not enought ressources to manage the real IRQ and
this timer. Then I start it only if the treatement is not done.
On my target the kernel receives all IRQ then the timer is useless.
Perhaps some targets have some troubles to receive all IRQ
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index f81e4f0..9da4d98 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -1919,6 +1919,7 @@ static void pio_out_timer(unsigned long _ep)
struct omap_ep *ep = (void *) _ep;
unsigned long flags;
u16 stat_flg;
+ int stat = -1;
spin_lock_irqsave(ep-udc-lock, flags);
if (!list_empty(ep-queue) ep-ackwait) {
@@ -1932,14 +1933,14 @@ static void pio_out_timer(unsigned long _ep)
VDBG(%s: lose, %04x\n, ep-ep.name, stat_flg);
req = container_of(ep-queue.next,
struct omap_req, queue);
- (void) read_fifo(ep, req);
+ stat = read_fifo(ep, req);
omap_writew(ep-bEndpointAddress, UDC_EP_NUM);
omap_writew(UDC_SET_FIFO_EN, UDC_CTRL);
ep-ackwait = 1 + ep-double_buf;
} else
deselect_ep();
}
- mod_timer(ep-timer, PIO_OUT_TIMEOUT);
+ if (stat == -1) mod_timer(ep-timer, PIO_OUT_TIMEOUT);
spin_unlock_irqrestore(ep-udc-lock, flags);
}
@@ -1948,7 +1949,7 @@ static irqreturn_t omap_udc_pio_irq(int irq, void
*_dev)
u16 epn_stat, irq_src;
irqreturn_t status = IRQ_NONE;
struct omap_ep *ep;
- int epnum;
+ int epnum, epnumrx, epnumtx;
struct omap_udc *udc = _dev;
struct omap_req *req;
unsigned long flags;
@@ -1957,9 +1958,12 @@ static irqreturn_t omap_udc_pio_irq(int irq, void
*_dev)
epn_stat = omap_readw(UDC_EPN_STAT);
irq_src = omap_readw(UDC_IRQ_SRC);
+ epnumrx = (epn_stat 8) 0x0f;
+ epnumtx = epn_stat 0x0f;
/* handle OUT first, to avoid some wasteful NAKs */
- if (irq_src UDC_EPN_RX) {
- epnum = (epn_stat 8) 0x0f;
+ if ((irq_src UDC_EPN_RX) epnumrx) {
+ int stat = -1;
+ epnum = epnumrx;
omap_writew(UDC_EPN_RX, UDC_IRQ_SRC);
status = IRQ_HANDLED;
ep = udc-ep[epnum];
@@ -1970,7 +1974,6 @@ static irqreturn_t omap_udc_pio_irq(int irq, void
*_dev)
if (omap_readw(UDC_STAT_FLG) UDC_ACK) {
ep-ackwait--;
if (!list_empty(ep-queue)) {
- int stat;
req = container_of(ep-queue.next,
struct omap_req, queue);
stat = read_fifo(ep, req);
@@ -1990,12 +1993,12 @@ static irqreturn_t omap_udc_pio_irq(int irq,
void *_dev)
omap_writew(UDC_SET_FIFO_EN, UDC_CTRL);
ep-ackwait = 1 + ep-double_buf;
}
- mod_timer(ep-timer, PIO_OUT_TIMEOUT);
+ if (stat == -1) mod_timer(ep-timer, PIO_OUT_TIMEOUT);
}
/* then IN transfers */
- else if (irq_src UDC_EPN_TX) {
- epnum = epn_stat 0x0f;
+ else if ((irq_src UDC_EPN_TX) epnumtx){
+ epnum = epnumtx;
omap_writew(UDC_EPN_TX, UDC_IRQ_SRC);
status = IRQ_HANDLED;
ep = udc-ep[16 + epnum];
This message, including attachments, is intended solely for the addressee
indicated in this message and is strictly confidential or otherwise privileged.
If you are not the intended recipient (or responsible for delivery of the
message to such person) : - (1) please immediately (i) notify the sender by
reply email and (ii) delete this message and attachments, - (2) any use, copy
or dissemination of this transmission is strictly prohibited. If you or your
employer does not consent to Internet email messages of this kind, please
advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and
other information expressed in this message are not given or endorsed by Myriad
Group AG unless otherwise
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Bryan Wu bryan...@canonical.com [100819 12:31]: On 08/19/2010 03:38 PM, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100817 18:33]: On Tue, Aug 17, 2010 at 05:12:11PM +0300, Tony Lindgren wrote: Great, will give it a try hopefully tomorrow. Sounds like that's the way to deal with fixing up things when booting up older UP ARMv6 without the 32v6 support :) What I've also been debating about is adding another word to the smpalt structure, that being a set of flags which denote the situation where the alternative should be used. That means we can use it to do individual word replacements for SMP vs UP, ARMv6 vs ARMv6k etc. Sounds good to me. Maybe it should then be called cpualt instead of smpalt? Tried booting your patch and needed the following fix for Cortex-A8 UP. Now it boots to the following error: Machine configuration botched (nr -1073741824), unable to continue. Does some struct size need to be changed or something? I also tested these 2 patches on my beagle board based on -for-next branch for linux-omap tree. I don't have debug hardware to find the kernel boot failure. It looks like it stops at very early stage. Do you know where is the message (nr -1073741824) coming from? Looks like something is not quite right with smp_on_up part of __fixup_smp, returning early before smp_on_up does not produce that. 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/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote: Looks like something is not quite right with smp_on_up part of __fixup_smp, returning early before smp_on_up does not produce that. It's probably overwriting some register it shouldn't be. I might be able to look at this sometime during the coming week... assuming that the weather is as bad as they forecast and I have 'net connectivity. -- 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: OMAP2PLUS dpll rate calculation.
Hi Thara, On 8/18/2010 8:46 AM, Gopinath, Thara wrote: Hello Paul/Kevin, Recently I noticed that the dpll rate calculation code in arch/arm/mach-omap2/clkt_dpll.c is as follows dpll_clk = (long long)dd-clk_ref-rate * dpll_mult; do_div(dpll_clk, dpll_div + 1); But the actual trm for both OMAP3 and OMAP4 (I believe this is true for OMAP2 also) shows that the dpll output rate should be calculated as ref_clk * 2 * M / (N + 1). That's true, technically speaking the DPLL is locked at twice the required frequency. This is mandatory in order to generate the X2 output. Fdpll = ref_clk * 2 * M / (N + 1). In fact the DPLL IP has 3 outputs CLKOUT_M2 = Fdpll / (2 x M2) CLKOUTX2_M2 = Fdpll / M2 CLKOUTX2_M3 = (Fdpll or CLKINPHIF) / M3 For some reason, maybe because of legacy, Fdpll/2 is supposed to be the theoretical DPLL output clock, hence the X2 for all the others nodes. In that case CLKOUT = ref_clk * M / (N + 1) CLKOUTX2 = CLKOUT x 2 This is indeed a little bit confusing... We have not been hit by this bug in OMAP2 / OMAP3 as we have always had a X node X2 node for all the post dividers. And for the X2 node we do a *2 of the parent clock rate. This is again not according to spec as X2 nodes are direct derivatives from the dpll clock with just a post divider in between. Where as as per the spec the X nodes have to be /2 from the dpll clock rate in addition to applying the post divider. Even if that does not stick to the spec diagram, the way it is written suggests to do that. Here is what the 3430 TRM is saying: CLKOUT_M2 = CLKOUT/M2 CLKOUT_M2X2 = CLKOUTX2/M2 CLKOUT_M3X2 = CLKOUTX2/M3 CLKOUT_M4X2 = CLKOUTX2/M4 CLKOUT_M5X2 = CLKOUTX2/M5 CLKOUT_M6X2 = CLKOUTX2/M6 But now in OMAP4 clock data base in auto generated. The auto generation does not generate a X node and a X2 node for the post dividers. It just generates one node and it expects it's rate to be dpll clock rate / post divider. But then these nodes now reflect wrong rates as the dpll clock rate itself is /2. Hence all the child clocks start displaying a wrong rate. This issue can be solved in two ways. 1. Add explicit X2 nodes for all the post dividers let them be the parent to rest of the child clocks for OMAP4. Before doing this I would like to understand why the dpll rate calculation is not done according to the spec. This is probably the thing to do for the short term. The spec is using CLKOUT and CLKOUTX2, so this is just following that terminology. Otherwise we will have CLKOUT and CLKOUTDIV2... CLKOUT is considered as the reference output clock everywhere in the 3430 spec, not Fdpll. On the other hand, the OMAP4 TRM is now using Fdpll as a reference:-( 2. Correct the dpll rate calculation as per the spec. But then this change will be intrusive. We will have to modify the OMAP2 and OMAP3 clock data base accordingly. (Lot of X nodes can disappear). Yes, but in that case you will have to add an extra divider by 2 for the clkout output. So the X2 nodes will be replaced by div2 nodes. Both views are correct, this is mainly a matter of spec interpretation. That being said, the second approach is probably the best for the long term. Regards, Benoit -- 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: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki Sent: Tuesday, August 17, 2010 2:48 AM To: Kevin Hilman Cc: linux...@lists.linux-foundation.org; linux-omap@vger.kernel.org; Alan Stern; Ming Lei Subject: Re: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled On Tuesday, August 10, 2010, Kevin Hilman wrote: When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts will likely be disabled when runtime PM for these devices is initiated. Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: pm_runtime_put_sync() Please don't use that from interrupt context. There's pm_runtime_put() exactly for this purpose that puts the _idle() call into a workqueue. Rafael, we execute this little before executing idle instruction with interrupts locked. So, we cannot call pm_runtime_put() as we want it to take effect immediately. Kevin?? __pm_runtime_put() pm_runtime_idle() spin_lock_irq() __pm_runtime_idle() spin_unlock_irq() --- interrupts unconditionally enabled That's because __pm_runtime_idle() has to be called from process context. dev-bus-pm-runtime_idle() spin_lock_irq() spin_unlock_irq() Thanks, Rafael -- 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: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Monday 16 August 2010 12:17:36 Marin Mitov wrote: On Saturday, August 14, 2010 08:33:09 pm Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: What exactly does this mean - happens to fail - you mean starting and stopping mplayer several times? Can you verify, that you're not leaking memory? That you're freeing all allocated DMA memory again? Are you using the same parameters to mplayer, right? As for the work-around - can you not do this in your board late-initcall function? Not sure whether and how one can get this in the mainline. This is in principle the same, as in the above dma_declare_coherent_memory() example, only open-coded without the ioremap. My believe is that dma_declare_coherent_memory() could be used if your frame grabber has local RAM buffer (like video buffer if the graphic adapters) defined by BAR - that is why you need ioremap(). If this RAM turns out to be coherent you use dma_declare_coherent_memory() and any further invocation of dma_alloc_coherent() will allocate from it (till it is exosted). My use of dt3155_alloc_coherent()/dt3155_free_coherent() is to allocate a block of coherent 4MB memory during driver probe() method and use it latter (via videobuff_dma_contig framework)). Maybe we can add a suitable function to the dma-alloc API... Could be of general use, I am thinking about this. This could be done by just renaming dt3155_alloc_coherent()/dt3155_free_coherent() to something acceptable (dma_reserve_coherent_memory()/dma_release_reserved_memory(), I am open for suggestions) and export them. Should be added to drivers/base/dma-coherent.c. Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? I would suggest creating one common function that allocates and fills the dev-dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thu, 19 Aug 2010, Janusz Krzysztofik wrote: Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? I'm about to submit a patch, which you'll be most welcome to test. Just give me a couple more hours. I would suggest creating one common function that allocates and fills the dev-dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [ 6068.70] [c002b094] (dma_alloc_coherent+0x0/0x64) from [bf000a44] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: [ 6068.77] [bf000938] (__videobuf_mmap_mapper+0x0/0x374 [videobuf_dma_contig]) from [c01f9a78] (videobuf_mmap_mapper+0xc4/0x108) [ 6068.81] [c01f99b4] (videobuf_mmap_mapper+0x0/0x108) from [c01fc1ac] (soc_camera_mmap+0x80/0x140) [ 6068.84] r5:c1a3b4e0 r4: [ 6068.87] [c01fc12c] (soc_camera_mmap+0x0/0x140) from [c01eeba8] (v4l2_mmap+0x4c/0x5c) [ 6068.90] r7:c145c000 r6:00ff r5:c16934c0 r4: [ 6068.93] [c01eeb5c] (v4l2_mmap+0x0/0x5c) from [c0085de4] (mmap_region+0x238/0x458) [ 6068.97] [c0085bac] (mmap_region+0x0/0x458) from [c00862c0] (do_mmap_pgoff+0x2bc/0x320) [ 6069.00] [c0086004] (do_mmap_pgoff+0x0/0x320) from [c00863c0] (sys_mmap_pgoff+0x9c/0xc8) [ 6069.04] [c0086324] (sys_mmap_pgoff+0x0/0xc8) from [c0024f00] (ret_fast_syscall+0x0/0x2c) [ 6069.20] Mem-info: [ 6069.22] Normal per-cpu: [ 6069.24] CPU0: hi:0, btch: 1 usd: 0 [ 6069.26] active_anon:676 inactive_anon:682 isolated_anon:0 [ 6069.26] active_file:422 inactive_file:2348 isolated_file:0 [ 6069.26] unevictable:177 dirty:0 writeback:0 unstable:0 [ 6069.26] free:1166 slab_reclaimable:0 slab_unreclaimable:0 [ 6069.26] mapped:1120 shmem:0 pagetables:121 bounce:0 [ 6069.35] Normal free:4664kB min:720kB low:900kB high:1080kB active_anon:2704kB inactive_anon:2728kB active_file:1688kB inactive_file:9392kB unevictable:708kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:4480kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:552kB pagetables:484kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 6069.46] lowmem_reserve[]: 0 0 [ 6069.47] Normal: 6*4kB 20*8kB 14*16kB 29*32kB 26*64kB 9*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4664kB [ 6069.53] 2960 total pagecache pages [ 6069.55] 8192 pages of RAM [ 6069.56] 1322 free pages [ 6069.58] 1114 reserved pages [ 6069.59] 750 slab pages [ 6069.61] 2476 pages shared [ 6069.63] 0 pages swap cached [ 6069.64] omap1-camera omap1-camera.0: dma_alloc_coherent size 204800 failed [ 6069.68] omap1-camera omap1-camera.0: OMAP1 Camera driver detached from camera 0 Maybe I should preallocate a few more pages than will be actually used by the driver? That was it. I was trying to reserve exact frame size, times number of buffers. Apparently, the frame size should be rounded up to the nearest power of 2 first for it to work as expected. No, I don't think you should go to the next power of 2 - that's too crude. Try rounding your buffer size to the page size, that should suffice. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
[RFC PATCH] Board support for the the GPIO keys
Board support for the GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 56 +++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..7f619bf 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
@@ -40,6 +41,10 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO 188
+static int omap_prox_activate(struct device *dev);
+static void omap_prox_deactivate(struct device *dev);
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -76,11 +81,33 @@ static struct gpio_led sdp4430_gpio_leds[] = {
},
};
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+ {
+ .desc = Proximity Sensor,
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+ .active_low = 0,
+ }
+};
static struct gpio_led_platform_data sdp4430_led_data = {
.leds = sdp4430_gpio_leds,
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+ .buttons= sdp4430_gpio_keys,
+ .nbuttons = ARRAY_SIZE(sdp4430_gpio_keys),
+ .enable = omap_prox_activate,
+ .disable= omap_prox_deactivate,
+};
+static struct platform_device sdp4430_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_gpio_keys_data,
+ },
+};
static struct platform_device sdp4430_leds_gpio = {
.name = leds-gpio,
@@ -161,6 +188,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
};
@@ -426,6 +454,33 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+static int omap_prox_activate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ return 0;
+}
+static void omap_prox_deactivate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+static void omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(failed to request GPIO %d, error %d\n,
+ OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,\
+__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+ }
+}
static void __init omap_4430sdp_init(void)
{
int status;
@@ -448,6 +503,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_sfh7741prox_init();
}
static void __init omap_4430sdp_map_io(void)
--
1.7.0.4
--
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/5] OMAP2420: McSPI: Add mcspi hwmod
Hi,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Varadarajan, Charulatha
Sent: Friday, August 13, 2010 7:35 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson,
Benoit; t...@atomide.com; grant.lik...@secretlab.ca;
dbrown...@users.sourceforge.net;
spi-devel-gene...@lists.sourceforge.net; Nayak, Rajendra;
Basak, Partha; Varadarajan, Charulatha; Raja, Govindraj
Subject: [PATCH 1/5] OMAP2420: McSPI: Add mcspi hwmod
This patch updates the omap2420 hwmod data with the
McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 138
1 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..7d1a0ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -33,6 +34,8 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_mcspi1_hwmod;
+static struct omap_hwmod omap2420_mcspi2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -72,6 +75,42 @@ static struct omap_hwmod omap2420_l3_main_hwmod = {
static struct omap_hwmod omap2420_l4_wkup_hwmod;
+/* L4 CORE - MCSPI1 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
Align all of them to one tab..
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcspi1_hwmod,
+ .clk= mcspi1_ick,
+ .addr = omap2420_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - MCSPI2 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
Ditto align to one tab
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcspi2_hwmod,
+ .clk= mcspi2_ick,
+ .addr = omap2420_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.master = omap2420_l4_core_hwmod,
@@ -165,12 +204,111 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* SPI common */
+static struct omap_hwmod_class_sysconfig omap2420_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP |
SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_mcspi_class = {
+ .name = mcspi,
+ .sysc = omap2420_mcspi_sysc,
+};
+
+/* SPI1 */
+static struct omap_hwmod_irq_info omap2420_mcspi1_mpu_irqs[] = {
+ { .irq = INT_24XX_SPI1_IRQ }, /* 65 */
+};
+
+static struct omap_hwmod_dma_info omap2420_mcspi1_sdma_reqs[] = {
+ { .name = rx0, .dma_req = OMAP24XX_DMA_SPI1_RX0 }, /* 35 */
+ { .name = rx1, .dma_req = OMAP24XX_DMA_SPI1_RX1 }, /* 37 */
+ { .name = rx2, .dma_req = OMAP24XX_DMA_SPI1_RX2 }, /* 39 */
+ { .name = rx3, .dma_req = OMAP24XX_DMA_SPI1_RX3 }, /* 41 */
+ { .name = tx0, .dma_req = OMAP24XX_DMA_SPI1_TX0 }, /* 34 */
+ { .name = tx1, .dma_req = OMAP24XX_DMA_SPI1_TX1 }, /* 36 */
+ { .name = tx2, .dma_req = OMAP24XX_DMA_SPI1_TX2 }, /* 38 */
+ { .name = tx3, .dma_req = OMAP24XX_DMA_SPI1_TX3 }, /* 40 */
+};
+
+static struct omap_hwmod_ocp_if *omap2420_mcspi1_slaves[] = {
+ omap2420_l4_core__mcspi1,
+};
+
+static struct omap_hwmod omap2420_mcspi1_hwmod = {
+ .name = mcspi1_hwmod,
+ .mpu_irqs = omap2420_mcspi1_mpu_irqs,
+
RE: [RFC PATCH] Board support for the the GPIO keys
Datta, Shubhrajyoti wrote:
Subject: [RFC PATCH] Board support for the the GPIO keys
Please tag $SUBJECT with something like omap: 4430sdp:
Board support for the GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
...
+static void omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(failed to request GPIO %d, error %d\n,
+ OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,\
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
That trailing '\' is unnecessary.
--
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] usb: ehci: omap: Adding OMAP4 support
The OMAP4 EHCI supports only two ports and hence two TLL channels. Each port is driven by seperate clocks. Following interface mode exists in EHCI controller of OMAP4. - External PHY mode , with 12 pin ULPI - USBTLL mode - HSIC mode The External PHY mode is validated with these patches and other modes are TODOs for later. The TLL clocks are enabled and channels are configuared only when USBTLL mode is choosen. The summary is of patches - 1/7 Add the base address of EHCI controller 2/7 based on omap3 and omap4 ; the processor specific clocks enabled. formats the code of ehci-omap.c so that OMAP4 specific changes can be easily inserted. 3/7 Adding OMAP4 support. 4/7 Introduces the Kconfig macro to include the ehci driver as platform driver 5/7 This is hack to do the mux setting for EHCI pad configuration; This patch will be replaced when the mux framework for omap4 is introduced. 6/7 Adds the EHCI IRQ number and base address resources in ehci initialization. 7/7 The EHCI init fuction invocation from 4430 sdp init. diffstat is below: drivers/usb/host/Kconfig |8 drivers/usb/host/ehci-hcd.c|2 drivers/usb/host/ehci-omap.c | 539 + 3 files changed -- keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH 1/7] usb: ehci-omap: Add the HSUSB base address
Update omap44xx.h with base addresses for USBHOST and USBTLL. This patch will be replaced with the HWMOD(hardware mode) implementation later. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com --- arch/arm/plat-omap/include/plat/omap44xx.h |5 + 1 file changed, 5 insertions(+) Index: kernel-omap4-base/arch/arm/plat-omap/include/plat/omap44xx.h === --- kernel-omap4-base.orig/arch/arm/plat-omap/include/plat/omap44xx.h +++ kernel-omap4-base/arch/arm/plat-omap/include/plat/omap44xx.h @@ -52,5 +52,10 @@ #define OMAP4_MMU1_BASE0x55082000 #define OMAP4_MMU2_BASE0x4A066000 +#define OMAP44XX_USBTLL_BASE (L4_44XX_BASE + 0x62000) +#define OMAP44XX_UHH_CONFIG_BASE (L4_44XX_BASE + 0x64000) +#define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800) +#define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00) + #endif /* __ASM_ARCH_OMAP44XX_H */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH 2/7] usb: ehci-omap: don't execute OMAP3-specific code on non-OMAP3
Formats the code so that omap4 ehci host driver can be inserted
in TODO location later. The function cpu_is_omap44xx is used to determine
the OMAP3 or OAMP4 processor. This function will be later replaced by
hwmode changes.
There are No functional changes in this patch.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c | 295 +--
1 file changed, 150 insertions(+), 145 deletions(-)
Index: linux-2.6/drivers/usb/host/ehci-omap.c
===
--- linux-2.6.orig/drivers/usb/host/ehci-omap.c
+++ linux-2.6/drivers/usb/host/ehci-omap.c
@@ -297,194 +297,184 @@ static int omap_start_ehc(struct ehci_hc
udelay(10);
}
- /* Enable Clocks for USBHOST */
- omap-usbhost_ick = clk_get(omap-dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- goto err_host_ick;
- }
- clk_enable(omap-usbhost_ick);
+ if (cpu_is_omap44xx()) {
+ /* TODO */
+ } else {
+ /* Enable Clocks for USBHOST */
+ omap-usbhost_ick = clk_get(omap-dev, usbhost_ick);
+ if (IS_ERR(omap-usbhost_ick)) {
+ ret = PTR_ERR(omap-usbhost_ick);
+ goto err_host;
+ }
+ clk_enable(omap-usbhost_ick);
- omap-usbhost_hs_fck = clk_get(omap-dev, usbhost_120m_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- goto err_host_hs_fck;
- }
- clk_enable(omap-usbhost_hs_fck);
+ omap-usbhost_hs_fck = clk_get(omap-dev, usbhost_120m_fck);
+ if (IS_ERR(omap-usbhost_hs_fck)) {
+ ret = PTR_ERR(omap-usbhost_hs_fck);
+ goto err_host_hs_fck;
+ }
+ clk_enable(omap-usbhost_hs_fck);
- omap-usbhost_fs_fck = clk_get(omap-dev, usbhost_48m_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- goto err_host_fs_fck;
- }
- clk_enable(omap-usbhost_fs_fck);
+ omap-usbhost_fs_fck = clk_get(omap-dev, usbhost_48m_fck);
+ if (IS_ERR(omap-usbhost_fs_fck)) {
+ ret = PTR_ERR(omap-usbhost_fs_fck);
+ goto err_host_fs_fck;
+ }
+ clk_enable(omap-usbhost_fs_fck);
- /* Configure TLL for 60Mhz clk for ULPI */
- omap-usbtll_fck = clk_get(omap-dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- goto err_tll_fck;
- }
- clk_enable(omap-usbtll_fck);
+ /* Configure TLL for 60Mhz clk for ULPI */
+ omap-usbtll_fck = clk_get(omap-dev, usbtll_fck);
+ if (IS_ERR(omap-usbtll_fck)) {
+ ret = PTR_ERR(omap-usbtll_fck);
+ goto err_tll_fck;
+ }
+ clk_enable(omap-usbtll_fck);
- omap-usbtll_ick = clk_get(omap-dev, usbtll_ick);
- if (IS_ERR(omap-usbtll_ick)) {
- ret = PTR_ERR(omap-usbtll_ick);
- goto err_tll_ick;
- }
- clk_enable(omap-usbtll_ick);
+ omap-usbtll_ick = clk_get(omap-dev, usbtll_ick);
+ if (IS_ERR(omap-usbtll_ick)) {
+ ret = PTR_ERR(omap-usbtll_ick);
+ goto err_tll_ick;
+ }
+ clk_enable(omap-usbtll_ick);
- /* perform TLL soft reset, and wait until reset is complete */
- ehci_omap_writel(omap-tll_base, OMAP_USBTLL_SYSCONFIG,
+ /* perform TLL soft reset, and wait until reset is complete */
+ ehci_omap_writel(omap-tll_base, OMAP_USBTLL_SYSCONFIG,
OMAP_USBTLL_SYSCONFIG_SOFTRESET);
- /* Wait for TLL reset to complete */
- while (!(ehci_omap_readl(omap-tll_base, OMAP_USBTLL_SYSSTATUS)
+ /* Wait for TLL reset to complete */
+ while (!(ehci_omap_readl(omap-tll_base, OMAP_USBTLL_SYSSTATUS)
OMAP_USBTLL_SYSSTATUS_RESETDONE)) {
- cpu_relax();
+ cpu_relax();
- if (time_after(jiffies, timeout)) {
- dev_dbg(omap-dev, operation timed out\n);
- ret = -EINVAL;
- goto err_sys_status;
+ if (time_after(jiffies, timeout)) {
+ dev_dbg(omap-dev, operation timed out\n);
+ ret = -EINVAL;
+ goto err_sys_status;
+ }
}
- }
- dev_dbg(omap-dev, TLL RESET DONE\n);
+
[RFC] [PATCH 3/7] usb: ehci-omap: omap: Add OMAP4 support
Update the ehci-omap driver to add support for OMAP4.
The OMAP4 has two ports compared to 3 on the OMAP3.
Each port has its own functional clock, compared to a single clock
for all ports on OMAP3. The clock can be internally sourced
(TLL mode, HSIC mode), or externally provided (ULPI PHY).
Register bit positions for mode selections
(TLL, HSIC or ULPI PHY) have changed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
drivers/usb/host/ehci-omap.c | 208 ++-
1 file changed, 205 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/usb/host/ehci-omap.c
===
--- linux-2.6.orig/drivers/usb/host/ehci-omap.c
+++ linux-2.6/drivers/usb/host/ehci-omap.c
@@ -127,6 +127,31 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
+/* OMAP4 specific */
+#define OMAP_UHH_SYSCONFIG_IDLEMODE_RESET (~(0xC))
+#define OMAP_UHH_SYSCONFIG_FIDLEMODE_SET (0 2)
+#define OMAP_UHH_SYSCONFIG_NIDLEMODE_SET (1 2)
+#define OMAP_UHH_SYSCONFIG_SIDLEMODE_SET (2 2)
+#define OMAP_UHH_SYSCONFIG_SWIDLMODE_SET (3 2)
+
+#define OMAP_UHH_SYSCONFIG_STDYMODE_RESET (~(3 4))
+#define OMAP_UHH_SYSCONFIG_FSTDYMODE_SET (0 4)
+#define OMAP_UHH_SYSCONFIG_NSTDYMODE_SET (1 4)
+#define OMAP_UHH_SYSCONFIG_SSTDYMODE_SET (2 4)
+#define OMAP_UHH_SYSCONFIG_SWSTDMODE_SET (3 4)
+
+#define OMAP_UHH_HOST_PORTS_RESET (~(0xF 16))
+#define OMAP_UHH_HOST_P1_SET_ULPIPHY (0 16)
+#define OMAP_UHH_HOST_P1_SET_ULPITLL (1 16)
+#define OMAP_UHH_HOST_P1_SET_HSIC (3 16)
+
+#define OMAP_UHH_HOST_P2_SET_ULPIPHY (0 18)
+#define OMAP_UHH_HOST_P2_SET_ULPITLL (1 18)
+#define OMAP_UHH_HOST_P2_SET_HSIC (3 18)
+#define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 0)
+
+#define OMAP4_TLL_CHANNEL_COUNT2
+
/*-*/
static inline void ehci_omap_writel(void __iomem *base, u32 reg, u32 val)
@@ -160,6 +185,10 @@ struct ehci_hcd_omap {
struct clk *usbhost_fs_fck;
struct clk *usbtll_fck;
struct clk *usbtll_ick;
+ struct clk *xclk60mhsp1_ck;
+ struct clk *xclk60mhsp2_ck;
+ struct clk *utmi_p1_fck;
+ struct clk *utmi_p2_fck;
/* FIXME the following two workarounds are
* board specific not silicon-specific so these
@@ -298,7 +327,163 @@ static int omap_start_ehc(struct ehci_hc
}
if (cpu_is_omap44xx()) {
- /* TODO */
+ /* Enable clocks for OMAP4 USBHOST */
+ omap-usbhost_hs_fck = clk_get(omap-dev, usb_host_fck);
+ if (IS_ERR(omap-usbhost_hs_fck)) {
+ ret = PTR_ERR(omap-usbhost_hs_fck);
+ goto err_host;
+ }
+ clk_enable(omap-usbhost_hs_fck);
+
+ omap-usbhost_fs_fck = clk_get(omap-dev, usb_host_fs_fck);
+ if (IS_ERR(omap-usbhost_fs_fck)) {
+ ret = PTR_ERR(omap-usbhost_fs_fck);
+ goto err_44host_fs_fck;
+ }
+ clk_enable(omap-usbhost_fs_fck);
+
+ omap-xclk60mhsp1_ck = clk_get(omap-dev, xclk60mhsp1_ck);
+ if (IS_ERR(omap-xclk60mhsp1_ck)) {
+ ret = PTR_ERR(omap-xclk60mhsp1_ck);
+ goto err_xclk60mhsp1_ck;
+ }
+
+ omap-utmi_p1_fck = clk_get(omap-dev, utmi_p1_gfclk_ck);
+ if (IS_ERR(omap-utmi_p1_fck)) {
+ ret = PTR_ERR(omap-utmi_p1_fck);
+ goto err_xclk60mhsp1_ck;
+ }
+
+ /* Set the clock parent as External clock */
+ ret = clk_set_parent(omap-utmi_p1_fck, omap-xclk60mhsp1_ck);
+ if (ret != 0)
+ goto err_xclk60mhsp1_ck;
+
+ clk_enable(omap-utmi_p1_fck);
+
+ omap-xclk60mhsp2_ck = clk_get(omap-dev, xclk60mhsp2_ck);
+ if (IS_ERR(omap-xclk60mhsp2_ck)) {
+ ret = PTR_ERR(omap-xclk60mhsp2_ck);
+ goto err_xclk60mhsp2_ck;
+ }
+
+ omap-utmi_p2_fck = clk_get(omap-dev, utmi_p2_gfclk_ck);
+ if (IS_ERR(omap-utmi_p2_fck)) {
+ ret = PTR_ERR(omap-utmi_p2_fck);
+ goto err_xclk60mhsp2_ck;
+ }
+
+ /* Set the clock parent as External clock */
+ ret =
[RFC] [PATCH 4/7] omap: usb: ehci: IO mux mode settings for omap4
This patch adds mux-mode settings for EHCI pads on OMAP4.
This is a hack for now,
This code be replaced when the mux framework is introduced for OMAP4.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/usb-ehci.c | 109 +
1 file changed, 109 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/usb-ehci.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-ehci.c
+++ linux-2.6/arch/arm/mach-omap2/usb-ehci.c
@@ -214,6 +214,115 @@ static void setup_ehci_io_mux(const enum
return;
}
+static void setup_4430ehci_io_mux(const enum ehci_hcd_omap_mode *port_mode)
+{
+ /*
+* FIXME: This funtion should use mux framework functions;
+* For now, we are hardcoding this.
+*/
+ switch (port_mode[0]) {
+ case EHCI_HCD_OMAP_MODE_PHY:
+
+ /* HUSB1_PHY CLK , INPUT ENABLED, PULLDOWN */
+ omap_writew(0x010C, 0x4A1000C2);
+
+ /* HUSB1 STP */
+ omap_writew(0x0004, 0x4A1000C4);
+
+ /* HUSB1_DIR */
+ omap_writew(0x010C, 0x4A1000C6);
+
+ /* HUSB1_NXT */
+ omap_writew(0x010C, 0x4A1000C8);
+
+ /* HUSB1_DATA0 */
+ omap_writew(0x010C, 0x4A1000CA);
+
+ /* HUSB1_DATA1 */
+ omap_writew(0x010C, 0x4A1000CC);
+
+ /* HUSB1_DATA2 */
+ omap_writew(0x010C, 0x4A1000CE);
+
+ /* HUSB1_DATA3 */
+ omap_writew(0x010C, 0x4A1000D0);
+
+ /* HUSB1_DATA4 */
+ omap_writew(0x010C, 0x4A1000D2);
+
+ /* HUSB1_DATA5 */
+ omap_writew(0x010C, 0x4A1000D4);
+
+ /* HUSB1_DATA6 */
+ omap_writew(0x010C, 0x4A1000D6);
+
+ /* HUSB1_DATA7 */
+ omap_writew(0x010C, 0x4A1000D8);
+
+ break;
+
+ case EHCI_HCD_OMAP_MODE_TLL:
+ /* TODO */
+
+ break;
+ case EHCI_HCD_OMAP_MODE_UNKNOWN:
+ /* FALLTHROUGH */
+ default:
+ break;
+ }
+
+ switch (port_mode[1]) {
+ case EHCI_HCD_OMAP_MODE_PHY:
+ /* HUSB2_PHY CLK , INPUT PULLDOWN ENABLED */
+ omap_writew(0x010C, 0x4A100160);
+
+ /* HUSB2 STP */
+ omap_writew(0x0002, 0x4A100162);
+
+ /* HUSB2_DIR */
+ omap_writew(0x010A, 0x4A100164);
+
+ /* HUSB2_NXT */
+ omap_writew(0x010A, 0x4A100166);
+
+ /* HUSB2_DATA0 */
+ omap_writew(0x010A, 0x4A100168);
+
+ /* HUSB2_DATA1 */
+ omap_writew(0x010A, 0x4A10016A);
+
+ /* HUSB2_DATA2 */
+ omap_writew(0x010A, 0x4A10016C);
+
+ /* HUSB2_DATA3 */
+ omap_writew(0x010A, 0x4A10016E);
+
+ /* HUSB2_DATA4 */
+ omap_writew(0x010A, 0x4A100170);
+
+ /* HUSB2_DATA5 */
+ omap_writew(0x010A, 0x4A100172);
+
+ /* HUSB2_DATA6 */
+ omap_writew(0x010A, 0x4A100174);
+
+ /* HUSB2_DATA7 */
+ omap_writew(0x010A, 0x4A100176);
+
+ break;
+
+ case EHCI_HCD_OMAP_MODE_TLL:
+ /* TODO */
+
+ break;
+ case EHCI_HCD_OMAP_MODE_UNKNOWN:
+ /* FALLTHROUGH */
+ default:
+ break;
+ }
+ return;
+}
+
void __init usb_ehci_init(const struct ehci_hcd_omap_platform_data *pdata)
{
platform_device_add_data(ehci_device, pdata, sizeof(*pdata));
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH 5/7] omap: usb: ehci: Initialize resources for omap4
Update resources (IRQ number, base addresses) for EHCI on OMAP4.
This patch will be replaced when the driver is converted to
take advantage of hwmod (hardware mode).
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/usb-ehci.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
Index: linux-2.6/arch/arm/mach-omap2/usb-ehci.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-ehci.c
+++ linux-2.6/arch/arm/mach-omap2/usb-ehci.c
@@ -34,22 +34,15 @@
static struct resource ehci_resources[] = {
{
- .start = OMAP34XX_EHCI_BASE,
- .end= OMAP34XX_EHCI_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP34XX_UHH_CONFIG_BASE,
- .end= OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP34XX_USBTLL_BASE,
- .end= OMAP34XX_USBTLL_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* general IRQ */
- .start = INT_34XX_EHCI_IRQ,
.flags = IORESOURCE_IRQ,
}
};
@@ -328,8 +321,25 @@ void __init usb_ehci_init(const struct e
platform_device_add_data(ehci_device, pdata, sizeof(*pdata));
/* Setup Pin IO MUX for EHCI */
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx()) {
+ ehci_resources[0].start = OMAP34XX_EHCI_BASE;
+ ehci_resources[0].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
+ ehci_resources[1].start = OMAP34XX_UHH_CONFIG_BASE;
+ ehci_resources[1].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
+ ehci_resources[2].start = OMAP34XX_USBTLL_BASE;
+ ehci_resources[2].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
+ ehci_resources[3].start = INT_34XX_EHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
+ } else if (cpu_is_omap44xx()) {
+ ehci_resources[0].start = OMAP44XX_HSUSB_EHCI_BASE;
+ ehci_resources[0].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
+ ehci_resources[1].start = OMAP44XX_UHH_CONFIG_BASE;
+ ehci_resources[1].end = OMAP44XX_UHH_CONFIG_BASE + SZ_2K - 1;
+ ehci_resources[2].start = OMAP44XX_USBTLL_BASE;
+ ehci_resources[2].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
+ ehci_resources[3].start = OMAP44XX_IRQ_EHCI;
+ setup_4430ehci_io_mux(pdata-port_mode);
+ }
if (platform_device_register(ehci_device) 0) {
printk(KERN_ERR Unable to register HS-USB (EHCI) device\n);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH 7/7] omap: ehci: enable the ehci port on OMAP4SDP
The OMAP4 SDP has EHCI port1 hooked up to an external SMSC3320
transciever. GPIO 157 is used to power on the transceiver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 20
1 file changed, 20 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -40,6 +40,7 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+#define OMAP4SDP_MDM_PWR_EN_GPIO 157
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -412,6 +413,17 @@ static struct i2c_board_info __initdata
I2C_BOARD_INFO(tmp105, 0x48),
},
};
+
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+ .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 = false,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static int __init omap4_i2c_init(void)
{
/*
@@ -434,6 +446,14 @@ static void __init omap_4430sdp_init(voi
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
+
+ /* Power on the ULPI PHY */
+ if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
+ /* FIXME: Assumes pad is muxed for GPIO mode */
+ gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, USBB1 PHY VMDM_3V3);
+ gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
+ }
+ usb_ehci_init(ehci_pdata);
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
--
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 3/3] OMAP: hwmod: Force a softreset during _setup
-Original Message-
From: Cousson, Benoit
Sent: Wednesday, August 18, 2010 8:31 PM
To: Basak, Partha
Cc: Nayak, Rajendra; Shilimkar, Santosh; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; p...@pwsan.com
Subject: Re: [PATCH 3/3] OMAP: hwmod: Force a softreset during _setup
Hi Partha,
On 8/17/2010 2:46 PM, Basak, Partha wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Thursday, August 05, 2010 3:43 AM
Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index 53b08e3..91ad9c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -856,8 +856,8 @@ static int _reset(struct omap_hwmod *oh)
/* clocks must be on for this operation */
if (oh-_state != _HWMOD_STATE_ENABLED) {
- WARN(1, omap_hwmod: %s: reset can only be entered from
- enabled state\n, oh-name);
+ pr_warning(omap_hwmod: %s: reset can only be entered from
+ enabled state\n, oh-name);
return -EINVAL;
}
@@ -874,8 +874,8 @@ static int _reset(struct omap_hwmod *oh)
MAX_MODULE_RESET_WAIT, c);
if (c == MAX_MODULE_RESET_WAIT)
- WARN(1, omap_hwmod: %s: failed to reset in %d usec\n,
- oh-name, MAX_MODULE_RESET_WAIT);
+ pr_warning(omap_hwmod: %s: failed to reset in %d usec\n,
+ oh-name, MAX_MODULE_RESET_WAIT);
http://focus.ti.com/pdfs/wtbu/SWPU177B_FinalEPDF_12_04_2009.pdf
This is leading to the above warning for DSS on OMAP3430/3630. Referring
to the reference manual (7.5.1 Display Subsystem Reset), successful reset
of DSS would need PRCM.CM_FCLKEN_DSS[2] EN_TV bit set to 1. For DSS, even
though TV clock is an optional clock, this is mandatory for successful DSS
reset. We could ignore this warning, or possibly WA it.
One way could be:
1. In the database, have HWMOD_INIT_NO_RESET flag set so that _setup()
skips reset.
2. After omap device build of DSS is done, lookup the opt-clock and
enable it (using clock framework).
4. Then do DSS reset again calling omap_device_reset().
All IPs that potentially have any special soft-reset sequence will need
customized handling. Should we keep the framework light and handle such
special cases in the drivers? In that case, the framework need not throw
up a warning. Please comment.
If the softreset is not mandatory for an IP like DSS, you just have to
set this HWMOD_INIT_NO_RESET flag.
There is no need to use the softreset for every IP, the PRCM already
resets every IPs each time the power domain is powered on.
softreset is useful if you need to recover from an HW error.
I agree, however without doing soft-reset, we have observed DSI malfunction.
Senthil can provide more details. As DSS needs TV_clk for successful reset, I
doubt whether PRCM can reset DSS once we merely turn on the DSS power domain.
So, it really depends on the IP in question. If it is necessary, we will do a
omap_device_reset()in the driver. Correct?
Regards,
Benoit
--
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
[PATCHv2 0/2] add isp1704 power supply driver
From: Heikki Krogerus ext-heikki.kroge...@nokia.com There are a few modifications in isp1704_charger_work() and in isp1704_notifier_call() that I would like you guys to check. Changes since v1: - No more platform_device registering in the driver - in Kconfig, only depending on USB_OTG_UTILS - power_supply_changed() called only when isp-present changed - cleanups Heikki Krogerus (2): power_supply: add isp1704 charger detection driver omap: rx51: add support for USB chargers arch/arm/mach-omap2/board-rx51-peripherals.c |5 + drivers/power/Kconfig|7 + drivers/power/Makefile |1 + drivers/power/isp1704_charger.c | 370 ++ 4 files changed, 383 insertions(+), 0 deletions(-) create mode 100644 drivers/power/isp1704_charger.c -- 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
[PATCHv2 2/2] omap: rx51: add support for USB chargers
From: Heikki Krogerus ext-heikki.kroge...@nokia.com
This enables isp1704 power supply driver on RX51, allowing
USB charger detection with N900.
Signed-off-by: Heikki Krogerus ext-heikki.kroge...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a5eb87..a4b1f8b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -104,6 +104,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
},
};
+static struct platform_device rx51_charger_device = {
+ .name = isp1704_charger,
+};
+
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
#define RX51_GPIO_CAMERA_LENS_COVER110
@@ -909,5 +913,6 @@ void __init rx51_peripherals_init(void)
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
omap2_hsmmc_init(mmc);
+ platform_device_register(rx51_charger_device);
}
--
1.7.0.4
--
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
[PATCHv2 1/2] power_supply: add isp1704 charger detection driver
From: Heikki Krogerus ext-heikki.kroge...@nokia.com
NXP ISP1704 is Battery Charging Specification 1.0 compliant USB
transceiver. This adds a power supply driver for ISP1704 and
ISP1707 USB transceivers.
Signed-off-by: Heikki Krogerus ext-heikki.kroge...@nokia.com
---
drivers/power/Kconfig |7 +
drivers/power/Makefile |1 +
drivers/power/isp1704_charger.c | 370 +++
3 files changed, 378 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/isp1704_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0734356..c2a1b8b 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -166,4 +166,11 @@ config BATTERY_INTEL_MID
Say Y here to enable the battery driver on Intel MID
platforms.
+config CHARGER_ISP1704
+ tristate ISP1704 USB Charger Detection
+ depends on USB_OTG_UTILS
+ help
+ Say Y to enable support for USB Charger Detection with
+ ISP1707/ISP1704 USB transceivers.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 10143aa..c73d381 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_BATTERY_S3C_ADC) += s3c_adc_battery.o
obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
obj-$(CONFIG_BATTERY_JZ4740) += jz4740-battery.o
obj-$(CONFIG_BATTERY_INTEL_MID)+= intel_mid_battery.o
+obj-$(CONFIG_CHARGER_ISP1704) += isp1704_charger.o
diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
new file mode 100644
index 000..a140674
--- /dev/null
+++ b/drivers/power/isp1704_charger.c
@@ -0,0 +1,370 @@
+/*
+ * isp1704_charger.c - ISP1704 USB Charger Detection driver
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/init.h
+#include linux/types.h
+#include linux/device.h
+#include linux/sysfs.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/delay.h
+
+#include linux/usb/otg.h
+#include linux/usb/ulpi.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+
+/* Vendor specific Power Control register */
+#define ISP1704_PWR_CTRL 0x3d
+#define ISP1704_PWR_CTRL_SWCTRL(1 0)
+#define ISP1704_PWR_CTRL_DET_COMP (1 1)
+#define ISP1704_PWR_CTRL_BVALID_RISE (1 2)
+#define ISP1704_PWR_CTRL_BVALID_FALL (1 3)
+#define ISP1704_PWR_CTRL_DP_WKPU_EN(1 4)
+#define ISP1704_PWR_CTRL_VDAT_DET (1 5)
+#define ISP1704_PWR_CTRL_DPVSRC_EN (1 6)
+#define ISP1704_PWR_CTRL_HWDETECT (1 7)
+
+#define NXP_VENDOR_ID 0x04cc
+
+static u16 isp170x_id[] = {
+ 0x1704,
+ 0x1707,
+};
+
+struct isp1704_charger {
+ struct device *dev;
+ struct power_supply psy;
+ struct otg_transceiver *otg;
+ struct notifier_block nb;
+ struct work_struct work;
+
+ charmodel[7];
+ unsignedpresent:1;
+};
+
+/*
+ * ISP1704 detects PS/2 adapters as charger. To make sure the detected charger
+ * is actually a dedicated charger, the following steps need to be taken.
+ */
+static inline int isp1704_charger_verify(struct isp1704_charger *isp)
+{
+ int ret = 0;
+ u8 r;
+
+ /* Reset the transceiver */
+ r = otg_io_read(isp-otg, ULPI_FUNC_CTRL);
+ r |= ULPI_FUNC_CTRL_RESET;
+ otg_io_write(isp-otg, ULPI_FUNC_CTRL, r);
+ usleep_range(1000, 2000);
+
+ /* Set normal mode */
+ r = ~(ULPI_FUNC_CTRL_RESET | ULPI_FUNC_CTRL_OPMODE_MASK);
+ otg_io_write(isp-otg, ULPI_FUNC_CTRL, r);
+
+ /* Clear the DP and DM pull-down bits */
+ r = ULPI_OTG_CTRL_DP_PULLDOWN | ULPI_OTG_CTRL_DM_PULLDOWN;
+ otg_io_write(isp-otg, ULPI_CLR(ULPI_OTG_CTRL), r);
+
+ /* Enable strong pull-up on DP (1.5K) and reset */
+ r = ULPI_FUNC_CTRL_TERMSELECT | ULPI_FUNC_CTRL_RESET;
+ otg_io_write(isp-otg, ULPI_SET(ULPI_FUNC_CTRL), r);
+ usleep_range(1000, 2000);
+
+ /* Read the line state */
+ if (!otg_io_read(isp-otg, ULPI_DEBUG)) {
+ /* Disable strong pull-up on DP (1.5K) */
+
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote: On Thu, 19 Aug 2010, Janusz Krzysztofik wrote: Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? It is ready, I just wait for the invitation. Marin Mitov I'm about to submit a patch, which you'll be most welcome to test. Just give me a couple more hours. I would suggest creating one common function that allocates and fills the dev-dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. No, I don't think you should go to the next power of 2 - that's too crude. Try rounding your buffer size to the page size, that should suffice. Allocated coherent memory is always a power of 2. Thanks. Marin Mitov Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] power_supply: add isp1704 charger detection driver
On Thu, Aug 19, 2010 at 03:09:36PM +0300, Krogerus Heikki (EXT-Teleca/Helsinki) wrote: From: Heikki Krogerus ext-heikki.kroge...@nokia.com NXP ISP1704 is Battery Charging Specification 1.0 compliant USB transceiver. This adds a power supply driver for ISP1704 and ISP1707 USB transceivers. Signed-off-by: Heikki Krogerus ext-heikki.kroge...@nokia.com --- Applied to battery-2.6.git, thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/2] omap: rx51: add support for USB chargers
On Thu, Aug 19, 2010 at 03:09:37PM +0300, Krogerus Heikki (EXT-Teleca/Helsinki)
wrote:
From: Heikki Krogerus ext-heikki.kroge...@nokia.com
This enables isp1704 power supply driver on RX51, allowing
USB charger detection with N900.
Signed-off-by: Heikki Krogerus ext-heikki.kroge...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a5eb87..a4b1f8b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -104,6 +104,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
},
};
+static struct platform_device rx51_charger_device = {
+ .name = isp1704_charger,
+};
+
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
#define RX51_GPIO_CAMERA_LENS_COVER 110
@@ -909,5 +913,6 @@ void __init rx51_peripherals_init(void)
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
omap2_hsmmc_init(mmc);
+ platform_device_register(rx51_charger_device);
Maybe
platform_device_register_simple(isp1704_charger, -1, NULL, 0);
?
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/2] omap: rx51: add support for USB chargers
On Thu, Aug 19, 2010 at 02:40:42PM +0200, ext Anton Vorontsov wrote: On Thu, Aug 19, 2010 at 03:09:37PM +0300, Krogerus Heikki (EXT-Teleca/Helsinki) wrote: @@ -909,5 +913,6 @@ void __init rx51_peripherals_init(void) spi_register_board_info(rx51_peripherals_spi_board_info, ARRAY_SIZE(rx51_peripherals_spi_board_info)); omap2_hsmmc_init(mmc); +platform_device_register(rx51_charger_device); Maybe platform_device_register_simple(isp1704_charger, -1, NULL, 0); I guess it's enough in this case. Ameya, Roger, any objections? -- heikki -- 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/5] OMAP2420: McSPI: Add mcspi hwmod
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Varadarajan, Charulatha
Sent: Friday, August 13, 2010 7:35 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson,
Benoit; t...@atomide.com; grant.lik...@secretlab.ca;
dbrown...@users.sourceforge.net;
spi-devel-gene...@lists.sourceforge.net; Nayak, Rajendra;
Basak, Partha; Varadarajan, Charulatha; Raja, Govindraj
Subject: [PATCH 1/5] OMAP2420: McSPI: Add mcspi hwmod
This patch updates the omap2420 hwmod data with the
McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 138
1 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..7d1a0ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -33,6 +34,8 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_mcspi1_hwmod;
+static struct omap_hwmod omap2420_mcspi2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -72,6 +75,42 @@ static struct omap_hwmod omap2420_l3_main_hwmod = {
static struct omap_hwmod omap2420_l4_wkup_hwmod;
+/* L4 CORE - MCSPI1 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
+{
+.pa_start = 0x48098000,
+.pa_end = 0x480980ff,
+.flags = ADDR_TYPE_RT,
+},
+};
Align all of them to one tab..
If you apply the patch, you would see them aligned to one tab.
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
+.master = omap2420_l4_core_hwmod,
+.slave = omap2420_mcspi1_hwmod,
+.clk= mcspi1_ick,
+.addr = omap2420_mcspi1_addr_space,
+.addr_cnt = ARRAY_SIZE(omap2420_mcspi1_addr_space),
+.user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - MCSPI2 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi2_addr_space[] = {
+{
+.pa_start = 0x4809a000,
+.pa_end = 0x4809a0ff,
+.flags = ADDR_TYPE_RT,
+},
+};
+
Ditto align to one tab
Ditto :)
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
+.master = omap2420_l4_core_hwmod,
.
.
[snip]
.
.
--
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 3/3] OMAP: hwmod: Force a softreset during _setup
On 8/19/2010 1:57 PM, Basak, Partha wrote:
-Original Message-
From: Cousson, Benoit
Sent: Wednesday, August 18, 2010 8:31 PM
To: Basak, Partha
Cc: Nayak, Rajendra; Shilimkar, Santosh; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; p...@pwsan.com
Subject: Re: [PATCH 3/3] OMAP: hwmod: Force a softreset during _setup
Hi Partha,
On 8/17/2010 2:46 PM, Basak, Partha wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Thursday, August 05, 2010 3:43 AM
Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index 53b08e3..91ad9c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -856,8 +856,8 @@ static int _reset(struct omap_hwmod *oh)
/* clocks must be on for this operation */
if (oh-_state != _HWMOD_STATE_ENABLED) {
- WARN(1, omap_hwmod: %s: reset can only be entered from
-enabled state\n, oh-name);
+ pr_warning(omap_hwmod: %s: reset can only be entered from
+ enabled state\n, oh-name);
return -EINVAL;
}
@@ -874,8 +874,8 @@ static int _reset(struct omap_hwmod *oh)
MAX_MODULE_RESET_WAIT, c);
if (c == MAX_MODULE_RESET_WAIT)
- WARN(1, omap_hwmod: %s: failed to reset in %d usec\n,
-oh-name, MAX_MODULE_RESET_WAIT);
+ pr_warning(omap_hwmod: %s: failed to reset in %d usec\n,
+ oh-name, MAX_MODULE_RESET_WAIT);
http://focus.ti.com/pdfs/wtbu/SWPU177B_FinalEPDF_12_04_2009.pdf
This is leading to the above warning for DSS on OMAP3430/3630. Referring
to the reference manual (7.5.1 Display Subsystem Reset), successful reset
of DSS would need PRCM.CM_FCLKEN_DSS[2] EN_TV bit set to 1. For DSS, even
though TV clock is an optional clock, this is mandatory for successful DSS
reset. We could ignore this warning, or possibly WA it.
One way could be:
1. In the database, have HWMOD_INIT_NO_RESET flag set so that _setup()
skips reset.
2. After omap device build of DSS is done, lookup the opt-clock and
enable it (using clock framework).
4. Then do DSS reset again calling omap_device_reset().
All IPs that potentially have any special soft-reset sequence will need
customized handling. Should we keep the framework light and handle such
special cases in the drivers? In that case, the framework need not throw
up a warning. Please comment.
If the softreset is not mandatory for an IP like DSS, you just have to
set this HWMOD_INIT_NO_RESET flag.
There is no need to use the softreset for every IP, the PRCM already
resets every IPs each time the power domain is powered on.
softreset is useful if you need to recover from an HW error.
I agree, however without doing soft-reset, we have observed DSI malfunction.
Senthil can provide more details. As DSS needs TV_clk for successful reset, I
doubt whether PRCM can reset DSS once we merely turn on the DSS power domain.
After a check with Jean, The DSS will propagate the reset to sub-IPs and
only the one that are properly clocked will complete the reset. So the
DSS reset status cannot transition until all sub-IPs have completed the
reset. The issue should not exist on OMAP4 because the sys_clk is
available for all DSS sub-IPs.
So, it really depends on the IP in question. If it is necessary, we will do a
omap_device_reset()in the driver. Correct?
We should avoid that. We can either allow a custom hooks to allow IPs
with specifics reset / sysconfig management to change the default
behavior. Or we can find a generic way to handle all these specifics cases.
I know that Paul have some ideas on that.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/2] omap: rx51: add support for USB chargers
On 08/19/2010 04:09 PM, Krogerus Heikki (EXT-Teleca/Helsinki) wrote: On Thu, Aug 19, 2010 at 02:40:42PM +0200, ext Anton Vorontsov wrote: On Thu, Aug 19, 2010 at 03:09:37PM +0300, Krogerus Heikki (EXT-Teleca/Helsinki) wrote: @@ -909,5 +913,6 @@ void __init rx51_peripherals_init(void) spi_register_board_info(rx51_peripherals_spi_board_info, ARRAY_SIZE(rx51_peripherals_spi_board_info)); omap2_hsmmc_init(mmc); + platform_device_register(rx51_charger_device); Maybe platform_device_register_simple(isp1704_charger, -1, NULL, 0); I guess it's enough in this case. Ameya, Roger, any objections? I'm fine with the current approach. No need to re-spin. -- regards, -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: [PATCHv2] mailbox: change full flag per mailbox queue instead of global
Hi Ohad,
This patch already contains the missed changes due to previous rebases.
Thanks.
Regards,
Rene
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando
Sent: Tuesday, August 10, 2010 8:13 PM
To: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; o...@wizery.com; Guzman Lugo, Fernando
Subject: [PATCHv2] mailbox: change full flag per mailbox queue instead of
global
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c | 10 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-
omap/include/plat/mailbox.h
index 9976565..261f6b8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ boolfull;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..c59c9c3 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -145,7 +144,12 @@ static void mbox_rx_work(struct work_struct *work)
while (kfifo_len(mq-fifo) = sizeof(msg)) {
len = kfifo_out(mq-fifo, (unsigned char *)msg,
sizeof(msg));
WARN_ON(len != sizeof(msg));
-
+ spin_lock_irq(mq-lock);
+ if (mq-full) {
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ mq-full = false;
+ }
+ spin_unlock_irq(mq-lock);
if (mq-callback)
mq-callback((void *)msg);
}
@@ -170,7 +174,7 @@ static void __mbox_rx_interrupt(struct omap_mbox
*mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
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
--
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/6] SoC Camera: add driver for OMAP1 camera interface
Thursday 19 August 2010 14:16:21 Marin Mitov napisał(a):
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote:
No, I don't think you should go to the next power of 2 - that's too
crude. Try rounding your buffer size to the page size, that should
suffice.
Guennadi,
If you have a look at how a device reserved memory is next allocated to a
driver with drivers/base/dma-coherent.c::dma_alloc_from_coherent(), then than
you may find my conclusion on a power of 2 as true:
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
...
int order = get_order(size);
...
pageno = bitmap_find_free_region(mem-bitmap, mem-size, order);
...
}
Allocated coherent memory is always a power of 2.
Marin,
For ARM, this seems true as long as allocated with the above from a device
assigned pool, but not true for a (pre)allocation from a generic system RAM.
See arch/arm/mm/dma-mapping.c::__dma_alloc_buffer(), where it looks like extra
pages are freed:
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
unsigned long order = get_order(size);
...
page = alloc_pages(gfp, order);
...
split_page(page, order);
for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
__free_page(p);
...
}
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] : omap-udc stressed full duplex usb communication.
Hi, On Thu, Aug 19, 2010 at 11:30:35AM +0200, ext Marc Chalain wrote: OMAP1710 revision 8 handled as 16xx id: 8b5f702f03330200 wow, 1710. That brings me back to good old times with the 1710 H3 board. I send you my patch. I hope that it will be usefull. please read Documentation/CodingStyle and Documentation/SubmittingPatches and resend following those rules ? This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message. and you should remove these kind of footers when communicating with a mailing list. It would prevent archiving the list. -- balbi DefectiveByDesign.org -- 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/6] SoC Camera: add driver for OMAP1 camera interface
On Thursday, August 19, 2010 08:09:27 pm Janusz Krzysztofik wrote:
Thursday 19 August 2010 14:16:21 Marin Mitov napisał(a):
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote:
No, I don't think you should go to the next power of 2 - that's too
crude. Try rounding your buffer size to the page size, that should
suffice.
Guennadi,
If you have a look at how a device reserved memory is next allocated to a
driver with drivers/base/dma-coherent.c::dma_alloc_from_coherent(), then than
you may find my conclusion on a power of 2 as true:
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
...
int order = get_order(size);
...
pageno = bitmap_find_free_region(mem-bitmap, mem-size, order);
...
}
Allocated coherent memory is always a power of 2.
Marin,
For ARM, this seems true as long as allocated with the above from a device
assigned pool, but not true for a (pre)allocation from a generic system RAM.
See arch/arm/mm/dma-mapping.c::__dma_alloc_buffer(), where it looks like
extra
pages are freed:
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
unsigned long order = get_order(size);
...
page = alloc_pages(gfp, order);
...
split_page(page, order);
for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
__free_page(p);
...
}
Thanks for the clarification.
Marin Mitov
Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP3: PM: ensure IO wakeups are properly disabled
Sergei Shtylyov sshtyl...@mvista.com writes: Hello. Tony Lindgren wrote: From: Kevin Hilman khil...@ti.com Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes) mistakenly removed the check for PER when disabling the IO chain. During idle, if the PER powerdomain transitions and CORE does not (as Does not what? How about .. and CORE does not transition? Transition to what then? Sentense till won't parse right... Kevin, care to clarify that? Yeah, looks like a considerable partt of that sentense got omitted... No. Nothing was omitted. It's like saying Tony drinks Fernet and Kevin does not. Adding an additional drinks Fernet at the end is redundant. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE
On Sun, Aug 8, 2010 at 3:18 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Davinci SRAM is mapped as MT_DEVICE becasue of the section
mapping pre-requisite instead of intended MT_MEMORY_NONCACHED
Since the section mapping limitation gets fixed with first
patch in this series, the MT_MEMORY_NONCACHED can be used now.
Have not tested this, so somebody with Davinci hardware can
try this out
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm355.c | 3 +--
arch/arm/mach-davinci/dm365.c | 3 +--
arch/arm/mach-davinci/dm644x.c | 3 +--
arch/arm/mach-davinci/dm646x.c | 3 +--
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 3834781..e7bd2ad 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -767,8 +767,7 @@ static struct map_desc dm355_io_desc[] = {
.virtual = SRAM_VIRT,
.pfn = __phys_to_pfn(0x0001),
.length = SZ_32K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..5dee032 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -967,8 +967,7 @@ static struct map_desc dm365_io_desc[] = {
.virtual = SRAM_VIRT,
.pfn = __phys_to_pfn(0x0001),
.length = SZ_32K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 7ad1520..5112d51 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -651,8 +651,7 @@ static struct map_desc dm644x_io_desc[] = {
.virtual = SRAM_VIRT,
.pfn = __phys_to_pfn(0x8000),
.length = SZ_16K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 9404565..97078f4 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -735,8 +735,7 @@ static struct map_desc dm646x_io_desc[] = {
.virtual = SRAM_VIRT,
.pfn = __phys_to_pfn(0x0001),
.length = SZ_32K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
--
1.6.0.4
--
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 3/6] OMAP3: PM: ensure IO wakeups are properly disabled
Hello. Kevin Hilman wrote: From: Kevin Hilman khil...@ti.com Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes) mistakenly removed the check for PER when disabling the IO chain. During idle, if the PER powerdomain transitions and CORE does not (as Does not what? How about .. and CORE does not transition? Transition to what then? Sentense till won't parse right... Kevin, care to clarify that? Yeah, looks like a considerable partt of that sentense got omitted... No. Nothing was omitted. It's like saying Tony drinks Fernet and Kevin does not. Adding an additional drinks Fernet at the end is redundant. Sorry, the sentence still doesn't parse for me. You don't say Fernet there BTW, so it's not clear where the PER powerdomain transitions to. What goes after the closing parenthesis doesn't clear things up either, it just describes what happens if... Kevin 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: DSS2 patch series
Hi Benoit, Thanks for the comments, ill study how we can leverage the hwmod fw for DSS features. Archit -Original Message- From: Cousson, Benoit Sent: Tuesday, August 17, 2010 5:03 PM To: Taneja, Archit Cc: Tomi Valkeinen; Semwal, Sumit; linux-omap@vger.kernel.org; Paul Walmsley; Kevin Hilman Subject: Re: DSS2 patch series Hi Archit, On 8/17/2010 1:16 PM, Taneja, Archit wrote: Hi, Ok. Well, good that it's clear now =). How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). I talked to some more folks about this. To summarize: - The revision registers aren't reliable enough, it's better to use the combination of cpu_is_ and and omap_rev macros. These should be enough for making an DSS specific feature list. -The feature framework(HWMOD) can help out with the following things - The internal IP blocks within DSS. - The PRCM clocks and IRQs coming to DSS, and PM stuff which I don't know much about. - Effectively, the information on how the outside world communicates with DSS. -DSS features like number of vid pipelines, supported color modes,internal clocks and PLL info, bit fields needs to be managed by us. You can use hwmod to store that as well. Other IPs might require features management, so instead of doing a DSS dedicated solution, you can directly leverage the existing fmwk and extend it to manage your features. One good input was that we can manage internal DSS clocks using the exisiting clock framework and custom clock modes. I don't know much about it. Others in the list can probably help out with this :) The present way of handling DSS2 clocks is good, but we need to see if it can be scalable when more OMAPs come in. Good? It works, but this is still redoing what the clocks framework can already do. The good approach will be to encode your clocks nodes using the clock framework, as you've just said. The dss_features.c idea sounds good, we will still have these new bunch of functions scattered around in the code. But it will be much than an if else chain of omap checks. So should we stick with this idea? Using directly the hwmod struct sound a much better idea for my point of view. Regards, Benoit -- 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: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled
Alan Stern st...@rowland.harvard.edu writes: On Tue, 10 Aug 2010, Kevin Hilman wrote: When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts will likely be disabled when runtime PM for these devices is initiated. Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: ... Unconditionally enabling interrupts late in the idle sequence is not desired behavior. To fix, use the save/restore versions of the spinlock API. Reported-by: Partha Basak p-bas...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- RFC: I'm not crazy about having the 'flags' in struct dev_pm_info, but since the locks are taken and released in separate functions, this seems better than changing the function APIs to pass around the flags. There are restrictions on what you're allowed to do with the flags, but I don't remember exactly what they are. In any case, I don't really like this change. It seems that we would be better off preventing the runtime PM calls from occurring in the first place while interrupts are disabled. Why? In fact, it's hard to see what could cause this to happen at all. As I mentioned in the changelog, this happens when trying to use runtime PM in combination with CPUidle. As has been suggested elsewhere[1], there is a need to do runtime PM on some devices in combination with CPU idle transitions managed by CPUidle. However, late in the idle path, at the time we want to manage these IO devices, interrupts are disabled. Currently, on OMAP, we are already managing the power state of certain IO devices along with CPUidle transitions using more brute force methods. IMO, using runtime PM for this would be a much cleaner approach. The only obstacle is the assumption that the API must be called with interrupts enabled. Kevin [1] http://www.linuxplumbersconf.org/2010/ocw/proposals/717 -- 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: DSS2 patch series
Hi, -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Tuesday, August 17, 2010 5:10 PM To: Taneja, Archit Cc: Semwal, Sumit; linux-omap@vger.kernel.org Subject: RE: DSS2 patch series On Tue, 2010-08-17 at 13:16 +0200, ext Taneja, Archit wrote: Hi, Ok. Well, good that it's clear now =). How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). I talked to some more folks about this. To summarize: - The revision registers aren't reliable enough, it's better to use the combination of cpu_is_ and and omap_rev macros. These should be enough for making an DSS specific feature list. -The feature framework(HWMOD) can help out with the following things - The internal IP blocks within DSS. - The PRCM clocks and IRQs coming to DSS, and PM stuff which I don't know much about. - Effectively, the information on how the outside world communicates with DSS. -DSS features like number of vid pipelines, supported color modes,internal clocks and PLL info, bit fields needs to be managed by us. One good input was that we can manage internal DSS clocks using the exisiting clock framework and custom clock modes. I don't know much about it. Others in the list can probably help out with this :) The present way of handling DSS2 clocks is good, but we need to see if it can be scalable when more OMAPs come in. The dss_features.c idea sounds good, we will still have these new bunch of functions scattered around in the code. But it will be much than an if else chain of omap checks. So should we stick with this idea? Yes, and even if the dss_features.c isn't what is needed in the end, it'll still be easier to convert to whatever way we want in the future. But this is also not a very high priority thing. So I don't see a need to start converting everything to use dss_features.c right away. We can start by converting the places where OMAP4 changes require feature checks. Tomi Okay, I'll come up with a way to implement the dss_features.c idea, I'll also try to learn how we can use hwmod for dss specific features. Archit-- 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: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled
Rafael J. Wysocki r...@sisk.pl writes: On Tuesday, August 10, 2010, Kevin Hilman wrote: When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts will likely be disabled when runtime PM for these devices is initiated. Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: pm_runtime_put_sync() Please don't use that from interrupt context. I'm not using this in interrupt context. I'm using it in process context where interrupts are disabled, specifically, the idle thread. There's pm_runtime_put() exactly for this purpose that puts the _idle() call into a workqueue. If I'm in my CPU's idle path, I don't want to activate a workqueue because then I'll no longer be idle. 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: NAND ECC in linux-omap
Cliff Brake cliff.br...@gmail.com writes: On Wed, Aug 18, 2010 at 12:14 AM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] 1. Can you send the git tree link and branch you are referring? git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm 95e42b92313f229cbc9fc81bf68fe60aaee515aa I'm pretty sure this branch tracks linux-omap. Yes, it does. I have not tested linux-omap yet (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git:master) the PM branch has nothing NAND/MTD related in it, so the problem should be the same on linux-omap, but should be tested there as well to eliminate any possible PM interactions. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
Grant Likely grant.lik...@secretlab.ca writes: On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com wrote: This patch series implements McSPI Module in HWMOD FW way and use the runtime PM layer. Hi Charulatha, I'll go through and review the patches, but I'm unfamiliar with HWMOD. Is there a description of HWMOD that you can point me at? Hi Grant, If you want to skip my rambling, the source for omap_hwmod is in mainline: arch/arm/mach-omap2/omap_hwmod.c arch/arm/plat-omap/include/plat/omap_hwmod.h omap_hwmod is short for OMAP hardware module. It is essentially a central way of describing each IP block in an OMAP SoC, and the way they are connected together to make an SoC. An omap_hwmod for a given IP block contains base address, IRQs, DMA channels etc. (as would a device tree node) but also includes information on any master/slave interfaces to model how IP blocks are connected on the SoC and many other details. With my PM hat on, the most important part of an omap_hwmod is that it also defines lots of details about the PM register and capabilities of a given IP block. Part of omap_hwmod is the data (which is now auto-generated for current and future OMAPs), and the other part is the code. In the code, the omap_hwmod layer also provides an API so that functionality common to all IP blocks (clock management, power states, idle modes, resets, etc.) can be handled in a common way. Drivers do not interact directly with omap_hwmod and it is considered OMAP core code. In other threads, you've seen a little bit of the omap_device layer. The omap_device layer encapsulates the omap_hwmod layer. An omap_device consists of at least one (but possibly several) omap_hwmods. Drivers do not interact directly with omap_device either, but instead use runtime PM to trigger the custom bus code which would call omap_device_* which in turn would call into omap_hwmod_*. Also, from the omap_hwmod data, platform_devices are generated (including resources) so drivers get the common data in standard ways. So, with that background, we're going through some major work in several OMAP drivers to convert them to work across multiple OMAP SoCs (OMAP2, 3 and 4.) To make the drivers more general, this means adding the hwmod data for the device IP, building the omap_device for the device and converting the driver to use runtime PM instead of direct clock management. You see all these changes happening in a single patch because the are quite dependent on one another. This driver seems to have needed pretty significant cleanup as well, so I agree that this last patch should be broken up into parts. I think it could be broken up into at least two parts: cleanup/restructure work to handle more data coming via platform_data, followed by the conversion to runtime PM. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] ARM: OMAP: Beagle: revision detection
On Thu, Aug 19, 2010 at 1:53 AM, Jarkko Nikula jhnik...@gmail.com wrote: On Wed, 18 Aug 2010 10:56:51 -0500 Robert Nelson robertcnel...@gmail.com wrote: + ret = gpio_request(171, rev_id_0); + if (ret 0) + goto fail0; + + ret = gpio_request(172, rev_id_1); + if (ret 0) + goto fail1; + + ret = gpio_request(173, rev_id_2); + if (ret 0) + goto fail2; ... +fail2: + gpio_free(173); +fail1: + gpio_free(172); +fail0: + gpio_free(171); This must be: +fail2: + gpio_free(172); +fail1: + gpio_free(171); +fail0: Otherwise the set looks good to me. -- Jarkko Thanks Jarkko, Yeah that one is obvious, will resubmit.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/3] ARM: OMAP: Beagle: revision detection
Due to the omap3530 ES3.0 Silicon being used on both the
B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
routines to differentiate the Beagle Boards.
However gpio pins 171,172,173 where setup for this prupose, so
lets use them.
Changes:
for older U-Boot's, use omap_mux_init_gpio()
keep Beagle Rev in board-omap3beagle.c
gpio_free on gpio request failure
Tested on Beagle Revisions: B5, C2, C4, and xMA
Signed-off-by: Robert Nelson robertcnel...@gmail.com
Cc: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 88 +++
1 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 87969c7..1aebb3f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -50,6 +50,93 @@
#define NAND_BLOCK_SIZESZ_128K
+/*
+ * OMAP3 Beagle revision
+ * Run time detection of Beagle revision is done by reading GPIO.
+ * GPIO ID -
+ * AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
+ * C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
+ * C4 = GPIO173, GPIO172, GPIO171: 1 0 1
+ * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ */
+enum {
+ OMAP3BEAGLE_BOARD_UNKN = 0,
+ OMAP3BEAGLE_BOARD_AXBX,
+ OMAP3BEAGLE_BOARD_C1_3,
+ OMAP3BEAGLE_BOARD_C4,
+ OMAP3BEAGLE_BOARD_XM,
+};
+
+static u8 omap3_beagle_version;
+
+static u8 omap3_beagle_get_rev(void)
+{
+ return omap3_beagle_version;
+}
+
+static void __init omap3_beagle_init_rev(void)
+{
+ int ret;
+ u16 beagle_rev = 0;
+
+ omap_mux_init_gpio(171, OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_gpio(172, OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_gpio(173, OMAP_PIN_INPUT_PULLUP);
+
+ ret = gpio_request(171, rev_id_0);
+ if (ret 0)
+ goto fail0;
+
+ ret = gpio_request(172, rev_id_1);
+ if (ret 0)
+ goto fail1;
+
+ ret = gpio_request(173, rev_id_2);
+ if (ret 0)
+ goto fail2;
+
+ gpio_direction_input(171);
+ gpio_direction_input(172);
+ gpio_direction_input(173);
+
+ beagle_rev = gpio_get_value(171) | (gpio_get_value(172) 1)
+ | (gpio_get_value(173) 2);
+
+ switch (beagle_rev) {
+ case 7:
+ printk(KERN_INFO OMAP3 Beagle Rev: Ax/Bx\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_AXBX;
+ break;
+ case 6:
+ printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_C1_3;
+ break;
+ case 5:
+ printk(KERN_INFO OMAP3 Beagle Rev: C4\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
+ break;
+ case 0:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
+ break;
+ default:
+ printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n, beagle_rev);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+ }
+
+ return;
+
+fail2:
+ gpio_free(172);
+fail1:
+ gpio_free(171);
+fail0:
+ printk(KERN_ERR Unable to get revision detection GPIO pins\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+
+ return;
+}
+
static struct mtd_partition omap3beagle_nand_partitions[] = {
/* All the partition sizes are listed in terms of NAND block size */
{
@@ -464,6 +551,7 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap3_beagle_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap3_beagle_init_rev();
omap3_beagle_i2c_init();
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
--
1.7.0.4
--
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 v6 2/3] ARM: OMAP: Beagle: only Cx boards use pin 23 for write protect
system_rev comes from u-boot and is a constant 0x20, so
Bx boards also fall in this 'if' and will get setup with the
wrong gpio_wp pin. Switch to using the Beagle revision routine
to correcly set pin 23 only for C1/2/3 and C4 Boards. Bx boards
will then use the correct default pin setting.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 62d69a9..e9af4fd 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -274,7 +274,8 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- if (system_rev = 0x20 system_rev = 0x34301000) {
+ if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
+ (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
} else {
--
1.7.0.4
--
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 v6 3/3] ARM: OMAP: Beagle: no gpio_wp pin connection on xM
The omap3630 based BeagleBoard xM uses a MicroSD card slot with
no write protection.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index e9af4fd..1f455c3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -274,7 +274,9 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ mmc[0].gpio_wp = -EINVAL;
+ } else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
--
1.7.0.4
--
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/7] usb: ehci-omap: omap: Add OMAP4 support
Hi,
On Thu, Aug 19, 2010 at 01:49:33AM +0200, ext Keshava Munegowda wrote:
@@ -298,7 +327,163 @@ static int omap_start_ehc(struct ehci_hc
}
if (cpu_is_omap44xx()) {
- /* TODO */
driver should never make use of cpu_is_omap* calls neither machine_is_*
for that matter. Driver shouldn't care about correct clock names either.
You need to find a better to handle differences between omap3 and omap4.
--
balbi
DefectiveByDesign.org
--
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 5/7] omap: usb: ehci: Initialize resources for omap4
On Thu, Aug 19, 2010 at 01:49:35AM +0200, ext Keshava Munegowda wrote:
@@ -328,8 +321,25 @@ void __init usb_ehci_init(const struct e
platform_device_add_data(ehci_device, pdata, sizeof(*pdata));
/* Setup Pin IO MUX for EHCI */
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx()) {
+ ehci_resources[0].start = OMAP34XX_EHCI_BASE;
+ ehci_resources[0].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
+ ehci_resources[1].start = OMAP34XX_UHH_CONFIG_BASE;
+ ehci_resources[1].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
+ ehci_resources[2].start = OMAP34XX_USBTLL_BASE;
+ ehci_resources[2].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
+ ehci_resources[3].start = INT_34XX_EHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
rename this to setup_3430ehci_io_mux() while at that.
--
balbi
DefectiveByDesign.org
--
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 6/7] usb: ehci: Introduce CONFIG_USB_EHCI_HCD_OMAP3
On Thu, Aug 19, 2010 at 01:49:36AM +0200, ext Keshava Munegowda wrote: @@ -126,6 +126,14 @@ config USB_EHCI_MXC ---help--- Variation of ARC USB block used in some Freescale chips. +config USB_EHCI_HCD_OMAP3 USB_EHCI_HCD_OMAP would be enough as you already have omap3 and omap4 supported. -- balbi DefectiveByDesign.org -- 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 6/7] usb: ehci: Introduce CONFIG_USB_EHCI_HCD_OMAP3
hi again, On Thu, Aug 19, 2010 at 01:49:36AM +0200, ext Keshava Munegowda wrote: @@ -126,6 +126,14 @@ config USB_EHCI_MXC ---help--- Variation of ARC USB block used in some Freescale chips. +config USB_EHCI_HCD_OMAP3 + bool EHCI support for OMAP3 and later chips + depends on USB_EHCI_HCD (ARCH_OMAP3 || ARCH_OMAP4) this line doesn't scale. When we have another omap release this will become e.g. ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5 || ARCH_OMAP6 etc etc, so instead of depending on ARCH_OMAPX, depend only on ARCH_OMAP and make the architecture select the USB_ARCH_HAS_EHCI like this: diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b48bacf..872b30a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -43,6 +43,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select USB_ARCH_HAS_EHCI comment OMAP Core Type depends on ARCH_OMAP2 -- balbi DefectiveByDesign.org -- 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/7] usb: ehci-omap: omap: Add OMAP4 support
Felipe Balbi wrote:
On Thu, Aug 19, 2010 at 01:49:33AM +0200, ext Keshava Munegowda wrote:
@@ -298,7 +327,163 @@ static int omap_start_ehc(struct ehci_hc
}
if (cpu_is_omap44xx()) {
-/* TODO */
driver should never make use of cpu_is_omap* calls neither machine_is_*
for that matter. Driver shouldn't care about correct clock names either.
You need to find a better to handle differences between omap3 and omap4.
The differences between OMAP3 and OMAP4 are:
- The OMAP4 has a different set of clocks which do not exist on OMAP3.
- The register bits for configuring port modes is different
For the clock handling:
One approach: On OMAP3, have a set of dummy clocks corresponding to the
per-port clocks on OMAP4. Then the driver wouldn't need to know which
SoC it is running on.
Another approach:
Have a different glue layer driver for OMAP4.
For the register bit differences, we do need to know which SoC we are
running on to be able to use the correct register bits. For this,
One approach:
At the very minimum, we need a set of clocks to be enabled to be able to
read the UHH_REVISION register, and we could use that to figure out which
bits we need to use.
The other approach I can think of is to have platform data tell us (I'm
guessing this is a bad idea).
What do you think?
- 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: [RFC] [PATCH 3/7] usb: ehci-omap: omap: Add OMAP4 support
Hi, On Fri, Aug 20, 2010 at 07:47:07AM +0200, ext Gadiyar, Anand wrote: The differences between OMAP3 and OMAP4 are: - The OMAP4 has a different set of clocks which do not exist on OMAP3. - The register bits for configuring port modes is different is it a different ip core or just a modification of the previous ? For the clock handling: One approach: On OMAP3, have a set of dummy clocks corresponding to the per-port clocks on OMAP4. Then the driver wouldn't need to know which SoC it is running on. Another approach: Have a different glue layer driver for OMAP4. For the register bit differences, we do need to know which SoC we are running on to be able to use the correct register bits. For this, isn't the ehci ip revision different ? Why don't you use that instead of cpu_is_omap* One approach: At the very minimum, we need a set of clocks to be enabled to be able to read the UHH_REVISION register, and we could use that to figure out which bits we need to use. exactly The other approach I can think of is to have platform data tell us (I'm guessing this is a bad idea). yeah, that would be bad... What do you think? another approach: make ohci and ehci play well together have an omap3-specific and one omap4-specific MFD-like driver that will instantiate ehci and ohci platform_drivers and handle clock + locking to shared address space. then you define a set of accessor functions for registers with different offset that act differently depending on revision of the ip core. Does that work ? -- balbi DefectiveByDesign.org -- 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 6/7] usb: ehci: Introduce CONFIG_USB_EHCI_HCD_OMAP3
Felipe Balbi wrote: On Thu, Aug 19, 2010 at 01:49:36AM +0200, ext Keshava Munegowda wrote: @@ -126,6 +126,14 @@ config USB_EHCI_MXC ---help--- Variation of ARC USB block used in some Freescale chips. +config USB_EHCI_HCD_OMAP3 +bool EHCI support for OMAP3 and later chips +depends on USB_EHCI_HCD (ARCH_OMAP3 || ARCH_OMAP4) this line doesn't scale. When we have another omap release this will become e.g. ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5 || ARCH_OMAP6 etc etc, so instead of depending on ARCH_OMAPX, depend only on ARCH_OMAP and make the architecture select the USB_ARCH_HAS_EHCI like this: ARCH_OMAP includes OMAP1/2, and these chips do not have any EHCI controllers. Is this okay? - 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
