no audio out on beagleboard-xm
Hi-- I'm not able to get any audio out the headphone jack on my beagleboard-xm. I have a Angstrom build that's on kernel 3.2. If instead I use a 2.6.32 build the audio works just fine. If I go through the /proc and /sys trees it looks like everything is as it should be. I also see the output for the twl4030 driver during boot-up. I also ran through the alsamixer app and took everything off mute (maybe overkill?). So, near as I can tell the software is okay (built properly, all modules present and installed, etc.). I suspect there may be a lower-level pin/register setting that is goofed up, but I'm stuck in terms of how to investigate that further. Any pointers on how I might proceed? Thanks! Peter Kurrasch -- 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
twl4030_charger seems to be broken by switch from 'notifier' to 'mailbox'.
Hi, this commit: commit c9721438c009adf8e81d376839ed037c53b9b8d9 Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jun 22 17:40:52 2012 +0530 usb: musb: twl: use mailbox API to send VBUS or ID events The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID events, is replaced by a direct call to omap musb blue. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Seems to have broken twl4030_charger.c. This code relies on the notifier to know when the USB has been plugged in and so it should consider enabling the charger. now that the notification has gone, the charger never turns on. If I put the atomic_notifier_call_chain() calls back in, then the charger is activated as appropriate. What is the plan here? Should the calls go back, or is there some way for twl4030_charger to hook into the mailbox? Or is there some other way it should work? Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Fri, 2012-12-14 at 18:05 +1100, NeilBrown wrote:
On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman khil...@deeprootsystems.com
wrote:
OK thanks, I'll queue this up for v3.6-rc as this should qualify as a
regression.
I don't think this did actually get queued. At least I'm still seeing the
bug in 3.7 and I cannot see a patch in the git history that looks right.
But then I don't remember what we ended up with - it was 3 months ago!!!
This is the last thing I can find in my email history - it still seems to
apply and still seems to work.
NeilBrown
From: NeilBrown ne...@suse.de
Date: Mon, 10 Sep 2012 14:09:06 +1000
Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Current kernel will wake from suspend on an event an any active
GPIO event if enable_irq_wake() wasn't called.
Should it read this way Current kernel will wake from suspend on any
active gpio event if enable_irq_wake() wasn't called ?
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
in which case
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
has been enabled
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4fbc208..79e1340 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,6 +57,7 @@ struct gpio_bank {
u16 irq;
int irq_base;
struct irq_domain *domain;
+ u32 suspend_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -522,11 +523,9 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
spin_lock_irqsave(bank-lock, flags);
if (enable)
- bank-context.wake_en |= gpio_bit;
+ bank-suspend_wakeup |= gpio_bit;
else
- bank-context.wake_en = ~gpio_bit;
-
- __raw_writel(bank-context.wake_en, bank-base + bank-regs-wkup_en);
+ bank-suspend_wakeup = ~gpio_bit;
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1157,6 +1156,49 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM_RUNTIME)
+
+#if defined(CONFIG_PM_SLEEP)
+static int omap_gpio_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned long flags;
+
+ if (!bank-mod_usage ||
+ !bank-regs-wkup_en ||
+ !bank-context.wake_en)
+ return 0;
+
+ spin_lock_irqsave(bank-lock, flags);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ return 0;
+}
+
+static int omap_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned long flags;
+
+ if (!bank-mod_usage ||
+ !bank-regs-wkup_en ||
+ !bank-context.wake_en)
+ return 0;
+
+ spin_lock_irqsave(bank-lock, flags);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
static void omap_gpio_restore_context(struct gpio_bank *bank);
static int omap_gpio_runtime_suspend(struct device *dev)
@@ -1386,11 +1428,14 @@ static void omap_gpio_restore_context(struct
gpio_bank *bank)
}
#endif /* CONFIG_PM_RUNTIME */
#else
+#define omap_gpio_suspend NULL
+#define omap_gpio_resume
Re: twl4030_charger seems to be broken by switch from 'notifier' to 'mailbox'.
Hi, On Fri, Dec 14, 2012 at 08:04:27PM +1100, NeilBrown wrote: this commit: commit c9721438c009adf8e81d376839ed037c53b9b8d9 Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jun 22 17:40:52 2012 +0530 usb: musb: twl: use mailbox API to send VBUS or ID events The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID events, is replaced by a direct call to omap musb blue. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Seems to have broken twl4030_charger.c. This code relies on the notifier to know when the USB has been plugged in and so it should consider enabling the charger. now that the notification has gone, the charger never turns on. If I put the atomic_notifier_call_chain() calls back in, then the charger is activated as appropriate. What is the plan here? Should the calls go back, or is there some way for twl4030_charger to hook into the mailbox? Or is there some other way it should work? hmmm, tricky situation. Maybe we add back the notifer calls but keep the mailbox API ? -- balbi signature.asc Description: Digital signature
MUSB-HDRC Gadget driving VBUS inappropriately
Hi, We're using Linux 3.3 on DM3730 with TPS6595xx PMIC for an embedded product. For a particular board, we have musb-hdrc (RTL 1.4) configured in peripheral mode. We use the Ethernet gadget configured for cdc_eem to use Ethernet emulation over USB for this link, and the robustness of the link is mission-critical. To assure this, we have performed some massive reboot testing to ensure that this usb link reliably comes up. After working through an issue which required pulling in the following patch, - commit b1b552a69b8805e7e338074a9e8b670b4a795218 Author: Michael Grzeschik m.grzesc...@pengutronix.de Date: Wed Aug 8 11:48:10 2012 +0200 usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop - we find that with about a 2% chance, the gadget comes up in some kind of firmware failed state, driving VBUS. In this condition, we found that MUSB_DEVCTL_SESSION bit was set. I understand this to be indicative of MUSB thinking it is in host mode, which agrees with the driven VBUS. Further, in this state, I found that usually, there was one interrupt from twl4030_usb, but NO interrupts from musb-hdrc. So, as a hack, I cleared MUSB_DEVCTL_SESSION in omap2430.c in the notifier block from the VBUS interrupt. This appears to reduce the frequency of the problem -- I now always at least one instance of the musb-hdrc interrupt. However, sometimes, it looks like the MUSB PHY dies shortly thereafter. So, I don't think this hack is fully effective. I reviewed commits that post-date 3.3 in omap2430.c, musb_core.c, twl4030-usb.c, musb_gadget.c, and I couldn't find anything interesting -- it looks like mostly reorganization has taken place. We have also engaged TI to try to get some silicon errata from Mentor Graphics, and maybe a register manual for the MUSB HDRC IP, but this is slow going, and that has little guarantee of paying off anyways. Are there any ideas, or patches that anyone might suggest? Thanks! Ian-- 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: cpts: Fix build error caused by include of plat/clock.h
Op 14 dec. 2012, om 08:13 heeft Richard Cochran richardcoch...@gmail.com het volgende geschreven: On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html That patch didn't get applied, so it's still broken in Linus' tree :( regards, Koen-- 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: MUSB-HDRC Gadget driving VBUS inappropriately
Hi, On Fri, Dec 14, 2012 at 01:53:07AM -0800, Ian Coolidge wrote: Hi, We're using Linux 3.3 on DM3730 with TPS6595xx PMIC for an embedded product. For a particular board, we have musb-hdrc (RTL 1.4) configured in peripheral mode. We use the Ethernet gadget configured for cdc_eem to use Ethernet emulation over USB for this link, and the robustness of the link is mission-critical. To assure this, we have performed some massive reboot testing to ensure that this usb link reliably comes up. After working through an issue which required pulling in the following patch, - commit b1b552a69b8805e7e338074a9e8b670b4a795218 Author: Michael Grzeschik m.grzesc...@pengutronix.de Date: Wed Aug 8 11:48:10 2012 +0200 usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop - we find that with about a 2% chance, the gadget comes up in some kind of firmware failed state, driving VBUS. In this condition, we found that MUSB_DEVCTL_SESSION bit was set. I understand this to be indicative of MUSB thinking it is in host mode, which agrees with the driven VBUS. Further, in this state, I found that usually, there was one interrupt from twl4030_usb, but NO interrupts from musb-hdrc. So, as a hack, I cleared MUSB_DEVCTL_SESSION in omap2430.c in the notifier block from the VBUS interrupt. This appears to reduce the frequency of the problem -- I now always at least one instance of the musb-hdrc interrupt. However, sometimes, it looks like the MUSB PHY dies shortly thereafter. So, I don't think this hack is fully effective. I reviewed commits that post-date 3.3 in omap2430.c, musb_core.c, twl4030-usb.c, musb_gadget.c, and I couldn't find anything interesting -- it looks like mostly reorganization has taken place. We have also engaged TI to try to get some silicon errata from Mentor Graphics, and maybe a register manual for the MUSB HDRC IP, but this is slow going, and that has little guarantee of paying off anyways. Are there any ideas, or patches that anyone might suggest? I don't think it's a silicon errata. Looks like a driver bug to me. But since you're using such an old kernel, your TI support channel is the only way forward, unless you can test with a more recent kernel like v3.7. From what you describe, however, it sounds like it's a problem with some -set_vbus() call. -- balbi signature.asc Description: Digital signature
[GIT PULL] fbdev changes for 3.8
Hi Linus, Florian, the fbdev maintainer, has been very busy lately, so I offered to send the pull request for fbdev for this merge window. There are a few conflicts, but they look clear to me. arch/arm/plat-omap/common.c is to be removed. Tomi The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17: Linux 3.7-rc7 (2012-11-25 17:59:19 -0800) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-for-3.8 for you to fetch changes up to e7f5c9a16ea2648a3e85af8e34191026bf3dcb62: Merge tag 'omapdss-for-3.8' of git://gitorious.org/linux-omap-dss2/linux into for-linus (2012-12-13 14:30:56 +0200) fbdev changes for 3.8: OMAPDSS changes, including: - use dynanic debug prints - OMAP platform dependency removals - Creation of compat-layer, helping us to improve omapdrm - Misc cleanups, aiming to make omadss more in line with the upcoming common display framework Exynos DP changes for the 3.8 merge window: - Device Tree support for Samsung Exynos DP - SW Link training is cleaned up. - HPD interrupt is supported. Samsung Framebuffer changes for the 3.8 merge window: - The bit definitions of header file are updated. - Some minor typos are fixed. - Some minor bugs of s3c_fb_check_var() are fixed. FB related changes for SH Mobile, Freescale DIU Add support for the Solomon SSD1307 OLED Controller Aaro Koskinen (1): OMAPDSS: panel-n8x0: register the DSS driver after SPI probe Ajay Kumar (5): video: exynos_dp: Add device tree support to DP driver video: exynos_dp: device tree documentation video: exynos_dp: Reset and initialize DP before requesting irq video: exynos_dp: Fix incorrect setting for INT_CTL video: exynos_dp: remove redundant parameters Archit Taneja (10): OMAPDSS: Remove acb and acbi fields from omap_dss_device OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline OMAPDSS: DISPC: Don't allow predecimation for writeback OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback OMAPDSS: APPLY: Don't treat an overlay's channel out as shadow bits OMAPDSS: APPLY: Remove unnecessary variable in dss_apply_irq_handler OMAPDSS: APPLY: Remove unnecessary call to mg_clear_shadow_dirty OMAPDSS: Add overlay manager width and height limits as a dispc feature OMAPDSS: Add a dispc_features struct for OMAP5 OMAPDSS: Use only omapdss_dss platform device to get context lost count Axel Lin (1): OMAPDSS: Add terminating entry for picodlp_i2c_id table Chandrabhanu Mahapatra (5): OMAPDSS: Move definition of DEBUG flag to Makefile OMAPDSS: Create new debug config options OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function OMAPDSS: Replace multi part debug prints with pr_debug OMAPDSS: Remove dss_debug variable Chuansheng Liu (2): OMAPDSS: DISPC: Fix the usage of wait_for_completion_timeout OMAPDSS: APPLY: Fix the usage of wait_for_completion_timeout Hideki EIRAKU (1): fbdev: sh_mobile_lcdc: use dma_mmap_coherent Jingoo Han (14): video: s3c-fb: clean the bit definition for WINCON register video: s3c-fb: move the address definitions for VIDTCON registers video: s3c-fb: move the address definition for VIDOSD register video: s3c-fb: move the bit definitions for VIDINTCON0 register video: s3c-fb: move the bit definitions for WINxMAP and WPALCON register video: s3c-fb: move the bit definitions for DITHMODE register video: s3c-fb: add the bit definitions for VIDCON0_VIDOUT_WB video: s3c-fb: fix typo in comment video: s3c-fb: fix help message for FB_S3C_DEBUG_REGWRITE video: s3c-fb: use FIMD_V8_VIDTCON0 for EXYNOS5 FIMD video: s3c-fb: use dev_get_drvdata() instead of platform_get_drvdata() video: s3c-fb: add drop through comment video: s3c-fb: return an error when bpp is invalid video: s3c-fb: fix red offset and length for ARGB232 format Laurent Pinchart (19): fbdev: sh_mobile_lcdc: Get display dimensions from the channel structure fbdev: sh_mobile_lcdc: Rename mode argument to modes fbdev: sh_mobile_lcdc: Remove priv argument from channel and overlay init ARM: mach-shmobile: ag5evm: Add LCDC tx_dev field to platform data fbdev: sh_mipi_dsi: Add channel field to platform data ARM: mach-shmobile: Initiliaze the new sh_mipi_dsi_info channel field fbdev: sh_mipi_dsi: Use the sh_mipi_dsi_info channel field fbdev: sh_mipi_dsi: Use the LCDC entity default mode fbdev: sh_mipi_dsi: Remove last reference to LCDC platform data ARM: mach-shmobile: Remove the unused sh_mipi_dsi_info lcd_chan field fbdev: sh_mipi_dsi: Remove the unused sh_mipi_dsi_info lcd_chan field fbdev: sh_mobile_lcdc:
crypto: omap-aes - fix a build error
[...] CC init/version.o LD init/built-in.o drivers/built-in.o:(.data+0xbc6c): undefined reference to `crypto_ablkcipher_type' drivers/built-in.o:(.data+0xbd4c): undefined reference to `crypto_ablkcipher_type' The omap-aes driver uses crypto_ablkcipher_type symbol without selecting it. Signed-off-by: Alessio Igor Bogani alessio.bog...@elettra.trieste.it --- drivers/crypto/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index f6644f5..b04d78f 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -254,6 +254,7 @@ config CRYPTO_DEV_OMAP_AES tristate Support for OMAP AES hw engine depends on ARCH_OMAP2 || ARCH_OMAP3 select CRYPTO_AES + select CRYPTO_BLKCIPHER help OMAP processors have AES module accelerator. Select this if you want to use the OMAP module for AES algorithms. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/5] ARM: OMAP: gpmc: don't create devices from initcall on DT
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65468f6..d5cbd29 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1214,6 +1214,13 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = gpmc;
+ /*
+* if the board boots up with a populated DT, do not
+* manually add the device from this initcall
+*/
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err(Could not look up %s\n, oh_name);
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/mtd/nand/omap2.c | 4 +++-
include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0002d5e..1d333497c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1332,6 +1332,7 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1557,7 +1558,8 @@ static int omap_nand_probe(struct platform_device *pdev)
goto out_release_mem_region;
}
- mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
+ ppdata.of_node = pdata-of_node;
+ mtd_device_parse_register(info-mtd, NULL, ppdata, pdata-parts,
pdata-nr_parts);
platform_set_drvdata(pdev, info-mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..6bf9ef4 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
-};
+ /* for passing the partitions */
+ struct device_node *of_node;
+};
#endif
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/5] ARM: OMAP: gpmc-nand: drop __init annotation
gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index db969a5..3059f5e 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -89,7 +89,7 @@ static int omap2_nand_gpmc_retime(
return 0;
}
-static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
+static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
if (!cpu_is_omap34xx()) {
@@ -110,8 +110,8 @@ static bool __init gpmc_hwecc_bch_capable(enum omap_ecc
ecc_opt)
return 1;
}
-int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
- struct gpmc_timings *gpmc_t)
+int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
+ struct gpmc_timings *gpmc_t)
{
int err = 0;
struct device *dev = gpmc_nand_device.dev;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/5] OMAP GPMC DT bindings
This is a series of patches to support GPMC peripherals on OMAP boards. Tested on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) Generated from linux-next as of today, resolving one trivial include file rebase conflict. The only supported peripheral for now is NAND, but other types would be easy to add. Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed and Rob Herring: - add reg and ti,hwmod properties to Documentation - use generic of_mtd functions and the property names defined by them, namely nand-bus-width and nand-ecc-mode - reduce the default register space size in the Documentation to 8K, as found in the hwmod code - switch to a DT layout based on ranges and address translation. Although this property is not currently looked at as long as the handling code still uses the runtime calculation methods, we now have these values in the bindings, eventually allowing us to switch the implementation with less pain. Version 3 includes fixes pointed out by Jon Hunter: - better documentation of the 'ranges' property to describe the fact that it's representing the CS lines - GPMC_CS_CONFIGx - GPMC_CONFIGx in comments - drop interrupt-parent from example bindings - add of_node_put() at the end of the child iteration Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more details from Jon Hunter and Avinash, Philip: - Add num-cs and num-waitpins properties, which will eventually be used to get rid of GPMC_CS_NUM - Better description of generic nand DT properties - Dropped patch 3/4 as an equivalent fix was already merged - Added ti,nand-ecc-use-elm property Version 5 with regards to Avinash, Philip and Peter Korsgaard: - Re-add accidentially forgotten Documentation/devicetree/bindings/bus/ti-gpmc.txt - Rename software ecc mode to sw - Initialize gpmc_nand_data-is_elm_used to 'true' rather than 1 - Drop ti,nand-ecc-use-elm binding in favor of a new ecc mode named bch8-am335xrbl-compatible - Add two more patches for section mismatch fixups Version 6: - Dropped bch8-am335xrbl-compatible mode again. As discussed with Avinash, the ELM issue will be solved subsequently in s separate series. - re-added a patch to bail out of automatic GPMC instanciation in case of DT boot. - re-added the of_node addition in mtd_nand_omap2.h in 2/5 Version 7: comments from Jon Hunter, all affecting the documentation: - add num-wait pins properties as they are marked 'required' - make reg sizes consistent - AM335x only has 2 wait-pins Version 8: comments from Grant, thanks to Jon for the summary of all the derivates: - Added specific compatible strings for different derivates of OMAPs - Renamed num-cs to gpmc,num-cs - Renamed num-waitpins to gpmc,num-waitpins Daniel Mack (5): ARM: OMAP: gpmc: don't create devices from initcall on DT mtd: omap-nand: pass device_node in platform data ARM: OMAP: gpmc-nand: drop __init annotation ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND Documentation/devicetree/bindings/bus/ti-gpmc.txt | 84 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc-nand.c| 15 +- arch/arm/mach-omap2/gpmc.c | 182 - drivers/mtd/nand/omap2.c | 4 +- include/linux/platform_data/mtd-nand-omap2.h | 4 +- 6 files changed, 355 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 84 ++
.../devicetree/bindings/mtd/gpmc-nand.txt | 76 +
arch/arm/mach-omap2/gpmc.c | 173 +
3 files changed, 333 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 000..5ddb2e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,84 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to one of the following:
+
+ ti,omap2420-gpmc (omap2420)
+ ti,omap2430-gpmc (omap2430)
+ ti,omap3430-gpmc (omap3430 omap3630)
+ ti,omap4430-gpmc (omap4430 omap4460 omap543x)
+ ti,am3352-gpmc (am335x devices)
+
+ - reg:A resource specifier for the register space
+ (see the example below)
+ - ti,hwmods: Should be set to ti,gpmc until the DT transition is
+ completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells:Must be set to 1 to allow CS address passing
+ - gpmc,num-cs:The maximum number of chip-select lines that
controller
+ can support.
+ - gpmc,num-waitpins: The maximum number of wait pins that controller can
+ support.
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+ cs-number 0 physical address of mapping size
+
+ Currently, calculated values derived from the contents
+ of the per-CS register GPMC_CONFIG7 (as set up by the
+ bootloader) are used for the physical address decoding.
+ As this will change in the future, filling correct
+ values here is a requirement.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk: Minimum clock period for synchronous mode, in
picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on: Assertion time
+ - gpmc,cs-rd-off: Read deassertion time
+ - gpmc,cs-wr-off: Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on:Assertion time
+ - gpmc,adv-rd-off:Read deassertion time
+ - gpmc,adv-wr-off:Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on: Assertion time
+ - gpmc,we-off:Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on: Assertion time
+ - gpmc,oe-off:Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5:
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:Start-cycle to first data valid delay
+ - gpmc,rd-cycle: Total read cycle time
+ - gpmc,wr-cycle: Total write cycle time
+
+The following are only applicable to OMAP3+ and AM335x:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x2000;
+ interrupts = 100;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x1000; /* CS0 @addr 0x800,
size 0x1000 */
+
+ /* child nodes go here */
+ };
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000..9f464f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,76 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of nand.
+
+All timing relevant properties as well
[PATCH v8 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
The am33xx is capable of handling bch error correction modes, so
enable that feature in the driver.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 3059f5e..afc1e8c 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,17 +92,18 @@ static int omap2_nand_gpmc_retime(
static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
- if (!cpu_is_omap34xx()) {
+ if (!cpu_is_omap34xx() !soc_is_am33xx()) {
pr_err(BCH ecc is not supported on this CPU\n);
return 0;
}
/*
-* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1.
-* Other chips may be added if confirmed to work.
+* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
+* and AM33xx derivates. Other chips may be added if confirmed to work.
*/
if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW)
- (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
+ (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))
+ (!soc_is_am33xx())) {
pr_err(BCH 4-bit mode is not supported on this CPU\n);
return 0;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpts: Fix build error caused by include of plat/clock.h
On Fri, Dec 14, 2012 at 10:55:56AM +0100, Koen Kooi wrote: Op 14 dec. 2012, om 08:13 heeft Richard Cochran richardcoch...@gmail.com het volgende geschreven: On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html That patch didn't get applied, so it's still broken in Linus' tree :( In netdev's patchwork, this was marked Not Applicable. Dave, can you possibly take this patch? If not, who should I ask next? Thanks, Richard -- 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: MUSB-HDRC Gadget driving VBUS inappropriately
On Fri, Dec 14, 2012 at 11:53 AM, Ian Coolidge iancooli...@gmail.com wrote: we find that with about a 2% chance, the gadget comes up in some kind of firmware failed state, driving VBUS. In this condition, we found that MUSB_DEVCTL_SESSION bit was set. I understand this to be indicative of MUSB thinking it is in host mode, which agrees with the driven VBUS. Further, in this state, I found that usually, there was one interrupt from twl4030_usb, but NO interrupts from musb-hdrc. I'm also also often seeing this and don't know any workaround except powercycling the board :( This was kind or relieved for me after I changed it to deinit musb on shutdown/reset (3.3 should have that patch merged), however if you randomly reset the board, there is still something like 30-50% chance musb will come up dead, and on proper reset it's still something like 5% chance like you reported. -- Gražvydas -- 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: MUSB-HDRC Gadget driving VBUS inappropriately
Hi, On Fri, Dec 14, 2012 at 02:13:07PM +0200, Grazvydas Ignotas wrote: On Fri, Dec 14, 2012 at 11:53 AM, Ian Coolidge iancooli...@gmail.com wrote: we find that with about a 2% chance, the gadget comes up in some kind of firmware failed state, driving VBUS. In this condition, we found that MUSB_DEVCTL_SESSION bit was set. I understand this to be indicative of MUSB thinking it is in host mode, which agrees with the driven VBUS. Further, in this state, I found that usually, there was one interrupt from twl4030_usb, but NO interrupts from musb-hdrc. I'm also also often seeing this and don't know any workaround except powercycling the board :( This was kind or relieved for me after I changed it to deinit musb on shutdown/reset (3.3 should have that patch merged), however if you randomly reset the board, there is still something like 30-50% chance musb will come up dead, and on proper reset it's still something like 5% chance like you reported. hehe, then you should've reported earlier :-) Anyway, I really think this has something to do with some bogus set_vbus() calls. Likely that looking at probe() path for checks for MUSB_DEVCTL_VBUS will probably show you something which is wrong. Maybe the driver is assuming that if VBUS bitfield is zero, then it kicks host side, or something. Go over that part of the code and you probably will find something. -- balbi signature.asc Description: Digital signature
[patch] OMAPDSS: reading past end of array in dispc_dump_regs()
We added another kind of plane in 66a0f9e4ac OMAPDSS: Use WB fifo for GFX overlay so this array needs a new entry as well. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Static checker work. I don't have a way to test this. diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index fedbd2c..bfe62cc 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -3163,6 +3163,7 @@ static void dispc_dump_regs(struct seq_file *s) [OMAP_DSS_VIDEO1] = VID1, [OMAP_DSS_VIDEO2] = VID2, [OMAP_DSS_VIDEO3] = VID3, + [OMAP_DSS_WB] = WB, }; const char **p_names; -- 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] regulator: core: if voltage scaling fails, restore original voltage values
On Thu, Dec 13, 2012 at 11:47:15AM +0200, Felipe Balbi wrote: On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: Signed-off-by: Paolo Pisati paolo.pis...@canonical.com Tested-by: Robert Nelson robertcnel...@gmail.com please read Documentation/stable_kernel_rules.txt, you'll see this is wrong. you mean that i should have waited for the commit to hit Linus's tree before cc-ing stable? -- bye, p. -- 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] regulator: core: if voltage scaling fails, restore original voltage values
Hi, On Fri, Dec 14, 2012 at 04:39:43PM +0100, Paolo Pisati wrote: On Thu, Dec 13, 2012 at 11:47:15AM +0200, Felipe Balbi wrote: On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: Signed-off-by: Paolo Pisati paolo.pis...@canonical.com Tested-by: Robert Nelson robertcnel...@gmail.com please read Documentation/stable_kernel_rules.txt, you'll see this is wrong. you mean that i should have waited for the commit to hit Linus's tree before cc-ing stable? No no, I mean that before you SoB you should have a: Cc: sta...@vger.kernel.org # v3.x v3.y ... Something like the commit below: commit 041d81f493d90c940ec41f0ec98bc7c4f2fba431 Author: Felipe Balbi ba...@ti.com Date: Thu Oct 4 11:58:00 2012 +0300 usb: dwc3: gadget: fix 'endpoint always busy' bug If a USB transfer has already been started, meaning we have already issued StartTransfer command to that particular endpoint, DWC3_EP_BUSY flag has also already been set. When we try to cancel this transfer which is already in controller's cache, we will not receive XferComplete event and we must clear DWC3_EP_BUSY in order to allow subsequent requests to be properly started. The best place to clear that flag is right after issuing DWC3_DEPCMD_ENDTRANSFER. Cc: sta...@vger.kernel.org # v3.4 v3.5 v3.6 Reported-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/8] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints
Hi Paul, On Tue, Dec 11, 2012 at 1:05 AM, Paul Walmsley p...@pwsan.com wrote: Hi On Tue, 18 Sep 2012, Jean Pihet wrote: When a PM QoS device latency constraint is requested or removed the constraint is stored in the constraints list of the corresponding power domain, then the aggregated constraint value is applied by programming the next functional power state using pwrdm_set_fpwrst. The per-device PM QoS locking requires a spinlock to be used. The reasons is that some drivers need to use the per-device PM QoS functionality from interrupt context or spinlock protected context, as reported by Djamil. An example of such a driver is the OMAP HSI (high-speed synchronous serial interface) driver which needs to control the IP block idle state from the FIFO empty state, from interrupt context. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Djamil Elaidi d-ela...@ti.com This patch has been changed here. Details below, but the major changes Thanks for reworking this! were to fix the locking and to not attempt GFP_ATOMIC allocations. Hopefully the reasons why are clear, but if not, feel free to ask. This is fine. Note about the locking and the allocations: The locking had been changed to spinlocks because of the potential need to call the per-device PM QoS API from interrupt or spinlock protected context. Unfortunately the per-device PM QoS cannot be called from such a context, because (1) it internally uses mutexes and (2) it relies on a blocking notification mechanism. However after discussion with Rafael W at ELCE, the PM QoS framework will be reworked to get rid of the overly complex notification mechanism [1]. The generic power domain framework will be used instead to apply the constraints to the power domains at the time the power domain is set up to transition to a lower power state (e.g. when the last active device of a power domain is set up to idle automatically). The implementation on OMAP needs some thinking. This very patch is ok but the registration mechanism to the PM QoS framework [2] will need to change. [1] http://marc.info/?l=linux-pmm=134856516908683w=2 [2] http://marc.info/?l=linux-omapm=134795836304294w=2 The following patch has only been compile-tested, and a few more minor changes will probably be needed. Reviewed only from my side. More comments here below. - Paul From: Jean Pihet jean.pi...@newoldbits.com Date: Sun, 9 Dec 2012 18:38:12 -0700 Subject: [PATCH] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints When a PM QoS device latency constraint is requested or removed the constraint is stored in the constraints list of the corresponding power domain, then the aggregated constraint value is applied by programming the next functional power state using pwrdm_set_fpwrst. The per-device PM QoS locking requires a spinlock to be used. The reasons is that some drivers need to use the per-device PM QoS functionality from interrupt context or spinlock protected context, as reported by Djamil. An example of such a driver is the OMAP HSI (high-speed synchronous serial interface) driver which needs to control the IP block idle state from the FIFO empty state, from interrupt context. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Has it been tested already? Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Djamil Elaidi d-ela...@ti.com [p...@pwsan.com: updated to apply; renamed *state to *fpwrst and define as u8; use existing powerdomain spinlock; pack the struct powerdomain variables; removed the GFP_ATOMIC allocation; drop expensive operations from the _pwrdm_wakeuplat_update_pwrst() debug; ensure that the entire wakeuplat update process takes place under the spinlock; remove UNSUP_STATE; remove assumption that fpwrsts start at 0; remove unnecessary plist_empty test from update path; standardize 'wakeuplat' naming; add kerneldoc] XXX conform debug to other powerdomain debugging There are a few 'XXX' comments left. --- arch/arm/mach-omap2/powerdomain.c | 208 + arch/arm/mach-omap2/powerdomain.h | 27 - 2 files changed, 233 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 7caceaa..bcba0af 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -21,8 +21,10 @@ #include linux/kernel.h #include linux/types.h #include linux/list.h +#include linux/slab.h #include linux/errno.h #include linux/string.h +#include linux/pm_qos.h #include linux/spinlock.h #include linux/sched.h #include linux/seq_file.h @@ -125,6 +127,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm) for (i = 0; i PWRDM_FPWRSTS_COUNT; i++)
[PATCH REBASE 0/6] i2c: omap: misc changes
Hi, this is just a rebase of the previous series adding support for amount of bytes transferred upon NACK. Well, actually the patches implementing transferred bytes reporting aren't here because we need to discuss how to move forward. This series is just a preparation for that, but it also contains a at least one bugfix. Each and every patch has been tested with pandaboard, it would be nice to get Tested-bys from other folks on other platforms before pushing this for v3.9 (there's more than enough time for that). Note that we're also dropping b_hw flag since that becomes useless since we'll never set STT and STP together anymore. Give it a good round of test, please. Felipe Balbi (6): i2c: omap: no need to access platform_device i2c: omap: also complete() when stat becomes zero i2c: omap: improve 'rev' a little bit i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS i2c: omap: wait for transfer completion before sending STP bit i2c: omap: get rid of b_hw flag drivers/i2c/busses/i2c-omap.c | 184 +- 1 file changed, 93 insertions(+), 91 deletions(-) -- 1.8.1.rc1.5.g7e0651a -- 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 REBASE 3/6] i2c: omap: improve 'rev' a little bit
a later patch will use scheme detection at
another part of the code, but current scheme
detection implementation relies on the fact that
we still hold scheme on the first 16 bits of our
rev variable, which won't be true as soon as
we move away from probe() because we left shift
it by 16 in case of newer IP versions in order
to fit other revision data in the lower 16 bits.
To fix that, we are changing scheme implementation
to assume scheme is always placed on the top 16
bits.
While at that, also move those macro definitions
to the top of the source file, where they should've
been to start with, because a later patch will use
them.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fcecb0b..c93eb17 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -60,6 +60,17 @@
/* timeout for pm runtime autosuspend */
#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+#define OMAP_I2C_SCHEME(rev) ((rev 0xc000) 30)
+
+#define OMAP_I2C_SCHEME_0 0
+#define OMAP_I2C_SCHEME_1 1
+
+#define OMAP_I2C_REV_SCHEME_0_MAJOR(rev) (rev 4)
+#define OMAP_I2C_REV_SCHEME_0_MINOR(rev) (rev 0xf)
+
+#define OMAP_I2C_REV_SCHEME_1_MAJOR(rev) ((rev 0x0700) 7)
+#define OMAP_I2C_REV_SCHEME_1_MINOR(rev) (rev 0x1f)
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -1058,16 +1069,6 @@ static const struct of_device_id omap_i2c_of_match[] = {
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
#endif
-#define OMAP_I2C_SCHEME(rev) ((rev 0xc000) 14)
-
-#define OMAP_I2C_REV_SCHEME_0_MAJOR(rev) (rev 4)
-#define OMAP_I2C_REV_SCHEME_0_MINOR(rev) (rev 0xf)
-
-#define OMAP_I2C_REV_SCHEME_1_MAJOR(rev) ((rev 0x0700) 7)
-#define OMAP_I2C_REV_SCHEME_1_MINOR(rev) (rev 0x1f)
-#define OMAP_I2C_SCHEME_0 0
-#define OMAP_I2C_SCHEME_1 1
-
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1158,7 +1159,7 @@ omap_i2c_probe(struct platform_device *pdev)
* Also since the omap_i2c_read_reg uses reg_map_ip_* a
* raw_readw is done.
*/
- rev = __raw_readw(dev-base + 0x04);
+ rev = __raw_readw(dev-base + 0x04) 16;
scheme = OMAP_I2C_SCHEME(rev);
switch (scheme) {
@@ -1172,8 +1173,7 @@ omap_i2c_probe(struct platform_device *pdev)
/* FALLTHROUGH */
default:
dev-regs = (u8 *)reg_map_ip_v2;
- rev = (rev 16) |
- omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
+ rev |= omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
minor = OMAP_I2C_REV_SCHEME_1_MINOR(rev);
major = OMAP_I2C_REV_SCHEME_1_MAJOR(rev);
dev-rev = rev;
--
1.8.1.rc1.5.g7e0651a
--
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 REBASE 6/6] i2c: omap: get rid of b_hw flag
Now that we never set STP and STT together,
that flag has been rendered useless. Let's
completely drop it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4d90f08..510506d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -215,7 +215,6 @@ struct omap_i2c_dev {
* if set, should be trsh+1
*/
u32 rev;
- unsignedb_hw:1; /* bad h/w fixes */
unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
@@ -557,9 +556,6 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev,
u8 size, bool is_rx)
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- if (dev-rev OMAP_I2C_REV_ON_3630)
- dev-b_hw = 1; /* Enable hardware fixes */
-
/* calculate wakeup latency constraint for MPU */
if (dev-set_mpu_wkup_lat != NULL)
dev-latency = (100 * dev-threshold) /
@@ -1215,9 +1211,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev OMAP_I2C_REV_ON_3630)
- dev-b_hw = 1; /* Enable hardware fixes */
-
/* calculate wakeup latency constraint for MPU */
if (dev-set_mpu_wkup_lat != NULL)
dev-latency = (100 * dev-fifo_size) /
--
1.8.1.rc1.5.g7e0651a
--
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 REBASE 2/6] i2c: omap: also complete() when stat becomes zero
In case we loop on IRQ handler until stat is finally zero, we would end up in a situation where all I2C transfers would misteriously timeout because we were not calling complete() in that situation. Fix the issue by moving omap_i2c_complete_cmd() call inside the 'out' label. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/i2c/busses/i2c-omap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 9a9cf7c..fcecb0b 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) } } while (stat); - omap_i2c_complete_cmd(dev, err); - out: + omap_i2c_complete_cmd(dev, err); spin_unlock_irqrestore(dev-lock, flags); return IRQ_HANDLED; -- 1.8.1.rc1.5.g7e0651a -- 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 REBASE 1/6] i2c: omap: no need to access platform_device
PM callbacks pass our device pointer as argument
and we don't need to access the platform_device
just to dereference that down to dev-drvdata.
instead, just use dev_get_drvdata() directly.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7a62acb..9a9cf7c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1289,8 +1289,7 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM_RUNTIME
static int omap_i2c_runtime_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
@@ -1310,8 +1309,7 @@ static int omap_i2c_runtime_suspend(struct device *dev)
static int omap_i2c_runtime_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
if (!_dev-regs)
return 0;
--
1.8.1.rc1.5.g7e0651a
--
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 REBASE 4/6] i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't enabled as an
IRQ source.
One such case is after we finish converting to
deferred stop bit, we will have to poll for ARDY
bit before returning control for the client driver
in order to prevent us from trying to start a
transfer on a bus which is already busy.
Note, however, that i2c-omap.c needs a big rework
on register definition and register access. Such
work will be done in a separate series of patches.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 50 +--
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c93eb17..039edc2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -288,6 +288,36 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
+static inline void omap_i2c_write_irqstatus(struct omap_i2c_dev *i2c_dev,
+ u16 val)
+{
+ omap_i2c_write_reg(i2c_dev, OMAP_I2C_STAT_REG, val);
+}
+
+static inline u16 omap_i2c_read_irqstatus(struct omap_i2c_dev *i2c_dev)
+{
+ u16 scheme;
+
+ /*
+* if we are OMAP_I2C_IP_VERSION_2, we need to read from
+* IRQSTATUS_RAW, but write to IRQSTATUS
+*/
+ scheme = OMAP_I2C_SCHEME(i2c_dev-rev);
+ switch (scheme) {
+ case OMAP_I2C_SCHEME_0:
+ return __raw_readw(i2c_dev-base +
+ (i2c_dev-regs[OMAP_I2C_STAT_REG]
+i2c_dev-reg_shift));
+ break;
+ case OMAP_I2C_SCHEME_1:
+ /* FALLTHROUGH */
+ default:
+ return __raw_readw(i2c_dev-base +
+ ((i2c_dev-regs[OMAP_I2C_STAT_REG] - 0x04)
+ i2c_dev-reg_shift));
+ }
+}
+
static void __omap_i2c_init(struct omap_i2c_dev *dev)
{
@@ -470,7 +500,7 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
unsigned long timeout;
timeout = jiffies + OMAP_I2C_TIMEOUT;
- while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) OMAP_I2C_STAT_BB) {
+ while (omap_i2c_read_irqstatus(dev) OMAP_I2C_STAT_BB) {
if (time_after(jiffies, timeout)) {
dev_warn(dev-dev, timeout waiting for bus ready\n);
return -ETIMEDOUT;
@@ -696,7 +726,7 @@ omap_i2c_complete_cmd(struct omap_i2c_dev *dev, u16 err)
static inline void
omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
{
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
+ omap_i2c_write_irqstatus(dev, stat);
}
static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)
@@ -713,12 +743,10 @@ static inline void i2c_omap_errata_i207(struct
omap_i2c_dev *dev, u16 stat)
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
/* Step 2: */
- if (!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
-OMAP_I2C_STAT_BB)) {
+ if (!(omap_i2c_read_irqstatus(dev) OMAP_I2C_STAT_BB)) {
/* Step 3: */
- if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
-OMAP_I2C_STAT_RDR) {
+ if (omap_i2c_read_irqstatus(dev) OMAP_I2C_STAT_RDR) {
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
dev_dbg(dev-dev, RDR when bus is busy.\n);
}
@@ -799,7 +827,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
u16 stat;
do {
- stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat = omap_i2c_read_irqstatus(dev);
if (stat OMAP_I2C_STAT_XUDF)
break;
@@ -894,7 +922,7 @@ omap_i2c_isr(int irq, void *dev_id)
spin_lock(dev-lock);
mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat = omap_i2c_read_irqstatus(dev);
if (stat mask)
ret = IRQ_WAKE_THREAD;
@@ -916,7 +944,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat = omap_i2c_read_irqstatus(dev);
stat = bits;
/* If we're in receiver mode, ignore XDR/XRDY */
@@ -1297,10 +1325,10 @@ static int omap_i2c_runtime_suspend(struct device
[PATCH REBASE 5/6] i2c: omap: wait for transfer completion before sending STP bit
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
byte got NACKed so it doesn't have to resend
all bytes again.
In order to make that work with OMAP's I2C
controller, we need to prevent sending STP
bit until message is transferred. The reason
behind that is because OMAP_I2C_CNT_REG gets
reset to original value after STP bit is
shifted through I2C_SDA line and that would
prevent us from reading the correct number of
bytes left to transfer.
The full programming model suggested by IP
owner was the following:
- start I2C transfer (without STP bit)
- upon completion or NACK, read I2C_CNT register
- write STP bit to I2C_CON register
- wait for ARDY bit
With this patch we're implementing all steps
except step #2 which will come in a later
patch series. In order to implement full NACK
reporting we need to add a new field to struct
i2c_msg, but that's still under discussion on
what's the best way to do it. For now, we can
prepare the driver to receive that piece of code.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 92 ++-
1 file changed, 38 insertions(+), 54 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 039edc2..4d90f08 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -479,9 +479,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev-fifo_size) ?
- (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0);
+ OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
+ ((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
+ OMAP_I2C_IE_XDR) : 0);
dev-pscstate = psc;
dev-scllstate = scll;
@@ -511,6 +511,22 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+static int omap_i2c_wait_for_ardy(struct omap_i2c_dev *dev)
+{
+ unsigned long timeout;
+
+ timeout = jiffies + OMAP_I2C_TIMEOUT;
+ while (!(omap_i2c_read_irqstatus(dev) OMAP_I2C_STAT_ARDY)) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev, timeout waiting for access
ready\n);
+ return -ETIMEDOUT;
+ }
+ usleep_range(800, 1200);
+ }
+
+ return 0;
+}
+
static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
{
u16 buf;
@@ -558,6 +574,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
unsigned long timeout;
+ int ret = 0;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -601,35 +618,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (!(msg-flags I2C_M_RD))
w |= OMAP_I2C_CON_TRX;
- if (!dev-b_hw stop)
- w |= OMAP_I2C_CON_STP;
-
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
-* Don't write stt and stp together on some hardware.
-*/
- if (dev-b_hw stop) {
- unsigned long delay = jiffies + OMAP_I2C_TIMEOUT;
- u16 con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- while (con OMAP_I2C_CON_STT) {
- con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
-
- /* Let the user know if i2c is in a bad state */
- if (time_after(jiffies, delay)) {
- dev_err(dev-dev, controller timed out
- waiting for start condition to finish\n);
- return -ETIMEDOUT;
- }
- cpu_relax();
- }
-
- w |= OMAP_I2C_CON_STP;
- w = ~OMAP_I2C_CON_STT;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
-
- /*
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
@@ -639,31 +630,37 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev_err(dev-dev, controller timed out\n);
omap_i2c_reset(dev);
__omap_i2c_init(dev);
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
- if (likely(!dev-cmd_err))
- return 0;
-
/* We have an error */
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
[GIT PULL] ARM: OMAP2+: Timer build warnings fixes for v3.8-rc
The following changes since commit 698d601224824bc1a5bf17f3d86be902e2aabff0: Merge tag 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-12-13 10:59:11 -0800) are available in the git repository at: git://github.com/jonhunter/linux.git fixes-timer-build for you to fetch changes up to bf85f205d95eb223e849914101e0db1a5a576a3c: ARM: OMAP2+: Fix sparse warnings in timer.c (2012-12-14 10:14:55 -0600) Fixes for a few timer warnings observed with different kernel configurations for OMAP2+ devices. I have dropped the patch to fix a build error for OMAP4 in the timer code as Olof already has this fix merged. Jon Hunter (2): ARM: OMAP2+: Fix realtime_counter_init warning in timer.c ARM: AM335x: Fix warning in timer.c Vaibhav Hiremath (1): ARM: OMAP2+: Fix sparse warnings in timer.c arch/arm/mach-omap2/Kconfig |3 ++- arch/arm/mach-omap2/timer.c |6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider
On Thu, Dec 13, 2012 at 11:32 PM, Paul Walmsley p...@pwsan.com wrote: The OMAP4 clock divider div_iva_hs_clk is listed in the clock data as an OMAP HSDIVIDER, but it's actually a power-of-two divider. This causes a warning during boot on an OMAP4460 Pandaboard-ES with a recent u-boot: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:143 omap2_clksel_recalc+0xf4/0x12c() clock: div_iva_hs_clk: could not find fieldval 0 for parent dpll_core_m5x2_ck Fix by converting the data for this clock to a power-of-two divider. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@linaro.org --- arch/arm/mach-omap2/cclock44xx_data.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c index aa56c3e..a3c54b2 100644 --- a/arch/arm/mach-omap2/cclock44xx_data.c +++ b/arch/arm/mach-omap2/cclock44xx_data.c @@ -286,9 +286,9 @@ DEFINE_CLK_DIVIDER(div_core_ck, dpll_core_m5x2_ck, dpll_core_m5x2_ck, 0x0, OMAP4430_CM_CLKSEL_CORE, OMAP4430_CLKSEL_CORE_SHIFT, OMAP4430_CLKSEL_CORE_WIDTH, 0x0, NULL); -DEFINE_CLK_OMAP_HSDIVIDER(div_iva_hs_clk, dpll_core_m5x2_ck, - dpll_core_m5x2_ck, 0x0, OMAP4430_CM_BYPCLK_DPLL_IVA, - OMAP4430_CLKSEL_0_1_MASK); +DEFINE_CLK_DIVIDER(div_iva_hs_clk, dpll_core_m5x2_ck, dpll_core_m5x2_ck, + 0x0, OMAP4430_CM_BYPCLK_DPLL_IVA, OMAP4430_CLKSEL_0_1_SHIFT, + OMAP4430_CLKSEL_0_1_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL); Hi Paul, Looks good to me. Regards, Mike DEFINE_CLK_DIVIDER(div_mpu_hs_clk, dpll_core_m5x2_ck, dpll_core_m5x2_ck, 0x0, OMAP4430_CM_BYPCLK_DPLL_MPU, OMAP4430_CLKSEL_0_1_SHIFT, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent lists
On Thu, Dec 13, 2012 at 11:32 PM, Paul Walmsley p...@pwsan.com wrote: Booting OMAP4460 Pandaboard ES with a recent u-boot results in this warning: WARNING: at arch/arm/mach-omap2/dpll3xxx.c:427 omap3_noncore_dpll_enable+0xf4/0x110() The OMAP4 DPLL parent clock name arrays only listed the reference clocks, not the bypass clocks. Fix by adding the bypass clocks to the DPLL parent lists. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@linaro.org That is really strange. I wonder if something went wrong with the autogenerated data or perhaps later on when the file was being edited by hand... Patch looks good to me. Regards, Mike -- 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: [GIT PULL] ARM: OMAP2+: Timer build warnings fixes for v3.8-rc
* Jon Hunter jon-hun...@ti.com [121214 08:48]: The following changes since commit 698d601224824bc1a5bf17f3d86be902e2aabff0: Merge tag 'drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-12-13 10:59:11 -0800) are available in the git repository at: git://github.com/jonhunter/linux.git fixes-timer-build for you to fetch changes up to bf85f205d95eb223e849914101e0db1a5a576a3c: ARM: OMAP2+: Fix sparse warnings in timer.c (2012-12-14 10:14:55 -0600) Fixes for a few timer warnings observed with different kernel configurations for OMAP2+ devices. I have dropped the patch to fix a build error for OMAP4 in the timer code as Olof already has this fix merged. Thanks pulling into omap-for-v3.8/fixes-for-merge-window. Regards, Tony Jon Hunter (2): ARM: OMAP2+: Fix realtime_counter_init warning in timer.c ARM: AM335x: Fix warning in timer.c Vaibhav Hiremath (1): ARM: OMAP2+: Fix sparse warnings in timer.c arch/arm/mach-omap2/Kconfig |3 ++- arch/arm/mach-omap2/timer.c |6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: OMAP3: igep0020: simplify GPIO LEDs dependencies
The IGEPv2 board has two user GPIO LEDs and one of them is
default to on to tell the user that the board booted correctly.
But to use these LEDs the config options CONFIG_LEDS_GPIO,
CONFIG_LEDS_TRIGGERS and CONFIG_LEDS_TRIGGER_DEFAULT_ON have to
be enabled.
Since only the default-on and default-off triggers were used
anyway, it is better to just use .default_state instead of
.default_trigger and not depend on CONFIG_LEDS_TRIGGER_*
Also, this is consistent with IGEPv2 Device Tree that uses
default-state instead of linux,default-trigger for the leds
device nodes. The LED names also have been updated to use the
same names used on omap3-igep0020.dtb.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/board-igep0020.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..1921541 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -300,20 +300,20 @@ static struct omap2_hsmmc_info mmc[] = {
static struct gpio_led igep_gpio_leds[] = {
[0] = {
- .name = gpio-led:red:d0,
- .default_trigger= default-off
+ .name = omap3:red:user0,
+ .default_state = 0,
},
[1] = {
- .name = gpio-led:green:d0,
- .default_trigger= default-off,
+ .name = omap3:green:boot,
+ .default_state = 1,
},
[2] = {
- .name = gpio-led:red:d1,
- .default_trigger= default-off,
+ .name = omap3:red:user1,
+ .default_state = 0,
},
[3] = {
- .name = gpio-led:green:d1,
- .default_trigger= heartbeat,
+ .name = omap3:green:user1,
+ .default_state = 0,
.gpio = -EINVAL, /* gets replaced */
.active_low = 1,
},
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER
* Peter Ujfalusi peter.ujfal...@ti.com [121122 02:28]: Hi Tony, On 11/21/2012 10:52 PM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [121115 00:12]: Hi Tony, On 11/13/2012 10:32 AM, Peter Ujfalusi wrote: To facilitate upcoming cleanup in twl stack. No functional change. Would you please consider this patch for 3.8? It would shorten the time I'll need to progress on the cleanup regarding to twl-core greatly. Please go ahead and merge this with your other patches: Acked-by: Tony Lindgren t...@atomide.com Or let me know if I still need to queue it. This patch has no dependencies on other patches. It is better to go via linux-omap. Applying into omap-for-v3.8/fixes-for-merge-window. 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] mach-omap2/board-igep0020.c: Fix reboot problem
* Robert Nelson robertcnel...@gmail.com [121115 08:44]:
On Thu, Nov 15, 2012 at 10:06 AM, Matthias Brugger
matthias@googlemail.com wrote:
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
This patch adds a generic power save script, which resets the TWL4030 when a
warm reset occures. This way the OMAP3530 does not hang on reboot.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/arm/mach-omap2/board-igep0020.c | 36
++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 48d5e41..9ba1c4b 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -487,11 +487,47 @@ static struct twl4030_keypad_data igep2_keypad_pdata
= {
.rep= 1,
};
+static struct twl4030_ins wrst_seq[] __initdata = {
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *twl4030_scripts[] __initdata = {
+ wrst_script,
+};
+
+static struct twl4030_resconfig twl4030_rconfig[] = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data igep_twl4030_power_data = {
+ .scripts= twl4030_scripts,
+ .num= ARRAY_SIZE(twl4030_scripts),
+ .resource_config = twl4030_rconfig,
+};
+
static struct twl4030_platform_data igep_twldata = {
/* platform_data for children goes here */
.gpio = igep_twl4030_gpio_pdata,
.vmmc1 = igep_vmmc1,
.vio= igep_vio,
+ .power = igep_twl4030_power_data,
};
static struct i2c_board_info __initdata igep2_i2c3_boardinfo[] = {
--
1.7.9.5
--
Sweet, this also fixes the software reboot lockup I've been bisecting
on the Beagle C4 (omap3530), when the ONDEMAND governor is enabled..
(applied the same changes to the beagle's board file:
board-omap3beagle.c)
Can we make this script generic for all omap35xx/twl4030 boards that need it?
So far, no regressions in a quick boot/reboot test of DM3730 Beagle xM
C that shares the board file...
Any news on making this fix generic?
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] ARM: OMAP3: Devkit8000: Add DDC i2c_bus_num
* Thomas Weber tho...@tomweber.eu [121115 10:14]:
Add i2c bus number for DVI output.
The driver uses this to detect if a panel is connected and to read EDID.
Thanks applying into omap-for-v3.8/fixes-for-merge-window.
Regards,
Tony
Signed-off-by: Thomas Weber tho...@tomweber.eu
---
arch/arm/mach-omap2/board-devkit8000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..6f04f0f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -139,6 +139,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= 1,
};
static struct omap_dss_device devkit8000_dvi_device = {
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Devkit8000: Add DDC i2c_bus_num
* Tony Lindgren t...@atomide.com [121214 09:23]: * Thomas Weber tho...@tomweber.eu [121115 10:14]: Add i2c bus number for DVI output. The driver uses this to detect if a panel is connected and to read EDID. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Oops, dropping and using Tomi's generic version instead. 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: [PATCHv2] OMAP: board-files: fix i2c_bus for tfp410
* Tomi Valkeinen tomi.valkei...@ti.com [121130 01:33]: Hi Tony, On 2012-11-22 10:39, Tomi Valkeinen wrote: The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af (OMAPDSS: TFP410: pdata rewrite). The patch changed what value the driver considers as invalid/undefined. Before the patch, 0 was the invalid value, but as 0 is a valid bus number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: Thomas Weber tho...@tomweber.eu Cc: Thomas Weber tho...@tomweber.eu Cc: sta...@vger.kernel.org # v3.5+ --- arch/arm/mach-omap2/board-3430sdp.c |1 + arch/arm/mach-omap2/board-am3517evm.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/board-omap3stalker.c |1 + include/video/omap-panel-tfp410.h|2 +- 7 files changed, 7 insertions(+), 1 deletion(-) Did this make it into your v3.8 branch? Applying now into omap-for-v3.8/fixes-for-merge-window. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ir-rx51: Handle signals properly
* Tony Lindgren t...@atomide.com [121120 12:00]:
Hi,
* Timo Kokkonen timo.t.kokko...@iki.fi [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
Just to update the status on this.. It seems that we'll be moving
parts of plat/dmtimer into a minimal include/linux/timer-omap.h
unless people have better ideas on what to do with custom
hardware timers for PWM etc.
The other alternative is to set them up as platform_data
function pointers, but that won't work after we make omap2+
device tree only. And that really just postpones the problem.
Cheers,
Tony
@@ -163,13 +176,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int
irq, void *ptr)
return IRQ_HANDLED;
end:
- /* Stop TX here */
- lirc_rx51_off(lirc_rx51);
- lirc_rx51-wbuf_index = -1;
- omap_dm_timer_stop(lirc_rx51-pwm_timer);
- omap_dm_timer_stop(lirc_rx51-pulse_timer);
- omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
- wake_up_interruptible(lirc_rx51-wqueue);
+ lirc_rx51_stop_tx(lirc_rx51);
return IRQ_HANDLED;
}
@@ -249,8 +256,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if ((count WBUF_LEN) || (count % 2 == 0))
return -EINVAL;
- /* Wait any pending transfers to finish */
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ /* We can have only one transmit at a time */
+ if (lirc_rx51-wbuf_index = 0)
+ return -EBUSY;
if (copy_from_user(lirc_rx51-wbuf, buf, n))
return -EFAULT;
@@ -276,9 +284,18 @@ static ssize_t lirc_rx51_write(struct file *file,
const char *buf,
/*
* Don't return back to the userspace until the transfer has
-* finished
+* finished. However, we wish to not spend any more than 500ms
+* in kernel. No IR code TX should ever take that long.
+*/
+ i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0,
+ HZ / 2);
+
+ /*
+* Ensure transmitting has really stopped, even if the timers
+* went mad or something else happened that caused it still
+* sending out something.
*/
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ lirc_rx51_stop_tx(lirc_rx51);
/* We can sleep again */
lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] OMAP2+: enable TPS65217 support in omap2plus_defconfig
* Igor Mazanov i.maza...@gmail.com [121120 09:12]: On Tue, Nov 20, 2012 at 2:15 PM, AnilKumar, Chimata anilku...@ti.com wrote: On Mon, Nov 19, 2012 at 17:15:25, Igor Mazanov wrote: TPS65217 is described in arch/arm/boot/dts/am335x-bone.dts but doesn't enabled in arch/arm/configs/omap2plus_defconfig. Enable TPS65217 support in omap2plus_defconfig. Signed-off-by: Igor Mazanov i.maza...@gmail.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..00f2ce3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -240,3 +240,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_MFD_CORE=y +CONFIG_MFD_TPS65217=y +CONFIG_REGULATOR_TPS65217=y Hi Igor, Can you try this, MFD_CORE is selected by default and note that remaining flags should be added at appropriate places. Author: AnilKumar Ch anilku...@ti.com Date: Tue Nov 20 15:34:51 2012 +0530 Custom: ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support Signed-off-by: AnilKumar Ch anilku...@ti.com diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..69ddbf7 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -132,9 +132,11 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_TPS65217=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TPS65217=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y OK, I made changes as you say and it works. Thanks for a tip about default selection of CONFIG_MFD. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ir-rx51: Handle signals properly
Hi,
On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121120 12:00]:
Hi,
* Timo Kokkonen timo.t.kokko...@iki.fi [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
Just to update the status on this.. It seems that we'll be moving
parts of plat/dmtimer into a minimal include/linux/timer-omap.h
unless people have better ideas on what to do with custom
hardware timers for PWM etc.
if it's really for PWM, shouldn't we be using drivers/pwm/ ??
Meaning that $SUBJECT would just request a PWM device and use it. That
doesn't solve the whole problem, however, as pwm-omap.c would still need
access to timer-omap.h.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/7] ir-rx51: Handle signals properly
* Felipe Balbi ba...@ti.com [121214 09:36]:
Hi,
On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121120 12:00]:
Hi,
* Timo Kokkonen timo.t.kokko...@iki.fi [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51
*lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
Just to update the status on this.. It seems that we'll be moving
parts of plat/dmtimer into a minimal include/linux/timer-omap.h
unless people have better ideas on what to do with custom
hardware timers for PWM etc.
if it's really for PWM, shouldn't we be using drivers/pwm/ ??
Meaning that $SUBJECT would just request a PWM device and use it. That
doesn't solve the whole problem, however, as pwm-omap.c would still need
access to timer-omap.h.
That would only help with omap_dm_timer_set_pwm() I think.
The other functions are also needed by the clocksource and clockevent
drivers. And tidspbridge too:
$ grep -r omap_dm_timer drivers/
...
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ir-rx51: Handle signals properly
Hi,
On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121214 09:36]:
Hi,
On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121120 12:00]:
Hi,
* Timo Kokkonen timo.t.kokko...@iki.fi [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51
*lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
Just to update the status on this.. It seems that we'll be moving
parts of plat/dmtimer into a minimal include/linux/timer-omap.h
unless people have better ideas on what to do with custom
hardware timers for PWM etc.
if it's really for PWM, shouldn't we be using drivers/pwm/ ??
Meaning that $SUBJECT would just request a PWM device and use it. That
doesn't solve the whole problem, however, as pwm-omap.c would still need
access to timer-omap.h.
That would only help with omap_dm_timer_set_pwm() I think.
The other functions are also needed by the clocksource and clockevent
drivers. And tidspbridge too:
well, we _do_ have drivers/clocksource ;-)
--
balbi
signature.asc
Description: Digital signature
[PATCH v2 1/1] ARM: OMAP2+: omap2plus_defconfig: enable devtmpfs and automount
Since udev-176 [1], udev no longer creates device nodes under /dev and this has to be managed by the kernel devtmpfs filesystem. This makes devtmpfs filesystem a requirement on newer systems and a kernel built with the current OMAP2+ config will not boot on them. Also, it is good to have devtmpfs at /dev automount enabled by default. [1]: http://permalink.gmane.org/gmane.linux.hotplug.devel/17230 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Point to correct udev version that first this a requirement as suggested by Sekhar Nori arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a1dc5c0..ad41190 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -65,6 +65,8 @@ CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ir-rx51: Handle signals properly
* Felipe Balbi ba...@ti.com [121214 09:59]: On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121214 09:36]: if it's really for PWM, shouldn't we be using drivers/pwm/ ?? Meaning that $SUBJECT would just request a PWM device and use it. That doesn't solve the whole problem, however, as pwm-omap.c would still need access to timer-omap.h. That would only help with omap_dm_timer_set_pwm() I think. The other functions are also needed by the clocksource and clockevent drivers. And tidspbridge too: well, we _do_ have drivers/clocksource ;-) That's where the dmtimer code should live. But still it does not help with the header. Thomas, maybe we could use the hrtimer framework for it if there was some way to completely leave out the rb tree for the dedicated hardware timers? There's no queue needed as there's always just one value tied to a specific timer. 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
[PATCH] ARM: OMAP2+: PMU: Remove unused header
Commit 2ac29a1 (ARM: PMU: fix runtime PM enable) moved the call to pm_runtime_enable() from the OMAP2+ PMU code into the ARM PERF core code. However, header for pm_runtime which should have been removed from the OMAP2+ PMU code was not. It is no longer necessary to include this header in the OMAP2+ PMU code and so remove it. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/pmu.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c index 250d909..eb78ae7 100644 --- a/arch/arm/mach-omap2/pmu.c +++ b/arch/arm/mach-omap2/pmu.c @@ -11,8 +11,6 @@ * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. */ -#include linux/pm_runtime.h - #include asm/pmu.h #include soc.h -- 1.7.10.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 0/7] ARM: OMAP2+: AM33XX: Enable few drivers in omap2plus_defconfig
* AnilKumar Ch anilku...@ti.com [121120 23:01]: This patch series enable tps65910, lis3lv02d accelerometer, tsl2550 ambient light sensor, matrix keypad, tmp275 temperature sensor, gpio leds and D_CAN drivers in omap2plus_defconfig. These are the peripherals present in AM33XX family of devices. AnilKumar Ch (7): ARM: OMAP2+: omap2plus_defconfig: Enable tps65910 PMIC ARM: OMAP2+: omap2plus_defconfig: Enable lis3lv02d accelerometer ARM: OMAP2+: omap2plus_defconfig: Enable tsl2550 ambient light sensor ARM: OMAP2+: omap2plus_defconfig: Enable matrix keypad driver ARM: OMAP2+: omap2plus_defconfig: Enable tmp275 sensor ARM: OMAP2+: omap2plus_defconfig: Enable leds-gpio driver ARM: OMAP2+: omap2plus_defconfig: Enable DCAN controller arch/arm/configs/omap2plus_defconfig | 17 + 1 file changed, 17 insertions(+) Let's make all these into modules except for the tps65910. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP2+: enable devtmpfs and devtmpfs automount
* Javier Martinez Canillas javier.marti...@collabora.co.uk [121121 05:29]: Since udev-182, udev no longer creates device nodes under /dev and this has to be managed by the kernel devtmpfs filesystem. This means that a kernel built with the current OMAP2+ config will not boot on a system with a recent udev. Also, it is good to have /dev automatically mounted since some non-initramfs based setups assumes this and don't manually mount it. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Regards, Tony Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..6333e96 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -65,6 +65,8 @@ CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP2+: mux: Fixed gpio mux mode analysis.
* oleg.matcovs...@ti.com oleg.matcovs...@ti.com [121126 17:04]:
From: Oleg Matcovschi oleg.matcovs...@ti.com
OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4.
It is not correct for following platforms:
2430 - gpio mux mode 3
44xx - gpio mux mode 3
54xx - gpio mux mode 6
Patch reserves first 3 bits in partition flags for storing gpio mux
mode in same format as stored in control pad register.
Modified OMAP_MODE_GPIO() macro to handle all possible cases of gpio mux mode.
Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4.
Thanks applying into omap-for-v3.8/fixes-for-merge-window.
Regards,
Tony
Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com
---
arch/arm/mach-omap2/mux.c | 10 --
arch/arm/mach-omap2/mux.h | 20 +++-
arch/arm/mach-omap2/mux34xx.c |2 +-
3 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 701e17c..1fa39dc 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -134,10 +134,7 @@ static int __init _omap_mux_init_gpio(struct
omap_mux_partition *partition,
old_mode = omap_mux_read(partition, gpio_mux-reg_offset);
mux_mode = val ~(OMAP_MUX_NR_MODES - 1);
- if (partition-flags OMAP_MUX_GPIO_IN_MODE3)
- mux_mode |= OMAP_MUX_MODE3;
- else
- mux_mode |= OMAP_MUX_MODE4;
+ mux_mode |= partition-gpio;
pr_debug(%s: Setting signal %s.gpio%i 0x%04x - 0x%04x\n, __func__,
gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
omap_mux_write(partition, mux_mode, gpio_mux-reg_offset);
@@ -799,7 +796,7 @@ int __init omap_mux_late_init(void)
struct omap_mux *m = e-mux;
u16 mode = omap_mux_read(partition, m-reg_offset);
- if (OMAP_MODE_GPIO(mode))
+ if (OMAP_MODE_GPIO(partition, mode))
continue;
#ifndef CONFIG_DEBUG_FS
@@ -1064,7 +1061,7 @@ static void __init omap_mux_init_list(struct
omap_mux_partition *partition,
}
#else
/* Skip pins that are not muxed as GPIO by bootloader */
- if (!OMAP_MODE_GPIO(omap_mux_read(partition,
+ if (!OMAP_MODE_GPIO(partition, omap_mux_read(partition,
superset-reg_offset))) {
superset++;
continue;
@@ -1131,6 +1128,7 @@ int __init omap_mux_init(const char *name, u32 flags,
partition-name = name;
partition-flags = flags;
+ partition-gpio = flags OMAP_MUX_MODE7;
partition-size = mux_size;
partition-phys = mux_pbase;
partition-base = ioremap(mux_pbase, mux_size);
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 76f9b3c..5504e12 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -58,7 +58,8 @@
#define OMAP_PIN_OFF_INPUT_PULLDOWN (OMAP_OFF_EN | OMAP_OFF_PULL_EN)
#define OMAP_PIN_OFF_WAKEUPENABLEOMAP_WAKEUP_EN
-#define OMAP_MODE_GPIO(x)(((x) OMAP_MUX_MODE7) == OMAP_MUX_MODE4)
+#define OMAP_MODE_GPIO(partition, x) (((x) OMAP_MUX_MODE7) == \
+ partition-gpio)
#define OMAP_MODE_UART(x)(((x) OMAP_MUX_MODE7) == OMAP_MUX_MODE0)
/* Flags for omapX_mux_init */
@@ -79,13 +80,20 @@
/*
* omap_mux_init flags definition:
*
+ * OMAP_GPIO_MUX_MODE, bits 0-2: gpio muxing mode, same like pad control
+ * register which includes values from 0-7.
* OMAP_MUX_REG_8BIT: Ensure that access to padconf is done in 8 bits.
* The default value is 16 bits.
- * OMAP_MUX_GPIO_IN_MODE3: The GPIO is selected in mode3.
- * The default is mode4.
*/
-#define OMAP_MUX_REG_8BIT(1 0)
-#define OMAP_MUX_GPIO_IN_MODE3 (1 1)
+#define OMAP_MUX_GPIO_IN_MODE0 OMAP_MUX_MODE0
+#define OMAP_MUX_GPIO_IN_MODE1 OMAP_MUX_MODE1
+#define OMAP_MUX_GPIO_IN_MODE2 OMAP_MUX_MODE2
+#define OMAP_MUX_GPIO_IN_MODE3 OMAP_MUX_MODE3
+#define OMAP_MUX_GPIO_IN_MODE4 OMAP_MUX_MODE4
+#define OMAP_MUX_GPIO_IN_MODE5 OMAP_MUX_MODE5
+#define OMAP_MUX_GPIO_IN_MODE6 OMAP_MUX_MODE6
+#define OMAP_MUX_GPIO_IN_MODE7 OMAP_MUX_MODE7
+#define OMAP_MUX_REG_8BIT(1 3)
/**
* struct omap_board_data - board specific device data
@@ -105,6 +113,7 @@ struct omap_board_data {
* struct mux_partition - contain partition related information
* @name: name of the current partition
* @flags: flags specific to this partition
+ * @gpio: gpio mux mode
* @phys: physical address
* @size: partition size
* @base: virtual address after ioremap
@@ -114,6 +123,7 @@ struct omap_board_data {
struct omap_mux_partition {
const char *name;
Re: [PATCH 1/7] ir-rx51: Handle signals properly
Hi, On Fri, Dec 14, 2012 at 10:06:45AM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121214 09:59]: On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121214 09:36]: if it's really for PWM, shouldn't we be using drivers/pwm/ ?? Meaning that $SUBJECT would just request a PWM device and use it. That doesn't solve the whole problem, however, as pwm-omap.c would still need access to timer-omap.h. That would only help with omap_dm_timer_set_pwm() I think. The other functions are also needed by the clocksource and clockevent drivers. And tidspbridge too: well, we _do_ have drivers/clocksource ;-) That's where the dmtimer code should live. But still it does not help with the header. yeah, the header should be where you suggested, no doubts. I was actually criticizing the current timer code. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] ARM: OMAP2+: enable devtmpfs and devtmpfs automount
On Fri, Dec 14, 2012 at 7:10 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [121121 05:29]: Since udev-182, udev no longer creates device nodes under /dev and this has to be managed by the kernel devtmpfs filesystem. This means that a kernel built with the current OMAP2+ config will not boot on a system with a recent udev. Also, it is good to have /dev automatically mounted since some non-initramfs based setups assumes this and don't manually mount it. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Regards, Tony Hi Tony, I resend a v2 today: [PATCH v2 1/1] ARM: OMAP2+: omap2plus_defconfig: enable devtmpfs and automount That fixes an issue in the patch comments. Sekar Nori pointed out that the first udev to make this a requirement was 176 not 182. So probably is better if you can apply that one instead. Thanks a lot and best regards, Javier -- 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: cpts: Fix build error caused by include of plat/clock.h
From: Richard Cochran richardcoch...@gmail.com Date: Fri, 14 Dec 2012 12:09:18 +0100 On Fri, Dec 14, 2012 at 10:55:56AM +0100, Koen Kooi wrote: Op 14 dec. 2012, om 08:13 heeft Richard Cochran richardcoch...@gmail.com het volgende geschreven: On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html That patch didn't get applied, so it's still broken in Linus' tree :( In netdev's patchwork, this was marked Not Applicable. Dave, can you possibly take this patch? If not, who should I ask next? That's strange, when I look at that patch it's marked Accepted ;-) -- 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 -next] ARM: OMAP4: remove duplicated include from omap_hwmod_44xx_data.c
* Wei Yongjun weiyj...@gmail.com [121128 18:48]: From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Regards, Tony Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index e5eda55..f13fdbb 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -26,7 +26,6 @@ #include plat-omap/dma-omap.h -#include linux/platform_data/omap_ocp2scp.h #include linux/platform_data/spi-omap2-mcspi.h #include linux/platform_data/asoc-ti-mcbsp.h #include plat/dmtimer.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
Re: [PATCH 1/1] ARM: OMAP3: igep0020: default boot status LED to On instead of Heartbeat
On Sat, Nov 24, 2012 at 9:29 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 board uses an green GPIO LED to inform the user
that the kernel could boot.
The green status GPIO LED was default to Heartbeat but On
is better to signal that is running correctly.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/board-igep0020.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..e526228 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -313,7 +313,7 @@ static struct gpio_led igep_gpio_leds[] = {
},
[3] = {
.name = gpio-led:green:d1,
- .default_trigger= heartbeat,
+ .default_trigger= default-on,
.gpio = -EINVAL, /* gets replaced */
.active_low = 1,
},
--
Please ignore this patch since another one was sent that supersedes it.
Thanks a lot and sorry for the noise.
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] ARM: OMAP2+: omap2plus_defconfig: enable devtmpfs and automount
On Friday 14 December 2012 07:02 PM, Javier Martinez Canillas wrote: Since udev-176 [1], udev no longer creates device nodes under /dev and this has to be managed by the kernel devtmpfs filesystem. This makes devtmpfs filesystem a requirement on newer systems and a kernel built with the current OMAP2+ config will not boot on them. Also, it is good to have devtmpfs at /dev automount enabled by default. [1]: http://permalink.gmane.org/gmane.linux.hotplug.devel/17230 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Santosh Shilimkarsantosh.shilim...@ti.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
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
* Roger Quadros rog...@ti.com [121210 02:23]:
There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.
CC: Paul Walmsley p...@pwsan.com
CC: Rajendra Nayak rna...@ti.com
CC: Benoit Cousson b-cous...@ti.com
CC: Mike Turquette mturque...@gmail.com
Paul, what about this patch? Looks like you've acked the other
clock patches in this series but not this one?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 -
arch/arm/mach-omap2/cclock44xx_data.c | 47
+++--
2 files changed, 33 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index bdf3948..5655414 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3392,8 +3392,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(NULL, utmi_p1_gfclk,dummy_ck, CK_3XXX),
- CLK(NULL, utmi_p2_gfclk,dummy_ck, CK_3XXX),
CLK(NULL, xclk60mhsp1_ck, dummy_ck, CK_3XXX),
CLK(NULL, xclk60mhsp2_ck, dummy_ck, CK_3XXX),
CLK(NULL, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index aa56c3e..74535fe 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1366,31 +1366,52 @@ static struct clk_hw_omap usb_host_fs_fck_hw = {
DEFINE_STRUCT_CLK(usb_host_fs_fck, usb_host_fs_fck_parent_names,
usb_host_fs_fck_ops);
+static const struct clk_ops utmi_clk_ops = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .is_enabled = omap2_dflt_clk_is_enabled,
+ .recalc_rate= omap2_clksel_recalc,
+ .get_parent = omap2_clksel_find_parent_index,
+ .set_parent = omap2_clksel_set_parent,
+};
+
static const char *utmi_p1_gfclk_parents[] = {
init_60m_fclk, xclk60mhsp1_ck,
};
-DEFINE_CLK_MUX(utmi_p1_gfclk, utmi_p1_gfclk_parents, NULL, 0x0,
-OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-OMAP4430_CLKSEL_UTMI_P1_SHIFT, OMAP4430_CLKSEL_UTMI_P1_WIDTH,
-0x0, NULL);
+static const struct clksel utmi_p1_clk_mux_sel[] = {
+ { .parent = init_60m_fclk, .rates = div_1_0_rates },
+ { .parent = xclk60mhsp1_ck, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
-DEFINE_CLK_GATE(usb_host_hs_utmi_p1_clk, utmi_p1_gfclk, utmi_p1_gfclk,
0x0,
+/* Merged utmi_p1_gfclk into usb_host_hs_utmi_p1_clk */
+DEFINE_CLK_OMAP_MUX_GATE(usb_host_hs_utmi_p1_clk, l3_init_clkdm,
+ utmi_p1_clk_mux_sel,
+ OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ OMAP4430_CLKSEL_UTMI_P1_MASK,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, 0x0, NULL);
+ OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, NULL,
+ utmi_p1_gfclk_parents, utmi_clk_ops);
static const char *utmi_p2_gfclk_parents[] = {
init_60m_fclk, xclk60mhsp2_ck,
};
-DEFINE_CLK_MUX(utmi_p2_gfclk, utmi_p2_gfclk_parents, NULL, 0x0,
-OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-OMAP4430_CLKSEL_UTMI_P2_SHIFT, OMAP4430_CLKSEL_UTMI_P2_WIDTH,
-0x0, NULL);
+static const struct clksel utmi_p2_clk_mux_sel[] = {
+ { .parent = init_60m_fclk, .rates = div_1_0_rates },
+ { .parent = xclk60mhsp2_ck, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
-DEFINE_CLK_GATE(usb_host_hs_utmi_p2_clk, utmi_p2_gfclk, utmi_p2_gfclk,
0x0,
+/* Merged utmi_p2_gfclk into usb_host_hs_utmi_p2_clk */
+DEFINE_CLK_OMAP_MUX_GATE(usb_host_hs_utmi_p2_clk, l3_init_clkdm,
+ utmi_p2_clk_mux_sel,
+ OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ OMAP4430_CLKSEL_UTMI_P2_MASK,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, 0x0, NULL);
+ OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, NULL,
+ utmi_p2_gfclk_parents, utmi_clk_ops);
DEFINE_CLK_GATE(usb_host_hs_utmi_p3_clk, init_60m_fclk, init_60m_fclk,
0x0,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
@@ -1838,9 +1859,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart4_fck,uart4_fck,
CK_443X),
CLK(NULL,
Re: [PATCH v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
* Samuel Ortiz sa...@linux.intel.com [121213 16:57]: Hi Tony, On Thu, Dec 13, 2012 at 01:49:49PM -0800, Tony Lindgren wrote: Hi Samuel, * Roger Quadros rog...@ti.com [121210 02:23]: Instead of using cpu_is_omap..() macros in the device driver we rely on information provided in the platform data. The only information we need is whether the USB Host module has a single ULPI bypass control bit for all ports or individual bypass control bits for each port. OMAP3 REV2.1 and earlier have the former. I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h for omaps by -rc1 before more drivers start using it again. That is assuming nobody else is planning on merging this series for v3.8 presumably. This should go into 3.9, yes. OK looks like you have all the necessary acks except for one clock change. I replied to that one. Want to ack this one? Looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com Thanks, I'll queue that one and then after -rc1 hopefully you have all the necessary acks to queue this one via your mfd tree. 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/2] ARM: OMAP4: clock data fixes for early 3.8-rc
* Paul Walmsley p...@pwsan.com [121213 23:37]: A few bugs in the OMAP4 common clock framework data caused boot-time warnings on OMAP4460 PandaBoard-ES; these patches fix those. They apply after the arm-soc merge during pre-3.8-rc1. Also needed are Jon Hunter's clock fixes series; the pull request will combine his patches and this series. OK good to hear, I was wondering about that patch. No need for me to reply to that thread then :) 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: MUSB-HDRC Gadget driving VBUS inappropriately
* Ian Coolidge iancooli...@gmail.com [121214 01:55]: Hi, We're using Linux 3.3 on DM3730 with TPS6595xx PMIC for an embedded product. For a particular board, we have musb-hdrc (RTL 1.4) configured in peripheral mode. We use the Ethernet gadget configured for cdc_eem to use Ethernet emulation over USB for this link, and the robustness of the link is mission-critical. To assure this, we have performed some massive reboot testing to ensure that this usb link reliably comes up. Hehehe I've never seen MUSB and mission critical in the same sentence before :) After working through an issue which required pulling in the following patch, - commit b1b552a69b8805e7e338074a9e8b670b4a795218 Author: Michael Grzeschik m.grzesc...@pengutronix.de Date: Wed Aug 8 11:48:10 2012 +0200 usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop - we find that with about a 2% chance, the gadget comes up in some kind of firmware failed state, driving VBUS. In this condition, we found that MUSB_DEVCTL_SESSION bit was set. I understand this to be indicative of MUSB thinking it is in host mode, which agrees with the driven VBUS. Further, in this state, I found that usually, there was one interrupt from twl4030_usb, but NO interrupts from musb-hdrc. So, as a hack, I cleared MUSB_DEVCTL_SESSION in omap2430.c in the notifier block from the VBUS interrupt. This appears to reduce the frequency of the problem -- I now always at least one instance of the musb-hdrc interrupt. However, sometimes, it looks like the MUSB PHY dies shortly thereafter. So, I don't think this hack is fully effective. I reviewed commits that post-date 3.3 in omap2430.c, musb_core.c, twl4030-usb.c, musb_gadget.c, and I couldn't find anything interesting -- it looks like mostly reorganization has taken place. We have also engaged TI to try to get some silicon errata from Mentor Graphics, and maybe a register manual for the MUSB HDRC IP, but this is slow going, and that has little guarantee of paying off anyways. Are there any ideas, or patches that anyone might suggest? Don't know if this is related, but it might. I've noticed and issu with MUSB host mode where MUSB with USB-A cable plugged in fails to come up properly in host mode. It seems to require replugging the USB cable to get it to work in host mode. To reproduce this issue: 1. Boot system with USB-A cable connected and some devices 2. Load g_ether or some gadget module and notice how the USB devices are not discovered, and reloading g_ether does not help. 3. Unplug the USB-A cable, plug in USB-B cable, then plug in USB-A cable again, and the devices are discovered. This one is annoying as it means that trying to use Panda with USB HID devices connected to the MUSB port does not discover them. And the reason to do that is to keep the EHCI ports free for other use naturally.. 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 v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
Hi On Fri, 14 Dec 2012, Tony Lindgren wrote: Paul, what about this patch? Looks like you've acked the other clock patches in this series but not this one? I commented on it briefly here: https://patchwork.kernel.org/patch/1838111/ Maybe Benoît could comment here, but it looks to me (based on a superficial look at the hardware clock tree data) that these clock nodes should exist. In an ideal world, we'd be able to get back to the autogeneration of this clock data. Roger, is it a requirement for the driver to remove these clock nodes, or is it possible to stick with the existing nodes? - Paul
Re: [PATCH v2 1/1] ARM: OMAP2+: omap2plus_defconfig: enable devtmpfs and automount
* Santosh Shilimkar santosh.shilim...@ti.com [121214 10:31]: On Friday 14 December 2012 07:02 PM, Javier Martinez Canillas wrote: Since udev-176 [1], udev no longer creates device nodes under /dev and this has to be managed by the kernel devtmpfs filesystem. This makes devtmpfs filesystem a requirement on newer systems and a kernel built with the current OMAP2+ config will not boot on them. Also, it is good to have devtmpfs at /dev automount enabled by default. [1]: http://permalink.gmane.org/gmane.linux.hotplug.devel/17230 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Santosh Shilimkarsantosh.shilim...@ti.com Thanks, got the previous version of the same patch applied, adding your ack. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: PMU: Remove unused header
* Jon Hunter jon-hun...@ti.com [121214 10:10]: Commit 2ac29a1 (ARM: PMU: fix runtime PM enable) moved the call to pm_runtime_enable() from the OMAP2+ PMU code into the ARM PERF core code. However, header for pm_runtime which should have been removed from the OMAP2+ PMU code was not. It is no longer necessary to include this header in the OMAP2+ PMU code and so remove it. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Regards, Tony Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/pmu.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c index 250d909..eb78ae7 100644 --- a/arch/arm/mach-omap2/pmu.c +++ b/arch/arm/mach-omap2/pmu.c @@ -11,8 +11,6 @@ * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. */ -#include linux/pm_runtime.h - #include asm/pmu.h #include soc.h -- 1.7.10.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: [RESEND] [PATCH 3.6.0- 5/6] ARM/omap: use module_platform_driver macro
* Srinivas KANDAGATLA srinivas.kandaga...@st.com [121012 00:14]:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Thanks, applying this one into omap-for-v3.8/fixes-for-merge-window.
Skipping the mailbox ones as they are getting moved to live
under drivers. And the rng one should go via the rng maintainers.
Regards,
Tony
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 938b50a..c89fc6a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -786,19 +786,8 @@ static struct platform_driver omap_dm_timer_driver = {
},
};
-static int __init omap_dm_timer_driver_init(void)
-{
- return platform_driver_register(omap_dm_timer_driver);
-}
-
-static void __exit omap_dm_timer_driver_exit(void)
-{
- platform_driver_unregister(omap_dm_timer_driver);
-}
-
early_platform_init(earlytimer, omap_dm_timer_driver);
-module_init(omap_dm_timer_driver_init);
-module_exit(omap_dm_timer_driver_exit);
+module_platform_driver(omap_dm_timer_driver);
MODULE_DESCRIPTION(OMAP Dual-Mode Timer Driver);
MODULE_LICENSE(GPL);
--
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] OMAP2: Fix a typo - replace regist with register.
* YOSHIFUJI Hideaki yoshf...@linux-ipv6.org [121102 07:57]: Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org --- arch/arm/mach-omap2/control.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index a89e825..5e6886e 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -233,7 +233,7 @@ #define OMAP343X_PADCONF_ETK_D14 OMAP343X_PADCONF_ETK(16) #define OMAP343X_PADCONF_ETK_D15 OMAP343X_PADCONF_ETK(17) -/* 34xx GENERAL_WKUP regist offsets */ +/* 34xx GENERAL_WKUP register offsets */ #define OMAP343X_CONTROL_WKUP_DEBOBSMUX(i) (OMAP343X_CONTROL_GENERAL_WKUP + \ 0x008 + (i)) #define OMAP343X_CONTROL_WKUP_DEBOBS0 (OMAP343X_CONTROL_GENERAL_WKUP + 0x008) Thanks applying into omap-for-v3.8/fixes-for-merge-window with the subject line also as the description. 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 6/8] arch/arm/mach-omap2/dpll3xxx.c: drop if around WARN_ON
* Julia Lawall julia.law...@lip6.fr [121103 13:32]:
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
Thanks applying this one into omap-for-v3.8/fixes-for-merge-window.
Regards,
Tony
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
arch/arm/mach-omap2/dpll3xxx.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index eacf51f..ed855b0 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -478,8 +478,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (!soc_is_am33xx() !cpu_is_omap44xx()
!cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd-last_rounded_n);
- if (!freqsel)
- WARN_ON(1);
+ WARN_ON(!freqsel);
}
pr_debug(clock: %s: set rate: locking rate to %lu.\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
Re: [PATCH 0/2] ARM: OMAP2420: Fix ethernet support
* Jon Hunter jon-hun...@ti.com [121113 14:04]: Fix ethernet support for OMAP2420 and remove legacy code for ethernet configuration. Thanks applying both into omap-for-v3.8/fixes-for-merge-window. Regards, Tony Jon Hunter (2): ARM: OMAP2420: Fix ethernet support for OMAP2420 H4 ARM: OMAP: Remove debug-devices.c arch/arm/mach-omap2/board-h4.c | 80 +++--- arch/arm/mach-omap2/debug-devices.h |9 arch/arm/plat-omap/Makefile |1 - arch/arm/plat-omap/debug-devices.c | 93 --- 4 files changed, 19 insertions(+), 164 deletions(-) delete mode 100644 arch/arm/mach-omap2/debug-devices.h delete mode 100644 arch/arm/plat-omap/debug-devices.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ir-rx51: Handle signals properly
On 12/14/12 19:26, Felipe Balbi wrote:
Hi,
On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121120 12:00]:
Hi,
* Timo Kokkonen timo.t.kokko...@iki.fi [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
Just to update the status on this.. It seems that we'll be moving
parts of plat/dmtimer into a minimal include/linux/timer-omap.h
unless people have better ideas on what to do with custom
hardware timers for PWM etc.
if it's really for PWM, shouldn't we be using drivers/pwm/ ??
Now that Neil Brown posted the PWM driver for omap, I've been thinking
about whether converting the ir-rx51 into the PWM API would work. Maybe
controlling the PWM itself would be sufficient, but the ir-rx51 uses
also another dmtimer for creating accurate (enough) timing source for
the IR pulse edges.
I haven't tried whether the default 32kHz clock source is enough for
that. Now that I think about it, I don't see why it wouldn't be good
enough. I think it would even be possible to just use the PWM api alone
(plus hr-timers) in order to generate good enough IR pulses.
-Timo
Meaning that $SUBJECT would just request a PWM device and use it. That
doesn't solve the whole problem, however, as pwm-omap.c would still need
access to timer-omap.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
Re: [PATCH 1/7] ir-rx51: Handle signals properly
* Timo Kokkonen timo.t.kokko...@iki.fi [121214 11:33]: On 12/14/12 19:26, Felipe Balbi wrote: if it's really for PWM, shouldn't we be using drivers/pwm/ ?? Now that Neil Brown posted the PWM driver for omap, I've been thinking about whether converting the ir-rx51 into the PWM API would work. Maybe controlling the PWM itself would be sufficient, but the ir-rx51 uses also another dmtimer for creating accurate (enough) timing source for the IR pulse edges. OK. I haven't tried whether the default 32kHz clock source is enough for that. Now that I think about it, I don't see why it wouldn't be good enough. I think it would even be possible to just use the PWM api alone Cool. 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
[PATCH 0/2] few trivial omap patches
Hi all, Here's cleanup patch to remove plat/cpu.h usage where possible, and to add a .dts file maintainers entry for omaps. Regards, Tony --- Tony Lindgren (2): ARM: OMAP2+: Drop remaining plat/cpu.h usage where possible MAINTAINERS: Add an entry for omap related .dts files MAINTAINERS |9 + arch/arm/mach-omap2/drm.c|1 - arch/arm/mach-omap2/dss-common.c |3 +-- arch/arm/mach-omap2/prm2xxx.c|3 +-- arch/arm/mach-omap2/prm3xxx.c|3 +-- drivers/power/avs/smartreflex.c |2 -- 6 files changed, 12 insertions(+), 9 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Drop remaining plat/cpu.h usage where possible
These macros are now in local soc.h in arch/arm/mach-omap2, and plat/cpu.h is around only until the remaining drivers are fixed. Also remove the unused plat/cpu.h from smartreflex.c as it will cause compile errors with ARCH_MULTIPLATFORM enabled. Cc: Jean Pihet jean.pi...@newoldbits.com Cc: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/drm.c|1 - arch/arm/mach-omap2/dss-common.c |3 +-- arch/arm/mach-omap2/prm2xxx.c|3 +-- arch/arm/mach-omap2/prm3xxx.c|3 +-- drivers/power/avs/smartreflex.c |2 -- 5 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c index fce5aa3..4c7566c 100644 --- a/arch/arm/mach-omap2/drm.c +++ b/arch/arm/mach-omap2/drm.c @@ -27,7 +27,6 @@ #include omap_device.h #include omap_hwmod.h -#include plat/cpu.h #if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE) diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c index 679a047..4be5cfc 100644 --- a/arch/arm/mach-omap2/dss-common.c +++ b/arch/arm/mach-omap2/dss-common.c @@ -31,8 +31,7 @@ #include video/omap-panel-nokia-dsi.h #include video/omap-panel-picodlp.h -#include plat/cpu.h - +#include soc.h #include dss-common.h #include mux.h diff --git a/arch/arm/mach-omap2/prm2xxx.c b/arch/arm/mach-omap2/prm2xxx.c index faeab18..cc0e714 100644 --- a/arch/arm/mach-omap2/prm2xxx.c +++ b/arch/arm/mach-omap2/prm2xxx.c @@ -18,9 +18,8 @@ #include linux/io.h #include linux/irq.h +#include soc.h #include common.h -#include plat/cpu.h - #include vp.h #include powerdomain.h #include clockdomain.h diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c index db198d0..39822aa 100644 --- a/arch/arm/mach-omap2/prm3xxx.c +++ b/arch/arm/mach-omap2/prm3xxx.c @@ -18,9 +18,8 @@ #include linux/io.h #include linux/irq.h +#include soc.h #include common.h -#include plat/cpu.h - #include vp.h #include powerdomain.h #include prm3xxx.h diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c index a17d084..6b2238b 100644 --- a/drivers/power/avs/smartreflex.c +++ b/drivers/power/avs/smartreflex.c @@ -27,8 +27,6 @@ #include linux/pm_runtime.h #include linux/power/smartreflex.h -#include plat/cpu.h - #define SMARTREFLEX_NAME_LEN 16 #define NVALUE_NAME_LEN40 #define SR_DISABLE_TIMEOUT 200 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] MAINTAINERS: Add an entry for omap related .dts files
All your omap .dts files are belong to us. Benoît has been doing a good job picking up most of the omap .dts files so far. Let's make sure we both get cc:ed for the related patches. The .dts patches need to be queued by us as separate patches from drivers and other code changes to avoid pointless merge conflists like we saw with v3.8 networking changes. Cc: Benoît Cousson b-cous...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- MAINTAINERS |9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0bc485c..4927e80 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5253,6 +5253,15 @@ F: arch/arm/*omap*/ F: drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h +OMAP DEVICE TREE SUPPORT +M: Benoît Cousson b-cous...@ti.com +M: Tony Lindgren t...@atomide.com +L: linux-omap@vger.kernel.org +L: devicetree-disc...@lists.ozlabs.org (moderated for non-subscribers) +S: Maintained +F: arch/arm/boot/dts/*omap* +F: arch/arm/boot/dts/*am3* + OMAP CLOCK FRAMEWORK SUPPORT M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.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 2/5] ARM: dts: Add Cross Trigger Interface binding
On 12/12/2012 05:23 PM, Jon Hunter wrote: On 12/12/2012 04:12 PM, Rob Herring wrote: On 12/12/2012 03:43 PM, Jon Hunter wrote: Adds a device-tree binding for the ARM Cross Trigger Interface (CTI). The ARM Cross Trigger Interface provides a way to route events between processor modules. For example, on OMAP4430 we use the CTI module to route PMU events to the GIC interrupt module. Do you need to describe the PMU-CTI-GIC connection in DT? We definitely could. This is achieved by mapping a trigger-input to a trigger-output. So we could list the trigger outputs and inputs in the binding. For omap4430 we would have ... arm,cti-trigin = 0 1 2 3 4 5 6; I'd prefer to just spell it out: arm,cti-trigger-in arm,cti-trigin-names = dbgack, pmuirq, ptmextout0, ptmextout1, commtx, commrx, ptmtrigger; arm,cti-trigout = 0 1 2 3 4 6 7; arm,cti-trigout-names = edbgreq, ptmextin0, ptmextin1, ptmextin2, ptmextin3,mpuirq, dbgrestart; So to map the PMU to GIC, we would map the pmuirq trigger input to the mpuirq trigger output. Then we could setup the mapping by name instead of index. I'm not crazy about the name strings and would prefer something with phandles. The above binding doesn't really describe the connection of the CTI to the GIC. The GIC node would need to define some inputs and then you show the connection to the CTI outputs. This may be similar to an interrupt nexus node. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: OMAP2420: Correct H4 board memory size
The system memory node for the OMAP2420 H4 was incorrectly defined as
start address followed by end address, instead of start address and
size. No noticable side-effects were observed but fix this for
correctness.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 77b84e1..9b0d077 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -15,6 +15,6 @@
memory {
device_type = memory;
- reg = 0x8000 0x8400; /* 64 MB */
+ reg = 0x8000 0x400; /* 64 MB */
};
};
--
1.7.10.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] drm/lcdc: add TI LCD Controller DRM driver
On Fri, Dec 14, 2012 at 1:04 AM, Rob Clark robdcl...@gmail.com wrote:
+static int lcdc_crtc_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event)
+{
+ struct lcdc_crtc *lcdc_crtc = to_lcdc_crtc(crtc);
+ struct drm_device *dev = crtc-dev;
+
+ if (lcdc_crtc-event) {
+ dev_err(dev-dev, already pending page flip!\n);
+ return -EBUSY;
+ }
+
+ // TODO we should hold a ref to the fb somewhere..
Note that with the current fb refcounting nothing prevents you from
fixing this. The ugly problems I've had to solve for the locking
rework are all due to the drm core (i.e. setcrtc/pageflip/...) ioctl
functions assuming that an fb can't suddenly disappear while holding
the mode_config lock. Since I wanted to remove that requirement I've
had to changed the refcounting in the drm core functions.
But drivers can already extend the lifetime of an fb simply by
grabbing a reference (as long as they grab that reference while
holding the struct mutex all the time between fb lookup and grabbing
the reference). And it will continue to work the same with the new
locking scheme.
-Daniel
+ crtc-fb = fb;
+ lcdc_crtc-event = event;
+ update_scanout(crtc);
+
+ return 0;
+}
+
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: dts: Add PMU support for OMAP2+
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board. Boot tested only on OMAP2420 H4. Jon Hunter (2): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |6 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 ++ arch/arm/boot/dts/omap4460.dtsi | 18 ++ arch/arm/mach-omap2/pmu.c| 14 +++--- 5 files changed, 42 insertions(+), 3 deletions(-) create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.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 1/2] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/pmu.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..6e620eb 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -64,6 +64,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -76,9 +85,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.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 2/2] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
arch/arm/mach-omap2/pmu.c|2 ++
5 files changed, 33 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = arm,arm1136-pmu;
+ interrupts = 3;
+ };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = arm,cortex-a8-pmu;
+ interrupts = 3;
+ ti,hwmods = debugss;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ omap4-panda.dts
+/include/ omap4460.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..1270890
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupts = 0 54 0x4
+ 0 55 0x4;
+ ti,hwmods = debugss;
+ };
+};
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 6e620eb..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include linux/of.h
+
#include asm/pmu.h
#include soc.h
--
1.7.10.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 2/2] ARM: dts: OMAP2+: Add PMU nodes
On 12/14/2012 03:18 PM, Jon Hunter wrote:
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
arch/arm/mach-omap2/pmu.c|2 ++
5 files changed, 33 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = arm,arm1136-pmu;
+ interrupts = 3;
+ };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = arm,cortex-a8-pmu;
+ interrupts = 3;
+ ti,hwmods = debugss;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ omap4-panda.dts
+/include/ omap4460.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..1270890
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupts = 0 54 0x4
+ 0 55 0x4;
+ ti,hwmods = debugss;
+ };
+};
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 6e620eb..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include linux/of.h
+
Oops! I screwed something up here when rebasing. Resending this shortly ...
Jon
--
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
[RESEND PATCH 0/2] ARM: dts: Add PMU support for OMAP2+
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board. Boot tested only on OMAP2420 H4. Jon Hunter (2): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |6 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 ++ arch/arm/boot/dts/omap4460.dtsi | 18 ++ arch/arm/mach-omap2/pmu.c| 14 +++--- 5 files changed, 42 insertions(+), 3 deletions(-) create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.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
[RESEND PATCH 1/2] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include linux/of.h
+
#include asm/pmu.h
#include soc.h
@@ -64,6 +66,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -76,9 +87,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.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
[RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = arm,arm1136-pmu;
+ interrupts = 3;
+ };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = arm,cortex-a8-pmu;
+ interrupts = 3;
+ ti,hwmods = debugss;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ omap4-panda.dts
+/include/ omap4460.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..1270890
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupts = 0 54 0x4
+ 0 55 0x4;
+ ti,hwmods = debugss;
+ };
+};
--
1.7.10.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] ARM: dts: Add build target for omap4-panda-a4
Commit 0d9250c (ARM: dts: omap4-panda: Add pinmux configuration for HDMI) added a new device-tree source file for Rev A4 of the OMAP4430 Panda board but it did not add this version to the makefile. Hence, add this file to the makefile. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/boot/dts/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 2af359c..f8b4ff4 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -105,6 +105,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap3-evm.dtb \ omap3-tobi.dtb \ omap4-panda.dtb \ + omap4-panda-a4.dtb \ omap4-panda-es.dtb \ omap4-var-som.dtb \ omap4-sdp.dtb \ -- 1.7.10.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] ARM: dts: OMAP2420: Correct H4 board memory size
* Jon Hunter jon-hun...@ti.com [121214 12:37]:
The system memory node for the OMAP2420 H4 was incorrectly defined as
start address followed by end address, instead of start address and
size. No noticable side-effects were observed but fix this for
correctness.
Thanks applying into omap-for-v3.8/fixes-for-merge-window.
Tony
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 77b84e1..9b0d077 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -15,6 +15,6 @@
memory {
device_type = memory;
- reg = 0x8000 0x8400; /* 64 MB */
+ reg = 0x8000 0x400; /* 64 MB */
};
};
--
1.7.10.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] ARM: dts: Add build target for omap4-panda-a4
* Jon Hunter jon-hun...@ti.com [121214 13:58]: Commit 0d9250c (ARM: dts: omap4-panda: Add pinmux configuration for HDMI) added a new device-tree source file for Rev A4 of the OMAP4430 Panda board but it did not add this version to the makefile. Hence, add this file to the makefile. Thanks applying into omap-for-v3.8/fixes-for-merge-window. Tony Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/boot/dts/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 2af359c..f8b4ff4 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -105,6 +105,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap3-evm.dtb \ omap3-tobi.dtb \ omap4-panda.dtb \ + omap4-panda-a4.dtb \ omap4-panda-es.dtb \ omap4-var-som.dtb \ omap4-sdp.dtb \ -- 1.7.10.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] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 8, 2012 at 9:08 AM, Hiremath, Vaibhav hvaib...@ti.com wrote: No we do not have 32k_counter block in AM335x. If you are referring to 32Khz clock availability alone, then yes, we need to get persistent clock and we use RTC 32Khz clock source for it. But please note that this is not a 32k_counter block which OMAP family of devices has. The way AM335x works is, we have timers (0-7), timer0 being secure timer. We use timer1 and timer2 for clockevent and clocksource and they are driven by 26MHz OSC clock currently. So when you go into Low power state, OSC is turned off and you need persistent clock for time keeping, right? And only persistent clock available is RTC 32khz crystal clock, being RTC is in wakeup domain. RTC domain. -- 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: add pwm driver using dmtimers.
On Thu, 13 Dec 2012 11:42:18 -0600 Jon Hunter jon-hun...@ti.com wrote:
On 12/12/2012 10:33 PM, NeilBrown wrote:
On Thu, 13 Dec 2012 14:06:35 +1100 NeilBrown ne...@suse.de wrote:
+omap_dm_timer_enable(omap-dm_timer);
Do you need to call omap_dm_timer_enable here? _set_load and _set_match
will enable the timer. So this should not be necessary.
True. That is what you get for copying someone else's code and not
understanding it fully.
However omap_dm_timer_write_counter *doesn't* enable the timer, and
explicitly checks that it is already runtime-enabled.
Does that mean I don't need to call omap_dm_timer_write_counter here? Or
does it mean that I do need the enable/disable pair?
Typically, omap_dm_timer_write_counter() is used to update the counter
value while the counter is running and hence is enabled.
Looking at the code, some more I now see what they are trying to do. It
seems that they are trying to force an overflow to occur as soon as they
enable the timer. This will cause the timer to load the count value from
the timer load register into the timer counter register. So that does
make sense to me. However, this should not be necessary as
omap_dm_timer_set_load should do this for you. Therefore, I think that
you could accomplish the same thing by doing ...
omap_pwm_config
-- omap_dm_timer_set_load()
-- omap_dm_timer_set_match()
-- omap_dm_timer_set_pwm()
omap_pwm_enable
-- omap_dm_timer_start()
If we call _set_load in config then we don't need to call _load_start in
the enable, we can just call _start.
Can you try this and see if this is working ok?
Seems to work, and is much neater. Thanks.
Below is my current patch.
Unresolved issues are:
- it uses
omap_dm_timer_request_specific()
which apparently isn't ideal.
- It still zeros things in the suspend routine. I haven't explored this at
all yet
Thanks,
NeilBrown
From 69ed735d1bc377e8e65345792997f809e60b5fbf Mon Sep 17 00:00:00 2001
From: NeilBrown ne...@suse.de
Date: Sun, 2 Dec 2012 14:53:20 +1100
Subject: [PATCH] pwm: omap: Add PWM support using dual-mode timers
This patch is based on an earlier patch by Grant Erickson
which provided PWM devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Platform data must be provided to identify which dmtimer to use.
Lots of cleanup and inprovements thanks to Thierry Reding
and Jon Hunter.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..32c1253 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP PWM support
+ depends on ARCH_OMAP OMAP_DM_TIMER
+ help
+ Generic PWM framework driver for OMAP
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap
+
config PWM_PUV3
tristate PKUnity NetBook-0916 PWM support
depends on ARCH_PUV3
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..f5d200d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
new file mode 100644
index 000..344072c
--- /dev/null
+++ b/drivers/pwm/pwm-omap.c
@@ -0,0 +1,271 @@
+/*
+ *Copyright (c) 2012 NeilBrown ne...@suse.de
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.com
+ *
+ *Also based on pwm-samsung.c
+ *
+ *This program is free software; you can redistribute it and/or
+ *modify it under the terms of the GNU General Public License
+ *version 2 as published by the Free Software Foundation.
+ *
+ *Description:
+ * This file is the core OMAP support for the generic, Linux
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ */
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+#include linux/platform_data/omap-pwm.h
+
+#include plat/dmtimer.h
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct omap_chip {
+ struct omap_dm_timer*dm_timer;
+ enum pwm_polarity polarity;
+ unsigned intduty_ns, period_ns;
+ struct
Re: twl4030_charger seems to be broken by switch from 'notifier' to 'mailbox'.
On Fri, 14 Dec 2012 11:36:59 +0200 Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Dec 14, 2012 at 08:04:27PM +1100, NeilBrown wrote:
this commit:
commit c9721438c009adf8e81d376839ed037c53b9b8d9
Author: Kishon Vijay Abraham I kis...@ti.com
Date: Fri Jun 22 17:40:52 2012 +0530
usb: musb: twl: use mailbox API to send VBUS or ID events
The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID events,
is replaced by a direct call to omap musb blue.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Seems to have broken twl4030_charger.c.
This code relies on the notifier to know when the USB has been plugged in
and
so it should consider enabling the charger.
now that the notification has gone, the charger never turns on.
If I put the atomic_notifier_call_chain() calls back in, then the charger is
activated as appropriate.
What is the plan here? Should the calls go back, or is there some way for
twl4030_charger to hook into the mailbox? Or is there some other way it
should work?
hmmm, tricky situation. Maybe we add back the notifer calls but keep the
mailbox API ?
Maybe. This is my current patch. I'm not entirely confident about the
mapping from omap_musb_vbus_id_status to usb_phy_events.
Thanks,
NeilBrown
From ffafe1fe4da3c848631c082f70745017c03e23bf Mon Sep 17 00:00:00 2001
From: NeilBrown ne...@suse.de
Date: Sat, 15 Dec 2012 10:35:37 +1100
Subject: [PATCH] twl4030-usb - re-instate event notifications
commit c9721438c009adf8e81d376839ed037c53b9b8d9
usb: musb: twl: use mailbox API to send VBUS or ID events
went a bit too far in removing all event notification
from twl4030-usb. The notifications are still needed for
twl4030_charger.c to know when to enable the charger.
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index f0d2e75..15733f9 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -38,6 +38,7 @@
#include linux/i2c/twl.h
#include linux/regulator/consumer.h
#include linux/err.h
+#include linux/notifier.h
#include linux/slab.h
/* Register defines */
@@ -388,6 +389,28 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int
on)
}
}
+static void do_notify(struct twl4030_usb *twl,
+ enum omap_musb_vbus_id_status status)
+{
+ enum usb_phy_events event;
+
+ switch (status) {
+ case OMAP_MUSB_UNKNOWN:
+ event = USB_EVENT_NONE; break;
+ case OMAP_MUSB_ID_GROUND:
+ event = USB_EVENT_ID; break;
+ case OMAP_MUSB_ID_FLOAT:
+ event = USB_EVENT_NONE; break;
+ case OMAP_MUSB_VBUS_VALID:
+ event = USB_EVENT_VBUS; break;
+ case OMAP_MUSB_VBUS_OFF:
+ event = USB_EVENT_NONE; break;
+ }
+
+ atomic_notifier_call_chain(twl-phy.notifier, event,
+ twl-phy.otg-gadget);
+}
+
static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
{
if (twl-asleep)
@@ -514,6 +537,7 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
twl4030_phy_suspend(twl, 0);
else
twl4030_phy_resume(twl);
+ do_notify(twl, status);
omap_musb_mailbox(twl-linkstat);
}
@@ -537,6 +561,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
twl-asleep = 0;
}
+ do_notify(twl, status);
omap_musb_mailbox(twl-linkstat);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
@@ -634,6 +659,8 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
if (device_create_file(pdev-dev, dev_attr_vbus))
dev_warn(pdev-dev, could not create sysfs file\n);
+ ATOMIC_INIT_NOTIFIER_HEAD(twl-phy.notifier);
+
/* Our job is to use irqs and status from the power module
* to keep the transceiver disabled when nothing's connected.
*
signature.asc
Description: PGP signature
Re: [PATCH 1/2] spi: omap2: disable DMA requests before complete()
On Wed, 12 Dec 2012 10:45:59 +0200, Felipe Balbi ba...@ti.com wrote: No actual errors have been found for completing before disabling DMA request lines, but it just looks more semantically correct that on our DMA callback we quiesce the whole thing before stating transfer is finished. Signed-off-by: Felipe Balbi ba...@ti.com Applied, thanks. g. --- drivers/spi/spi-omap2-mcspi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index b610f52..68446db 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -298,10 +298,10 @@ static void omap2_mcspi_rx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master); struct omap2_mcspi_dma *mcspi_dma = mcspi-dma_channels[spi-chip_select]; - complete(mcspi_dma-dma_rx_completion); - /* We must disable the DMA RX request */ omap2_mcspi_set_dma_req(spi, 1, 0); + + complete(mcspi_dma-dma_rx_completion); } static void omap2_mcspi_tx_callback(void *data) @@ -310,10 +310,10 @@ static void omap2_mcspi_tx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master); struct omap2_mcspi_dma *mcspi_dma = mcspi-dma_channels[spi-chip_select]; - complete(mcspi_dma-dma_tx_completion); - /* We must disable the DMA TX request */ omap2_mcspi_set_dma_req(spi, 0, 0); + + complete(mcspi_dma-dma_tx_completion); } static void omap2_mcspi_tx_dma(struct spi_device *spi, -- 1.8.1.rc1.5.g7e0651a -- 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Wed, 12 Dec 2012 17:02:10 -0600, Jon Hunter jon-hun...@ti.com wrote: So looking at this today, here is what I see when comparing the registers ... omap2430 != omap2420 omap3430 != omap2430 omap3630 == omap3430 omap4430 != omap3430 omap4460 == omap4430 omap543x == omap4430 am335x != omap4430 Therefore, I believe that we need to have the following compatible strings ... ti,omap2420-gpmc ti,omap2430-gpmc ti,omap3430-gpmc (omap3430 omap3630) ti,omap4430-gpmc (omap4430 omap4460 omap543x) ti,am3352-gpmc (am335x devices) Probably worth adding a comment to the Documentation what should be used for which device. Yes, it is completely appropriate to add a comment to the documentation here so this doesn't get lost. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] spi: devicetree: add support for loopback mode
On Wed, 12 Dec 2012 10:46:00 +0200, Felipe Balbi ba...@ti.com wrote: there are a few spi master drivers which make use of that flag but there is no way to pass it through devicetree. This patch just creates a way to pass SPI_LOOP via devicetree. I don't understand how this would be useful since loopback mode is really just a test feature. Is there any reason to do loopback for something other than test? I think it would be better to add a sysfs or debugfs property to manipulate the SPI_LOOP flag from userspace. What do you think? g. Signed-off-by: Felipe Balbi ba...@ti.com --- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 ++ drivers/spi/spi.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 296015e..1949586 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-loopback- (optional) Empty property indicating device requires + loopback mode. If a gpio chipselect is used for the SPI slave the gpio number will be passed via the cs_gpio diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 3f1b9ee..6bcdc03 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) spi-mode |= SPI_CS_HIGH; if (of_find_property(nc, spi-3wire, NULL)) spi-mode |= SPI_3WIRE; + if (of_find_property(nc, spi-loopback, NULL)) + spi-mode |= SPI_LOOP; /* Device speed */ prop = of_get_property(nc, spi-max-frequency, len); -- 1.8.1.rc1.5.g7e0651a -- 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
[PATCH 1/1] ARM: dts: omap3-igep: remove VSIM regulator
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved the VSIM regulator definition to the twl4030.dtsi to avoid
duplication. A definition for the VSIM regulator was also present
on omap3-igep.dtsi which leads to the following build error:
DTC arch/arm/boot/dts/omap3-igep0020.dtb
DTC arch/arm/boot/dts/omap3-igep0030.dtb
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
ERROR (duplicate_label): Duplicate label 'vsim' on
/ocp/i2c@4807/twl@48/regulator-vsim and
/ocp/i2c@4807/twl@48/regulator@10
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [arch/arm/boot/dts/omap3-igep0020.dtb] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/boot/dts/omap3-igep0030.dtb] Error 2
make: *** [dtbs] Error 2
Since IGEP devices uses the same PMIC as Beagle boards, the VSIM
definition from twl4030.dtsi can be used.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..de708ca 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -43,12 +43,6 @@
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
- vsim: regulator@10 {
- compatible = ti,twl4030-vsim;
- regulator-min-microvolt = 180;
- regulator-max-microvolt = 300;
- };
-
twl_audio: audio {
compatible = ti,twl4030-audio;
codec {
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
