Re: [PATCH pm_wip/cpufreq] OMAP2+: cpufreq: Enable all CPUs in shared policy mask
On 6/8/2011 2:27 AM, Todd Poynor wrote:
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.
Signed-off-by: Todd Poynortoddpoy...@google.com
Looks good to me.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 77efcb0..0fe4edb 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -166,7 +166,6 @@ static inline void freq_table_free(void)
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
- static cpumask_var_t cpumask;
mpu_clk = clk_get(NULL, mpu_clk_name);
if (IS_ERR(mpu_clk))
@@ -207,8 +206,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
*/
if (is_smp()) {
policy-shared_type = CPUFREQ_SHARED_TYPE_ANY;
- cpumask_or(cpumask, cpumask_of(policy-cpu), cpumask);
- cpumask_copy(policy-cpus, cpumask);
+ cpumask_setall(policy-cpus);
}
/* FIXME: what's the actual transition time? */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: iovmm: s/sg_dma_len(sg)/sg-length/
iovmm is erroneously using sg_dma_len with unmapped (DMA API-wise)
SG entries, and will break if CONFIG_NEED_SG_DMA_LENGTH is enabled.
Fix that by using sg-length instead.
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 83a37c5..c60737c 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -72,7 +72,7 @@ static size_t sgtable_len(const struct sg_table *sgt)
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
size_t bytes;
- bytes = sg_dma_len(sg);
+ bytes = sg-length;
if (!iopgsz_ok(bytes)) {
pr_err(%s: sg[%d] not iommu pagesize(%x)\n,
@@ -198,7 +198,7 @@ static void *vmap_sg(const struct sg_table *sgt)
int err;
pa = sg_phys(sg);
- bytes = sg_dma_len(sg);
+ bytes = sg-length;
BUG_ON(bytes != PAGE_SIZE);
@@ -476,7 +476,7 @@ static int map_iovm_area(struct iommu *obj, struct
iovm_struct *new,
struct iotlb_entry e;
pa = sg_phys(sg);
- bytes = sg_dma_len(sg);
+ bytes = sg-length;
flags = ~IOVMF_PGSZ_MASK;
pgsz = bytes_to_iopgsz(bytes);
--
1.7.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 v2 03/12] OMAP3: Move common pmic configuration to pmic-common
On Tuesday 07 June 2011 17:45:35 Tony Lindgren wrote: +#define TWL_COMMON_PDATA_BCI (1 1) +#define TWL_COMMON_PDATA_MADC (1 2) +#define TWL_COMMON_PDATA_CODEC (1 3) This is looking good, thanks for cleaning up the twl bloat in board-*.c files :) As I recall the first three patch results ~600 less lines of code under mach- omap2. Maybe already define TWL_COMMON_PDATA_AUDIO here so you can drop most of patch 7/12? If you need both then you can temporarily have: #define TWL_COMMON_PDATA_CODECTWL_COMMON_PDATA_AUDIO I have not thought about this. But I think we can live with the TWL_COMMON_PDATA_AUDIO all the way. I'll wait for more comments, and I'll do this for the v3. Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe 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 PATCHv4 0/7] HSI framework and drivers
Hi, On Tue, 2011-06-07 at 17:09 +0200, ext Sebastian Reichel wrote: On Tue, May 17, 2011 at 11:39:13AM +0300, Carlos Chinea wrote: We are still committed to these patches. We are aiming to release a new version in 3 weeks max, sooner if we can. I am very sorry for the delay and I agree that starting to have several out-of-tree drivers is not acceptable. I'll try my best to fix this asap. Do you also plan to add the platform code for rx51 to the mainline kernel? Not yet in this patch set. If the HSI framework makes it into the kernel, then I will try to push a couple of new HSI clients needed for rx51 and the platform related code. P.S.: 3 weeks are over today :) Yep, we are almost there with the patches :P A small problem in a last minute test is keeping us from releasing the patches already. Br, -- Carlos Chinea carlos.chi...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: McBSP: Clear rx_irq at probe time
Hi Tony, On Tuesday 31 May 2011 10:57:02 Tony Lindgren wrote: Sure, but that's the only option we have to merge any new code. So this patch will be not taken (even if without this patch OMAP4 McBSP is broken), unless we move the McBSP code out from plat-omap? I have discussed with Jarkko, and internally about the mcbsp code move. This will certainly take some time to figure out a sane way to do this. To be hones I would be surprised if we can do this for 3.1... Regards, Péter -- To unsubscribe from this list: send the line unsubscribe 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 19/27] OMAP: DSS2: Use PM runtime HWMOD support
On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote: On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote: On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote: The issue is that there is only one modulemode for the whole DSS. Potentially only the dss_hwmod should have it. But then you have to ensure that this device is enabled before any other DSS devices. Does that change anything? Isn't the above (modulemode enabled before opt clock) still true, even if it was enabled only once for the dss_core hwmod? It does not really change anything, but it is more accurate. Modulemode need to be enable after the opt clocks that act as a functional clock and before enabling HW_AUTO for the clockdomain. The important parameter is the clock domain mode change. It is another issue that we have to fix. It might not affect you for the moment. Ok. But the main issue now is the PM. If I change the clocks in hwmod data as you suggested, dss_fck will always stay enabled and prevent RET and OFF. So the fix is not acceptable even for temporary use. So is there some way to fix this, or shall we just go forward with the current patch series having the somewhat hacky way to use pm_runtime? I would personally like to get the driver right from the start, even if that means more hacks in the hwmod fmwk (because that's where the problems are). But if that is very difficult, I'm fine with the current patch series. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] x86: amd_iommu: move to drivers/iommu/
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/x86/Kconfig | 28
arch/x86/kernel/Makefile |2 +-
drivers/iommu/Kconfig | 28
drivers/iommu/Makefile |1 +
{arch/x86/kernel = drivers/iommu}/amd_iommu.c |0
5 files changed, 30 insertions(+), 29 deletions(-)
rename {arch/x86/kernel = drivers/iommu}/amd_iommu.c (100%)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 460d573..1b6a2e2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -680,34 +680,6 @@ config CALGARY_IOMMU_ENABLED_BY_DEFAULT
Calgary anyway, pass 'iommu=calgary' on the kernel command line.
If unsure, say Y.
-config AMD_IOMMU
- bool AMD IOMMU support
- select SWIOTLB
- select PCI_MSI
- select PCI_IOV
- select IOMMU_API
- depends on X86_64 PCI ACPI
- ---help---
- With this option you can enable support for AMD IOMMU hardware in
- your system. An IOMMU is a hardware component which provides
- remapping of DMA memory accesses from devices. With an AMD IOMMU you
- can isolate the the DMA memory of different devices and protect the
- system from misbehaving device drivers or hardware.
-
- You can find out if your system has an AMD IOMMU if you look into
- your BIOS for an option to enable it or if you have an IVRS ACPI
- table.
-
-config AMD_IOMMU_STATS
- bool Export AMD IOMMU statistics to debugfs
- depends on AMD_IOMMU
- select DEBUG_FS
- ---help---
- This option enables code in the AMD IOMMU driver to collect various
- statistics about whats happening in the driver and exports that
- information to userspace via debugfs.
- If unsure, say N.
-
# need this always selected by IOMMU for the VIA workaround
config SWIOTLB
def_bool y if X86_64
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 90b06d4..aef0298 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -123,7 +123,7 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
- obj-$(CONFIG_AMD_IOMMU) += amd_iommu_init.o amd_iommu.o
+ obj-$(CONFIG_AMD_IOMMU) += amd_iommu_init.o
obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o
obj-y += vsmp_64.o
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c6d667c..555f5a8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -12,3 +12,31 @@ config MSM_IOMMU
cores within the multimedia subsystem.
If unsure, say N here.
+
+config AMD_IOMMU
+ bool AMD IOMMU support
+ select SWIOTLB
+ select PCI_MSI
+ select PCI_IOV
+ select IOMMU_API
+ depends on X86_64 PCI ACPI
+ ---help---
+ With this option you can enable support for AMD IOMMU hardware in
+ your system. An IOMMU is a hardware component which provides
+ remapping of DMA memory accesses from devices. With an AMD IOMMU you
+ can isolate the the DMA memory of different devices and protect the
+ system from misbehaving device drivers or hardware.
+
+ You can find out if your system has an AMD IOMMU if you look into
+ your BIOS for an option to enable it or if you have an IVRS ACPI
+ table.
+
+config AMD_IOMMU_STATS
+ bool Export AMD IOMMU statistics to debugfs
+ depends on AMD_IOMMU
+ select DEBUG_FS
+ ---help---
+ This option enables code in the AMD IOMMU driver to collect various
+ statistics about whats happening in the driver and exports that
+ information to userspace via debugfs.
+ If unsure, say N.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index a7e66fa..d099d39 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_IOMMU_API) += iommu.o
obj-$(CONFIG_MSM_IOMMU) += msm-iommu.o
+obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o
diff --git a/arch/x86/kernel/amd_iommu.c b/drivers/iommu/amd_iommu.c
similarity index 100%
rename from arch/x86/kernel/amd_iommu.c
rename to drivers/iommu/amd_iommu.c
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] x86: intel-iommu: move to drivers/iommu/
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled
in this patch, too.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/x86/Kconfig | 11 ---
drivers/iommu/Kconfig| 11 +++
drivers/iommu/Makefile |1 +
drivers/{pci = iommu}/intel-iommu.c |1 -
drivers/pci/Makefile |2 +-
drivers/pci/pci.h|2 --
include/linux/pci.h | 11 +++
7 files changed, 24 insertions(+), 15 deletions(-)
rename drivers/{pci = iommu}/intel-iommu.c (99%)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1b6a2e2..d22662c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1912,17 +1912,6 @@ config PCI_CNB20LE_QUIRK
You should say N unless you know you need this.
-config DMAR
- bool Support for DMA Remapping Devices (EXPERIMENTAL)
- depends on PCI_MSI ACPI EXPERIMENTAL
- select IOMMU_API
- help
- DMA remapping (DMAR) devices support enables independent address
- translations for Direct Memory Access (DMA) from devices.
- These DMA remapping devices are reported via ACPI tables
- and include PCI device scope covered by these DMA
- remapping devices.
-
config DMAR_DEFAULT_ON
def_bool y
prompt Enable DMA Remapping Devices by default
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 555f5a8..b03a980 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -40,3 +40,14 @@ config AMD_IOMMU_STATS
statistics about whats happening in the driver and exports that
information to userspace via debugfs.
If unsure, say N.
+
+config DMAR
+ bool Support for DMA Remapping Devices (EXPERIMENTAL)
+ depends on PCI_MSI ACPI EXPERIMENTAL
+ select IOMMU_API
+ help
+ DMA remapping (DMAR) devices support enables independent address
+ translations for Direct Memory Access (DMA) from devices.
+ These DMA remapping devices are reported via ACPI tables
+ and include PCI device scope covered by these DMA
+ remapping devices.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index d099d39..aaac56d 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_IOMMU_API) += iommu.o
obj-$(CONFIG_MSM_IOMMU) += msm-iommu.o
obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o
+obj-$(CONFIG_DMAR) += intel-iommu.o
diff --git a/drivers/pci/intel-iommu.c b/drivers/iommu/intel-iommu.c
similarity index 99%
rename from drivers/pci/intel-iommu.c
rename to drivers/iommu/intel-iommu.c
index 59f17ac..fd7a055 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -42,7 +42,6 @@
#include linux/pci-ats.h
#include asm/cacheflush.h
#include asm/iommu.h
-#include pci.h
#define ROOT_SIZE VTD_PAGE_SIZE
#define CONTEXT_SIZE VTD_PAGE_SIZE
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index c85f744..7826920 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_PCI_MSI) += msi.o
obj-$(CONFIG_HT_IRQ) += htirq.o
# Build Intel IOMMU support
-obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o
+obj-$(CONFIG_DMAR) += dmar.o iova.o
obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 731e202..b7bf11d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -184,8 +184,6 @@ pci_match_one_device(const struct pci_device_id *id, const
struct pci_dev *dev)
return NULL;
}
-struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
-
/* PCI slot sysfs helper code */
#define to_pci_slot(s) container_of(s, struct pci_slot, kobj)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c446b5c..970bfe0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1589,5 +1589,16 @@ int pci_vpd_find_tag(const u8 *buf, unsigned int off,
unsigned int len, u8 rdt);
int pci_vpd_find_info_keyword(const u8 *buf, unsigned int off,
unsigned int len, const char *kw);
+/**
+ * pci_find_upstream_pcie_bridge - find upstream PCIe-to-PCI bridge of a device
+ * @pdev: the PCI device
+ *
+ * if the device is PCIE, return NULL
+ * if the device isn't connected to a PCIe bridge (that is its parent is a
+ * legacy PCI bridge and the bridge is directly connected to bus 0), return its
+ * parent
+ */
+struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
+
#endif /* __KERNEL__ */
#endif /* LINUX_PCI_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
[PATCH 0/4] drivers/iommu/ relocations
Create a dedicated iommu drivers folder, put the base iommu code there,
and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
intel-iommu).
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
in a generic framework, which everyone can use.
OMAP's iommu will be moved too as soon as it's migrated.
For previous discussions on this, please see:
https://lkml.org/lkml/2011/6/2/369
Ohad Ben-Cohen (4):
drivers: iommu: move to a dedicated folder
msm: iommu: move to drivers/iommu/
x86: amd_iommu: move to drivers/iommu/
x86: intel-iommu: move to drivers/iommu/
arch/arm/mach-msm/Kconfig | 15 --
arch/arm/mach-msm/Makefile |2 +-
arch/x86/Kconfig | 40 ---
arch/x86/kernel/Makefile |2 +-
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig | 53
drivers/iommu/Makefile |4 ++
{arch/x86/kernel = drivers/iommu}/amd_iommu.c |0
drivers/{pci = iommu}/intel-iommu.c |1 -
drivers/{base = iommu}/iommu.c|0
.../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0
drivers/pci/Makefile |2 +-
drivers/pci/pci.h |2 -
include/linux/pci.h| 11
16 files changed, 74 insertions(+), 62 deletions(-)
create mode 100644 drivers/iommu/Kconfig
create mode 100644 drivers/iommu/Makefile
rename {arch/x86/kernel = drivers/iommu}/amd_iommu.c (100%)
rename drivers/{pci = iommu}/intel-iommu.c (99%)
rename drivers/{base = iommu}/iommu.c (100%)
rename arch/arm/mach-msm/iommu.c = drivers/iommu/msm-iommu.c (100%)
--
To unsubscribe from this list: send the line unsubscribe 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/4] drivers: iommu: move to a dedicated folder
Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.
Grouping the various iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig |3 +++
drivers/iommu/Makefile |1 +
drivers/{base = iommu}/iommu.c |0
8 files changed, 9 insertions(+), 7 deletions(-)
create mode 100644 drivers/iommu/Kconfig
create mode 100644 drivers/iommu/Makefile
rename drivers/{base = iommu}/iommu.c (100%)
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 1516896..efb7b7d 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -205,9 +205,6 @@ config MSM_GPIOMUX
config MSM_V2_TLMM
bool
-config IOMMU_API
- bool
-
config MSM_SCM
bool
endif
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index da34972..460d573 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -685,6 +685,7 @@ config AMD_IOMMU
select SWIOTLB
select PCI_MSI
select PCI_IOV
+ select IOMMU_API
depends on X86_64 PCI ACPI
---help---
With this option you can enable support for AMD IOMMU hardware in
@@ -720,9 +721,6 @@ config SWIOTLB
config IOMMU_HELPER
def_bool (CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU)
-config IOMMU_API
- def_bool (AMD_IOMMU || DMAR)
-
config MAXSMP
bool Enable Maximum number of SMP Processors and NUMA Nodes
depends on X86_64 SMP DEBUG_KERNEL EXPERIMENTAL
@@ -1945,6 +1943,7 @@ config PCI_CNB20LE_QUIRK
config DMAR
bool Support for DMA Remapping Devices (EXPERIMENTAL)
depends on PCI_MSI ACPI EXPERIMENTAL
+ select IOMMU_API
help
DMA remapping (DMAR) devices support enables independent address
translations for Direct Memory Access (DMA) from devices.
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 3bb154d..9d51318 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -126,4 +126,6 @@ source drivers/hwspinlock/Kconfig
source drivers/clocksource/Kconfig
+source drivers/iommu/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 09f3232..2f7a71a 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -122,3 +122,4 @@ obj-y += ieee802154/
obj-y += clk/
obj-$(CONFIG_HWSPINLOCK) += hwspinlock/
+obj-$(CONFIG_IOMMU_API)+= iommu/
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4c5701c..5ab0d07 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -13,7 +13,6 @@ obj-$(CONFIG_FW_LOADER) += firmware_class.o
obj-$(CONFIG_NUMA) += node.o
obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
obj-$(CONFIG_SMP) += topology.o
-obj-$(CONFIG_IOMMU_API) += iommu.o
ifeq ($(CONFIG_SYSFS),y)
obj-$(CONFIG_MODULES) += module.o
endif
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
new file mode 100644
index 000..2c5dfb4
--- /dev/null
+++ b/drivers/iommu/Kconfig
@@ -0,0 +1,3 @@
+# IOMMU_API always gets selected by whoever wants it.
+config IOMMU_API
+ bool
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
new file mode 100644
index 000..241ba4c
--- /dev/null
+++ b/drivers/iommu/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_IOMMU_API) += iommu.o
diff --git a/drivers/base/iommu.c b/drivers/iommu/iommu.c
similarity index 100%
rename from drivers/base/iommu.c
rename to drivers/iommu/iommu.c
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] msm: iommu: move to drivers/iommu/
This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-msm/Kconfig | 12 arch/arm/mach-msm/Makefile |2 +- drivers/iommu/Kconfig | 11 +++ drivers/iommu/Makefile |1 + .../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0 5 files changed, 13 insertions(+), 13 deletions(-) rename arch/arm/mach-msm/iommu.c = drivers/iommu/msm-iommu.c (100%) diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index efb7b7d..14ebda1 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -148,18 +148,6 @@ config MACH_MSM8960_RUMI3 endmenu -config MSM_IOMMU - bool MSM IOMMU Support - depends on ARCH_MSM8X60 || ARCH_MSM8960 - select IOMMU_API - default n - help - Support for the IOMMUs found on certain Qualcomm SOCs. - These IOMMUs allow virtualization of the address space used by most - cores within the multimedia subsystem. - - If unsure, say N here. - config IOMMU_PGTABLES_L2 def_bool y depends on MSM_IOMMU MMU SMP CPU_DCACHE_DISABLE=n diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile index 9519fd2..0bf4648 100644 --- a/arch/arm/mach-msm/Makefile +++ b/arch/arm/mach-msm/Makefile @@ -3,7 +3,7 @@ obj-y += clock.o obj-$(CONFIG_DEBUG_FS) += clock-debug.o obj-$(CONFIG_MSM_VIC) += irq-vic.o -obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o devices-iommu.o +obj-$(CONFIG_MSM_IOMMU) += iommu_dev.o devices-iommu.o obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o acpuclock-arm11.o obj-$(CONFIG_ARCH_MSM7X30) += dma.o diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 2c5dfb4..c6d667c 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -1,3 +1,14 @@ # IOMMU_API always gets selected by whoever wants it. config IOMMU_API bool + +config MSM_IOMMU + bool MSM IOMMU Support + depends on ARCH_MSM8X60 || ARCH_MSM8960 + select IOMMU_API + help + Support for the IOMMUs found on certain Qualcomm SOCs. + These IOMMUs allow virtualization of the address space used by most + cores within the multimedia subsystem. + + If unsure, say N here. diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 241ba4c..a7e66fa 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_IOMMU_API) += iommu.o +obj-$(CONFIG_MSM_IOMMU) += msm-iommu.o diff --git a/arch/arm/mach-msm/iommu.c b/drivers/iommu/msm-iommu.c similarity index 100% rename from arch/arm/mach-msm/iommu.c rename to drivers/iommu/msm-iommu.c -- 1.7.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 4/4] x86: intel-iommu: move to drivers/iommu/
On Wed, 2011-06-08 at 11:34 +0300, Ohad Ben-Cohen wrote: --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -30,7 +30,7 @@ obj-$(CONFIG_PCI_MSI) += msi.o obj-$(CONFIG_HT_IRQ) += htirq.o # Build Intel IOMMU support -obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o +obj-$(CONFIG_DMAR) += dmar.o iova.o obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o At least iova.o wants to go with it. That's one of the parts that is a candidate for harmonisation across IOMMU implementations, either by removing it or by having others use it too. It's how we allocate virtual I/O address space. I suspect the interrupt remapping support may well want to move with it too. It's no more out-of-place in drivers/iommu than it is in drivers/pci. And then you can certainly move dmar.o too. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
(Cc'ing Ingo) On Wed, Jun 08, 2011 at 04:34:18AM -0400, Ohad Ben-Cohen wrote: Create a dedicated iommu drivers folder, put the base iommu code there, and move the existing IOMMU API users as well (msm-iommu, amd_iommu and intel-iommu). Putting all iommu drivers together will ease finding similarities between different platforms, with the intention of solving problems once, in a generic framework, which everyone can use. OMAP's iommu will be moved too as soon as it's migrated. Great, thanks. I'll apply the patches as soon as the relevant ACKs come in. Looking at the MAINTAINERS file David Brown needs to ACK the MSM patch and David Woodhouse the VT-d patch. David B., David W., is this direction ok for both of you? A more important question is how we handle the IOMMU tree. Currently the situation is as follows: * The AMD IOMMU changes go upstream through Ingo * David Woohouse has his own tree which he sents directly to Linus * Not sure about the ARM IOMMU code * And to comlicate things further there is the upcoming ARM integration tree which may contain code that depends on IOMMU changes My suggestion is that the ARM tree pulls in the necessary changes from the IOMMU tree and the IOMMU code goes upstream through Ingo or directly to Linus (with some time in linux-next, of course). Thoughts? Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe 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/4] x86: intel-iommu: move to drivers/iommu/
On Wed, Jun 08, 2011 at 05:17:38AM -0400, David Woodhouse wrote: On Wed, 2011-06-08 at 11:34 +0300, Ohad Ben-Cohen wrote: --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -30,7 +30,7 @@ obj-$(CONFIG_PCI_MSI) += msi.o obj-$(CONFIG_HT_IRQ) += htirq.o # Build Intel IOMMU support -obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o +obj-$(CONFIG_DMAR) += dmar.o iova.o obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o At least iova.o wants to go with it. That's one of the parts that is a candidate for harmonisation across IOMMU implementations, either by removing it or by having others use it too. It's how we allocate virtual I/O address space. I suspect the interrupt remapping support may well want to move with it too. It's no more out-of-place in drivers/iommu than it is in drivers/pci. And then you can certainly move dmar.o too. Interrupt remapping certainly makes sense too. I am not sure yet how to generalize it because the AMD version of it is significantly different from VT-d, but we'll see. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe 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 v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
Hi Russell, On Monday 06 June 2011 20:00:52 Russell King - ARM Linux wrote: On Mon, Jun 06, 2011 at 06:54:10PM +0200, Laurent Pinchart wrote: Of course not, but if the scatterlist is only touched by kernel code, it doesn't need to be contiguous in memory. It could be allocated with vmalloc(). Except vmalloc has a higher latency and a more restrictive API than other allocators (think about the coherency issues with SMP systems which may have to do TLB flushing on several cores, etc.) Right, thank you for the explanation. It is now clear to me why we want to use the page allocator and handle scatter list chaining in the critical paths. We could still use vmalloc() in the iovmm driver, but that's probably not worth it if we can enable scatter list chaining for the system. With your patch scatter list chaining can be enabled at the platform level for the ARM architecture. What are the platform requirements to enable scatter list chaining ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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/4] x86: intel-iommu: move to drivers/iommu/
On Wed, Jun 8, 2011 at 12:17 PM, David Woodhouse dw...@infradead.org wrote: At least iova.o wants to go with it. That's one of the parts that is a candidate for harmonisation across IOMMU implementations, either by removing it or by having others use it too. It's how we allocate virtual I/O address space. I suspect the interrupt remapping support may well want to move with it too. It's no more out-of-place in drivers/iommu than it is in drivers/pci. And then you can certainly move dmar.o too. Sounds good, thanks. I'll wait a bit to see if there're more comments, and then re-send this one -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/6] omap: iovmm: generic iommu api migration
Hi Ohad, On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote: On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart wrote: Right now we have a BUG_ON if pa is unaligned, but that can be changed if needed (do we want it to handle offsets ?). At least for the OMAP3 ISP we need to, as video buffers don't necessarily start on page boundaries. Where do you take care of those potential offsets today ? Or do you simply ignore the offsets and map the entire page ? Here http://marc.info/?l=linux-omapm=130693502326513w=2 :-) Seems like omap's iommu (mostly) rejects unaligned pa addresses, see: 4abb761749abfb4ec403e4054f9dae2ee604e54f omap iommu: Reject unaligned addresses at setting page table entry (this doesn't seem to cover 4KB entries though, only large pages, sections and super sections) A separate patch is indeed needed, yes. As you're already working on iommu it might be simpler if you add it to your tree. Sure, i'll send it. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 IOMMU fixes
Hi Tony, On Monday 30 May 2011 14:47:07 Laurent Pinchart wrote: Hi everybody, Here are two OMAP3 IOMMU fixes required to support big and/or unaligned memory buffers. Laurent Pinchart (2): omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU omap3: iovmm: Support non page-aligned buffers in iommu_vmap As per Russell comments, the first patch needs more work (or at least more discussions). Could you apply the second patch already ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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 v3 05/12] OMAP: Serial: Hold console lock for console usage.
Acquire console lock before enabling and writing to console-uart to avoid any recursive prints from console write. for ex: -- printk -- uart_console_write -- get_sync -- printk from omap_device enable -- uart_console write Use RPM_SUSPENDING check to avoid below scenario during bootup As during bootup console_lock is not available. -- uart_add_one_port -- console_register -- console_lock -- console_unlock -- call_console_drivers (here yet console_lock is not released) -- uart_console_write Acked-by: Alan Cox a...@linux.intel.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- drivers/tty/serial/omap-serial.c | 20 +++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 897416f..ee94291 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1008,7 +1008,22 @@ serial_omap_console_write(struct console *co, const char *s, struct uart_omap_port *up = serial_omap_console_ports[co-index]; unsigned long flags; unsigned int ier; - int locked = 1; + int console_lock = 0, locked = 1; + + if (console_trylock()) + console_lock = 1; + + /* +* If console_lock is not available and we are in suspending +* state then we can avoid the console usage scenario +* as this may introduce recursive prints. +* Basically this scenario occurs during boot while +* printing debug bootlogs. +*/ + + if (!console_lock + up-pdev-dev.power.runtime_status == RPM_SUSPENDING) + return; local_irq_save(flags); if (up-port.sysrq) @@ -1044,6 +1059,9 @@ serial_omap_console_write(struct console *co, const char *s, if (up-msr_saved_flags) check_modem_status(up); + if (console_lock) + console_unlock(); + serial_omap_port_disable(up); if (locked) spin_unlock(up-port.lock); -- 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 v3 00/12] OMAP2+: Serial: Runtime adaptation + cleanup
Converting uart driver to adapt to pm runtime api's. Code re-org + cleanup. Moving some functionality from serial.c to omap-serial.c Changes involves: 1.) Cleaning up certain uart calls from sram_idle func. 2.) Removed all types of uart clock handling code from serial.c 3.) Using hwmod_mux api enable wakeup capability for uart pad during hwmod_idle state i.e., when uart clocks are disabled we can enable io-pad wakeup capability for uart if mux_data is available for given uart. Also during during resume from idle call to uart we need to enable clocks back conditionally and this can be done only when io-pad wakeup event bit is set for uart_rx pad. So we need a hwmod api which can probe the uart pad and let us know whether a uart wakeup happened. So omap_hmwod_pad_wakeup_status api is added to meet this requirement. 3.) Adapted omap-serial driver to use runtime api's. 4.) Modify serial_init calls to accept certain uart parameters from board file. 5.) using resume_call to enable uart port back untill we have irq_chaining available. Patch series is based on 3.0-rc2. Hosted at: https://gitorious.org/runtime_3-0/runtime_3-0/commits/master Dependency Patches: -- This patch series depends on patch [1], [2] posted earlier. 3.0-rc2 needs [3] patch for core to hit low power states. [1] http://www.spinics.net/lists/arm-kernel/msg124495.html [2] http://www.spinics.net/lists/arm-kernel/msg124493.html [3] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git; a=commit;h=345f79b3de7f6d651e4dba794af7c7303bdfd649 Testing updates: 3430SDP: retention, off_mode, system_wide suspend is tested. (earlyprintk no_console_suspend checked) OMAP3630 - Zoom3: pm-retention checked, off mode for per domain checked. [uart3/uart4 in per domain on omap3630]. [ZOOM3 tested with uart3 as console uart and pm-ret checked] OMAP4430-SDP/PANDA: Boot tested. OMAP2420/2430SDP: Boot tested. - Govindraj.R (11): OMAP2+: UART: Remove certain uart calls from sram_idle OMAP2+: UART: Remove uart clock handling code from serial.c OMAP2+: Serial: Add default mux for all uarts. Serial: OMAP: Add runtime pm support for omap-serial driver OMAP: Serial: Hold console lock for console usage. Serial: OMAP2+: Move erratum handling from serial.c OMAP: Serial: Allow UART parameters to be configured from board file. OMAP3: Serial: Remove uart pads from 3430 board file. OMAP: Serial: Use resume call from prcm to enable uart OMAP2: Serial: Add has_async_wake flag. OMAP4: Serial: Set TX_FIFO_THRESHOLD if uart in dma mode for es2.0 Jon Hunter (1): Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART arch/arm/mach-omap2/board-3430sdp.c | 100 +--- arch/arm/mach-omap2/board-4430sdp.c |8 +- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c|8 +- arch/arm/mach-omap2/pm24xx.c | 19 +- arch/arm/mach-omap2/pm34xx.c | 26 +- arch/arm/mach-omap2/serial.c | 929 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 49 ++- arch/arm/plat-omap/include/plat/serial.h | 12 +- drivers/tty/serial/omap-serial.c | 336 - 10 files changed, 620 insertions(+), 873 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 v3 03/12] OMAP2+: Serial: Add default mux for all uarts.
Add default mux data for all uarts if mux info is not passed from
board file to avoid breaking any board support.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 127 +-
1 files changed, 126 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b16768a..8c1a4c7 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -66,6 +66,129 @@ static struct omap_device_pm_latency omap_uart_latency[] = {
},
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_device_pad default_uart1_pads[] __initdata = {
+ {
+ .name = uart1_cts.uart1_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart1_rts.uart1_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart1_tx.uart1_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart1_rx.uart1_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_uart2_pads[] __initdata = {
+ {
+ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart2_rx.uart2_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_uart3_pads[] __initdata = {
+ {
+ .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {
+ {
+ .name = gpmc_wait2.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = gpmc_wait3.uart4_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
+ },
+};
+
+static struct omap_device_pad default_omap4_uart4_pads[] __initdata = {
+ {
+ .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart4_rx.uart4_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+};
+#else
+static struct omap_device_pad default_uart1_pads[] __initdata = {};
+static struct omap_device_pad default_uart2_pads[] __initdata = {};
+static struct omap_device_pad default_uart3_pads[] __initdata = {};
+static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {};
+static struct omap_device_pad default_omap4_uart4_pads[] __initdata = {};
+#endif
+
+static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+{
+ switch (bdata-id) {
+ case 0:
+ bdata-pads = default_uart1_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_uart1_pads);
+ break;
+ case 1:
+ bdata-pads = default_uart2_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_uart2_pads);
+ break;
+ case 2:
+ bdata-pads = default_uart3_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_uart3_pads);
+ break;
+ case 3:
+ if (cpu_is_omap44xx()) {
+ bdata-pads = default_omap4_uart4_pads;
+ bdata-pads_cnt =
+ ARRAY_SIZE(default_omap4_uart4_pads);
+ } else {
+ bdata-pads = default_omap36xx_uart4_pads;
+ bdata-pads_cnt =
+ ARRAY_SIZE(default_omap36xx_uart4_pads);
+ }
+ break;
+ default:
+ break;
+ }
+}
+
static void omap_uart_idle_init(struct omap_uart_port_info *uart,
[PATCH v3 08/12] Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The secound timeout, RX_TIMEOUT, is a timeout after which the
DMA will be stopped if no more data is received. To make this
clearer, rename rx_timeout as rx_poll_rate and rename the
function serial_omap_rx_timeout() to serial_omap_rxdma_poll().
The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
used to indicate when the DMA for UART can be stopped if no more
data is received. The value is a global definition that is applied
to all instances of the UART.
Each UART may be used for a different purpose and so the timeout
required may differ. Make this value configurable for each UART so
that this value can be optimised for power savings.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |2 ++
arch/arm/plat-omap/include/plat/omap-serial.h |6 --
drivers/tty/serial/omap-serial.c | 15 ---
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f38296e..6ac078f 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -48,6 +48,7 @@ static struct omap_uart_port_info omap_serial_default_info[]
= {
{
.dma_enabled= 0,
.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ .dma_rx_poll_rate = DEFAULT_RXDMA_POLLRATE,
.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
.auto_sus_timeout = DEFAULT_AUTOSUSPEND_DELAY,
},
@@ -370,6 +371,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
pdata-enable_wakeup = omap_uart_wakeup_enable;
pdata-dma_enabled = info-dma_enabled;
pdata-dma_rx_buf_size = info-dma_rx_buf_size;
+ pdata-dma_rx_poll_rate = info-dma_rx_poll_rate;
pdata-dma_rx_timeout = info-dma_rx_timeout;
pdata-auto_sus_timeout = info-auto_sus_timeout;
if (bdata-id == omap_uart_con_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 4e2dcdc..c5f4dd9 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -51,8 +51,8 @@
#define OMAP_UART_DMA_CH_FREE -1
-#define RX_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */
-#define DEFAULT_RXDMA_TIMEOUT 1 /* RX DMA polling rate (us) */
+#define DEFAULT_RXDMA_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */
+#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
#define DEFAULT_AUTOSUSPEND_DELAY (30 * HZ) /* Runtime autosuspend (msecs) */
@@ -71,6 +71,7 @@ struct omap_uart_port_info {
unsigned intconsole_uart;
unsigned intdma_rx_buf_size;/* DMA Rx Buffer Size */
unsigned intdma_rx_timeout; /* DMA RX timeout */
+ unsigned intdma_rx_poll_rate; /* DMA RX timeout */
unsigned intauto_sus_timeout; /* Auto_suspend timeout */
void (*enable_wakeup)(struct platform_device *, bool);
@@ -101,6 +102,7 @@ struct uart_omap_dma {
/* timer to poll activity on rx dma */
struct timer_list rx_timer;
unsigned intrx_buf_size;
+ unsigned intrx_poll_rate;
unsigned intrx_timeout;
};
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index dc2743a..307b7c6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -48,7 +48,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
-static void serial_omap_rx_timeout(unsigned long uart_no);
+static void serial_omap_rxdma_poll(unsigned long uart_no);
static int serial_omap_start_rxdma(struct uart_omap_port *up);
static void omap_uart_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
@@ -543,7 +543,7 @@ static int serial_omap_startup(struct uart_port *port)
(dma_addr_t *)(up-uart_dma.tx_buf_dma_phys),
0);
init_timer((up-uart_dma.rx_timer));
- up-uart_dma.rx_timer.function = serial_omap_rx_timeout;
+ up-uart_dma.rx_timer.function = serial_omap_rxdma_poll;
up-uart_dma.rx_timer.data = up-pdev-id;
/* Currently the buffer size is 4KB. Can increase it */
up-uart_dma.rx_buf = dma_alloc_coherent(NULL,
@@ -1175,7
[PATCH v3 12/12] OMAP4: Serial: Set TX_FIFO_THRESHOLD if uart in dma mode for es2.0
From OMAP4430 ES2.0 onwards if uart is configured in dma mode we need to set
uart tx threshold value using the new register UART_TX_DMA_THRESHOLD, this
register can used if UART_MDR3 bit(2) is set. We have to ensure
tx_threshold + tx_trigger = 63 from es2.0 onwards. By default we are using
tx_trigger of 1 so we can set threshold to 62 to satisfy above criteria.
Without the threshold setting we hit dma_sync lost errors on tx channel
leading to data loss on rx side
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |4
arch/arm/plat-omap/include/plat/omap-serial.h | 11 +++
drivers/tty/serial/omap-serial.c |5 +
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0a95c95..437fc0b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -401,6 +401,10 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
if (bdata-id == omap_uart_con_id)
pdata-console_uart = true;
+ if (pdata-dma_enabled
+ cpu_is_omap44xx() omap_rev() OMAP4430_REV_ES1_0)
+ pdata-errata |= OMAP4_UART_ERRATA_i659_TX_THR;
+
od = omap_device_build(name, bdata-id, oh, pdata,
sizeof(*pdata), omap_uart_latency,
ARRAY_SIZE(omap_uart_latency), false);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 69e6d4b..0d10f72 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -56,12 +56,23 @@
#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
#define DEFAULT_AUTOSUSPEND_DELAY (30 * HZ) /* Runtime autosuspend (msecs) */
+/*
+ * (Errata i659) - From OMAP4430 ES 2.0 onwards set
+ * tx_threshold while using UART in DMA Mode
+ * and ensure tx_threshold + tx_trigger = 63
+ */
+#define UART_MDR3 0x20
+#define UART_TX_DMA_THRESHOLD 0x21
+#define SET_DMA_TX_THRESHOLD BIT(2)
+/* Setting TX Threshold Level to 62 */
+#define TX_FIFO_THR_LVL0x3E
#define OMAP_MAX_HSUART_PORTS 4
#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
#define UART_ERRATA_i202_MDR1_ACCESS BIT(0)
+#define OMAP4_UART_ERRATA_i659_TX_THR BIT(1)
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index dbe76f3..a9645ac 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -818,6 +818,11 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
if (up-use_dma) {
+ if (up-errata OMAP4_UART_ERRATA_i659_TX_THR) {
+ serial_out(up, UART_MDR3, SET_DMA_TX_THRESHOLD);
+ serial_out(up, UART_TX_DMA_THRESHOLD, TX_FIFO_THR_LVL);
+ }
+
serial_out(up, UART_TI752_TLR, 0);
serial_out(up, UART_OMAP_SCR,
(UART_FCR_TRIGGER_4 | UART_FCR_TRIGGER_8));
--
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 v3 01/12] OMAP2+: UART: Remove certain uart calls from sram_idle
In preparation to UART runtime conversion. Remove certain uart specific calls
from sram_idle path in pm24xx/34xx files.
These func calls will no more be used with upcoming uart runtime design.
1.) Removing console lock holding :- Now can be handled with omap-serial file
itself.
2.) omap_uart_can_sleep :- not needed driver can autosuspend based on
usage_count
and autosuspend delay.
3.) omap_uart_prepare_suspend :- omap-serial can be taken care with driver
suspend/resume hooks.
4.) Also remove individual uart_prepare/resume calls.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm24xx.c | 19 ---
arch/arm/mach-omap2/pm34xx.c | 24
arch/arm/plat-omap/include/plat/serial.h |6 --
3 files changed, 0 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index df3ded6..c405bda 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -132,27 +132,11 @@ static void omap2_enter_full_retention(void)
if (omap_irq_pending())
goto no_sleep;
- /* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
- if (!console_trylock())
- goto no_sleep;
-
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
- omap_uart_prepare_idle(2);
-
/* Jump to SRAM suspend code */
omap2_sram_suspend(sdrc_read_reg(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_POWER));
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(1);
- omap_uart_resume_idle(0);
-
- if (!is_suspending())
- console_unlock();
-
no_sleep:
if (omap2_pm_debug) {
unsigned long long tmp;
@@ -267,8 +251,6 @@ static int omap2_can_sleep(void)
{
if (omap2_fclks_active())
return 0;
- if (!omap_uart_can_sleep())
- return 0;
if (osc_ck-usecount 1)
return 0;
if (omap_dma_running())
@@ -319,7 +301,6 @@ static int omap2_pm_suspend(void)
mir1 = omap_readl(0x480fe0a4);
omap_writel(1 5, 0x480fe0ac);
- omap_uart_prepare_suspend();
omap2_enter_full_retention();
omap_writel(mir1, 0x480fe0a4);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c155c9d..ac7b7f8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -391,18 +391,9 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- /* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (!console_trylock())
- goto console_still_active;
-
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
- omap_uart_prepare_idle(2);
- omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -410,8 +401,6 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -458,8 +447,6 @@ void omap_sram_idle(void)
omap3_sram_restore_context();
omap2_sms_restore_context();
}
- omap_uart_resume_idle(0);
- omap_uart_resume_idle(1);
if (core_next_state == PWRDM_POWER_OFF)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
OMAP3430_GR_MOD,
@@ -473,14 +460,8 @@ void omap_sram_idle(void)
omap2_gpio_resume_after_idle();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(3);
}
- if (!is_suspending())
- console_unlock();
-
-console_still_active:
/* Disable IO-PAD and IO-CHAIN wakeup */
if (omap3_has_io_wakeup()
(per_next_state PWRDM_POWER_ON ||
@@ -499,8 +480,6 @@ int omap3_can_sleep(void)
{
if (!sleep_while_idle)
return 0;
- if (!omap_uart_can_sleep())
- return 0;
return 1;
}
@@ -549,7 +528,6 @@ static int
[PATCH v3 04/12] Serial: OMAP: Add runtime pm support for omap-serial driver
Adapts omap-serial driver to use pm_runtime api's.
1.) Populate reg values to uart port which can be used for context restore.
2.) Moving context_restore func to driver from serial.c
3.) Adding port_enable/disable func to enable/disable given uart port.
enable port using get_sync and disable using autosuspend.
4.) using runtime irq safe api to make get_sync be called from irq context.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 22 +++
arch/arm/plat-omap/include/plat/omap-serial.h |2 +
drivers/tty/serial/omap-serial.c | 212 ++---
3 files changed, 210 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8c1a4c7..1651c2c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -189,6 +189,27 @@ static void omap_serial_fill_default_pads(struct
omap_board_data *bdata)
}
}
+static void omap_uart_wakeup_enable(struct platform_device *pdev, bool enable)
+{
+ struct omap_uart_port_info *up = pdev-dev.platform_data;
+
+ /* Set or clear wake-enable bit */
+ if (up-wk_en up-wk_mask) {
+ u32 v = __raw_readl(up-wk_en);
+ if (enable)
+ v |= up-wk_mask;
+ else
+ v = ~up-wk_mask;
+ __raw_writel(v, up-wk_en);
+ }
+
+ /* Enable or clear io-pad wakeup */
+ if (enable)
+ omap_device_enable_ioring_wakeup(pdev);
+ else
+ omap_device_disable_ioring_wakeup(pdev);
+}
+
static void omap_uart_idle_init(struct omap_uart_port_info *uart,
unsigned short num)
{
@@ -332,6 +353,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
pdata-uartclk = OMAP24XX_BASE_BAUD * 16;
pdata-flags = UPF_BOOT_AUTOCONF;
+ pdata-enable_wakeup = omap_uart_wakeup_enable;
if (bdata-id == omap_uart_con_id)
pdata-console_uart = true;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 2ca885b..ac30de8 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,6 +65,7 @@ struct omap_uart_port_info {
unsigned interrata;
unsigned intconsole_uart;
+ void (*enable_wakeup)(struct platform_device *, bool);
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
@@ -120,6 +121,7 @@ struct uart_omap_port {
charname[20];
unsigned long port_activity;
unsigned interrata;
+ void (*enable_wakeup)(struct platform_device *, bool);
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 47cadf4..897416f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,10 +37,14 @@
#include linux/clk.h
#include linux/serial_core.h
#include linux/irq.h
+#include linux/pm_runtime.h
#include plat/dma.h
#include plat/dmtimer.h
#include plat/omap-serial.h
+#include plat/omap_device.h
+
+#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is msecs */
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
@@ -94,6 +98,17 @@ serial_omap_get_divisor(struct uart_port *port, unsigned int
baud)
return port-uartclk/(baud * divisor);
}
+static inline void serial_omap_port_disable(struct uart_omap_port *up)
+{
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
+}
+
+static inline void serial_omap_port_enable(struct uart_omap_port *up)
+{
+ pm_runtime_get_sync(up-pdev-dev);
+}
+
static void serial_omap_stop_rxdma(struct uart_omap_port *up)
{
if (up-uart_dma.rx_dma_used) {
@@ -110,8 +125,11 @@ static void serial_omap_enable_ms(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-pdev-id);
+
+ serial_omap_port_enable(up);
up-ier |= UART_IER_MSI;
serial_out(up, UART_IER, up-ier);
+ serial_omap_port_disable(up);
}
static void serial_omap_stop_tx(struct uart_port *port)
@@ -131,21 +149,26 @@ static void serial_omap_stop_tx(struct uart_port *port)
up-uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
}
+ serial_omap_port_enable(up);
if (up-ier UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
}
+
+ serial_omap_port_disable(up);
}
static void serial_omap_stop_rx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ serial_omap_port_enable(up);
if
[PATCH v3 09/12] OMAP3: Serial: Remove uart pads from 3430 board file.
The pad values here are same as the default pad values updated in
serial.c file.
Avoid structure duplication and use default pads.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 100 +--
1 files changed, 1 insertions(+), 99 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 2b44c86..4e2baf7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -553,106 +553,8 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-
-static struct omap_device_pad serial1_pads[] __initdata = {
- /*
-* Note that off output enable is an active low
-* signal. So setting this means pin is a
-* input enabled in off mode
-*/
- OMAP_MUX_STATIC(uart1_cts.uart1_cts,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_rts.uart1_rts,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_rx.uart1_rx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_tx.uart1_tx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_device_pad serial2_pads[] __initdata = {
- OMAP_MUX_STATIC(uart2_cts.uart2_cts,
-OMAP_PIN_INPUT_PULLUP |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_rts.uart2_rts,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_rx.uart2_rx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_tx.uart2_tx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_device_pad serial3_pads[] __initdata = {
- OMAP_MUX_STATIC(uart3_cts_rctx.uart3_cts_rctx,
-OMAP_PIN_INPUT_PULLDOWN |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_rts_sd.uart3_rts_sd,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_rx_irrx.uart3_rx_irrx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_tx_irtx.uart3_tx_irtx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_board_data serial1_data = {
- .id = 0,
- .pads = serial1_pads,
- .pads_cnt = ARRAY_SIZE(serial1_pads),
-};
-
-static struct omap_board_data serial2_data = {
- .id = 1,
- .pads = serial2_pads,
- .pads_cnt = ARRAY_SIZE(serial2_pads),
-};
-
-static struct omap_board_data serial3_data = {
- .id = 2,
- .pads = serial3_pads,
- .pads_cnt = ARRAY_SIZE(serial3_pads),
-};
-
-static inline void board_serial_init(void)
-{
- omap_serial_init_port(serial1_data, NULL);
- omap_serial_init_port(serial2_data, NULL);
- omap_serial_init_port(serial3_data, NULL);
-}
#else
#define board_mux NULL
-
-static inline void board_serial_init(void)
-{
- omap_serial_init();
-}
#endif
/*
@@ -789,7 +691,7 @@ static void __init omap_3430sdp_init(void)
else
gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV1;
omap_ads7846_init(1, gpio_pendown, 310, NULL);
- board_serial_init();
+ omap_serial_init();
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
--
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 v3 02/12] OMAP2+: UART: Remove uart clock handling code from serial.c
Cleanup serial.c file in preparation to addition of runtime api's in omap-serial
file. Remove all clock handling mechanism as this will be taken care with
pm runtime api's in omap-serial.c file itself.
1.) Remove omap-device enable and disable. We can can use get_sync/put_sync
api's
2.) Remove context save/restore can be done with runtime_resume callback for
get_sync call. No need to save context as all reg details available in
uart_port structure can be used for restore, so add missing regs in
uart port struct.
3.) Add func to identify console uart.
4.) Erratum handling informed as flag to driver and func to handle erratum
can be moved to omap-serial driver itself.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 754 ++---
arch/arm/plat-omap/include/plat/omap-serial.h | 15 +-
2 files changed, 74 insertions(+), 695 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 1ac361b..b16768a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -19,25 +19,18 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
#include linux/delay.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/serial_8250.h
#include linux/pm_runtime.h
-#include linux/console.h
-#ifdef CONFIG_SERIAL_OMAP
#include plat/omap-serial.h
-#endif
-
#include plat/common.h
#include plat/board.h
#include plat/clock.h
#include plat/dma.h
-#include plat/omap_hwmod.h
#include plat/omap_device.h
#include prm2xxx_3xxx.h
@@ -47,65 +40,9 @@
#include control.h
#include mux.h
-#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
-#define UART_OMAP_WER 0x17/* Wake-up enable register */
-
-#define UART_ERRATA_FIFO_FULL_ABORT(0x1 0)
-#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1)
-
-/*
- * NOTE: By default the serial timeout is disabled as it causes lost characters
- * over the serial ports. This means that the UART clocks will stay on until
- * disabled via sysfs. This also causes that any deeper omap sleep states are
- * blocked.
- */
-#define DEFAULT_TIMEOUT 0
-
-#define MAX_UART_HWMOD_NAME_LEN16
+#define MAX_UART_HWMOD_NAME_LEN16
-struct omap_uart_state {
- int num;
- int can_sleep;
- struct timer_list timer;
- u32 timeout;
-
- void __iomem *wk_st;
- void __iomem *wk_en;
- u32 wk_mask;
- u32 padconf;
- u32 dma_enabled;
-
- struct clk *ick;
- struct clk *fck;
- int clocked;
-
- int irq;
- int regshift;
- int irqflags;
- void __iomem *membase;
- resource_size_t mapbase;
-
- struct list_head node;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- u32 errata;
-#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
- int context_valid;
-
- /* Registers to be saved/restored for OFF-mode */
- u16 dll;
- u16 dlh;
- u16 ier;
- u16 sysc;
- u16 scr;
- u16 wer;
- u16 mcr;
-#endif
-};
-
-static LIST_HEAD(uart_list);
-static u8 num_uarts;
+static int omap_uart_con_id __initdata = -1;
static int uart_idle_hwmod(struct omap_device *od)
{
@@ -129,396 +66,35 @@ static struct omap_device_pm_latency omap_uart_latency[]
= {
},
};
-static inline unsigned int __serial_read_reg(struct uart_port *up,
-int offset)
-{
- offset = up-regshift;
- return (unsigned int)__raw_readb(up-membase + offset);
-}
-
-static inline unsigned int serial_read_reg(struct omap_uart_state *uart,
- int offset)
-{
- offset = uart-regshift;
- return (unsigned int)__raw_readb(uart-membase + offset);
-}
-
-static inline void __serial_write_reg(struct uart_port *up, int offset,
- int value)
-{
- offset = up-regshift;
- __raw_writeb(value, up-membase + offset);
-}
-
-static inline void serial_write_reg(struct omap_uart_state *uart, int offset,
- int value)
-{
- offset = uart-regshift;
- __raw_writeb(value, uart-membase + offset);
-}
-
-/*
- * Internal UARTs need to be initialized for the 8250 autoconfig to work
- * properly. Note that the TX watermark initialization may not be needed
- * once the 8250.c watermark handling code is merged.
- */
-
-static inline void __init omap_uart_reset(struct omap_uart_state *uart)
-{
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_OMAP_SCR, 0x08);
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
-}
-
-#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
-
-/*
- * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
- * The access to uart register after MDR1
[PATCH v3 07/12] OMAP: Serial: Allow UART parameters to be configured from board file.
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto suspend delay that will be passed for pm_runtime_autosuspend
where uart will be disabled after timeout
Different UARTs may be used for different purpose such as the console,
for interfacing bluetooth chip, for interfacing to a modem chip, etc.
Therefore, it is necessary to be able to customize the above settings
for a given board on a per UART basis.
This change allows these parameters to be configured from the board file
and allows the parameters to be configured for each UART independently.
If a board does not define its own custom parameters for the UARTs, then
use the default parameters in the structure omap_serial_default_info.
The default parameters are defined to be the same as the current settings
in the UART driver to avoid breaking the UART for any board. By default,
make all boards use the default UART parameters.
Signed-off-by: Deepak K deepa...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |6 ++--
arch/arm/mach-omap2/board-4430sdp.c |8 ++--
arch/arm/mach-omap2/board-n8x0.c |6 ++--
arch/arm/mach-omap2/board-omap4panda.c|8 ++--
arch/arm/mach-omap2/serial.c | 42 +++--
arch/arm/plat-omap/include/plat/omap-serial.h | 14 ++--
arch/arm/plat-omap/include/plat/serial.h |5 ++-
drivers/tty/serial/omap-serial.c |8 ++---
8 files changed, 71 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ae2963a..2b44c86 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -642,9 +642,9 @@ static struct omap_board_data serial3_data = {
static inline void board_serial_init(void)
{
- omap_serial_init_port(serial1_data);
- omap_serial_init_port(serial2_data);
- omap_serial_init_port(serial3_data);
+ omap_serial_init_port(serial1_data, NULL);
+ omap_serial_init_port(serial2_data, NULL);
+ omap_serial_init_port(serial3_data, NULL);
}
#else
#define board_mux NULL
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73fa90b..946a558 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -707,11 +707,11 @@ static inline void board_serial_init(void)
bdata.pads_cnt = 0;
bdata.id= 0;
/* pass dummy data for UART1 */
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
- omap_serial_init_port(serial2_data);
- omap_serial_init_port(serial3_data);
- omap_serial_init_port(serial4_data);
+ omap_serial_init_port(serial2_data, NULL);
+ omap_serial_init_port(serial3_data, NULL);
+ omap_serial_init_port(serial4_data, NULL);
}
#else
#define board_mux NULL
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 8d74318..5ab626a 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -656,15 +656,15 @@ static inline void board_serial_init(void)
bdata.pads_cnt = 0;
bdata.id = 0;
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
bdata.id = 1;
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
bdata.id = 2;
bdata.pads = serial2_pads;
bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
}
#else
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 90485fc..c402d03 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -552,11 +552,11 @@ static inline void board_serial_init(void)
bdata.pads_cnt = 0;
bdata.id= 0;
/* pass dummy data for UART1 */
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
- omap_serial_init_port(serial2_data);
- omap_serial_init_port(serial3_data);
- omap_serial_init_port(serial4_data);
+ omap_serial_init_port(serial2_data, NULL);
+ omap_serial_init_port(serial3_data, NULL);
+ omap_serial_init_port(serial4_data, NULL);
}
#else
#define board_mux NULL
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 1651c2c..f38296e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -44,6 +44,15 @@
static int omap_uart_con_id __initdata = -1;
+static struct omap_uart_port_info
[PATCH v3 10/12] OMAP: Serial: Use resume call from prcm to enable uart
Use resume idle call from prcm_irq to enable uart_port from low power states.
Add api to check pad wakeup status which will we used from uart_resume func.
to enable back uart port if a wakeup event occurred.
UART_Resume func. can be removed once we have irq_chaining functionality
available.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm24xx.c |2 ++
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/serial.c | 23 +++
arch/arm/plat-omap/include/plat/omap-serial.h |2 ++
arch/arm/plat-omap/include/plat/serial.h |1 +
drivers/tty/serial/omap-serial.c | 23 +++
6 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c405bda..ba58a1d 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -137,6 +137,8 @@ static void omap2_enter_full_retention(void)
OMAP_SDRC_REGADDR(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_POWER));
+ omap_uart_resume_idle();
+
no_sleep:
if (omap2_pm_debug) {
unsigned long long tmp;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ac7b7f8..3997e92 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -216,6 +216,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
+
+ c += omap_uart_resume_idle();
if (wkst) {
iclk = omap2_cm_read_mod_reg(module, iclk_off);
fclk = omap2_cm_read_mod_reg(module, fclk_off);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 6ac078f..4bc5914 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -199,6 +199,28 @@ static void omap_serial_fill_default_pads(struct
omap_board_data *bdata)
}
}
+/* TBD: Will be removed once we have irq-chaing mechanism */
+static bool omap_uart_chk_wakeup(struct platform_device *pdev)
+{
+ struct omap_uart_port_info *up = pdev-dev.platform_data;
+ struct omap_device *od;
+ u32 wkst = 0;
+ bool ret = false;
+
+ od = to_omap_device(pdev);
+ if (omap_hmwod_pad_get_wakeup_status(od-hwmods[0]))
+ ret = true;
+
+ /* Check for normal UART wakeup (and clear it) */
+ wkst = __raw_readl(up-wk_st) up-wk_mask;
+ if (wkst) {
+ __raw_writel(wkst, up-wk_st);
+ ret = true;
+ }
+
+ return ret;
+}
+
static void omap_uart_wakeup_enable(struct platform_device *pdev, bool enable)
{
struct omap_uart_port_info *up = pdev-dev.platform_data;
@@ -369,6 +391,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
pdata-uartclk = OMAP24XX_BASE_BAUD * 16;
pdata-flags = UPF_BOOT_AUTOCONF;
pdata-enable_wakeup = omap_uart_wakeup_enable;
+ pdata-chk_wakeup = omap_uart_chk_wakeup;
pdata-dma_enabled = info-dma_enabled;
pdata-dma_rx_buf_size = info-dma_rx_buf_size;
pdata-dma_rx_poll_rate = info-dma_rx_poll_rate;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index c5f4dd9..b5117bd 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -75,6 +75,7 @@ struct omap_uart_port_info {
unsigned intauto_sus_timeout; /* Auto_suspend timeout */
void (*enable_wakeup)(struct platform_device *, bool);
+ bool (*chk_wakeup)(struct platform_device *);
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
@@ -132,6 +133,7 @@ struct uart_omap_port {
unsigned long port_activity;
unsigned interrata;
void (*enable_wakeup)(struct platform_device *, bool);
+ bool (*chk_wakeup)(struct platform_device *);
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index ee758d4..44a42aa 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -109,6 +109,7 @@ extern void omap_serial_init(void);
extern void omap_serial_board_init(struct omap_uart_port_info *platform_data);
extern void omap_serial_init_port(struct omap_board_data *bdata,
struct omap_uart_port_info *platform_data);
+extern u32 omap_uart_resume_idle(void);
#endif
#endif
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 307b7c6..c3561dd 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,7 @@
#include plat/dmtimer.h
#include plat/omap-serial.h
#include
[PATCH v3 06/12] Serial: OMAP2+: Move erratum handling from serial.c
Move the erratum handling mechanism from serial.c to driver file
and utilise the same func. in driver file.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/tty/serial/omap-serial.c | 57 ++---
1 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ee94291..2ad8fa0 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -52,6 +52,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
static void serial_omap_rx_timeout(unsigned long uart_no);
static int serial_omap_start_rxdma(struct uart_omap_port *up);
+static void omap_uart_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
static inline unsigned int serial_in(struct uart_omap_port *up, int offset)
{
@@ -807,7 +808,11 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_MCR, up-mcr);
/* Protocol, Baud Rate, and Interrupt Settings */
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, up-mdr1);
+ else
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
+
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up-efr = serial_in(up, UART_EFR);
@@ -832,7 +837,10 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
else
up-mdr1 = UART_OMAP_MDR1_16X_MODE;
- serial_out(up, UART_OMAP_MDR1, up-mdr1)
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, up-mdr1);
+ else
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
/* Hardware Flow Control Configuration */
@@ -1447,11 +1455,48 @@ static int serial_omap_remove(struct platform_device
*dev)
return 0;
}
+/*
+ * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
+ * The access to uart register after MDR1 Access
+ * causes UART to corrupt data.
+ *
+ * Need a delay =
+ * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
+ * give 10 times as much
+ */
+static void omap_uart_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
+{
+ u8 timeout = 255;
+
+ serial_out(up, UART_OMAP_MDR1, mdr1);
+ udelay(2);
+ serial_out(up, UART_FCR, up-fcr | UART_FCR_CLEAR_XMIT |
+ UART_FCR_CLEAR_RCVR);
+ /*
+* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
+* TX_FIFO_E bit is 1.
+*/
+ while (UART_LSR_THRE != (serial_in(up, UART_LSR)
+ (UART_LSR_THRE | UART_LSR_DR))) {
+ timeout--;
+ if (!timeout) {
+ /* Should *never* happen. we warn and carry on */
+ dev_crit(up-pdev-dev, Errata i202: timedout %x\n,
+ serial_in(up, UART_LSR));
+ break;
+ }
+ udelay(1);
+ }
+}
+
static void omap_uart_restore_context(struct uart_omap_port *up)
{
u16 efr = 0;
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
+ else
+ serial_out(up, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
serial_out(up, UART_LCR, 0xBF); /* Config B mode */
efr = serial_in(up, UART_EFR);
serial_out(up, UART_EFR, UART_EFR_ECB);
@@ -1468,8 +1513,10 @@ static void omap_uart_restore_context(struct
uart_omap_port *up)
serial_out(up, UART_LCR, 0xBF); /* Config B mode */
serial_out(up, UART_EFR, efr);
serial_out(up, UART_LCR, up-lcr);
- /* UART 16x mode */
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, up-mdr1);
+ else
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
}
static int omap_serial_runtime_suspend(struct device *dev)
--
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 v3 11/12] OMAP2: Serial: Add has_async_wake flag.
Prior to this patch the uart_clock was cut using prepare/resume calls since
these funcs are no more available with runtime changes use has_async_wake
flag to keep clock active during bootup otherwise uart port will disabled
during boot-up and cannot be enabled back. Also based on this flag we can
disable uart port during suspend and enable back during resume for omap_socs
that have not set has_async_wake.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |1 +
arch/arm/plat-omap/include/plat/omap-serial.h |3 +++
drivers/tty/serial/omap-serial.c | 14 ++
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 4bc5914..0a95c95 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -266,6 +266,7 @@ static void omap_uart_idle_init(struct omap_uart_port_info
*uart,
break;
}
uart-wk_mask = wk_mask;
+ uart-has_async_wake = true;
} else if (cpu_is_omap24xx()) {
u32 wk_mask = 0;
u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index b5117bd..69e6d4b 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -79,6 +79,7 @@ struct omap_uart_port_info {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
+ boolhas_async_wake;
};
struct uart_omap_dma {
@@ -134,6 +135,8 @@ struct uart_omap_port {
unsigned interrata;
void (*enable_wakeup)(struct platform_device *, bool);
bool (*chk_wakeup)(struct platform_device *);
+
+ boolhas_async_wake;
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c3561dd..dbe76f3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1181,6 +1181,13 @@ static int serial_omap_suspend(struct device *dev)
uart_suspend_port(serial_omap_reg, up-port);
console_trylock();
serial_omap_pm(up-port, 3, 0);
+
+ /* OMAP2 dont have async wakeup from prcm.
+* For such socs clocks will be kept active from probe and
+* cut only in suspend path.
+*/
+ if (!up-has_async_wake)
+ serial_omap_port_disable(up);
}
return 0;
}
@@ -1192,6 +1199,9 @@ static int serial_omap_resume(struct device *dev)
if (up) {
uart_resume_port(serial_omap_reg, up-port);
console_unlock();
+
+ if (!up-has_async_wake)
+ serial_omap_port_enable(up);
}
return 0;
@@ -1415,6 +1425,7 @@ static int serial_omap_probe(struct platform_device *pdev)
up-errata = omap_up_info-errata;
up-enable_wakeup = omap_up_info-enable_wakeup;
up-chk_wakeup = omap_up_info-chk_wakeup;
+ up-has_async_wake = omap_up_info-has_async_wake;
if (omap_up_info-dma_enabled) {
up-uart_dma.uart_dma_tx = dma_tx-start;
@@ -1443,6 +1454,9 @@ static int serial_omap_probe(struct platform_device *pdev)
serial_omap_port_disable(up);
}
+ if (!up-has_async_wake)
+ serial_omap_port_enable(up);
+
ui[pdev-id] = up;
serial_omap_add_console_port(up);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
On Wed, Jun 08, 2011 at 11:34:18AM +0300, Ohad Ben-Cohen wrote: Create a dedicated iommu drivers folder, put the base iommu code there, and move the existing IOMMU API users as well (msm-iommu, amd_iommu and intel-iommu). Putting all iommu drivers together will ease finding similarities between different platforms, with the intention of solving problems once, in a generic framework, which everyone can use. OMAP's iommu will be moved too as soon as it's migrated. For previous discussions on this, please see: https://lkml.org/lkml/2011/6/2/369 Ohad Ben-Cohen (4): drivers: iommu: move to a dedicated folder msm: iommu: move to drivers/iommu/ x86: amd_iommu: move to drivers/iommu/ x86: intel-iommu: move to drivers/iommu/ You've missed at least parisc, ia64, alpha, sparc, powerpc and sh which have IOMMUs. Not that they necessarily all need to be moved across in one patchset, but saying all iommu drivers is clearly false. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To unsubscribe from this list: send the line unsubscribe 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 00/11] crypto: omap-sham driver fixes
On Thu, Jun 02, 2011 at 09:10:02PM +0300, Dmitry Kasatkin wrote: Hi, Recently we got crashes few times after some other patches to 2.6.32 kernel. This patch set greatly prevents race condition situations. No crashes are noticed any more. Now the driver should be ok for multi core as well. All applied to cryptodev. Thanks Dmitry! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
On Wed, Jun 8, 2011 at 4:05 PM, Matthew Wilcox matt...@wil.cx wrote: You've missed at least parisc, ia64, alpha, sparc, powerpc and sh which have IOMMUs. None of these seem to call register_iommu. Not that they necessarily all need to be moved across in one patchset, but saying all iommu drivers is clearly false. I've moved only the existing IOMMU API users. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
On Wed, Jun 08, 2011 at 09:11:16AM -0400, Ohad Ben-Cohen wrote: On Wed, Jun 8, 2011 at 4:05 PM, Matthew Wilcox matt...@wil.cx wrote: You've missed at least parisc, ia64, alpha, sparc, powerpc and sh which have IOMMUs. None of these seem to call register_iommu. Not that they necessarily all need to be moved across in one patchset, but saying all iommu drivers is clearly false. I've moved only the existing IOMMU API users. And I think that is good for now. The iommu-api needs to be extended to cover all kinds of iommus (like the iommus available on other architectures). It is definitly the plan to do that and have a common dma_ops implementation for all of them. But lets start small by now and move forward step by step :-) Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Clock PM breakage in 3.0-rc2
Hi While debugging another issue I noticed that McBSP2 clock on Nokia N900 doesn't get disabled in 3.0-rc2 after calling pm_runtime_put_sync(mcbsp-dev) and the fclk usecount remains active if the pm_runtime_get_sync(mcbsp-dev) was ever called activating it. I believe this affects other drivers too as the system is not able to enter into retention idle even if the mcbsp clocks are off. I traced breakage to commit 638080c (OMAP2+ / PM: move runtime PM implementation to use device power domains). Reventing that and and 2064af9 (PM: Revert driver core: platform_bus: allow runtime override of dev_pm_ops) makes both mcbsp clocks and retention idle working again. Unfortunately I'm not able to see quickly what would be the right fix. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
* Roedel, Joerg joerg.roe...@amd.com wrote: (Cc'ing Ingo) On Wed, Jun 08, 2011 at 04:34:18AM -0400, Ohad Ben-Cohen wrote: Create a dedicated iommu drivers folder, put the base iommu code there, and move the existing IOMMU API users as well (msm-iommu, amd_iommu and intel-iommu). Putting all iommu drivers together will ease finding similarities between different platforms, with the intention of solving problems once, in a generic framework, which everyone can use. OMAP's iommu will be moved too as soon as it's migrated. Great, thanks. I'll apply the patches as soon as the relevant ACKs come in. Looking at the MAINTAINERS file David Brown needs to ACK the MSM patch and David Woodhouse the VT-d patch. David B., David W., is this direction ok for both of you? A more important question is how we handle the IOMMU tree. Currently the situation is as follows: * The AMD IOMMU changes go upstream through Ingo * David Woohouse has his own tree which he sents directly to Linus * Not sure about the ARM IOMMU code * And to comlicate things further there is the upcoming ARM integration tree which may contain code that depends on IOMMU changes My suggestion is that the ARM tree pulls in the necessary changes from the IOMMU tree and the IOMMU code goes upstream through Ingo or directly to Linus (with some time in linux-next, of course). Thoughts? I can certainly pull from you trees you pull from elsewhere. David could help keep things tidier by sending the Intel IOMMU bits to me as well. In any case the tip:core/iommu tree is in linux-next so whatever you send me shows up there on the next day or so. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] GPIO: OMAP fixes for v3.0-rc
On Tue, Jun 07, 2011 at 05:08:27PM -0700, Kevin Hilman wrote: Grant, Here's a small set of OMAP GPIO fixes for v3.0-rc. Thanks, Kevin Merged, thanks. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] omap3: pm: Downgrade WARN for no wakeup source
When multiple wakeup sources are defined in a system,
there is a small window, when more than one source
can trigger wakeup interrupt.
In the current implementation, the do-while() loop
can handle all wakeup sources that are recorded when
probing the status register in prcm_interrupt_handler().
When the ISR executes due to next queued wakeup, it
there is nothing to be handled and value of c is 0.
The comment in the code, attributing this behavior to
race with IVA2 along with WARN (and associated text)
makes this condition appear as an error condition -
while it isn't.
Though the problem was found in kernel version 2.6.32
running on AM3703 (no IVA2), it is still relevant.
This patch also fixes the comment that attributes current
behavior to race with interrupt handler on IVA2.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Quoting specific instances, on entry into the ISR, the
PM_WKST_WKUP read either 0x00010101 or 0x00010001
Where,
Bit 0 : ST_GPT1 - GPTIMER wakeup occurred
Bit 8 : ST_IO_EN- IO pad wakeup occurred
Bit 16 : ST_IO_CHAIN - The I/O wake-up scheme is enabled
This time value of c is 2 (or 3), but then on next
and immediate entry, value of c is 0 leading to WARN().
Another approach I considered was to keep track of the
number of wakeup sources handled in previous execution
of ISR, but it fails when status register indicates 3
wakeup sources.
Downgrading the WARN seemed to be the simplest solution.
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c155c9d..d24942b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -289,11 +289,12 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
c = _prcm_int_handle_wakeup();
/*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
+* If multiple wakeup events get handled in certain
+* execution through this do-while, value of c will
+* be returned as 0.
*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
+ if (c == 0)
+ pr_debug (prcm: no more wakeup event to
handle) ;
} else {
/* XXX we need to expand our PRCM interrupt handler */
WARN(1, prcm: WARNING: PRCM interrupt received, but
--
1.7.2.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] omap: iovmm: s/sg_dma_len(sg)/sg-length/
Hi Ohad, Thanks for the patch. On Wednesday 08 June 2011 08:43:55 Ohad Ben-Cohen wrote: iovmm is erroneously using sg_dma_len with unmapped (DMA API-wise) SG entries, and will break if CONFIG_NEED_SG_DMA_LENGTH is enabled. Fix that by using sg-length instead. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Ohad Ben-Cohen o...@wizery.com Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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/4] x86: intel-iommu: move to drivers/iommu/
* Ohad Ben-Cohen (o...@wizery.com) wrote: + +config DMAR + bool Support for DMA Remapping Devices (EXPERIMENTAL) + depends on PCI_MSI ACPI EXPERIMENTAL You may want to further restrict to x86 and ia64 And I think you'll need to fixup arch/ia64/Kconfig BTW, I think EXPERIMENTAL can be dropped by now. -- To unsubscribe from this list: send the line unsubscribe 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: Clock PM breakage in 3.0-rc2
Jarkko Nikula jhnik...@gmail.com writes: While debugging another issue I noticed that McBSP2 clock on Nokia N900 doesn't get disabled in 3.0-rc2 after calling pm_runtime_put_sync(mcbsp-dev) and the fclk usecount remains active if the pm_runtime_get_sync(mcbsp-dev) was ever called activating it. I believe this affects other drivers too as the system is not able to enter into retention idle even if the mcbsp clocks are off. I traced breakage to commit 638080c (OMAP2+ / PM: move runtime PM implementation to use device power domains). Reventing that and and 2064af9 (PM: Revert driver core: platform_bus: allow runtime override of dev_pm_ops) makes both mcbsp clocks and retention idle working again. Unfortunately I'm not able to see quickly what would be the right fix. This should be fixed in my for_3.0/pm-fixes branch (pull req. sent to Tony earlier this week.) Specifically, the OMAP: PM: omap_device: fix device power domain callbacks patch should fix your problem Can you test again with merging that branch from: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit
Menon, Nishanth n...@ti.com writes: On Tue, Jun 7, 2011 at 16:49, Kevin Hilman khil...@ti.com wrote: Nishanth Menon n...@ti.com writes: Since we do module_init, cpufreq initializes before power late_init where many of the required data structures are registered. What exactly are the dependencies here? The only thing I see is the dependency on omap2_get_mpuss_device(), and those devices should be created as a postcore_initcall. If there are other dependencies, they're probably created a side effect of your earlier patches where you moved stuff from the -init hook (which happens much later) into the initcall function. Maybe that needs a rethink? Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on which the build depends is bool and does'nt support modules yet. Signed-off-by: Nishanth Menon n...@ti.com If this works, it's only because of the link order defined by the Makefile ordering since both are the same level of initcall. When I move this driver to drivers/cpufreq, then the link order is less obvious. the issue is as follows: currently we dont do voltage transitions. when we do that eventually(and my current code has an forked implementation of dvfs, the following steps happen): late_initcall(omap2_common_pm_late_init); does pmic inits, omap_voltage_late_init, init_voltages and SR dev initialization without these, there is no way to transition MPU to proper voltage, frequency combination. The requirement will have to be that omap2-cpufreq.c allows for cpufreq transitions only after voltage and clk layers are ready for transitions - if we ever want to do dvfs - which we will eventually need to. Yes, I understand. But $SUBJECT patch is fixing this as an _init_ time ordering problem, What you're describing is a runtime requirement that doesn't exist until a DVFS transition is done. IOW, the requirement is that the voltage etc. layers have to be init'd before the first transition. So, rather than fix this with initcall ordering (which will have to be redone as things git moved and converted to modules), just create a type of late init function in this driver, which gets called on the first transition. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit
On Wed, Jun 8, 2011 at 13:51, Kevin Hilman khil...@ti.com wrote:
[..]
the issue is as follows:
currently we dont do voltage transitions. when we do that
eventually(and my current code has an forked implementation of dvfs,
the following steps happen):
late_initcall(omap2_common_pm_late_init);
does pmic inits, omap_voltage_late_init, init_voltages and SR dev
initialization
without these, there is no way to transition MPU to proper voltage,
frequency combination. The requirement will have to be that
omap2-cpufreq.c allows for cpufreq transitions only after voltage and
clk layers are ready for transitions - if we ever want to do dvfs -
which we will eventually need to.
Yes, I understand.
But $SUBJECT patch is fixing this as an _init_ time ordering problem,
What you're describing is a runtime requirement that doesn't exist until
a DVFS transition is done. IOW, the requirement is that the voltage
etc. layers have to be init'd before the first transition.
So, rather than fix this with initcall ordering (which will have to be
redone as things git moved and converted to modules), just create a type
of late init function in this driver, which gets called on the first
transition.
The tricky part ofcourse is for the registration - if we do the
registration, omap_cpu_init will get called once the registration
happens - no reason to stop it, which in turn triggers omap_target the
moment the governors are ready to do their thing. Is the following
what you are talking about? I am not completely sure how this helps..
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 77efcb0..8586df8 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -253,6 +253,11 @@ static struct cpufreq_driver omap_driver = {
.attr = omap_cpufreq_attr,
};
+static int __init omap_cpufreq_lateinit(void)
+{
+ return cpufreq_register_driver(omap_driver);
+}
+
static int __init omap_cpufreq_init(void)
{
if (cpu_is_omap24xx()) {
@@ -277,8 +282,7 @@ static int __init omap_cpufreq_init(void)
pr_warning(%s: unable to get the mpu device\n, __func__);
return -EINVAL;
}
-
- return cpufreq_register_driver(omap_driver);
+ return 0;
}
static void __exit omap_cpufreq_exit(void)
@@ -288,5 +292,6 @@ static void __exit omap_cpufreq_exit(void)
MODULE_DESCRIPTION(cpufreq driver for OMAP2PLUS SOCs);
MODULE_LICENSE(GPL);
+late_initcall(omap_cpufreq_lateinit);
module_init(omap_cpufreq_init);
module_exit(omap_cpufreq_exit);
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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/4] x86: intel-iommu: move to drivers/iommu/
On Wed, Jun 8, 2011 at 8:47 PM, Chris Wright chr...@sous-sol.org wrote: You may want to further restrict to x86 and ia64 And I think you'll need to fixup arch/ia64/Kconfig BTW, I think EXPERIMENTAL can be dropped by now. Sounds all good, thanks a lot ! -- To unsubscribe from this list: send the line unsubscribe 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 00/11] crypto: omap-sham driver fixes
Thanks! On Wed, Jun 8, 2011 at 4:08 PM, Herbert Xu herb...@gondor.apana.org.au wrote: On Thu, Jun 02, 2011 at 09:10:02PM +0300, Dmitry Kasatkin wrote: Hi, Recently we got crashes few times after some other patches to 2.6.32 kernel. This patch set greatly prevents race condition situations. No crashes are noticed any more. Now the driver should be ok for multi core as well. All applied to cryptodev. Thanks Dmitry! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe 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 v3 04/12] Serial: OMAP: Add runtime pm support for omap-serial driver
Hi Govindraj, On 6/8/2011 6:23 AM, Govindraj.R wrote: [snip] + +#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is msecs */ [snip] @@ -1295,18 +1381,36 @@ static int serial_omap_probe(struct platform_device *pdev) up-uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE; } + pm_runtime_use_autosuspend(pdev-dev); + pm_runtime_set_autosuspend_delay(pdev-dev, + OMAP_UART_AUTOSUSPEND_DELAY); Something is weird here...DEFAULT_AUTOSUSPEND_DELAY is defined as (30*HZ) which would appear to be jiffies (ticks per second) and NOT msecs. However, pm_runtime_set_autosuspend is clearly expecting msecs. So this seems to conflict. By default 30*HZ for omap would be 30*128 = 3840ms so not quite 4 seconds. What were you intending here? 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 19/27] OMAP: DSS2: Use PM runtime HWMOD support
On 6/8/2011 9:55 AM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote:
On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
The issue is that there is only one modulemode for the whole DSS.
Potentially only the dss_hwmod should have it. But then you have to
ensure that this device is enabled before any other DSS devices.
Does that change anything? Isn't the above (modulemode enabled before
opt clock) still true, even if it was enabled only once for the dss_core
hwmod?
It does not really change anything, but it is more accurate.
Modulemode need to be enable after the opt clocks that act as a
functional clock and before enabling HW_AUTO for the clockdomain.
The important parameter is the clock domain mode change. It is another
issue that we have to fix. It might not affect you for the moment.
Ok. But the main issue now is the PM. If I change the clocks in hwmod
data as you suggested, dss_fck will always stay enabled and prevent RET
and OFF. So the fix is not acceptable even for temporary use.
Mmm, the issue is probably due to the way we are managing interface
clock that are usually able to autoidle. Because of that the
_disable_clocks function will not try to disable an interface clock
except if you use the following flag: OCPIF_SWSUP_IDLE.
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
.master = omap44xx_l3_main_2_hwmod,
.slave = omap44xx_dss_hwmod,
.clk= dss_fck,
.addr = omap44xx_dss_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
.user = OCP_USER_SDMA,
+ .flags = OCPIF_SWSUP_IDLE,
So is there some way to fix this, or shall we just go forward with the
current patch series having the somewhat hacky way to use pm_runtime?
I would personally like to get the driver right from the start, even if
that means more hacks in the hwmod fmwk (because that's where the
problems are). But if that is very difficult, I'm fine with the current
patch series.
I hope we'll be able to fix the fmwk for 3.0.1.
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: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit
Menon, Nishanth n...@ti.com writes:
On Wed, Jun 8, 2011 at 13:51, Kevin Hilman khil...@ti.com wrote:
[..]
the issue is as follows:
currently we dont do voltage transitions. when we do that
eventually(and my current code has an forked implementation of dvfs,
the following steps happen):
late_initcall(omap2_common_pm_late_init);
does pmic inits, omap_voltage_late_init, init_voltages and SR dev
initialization
without these, there is no way to transition MPU to proper voltage,
frequency combination. The requirement will have to be that
omap2-cpufreq.c allows for cpufreq transitions only after voltage and
clk layers are ready for transitions - if we ever want to do dvfs -
which we will eventually need to.
Yes, I understand.
But $SUBJECT patch is fixing this as an _init_ time ordering problem,
What you're describing is a runtime requirement that doesn't exist until
a DVFS transition is done. IOW, the requirement is that the voltage
etc. layers have to be init'd before the first transition.
So, rather than fix this with initcall ordering (which will have to be
redone as things git moved and converted to modules), just create a type
of late init function in this driver, which gets called on the first
transition.
The tricky part ofcourse is for the registration - if we do the
registration, omap_cpu_init will get called once the registration
happens - no reason to stop it, which in turn triggers omap_target the
moment the governors are ready to do their thing.
Yes.
Is the following what you are talking about? I am not completely sure
how this helps..
No. I was thinking of doing registration as it is today, but have a
late hook that is called in the driver's-target() callback that checks
if the other frameworks are ready.
But now I see now that -target() is called right after -init(), so I
don't think this helps. Sheesh. The PM init sequence/dependencies
right now are a complete mess.
Probably a better solution to this, would be to actually create a
platform driver out of our CPUfreq driver. Then, PM core late init
would just register the platform device when it's ready. This would
also work if/when the CPUfreq driver is a module.
Kevin
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 77efcb0..8586df8 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -253,6 +253,11 @@ static struct cpufreq_driver omap_driver = {
.attr = omap_cpufreq_attr,
};
+static int __init omap_cpufreq_lateinit(void)
+{
+ return cpufreq_register_driver(omap_driver);
+}
+
static int __init omap_cpufreq_init(void)
{
if (cpu_is_omap24xx()) {
@@ -277,8 +282,7 @@ static int __init omap_cpufreq_init(void)
pr_warning(%s: unable to get the mpu device\n, __func__);
return -EINVAL;
}
-
- return cpufreq_register_driver(omap_driver);
+ return 0;
}
static void __exit omap_cpufreq_exit(void)
@@ -288,5 +292,6 @@ static void __exit omap_cpufreq_exit(void)
MODULE_DESCRIPTION(cpufreq driver for OMAP2PLUS SOCs);
MODULE_LICENSE(GPL);
+late_initcall(omap_cpufreq_lateinit);
module_init(omap_cpufreq_init);
module_exit(omap_cpufreq_exit);
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
For OMAP1, which is ARMv5 or lower, device memory becomes
'uncacheable, unbufferable' which is luckily what is used for the
DMA coherent memory on those platforms - so no technical problem
here.
However, on ARMv6 and later, ioremapped memory is device memory,
which has different ordering wrt normal memory mappings, and may
appear on different busses on the CPU's interface. So, this is
something I don't encourage as it's unclear that the hardware will
work.
Essentially, dma_declare_coherent_memory() on ARM with main SDRAM
should be viewed as a 'it might work, it might not, and it might
stop working in the future' kind of interface. In other words,
there is no guarantee that this kind of thing will be supported in
the future.
I was affraid of an unswer of this kind. I'm not capable of comming
out with any better, alternative solutions. Any hints other than
giving up with that old videobuf-contig, coherent memory based
interface? Or can we agree on that 'luckily uncacheable,
unbufferable, SDRAM based DMA coherent memory' solution for now?
Russell, Tony,
Sorry for getting back to this old thread, but since my previous
attempts to provide[1] or support[2] a possibly better solution to the
problem all failed on one hand, and I can see patches not very different
from mine[3] being accepted for arch/arm/mach-{mx3,imx} during this and
previous merge windows[4][5][6] on the other, is there any chance for the
'dma_declare_coherent_memory() over a memblock_alloc()-free()-remove()
obtained area' based solution being accepted for omap1_camera as well if
I resend it refreshed?
BTW, commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any
page in a pageblock is reserved before marking it MIGRATE_RESERVE,
almost corrected the problem for me, allowing for very stable device
operation in videobuf_dma_contig mode once all resident programs get
settled up and no unusual activity happens, but this is still not 100%
reliable, so I think that only using a kind of memory area reservered
during boot for the purpose can be considered as free of transient
-ENOMEM issues.
Thanks,
Janusz
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036551.html
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034643.html
[4]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=164f7b5237cca2701dd2943928ec8d078877a28d
[5]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=031e912741746e4350204bb0436590ca0e993a7d
[6]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=dca7c0b4293a06d1ed9387e729a4882896abccc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
On 06/07/11 14:15, Alexander Holler wrote: Am 07.06.2011 11:50, schrieb Igor Grinberg: On 06/07/11 11:01, Alexander Holler wrote: Am 31.05.2011 12:29, schrieb Tony Lindgren: * Alexander Hollerhol...@ahsoftware.de [110405 06:38]: Without msecure beeing high it isn't possible to set (or start) the RTC. Tested with a BeagleBoard C4. Adding this into fixes. Tony Signed-off-by: Alexander Hollerhol...@ahsoftware.de --- arch/arm/mach-omap2/board-omap3beagle.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 46d814a..ebe3a7e 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void) usb_ehci_init(ehci_pdata); omap3beagle_flash_init(); +/* Ensure msecure is mux'd to be able to set the RTC. */ +omap_mux_init_signal(sys_drm_msecure, OMAP_PIN_OFF_OUTPUT_HIGH); + /* Ensure SDRC pins are mux'd for self-refresh */ omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT); omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT); -- 1.7.3.4 I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC. (Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround). --- arch/arm/mach-omap2/board-omap3beagle.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 33007fd..24b4417 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void) usbhs_init(usbhs_bdata); omap3beagle_flash_init(); + /* Ensure msecure is high to be able to set the RTC. */ + omap_mux_init_signal(gpio_22, OMAP_PIN_OFF_OUTPUT_HIGH); + gpio_request(22, msecure); + gpio_direction_output(22, true); Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22. You need the gpio_22 in the mux_init, so using a define would imho introduce a potential source for an error, at least when the define would not be anywhere near the gpio_22 and someone would forget change the string too, when he changes the define. So I don't think a define adds much value there. Why not leave sys_drm_msecure for mux_init, or does it make troubles on XM? What about gpio_request_one()? To conform with the rest of the file and mach-omap2/*. -- 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
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr,
paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
For OMAP1, which is ARMv5 or lower, device memory becomes
'uncacheable, unbufferable' which is luckily what is used for the
DMA coherent memory on those platforms - so no technical problem
here.
However, on ARMv6 and later, ioremapped memory is device memory,
which has different ordering wrt normal memory mappings, and may
appear on different busses on the CPU's interface. So, this is
something I don't encourage as it's unclear that the hardware will
work.
Essentially, dma_declare_coherent_memory() on ARM with main SDRAM
should be viewed as a 'it might work, it might not, and it might
stop working in the future' kind of interface. In other words,
there is no guarantee that this kind of thing will be supported in
the future.
I was affraid of an unswer of this kind. I'm not capable of comming
out with any better, alternative solutions. Any hints other than
giving up with that old videobuf-contig, coherent memory based
interface? Or can we agree on that 'luckily uncacheable,
unbufferable, SDRAM based DMA coherent memory' solution for now?
Russell, Tony,
Sorry for getting back to this old thread, but since my previous
attempts to provide[1] or support[2] a possibly better solution to the
problem all failed on one hand, and I can see patches not very different
from mine[3] being accepted for arch/arm/mach-{mx3,imx} during this and
previous merge windows[4][5][6] on the other, is there any chance for the
'dma_declare_coherent_memory() over a memblock_alloc()-free()-remove()
obtained area' based solution being accepted for omap1_camera as well if
I resend it refreshed?
I stand by my answer to your patches quoted above from a technical point
of view; we should not be mapping SDRAM using device mappings.
That ioremap() inside dma_declare_coherent_memory() needs to die, but
it seems that those who now look after the DMA API really aren't
interested in the technical details of this being wrong for some
architecture - just like they're not really interested in the details
of devices using dma-engines for their DMA support.
I'm afraid that the DMA support in Linux sucks because of this, and I
have no real desire to participate in discussions with brick walls over
this.
Certainly the memblock_alloc()+free()+remove() is the right way to
reserve the memory, but as it stands dma_declare_coherent_memory()
should not be used on ARMv6 or higher CPUs to pass that memory to the
device driver.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
On Wed, Jun 08 2011, Roedel, Joerg wrote: Great, thanks. I'll apply the patches as soon as the relevant ACKs come in. Looking at the MAINTAINERS file David Brown needs to ACK the MSM patch and David Woodhouse the VT-d patch. David B., David W., is this direction ok for both of you? I think it is a good direction to move in. I'll reply to the patch directly to comment on it. My suggestion is that the ARM tree pulls in the necessary changes from the IOMMU tree and the IOMMU code goes upstream through Ingo or directly to Linus (with some time in linux-next, of course). Thoughts? This seems the cleanest to me. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe 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/4] msm: iommu: move to drivers/iommu/
On Wed, Jun 08 2011, Ohad Ben-Cohen wrote: This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-msm/Kconfig | 12 arch/arm/mach-msm/Makefile |2 +- drivers/iommu/Kconfig | 11 +++ drivers/iommu/Makefile |1 + .../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0 5 files changed, 13 insertions(+), 13 deletions(-) rename arch/arm/mach-msm/iommu.c = drivers/iommu/msm-iommu.c (100%) Moving the driver is good. I'm wondering what we should do with iommu_dev.c, though. Wouldn't it make sense to move this file as well? I've added the author, Stepan Moskovchenko, in case he has any feedback. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Thu 09 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote: I stand by my answer to your patches quoted above from a technical point of view; we should not be mapping SDRAM using device mappings. That ioremap() inside dma_declare_coherent_memory() needs to die, Then how about your alternative, ARM specific solution, Avoid aliasing mappings in DMA coherent allocator? There was a series of initially two, then three patches, of which the two others (459c1517f987 ARM: DMA: Replace page_to_dma()/dma_to_page() with pfn_to_dma()/dma_to_pfn() and 9eedd96301ca ARM: DMA: top-down allocation in DMA coherent region) are already in the mainline tree. I'm still porting a copy of that third one from kernel version to version to have my device working 100% reliably, in hope you finally push it into the mainline. No plans against it? Or is there something about it I could help with? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] calling runtime PM from system PM methods
Rafael J. Wysocki r...@sisk.pl writes:
[...]
you need to separate the system suspend handling from runtime PM.
/me risks getting yelled at again and jumps back in ;)
Each of them requires a different approach, because the goal is really
different in both cases (basically, runtime PM triggers when the
device is _known_ to be idle, while system suspend may trigger while
it's actually being used).
OK, but from the driver's perspective, the goals do not seem all that
different to me:
Runtime suspend
1. activity
2. activity finishes
3. device is _known_ to be idle
4. trigger device low-power transition
system suspend [echo mem /sys/power/state]
1. activity
2. prevent future activity, halt/wait for current activity
3. device is _known_ to be idle
4. trigger device low-power transition
The only difference is step 2. In runtime suspend, the activity
finishes on its own, in system suspend, the activity is forcibly
stopped. In either case, after that point the device is known to be
idle, and proceeding from there is identical. IOW, based on the above,
another way of looking at system PM is forcing idle so that runtime PM
can happen.
I think it's important to note the similarities as well as the
differences. Maybe I'm still really blind here, but I cannot see how
they can be completely decoupled.
More specifically, what should be the approach in system suspend when a
device is already runtime suspended? If you treat runtime and system PM
as completely independent, you would have to runtime resume the device
so that it can then be immediately system suspended.
For many (if not all) devices though, what I suspect we would want is
for devices that are runtime suspended to stay runtime suspended across
a system suspend *and* resume. That would mean that the device power
domain would not call system PM callbacks on devices that are runtime
suspended.
At least for device power domains where the low-power state is identical
between runtime suspend and system suspend, this makes a lot of sense
(to me.) Device power domain -suspend might look something like this
(obviously not tested):
if (pm_runtime_suspended(dev))
return;
pm_generic_suspend(dev);
magic_device_idle(dev); /* HW-specific, shared with runtime PM */
priv-flags |= MY_DEVICE_SYS_SUSPENDED;
and -resume():
if (priv-flags MY_DEVICE_SYS_SUSPENDED) {
magic_device_enable(dev);
pm_generic_resume(dev);
}
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
On 08.06.2011 23:57, Igor Grinberg wrote: On 06/07/11 14:15, Alexander Holler wrote: Am 07.06.2011 11:50, schrieb Igor Grinberg: On 06/07/11 11:01, Alexander Holler wrote: Am 31.05.2011 12:29, schrieb Tony Lindgren: * Alexander Hollerhol...@ahsoftware.de [110405 06:38]: Without msecure beeing high it isn't possible to set (or start) the RTC. Tested with a BeagleBoard C4. Adding this into fixes. Tony Signed-off-by: Alexander Hollerhol...@ahsoftware.de --- arch/arm/mach-omap2/board-omap3beagle.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 46d814a..ebe3a7e 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void) usb_ehci_init(ehci_pdata); omap3beagle_flash_init(); +/* Ensure msecure is mux'd to be able to set the RTC. */ +omap_mux_init_signal(sys_drm_msecure, OMAP_PIN_OFF_OUTPUT_HIGH); + /* Ensure SDRC pins are mux'd for self-refresh */ omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT); omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT); -- 1.7.3.4 I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC. (Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround). --- arch/arm/mach-omap2/board-omap3beagle.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 33007fd..24b4417 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void) usbhs_init(usbhs_bdata); omap3beagle_flash_init(); + /* Ensure msecure is high to be able to set the RTC. */ + omap_mux_init_signal(gpio_22, OMAP_PIN_OFF_OUTPUT_HIGH); + gpio_request(22, msecure); + gpio_direction_output(22, true); Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22. You need the gpio_22 in the mux_init, so using a define would imho introduce a potential source for an error, at least when the define would not be anywhere near the gpio_22 and someone would forget change the string too, when he changes the define. So I don't think a define adds much value there. Why not leave sys_drm_msecure for mux_init, or does it make troubles on XM? There is nothing wrong with the small patch which uses sys_drm_msecure. It's short and does everything which is needed to use the RTC. I've posted the solution with the use of the GPIO-mode only as an alternative because the drm-mode isn't explained in the TRM (I assume one has to sign a NDA to get more informations on that). So it is not obvious what my first patch does. Using sys_drm_msecure works because it seems to be always off, at least on the BeagleBoards. The additional functionality in my second patch to turn off possible modifications on the RTC through switching the GPIO is most likely just an educational feature, I don't think someone will ever use that. I don't have any preferences which solution will end in the kernel, I just wanted to offer the second one too. What about gpio_request_one()? To conform with the rest of the file and mach-omap2/*. Below is an updated version. The gpio_export() might be removed too. Regards, Alexander From: Alexander Holler hol...@ahsoftware.de Date: Thu, 19 May 2011 11:42:05 +0200 Subject: [PATCH v3] arm: omap3: beagle: Ensure msecure is mux'd and high to be able to set the RTC Without msecure beeing high it isn't possible to set (or start) the RTC. Tested with a BeagleBoard C4. Signed-off-by: Alexander Holler hol...@ahsoftware.de --- arch/arm/mach-omap2/board-omap3beagle.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 33007fd..4c9e26e 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -673,6 +673,11 @@ static void __init omap3_beagle_init(void) usbhs_init(usbhs_bdata); omap3beagle_flash_init(); + /* Ensure msecure is high to be able to set the RTC. */ + omap_mux_init_signal(gpio_22, OMAP_PIN_OFF_OUTPUT_HIGH); + gpio_request_one(22, GPIOF_OUT_INIT_HIGH, msecure); + gpio_export(22, false); + /* Ensure SDRC pins are mux'd for self-refresh */ omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
Re: [PATCH v3 04/12] Serial: OMAP: Add runtime pm support for omap-serial driver
On Thu, Jun 9, 2011 at 2:09 AM, Jon Hunter jon-hun...@ti.com wrote: Hi Govindraj, On 6/8/2011 6:23 AM, Govindraj.R wrote: [snip] + +#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is msecs */ [snip] @@ -1295,18 +1381,36 @@ static int serial_omap_probe(struct platform_device *pdev) up-uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE; } + pm_runtime_use_autosuspend(pdev-dev); + pm_runtime_set_autosuspend_delay(pdev-dev, + OMAP_UART_AUTOSUSPEND_DELAY); Something is weird here...DEFAULT_AUTOSUSPEND_DELAY is defined as (30*HZ) which would appear to be jiffies (ticks per second) and NOT msecs. However, pm_runtime_set_autosuspend is clearly expecting msecs. So this seems to conflict. By default 30*HZ for omap would be 30*128 = 3840ms so not quite 4 seconds. What were you intending here? Intention is to get approx 3 secs timeout for autosuspend. -- Thanks, Govindraj.R Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-serial in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] calling runtime PM from system PM methods
Hi Kevin, On Thu, Jun 9, 2011 at 7:50 AM, Kevin Hilman khil...@ti.com wrote: Rafael J. Wysocki r...@sisk.pl writes: [...] you need to separate the system suspend handling from runtime PM. /me risks getting yelled at again and jumps back in ;) =) Each of them requires a different approach, because the goal is really different in both cases (basically, runtime PM triggers when the device is _known_ to be idle, while system suspend may trigger while it's actually being used). OK, but from the driver's perspective, the goals do not seem all that different to me: Runtime suspend 1. activity 2. activity finishes 3. device is _known_ to be idle 4. trigger device low-power transition system suspend [echo mem /sys/power/state] 1. activity 2. prevent future activity, halt/wait for current activity 3. device is _known_ to be idle 4. trigger device low-power transition The only difference is step 2. In runtime suspend, the activity finishes on its own, in system suspend, the activity is forcibly stopped. In either case, after that point the device is known to be idle, and proceeding from there is identical. IOW, based on the above, another way of looking at system PM is forcing idle so that runtime PM can happen. I agree with the view that system wide suspend is similar to force idle in the case of a non-wakeup device. If you flip that around then from a device driver perspective, system wide suspend on a device which is a wakeup source looks like forcing enable. This is how I see the system wide suspend including wakeup support: 1. activity (In case of an ethernet device for instance, the network may be up or down) 2. save current state 3. prevent future activity, halt/wait for current activity 4. device is _known_ to be idle 5. if wakeup is enabled, force enable regardless of state in step 1 above 6. trigger device low-power transition (if possible) For system wide resume: 1. wake up from low-power state (if needed) 2. if wakeup was enabled, force idle - similar to suspend step 3 above 3. device is _known_ to be idle 4. restore state saved in suspend step 2 above 5. activity (Also, make sure no interrupts are lost) The two roles for each wakeup-capable driver, and switching between those adds quite a bit of complexity. The absolute best part is the interrupt leakage between the wakeup state and the real state. Almost impossible to get right. =) / magnus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
