Re: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
* Paul Walmsley p...@pwsan.com [120608 06:33]: On Fri, 8 Jun 2012, Cousson, Benoit wrote: On 6/8/2012 3:11 AM, Paul Walmsley wrote: On Thu, 7 Jun 2012, Cousson, Benoit wrote: Indeed, what I did not mention is that potentially the whole device init should be done ondemand as well. Meaning the whole hwmod setup phase should be done only when the driver will probe the device. That means if no driver exists for an IP block, or if the driver isn't using PM runtime, the IP block won't be reset. And somehow we still are missing drivers in mainline. We also still have drivers that aren't yet PM runtime converted. No the point is still the same as before. You let the drivers do the job if they are there, and then do a pass at very late time during the boot process to handle the ones that were not probed by any driver. Ah, I see what you mean. Above you wrote that the the hwmod setup phase would be done only when the driver will probe the device. But you also mean that it should also be done for the remaining devices before starting userspace. At least you will avoid the enable - reset - idle - enable sequence we are doing right now for most of the active drivers when it is not necessary. It must not be widely known, but early reset was implemented intentionally. The goal was to keep any configuration damage from out-of-date or broken bootloaders or previous OSes to a minimum length of time during the boot process. These devices should get reset as the device drivers initialize. Some parts of course need to be initialized properly early like caches and DMA controller. I don't really have a huge problem with switching to a late reset, but there are disadvantages to it. I think the early reset actually has more disadvantages to it compared to driver reset. We don't see any errors when things go wrong, and we may even kill the only debug console in the reset process. We are already doing what Benoit describes with clocks where we only reset the unclaimed ones at late_initcall level, and that has proven to work well. 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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
* Paul Walmsley p...@pwsan.com [120608 18:35]: On Thu, 7 Jun 2012, Tony Lindgren wrote: Oh OK yeah makes sense as that's hwmod internal function. Then the driver specific part should use just void __iomem *base and use readl/writel and live under include/linux/platform_data/omap-usb.h. This sounds like something that might be flame-bait, since these functions aren't platform_data. They at least should be as both platform init code and the driver will potentially use these functions. How about putting these functions in arch/arm/plat-omap/include/plat? Drivers are able to include those files easily. We need to pretty much get rid of all those headers and make them driver specific for the multi-zimage support. Drivers should be arch independent, and whatever parts need to be shared between platform init code and drivers should follow the standard platform driver stuff. The other place would be just the standard driver include at somewhere like include/linux/usb/omap-usb.h etc. 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: [PATCHv2 07/12] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
Hi,
Few comments below on making the platform_data work better along
with other archs.
* Paul Walmsley p...@pwsan.com [120610 17:56]:
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
...
--- /dev/null
+++ b/include/linux/platform_data/aess.h
This should be include/linux/platform_data/omap-aess.h or similar as
there are other aess controllers too.
+/*
+ * AESS_AUTO_GATING_ENABLE_OFFSET: offset in bytes of the AESS IP
+ * block's AESS_AUTO_GATING_ENABLE__1 register from the IP block's
+ * base address
+ */
+#define AESS_AUTO_GATING_ENABLE_OFFSET 0x07c
+
+/* Register bitfields in the AESS_AUTO_GATING_ENABLE__1 register */
+#define AESS_AUTO_GATING_ENABLE_SHIFT0
Also these should be OMAP_AESS_AUTOGATING etc, or even better,
XYZ_AESS_AUTOGATING where XYZ is the type of the AESS controller.
+/**
+ * aess_enable_autogating - enable AESS internal autogating
+ * @oh: struct omap_hwmod *
+ *
+ * Enable internal autogating on the AESS. This allows the AESS to
+ * indicate that it is idle to the OMAP PRCM. Returns 0.
+ */
+static void aess_enable_autogating(void __iomem *base)
+{
+ u32 v;
+
+ /* Set AESS_AUTO_GATING_ENABLE__1.ENABLE to allow idle entry */
+ v = 1 AESS_AUTO_GATING_ENABLE_SHIFT;
+ writel(v, base + AESS_AUTO_GATING_ENABLE_OFFSET);
+}
This should be static inline function as it's in the header, and again
something like omap_aess_enable_autogating.
+/**
+ * hwmod_aess_preprogram - enable AESS internal autogating (called by hwmod)
+ * @oh: struct omap_hwmod *
+ *
+ * The AESS will not IdleAck to the PRCM until its internal autogating
+ * is enabled. Since internal autogating is disabled by default after
+ * AESS reset, we must enable autogating after the hwmod code resets
+ * the AESS. Returns 0.
+ */
+static int __maybe_unused hwmod_aess_preprogram(struct omap_hwmod *oh)
+{
+ void __iomem *va;
+
+ va = omap_hwmod_get_mpu_rt_va(oh);
+ if (!va)
+ return -EINVAL;
+
+ aess_enable_autogating(va);
+
+ return 0;
+}
Then this function should not be in this header, instead it should be a
static function somewhere in the omap hwmod code in some .c file. That's
because this header should only have omap aess specific driver code, no
hwmod code should be needed here.
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: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
Hi,
Similar comments to the asess patch on this one below.
* Paul Walmsley p...@pwsan.com [120610 17:57]:
--- /dev/null
+++ b/include/linux/platform_data/fsusb.h
This would be better as include/linux/platform_data/omap-usb.h.
+#include plat/omap_hwmod.h
This include should not be needed here if the hwmod function is
a static function in the some hwmod*.c file.
+/* HCCOMMANDSTATUS: the register offset of the HCCOMMANDSTATUS register */
+#define HCCOMMANDSTATUS 0x0008
+
+/* HCCOMMANDSTATUS_HCR: the bitmask of the host controller reset flag */
+#define HCCOMMANDSTATUS_HCR_MASK (1 0)
I think these already have standard defines in some OHCI header?
Felipe may be able to comment more on this?
+static int fsusb_reset_host_controller(const char *name, void __iomem *base)
+{
+ int i;
+
+ writel(HCCOMMANDSTATUS_HCR_MASK, base + HCCOMMANDSTATUS);
+
+ for (i = 0; i MAX_FSUSB_HCR_TIME; i++) {
+ if (!(readl(base + HCCOMMANDSTATUS) HCCOMMANDSTATUS_HCR_MASK))
+ break;
+ udelay(1);
+ }
+
+ if (i == MAX_FSUSB_HCR_TIME) {
+ pr_warn(%s: %s: host controller reset failed (waited %d
usec)\n,
+ __func__, name, MAX_FSUSB_HCR_TIME);
+ return -EBUSY;
+ }
+
+ return 0;
+}
This should be static inline int fsusb_reset_host_controller as it's
in a header.
+static int __maybe_unused hwmod_fsusb_preprogram(struct omap_hwmod *oh)
+{
+ void __iomem *va;
+
+ va = omap_hwmod_get_mpu_rt_va(oh);
+ if (!va)
+ return -EINVAL;
+
+ fsusb_reset_host_controller(oh-name, va);
+
+ return 0;
+}
And this too should be a static function in some hwmod*.c file.
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: OMAP2+: cpu: Add am33xx device under cpu_class_is_omap2
* Vaibhav Hiremath hvaib...@ti.com [120609 08:00]: Newly added AM33XX device falls under omap2 class, so make cpu_class_is_omap2() true for AM33XX (Add soc_is_am33xx() check). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 14f050f..5e36564 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -375,7 +375,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap44xx() || soc_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 I think this can be now simply !cpu_class_is_omap1() as there is a very slim chance that we'll ever be compiling omap1 and omap2+ together because of the different compiler flags needed. 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: omap: drop unused IRQ defines
* Felipe Balbi ba...@ti.com [120608 07:16]: twl[46]030 have been converted to sparse IRQ already, so we can remove the unused defines and drop some code from board-files. Nice :) drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words': include/linux/mtd/map.h:331:11: warning: 'r$x$0' may be used uninitialized in this function This one I don't know if it's been fixed. WARNING: drivers/mmc/host/built-in.o(.devinit.text+0x2fc): Section mismatch in reference from the function mmc_omap_probe() to the function .init.text:mmc_omap_new_slot() The function __devinit mmc_omap_probe() references a function __init mmc_omap_new_slot(). If mmc_omap_new_slot is only used by mmc_omap_probe then annotate mmc_omap_new_slot with a matching annotation. The MMC related should be fixed and queued up. fs/ubifs/dir.c: In function 'ubifs_rename': fs/ubifs/dir.c:972:15: warning: 'saved_nlink' may be used uninitialized in this function net/mac80211/mlme.c: In function 'ieee80211_prep_connection': net/mac80211/mlme.c:3017:19: warning: 'sta' may be used uninitialized in this function No idea about these. 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: OMAP2+: cpu: Add am33xx device under cpu_class_is_omap2
On 6/11/2012 12:08 PM, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120609 08:00]: Newly added AM33XX device falls under omap2 class, so make cpu_class_is_omap2() true for AM33XX (Add soc_is_am33xx() check). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 14f050f..5e36564 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -375,7 +375,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap44xx() || soc_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS0x24200024 I think this can be now simply !cpu_class_is_omap1() as there is a very slim chance that we'll ever be compiling omap1 and omap2+ together because of the different compiler flags needed. Regards, Tony Ok... Shall I submit patch with this change? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe 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+: cpu: Add am33xx device under cpu_class_is_omap2
* Vaibhav Hiremath hvaib...@ti.com [120610 23:49]: On 6/11/2012 12:08 PM, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120609 08:00]: Newly added AM33XX device falls under omap2 class, so make cpu_class_is_omap2() true for AM33XX (Add soc_is_am33xx() check). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 14f050f..5e36564 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -375,7 +375,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap44xx() || soc_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS0x24200024 I think this can be now simply !cpu_class_is_omap1() as there is a very slim chance that we'll ever be compiling omap1 and omap2+ together because of the different compiler flags needed. Regards, Tony Ok... Shall I submit patch with this change? Yes 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 0/3] ARM: OMAP2/3: DSS HWMOD fixes
Paul, Ping. These could be queued for the next merge window. Tomi On Thu, 2012-05-10 at 13:21 +0300, Tomi Valkeinen wrote: Hi, These patches fix DSS hwmod data related to sysc flags. I haven't seen any problem produced by these missing bits, but by looking at the TRM it's clear that they should be defined. However, applying these will cause additional warnings to show during boot: omap_hwmod: dss_dispc: softreset failed (waited 1 usec) omap_hwmod: dss_rfbi: softreset failed (waited 1 usec) Most likely the softreset fails even now, but as there's no check to verify it, no warnings are visible. I think the reason for the failing softreset is the same problem as we have on OMAP4: dss_core hwmod should be enabled before other dss hwmods can be enabled (and reset). Tomi Tomi Valkeinen (3): ARM: OMAP2/3: HWMOD: Add missing flags for dispc class ARM: OMAP2/3: HWMOD: Add missing flag for rfbi class ARM: OMAP3: HWMOD: Add omap_hwmod_class_sysconfig for dsi .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 ++- 3 files changed, 17 insertions(+), 3 deletions(-) signature.asc Description: This is a digitally signed message part
Re: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
On Sun, Jun 10, 2012 at 11:34:17PM -0700, Tony Lindgren wrote:
Hi,
Similar comments to the asess patch on this one below.
* Paul Walmsley p...@pwsan.com [120610 17:57]:
--- /dev/null
+++ b/include/linux/platform_data/fsusb.h
This would be better as include/linux/platform_data/omap-usb.h.
+#include plat/omap_hwmod.h
This include should not be needed here if the hwmod function is
a static function in the some hwmod*.c file.
+/* HCCOMMANDSTATUS: the register offset of the HCCOMMANDSTATUS register */
+#define HCCOMMANDSTATUS0x0008
+
+/* HCCOMMANDSTATUS_HCR: the bitmask of the host controller reset flag */
+#define HCCOMMANDSTATUS_HCR_MASK (1 0)
I think these already have standard defines in some OHCI header?
Felipe may be able to comment more on this?
Well, yeah... but it's defined on drivers/usb/host/ohci.h and it's
actually a structure:
| /*
| * This is the structure of the OHCI controller's memory mapped I/O region.
| * You must use readl() and writel() (in asm/io.h) to access these fields!!
| * Layout is in section 7 (and appendix B) of the spec.
| */
| struct ohci_regs {
| /* control and status registers (section 7.1) */
| __hc32 revision;
| __hc32 control;
| __hc32 cmdstatus;
| __hc32 intrstatus;
| __hc32 intrenable;
| __hc32 intrdisable;
|
| /* memory pointers (section 7.2) */
| __hc32 hcca;
| __hc32 ed_periodcurrent;
| __hc32 ed_controlhead;
| __hc32 ed_controlcurrent;
| __hc32 ed_bulkhead;
| __hc32 ed_bulkcurrent;
| __hc32 donehead;
|
| /* frame counters (section 7.3) */
| __hc32 fminterval;
| __hc32 fmremaining;
| __hc32 fmnumber;
| __hc32 periodicstart;
| __hc32 lsthresh;
|
| /* Root hub ports (section 7.4) */
| struct ohci_roothub_regs {
| __hc32 a;
| __hc32 b;
| __hc32 status;
| #define MAX_ROOT_PORTS15 /* maximum OHCI root hub ports
(RH_A_NDP) */
| __hc32 portstatus [MAX_ROOT_PORTS];
| } roothub;
|
| /* and optional legacy support registers (appendix B) at 0x0100 */
|
| } __attribute__ ((aligned(32)));
[...]
| /*
| * HcCommandStatus (cmdstatus) register masks
| */
| #define OHCI_HCR (1 0)/* host controller reset */
| #define OHCI_CLF (1 1)/* control list filled */
| #define OHCI_BLF (1 2)/* bulk list filled */
| #define OHCI_OCR (1 3)/* ownership change request */
| #define OHCI_SOC (3 16) /* scheduling overrun count */
+static int fsusb_reset_host_controller(const char *name, void __iomem
*base)
+{
+ int i;
+
+ writel(HCCOMMANDSTATUS_HCR_MASK, base + HCCOMMANDSTATUS);
+
+ for (i = 0; i MAX_FSUSB_HCR_TIME; i++) {
+ if (!(readl(base + HCCOMMANDSTATUS) HCCOMMANDSTATUS_HCR_MASK))
+ break;
+ udelay(1);
+ }
+
+ if (i == MAX_FSUSB_HCR_TIME) {
+ pr_warn(%s: %s: host controller reset failed (waited %d
usec)\n,
+ __func__, name, MAX_FSUSB_HCR_TIME);
+ return -EBUSY;
+ }
+
+ return 0;
+}
This should be static inline int fsusb_reset_host_controller as it's
in a header.
why is it even in a header ? Only hwmod_fsusb_preprogram() will use it
anyway.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
* Felipe Balbi ba...@ti.com [120611 00:19]: On Sun, Jun 10, 2012 at 11:34:17PM -0700, Tony Lindgren wrote: Hi, Similar comments to the asess patch on this one below. * Paul Walmsley p...@pwsan.com [120610 17:57]: --- /dev/null +++ b/include/linux/platform_data/fsusb.h This would be better as include/linux/platform_data/omap-usb.h. +#include plat/omap_hwmod.h This include should not be needed here if the hwmod function is a static function in the some hwmod*.c file. +/* HCCOMMANDSTATUS: the register offset of the HCCOMMANDSTATUS register */ +#define HCCOMMANDSTATUS 0x0008 + +/* HCCOMMANDSTATUS_HCR: the bitmask of the host controller reset flag */ +#define HCCOMMANDSTATUS_HCR_MASK (1 0) I think these already have standard defines in some OHCI header? Felipe may be able to comment more on this? Well, yeah... but it's defined on drivers/usb/host/ohci.h and it's actually a structure: OK I guess then the define is OK. This should be static inline int fsusb_reset_host_controller as it's in a header. why is it even in a header ? Only hwmod_fsusb_preprogram() will use it anyway. Well ideally it would be something that any OHCI driver can use for it's reset, and whatever bus code can also call to reset and idle for the unused devices that don't have the driver compiled in. Got any better suggestions where to place it? I could be a generic ohci_reset function in some header? I don't want to have driver specific code under arch/arm/*omap*/* as the bus level code should not need to know anything about the driver specific registers. 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: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
Hi, On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote: This should be static inline int fsusb_reset_host_controller as it's in a header. why is it even in a header ? Only hwmod_fsusb_preprogram() will use it anyway. Well ideally it would be something that any OHCI driver can use for it's reset, and whatever bus code can also call to reset and idle for the unused devices that don't have the driver compiled in. Got any better suggestions where to place it? I could be a generic ohci_reset function in some header? maybe create linux/usb/ohci.h ? Then, while doing that, move register definitions to this new header too... Something like: $ mv drivers/usb/host/ohci.h include/linux/usb/ $ sed -i 's/\ohci.h\/linux/usb/ohci.h/g' $(git ls-files) then add your ohci_reset() function... I don't want to have driver specific code under arch/arm/*omap*/* as the bus level code should not need to know anything about the driver specific registers. I see. -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
* Felipe Balbi ba...@ti.com [120611 00:55]: Hi, On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote: This should be static inline int fsusb_reset_host_controller as it's in a header. why is it even in a header ? Only hwmod_fsusb_preprogram() will use it anyway. Well ideally it would be something that any OHCI driver can use for it's reset, and whatever bus code can also call to reset and idle for the unused devices that don't have the driver compiled in. Got any better suggestions where to place it? I could be a generic ohci_reset function in some header? maybe create linux/usb/ohci.h ? Then, while doing that, move register definitions to this new header too... Something like: $ mv drivers/usb/host/ohci.h include/linux/usb/ $ sed -i 's/\ohci.h\/linux/usb/ohci.h/g' $(git ls-files) then add your ohci_reset() function... Hmm but then again it's pointless to export the all the ohci registers as that will lead to misuse outside drivers/usb.. Sounds like just defining the reset register is safest option here. I don't want to have driver specific code under arch/arm/*omap*/* as the bus level code should not need to know anything about the driver specific registers. I see. 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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
On Sun, 10 Jun 2012, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120608 06:33]: I don't really have a huge problem with switching to a late reset, but there are disadvantages to it. I think the early reset actually has more disadvantages to it compared to driver reset. We don't see any errors when things go wrong, and we may even kill the only debug console in the reset process. We are already doing what Benoit describes with clocks where we only reset the unclaimed ones at late_initcall level, and that has proven to work well. The difference though between the clock and the IP block init is that leaving the clocks on until later has no effect on system stability. The chip simply consumes more energy. But if the IP blocks are reset later, and the bootloader or previous OS gets some register settings wrong, there's a greater risk of system instability or unpredictable behavior during the boot process. I agree that it is probably easier to debug a late reset approach. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: changing DMA slave configuration API
On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote: I think it is a good idea. And I would like to extend it even a little bit. Do we have any users of peripheral to peripheral slave dma? IIRC that is not the case, or does anyone know of existence or plans for such a h/w? If not, lets junk the src/dst fields and keep burst, length, addr fields which point to the peripheral values. Alternatively if we need both, then we can't have union and Russell's idea seems good one :) We don't need the union whatever way that goes. The question over whether we have the src/dst fields is whether we want to support a different configuration for DMA_DEV_TO_MEM/DMA_MEM_TO_DEV without having to reconfigure the channel each time its direction is switched. Out of the following users: drivers/mmc/host/mmci.c drivers/spi/spi-pl022.c drivers/tty/serial/amba-pl011.c with amba-pl08x, I don't see any which set a different configuration depending on direction, and sa11x0 and OMAP DMA engine drivers only support one direction per channel. So, the question really comes down to whether we _want_ to support this, and how painful it would be to re-introduce this if we did need it. Maybe the right answer is to use the control command value to sort that out when we come to it. -- To unsubscribe from this list: send the line unsubscribe 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: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi Paul,
So why should getting rid of some *unused* data have any testing
overhead?
Your definition of 'unused' seems to be different than mine:
$ egrep -rn 'c(lk|)-clkdm' arch/arm/
arch/arm/mach-omap2/omap_hwmod.c:560: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:563: return clkdm_add_sleepdep(oh-_clk-clkdm,
init_oh-_clk-clkdm);
arch/arm/mach-omap2/omap_hwmod.c:584: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:587: return clkdm_del_sleepdep(oh-_clk-clkdm,
init_oh-_clk-clkdm);
I did have a look at these (which are part of _add/_del_initiator_dep()
functions) while I was working on $SUBJECT patch, and was not very sure
of what these functions are expected to do.
They check for a CLKDM_NO_AUTODEPS flag which is not defined across any
clockdomain data files across any OMAP2+ platform.
What it then means is they add a sleep/static dependency for the
modules/hwmods clkdm with mpu on *all* platforms.
The AUTODEPS on the other hand are needed only on OMAP3 I guess, and
AUTODEPS need a sleep/wakeup (Not just a sleep dependency that
the above functions add) dependency not just with MPU but also with
DSP, besides AUTODEPS are already handled very well in the clockdomain
framework for OMAP3.
arch/arm/mach-omap2/omap_hwmod.c:612: if (!oh-_clk-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:2998: if (!c-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:3001: return c-clkdm-pwrdm.ptr;
I have fixed some of these dereferencing in hwmod to derive a clkdm/
pwrdm for a given hwmod by giving a precedence to a clkdm directly
associated with the hwmod and if missing only then looking for
something through the clk route. What I did miss is to update the
OMAP2/3 hwmod data file for some of the clks from where I was removing
the clkdm assocaitions (There are about ~10 clocks from $SUBJECT patch
which figure in hwmod data files out of the 75 from which I get rid of
the clkdms pointers)
arch/arm/mach-omap2/clock.c:96: if (!clk-clkdm_name)
arch/arm/mach-omap2/clock.c:99: clkdm = clkdm_lookup(clk-clkdm_name);
arch/arm/mach-omap2/clock.c:102: clk-name,
clk-clkdm_name);
arch/arm/mach-omap2/clock.c:103:clk-clkdm = clkdm;
arch/arm/mach-omap2/clock.c:106: clkdm %s\n, clk-name,
clk-clkdm_name);
These are part of the init code to resolve clkdm_name into a clkdm
pointer.
arch/arm/mach-omap2/clock.c:292:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:293:clkdm_clk_disable(clk-clkdm,
clk);
arch/arm/mach-omap2/clock.c:332:if (clkdm_control clk-clkdm) {
arch/arm/mach-omap2/clock.c:333:ret =
clkdm_clk_enable(clk-clkdm, clk);
arch/arm/mach-omap2/clock.c:336: %d\n, clk-name,
clk-clkdm-name, ret);
arch/arm/mach-omap2/clock.c:354:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:355:clkdm_clk_disable(clk-clkdm,
clk);
These are only applicable for gate clocks.
arch/arm/mach-omap2/clock.c:441:if (clk-clkdm != NULL)
arch/arm/mach-omap2/clock.c:442:
pwrdm_state_switch(clk-clkdm-pwrdm.ptr);
This again part of disable unused clocks should also matter only for
gate clocks.
That is just the result of a casual grep, not even a code analysis.
Removing this data is not like removing some macros where one can get a
compiler error if they turn out to be needed. Problems with this ares
only likely to show up at runtime.
By the way, I hope you're testing the patches that you send to the lists,
at the very least to the minimal PM testing that I do that is documented
e.g. here:
http://www.pwsan.com/omap/bootlogs/20120508/prcm_devel_a_3.5__0135f6a04642c192bdf4b36e06937d3387e174ff/
yes, I am, atleast with the platforms that I have access to,
2430sdp/N800/3430sdp/3630beagle-xm/4430panda/4460panda.
I don't have any 35xxevm/3517evm/5912osk or cmt3517 platforms.
regards,
Rajendra
Otherwise the testing burden is just getting pushed to other people who
already have too much to do.
...
So to repeat myself on this:
1. The patch that removes some of the struct clk clkdm_name strings should
be part of or otherwise grouped with the CCF conversion patch series
2. The CCF conversion patch series needs to be fully PM-tested
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On 6/8/2012 9:10 PM, Hiremath, Vaibhav wrote: On Fri, Jun 08, 2012 at 01:33:46, Paul Walmsley wrote: Hi On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote: I couldn't finish my testing today, got into continuous meetings. No worries, I understand. Tomorrow, I will test it and update you on this. That would be great. I took a look at SPRUH73F and sure enough, at least one module (CONTROL) doesn't support smart-idle -- per Table 14-217 CONTROL Register Field Descriptions. I'd guess that the PRCM won't idle-req this IP block until the kernel is not running, so we might be able to get away with the existing approach; but the TRM also says: By definition, initiator may generate read/write transaction as long as it is out of IDLE state. Which pretty much matches my understanding too of the implicit interface contract here. So I think we'd better go back to the flag approach as implemented in this patch: http://www.spinics.net/lists/arm-kernel/msg176836.html The WBU 32k sync timer's behavior is what relies on quirks of the integration that are hard to identify via other means, so it seems to be safest to tag it explicitly. Paul, I tested it on AM335x platform just now, it booted up to the Linux prompt, but I am sure it is going to impact low power state usecases on AM33xx. Why are you sure about that? As explained to Paul, using the force-idle will do the same as smart-idle most of the time. So what power impact are you expecting? So, I also feel that, flag based approach should be used here. Why? Why adding a new flag to detect a condition that is already captured somewhere else? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
On Mon, Jun 11, 2012 at 01:03:42AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [120611 00:55]: Hi, On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote: This should be static inline int fsusb_reset_host_controller as it's in a header. why is it even in a header ? Only hwmod_fsusb_preprogram() will use it anyway. Well ideally it would be something that any OHCI driver can use for it's reset, and whatever bus code can also call to reset and idle for the unused devices that don't have the driver compiled in. Got any better suggestions where to place it? I could be a generic ohci_reset function in some header? maybe create linux/usb/ohci.h ? Then, while doing that, move register definitions to this new header too... Something like: $ mv drivers/usb/host/ohci.h include/linux/usb/ $ sed -i 's/\ohci.h\/linux/usb/ohci.h/g' $(git ls-files) then add your ohci_reset() function... Hmm but then again it's pointless to export the all the ohci registers as that will lead to misuse outside drivers/usb.. Sounds like just defining the reset register is safest option here. could be as well, but looks like we need to create linux/usb/ohci.h anyway... -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/6] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data
On 6/11/2012 6:50 AM, Paul Walmsley wrote: Hi Vaibhav, Afzal, Tony, On Mon, 21 May 2012, Paul Walmsley wrote: From: Vaibhav Hiremath hvaib...@ti.com Currently dummy voltage domain data is being created in order to succeed boot process, nothing has been done w.r.t actual hardware (voltage control). Also, hook up the AM33XX voltage domain to OMAP framework. I had to update this patch again for v3.5 to account for the lack of am33xx_init_early(). So now this patch has to add it (updated patch below). Paul, I think this is not required, since Tony has already accepted the patch which has this implementation (available on linux-omap/master). Please refer to the commit, commit 08f3098928c991560408e8c71d4af8b1a3ff2d67 Author: Afzal Mohammed af...@ti.com Date: Fri May 11 00:38:49 2012 +0530 ARM: OMAP2+: am33xx: Add AM335XEVM machine support Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe 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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
Hi Paul, On 6/11/2012 10:04 AM, Paul Walmsley wrote: On Sun, 10 Jun 2012, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120608 06:33]: I don't really have a huge problem with switching to a late reset, but there are disadvantages to it. I think the early reset actually has more disadvantages to it compared to driver reset. We don't see any errors when things go wrong, and we may even kill the only debug console in the reset process. We are already doing what Benoit describes with clocks where we only reset the unclaimed ones at late_initcall level, and that has proven to work well. The difference though between the clock and the IP block init is that leaving the clocks on until later has no effect on system stability. The chip simply consumes more energy. But if the IP blocks are reset later, and the bootloader or previous OS gets some register settings wrong, there's a greater risk of system instability or unpredictable behavior during the boot process. Mmm, I'm not convince by that. If we delay the PM init at the very last time, at least after the modules are properly reset and init, I do not think we will have more issues than today. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Current state of AM33xx patches
Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? I'm getting involved in a project that is based on a AM3352 and would like to provide help where necessary and wanted. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe 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 04/12] ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
The 32k sync timer IP block target idle modes are incorrect in the
hwmod data are incorrect.
Nit: Is there too many incorrect in this sentence?
The IP block does not support any
smart-idle modes. Update the data to reflect the correct modes.
This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson b-cous...@ti.com.
Thanks for taking care of that patch.
Benoit
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 484..6b0aedc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -393,8 +393,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_counter_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0004,
.sysc_flags = SYSC_HAS_SIDLEMODE,
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
To unsubscribe from this list: send the line unsubscribe 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: changing DMA slave configuration API
On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote:
On Sun, 2012-06-10 at 12:22 +0100, Russell King - ARM Linux wrote:
On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
2012/6/10 Russell King - ARM Linux li...@arm.linux.org.uk:
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a pain to have the source and destination parameters in
the dma_slave_config structure as separate elements; it means when you
want to extract them, you end up with code in DMA engine drivers like:
+ if (dir == DMA_DEV_TO_MEM) {
+ dev_addr = c-src_addr;
+ dev_width = c-src_addr_width;
+ burst = c-src_maxburst;
+ } else if (dir == DMA_MEM_TO_DEV) {
+ dev_addr = c-dst_addr;
+ dev_width = c-dst_addr_width;
+ burst = c-dst_maxburst;
+ }
If we redefine the structure as below, this all becomes more simple:
+ if (dir == DMA_DEV_TO_MEM)
+ cfg = c-dev_src;
+ else if (dir == DMA_MEM_TO_DEV)
+ cfg = c-dev_dst;
it seems that might mean an union in your dma_slave_cfg, but not
co-exitense of both?
No, I want both so it's possible to select between the two when preparing
a DMA slave transfer.
struct dma_slave_cfg {
+ union {
struct dma_dev_cfg dev_src;
struct dma_dev_cfg dev_dst;
}
bool device_fc;
};
If you do that, the union becomes pointless, and you might as well have:
struct dma_slave_cfg {
struct dma_dev_cfg dev;
bool device_fc;
};
instead.
Hi Russell,
I think it is a good idea. And I would like to extend it even a little
bit. Do we have any users of peripheral to peripheral slave dma?
Yes, IMX sdma does support such kind of transfer.
The driver still does not support it currently.
IIRC that is not the case, or does anyone know of existence or plans
for such a h/w?
i.MX5 and i.MX6.
If not, lets junk the src/dst fields and keep burst, length, addr fields
which point to the peripheral values.
Alternatively if we need both, then we can't have union and Russell's
idea seems good one :)
Russell's idea seems reasonable and we may want to support peripheral to
peripheral in the future.
Regards
Dong Aisheng
--
To unsubscribe from this list: send the line unsubscribe 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 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
It appears that the McPDM on OMAP4 can only receive its functional
clock from an off-chip source. This source is not guaranteed to be
present on the board, and when present, it is controlled by I2C. This
would introduce a board dependency to the early hwmod code which it
was not designed to handle. Also, neither the driver for this
off-chip clock provider nor the I2C code is available early in boot
when the hwmod code is attempting to enable and reset IP blocks. This
effectively makes it impossible to enable and reset this device during
hwmod init.
At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source. (This is true for almost
every IP block on the chip. As far as I know, McPDM is the only
exception.) If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state. Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.
And I guess, that's a good reason as well to let the driver managing the
reset during the probe for such IPs.
This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3613054..86fc513 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2091,6 +2091,18 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = mcpdm,
.class = omap44xx_mcpdm_hwmod_class,
.clkdm_name = abe_clkdm,
+ /*
+* It's suspected that the McPDM requires an off-chip main
+* functional clock, controlled via I2C.
Nit: Is it not suspected, it is a fact. The clock tree clearly indicate
that the mcpdm fclk is generated from the pad_clks.
The IP is a custom link for the Audio IC control / data. using the Audio
IC as a source clock is standard. Since that IP is done only for that
purpose, there is no optional clock path from the PRCM like it is the
case for the McASP / McBSP.
This IP block is
+* currently reset very early during boot, before I2C is
+* available, so it doesn't seem that we have any choice in
+* the kernel other than to avoid resetting it. XXX This is
+* really a hardware issue workaround: every IP block should
+* be able to source its main functional clock from either
+* on-chip or off-chip sources. McPDM seems to be the only
+* current exception.
I do not think this is the right place to put some complaint about the
HW :-).
I guess we should just describe the facts.
+*/
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
Could you please update the hints for this IP in the autogen scripts?
I added a comment attribute to add a custom comment on top of the flags
entry.
The latest branch is omap5430_for_3.6.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: cpu: Make cpu_class_is_omap2 true for all non-omap1 platforms
As omap1 and omap2 will never be compiled together, due to different compiler flags, so we can simply make cpu_class_is_omap2() = true, for all non-omap1 platforms. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 14f050f..6a42558 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -374,8 +374,7 @@ IS_OMAP_TYPE(3430, 0x3430) /* Macros to detect if we have OMAP1 or OMAP2 */ #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) -#define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) +#define cpu_class_is_omap2() !cpu_class_is_omap1() /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP2/3: hwmod data: add gpmc
Add gpmc hwmod and associated interconnect data
HWMOD_INIT_NO_RESET can be removed once kernel is updated to
configure GPMC for all peripherals. Currently many depend on
bootloader, this facility will be removed.
(feature-removal-schedule.txt will get updated in upcoming
gpmc series).
No reset is also required for smooth migration to gpmc driver;
approach being taken is to hold old interface until boards are
converted to use driver interface one-by-one. Till that time,
this flag is a must as old interface rely on bootloader
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: rebased to 3.5-rc1
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 43 +++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 53
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
arch/arm/mach-omap2/prcm-common.h |2 +
6 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a7640d1..b672e48 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -529,6 +529,15 @@ static struct omap_hwmod_addr_space
omap2420_counter_32k_addrs[] = {
{ }
};
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6800A000,
+ .pa_end = 0x6800AFFF,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave = omap2xxx_counter_32k_hwmod,
@@ -537,6 +546,14 @@ static struct omap_hwmod_ocp_if
omap2420_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2xxx_gpmc_hwmod,
+ .clk= core_l3_ck,
+ .addr = omap2420_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -580,6 +597,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__msdi1,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
+ omap2420_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4d72649..c84d0a9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -875,6 +875,15 @@ static struct omap_hwmod_addr_space
omap2430_counter_32k_addrs[] = {
{ }
};
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6E00,
+ .pa_end = 0x6E000FFF,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave = omap2xxx_counter_32k_hwmod,
@@ -883,6 +892,14 @@ static struct omap_hwmod_ocp_if
omap2430_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2xxx_gpmc_hwmod,
+ .clk= core_l3_ck,
+ .addr = omap2430_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -933,6 +950,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2430_l4_wkup__counter_32k,
+ omap2430_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 83eafd9..339fbad 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -176,6 +176,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
};
/*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE |
Re: Current state of AM33xx patches
From: Daniel Mack zon...@gmail.com Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? There is a wiki page [1] that is intended to provide a summary, but I'm confident it is not up-to-date. There is also some automated testing, but I'm not aware if any of the test results are public and I believe the coverage is fairly limited. Hopefully Carlos can chime in with any information about that. [1] http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x _Status I'm getting involved in a project that is based on a AM3352 and would like to provide help where necessary and wanted. Your help is really appreciated, so thanks in advance. Hopefully Vaibhav or Chase can reply with info about any particular subsystems that need either review or coding. Conversion to Device Tree is an on-going complex area where Vaibhav is contributing. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe 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] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Add one-register-per-pin type device tree based pinctrl driver.
Currently this driver only works on omap2+ series of processors,
where there is either an 8 or 16-bit padconf register for each pin.
Support for other similar pinmux controllers can be added.
Signed-off-by: Tony Lindgren t...@atomide.com
---
Here's this one updated, I renamed it from pinctrl-simple to pinctrl-single
to limit it to one-register-per-mux type MMIO controllers. The bindings
for mapping bits in random registers started looking a bit too complex for
this patch to solve. Hopefully this should also solve the issues of different
expectations of what simple means :)
---
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
new file mode 100644
index 000..21b183e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
@@ -0,0 +1,12 @@
+Pinctrl driver for omap2plus using pinctrl-single driver
+
+Required properties:
+- compatible: one of:
+ - ti,omap2420-padconf
+ - ti,omap2430-padconf
+ - ti,omap3-padconf
+ - ti,omap4-padconf
+
+All omaps starting with omap2 are using pinctrl-single driver for
+the padconf registers. See pinctrl-single.txt in this directory for
+more information.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
new file mode 100644
index 000..6a6abf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -0,0 +1,102 @@
+One-register-per-pin type device tree based pinctrl driver
+
+Required properties:
+- compatible : one of:
+ - pinctrl-single
+- reg : offset and length of the register set for the mux registers
+- pinctrl-single,register-width : pinmux register access width
+- pinctrl-single,function-mask : mask of allowed pinmux function bits
+- pinctrl-single,function-off : function off mode for disabled state
+- pinctrl-single,pinconf-mask : mask of allowed pinconf bits
+
+This driver uses the common pinctrl bindings as specified in the
+pinctrl-bindings.txt document in this directory.
+
+The pinctrl register offsets and default values are specified as pairs
+using pinctrl-single,pins. For example, setting uart2_rx pin on omap2plus
+can be done with:
+
+ pinctrl-single,pins = 0xdc 0x118;
+
+Where 0xdc is the offset from the pinctrl ioremapped area for the
+uart2_rx register, and 0x118 contains the desired default value for
+for the pin setting it to INPUT_PULLUP | MODE0. See the uart example and
+static board pins example below for more information.
+
+If you are concerned about the boot time, set up the static pins in
+the bootloader, and only set up selected pins as device tree entries.
+
+This driver assumes that there is only one register for each pin. If you
+have some pins with more complicated configuration, you can set up a separate
+hardware specific driver for those pins.
+
+Note that this driver tries to avoid understanding pin and function
+names because of the extra bloat they would cause especially in the
+omap2plus case. This driver just sets what is specified for the board
+in the .dts file. Further user space debugging tools can be developed
+to decipher the pin and function names using debugfs.
+
+Example:
+
+/* SoC common file, such as omap4.dtsi */
+
+/* first controller instance for pins in core domain */
+omap4_pmx_core: pinmux@4a100040 {
+ compatible = ti,omap4-padconf;
+ reg = 0x4a100040 0x0196;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 16;
+ pinctrl-single,function-mask = 0x7;
+ pinctrl-single,function-off = 0x;
+ pinctrl-single,pinconf-mask = 0xfff8;
+};
+
+/* second controller instance for pins in wkup domain */
+omap4_pmx_wkup: pinmux@4a31e040 {
+ compatible = ti,omap4-padconf;
+ reg = 0x4a31e040 0x0038;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 16;
+ pinctrl-single,function-mask = 0x7;
+ pinctrl-single,function-off = 0x;
+ pinctrl-single,pinconf-mask = 0xfff8;
+};
+
+
+/* board specific .dts file, such as omap4-sdp.dts */
+
+omap4_pmx_core {
+
+ /*
+* map all board specific static pins enabled by the pinctrl driver
+* itself during the boot (or just set them up in the bootloader)
+*/
+ pinctrl-names = default;
+ pinctrl-0 = board_pins;
+
+ board_pins: pinmux_board_pins {
+ pinctrl-single,pins =
+ 0x6c 0xf/* csi21_dx3 OUTPUT | MODE7 */
+ 0x6e 0xf/* csi21_dy3 OUTPUT | MODE7 */
+ 0x70 0xf/* csi21_dx4 OUTPUT | MODE7 */
+ 0x72 0xf/* csi21_dy4 OUTPUT | MODE7 */
+ ;
+ };
+
+ /* map uart2 pins */
+ uart2_pins: pinmux_uart2_pins {
[PATCH 0/5] OMAP3530evm misc fixes for linux-omap
These patches fix misc problems when reflash ti-omap3530evm for master branch on Linux-omap. Currently they have been tested on 3530evm but were not ack'ed. Most of them are the leftovers from the great original developers with my the latest updates for adapting to the current kernel, so I add you directly into SOB(If not proper, please let me know). The series is based upon the latest linux-omap master branch from Tony (3.5-rc1). Zumeng Chen (5): ARM: OMAP3EVM: Add NAND flash definition ARM: OMAP3EVM: Adding USB internal LDOs board file ARM: omap3evm: enable VBUS switch for EHCI tranceiver MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set Input: ads7846: set proper debounce time in driver level arch/arm/mach-omap2/board-omap3evm.c | 75 ++ drivers/input/touchscreen/ads7846.c |2 + drivers/mfd/omap-usb-host.c |4 +- 3 files changed, 80 insertions(+), 1 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/5] ARM: OMAP3EVM: Add NAND flash definition
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@gmail.com
---
arch/arm/mach-omap2/board-omap3evm.c | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..fef911d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -24,6 +24,10 @@
#include linux/leds.h
#include linux/interrupt.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl.h
@@ -43,6 +47,7 @@
#include plat/board.h
#include plat/usb.h
+#include plat/nand.h
#include common.h
#include plat/mcspi.h
#include video/omapdss.h
@@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] =
{
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
+static struct mtd_partition omap3evm_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = xloader-nand,
+ .offset = 0,
+ .size = 4*(SZ_128K),
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = uboot-nand,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 14*(SZ_128K),
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = params-nand,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2*(SZ_128K)
+ },
+ {
+ .name = linux-nand,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 40*(SZ_128K)
+ },
+ {
+ .name = jffs2-nand,
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND,
+ },
+};
+
static void __init omap3_evm_init(void)
{
struct omap_board_mux *obm;
@@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
}
usb_musb_init(musb_board_data);
usbhs_init(usbhs_bdata);
+ omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
+ARRAY_SIZE(omap3evm_nand_partitions));
+
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
omap3_evm_display_init();
--
1.7.5.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/5] ARM: OMAP3EVM: Adding USB internal LDOs board file
EHCI PHY requires these regulators:
EVM Rev =E -- VAUX2
EVM Rev E -- VUSB1V5, VUSB1V8
Adding USB internal LDOs (vusb1v5 vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.
But we need not to add vaux2 in twl4030_platform_data since it will
be added conditionally.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
arch/arm/mach-omap2/board-omap3evm.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index fef911d..7e5e18f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata
= {
};
#endif
+/* VAUX2 for USB */
+static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(VDD_CSIPHY1, omap3isp),/* OMAP ISP */
+ REGULATOR_SUPPLY(VDD_CSIPHY2, omap3isp),/* OMAP ISP */
+ REGULATOR_SUPPLY(hsusb1, ehci-omap.0),
+ {
+ .supply = vaux2,
+ }
+};
+
+static struct regulator_init_data omap3evm_vaux2 = {
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3evm_vaux2_supplies),
+ .consumer_supplies = omap3evm_vaux2_supplies,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
/* platform_data for children goes here */
.keypad = omap3evm_kp_data,
@@ -659,6 +683,9 @@ static void __init omap3_evm_init(void)
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
omap_hsmmc_init(mmc);
+ if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
+ omap3evm_twldata.vaux2 = omap3evm_vaux2;
+
omap3_evm_i2c_init();
omap_display_init(omap3_evm_dss_data);
--
1.7.5.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 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set
A typo fix for this cosmetic change and mute a failed message from
a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
drivers/mfd/omap-usb-host.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..9aaaf3c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
goto err_usbtll_p2_fck;
}
+#ifndef CONFIG_MACH_OMAP3EVM
+ /* for OMAP3 , the clk set parent fails */
if (is_ehci_phy_mode(pdata-port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
ret = clk_set_parent(omap-utmi_p1_fck,
omap-xclk60mhsp1_ck);
if (ret != 0)
@@ -726,6 +727,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
dev_err(dev, init_60m_fclk set parent
failed error:%d\n, ret);
}
+#endif
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, uhh);
if (!res) {
--
1.7.5.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 5/5] Input: ads7846: set proper debounce time in driver level
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
Signed-off-by: Syed Mohammed Khasim kha...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/input/touchscreen/ads7846.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..a82a5fb 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -61,6 +61,7 @@
/* this driver doesn't aim at the peak continuous sample rate */
#defineSAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after
*/)
+#defineDEBOUNCE_TIME 310 /* About 10 ms */
struct ts_event {
/*
@@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
}
ts-gpio_pendown = pdata-gpio_pendown;
+ gpio_set_debounce(pdata-gpio_pendown, DEBOUNCE_TIME);
} else {
dev_err(spi-dev, no get_pendown_state nor gpio_pendown?\n);
--
1.7.5.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: Current state of AM33xx patches
On 6/11/2012 2:58 PM, Daniel Mack wrote: Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? Daniel, We are in the process of submitting all baseport patches to the upstream, summary would be, Accepted: - Machine and low-level init code - Basic DT required for boot. - Voltagedomain, Powerdomain, clockdomain implementation Currently under work (already submitted multiple versions): - Clock Tree - HWMOD I do maintain wiki page which you should refer for any updates: http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status In order to get latest and greatest kernel to boot, you can use my repo: https://github.com/hvaibhav/am335x-linux Also, note that, currently there will be very minimal feature-set supported in the kernel, so not sure how much can be leveraged for production use-cases. I'm getting involved in a project that is based on a AM3352 and would like to provide help where necessary and wanted. That's great, help is always required and appreciated. Thanks, Vaibhav Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe 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/3] Prepare for GPMC driver conversion
Hi, Objective of this series is to make things easy for GPMC driver conversion series by separating out more things from driver conversion series. This series, 1. Unifies NAND platform initialization functions 2. Cleans up OneNAND platform code a little 3. Handles additional timings in Kernel This series is based on 3.5-rc1 made on top of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html Regards Afzal Afzal Mohammed (3): ARM: OMAP2+: nand: unify init functions ARM: OMAP2+: onenand: cleanup for gpmc driver conversion ARM: OMAP2+: gpmc: handle additional timings arch/arm/mach-omap2/board-devkit8000.c |8 +++-- arch/arm/mach-omap2/board-flash.c | 45 ++- arch/arm/mach-omap2/board-flash.h |6 ++-- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|4 +-- arch/arm/mach-omap2/board-omap3beagle.c|8 +++-- arch/arm/mach-omap2/board-omap3touchbook.c |8 +++-- arch/arm/mach-omap2/board-overo.c |7 +++-- arch/arm/mach-omap2/board-zoom.c |5 +-- arch/arm/mach-omap2/common-board-devices.c | 46 arch/arm/mach-omap2/common-board-devices.h |1 - arch/arm/mach-omap2/gpmc-onenand.c | 24 ++- arch/arm/mach-omap2/gpmc.c |6 arch/arm/plat-omap/include/plat/gpmc.h |6 14 files changed, 77 insertions(+), 99 deletions(-) -- 1.7.10.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: nand: unify init functions
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c |8 +++--
arch/arm/mach-omap2/board-flash.c | 45 ++-
arch/arm/mach-omap2/board-flash.h |6 ++--
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|4 +--
arch/arm/mach-omap2/board-omap3beagle.c|8 +++--
arch/arm/mach-omap2/board-omap3touchbook.c |8 +++--
arch/arm/mach-omap2/board-overo.c |7 +++--
arch/arm/mach-omap2/board-zoom.c |5 +--
arch/arm/mach-omap2/common-board-devices.c | 46
arch/arm/mach-omap2/common-board-devices.h |1 -
11 files changed, 56 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6567c1c..6ee429a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -59,8 +59,11 @@
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#defineNAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -628,8 +631,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..0ee820b 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -108,41 +108,41 @@ __init board_onenand_init(struct mtd_partition
*nor_parts, u8 nr_parts, u8 cs)
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
@@ -243,5 +243,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ partition_info[2].nr_parts, nandcs,
+ nand_type,
[PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot be
expect to work properly unless GPMC is setup, this has been
removed. Two instances of doing the same has been clubbed
into one as onenand driver always calls indirectly
omap2_onenand_set_sync_mode, and has placed such that
configuring onenand for async read/write would happen once
GPMC is setup for async mode (which happens even for sync
mode, before configuring to sync mode).
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 71d7c07..fd4c48d 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static int omap2_onenand_set_async_mode(int cs)
{
struct gpmc_timings t;
- u32 reg;
int err;
const int t_cer = 15;
@@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
return 0;
}
@@ -191,19 +181,21 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
u32 reg;
bool clk_dep = false;
+ /* Ensure sync read and sync write are disabled */
+ reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
+
if (cfg-flags ONENAND_SYNC_READ) {
sync_read = 1;
} else if (cfg-flags ONENAND_SYNC_READWRITE) {
sync_read = 1;
sync_write = 1;
} else
- return omap2_onenand_set_async_mode(cs, onenand_base);
+ return 0;
if (!freq) {
/* Very first call freq is not known */
- err = omap2_onenand_set_async_mode(cs, onenand_base);
- if (err)
- return err;
freq = omap2_onenand_get_freq(cfg, onenand_base, clk_dep);
first_time = 1;
}
@@ -421,6 +413,8 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_resource.end = gpmc_onenand_resource.start +
ONENAND_IO_SIZE - 1;
+ omap2_onenand_set_async_mode(gpmc_onenand_data-cs);
+
if (platform_device_register(gpmc_onenand_device) 0) {
pr_err(%s: Unable to register OneNAND device\n, __func__);
gpmc_cs_free(gpmc_onenand_data-cs);
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c |6 ++
arch/arm/plat-omap/include/plat/gpmc.h |6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 578fd4c..517953f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -313,6 +313,12 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
+
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..802fb22 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -128,6 +128,12 @@ struct gpmc_timings {
u16 rd_cycle; /* Total read cycle time */
u16 wr_cycle; /* Total write cycle time */
+ u16 bus_turnaround;
+ u16 cycle2cycle_delay;
+
+ u16 wait_monitoring;
+ u16 clk_activation;
+
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Current state of AM33xx patches
-Original Message- From: Jason Kridner [mailto:jkrid...@gmail.com] Sent: Monday, June 11, 2012 9:51 AM To: Daniel Mack; Tony Lindgren; Hilman, Kevin; Paul Walmsley; Hiremath, Vaibhav; Hernandez, Carlos; Maupin, Chase Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Kridner, Jason Subject: Re: Current state of AM33xx patches From: Daniel Mack zon...@gmail.com Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? There is a wiki page [1] that is intended to provide a summary, but I'm confident it is not up-to-date. There is also some automated testing, but I'm not aware if any of the test results are public and I believe the coverage is fairly limited. Hopefully Carlos can chime in with any information about that. Linux Nightly Test results are available at http://arago-project.org/testresults/linux/ Builds are currently failing due to wpa-supplicant recipe. The current nightly test plan includes: USB Host tests, PWM, Alsa, SPI, MMC, NAND, EDMA, Ethernet, RTC, I2C, PWM, WDT, CPUFREQ, Timers, Kernel IPC, Math library, LMBench and cyclictest. Let us know if you want other areas to be included in the nightly test plan. For a sample test coverage, check build from last week at http://arago-project.org/testresults/linux/ti-staging/2012-06-05_16-05-17/am335x-evm/test-log.html Carlos [1] http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335 x _Status I'm getting involved in a project that is based on a AM3352 and would like to provide help where necessary and wanted. Your help is really appreciated, so thanks in advance. Hopefully Vaibhav or Chase can reply with info about any particular subsystems that need either review or coding. Conversion to Device Tree is an on-going complex area where Vaibhav is contributing. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Input: ads7846: set proper debounce time in driver level
Hi,
This is input subsystem, add Dmitry and linux-input.
On 06/11/12 17:00, Zumeng Chen wrote:
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.
What about other non-OMAP platforms?
NULL pointer for board_pdata, only means that the default pdata is used.
Please, see the common-board-devices.c file more closely.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
Signed-off-by: Syed Mohammed Khasim kha...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/input/touchscreen/ads7846.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..a82a5fb 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -61,6 +61,7 @@
/* this driver doesn't aim at the peak continuous sample rate */
#define SAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after
*/)
+#define DEBOUNCE_TIME 310 /* About 10 ms */
I think hard coding this value is wrong.
Can't it be derived from the pdata-debounce_* fields?
struct ts_event {
/*
@@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
}
ts-gpio_pendown = pdata-gpio_pendown;
+ gpio_set_debounce(pdata-gpio_pendown, DEBOUNCE_TIME);
} else {
dev_err(spi-dev, no get_pendown_state nor gpio_pendown?\n);
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe 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 v5 00/14] GPMC driver conversion
Hi, This series is based on 3.5-rc1, and is dependent on [1,2,3] This series has been tested on omap3evm (smsc911x) rev G C and beagle board(nand) using patch series which is going to be posted shortly (this series only creates a driver out of GPMC code) Also using private patches, nand onenand was tested on omap3evm, rev G C respectively (as support for these were not in mainline) Many of GPMC peripherals depend on bootloader for configuration. This is going to be deprecated. feature-removal-schedule.txt will be updated in one of the upcoming patch series regarding the same. [PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be reverted once all GPMC peripherals are migrated to use driver interface. GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC details can be referred in AM335X Technical Reference Manual @ http://www.ti.com/lit/pdf/spruh73 Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html v5: Make this a purely driver conversion series, i.e. gpmc-mtd interactions has been made as a separate series, so is adding hwmod entry for OMAP2/3. And modifying gpmc peripheral platform initialization has been separated out of this series, so is migrating boards to use new driver interface. GPMC driver conversion which was done in a few patches in v4 has been tranformed to series of small patches. Also care has been taken care that old interface will not break with any of these patches, so both interfaces can coexist. This helps in converting boards one-by-one gradually. Acquiring CS has been thrown out. And conclusive comments on v4 has been addressed. v4: Handle wait pin (except for interrupts), enhance configuration timing interface of GPMC to take care of all boards. Dynamic allocation of interrupt instead of static. Convert remaining peripherals to work with GPMC driver. Handle acquiring NAND CS#, adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor commenst on v3. v3: Single device structure passed from platform for peripherals using multiple CS instead of using multiple device structure having a few redundant data, handle interrupts, GPMC NAND handling by GPMC NAND driver instead of GPMC driver v2: Avoid code movement that kept similar code together (for easy review) Afzal Mohammed (14): ARM: OMAP2+: gpmc: platform definitions ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP2+: gpmc: driver migration helper ARM: OMAP2+: gpmc: minimal driver support ARM: OMAP2+: gpmc: resource creation helpers ARM: OMAP2+: gpmc: CS configuration helper ARM: OMAP2+: gpmc: time setting (register#) helper ARM: OMAP2+: gpmc: bool type timing helper ARM: OMAP2+: gpmc: holler if no configuration ARM: OMAP2+: gpmc: waitpin helper ARM: OMAP2+: gpmc: handle connected peripherals ARM: OMAP2+: gpmc: cs reconfigure helper ARM: OMAP2+: gpmc: update nand register info ARM: OMAP2+: gpmc: writeprotect helper arch/arm/mach-omap2/gpmc.c | 817 ++-- arch/arm/plat-omap/include/plat/gpmc.h | 68 +++ 2 files changed, 842 insertions(+), 43 deletions(-) -- 1.7.10.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/14] ARM: OMAP2+: gpmc: platform definitions
gpmc driver platform definitions
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/gpmc.h | 49
1 file changed, 49 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 802fb22..21a8cce 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -139,6 +139,55 @@ struct gpmc_timings {
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
};
+/* bool type time settings */
+struct gpmc_misc_timings {
+ bool cycle2cyclediffcsen;
+ bool cycle2cyclesamecsen;
+ bool we_extra_delay;
+ bool oe_extra_delay;
+ bool adv_extra_delay;
+ bool cs_extra_delay;
+ bool time_para_granularity;
+};
+
+enum {
+ has_none,
+ has_period,
+ has_clock
+};
+
+struct gpmc_time_ctrl {
+ int type;
+ struct gpmc_timings timings;
+ struct gpmc_misc_timings bool_timings;
+};
+
+struct gpmc_cs_data {
+ unsignedcs;
+ unsigned long mem_size;
+ unsigned long mem_offset;
+ boolhave_config;
+ unsignedconfig;
+ struct gpmc_time_ctrl time_ctrl;
+ unsignedirq_config;
+};
+
+struct gpmc_device_pdata {
+ char*name;
+ int id;
+ void*pdata;
+ unsignedpdata_size;
+ struct resource *per_res;
+ unsignedper_res_cnt;
+ struct gpmc_cs_data *cs_data;
+ unsignednum_cs;
+};
+
+struct gpmc_pdata {
+ unsignednum_device;
+ struct gpmc_device_pdata**device_pdata;
+};
+
struct gpmc_nand_regs {
void __iomem*gpmc_status;
void __iomem*gpmc_nand_command;
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 31 +++
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 517953f..b471c2f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -27,6 +27,7 @@
#include asm/mach-types.h
#include plat/gpmc.h
+#include plat/omap_device.h
#include plat/sdrc.h
@@ -898,6 +899,36 @@ static int __init gpmc_init(void)
}
postcore_initcall(gpmc_init);
+__init int omap_gpmc_init(struct gpmc_pdata *pdata)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *name = omap-gpmc;
+ char *oh_name = gpmc;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(name, -1, oh, pdata,
+ sizeof(*pdata), NULL, 0, 0);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ gpmc_l3_clk = clk_get(NULL, oh-main_clk);
+ if (IS_ERR(gpmc_l3_clk)) {
+ pr_err(Could not get GPMC clock\n);
+ return PTR_ERR(gpmc_l3_clk);
+ }
+
+ return 0;
+}
+
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 21a8cce..698fa33 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -207,6 +207,8 @@ struct gpmc_nand_regs {
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
+extern int omap_gpmc_init(struct gpmc_pdata *pdata);
+
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/14] ARM: OMAP2+: gpmc: driver migration helper
A driver is being created out of GPMC code. This is being
attempted to acheive by not breaking existing interface,
necessitating requirement of GPMC peripherals being able
to work with as well as without the help of driver. To not
break existing, initcall is required as in old interface
GPMC is configured at arch initcall and GPMC should be
ready to handle old interface by that time
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index b471c2f..6dbddb9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -902,7 +902,7 @@ postcore_initcall(gpmc_init);
__init int omap_gpmc_init(struct gpmc_pdata *pdata)
{
struct omap_hwmod *oh;
- struct platform_device *pdev;
+ static struct platform_device *pdev;
char *name = omap-gpmc;
char *oh_name = gpmc;
@@ -912,6 +912,12 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
return -ENODEV;
}
+ if (pdev != NULL) {
+ clk_put(gpmc_l3_clk);
+ omap_device_delete(pdev-archdata.od);
+ platform_device_unregister(pdev);
+ }
+
pdev = omap_device_build(name, -1, oh, pdata,
sizeof(*pdata), NULL, 0, 0);
if (IS_ERR(pdev)) {
@@ -929,6 +935,17 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
return 0;
}
+static int __init gpmc_pre_init(void)
+{
+ static struct gpmc_device_pdata *gpmc_device_data[1];
+ struct gpmc_pdata gpmc_data = {
+ .device_pdata = gpmc_device_data,
+ };
+
+ return omap_gpmc_init(gpmc_data);
+}
+postcore_initcall(gpmc_pre_init);
+
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 170
1 file changed, 123 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6dbddb9..a91f40f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -24,6 +24,7 @@
#include linux/io.h
#include linux/module.h
#include linux/interrupt.h
+#include linux/platform_device.h
#include asm/mach-types.h
#include plat/gpmc.h
@@ -31,6 +32,8 @@
#include plat/sdrc.h
+#defineDRIVER_NAME omap-gpmc
+
/* GPMC register offsets */
#define GPMC_REVISION 0x00
#define GPMC_SYSCONFIG 0x10
@@ -115,6 +118,21 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
+struct gpmc_peripheral {
+ char*name;
+ int id;
+ void*pdata;
+ unsignedpdata_size;
+ struct resource *per_res;
+ unsignedper_res_cnt;
+ struct resource *gpmc_res;
+ unsignedgpmc_res_cnt;
+ boolhave_waitpin;
+ boolwaitpin_polarity;
+ unsignedwaitpin;
+ struct platform_device *pdev;
+};
+
static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
static struct irq_chip gpmc_irq_chip;
static unsigned gpmc_irq_start;
@@ -124,6 +142,10 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
+static struct device *gpmc_dev;
+static u32 gpmc_revision;
+static int gpmc_irq;
+static resource_size_t phys_base, mem_size;
static void __iomem *gpmc_base;
@@ -433,6 +455,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base,
unsigned long size)
return r;
}
+static int gpmc_cs_delete_mem(int cs)
+{
+ struct resource *res = gpmc_cs_mem[cs];
+ int r;
+
+ spin_lock(gpmc_mem_lock);
+ r = release_resource(gpmc_cs_mem[cs]);
+ res-start = res-end = 0;
+ spin_unlock(gpmc_mem_lock);
+
+ return r;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = gpmc_cs_mem[cs];
@@ -769,7 +804,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
-static int gpmc_setup_irq(int gpmc_irq)
+static int gpmc_setup_irq(void)
{
int i;
u32 regval;
@@ -813,7 +848,37 @@ static int gpmc_setup_irq(int gpmc_irq)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
}
-static void __init gpmc_mem_init(void)
+static __exit int gpmc_free_irq(void)
+{
+ int i;
+
+ if (gpmc_irq)
+ free_irq(gpmc_irq, NULL);
+
+ for (i = 0; i GPMC_NR_IRQ; i++) {
+ irq_set_handler(gpmc_client_irq[i].irq, NULL);
+ irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
+ irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
+ }
+
+ irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+
+ return 0;
+}
+
+static void __devexit gpmc_mem_exit(void)
+{
+ int cs;
+
+ for (cs = 0; cs GPMC_CS_NUM; cs++) {
+ if (!gpmc_cs_mem_enabled(cs))
+ continue;
+ gpmc_cs_delete_mem(cs);
+ }
+
+}
+
+static void __devinit gpmc_mem_init(void)
{
int cs;
unsigned long boot_rom_space = 0;
@@ -840,64 +905,75 @@ static void __init gpmc_mem_init(void)
}
}
-static int __init gpmc_init(void)
+static __devinit int gpmc_probe(struct platform_device *pdev)
{
u32 l;
- int ret = -EINVAL;
- int gpmc_irq;
- char *ck = NULL;
-
- if (cpu_is_omap24xx()) {
- ck = core_l3_ck;
- if (cpu_is_omap2420())
- l = OMAP2420_GPMC_BASE;
- else
- l = OMAP34XX_GPMC_BASE;
- gpmc_irq = INT_34XX_GPMC_IRQ;
- } else if (cpu_is_omap34xx()) {
- ck = gpmc_fck;
- l = OMAP34XX_GPMC_BASE;
- gpmc_irq = INT_34XX_GPMC_IRQ;
- } else if (cpu_is_omap44xx()) {
- ck = gpmc_ck;
- l = OMAP44XX_GPMC_BASE;
- gpmc_irq = OMAP44XX_IRQ_GPMC;
- }
+ struct resource *res;
- if (WARN_ON(!ck))
- return ret;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL)
+ return -ENOENT;
- gpmc_l3_clk = clk_get(NULL, ck);
- if (IS_ERR(gpmc_l3_clk)) {
- printk(KERN_ERR
[PATCH v5 05/14] ARM: OMAP2+: gpmc: resource creation helpers
Helpers for propulating given resource structure
with memory interrupt information.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a91f40f..652b245 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -905,6 +905,51 @@ static void __devinit gpmc_mem_init(void)
}
}
+static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data *cs,
+ struct resource *res)
+{
+ unsigned long start;
+ int ret;
+
+ ret = gpmc_cs_request(cs-cs, cs-mem_size, start);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(gpmc_dev, error: gpmc request on CS: %d\n, cs-cs);
+ return ret;
+ }
+
+ res-start = start + cs-mem_offset;
+ res-end = res-start + cs-mem_size - 1;
+ res-flags = IORESOURCE_MEM;
+
+ dev_info(gpmc_dev, memory 0x%x-0x%x on CS %d\n, res-start,
+ res-end, cs-cs);
+
+ return 1;
+}
+
+static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
+{
+ return bitmask;
+}
+
+static __devinit int gpmc_setup_cs_irq(struct gpmc_cs_data *cs,
+ struct resource *res)
+{
+ int i, n;
+
+ for (i = 0, n = 0; i GPMC_NR_IRQ; i++)
+ if (gpmc_bit_to_irq(gpmc_client_irq[i].bitmask)
+cs-irq_config) {
+ res[n].start = res[n].end = gpmc_client_irq[i].irq;
+ res[n].flags = IORESOURCE_IRQ;
+ dev_info(gpmc_dev, irq %u on CS %d\n,
+ res[n].start, cs-cs);
+ n++;
+ }
+
+ return n;
+}
+
static __devinit int gpmc_probe(struct platform_device *pdev)
{
u32 l;
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper
Helper for configuring given CS based on flags.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 33
arch/arm/plat-omap/include/plat/gpmc.h |5 +
2 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 652b245..4e19010 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -927,6 +927,39 @@ static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data
*cs,
return 1;
}
+static void gpmc_setup_cs_config(unsigned cs, unsigned conf)
+{
+ u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ l = ~(GPMC_CONFIG1_MUXADDDATA |
+ GPMC_CONFIG1_WRITETYPE_SYNC |
+ GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
+ GPMC_CONFIG1_READTYPE_SYNC |
+ GPMC_CONFIG1_READMULTIPLE_SUPP |
+ GPMC_CONFIG1_WRAPBURST_SUPP |
+ GPMC_CONFIG1_DEVICETYPE(~0) |
+ GPMC_CONFIG1_DEVICESIZE(~0) |
+ GPMC_CONFIG1_PAGE_LEN(~0));
+
+ l |= conf GPMC_CONFIG1_DEVICETYPE_NAND;
+ l |= conf GPMC_CONFIG1_DEVICESIZE_16;
+
+ if (conf GPMC_CONFIG1_PAGE_LEN_8)
+ l |= GPMC_CONFIG1_PAGE_LEN_8;
+ else if (conf GPMC_CONFIG1_PAGE_LEN_16)
+ l |= GPMC_CONFIG1_PAGE_LEN_16;
+
+ conf = (GPMC_CONFIG1_MUXADDDATA |
+ GPMC_CONFIG1_WRITETYPE_SYNC |
+ GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
+ GPMC_CONFIG1_READTYPE_SYNC |
+ GPMC_CONFIG1_READMULTIPLE_SUPP |
+ GPMC_CONFIG1_WRAPBURST_SUPP);
+ l |= conf;
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+}
+
static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
{
return bitmask;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 698fa33..ff3f32c 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -57,14 +57,19 @@
#define GPMC_CONFIG1_WRITETYPE_SYNC (1 27)
#define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val 3) 25)
#define GPMC_CONFIG1_PAGE_LEN(val) ((val 3) 23)
+#defineGPMC_CONFIG1_PAGE_LEN_4 GPMC_CONFIG1_PAGE_LEN(0)
+#defineGPMC_CONFIG1_PAGE_LEN_8 GPMC_CONFIG1_PAGE_LEN(1)
+#defineGPMC_CONFIG1_PAGE_LEN_16GPMC_CONFIG1_PAGE_LEN(2)
#define GPMC_CONFIG1_WAIT_READ_MON (1 22)
#define GPMC_CONFIG1_WAIT_WRITE_MON (1 21)
#define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val 3) 18)
#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val 3) 16)
#define GPMC_CONFIG1_DEVICESIZE(val)((val 3) 12)
+#defineGPMC_CONFIG1_DEVICESIZE_8 GPMC_CONFIG1_DEVICESIZE(0)
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
+#defineGPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2)
#define GPMC_CONFIG1_MUXADDDATA (1 9)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/14] ARM: OMAP2+: gpmc: time setting (register#) helper
Helper for setting GPMC timing by taking input as register values.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4e19010..e60076e3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -960,6 +960,49 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned
conf)
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
}
+static inline void gpmc_set_one_timing(int cs, int reg, int start,
+ int end, u32 val)
+{
+ u32 l;
+ unsigned mask;
+
+ mask = (1 (end - start + 1)) - 1;
+ l = gpmc_cs_read_reg(cs, reg);
+ l = ~(mask start);
+ l |= val start;
+ gpmc_cs_write_reg(cs, reg, l);
+}
+
+static void gpmc_cs_set_register_timings(int cs, const struct gpmc_timings *t)
+{
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG1, 0, 1, t-sync_clk);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG1, 18, 19, t-wait_monitoring);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG1, 25, 26, t-clk_activation);
+
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG2, 0, 3, t-cs_on);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG2, 8, 12, t-cs_rd_off);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG2, 16, 20, t-cs_wr_off);
+
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG3, 0, 3, t-adv_on);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG3, 8, 12, t-adv_rd_off);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG3, 16, 20, t-adv_wr_off);
+
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 0, 3, t-oe_on);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 8, 12, t-oe_off);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 16, 19, t-we_on);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 24, 28, t-we_off);
+
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG5, 24, 27, t-page_burst_access);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 0, 3, t-bus_turnaround);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 8, 11, t-cycle2cycle_delay);
+
+ if (gpmc_revision = 4) {
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 16, 19,
+ t-wr_data_mux_bus);
+ gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 24, 28, t-wr_access);
+ }
+}
+
static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
{
return bitmask;
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 08/14] ARM: OMAP2+: gpmc: bool type timing helper
Some of the timing configuration like extra delay
has bool type configurations. Provide a helper so
that these too can be configured in Kernel.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 55
1 file changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e60076e3..65052f8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -68,6 +68,13 @@
#define GPMC_ECC_CTRL_ECCREG8 0x008
#define GPMC_ECC_CTRL_ECCREG9 0x009
+#defineGPMC_CONFIG2_CSEXTRADELAY BIT(7)
+#defineGPMC_CONFIG3_ADVEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_OEEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_WEEXTRADELAY BIT(23)
+#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
+#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
+
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -960,6 +967,54 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned
conf)
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
}
+static void gpmc_cs_misc_timings(int cs, const struct gpmc_misc_timings *p)
+{
+ u32 l;
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ if (p-time_para_granularity)
+ l |= GPMC_CONFIG1_TIME_PARA_GRAN;
+ else
+ l = ~GPMC_CONFIG1_TIME_PARA_GRAN;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
+ if (p-cs_extra_delay)
+ l |= GPMC_CONFIG2_CSEXTRADELAY;
+ else
+ l = ~GPMC_CONFIG2_CSEXTRADELAY;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, l);
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
+ if (p-adv_extra_delay)
+ l |= GPMC_CONFIG3_ADVEXTRADELAY;
+ else
+ l = ~GPMC_CONFIG3_ADVEXTRADELAY;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, l);
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
+ if (p-oe_extra_delay)
+ l |= GPMC_CONFIG4_OEEXTRADELAY;
+ else
+ l = ~GPMC_CONFIG4_OEEXTRADELAY;
+ if (p-we_extra_delay)
+ l |= GPMC_CONFIG4_WEEXTRADELAY;
+ else
+ l = ~GPMC_CONFIG4_WEEXTRADELAY;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, l);
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG6);
+ if (p-cycle2cyclesamecsen)
+ l |= GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
+ else
+ l = ~GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
+ if (p-cycle2cyclediffcsen)
+ l |= GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
+ else
+ l = ~GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG6, l);
+}
+
static inline void gpmc_set_one_timing(int cs, int reg, int start,
int end, u32 val)
{
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/14] ARM: OMAP2+: gpmc: holler if no configuration
Some of the GPMC peripherals depend on bootloader to do the
configuration. This facility is deprecated, notify user
about the present GPMC settings inform that that relying
on bootloader for GPMC setting is deprecated.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 104
1 file changed, 104 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65052f8..5a6f708 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1058,6 +1058,110 @@ static void gpmc_cs_set_register_timings(int cs, const
struct gpmc_timings *t)
}
}
+static void gpmc_print_cs_config(int cs)
+{
+ u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ dev_warn(gpmc_dev, GPMC CS%d depends on bootloader for config\n, cs);
+ dev_warn(gpmc_dev, Please update it in Kernel ASAP to prevent losing
support for this peripheral\n);
+ dev_warn(gpmc_dev, Bootloader dependency for GPMC configuration is
deprecated\n);
+
+ dev_warn(gpmc_dev, muxadddata: %s\n,
+ l GPMC_CONFIG1_MUXADDDATA ? yes : no);
+ dev_warn(gpmc_dev, writetypesync: %s\n,
+ l GPMC_CONFIG1_WRITETYPE_SYNC ? yes : no);
+ dev_warn(gpmc_dev, writemultiple: %s\n,
+ l GPMC_CONFIG1_WRITEMULTIPLE_SUPP ? yes : no);
+ dev_warn(gpmc_dev, readtypesync: %s\n,
+ l GPMC_CONFIG1_READTYPE_SYNC ? yes : no);
+ dev_warn(gpmc_dev, readmultiple: %s\n,
+ l GPMC_CONFIG1_READMULTIPLE_SUPP ? yes : no);
+ dev_warn(gpmc_dev, wrapburst: %s\n,
+ l GPMC_CONFIG1_WRAPBURST_SUPP ? yes : no);
+ dev_warn(gpmc_dev, devicetype: %s\n,
+ l GPMC_CONFIG1_DEVICETYPE_NAND ? nand : nor);
+ dev_warn(gpmc_dev, devicesize: %d\n,
+ l GPMC_CONFIG1_DEVICESIZE_16 ? 16 : 8);
+ dev_warn(gpmc_dev, pagelength: %d\n,
+ l GPMC_CONFIG1_PAGE_LEN(~0) ?
+ (l GPMC_CONFIG1_PAGE_LEN_16 ? 16 : 8) : 4);
+}
+static inline unsigned gpmc_get_one_timing(int cs, int reg, int start, int end)
+{
+ u32 l = gpmc_cs_read_reg(cs, reg);
+ unsigned mask;
+
+ mask = (1 (end - start + 1)) - 1;
+ l = (mask start);
+ return l = start;
+}
+
+static void gpmc_print_cs_timings(int cs)
+{
+ dev_warn(gpmc_dev, GPMC CS%d depends on bootloader for timing\n, cs);
+ dev_warn(gpmc_dev, Please update it in Kernel ASAP to prevent losing
support for this peripheral\n);
+ dev_warn(gpmc_dev, Bootloader dependency for GPMC configuration is
deprecated\n);
+
+ dev_warn(gpmc_dev, fclk period: %lups\n, gpmc_get_fclk_period());
+ dev_warn(gpmc_dev, sync_clk: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 0, 1));
+ dev_warn(gpmc_dev, wait_monitoring: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 18, 19));
+ dev_warn(gpmc_dev, clk_activation: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 25, 26));
+ dev_warn(gpmc_dev, cs_on: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 0, 3));
+ dev_warn(gpmc_dev, cs_rd_off: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 8, 12));
+ dev_warn(gpmc_dev, cs_wr_off: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 16, 20));
+ dev_warn(gpmc_dev, adv_on: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 0, 3));
+ dev_warn(gpmc_dev, adv_rd_off: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 8, 12));
+ dev_warn(gpmc_dev, adv_wr_off: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 16, 20));
+ dev_warn(gpmc_dev, oe_on: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 0, 3));
+ dev_warn(gpmc_dev, oe_off: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 8, 12));
+ dev_warn(gpmc_dev, we_on: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 16, 19));
+ dev_warn(gpmc_dev, we_off: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 24, 28));
+ dev_warn(gpmc_dev, rd_cycle: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 0, 4));
+ dev_warn(gpmc_dev, wr_cycle: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 8, 12));
+ dev_warn(gpmc_dev, acess: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 16, 20));
+ dev_warn(gpmc_dev, page_burst_access: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 24, 27));
+ dev_warn(gpmc_dev, bus_turnaround: %u\n,
+ gpmc_get_one_timing(cs, GPMC_CS_CONFIG6, 0, 3));
+ dev_warn(gpmc_dev, cycle2cycle_delay: %u\n,
+
[PATCH v5 10/14] ARM: OMAP2+: gpmc: waitpin helper
Helper for configuring waitpin. There are two parts to it;
configuring at CS level and the other at device level.
A device embedding multiple CS has been provided the
capability to use same waitpin (different waitpins has not
been supported as presently there are no GPMC peripherals
doing so)
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 122
arch/arm/plat-omap/include/plat/gpmc.h |9 +++
2 files changed, 131 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5a6f708..9073a8a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -75,6 +75,8 @@
#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
+#defineGPMC_CONFIG_WAITPIN_POLARITY_SHIFT 0x8
+
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -93,6 +95,19 @@
*/
#defineGPMC_NR_IRQ 2
+enum {
+ GPMC_WAITPIN_IDX0,
+ GPMC_WAITPIN_IDX1,
+ GPMC_WAITPIN_IDX2,
+ GPMC_WAITPIN_IDX3,
+ GPMC_NR_WAITPIN
+};
+
+enum {
+ LOW,
+ HIGH
+};
+
struct gpmc_client_irq {
unsignedirq;
u32 bitmask;
@@ -140,6 +155,8 @@ struct gpmc_peripheral {
struct platform_device *pdev;
};
+static unsigned gpmc_waitpin_map;
+
static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
static struct irq_chip gpmc_irq_chip;
static unsigned gpmc_irq_start;
@@ -1162,6 +1179,62 @@ static void gpmc_print_cs_timings(int cs)
gpmc_get_one_timing(cs, GPMC_CS_CONFIG6, 7, 7));
}
+static int gpmc_setup_cs_waitpin(struct gpmc_peripheral *g_per, unsigned cs,
+ unsigned conf)
+{
+ unsigned idx;
+ bool polarity = 0;
+ u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ switch (conf GPMC_WAITPIN_MASK) {
+ case GPMC_WAITPIN_0:
+ idx = GPMC_WAITPIN_IDX0;
+ break;
+ case GPMC_WAITPIN_1:
+ idx = GPMC_WAITPIN_IDX1;
+ break;
+ case GPMC_WAITPIN_2:
+ idx = GPMC_WAITPIN_IDX2;
+ break;
+ case GPMC_WAITPIN_3:
+ idx = GPMC_WAITPIN_IDX3;
+ break;
+ /* no waitpin */
+ case 0:
+ return 0;
+ break;
+ default:
+ dev_err(gpmc_dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
+
+ polarity = !!(conf GPMC_WAITPIN_ACTIVE_HIGH);
+
+ if (g_per-have_waitpin) {
+ if (g_per-waitpin != idx ||
+ g_per-waitpin_polarity != polarity) {
+ dev_err(gpmc_dev, error: conflict: waitpin %u with
polarity %d on device %s.%d\n,
+ g_per-waitpin, g_per-waitpin_polarity,
+ g_per-name, g_per-id);
+ return -EBUSY;
+ }
+ } else {
+ g_per-have_waitpin = true;
+ g_per-waitpin = idx;
+ g_per-waitpin_polarity = polarity;
+ }
+
+ l |= conf GPMC_CONFIG1_WAIT_WRITE_MON;
+ l |= conf GPMC_CONFIG1_WAIT_READ_MON;
+ l = ~GPMC_CONFIG1_WAIT_PIN_SEL_MASK;
+ l |= GPMC_CONFIG1_WAIT_PIN_SEL(idx);
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+
+ return 0;
+}
+
static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
{
return bitmask;
@@ -1185,6 +1258,55 @@ static __devinit int gpmc_setup_cs_irq(struct
gpmc_cs_data *cs,
return n;
}
+static inline int gpmc_waitpin_is_reserved(unsigned waitpin)
+{
+ return gpmc_waitpin_map (0x1 waitpin);
+}
+
+static inline void gpmc_reserve_waitpin(unsigned waitpin)
+{
+ gpmc_waitpin_map = ~(0x1 waitpin);
+ gpmc_waitpin_map |= (0x1 waitpin);
+}
+
+static int gpmc_waitpin_request(unsigned waitpin)
+{
+ if (!(waitpin GPMC_NR_WAITPIN))
+ return -ENODEV;
+
+ if (gpmc_waitpin_is_reserved(waitpin))
+ return -EBUSY;
+ else
+ gpmc_reserve_waitpin(waitpin);
+
+ return 0;
+}
+
+static int gpmc_setup_waitpin(struct gpmc_peripheral *g_per)
+{
+ int ret;
+ u32 l, shift;
+
+ if (!g_per-have_waitpin)
+ return 0;
+
+ ret = gpmc_waitpin_request(g_per-waitpin);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(gpmc_dev, waitpin %u reserved\n, g_per-waitpin);
+ return ret;
+ }
+
+ l = gpmc_read_reg(GPMC_CONFIG);
+ shift = g_per-waitpin + GPMC_CONFIG_WAITPIN_POLARITY_SHIFT;
+ if (g_per-waitpin_polarity == HIGH)
+ l |= 1 shift;
+ else
+ l = ~(1 shift);
+ gpmc_write_reg(GPMC_CONFIG, l);
+
+ return 0;
+}
+
[PATCH v5 11/14] ARM: OMAP2+: gpmc: handle connected peripherals
Platform will provide driver with configuration details for
each CS like configuration, timing, interrupts. Setup GPMC
based on it. Platform data also provides platform data
resources used for connected peripheral (eg. gpio irq).
GPMC driver tunnels those information to respective driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 146
1 file changed, 146 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9073a8a..281bd23 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -155,6 +155,8 @@ struct gpmc_peripheral {
struct platform_device *pdev;
};
+static struct gpmc_peripheral gpmc_peripheral[GPMC_CS_NUM];
+static unsigned gpmc_num_peripheral;
static unsigned gpmc_waitpin_map;
static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
@@ -1235,6 +1237,39 @@ static int gpmc_setup_cs_waitpin(struct gpmc_peripheral
*g_per, unsigned cs,
return 0;
}
+static int gpmc_setup_cs_config_timing(struct gpmc_peripheral *g_per,
+ struct gpmc_cs_data *cs)
+{
+ int ret;
+
+ /* some boards rely on bootloader for configuration */
+ if (cs-have_config) {
+ gpmc_setup_cs_config(cs-cs, cs-config);
+ ret = gpmc_setup_cs_waitpin(g_per, cs-cs, cs-config);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(gpmc_dev, error: waitpin on CS %d\n, cs-cs);
+ return ret;
+ }
+ } else
+ gpmc_print_cs_config(cs-cs);
+
+ /* some boards rely on bootloader for timing */
+ if (cs-time_ctrl.type == has_period) {
+ ret = gpmc_cs_set_timings(cs-cs, cs-time_ctrl.timings);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(gpmc_dev, error: timing on CS: %d\n, cs-cs);
+ return ret;
+ }
+ gpmc_cs_misc_timings(cs-cs, cs-time_ctrl.bool_timings);
+ } else if (cs-time_ctrl.type == has_clock) {
+ gpmc_cs_set_register_timings(cs-cs, cs-time_ctrl.timings);
+ gpmc_cs_misc_timings(cs-cs, cs-time_ctrl.bool_timings);
+ } else
+ gpmc_print_cs_timings(cs-cs);
+
+ return 0;
+}
+
static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
{
return bitmask;
@@ -1307,10 +1342,100 @@ static int gpmc_setup_waitpin(struct gpmc_peripheral
*g_per)
return 0;
}
+static __devinit int gpmc_setup_cs(struct gpmc_peripheral *g_per,
+ struct gpmc_cs_data *cs, struct resource *res)
+{
+ int num, ret;
+
+ num = gpmc_setup_cs_mem(cs, res);
+ if (IS_ERR_VALUE(num))
+ return num;
+
+ ret = gpmc_setup_cs_config_timing(g_per, cs);
+ if (IS_ERR_VALUE(ret))
+ return ret;
+
+ num += gpmc_setup_cs_irq(cs, res + num);
+
+ return num;
+}
+
+static __devinit int gpmc_setup_device(struct gpmc_peripheral *g_per,
+ struct gpmc_device_pdata *gdp)
+{
+ int i, n, ret;
+ struct gpmc_cs_data *cs;
+
+ for (i = 0, n = gdp-num_cs, cs = gdp-cs_data;
+ i gdp-num_cs; i++, cs++)
+ n += hweight32(cs-irq_config);
+
+ g_per-gpmc_res = devm_kzalloc(gpmc_dev, sizeof(*g_per-gpmc_res) * n,
+ GFP_KERNEL);
+ if (g_per-gpmc_res == NULL) {
+ dev_err(gpmc_dev, error: memory allocation\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0, cs = gdp-cs_data, g_per-gpmc_res_cnt = 0;
+ i gdp-num_cs; cs++, i++) {
+ ret = gpmc_setup_cs(g_per, cs,
+ g_per-gpmc_res + g_per-gpmc_res_cnt);
+ if (IS_ERR_VALUE(ret) ||
+ IS_ERR_VALUE(gpmc_setup_waitpin(g_per))) {
+ dev_err(gpmc_dev, error: setup for %s\n, gdp-name);
+ devm_kfree(gpmc_dev, g_per-gpmc_res);
+ g_per-gpmc_res = NULL;
+ g_per-gpmc_res_cnt = 0;
+ return -EINVAL;
+ } else
+ g_per-gpmc_res_cnt += ret;
+ }
+
+ g_per-name = gdp-name;
+ g_per-id = gdp-id;
+ g_per-pdata = gdp-pdata;
+ g_per-pdata_size = gdp-pdata_size;
+ g_per-per_res = gdp-per_res;
+ g_per-per_res_cnt = gdp-per_res_cnt;
+
+ return 0;
+}
+
+static __devinit
+struct platform_device *gpmc_create_device(struct gpmc_peripheral *p)
+{
+ int num = p-per_res_cnt + p-gpmc_res_cnt;
+ struct resource *res;
+ struct platform_device *pdev;
+
+ res = devm_kzalloc(gpmc_dev, sizeof(struct resource) * num,
+ GFP_KERNEL);
+
[PATCH v5 12/14] ARM: OMAP2+: gpmc: cs reconfigure helper
Helper for reconfiguring CS, peripheral that necessitated
it was OneNAND.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 32
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 281bd23..d493a4c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1429,6 +1429,38 @@ struct platform_device *gpmc_create_device(struct
gpmc_peripheral *p)
return pdev;
}
+static int gpmc_match_device(char *name, int id)
+{
+ int i;
+ struct gpmc_peripheral *g_per = gpmc_peripheral;
+
+ for (i = 0; i gpmc_num_peripheral; i++, g_per++)
+ if (!strcmp(g_per-name, name) g_per-id == id)
+ return i;
+
+ return -ENOENT;
+}
+
+int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *c)
+{
+ int i;
+
+ i = gpmc_match_device(name, id);
+ if (IS_ERR_VALUE(i)) {
+ dev_err(gpmc_dev, no device %s.%d to configure\n, name, id);
+ return i;
+ }
+
+ if (IS_ERR_VALUE(gpmc_setup_cs_config_timing(gpmc_peripheral + i, c))) {
+ dev_err(gpmc_dev, error: configure device %s.%d\n, name, id);
+ return i;
+ }
+
+ return gpmc_setup_waitpin(gpmc_peripheral + i);
+
+}
+EXPORT_SYMBOL_GPL(gpmc_cs_reconfigure);
+
static __devinit int gpmc_probe(struct platform_device *pdev)
{
u32 l;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index e1b130c..32017a1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -247,6 +247,8 @@ extern int gpmc_cs_configure(int cs, int cmd, int wval);
extern int gpmc_nand_read(int cs, int cmd);
extern int gpmc_nand_write(int cs, int cmd, int wval);
+extern int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *c);
+
int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size);
int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code);
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 13/14] ARM: OMAP2+: gpmc: update nand register info
GPMC has dedicated NAND handling blocks and have a few
registers exclusively meant for NAND operations. These
registers can be handled by OMAP NAND driver as it is
meant for handling NAND on GPMC. Update OMAP NAND
platform data with GPMC-NAND register details so that
OMAP NAND driver can handle by itself instead of
relying on GPMC exported symbols.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c |9 -
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d493a4c..98b52c3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -28,6 +28,7 @@
#include asm/mach-types.h
#include plat/gpmc.h
+#include plat/nand.h
#include plat/omap_device.h
#include plat/sdrc.h
@@ -1500,12 +1501,18 @@ static __devinit int gpmc_probe(struct platform_device
*pdev)
dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
/* Traverse NULL terminated array of peripheral pointers and setup */
- for (gdq = gp-device_pdata, g_per = gpmc_peripheral; *gdq; gdq++)
+ for (gdq = gp-device_pdata, g_per = gpmc_peripheral; *gdq; gdq++) {
+ if ((*gdq)-is_nand) {
+ struct omap_nand_platform_data *p = (*gdq)-pdata;
+
+ gpmc_update_nand_reg(p-reg, p-cs);
+ }
if (IS_ERR_VALUE(gpmc_setup_device(g_per, *gdq)))
dev_err(gpmc_dev, gpmc setup on %s failed\n,
(*gdq)-name);
else
g_per++;
+ }
gpmc_num_peripheral = g_per - gpmc_peripheral;
for (l = 0, g_per = gpmc_peripheral;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 32017a1..32d7f3d 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -195,6 +195,7 @@ struct gpmc_device_pdata {
unsignedper_res_cnt;
struct gpmc_cs_data *cs_data;
unsignednum_cs;
+ boolis_nand;
};
struct gpmc_pdata {
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 14/14] ARM: OMAP2+: gpmc: writeprotect helper
GPMC has a writeprotect pin that can be connected to
peripherals. If any CS wants to enable writeprotect,
writeprotect will be enabled, once CS configurations
are finished.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 98b52c3..eec011a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -159,6 +159,7 @@ struct gpmc_peripheral {
static struct gpmc_peripheral gpmc_peripheral[GPMC_CS_NUM];
static unsigned gpmc_num_peripheral;
static unsigned gpmc_waitpin_map;
+static bool gpmc_writeprotect;
static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
static struct irq_chip gpmc_irq_chip;
@@ -976,6 +977,9 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned conf)
else if (conf GPMC_CONFIG1_PAGE_LEN_16)
l |= GPMC_CONFIG1_PAGE_LEN_16;
+ if (conf GPMC_CONFIG_WRITEPROTECT)
+ gpmc_writeprotect = true;
+
conf = (GPMC_CONFIG1_MUXADDDATA |
GPMC_CONFIG1_WRITETYPE_SYNC |
GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
@@ -1462,6 +1466,19 @@ int gpmc_cs_reconfigure(char *name, int id, struct
gpmc_cs_data *c)
}
EXPORT_SYMBOL_GPL(gpmc_cs_reconfigure);
+static inline void gpmc_setup_writeprotect(void)
+{
+ u32 l;
+
+ l = gpmc_read_reg(GPMC_CONFIG);
+ if (gpmc_writeprotect == true) {
+ l = ~GPMC_CONFIG_WRITEPROTECT;
+ dev_info(gpmc_dev, write protect enabled\n);
+ } else
+ l |= GPMC_CONFIG_WRITEPROTECT;
+ gpmc_write_reg(GPMC_CONFIG, l);
+}
+
static __devinit int gpmc_probe(struct platform_device *pdev)
{
u32 l;
@@ -1521,6 +1538,8 @@ static __devinit int gpmc_probe(struct platform_device
*pdev)
dev_err(gpmc_dev, device creation on %s failed\n,
g_per-name);
+ gpmc_setup_writeprotect();
+
return 0;
}
@@ -1531,6 +1550,7 @@ static __exit int gpmc_remove(struct platform_device
*pdev)
for (; gpmc_num_peripheral; g_per++, gpmc_num_peripheral--)
platform_device_unregister(g_per-pdev);
+ gpmc_writeprotect = false;
gpmc_waitpin_map = 0;
gpmc_free_irq();
gpmc_mem_exit();
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP3530evm misc fixes for linux-omap
On 06/11/2012 09:00 AM, Zumeng Chen wrote: These patches fix misc problems when reflash ti-omap3530evm for master branch on Linux-omap. Currently they have been tested on 3530evm but were not ack'ed. Most of them are the leftovers from the great original developers with my the latest updates for adapting to the current kernel, so I add you directly into SOB(If not proper, please let me know). I don't see any references to the original patches in the changelogs. If you have references you may wish to add them for historical purposes. Cheers 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
Re: [PATCH 1/5] ARM: OMAP3EVM: Add NAND flash definition
On 06/11/2012 09:00 AM, Zumeng Chen wrote:
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@gmail.com
I think that you need to have something in the changelog above, even if
this is a trivial change.
---
arch/arm/mach-omap2/board-omap3evm.c | 39
++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..fef911d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -24,6 +24,10 @@
#include linux/leds.h
#include linux/interrupt.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl.h
@@ -43,6 +47,7 @@
#include plat/board.h
#include plat/usb.h
+#include plat/nand.h
#include common.h
#include plat/mcspi.h
#include video/omapdss.h
@@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[]
= {
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
+static struct mtd_partition omap3evm_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = xloader-nand,
Is this the only non-volatile memory on the EVM? If so, you can probably
drop the -nand part from the name. Also, if you look at other board
files to be consistent in naming they use X-Loader.
+ .offset = 0,
+ .size = 4*(SZ_128K),
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = uboot-nand,
U-Boot
+ .offset = MTDPART_OFS_APPEND,
+ .size = 14*(SZ_128K),
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = params-nand,
U-Boot Env
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2*(SZ_128K)
+ },
+ {
+ .name = linux-nand,
Kernel
+ .offset = MTDPART_OFS_APPEND,
+ .size = 40*(SZ_128K)
+ },
+ {
+ .name = jffs2-nand,
File System
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND,
+ },
+};
+
static void __init omap3_evm_init(void)
{
struct omap_board_mux *obm;
@@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
}
usb_musb_init(musb_board_data);
usbhs_init(usbhs_bdata);
+ omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
+ ARRAY_SIZE(omap3evm_nand_partitions));
+
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
omap3_evm_display_init();
Cheers
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
Re: [PATCH] omap2+: add drm device
Tomi, So at this point, are you OK with deferring a split of the DMM until it necessary to do so (if ever)? I'd like to get this patch in so that people have a working omapdrm device when they enable the config options. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set
On 06/11/2012 09:00 AM, Zumeng Chen wrote:
A typo fix for this cosmetic change and mute a failed message from
a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
drivers/mfd/omap-usb-host.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..9aaaf3c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
goto err_usbtll_p2_fck;
}
+#ifndef CONFIG_MACH_OMAP3EVM
+ /* for OMAP3 , the clk set parent fails */
if (is_ehci_phy_mode(pdata-port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
ret = clk_set_parent(omap-utmi_p1_fck,
omap-xclk60mhsp1_ck);
if (ret != 0)
This begs the question, why is port_mode[0] set to ehci phy mode if this
is failing? Something does not seem right here but this does not look
like the right fix.
Cheers
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
Re: [PATCH] omap2+: add drm device
On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote: Tomi, So at this point, are you OK with deferring a split of the DMM until it necessary to do so (if ever)? I'd like to get this patch in so that people have a working omapdrm device when they enable the config options. Yes, I'm ok with it. Tomi signature.asc Description: This is a digitally signed message part
[PATCH 0/9] Adapt GPMC peripherals, platforms to driver
Hi, This series provides new interface for GPMC peripherals that use helper functions for initialization and configures omap3evm beagleboard GPMC in Kernel. Existing interface would continue to serve its purpose as before. New interface for smsc911x has been provided the runtime timing calculation capability. This had to be tested on different boards. omap3evm has been converted to use this new smsc911x runtime calculation capability, thus is being configured in Kernel. beagleboard nand has been modified to use new interface in addition to making use of runtime calculation, and is being configured in Kernel This series is based on 3.5-rc1, and is dependent on [1,2,3,4] and has been tested on omap3evm (smsc911x) rev G C and beagle board(nand) Also using private patches, nand onenand was tested on omap3evm, rev G C respectively (as support for these were not in mainline) omap3evm beagleboard are the two boards that could be tested here. Within a couple of days, series for converting other boards (but which can't be tested) would be posted (unless there are strong objections to the way these patch series are going) along with updation of feature-removal-schedule.txt regarding deprecation of GPMC bootloader dependency (feature-removal-schedule.txt patch would make sense only with the modification of remaining boards to work gpmc driver) Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html [4] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69897.html Afzal Mohammed (9): ARM: OMAP2+: gpmc-nand: Adapt to use gpmc driver ARM: OMAP2+: gpmc-onenand: Adapt to use gpmc driver ARM: OMAP2+: flash: Adapt to use gpmc driver ARM: OMAP2+: gpmc-tusb6010: Adapt to use gpmc driver ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver ARM: OMAP2+: gpmc-smsc911x: Adapt to use gpmc driver ARM: OMAP2+: gpmc-smsc911x: runtime time calculation ARM: OMAP2+: board omap3evm: use gpmc driver ARM: OMAP2+: board omap3beagle: use gpmc driver arch/arm/mach-omap2/board-flash.c | 126 +++ arch/arm/mach-omap2/board-flash.h | 29 ++ arch/arm/mach-omap2/board-omap3beagle.c | 16 ++- arch/arm/mach-omap2/board-omap3evm.c| 12 ++- arch/arm/mach-omap2/gpmc-nand.c | 41 arch/arm/mach-omap2/gpmc-onenand.c | 117 ++--- arch/arm/mach-omap2/gpmc-smc91x.c | 69 +++-- arch/arm/mach-omap2/gpmc-smsc911x.c | 119 + arch/arm/mach-omap2/usb-tusb6010.c | 113 +++- arch/arm/plat-omap/include/plat/gpmc-smc91x.h | 12 ++- arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 25 - arch/arm/plat-omap/include/plat/gpmc.h |8 ++ arch/arm/plat-omap/include/plat/nand.h |7 ++ arch/arm/plat-omap/include/plat/onenand.h |8 +- 14 files changed, 662 insertions(+), 40 deletions(-) -- 1.7.10.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] ARM: OMAP2+: gpmc-nand: Adapt to use gpmc driver
Currently gpmc is configured in platform for nand. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 41
arch/arm/plat-omap/include/plat/nand.h |7 ++
2 files changed, 48 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 045596a..13248d7 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,6 +21,20 @@
#include plat/board.h
#include plat/gpmc.h
+static struct gpmc_cs_data gpmc_nand_cs_info = {
+ .have_config= true,
+ .config = GPMC_CONFIG1_DEVICETYPE_NAND,
+ .irq_config = GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT,
+};
+
+static struct gpmc_device_pdata gpmc_nand_info = {
+ .name = omap2-nand,
+ .id = 0,
+ .cs_data= gpmc_nand_cs_info,
+ .num_cs = 1,
+ .is_nand= true,
+};
+
static struct resource gpmc_nand_resource[] = {
{
.flags = IORESOURCE_MEM,
@@ -76,6 +90,13 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+ /* gpmc driver interface being used */
+ if (gpmc_nand_info.pdata != NULL) {
+ gpmc_nand_cs_info.time_ctrl.type = has_period;
+ gpmc_nand_cs_info.time_ctrl.timings = t;
+ return 0;
+ }
+
/* Configure GPMC */
if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 1);
@@ -139,3 +160,23 @@ out_free_cs:
return err;
}
+
+struct gpmc_device_pdata *
+__init gpmc_nand_update(struct omap_nand_platform_data *gpmc_nand_data)
+{
+ gpmc_nand_info.pdata = gpmc_nand_data;
+ gpmc_nand_info.pdata_size = sizeof(*gpmc_nand_data);
+
+ gpmc_nand_cs_info.cs = gpmc_nand_data-cs;
+ gpmc_nand_cs_info.mem_size = NAND_IO_SIZE;
+
+ if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
+ gpmc_nand_cs_info.config |= GPMC_CONFIG1_DEVICESIZE_16;
+ if (gpmc_nand_data-dev_ready)
+ gpmc_nand_cs_info.config |= GPMC_CONFIG1_WAIT_READ_MON |
+ GPMC_CONFIG1_WAIT_WRITE_MON;
+
+ omap2_nand_gpmc_retime(gpmc_nand_data);
+
+ return gpmc_nand_info;
+}
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 290cef5..27700e1 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -36,9 +36,16 @@ struct omap_nand_platform_data {
#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
extern int gpmc_nand_init(struct omap_nand_platform_data *d);
+struct gpmc_device_pdata *
+gpmc_nand_update(struct omap_nand_platform_data *gpmc_nand_data);
#else
static inline int gpmc_nand_init(struct omap_nand_platform_data *d)
{
return 0;
}
+static inline struct gpmc_device_pdata *
+gpmc_nand_update(struct omap_nand_platform_data *gpmc_nand_data)
+{
+ return NULL;
+};
#endif
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: OMAP2+: flash: Adapt to use gpmc driver
Currently gpmc is configured in platform for various flash
devices. As gpmc driver is now present, populate details
needed for the driver to configure gpmc, gpmc driver would
configure based on this information. Old interface has been
left as is so that platforms can continue configuring gpmc
using old interface too. This is done so that driver
conversion can be done gradually without breaking any.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-flash.c | 126 +
arch/arm/mach-omap2/board-flash.h | 29 +
2 files changed, 155 insertions(+)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0ee820b..f3be964 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -53,6 +53,15 @@ static struct platform_device board_nor_device = {
.resource = board_nor_resource,
};
+static struct gpmc_cs_data gpmc_nor_cs_data;
+
+static struct gpmc_device_pdata gpmc_nor_data = {
+ .name = physmap-flash,
+ .id = 0,
+ .cs_data= gpmc_nor_cs_data,
+ .num_cs = 1,
+};
+
static void
__init board_nor_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
{
@@ -81,6 +90,25 @@ __init board_nor_init(struct mtd_partition *nor_parts, u8
nr_parts, u8 cs)
pr_err(Unable to register NOR device\n);
}
+static __init struct gpmc_device_pdata *
+gpmc_nor_update(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
+{
+ board_nor_data.parts= nor_parts;
+ board_nor_data.nr_parts = nr_parts;
+
+ gpmc_nor_cs_data.cs = cs;
+
+ if (omap_rev() = OMAP3430_REV_ES1_0)
+ gpmc_nor_cs_data.mem_size = FLASH_SIZE_SDPV2;
+ else
+ gpmc_nor_cs_data.mem_size = FLASH_SIZE_SDPV1;
+
+ gpmc_nor_data.pdata = board_nor_data;
+ gpmc_nor_data.pdata_size = sizeof(board_nor_data);
+
+ return gpmc_nor_data;
+}
+
#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
static struct omap_onenand_platform_data board_onenand_data = {
@@ -97,6 +125,16 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
+
+struct omap_onenand_platform_data * __init
+board_onenand_update(struct mtd_partition *onenand_parts, u8 nr_parts, u8 cs)
+{
+ board_onenand_data.cs = cs;
+ board_onenand_data.parts= onenand_parts;
+ board_onenand_data.nr_parts = nr_parts;
+
+ return board_onenand_data;
+}
#else
void
__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
@@ -148,6 +186,19 @@ __init board_nand_init(struct mtd_partition *nand_parts,
u8 nr_parts, u8 cs,
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
+
+struct omap_nand_platform_data *
+__init board_nand_update(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
+{
+ board_nand_data.cs = cs;
+ board_nand_data.parts = nand_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
+
+ return board_nand_data;
+}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
/**
@@ -246,3 +297,78 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
partition_info[2].nr_parts, nandcs,
nand_type, nand_default_timings);
}
+
+struct gpmc_device_pdata __init **board_flash_update(
+ struct flash_partitions partition_info[],
+ char chip_sel_board[][GPMC_CS_NUM],
+ int nand_type,
+ struct gpmc_device_pdata **gpmc_data)
+{
+ u8 cs = 0;
+ u8 norcs = GPMC_CS_NUM + 1;
+ u8 nandcs = GPMC_CS_NUM + 1;
+ u8 onenandcs = GPMC_CS_NUM + 1;
+ u8 idx;
+ unsigned char *config_sel = NULL;
+
+ if (gpmc_data == NULL) {
+ pr_err(%s: NULL arguement passed\n, __func__);
+ return NULL;
+ }
+
+ idx = get_gpmc0_type();
+ if (idx = MAX_SUPPORTED_GPMC_CONFIG) {
+ pr_err(%s: Invalid chip select: %d\n, __func__, cs);
+ return gpmc_data;
+ }
+ config_sel = (unsigned char *)(chip_sel_board[idx]);
+
+ while (cs GPMC_CS_NUM) {
+ switch (config_sel[cs]) {
+ case PDC_NOR:
+ if (norcs GPMC_CS_NUM)
+ norcs = cs;
+ break;
+ case PDC_NAND:
+ if (nandcs GPMC_CS_NUM)
+
[PATCH 4/9] ARM: OMAP2+: gpmc-tusb6010: Adapt to use gpmc driver
Currently gpmc is configured in platform for tusb6010. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 113 +++-
arch/arm/plat-omap/include/plat/gpmc.h |8 +++
2 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index db84a46..0e17337 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -22,9 +22,26 @@
#include mux.h
+#defineCS_ASYNC_IDX0
+#defineCS_SYNC_IDX 1
+#defineCS_NUM 2
+
static u8 async_cs, sync_cs;
static unsignedrefclk_psec;
+static struct resource tusb_resource = {
+ .name = mc,
+ .flags = IORESOURCE_IRQ,
+};
+
+static struct gpmc_cs_data gpmc_tusb_cs_data[CS_NUM];
+
+static struct gpmc_device_pdata gpmc_tusb_data = {
+ .name = musb-tusb,
+ .id = -1,
+ .per_res= tusb_resource,
+ .per_res_cnt= 1,
+};
/* t2_ps, when quantized to fclk units, must happen no earlier than
* the clock after after t1_NS.
@@ -106,7 +123,14 @@ static int tusb_set_async_mode(unsigned sysclk_ps,
unsigned fclk_ps)
tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
- return gpmc_cs_set_timings(async_cs, t);
+ /* gpmc driver interface */
+ if (gpmc_tusb_data.pdata != NULL) {
+ gpmc_tusb_cs_data[CS_ASYNC_IDX].time_ctrl.type = has_period;
+ gpmc_tusb_cs_data[CS_ASYNC_IDX].time_ctrl.timings = t;
+ return 0;
+ /* old interface */
+ } else
+ return gpmc_cs_set_timings(async_cs, t);
}
static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
@@ -174,7 +198,16 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned
fclk_ps)
tmp = t.cs_wr_off * 1000 + 7000 /* t_scsn_rdy_z */;
t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
- return gpmc_cs_set_timings(sync_cs, t);
+ t.clk_activation = gpmc_ticks_to_ns(1);
+
+ /* gpmc driver interface */
+ if (gpmc_tusb_data.pdata != NULL) {
+ gpmc_tusb_cs_data[CS_SYNC_IDX].time_ctrl.type = has_period;
+ gpmc_tusb_cs_data[CS_SYNC_IDX].time_ctrl.timings = t;
+ return 0;
+ /* old interface */
+ } else
+ return gpmc_cs_set_timings(sync_cs, t);
}
extern unsigned long gpmc_get_fclk_period(void);
@@ -348,3 +381,79 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
}
return 0;
}
+
+struct gpmc_device_pdata *
+__init gpmc_tusb6010_update(struct musb_hdrc_platform_data *data,
+ unsigned ps_refclk, unsigned waitpin,
+ unsigned async, unsigned sync,
+ unsigned irq, unsigned dmachan)
+{
+ int ret;
+
+ if (!data) {
+ pr_err(error: %s: data: NULL\n, __func__);
+ return NULL;
+ }
+
+ gpmc_tusb_data.pdata = data;
+ gpmc_tusb_data.pdata_size = sizeof(*data);
+
+ /* ASYNC region, primarily for PIO */
+ gpmc_tusb_cs_data[CS_ASYNC_IDX].cs = async;
+ gpmc_tusb_cs_data[CS_ASYNC_IDX].mem_size = 0x1000;
+
+ async_cs = async;
+
+ gpmc_tusb_cs_data[CS_ASYNC_IDX].have_config = true;
+ gpmc_tusb_cs_data[CS_ASYNC_IDX].config = waitpin |
+ GPMC_CONFIG1_DEVICESIZE_16 | GPMC_CONFIG1_WAIT_READ_MON |
+ GPMC_CONFIG1_WAIT_WRITE_MON | GPMC_CONFIG1_READTYPE_ASYNC |
+ GPMC_CONFIG1_WRITETYPE_ASYNC | GPMC_CONFIG1_DEVICETYPE_NOR |
+ GPMC_CONFIG1_MUXADDDATA | GPMC_CONFIG1_PAGE_LEN_16;
+
+ /* SYNC region, primarily for DMA */
+ gpmc_tusb_cs_data[CS_SYNC_IDX].cs = sync;
+ gpmc_tusb_cs_data[CS_SYNC_IDX].mem_size = 0x1000;
+
+ sync_cs = sync;
+
+ gpmc_tusb_cs_data[CS_SYNC_IDX].have_config = true;
+ gpmc_tusb_cs_data[CS_SYNC_IDX].config = waitpin |
+ GPMC_CONFIG1_DEVICESIZE_16 | GPMC_CONFIG1_WAIT_READ_MON |
+ GPMC_CONFIG1_WAIT_WRITE_MON | GPMC_CONFIG1_READTYPE_SYNC |
+ GPMC_CONFIG1_WRITETYPE_SYNC | GPMC_CONFIG1_DEVICETYPE_NOR |
+ GPMC_CONFIG1_MUXADDDATA | GPMC_CONFIG1_READMULTIPLE_SUPP |
+ GPMC_CONFIG1_WRITEMULTIPLE_SUPP | GPMC_CONFIG1_PAGE_LEN_16;
+
+ /* IRQ */
+ ret = gpio_request_one(irq, GPIOF_IN, TUSB6010 irq);
+ if (ret 0) {
+ pr_err(error: %s: gpio_request_one: %d\n, __func__, ret);
+ return NULL;
+
[PATCH 5/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
Currently gpmc is configured in platform for smc91x. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 69 +
arch/arm/plat-omap/include/plat/gpmc-smc91x.h | 12 +++--
2 files changed, 66 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index ba10c24..06f7e73 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -48,6 +48,19 @@ static struct platform_device gpmc_smc91x_device = {
.resource = gpmc_smc91x_resources,
};
+static struct gpmc_cs_data gpmc_smc91x_cs_data;
+
+static struct gpmc_device_pdata gpmc_smc91x_data = {
+ .name = smc91x,
+ .id = -1,
+ .pdata = gpmc_smc91x_info,
+ .pdata_size = sizeof(gpmc_smc91x_info),
+ .per_res= gpmc_smc91x_resources + 1,
+ .per_res_cnt= 1,
+ .cs_data= gpmc_smc91x_cs_data,
+ .num_cs = 1,
+};
+
/*
* Set the gpmc timings for smc91c96. The timings are taken
* from the data sheet available at:
@@ -100,9 +113,18 @@ static int smc91c96_gpmc_retime(void)
l |= GPMC_CONFIG1_WAIT_READ_MON;
if (gpmc_cfg-flags GPMC_WRITE_MON)
l |= GPMC_CONFIG1_WAIT_WRITE_MON;
- if (gpmc_cfg-wait_pin)
- l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg-wait_pin);
- gpmc_cs_write_reg(gpmc_cfg-cs, GPMC_CS_CONFIG1, l);
+
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+ gpmc_smc91x_cs_data.have_config = true;
+ /* waitpin macro, not waitpin number */
+ gpmc_smc91x_cs_data.config |= l |
+ (gpmc_cfg-wait_pin GPMC_WAITPIN_MASK);
+ } else {
+ if (gpmc_cfg-wait_pin)
+ l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg-wait_pin);
+ gpmc_cs_write_reg(gpmc_cfg-cs, GPMC_CS_CONFIG1, l);
+ }
/*
* FIXME: Calculate the address and data bus muxed timings.
@@ -114,7 +136,13 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
return 0;
- return gpmc_cs_set_timings(gpmc_cfg-cs, t);
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+ gpmc_smc91x_cs_data.time_ctrl.type = has_period;
+ gpmc_smc91x_cs_data.time_ctrl.timings = t;
+ return 0;
+ } else
+ return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
/*
@@ -132,13 +160,17 @@ void __init gpmc_smc91x_init(struct
omap_smc91x_platform_data *board_data)
if (gpmc_cfg-flags GPMC_TIMINGS_SMC91C96)
gpmc_cfg-retime = smc91c96_gpmc_retime;
- if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
- printk(KERN_ERR Failed to request GPMC mem for smc91x\n);
- return;
+ /* old interface */
+ if (gpmc_smc91x_cs_data.mem_size != 0x10) {
+ if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
+ pr_err(error: gpmc_cs_request on smc91x\n);
+ return;
+ }
+
+ gpmc_smc91x_resources[0].start = cs_mem_base + 0x300;
+ gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
}
- gpmc_smc91x_resources[0].start = cs_mem_base + 0x300;
- gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
gpmc_smc91x_resources[1].flags |= (gpmc_cfg-flags IRQF_TRIGGER_MASK);
if (gpmc_cfg-retime) {
@@ -170,6 +202,10 @@ void __init gpmc_smc91x_init(struct
omap_smc91x_platform_data *board_data)
gpio_set_value(gpmc_cfg-gpio_reset, 0);
}
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10)
+ return;
+
if (platform_device_register(gpmc_smc91x_device) 0) {
printk(KERN_ERR Unable to register smc91x device\n);
gpio_free(gpmc_cfg-gpio_reset);
@@ -184,7 +220,20 @@ free3:
free2:
gpio_free(gpmc_cfg-gpio_irq);
free1:
- gpmc_cs_free(gpmc_cfg-cs);
+ if (gpmc_smc91x_cs_data.mem_size != 0x10)
+ gpmc_cs_free(gpmc_cfg-cs);
printk(KERN_ERR Could not initialize smc91x\n);
}
+
+struct gpmc_device_pdata *
+__init gpmc_smc91x_update(struct omap_smc91x_platform_data *board_data)
+{
+ gpmc_smc91x_cs_data.cs = gpmc_cfg-cs;
+ gpmc_smc91x_cs_data.mem_offset = 0x300;
+ gpmc_smc91x_cs_data.mem_size= 0x10;
+
+
[PATCH 7/9] ARM: OMAP2+: gpmc-smsc911x: runtime time calculation
OMAP Peripherals using SMSC911X driver were not configured
in Kernel. Here timing has been calculated so that it is
runtime configurable. As different SMSC devices like 9115,
9220, 9221 can be used with smsc911x driver, option has been
given for the boards to provide timing as per the part used,
if it is not provided, default one used is that of 9220.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 53 +++
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 14 ++
2 files changed, 67 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 93a534e..4bfe721 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -100,6 +100,53 @@ free1:
pr_err(Could not initialize smsc911x device\n);
}
+static void gpmc_smsc911x_timing(struct gpmc_time_ctrl *time_ctrl,
+ struct smsc911x_timing *timing)
+{
+ struct gpmc_timings t;
+ /* SMSC 9220 timings */
+ unsigned tcycle_r = 165;
+ unsigned tcsl_r = 32;
+ unsigned tcsh_r = 133;
+ unsigned tcsdv_r = 30;
+ unsigned tdoff_r = 9;
+ unsigned tcycle_w = 165;
+ unsigned tcsl_w = 32;
+ unsigned tcsh_w = 133;
+ unsigned tdsu_w = 7;
+
+ /* take timings from board, else use default */
+ if (timing) {
+ tcycle_r = timing-tcycle_r;
+ tcsl_r = timing-tcsl_r;
+ tcsh_r = timing-tcsh_r;
+ tcsdv_r = timing-tcsdv_r;
+ tdoff_r = tdoff_r;
+ tcycle_w = timing-tcycle_r;
+ tcsl_w = timing-tcsl_w;
+ tcsh_w = timing-tcsh_w;
+ tdsu_w = timing-tdsu_w;
+ }
+
+ memset(t, sizeof(t), 0);
+
+ t.cs_on = 0;
+ t.oe_on = 0;
+ t.access = tcsdv_r;
+ t.oe_off = max_t(unsigned, t.access + gpmc_ticks_to_ns(1), tcsl_r);
+ t.cs_rd_off = t.oe_off;
+ t.rd_cycle = tcsl_r + max(tcsh_r, tdoff_r);
+ t.rd_cycle = max_t(unsigned, tcycle_r, t.rd_cycle);
+
+ t.we_on = 0;
+ t.we_off = max(tcsl_w, tdsu_w);
+ t.cs_wr_off = t.we_off;
+ t.wr_cycle = max_t(unsigned, t.we_off + gpmc_ticks_to_ns(1), tcycle_w);
+
+ time_ctrl-type = has_period;
+ time_ctrl-timings = t;
+}
+
struct gpmc_device_pdata *
__init gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
{
@@ -127,6 +174,12 @@ __init gpmc_smsc911x_update(struct
omap_smsc911x_platform_data *gpmc_cfg)
gpmc_cs-cs = gpmc_cfg-cs;
gpmc_cs-mem_size = 0x100;
+ gpmc_cs-have_config = true;
+ gpmc_cs-config = GPMC_CONFIG1_DEVICESIZE_16 |
+ GPMC_CONFIG1_DEVICETYPE_NOR;
+
+ gpmc_smsc911x_timing(gpmc_cs-time_ctrl, gpmc_cfg-timing);
+
gpmc_pdev-per_res = gpmc_smsc911x_resources + 1;
gpmc_pdev-per_res_cnt = 1;
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index 50af49e..8be3343 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -13,12 +13,26 @@
#ifndef __ASM_ARCH_OMAP_GPMC_SMSC911X_H__
+/* timing in ns */
+struct smsc911x_timing {
+ unsigned tcycle_r;
+ unsigned tcsl_r;
+ unsigned tcsh_r;
+ unsigned tcsdv_r;
+ unsigned tdoff_r;
+ unsigned tcycle_w;
+ unsigned tcsl_w;
+ unsigned tcsh_w;
+ unsigned tdsu_w;
+};
+
struct omap_smsc911x_platform_data {
int id;
int cs;
int gpio_irq;
int gpio_reset;
u32 flags;
+ struct smsc911x_timing *timing;
};
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] ARM: OMAP2+: board omap3evm: use gpmc driver
gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..aa9429d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -43,6 +43,7 @@
#include plat/board.h
#include plat/usb.h
+#include plat/gpmc.h
#include common.h
#include plat/mcspi.h
#include video/omapdss.h
@@ -102,6 +103,12 @@ static void __init omap3_evm_get_revision(void)
}
}
+static struct gpmc_device_pdata *gpmc_device_data[2];
+
+static struct gpmc_pdata gpmc_data = {
+ .device_pdata = gpmc_device_data,
+};
+
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include plat/gpmc-smsc911x.h
@@ -122,7 +129,9 @@ static inline void __init omap3evm_init_smsc911x(void)
smsc911x_cfg.gpio_reset = OMAP3EVM_GEN2_ETHR_GPIO_RST;
}
- gpmc_smsc911x_init(smsc911x_cfg);
+ *gpmc_device_data = gpmc_smsc911x_update(smsc911x_cfg);
+ if (!*gpmc_device_data)
+ pr_err(error: unable to initilaize gpmc smsc911x\n);
}
#else
@@ -658,6 +667,7 @@ static void __init omap3_evm_init(void)
usbhs_init(usbhs_bdata);
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
+ omap_gpmc_init(gpmc_data);
omap3_evm_display_init();
omap3_evm_wl12xx_init();
}
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] ARM: OMAP2+: board omap3beagle: use gpmc driver
gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5aa8f28..0fe70ed 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -77,6 +77,12 @@ enum {
static u8 omap3_beagle_version;
+static struct gpmc_device_pdata *gpmc_device_data[2];
+
+static struct gpmc_pdata gpmc_data = {
+ .device_pdata = gpmc_device_data,
+};
+
/*
* Board-specific configuration
* Defaults to BeagleBoard-xMC
@@ -499,6 +505,8 @@ static void __init beagle_opp_init(void)
static void __init omap3_beagle_init(void)
{
+ struct omap_nand_platform_data *nand_data;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
@@ -524,9 +532,13 @@ static void __init omap3_beagle_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- board_nand_init(omap3beagle_nand_partitions,
+ nand_data = board_nand_update(omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions), NAND_CS,
- NAND_BUSWIDTH_16, NULL);
+ NAND_BUSWIDTH_16, nand_default_timings);
+ *gpmc_device_data = gpmc_nand_update(nand_data);
+ if (!*gpmc_device_data)
+ pr_err(error: unable to initilaize gpmc nand\n);
+ omap_gpmc_init(gpmc_data);
/* Ensure msecure is mux'd to be able to set the RTC. */
omap_mux_init_signal(sys_drm_msecure, OMAP_PIN_OFF_OUTPUT_HIGH);
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] ARM: OMAP2+: gpmc-smsc911x: Adapt to use gpmc driver
Currently gpmc is configured in platform for smsc911x. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 66 +++
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 11 ++--
2 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index b6c77be..93a534e 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -99,3 +99,69 @@ free1:
pr_err(Could not initialize smsc911x device\n);
}
+
+struct gpmc_device_pdata *
+__init gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+ int ret;
+ struct gpmc_device_pdata *gpmc_pdev;
+ struct gpmc_cs_data *gpmc_cs;
+
+ gpmc_pdev = kzalloc(sizeof(*gpmc_pdev), GFP_KERNEL);
+ if (gpmc_pdev == NULL)
+ return gpmc_pdev;
+
+ gpmc_cs = kzalloc(sizeof(*gpmc_cs), GFP_KERNEL);
+ if (gpmc_pdev == NULL) {
+ kfree(gpmc_pdev);
+ return NULL;
+ }
+
+ gpmc_pdev-cs_data = gpmc_cs;
+ gpmc_pdev-num_cs = 1;
+ gpmc_pdev-name = smsc911x;
+ gpmc_pdev-id = gpmc_cfg-id;
+ gpmc_pdev-pdata = gpmc_smsc911x_config;
+ gpmc_pdev-pdata_size = sizeof(gpmc_smsc911x_config);
+
+ gpmc_cs-cs = gpmc_cfg-cs;
+ gpmc_cs-mem_size = 0x100;
+
+ gpmc_pdev-per_res = gpmc_smsc911x_resources + 1;
+ gpmc_pdev-per_res_cnt = 1;
+
+ if (gpio_request_one(gpmc_cfg-gpio_irq, GPIOF_IN, smsc911x irq)) {
+ pr_err(Failed to request IRQ GPIO%d\n, gpmc_cfg-gpio_irq);
+ goto free1;
+ }
+
+ gpmc_smsc911x_resources[1].start = gpio_to_irq(gpmc_cfg-gpio_irq);
+
+ if (gpio_is_valid(gpmc_cfg-gpio_reset)) {
+ ret = gpio_request_one(gpmc_cfg-gpio_reset,
+ GPIOF_OUT_INIT_HIGH, smsc911x reset);
+ if (ret) {
+ pr_err(Failed to request reset GPIO%d\n,
+ gpmc_cfg-gpio_reset);
+ goto free2;
+ }
+
+ gpio_set_value(gpmc_cfg-gpio_reset, 0);
+ msleep(100);
+ gpio_set_value(gpmc_cfg-gpio_reset, 1);
+ }
+
+ gpmc_smsc911x_config.flags = gpmc_cfg-flags ? : SMSC911X_USE_16BIT;
+
+ return gpmc_pdev;
+
+free2:
+ gpio_free(gpmc_cfg-gpio_irq);
+free1:
+ kfree(gpmc_cs);
+ kfree(gpmc_pdev);
+
+ pr_err(Could not initialize smsc911x device\n);
+
+ return NULL;
+}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index ea6c9c8..50af49e 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -22,14 +22,17 @@ struct omap_smsc911x_platform_data {
};
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-
extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
-
+extern struct gpmc_device_pdata *
+gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg);
#else
-
static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
{
}
-
+static inline struct gpmc_device_pdata *
+gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+ return NULL;
+}
#endif
#endif
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 0/7] ARM: OMAP4: core retention support
Hi, Changes compared to previous version: - moved basic omap4 pm errata support from dev-off set to this one - changed ordering of patches a bit (core ret enabled at last patch) - dropped DSP reset hack patch from set, as it is no longer needed - added arch specific hwmod_ops support, needed for proper functioning of the context loss support - context offset register invalidity is now marked with USHRT_MAX instead of a separate flag - patches rebased on top of Jean Pihet's functional power state code - patches rebased on top of 3.5-rc2 - dropped debug option for enabling OSWR mode for suspend, this is now enabled by default Tested with omap4 panda board + omap3 beagle (just to verify nothing gets broken.) Fully functioning branch available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.5-rc2-omap4-ret-v6 Branch contains also hwmod fixes from Paul Walmsley, functional power state code from Jean Pihet, IO chain set and a few other needed misc fixes to make suspend to core retention + wakeup to work properly. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 1/7] ARM: OMAP4: PM: add errata support
Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..46ab9d9 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -88,6 +88,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#if defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
+#else
+#define IS_PM44XX_ERRATUM(id) 0
+#endif
+
#ifdef CONFIG_OMAP_SMARTREFLEX
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c234733..3a484b1 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,6 +33,7 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
},
},
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
Signed-off-by: Paul Walmsley p...@pwsan.com
[t-kri...@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 70 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |8 ++-
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7b1..742e507 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -170,6 +170,13 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
+struct hwmod_ops {
+ void(*hwmod_update_context_lost)(struct omap_hwmod *oh);
+ int (*hwmod_get_context_lost)(struct omap_hwmod *oh);
+};
+
+static struct hwmod_ops *arch_hwmod;
+
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -1773,6 +1780,51 @@ static void _reconfigure_io_chain(void)
}
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
+
+ r = omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
+
+ omap4_prminst_write_inst_reg(r, oh-clkdm-pwrdm.ptr-prcm_partition,
+oh-clkdm-pwrdm.ptr-prcm_offs,
+oh-prcm.omap4.context_offs);
+}
+
+/**
+ * _omap4_get_context_lost - get context loss counter for a hwmod
+ *
+ * Returns the in-memory context loss counter for a hwmod.
+ */
+static int _omap4_get_context_lost(struct omap_hwmod *oh)
+{
+ return oh-prcm.omap4.context_lost_counter;
+}
+
+static struct hwmod_ops omap4_hwmod_ops = {
+ .hwmod_update_context_lost = _omap4_update_context_lost,
+ .hwmod_get_context_lost = _omap4_get_context_lost,
+};
+
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1853,6 +1905,9 @@ static int _enable(struct omap_hwmod *oh)
_enable_clocks(oh);
_enable_module(oh);
+ if (arch_hwmod arch_hwmod-hwmod_update_context_lost)
+ arch_hwmod-hwmod_update_context_lost(oh);
+
r = _wait_target_ready(oh);
if (!r) {
/*
@@ -2711,6 +2766,9 @@ int __init omap_hwmod_setup_one(const char *oh_name)
*/
static int __init omap_hwmod_setup_all(void)
{
+ if (cpu_is_omap44xx())
+ arch_hwmod = omap4_hwmod_ops;
+
_ensure_mpu_hwmod_is_setup(NULL);
omap_hwmod_for_each(_init, NULL);
@@ -3364,17 +3422,21 @@ ohsps_unlock:
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
- * count for this device.
+ * Returns the context loss count of associated @oh
+ * upon success, or zero if no context loss data is available.
*
- * Returns the context loss count of the powerdomain assocated with @oh
- * upon success, or zero if no powerdomain exists for @oh.
+ * On OMAP4, this queries the per-hwmod context loss register,
+ * assuming one exists. If not, or on OMAP2/3, this queries the
+ * enclosing powerdomain context loss count.
*/
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
+ if (arch_hwmod arch_hwmod-hwmod_get_context_lost)
+
[PATCHv6 2/7] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4+ devices, GIC register context is lost when MPUSS hits
the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
gets executed and one of the steps in it is to restore the
saved context of the GIC. The ROM Code GIC distributor restoration
is split in two parts: CPU specific register done by each CPU and
common register done by only one CPU.
Below is the abstract flow.
...
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.
[..]
- CPU0 executes GIC Restoration:
[...]
- CPU0 swicthes to non-secure mode and jumps to OS resume code.
[...]
- CPU0 is online in OS
- CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1
- CPU0 wakes up CPU1 with clock-domain force wakeup method.
- CPU0 continues it's execution.
[..]
- CPU1 wakes up and start executing ROM code.
[..]
- CPU1 executes GIC Restoration:
[..]
- CPU1 swicthes to non-secure mode and jumps to OS resume code.
[...]
- CPU1 is online in OS and start executing.
[...] -
GIC Restoration: /* Common routine for HS and GP devices */
{
if (GICD != 1) { /* This will be true in OSWR state */
if (GIC_SAR_BACKUP_STATE == SAVED)
- CPU restores GIC distributor
else
- reconfigure GIC distributor to boot values.
GICD.Enable secure = 1
}
if (GIC_SAR_BACKUP_STATE == SAVED)
- CPU restore its GIC CPU interface registers if saved.
else
- reconfigure its GIC CPU interface registers to boot
values.
}
...
So as mentioned in the flow, GICD != 1 condition decides how
the GIC registers are handled in ROM code wakeup path from
OSWR. As evident from the flow, ROM code relies on the entire
GICD register value and not specific register bits.
The assumption was valid till CortexA9 r1pX version since there
was only one banked bit to control secure and non-secure GICD.
Secure view which ROM code sees:
bit 0 == Enable Non-secure
Non-secure view which HLOS sees:
bit 0 == Enable secure
But GICD register has changed between CortexA9 r1pX and r2pX.
On r2pX GICD register is composed of 2 bits.
Secure view which ROM code sees:
bit 1 == Enable Non-secure
bit 0 == Enable secure
Non-secure view which HLOS sees:
bit 0 == Enable Non-secure
Hence on OMAP4460(r2pX) devices, if you go through the
above flow again during CPU1 wakeup, GICD == 3 and hence
ROM code fails to understand the real wakeup power state
and reconfigures GIC distributor to boot values. This is
nasty since you loose the entire interrupt controller
context in a live system.
The ROM code fix done on next OMAP4 device (OMAP4470 - r2px) is to
check GICD.Enable secure != 1 for GIC restoration in OSWR wakeup path.
Since ROM code can't be fixed on OMAP4460 devices, a work around
needs to be implemented. As evident from the flow, as long as
CPU1 sees GICD == 1 in it's wakeup path from OSWR, the issue
won't happen. Below is the flow with the work-around.
...
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.
[..]
- CPU0 executes GIC Restoration:
[..]
- CPU0 swicthes to non-secure mode and jumps to OS resume code.
[..]
- CPU0 is online in OS.
- CPU0 does GICD.Enable Non-secure = 0
- CPU0 wakes up CPU1 with clock domain force wakeup method.
- CPU0 waits for GICD.Enable Non-secure = 1
- CPU0 coninues it's execution.
[..]
- CPU1 wakes up and start executing ROM code.
[..]
- CPU1 executes GIC Restoration:
[..]
- CPU1 swicthes to non-secure mode and jumps to OS resume code.
[..]
- CPU1 is online in OS
- CPU1 does GICD.Enable Non-secure = 1
- CPU1 start executing
[...]
...
With this procedure, the GIC configuration done between the
CPU0 wakeup and CPU1 wakeup will not be lost but during this
short windows, the CPU0 will not receive interrupts.
The BUG is applicable to only OMAP4460(r2pX) devices.
OMAP4470 (also r2pX) is not affected by this bug because
ROM code has been fixed.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/omap-headsmp.S| 38 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c |9 ++-
arch/arm/mach-omap2/omap-smp.c| 28 -
arch/arm/mach-omap2/omap4-common.c|8 +-
arch/arm/mach-omap2/pm.h |2 +
6 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index be9dfd1..a793ab3 100644
---
[PATCHv6 6/7] ARM: OMAP4: suspend: Program all domains to retention
From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com [Jean Pihet j-pi...@ti.com: ported on top of the functional power states] Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/pm44xx.c | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 3a484b1..1e845e8 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -97,19 +97,15 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) return -ENOMEM; pwrst-pwrdm = pwrdm; - pwrst-next_state = PWRDM_FUNC_PWRST_CSWR; + pwrst-next_state = pwrdm_get_achievable_func_pwrst( + pwrdm, + PWRDM_FUNC_PWRST_CSWR); list_add(pwrst-node, pwrst_list); return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 5/7] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain44xx.c | 59 +
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 030d10c..ab93f08 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -151,6 +151,34 @@ static int omap4_pwrdm_read_logic_retst(struct powerdomain
*pwrdm)
return v;
}
+/**
+ * omap4_pwrdm_read_prev_logic_pwrst - read the previous logic powerstate
+ * @pwrdm: struct powerdomain * to read the state for
+ *
+ * Reads the previous logic powerstate for a powerdomain. This function
+ * must determine the previous logic powerstate by first checking the
+ * previous powerstate for the domain. If that was OFF, then logic has
+ * been lost. If previous state was RETENTION, the function reads the
+ * setting for the next retention logic state to see the actual value.
+ * In every other case, the logic is retained. Returns either
+ * PWRDM_LOGIC_MEM_PWRST_OFF or PWRDM_LOGIC_MEM_PWRST_RET depending
+ * whether the logic was retained or not.
+ */
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_LOGIC_MEM_PWRST_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_LOGIC_MEM_PWRST_RET;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
{
u32 m, v;
@@ -179,6 +207,35 @@ static int omap4_pwrdm_read_mem_retst(struct powerdomain
*pwrdm, u8 bank)
return v;
}
+/**
+ * omap4_pwrdm_read_prev_mem_pwrst - reads the previous memory powerstate
+ * @pwrdm: struct powerdomain * to read mem powerstate for
+ * @bank: memory bank index
+ *
+ * Reads the previous memory powerstate for a powerdomain. This function
+ * must determine the previous memory powerstate by first checking the
+ * previous powerstate for the domain. If that was OFF, then logic has
+ * been lost. If previous state was RETENTION, the function reads the
+ * setting for the next memory retention state to see the actual value.
+ * In every other case, the logic is retained. Returns either
+ * PWRDM_LOGIC_MEM_PWRST_OFF or PWRDM_LOGIC_MEM_PWRST_RET depending
+ * whether logic was retained or not.
+ */
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
+{
+ int state;
+
+ state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+ if (state == PWRDM_POWER_OFF)
+ return PWRDM_LOGIC_MEM_PWRST_OFF;
+
+ if (state != PWRDM_POWER_RET)
+ return PWRDM_LOGIC_MEM_PWRST_RET;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -220,9 +277,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 7/7] ARM: OMAP4: PM: put all domains to OSWR during suspend
Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/pm44xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 1e845e8..eb3e073 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -105,7 +105,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) pwrst-pwrdm = pwrdm; pwrst-next_state = pwrdm_get_achievable_func_pwrst( pwrdm, - PWRDM_FUNC_PWRST_CSWR); + PWRDM_FUNC_PWRST_OSWR); list_add(pwrst-node, pwrst_list); return omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: nand: unify init functions
Hi Afzal, On 06/11/2012 09:01 AM, Afzal Mohammed wrote: Helper function for updating nand platform data has been added the capability to take timing structure arguement. Usage of omap_nand_flash_init() has been replaced by modifed one, omap_nand_flash_init was doing things similar to board_nand_init except that NAND CS# were being acquired based on bootloader setting. As CS# is hardwired for a given board, acquiring gpmc CS# has been removed, and updated with the value on board. NAND CS# used in beagle board was found to be CS0. Thomas Weber thomas.weber.li...@googlemail.com reported that value of devkit8000 to be CS0. Overo board was found to be using CS0 based on u-boot, while google grep says omap3touchbook too has CS0. [1] also confirms the omap3-touchbook uses CS0. Signed-off-by: Afzal Mohammed af...@ti.com Which boards have been tested with this change? Otherwise, looks good. Reviewed-by: Jon Hunter jon-hun...@ti.com Cheers Jon [1] http://www.alwaysinnovating.com/wiki/index.php/Booting -- To unsubscribe from this list: send the line unsubscribe 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+: add drm device
On Wed, May 23, 2012 at 3:08 PM, Andy Gross andy.gr...@ti.com wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark rob.cl...@linaro.org
---
arch/arm/mach-omap2/Makefile | 4 ++
arch/arm/mach-omap2/drm.c | 61
drivers/staging/omapdrm/omap_drv.h | 2 +-
drivers/staging/omapdrm/omap_priv.h | 55
include/linux/platform_data/omap_drm.h | 52 +++
5 files changed, 118 insertions(+), 56 deletions(-)
create mode 100644 arch/arm/mach-omap2/drm.c
delete mode 100644 drivers/staging/omapdrm/omap_priv.h
create mode 100644 include/linux/platform_data/omap_drm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..c301ab7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
obj-y += dsp.o
endif
+ifneq ($(CONFIG_DRM_OMAP),)
+obj-y += drm.o
+endif
+
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
new file mode 100644
index 000..72e0f01b
--- /dev/null
+++ b/arch/arm/mach-omap2/drm.c
@@ -0,0 +1,61 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .name = omapdrm,
+ .id = 0,
+};
+
+static int __init omap_init_drm(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
+
+arch_initcall(omap_init_drm);
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index b7e0f07..96296e0 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -25,8 +25,8 @@
#include linux/types.h
#include drm/drmP.h
#include drm/drm_crtc_helper.h
+#include linux/platform_data/omap_drm.h
#include omap_drm.h
-#include omap_priv.h
#define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug
*/
diff --git a/drivers/staging/omapdrm/omap_priv.h
b/drivers/staging/omapdrm/omap_priv.h
deleted file mode 100644
index ef64414..000
--- a/drivers/staging/omapdrm/omap_priv.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * include/drm/omap_priv.h
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Rob Clark r...@ti.com
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but
WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along
with
- * this program. If not, see http://www.gnu.org/licenses/.
- */
-
-#ifndef __OMAP_PRIV_H__
-#define __OMAP_PRIV_H__
-
-/* Non-userspace facing APIs
- */
-
-/* optional
Re: [PATCHv10 00/11] I2C fixes
On Sun, Jun 10, 2012 at 11:10:47AM +0530, Shubhrajyoti Datta wrote: On Fri, Jun 1, 2012 at 4:29 AM, Kevin Hilman khil...@ti.com wrote: Shubhrajyoti D shubhrajy...@ti.com writes: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. v9: Fix the comments from Wolfram Sang v10: Add a patch from Neil to the series. Fix kevin comments update the patches with comments. Shubhrajyoti, thanks for the updates. Wolfgang, with these updates and testing a bit better described, I'm OK with you merging it. Merging it now will give it plenty of time to bake in linux-next and get more test exposure. Agree, These are only fixes can it be considered for rc3? Baking in linux-next and considering rc3 don't match; baking needs time, rc3 is soon. I've put the patches now into my -next branch for more exposure. I am still uncertain if they should be in 3.5 already; there seem to be worhty fixes in there, but they do depend on stuff which don't really qualify as bugfixes... Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: Broken builds
On Tue, Jun 05, 2012 at 04:20:00PM +0300, Tomi Valkeinen wrote: Hi, On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]: Looks like the DSS stuff has broken OMAP builds again during this merge window: drivers/video/omap2/dss/core.c:197: error: static declaration of 'dss_debugfs_create_file' follows non-static declaration drivers/video/omap2/dss/dss.h:166: error: previous declaration of 'dss_debugfs_create_file' was here Both the OMAP3 and OMAP4 builds break with these two errors. Here's a patch for Tomi to fix this one. I have a patch for this in my for-rc branch. It just missed the main merge. I'll send this and a few other fixes today for the next rc. Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled. That's why I didn't notice it until too late. So... where are we with this? Apparantly not much further forward; it seems to be in linux-next but still not in mainline, and mainline continues to be broken. -- To unsubscribe from this list: send the line unsubscribe 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: Broken builds
On Wed, Jun 06, 2012 at 12:58:00AM -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120605 06:24]: Hi, On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]: Looks like the DSS stuff has broken OMAP builds again during this merge window: drivers/video/omap2/dss/core.c:197: error: static declaration of 'dss_debugfs_create_file' follows non-static declaration drivers/video/omap2/dss/dss.h:166: error: previous declaration of 'dss_debugfs_create_file' was here Both the OMAP3 and OMAP4 builds break with these two errors. Here's a patch for Tomi to fix this one. I have a patch for this in my for-rc branch. It just missed the main merge. I'll send this and a few other fixes today for the next rc. Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled. That's why I didn't notice it until too late. Tomi, please have your patches sitting in linux next for at least a week before they get merged. That usually shakes down bugs like these before the merge window. Note that tested simple bug fixes _should_ be upstreamed faster than that where possible - such as this one. I'm waiting for this to hit mainline before doing any further work on OMAP. That basically means I've been totally ignoring OMAP because of this issue for the last week. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data
Hi Vaibhav, On Mon, 11 Jun 2012, Vaibhav Hiremath wrote: I think this is not required, since Tony has already accepted the patch which has this implementation (available on linux-omap/master). Please refer to the commit, commit 08f3098928c991560408e8c71d4af8b1a3ff2d67 Author: Afzal Mohammed af...@ti.com Date: Fri May 11 00:38:49 2012 +0530 ARM: OMAP2+: am33xx: Add AM335XEVM machine support Thanks, that's what I need. Looks like our series needs to be based on this commit, rather than mainline. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
On Mon, 11 Jun 2012, Cousson, Benoit wrote: On 6/11/2012 10:04 AM, Paul Walmsley wrote: But if the IP blocks are reset later, and the bootloader or previous OS gets some register settings wrong, there's a greater risk of system instability or unpredictable behavior during the boot process. Mmm, I'm not convince by that. If we delay the PM init at the very last time, at least after the modules are properly reset and init, I do not think we will have more issues than today. My intent was not to convince, but to explain. Certainly back in the OMAP3 days there were bootloaders that got SDRAM and GPMC timings wrong. No way did I want to be chasing down kernel bugs based on those. Anyway, once people finish fixing the drivers, then we should be able to switch to late hwmod reset. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
Hi Paul,
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it.
But why? The clock domain information is already present in every hwmod
nodes for OMAP4.
This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:
omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..e2b701e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -84,6 +84,7 @@ static struct clk slimbus_clk = {
static struct clk sys_32k_ck = {
.name = sys_32k_ck,
+ .clkdm_name = prm_clkdm,
In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 :-(.
I've just realized that you introduced that for 3.5, but this is wrong.
We should not start adding some fake clock domains just because the fmwk
is not smart enough to allow a NULL clock domain.
The clkdomain should be optional, at least for clock nodes.
There is no need to enforce the presence of the clock domain in the
structure. We should remove the warning and test the clkdm attribute
before de-referencing it inside the clock core code.
This is the only proper fix for that issue for my point of view.
In a period of data size reduction, adding some fake information does
not seems to be the right approach.
Don't you think so?
Regards,
Benoit
PS: I think we should revert 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c
(ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common) and fix the
OMAP4 hwmod data.
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP2+: Fix errors in PRCM hwmods + wrong clkdm
Hi Paul,
Here is the serie to fix wrong clkdm for the PRCM hwmods.
I did revert as well the patch to make the cm_clkdm and prm_clkdm
common since it does not exist on OMAP4.
I do not thinks it exists in OMAP2 and 3 either, and thus that series should
probably be extended with the total removal of these fake clkdm.
I'd like to get your feedback first on this one to go further for OMAP2 3.
This series is based on 3.5-rc2 and should target -rc3.
Regards,
Benoit
Benoit Cousson (2):
ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
Revert ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/clockdomain44xx.c|6 ---
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10
arch/arm/mach-omap2/clockdomains44xx_data.c |2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 52 +++---
6 files changed, 36 insertions(+), 59 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.
Replace them with the proper wkup, l4_ao and l4_cfg.
Fix as well the wrong OCP port used by the cm_core_aon. It uses the
l4_cfg interconnect and not the l4_wkup.
Re-order the entries by address value.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..03fc705 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2529,27 +2529,6 @@ static struct omap_hwmod_class omap44xx_prcm_hwmod_class
= {
.name = prcm,
};
-/* prcm_mpu */
-static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
- .name = prcm_mpu,
- .class = omap44xx_prcm_hwmod_class,
- .clkdm_name = l4_wkup_clkdm,
-};
-
-/* cm_core_aon */
-static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
- .name = cm_core_aon,
- .class = omap44xx_prcm_hwmod_class,
- .clkdm_name = cm_clkdm,
-};
-
-/* cm_core */
-static struct omap_hwmod omap44xx_cm_core_hwmod = {
- .name = cm_core,
- .class = omap44xx_prcm_hwmod_class,
- .clkdm_name = cm_clkdm,
-};
-
/* prm */
static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
{ .irq = 11 + OMAP44XX_IRQ_GIC_START },
@@ -2564,12 +2543,33 @@ static struct omap_hwmod_rst_info omap44xx_prm_resets[]
= {
static struct omap_hwmod omap44xx_prm_hwmod = {
.name = prm,
.class = omap44xx_prcm_hwmod_class,
- .clkdm_name = prm_clkdm,
+ .clkdm_name = l4_wkup_clkdm,
.mpu_irqs = omap44xx_prm_irqs,
.rst_lines = omap44xx_prm_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_prm_resets),
};
+/* cm_core */
+static struct omap_hwmod omap44xx_cm_core_hwmod = {
+ .name = cm_core,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_cfg_clkdm,
+};
+
+/* cm_core_aon */
+static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
+ .name = cm_core_aon,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_ao_clkdm,
+};
+
+/* prcm_mpu */
+static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
+ .name = prcm_mpu,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
/*
* 'scrm' class
* system clock and reset manager
@@ -5305,10 +5305,10 @@ static struct omap_hwmod_addr_space
omap44xx_cm_core_aon_addrs[] = {
};
/* l4_wkup - cm_core_aon */
-static struct omap_hwmod_ocp_if omap44xx_l4_wkup__cm_core_aon = {
- .master = omap44xx_l4_wkup_hwmod,
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__cm_core_aon = {
+ .master = omap44xx_l4_cfg_hwmod,
.slave = omap44xx_cm_core_aon_hwmod,
- .clk= l4_wkup_clk_mux_ck,
+ .clk= l4_div_ck,
.addr = omap44xx_cm_core_aon_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -6101,7 +6101,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l3_main_2__ocmc_ram,
omap44xx_l4_cfg__ocp2scp_usb_phy,
omap44xx_mpu_private__prcm_mpu,
- omap44xx_l4_wkup__cm_core_aon,
+ omap44xx_l4_cfg__cm_core_aon,
omap44xx_l4_cfg__cm_core,
omap44xx_l4_wkup__prm,
omap44xx_l4_wkup__scrm,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Revert ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
This reverts commit 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c.
Conflicts:
arch/arm/mach-omap2/Makefile
Neither prm_clkdm nor cm_clkdm does exist on OMAP4.
Remove the common definition that does not make sense anymore
since it is not common for OMAP2+ platforms.
Please note that these clock domains are probably non existant
on OMAP 2 3 and thus should be removed in all the
clockdomain files.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/clockdomain44xx.c|6 -
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10 +
arch/arm/mach-omap2/clockdomains44xx_data.c |2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
5 files changed, 10 insertions(+), 33 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fa742f3..bc7d239 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -116,7 +116,6 @@ obj-$(CONFIG_ARCH_OMAP4)+=
powerdomains44xx_data.o
# PRCM clockdomain control
clockdomain-common += clockdomain.o
-clockdomain-common += clockdomains_common_data.o
obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common)
obj-$(CONFIG_ARCH_OMAP2) += clockdomain2xxx_3xxx.o
obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c
b/arch/arm/mach-omap2/clockdomain44xx.c
index 4f04dd1..935c7f0 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -51,9 +51,6 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct
clockdomain *clkdm)
struct clkdm_dep *cd;
u32 mask = 0;
- if (!clkdm-prcm_partition)
- return 0;
-
for (cd = clkdm-wkdep_srcs; cd cd-clkdm_name; cd++) {
if (!cd-clkdm)
continue; /* only happens if data is erroneous */
@@ -106,9 +103,6 @@ static int omap4_clkdm_clk_disable(struct clockdomain
*clkdm)
{
bool hwsup = false;
- if (!clkdm-prcm_partition)
- return 0;
-
hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index 839145e..0a6a048 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -89,3 +89,13 @@ struct clockdomain wkup_common_clkdm = {
.pwrdm = { .name = wkup_pwrdm },
.dep_bit= OMAP_EN_WKUP_SHIFT,
};
+
+struct clockdomain prm_common_clkdm = {
+ .name = prm_clkdm,
+ .pwrdm = { .name = wkup_pwrdm },
+};
+
+struct clockdomain cm_common_clkdm = {
+ .name = cm_clkdm,
+ .pwrdm = { .name = core_pwrdm },
+};
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index c534258..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -430,8 +430,6 @@ static struct clockdomain *clockdomains_omap44xx[]
__initdata = {
l4_wkup_44xx_clkdm,
emu_sys_44xx_clkdm,
l3_dma_44xx_clkdm,
- prm_common_clkdm,
- cm_common_clkdm,
NULL
};
diff --git a/arch/arm/mach-omap2/clockdomains_common_data.c
b/arch/arm/mach-omap2/clockdomains_common_data.c
deleted file mode 100644
index 615b1f0..000
--- a/arch/arm/mach-omap2/clockdomains_common_data.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * OMAP2+-common clockdomain data
- *
- * Copyright (C) 2008-2012 Texas Instruments, Inc.
- * Copyright (C) 2008-2010 Nokia Corporation
- *
- * Paul Walmsley, Jouni Högander
- */
-
-#include linux/kernel.h
-#include linux/io.h
-
-#include clockdomain.h
-
-/* These are implicit clockdomains - they are never defined as such in TRM */
-struct clockdomain prm_common_clkdm = {
- .name = prm_clkdm,
- .pwrdm = { .name = wkup_pwrdm },
-};
-
-struct clockdomain cm_common_clkdm = {
- .name = cm_clkdm,
- .pwrdm = { .name = core_pwrdm },
-};
--
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: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
On Mon, 11 Jun 2012, Cousson, Benoit wrote: In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 :-(. I've just realized that you introduced that for 3.5, but this is wrong. We should not start adding some fake clock domains just because the fmwk is not smart enough to allow a NULL clock domain. ... In a period of data size reduction, adding some fake information does not seems to be the right approach. Don't you think so? No, I do not. These clockdomains are clearly documented in both the OMAP4 TRM[1] and the NDA OMAP4 PRCM functional specifications. I continue to be baffled as to why you assert that they are fake, given how clearly they are documented. - Paul 1. See for example sections 3.6.6.1 Overview, Figure 3-58 CD_L4_PER Overview, Figure 3-59 CD_L3_INIT Overview, Figure 3-62 CD_EMU Overview, Figure 3-63 CD_DSS Overview, Figure 3-74 CD_L4_ALWON_CORE Overview in the OMAP4 TRM Rev. AA (SWPU231AA). -- To unsubscribe from this list: send the line unsubscribe 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: Broken builds
On Mon, 2012-06-11 at 17:06 +0100, Russell King - ARM Linux wrote: On Tue, Jun 05, 2012 at 04:20:00PM +0300, Tomi Valkeinen wrote: Hi, On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]: Looks like the DSS stuff has broken OMAP builds again during this merge window: drivers/video/omap2/dss/core.c:197: error: static declaration of 'dss_debugfs_create_file' follows non-static declaration drivers/video/omap2/dss/dss.h:166: error: previous declaration of 'dss_debugfs_create_file' was here Both the OMAP3 and OMAP4 builds break with these two errors. Here's a patch for Tomi to fix this one. I have a patch for this in my for-rc branch. It just missed the main merge. I'll send this and a few other fixes today for the next rc. Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled. That's why I didn't notice it until too late. So... where are we with this? Apparantly not much further forward; it seems to be in linux-next but still not in mainline, and mainline continues to be broken. The fixes have been pulled into fbdev tree, but it missed the -rc2. Fbdev maintainer said I merged this some days ago. Sorry that I didn't realize that rc2 would be released early and hence didn't manage to get it in. Tomi signature.asc Description: This is a digitally signed message part
Re: Broken builds
On Mon, 2012-06-11 at 17:09 +0100, Russell King - ARM Linux wrote: On Wed, Jun 06, 2012 at 12:58:00AM -0700, Tony Lindgren wrote: Tomi, please have your patches sitting in linux next for at least a week before they get merged. That usually shakes down bugs like these before the merge window. Note that tested simple bug fixes _should_ be upstreamed faster than that where possible - such as this one. I'm waiting for this to hit mainline before doing any further work on OMAP. That basically means I've been totally ignoring OMAP because of this issue for the last week. Okay. Perhaps I should have sent the patch directly to Linus, instead of sending a pull request to fbdev maintainer. There's always a possibility of delays with intermediate trees. Then again, I don't see that it's such a big problem that I'd want to skip the normal route for patches. Sure the bug is annoying, but one can easily avoid the bug by just enabling CONFIG_DEBUG_FS and CONFIG_OMAP2_DSS_DEBUG_SUPPORT. I've now improved my testing process, and I hope things will go smoother during the next merge window. Sorry about the mess. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/6] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data
On 6/11/2012 9:40 PM, Paul Walmsley wrote: Hi Vaibhav, On Mon, 11 Jun 2012, Vaibhav Hiremath wrote: I think this is not required, since Tony has already accepted the patch which has this implementation (available on linux-omap/master). Please refer to the commit, commit 08f3098928c991560408e8c71d4af8b1a3ff2d67 Author: Afzal Mohammed af...@ti.com Date: Fri May 11 00:38:49 2012 +0530 ARM: OMAP2+: am33xx: Add AM335XEVM machine support Thanks, that's what I need. Looks like our series needs to be based on this commit, rather than mainline. Yes, its already done. As you know I maintain this branch which always follows mainline and also integrates all the changes discussed on the list - https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe 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: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
On Mon, 11 Jun 2012, Benoit Cousson wrote:
The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.
Replace them with the proper wkup, l4_ao and l4_cfg.
This does not match either the publicly avaiable documentation and the
internal NDA hardware specifications[1].
Nor does it make sense from a logical perspective. To take an example
from your patch:
@@ -2564,12 +2543,33 @@ static struct omap_hwmod_rst_info
omap44xx_prm_resets[] = {
static struct omap_hwmod omap44xx_prm_hwmod = {
.name = prm,
.class = omap44xx_prcm_hwmod_class,
- .clkdm_name = prm_clkdm,
+ .clkdm_name = l4_wkup_clkdm,
.mpu_irqs = omap44xx_prm_irqs,
.rst_lines = omap44xx_prm_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_prm_resets),
};
There is no possible way that the PRM can exist in the L4_WKUP
clockdomain. The L4_WKUP clockdomain must be able to go inactive for the
chip to enter idle, as we just discussed[1]. But the PRM is the
entity that supervises chip wakeup from off-mode, so for off-mode
to work, there's no way that the PRM can be clock-gated.
Frustrating :-(
Fix as well the wrong OCP port used by the cm_core_aon. It uses the
l4_cfg interconnect and not the l4_wkup.
Re-order the entries by address value.
If you split this part off into a separate patch, I'll take it.
- Paul
1. Cousson, Benoît. _Re: [PATCH] ARM: OMAP2+: hwmod code/data: fix 32K
sync timer_. linux-omap@vger.kernel.org mailing list. Available from
http://www.spinics.net/lists/arm-kernel/msg177128.html (among others).
Re: [PATCH 2/2] Revert ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
On Mon, 11 Jun 2012, Benoit Cousson wrote: Neither prm_clkdm nor cm_clkdm does exist on OMAP4. Remove the common definition that does not make sense anymore since it is not common for OMAP2+ platforms. Please note that these clock domains are probably non existant on OMAP 2 3 and thus should be removed in all the clockdomain files. For the archives: http://marc.info/?l=linux-omapm=133943578712129w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 00/11] I2C fixes
On Monday 11 June 2012 09:30 PM, Wolfram Sang wrote: Agree, These are only fixes can it be considered for rc3? Baking in linux-next and considering rc3 don't match; baking needs time, rc3 is soon. I've put the patches now into my -next branch for more exposure. Thanks. I am still uncertain if they should be in 3.5 already; there seem to be worhty fixes in there, but they do depend on stuff which don't really qualify as bugfixes... -- To unsubscribe from this list: send the line unsubscribe 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 01/10] ARM: PMU: Add runtime PM Support
On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote: Hi Will, Hi Jon, Here is an updated version. I was going to send out a V3, but I wanted to wait to see if others had more comments first. This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!) and noticed that only the cycle counter seems to tick -- the event counters always return 0 deltas (that is, they don't increment). Booting the same SD card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the event counters function correctly there. It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these patches but I don't have any OMAP3 hardware to check if we get any regressions on older platforms. Do your patches only deal with OMAP4? Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
Hi Afzal,
On 06/11/2012 09:01 AM, Afzal Mohammed wrote:
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot be
expect to work properly unless GPMC is setup, this has been
removed.
So I think I see what you are saying, but the above is not 100% clear. I
think that what you are saying is that omap2_onenand_set_async_mode() is
attempting to configure the onenand registers before configuring the
gpmc interface and hence this is not correct.
Two instances of doing the same has been clubbed
into one as onenand driver always calls indirectly
omap2_onenand_set_sync_mode, and has placed such that
configuring onenand for async read/write would happen once
GPMC is setup for async mode (which happens even for sync
mode, before configuring to sync mode).
It may be clearer to say that _set_sync_mode is always called during
onenand setup and this will call _set_async_mode. So instead of calling
_set_async_mode from _set_sync_mode, just call it directly during the
gpmc_onenand_init().
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 71d7c07..fd4c48d 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static int omap2_onenand_set_async_mode(int cs)
{
struct gpmc_timings t;
- u32 reg;
int err;
const int t_cer = 15;
@@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
I agree with getting rid of the first instance at the beginning of
_set_async_mode, but why get rid of the above one? Are you assuming that
by default it is in async mode? Could be nice to keep it to be explicit.
return 0;
}
@@ -191,19 +181,21 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
u32 reg;
bool clk_dep = false;
+ /* Ensure sync read and sync write are disabled */
+ reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
+
Should we only set these after we have checked the flags and depending
on which flags are set?
if (cfg-flags ONENAND_SYNC_READ) {
sync_read = 1;
} else if (cfg-flags ONENAND_SYNC_READWRITE) {
sync_read = 1;
sync_write = 1;
} else
- return omap2_onenand_set_async_mode(cs, onenand_base);
+ return 0;
if (!freq) {
/* Very first call freq is not known */
- err = omap2_onenand_set_async_mode(cs, onenand_base);
- if (err)
- return err;
freq = omap2_onenand_get_freq(cfg, onenand_base, clk_dep);
first_time = 1;
}
@@ -421,6 +413,8 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_resource.end = gpmc_onenand_resource.start +
ONENAND_IO_SIZE - 1;
+ omap2_onenand_set_async_mode(gpmc_onenand_data-cs);
+
What about putting this in the gpmc_onenand_setup() function before the
call to _set_sync_mode? Seems nice to have these together.
Cheers
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
Re: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
Hi Afzal,
On 06/11/2012 09:02 AM, Afzal Mohammed wrote:
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader.
What boards have been tested with this change?
Tony is going to want to know what we have tested with such changes to
avoid any regressions.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c |6 ++
arch/arm/plat-omap/include/plat/gpmc.h |6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 578fd4c..517953f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -313,6 +313,12 @@ int gpmc_cs_set_timings(int cs, const struct
gpmc_timings *t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
+
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..802fb22 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -128,6 +128,12 @@ struct gpmc_timings {
u16 rd_cycle; /* Total read cycle time */
u16 wr_cycle; /* Total write cycle time */
+ u16 bus_turnaround;
+ u16 cycle2cycle_delay;
+
+ u16 wait_monitoring;
+ u16 clk_activation;
+
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
In general, I agree with this, but if we apply this today, it seems that
we *may* be clearing these fields if they have been configured by the
bootloader and hence this could introduce a regression (potentially).
So we ever need to test boards that this change impacts or at least
verify that this change would not impact these boards because these
fields have not been configured.
Cheers
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
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
Hi Will, On 06/11/2012 12:39 PM, Will Deacon wrote: On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote: Hi Will, Hi Jon, Here is an updated version. I was going to send out a V3, but I wanted to wait to see if others had more comments first. This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!) and noticed that only the cycle counter seems to tick -- the event counters always return 0 deltas (that is, they don't increment). Booting the same SD card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the event counters function correctly there. Thanks for the feedback. Being somewhat new to PMU, I was mainly using PERF to test and verify that with perf top I was seeing interrupts. How do I check what the event counters are returning? Any perf tests I could use? By the way, as a quick test you could modify the code in omap_init_pmu() to call omap4430_init_pmu() for all omap4 devices as follows ... if (cpu_is_omap44xx()) return omap4430_init_pmu(); I was hoping for 4460/70 we would not need to keep the debugss and other domains on and hence, I called the above function omap4430_init_pmu(). However this function works for all omap4 devices, it just turns on more power domains. It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these patches but I don't have any OMAP3 hardware to check if we get any regressions on older platforms. Do your patches only deal with OMAP4? It *should* work for all omap2+. So far I have tested an omap3 beagle but I have not tested an omap2 device. Again the extent of my testing was to run perf top and verify interrupts we being generated. I realise that this may not be sufficient and so if you have a more exhaustive test you recommend let me know. Cheers 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
Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal,
On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 31 +++
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 517953f..b471c2f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -27,6 +27,7 @@
#include asm/mach-types.h
#include plat/gpmc.h
+#include plat/omap_device.h
#include plat/sdrc.h
@@ -898,6 +899,36 @@ static int __init gpmc_init(void)
}
postcore_initcall(gpmc_init);
+__init int omap_gpmc_init(struct gpmc_pdata *pdata)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *name = omap-gpmc;
+ char *oh_name = gpmc;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(name, -1, oh, pdata,
+ sizeof(*pdata), NULL, 0, 0);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ gpmc_l3_clk = clk_get(NULL, oh-main_clk);
+ if (IS_ERR(gpmc_l3_clk)) {
+ pr_err(Could not get GPMC clock\n);
+ return PTR_ERR(gpmc_l3_clk);
+ }
My preference would be to store gpmc_l3_clk in the pdata and pass to
probe via the pdata. The aim would be to remove the global gpmc_l3_clk
altogether.
Also we should attempt to get the clk before calling omap_device_build
which is registering the driver.
Cheers
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
