[PATCHv3 1/1] OMAP3: AM3505/3517 do not have IO wakeup capability
AM3505/3517 don't have IO wakeup capability, so we don not need to set
the bit OMAP3430_EN_IO and the bit OMAP3430_EN_IO_CHAIN in the register
PM_WKEN_WKUP when the system enters retention.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/id.c |2 ++
arch/arm/mach-omap2/pm34xx.c |7 ---
arch/arm/plat-omap/include/plat/cpu.h |2 ++
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37b8a1a..67bd971 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -179,6 +179,8 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, ISP);
if (cpu_is_omap3630())
omap3_features |= OMAP3_HAS_192MHZ_CLK;
+ if (!cpu_is_omap3505() !cpu_is_omap3517())
+ omap3_features |= OMAP3_HAS_IO_WAKEUP;
/*
* TODO: Get additional info (where applicable)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b88737f..fb4994a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -385,8 +385,9 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON) {
+ if (omap3_has_io_wakeup() \
+ (per_next_state PWRDM_POWER_ON ||
+ core_next_state PWRDM_POWER_ON)) {
prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
@@ -479,7 +480,7 @@ void omap_sram_idle(void)
}
/* Disable IO-PAD and IO-CHAIN wakeup */
- if (core_next_state PWRDM_POWER_ON) {
+ if (omap3_has_io_wakeup() core_next_state PWRDM_POWER_ON) {
prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
omap3_disable_io_chain();
}
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..aa2f4f0 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -444,6 +444,7 @@ extern u32 omap3_features;
#define OMAP3_HAS_NEON BIT(3)
#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
+#define OMAP3_HAS_IO_WAKEUPBIT(6)
#define OMAP3_HAS_FEATURE(feat,flag) \
static inline unsigned int omap3_has_ ##feat(void) \
@@ -457,5 +458,6 @@ OMAP3_HAS_FEATURE(iva, IVA)
OMAP3_HAS_FEATURE(neon, NEON)
OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
+OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
#endif
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mm: iommu: An API to unify IOMMU, CPU and device memory management
Andi Kleen wrote:
Zach Pfeffer zpfef...@codeaurora.org writes:
This patch contains the documentation for and the main header file of
the API, termed the Virtual Contiguous Memory Manager. Its use would
allow all of the IOMMU to VM, VM to device and device to IOMMU
interoperation code to be refactored into platform independent code.
I read all the description and it's still unclear what advantage
this all has over the current architecture?
At least all the benefits mentioned seem to be rather nebulous.
Can you describe a concrete use case that is improved by this code
directly?
Sure. On a SoC with many IOMMUs (10-100), where each IOMMU may have
its own set of page-tables or share page-tables, and where devices
with and without IOMMUs and CPUs with or without MMUS want to
communicate, an abstraction like the VCM helps manage all conceivable
mapping topologies. In the same way that the Linux MM manages pages
apart from page-frames, the VCMM allows the Linux MM to manage ideal
memory regions, VCMs, apart from the actual memory region.
One real scenario would be video playback from a file on a memory
card. To read and display the video, a DMA engine would read blocks of
data from the memory card controller into memory. These would
typically be managed using a scatter-gather list. This list would be
mapped into a contiguous buffer of the video decoder's IOMMU. The
video decoder would write into a buffer mapped by the display engine's
IOMMU as well as the CPU (if the kernel needed to intercept the
buffers). In this instance, the video decoder's IOMMU and the display
engine's IOMMU use different page-table formats.
Using the VCM API, this topology can be created without worrying about
the device's IOMMUs or how to map the buffers into the kernel, or how
to interoperate with the scatter-gather list. The call flow would would go:
1. Establish a memory region for the video decoder and the display engine
that's 128 MB and starts at 0x1000.
vcm_out = vcm_create(0x1000, SZ_128M);
2. Associate the memory region with the video decoder's IOMMU and the
display engine's IOMMU.
avcm_dec = vcm_assoc(vcm_out, video_dec_dev, 0);
avcm_disp = vcm_assoc(vcm_out, disp_dev, 0);
The 2 dev_ids, video_dec_dev and disp_dev allow the right IOMMU
low-level functions to be called underneath.
3. Actually program the underlying IOMMUs.
vcm_activate(avcm_dec);
vcm_activate(avcm_disp);
4. Allocate 2 physical buffers that the DMA engine and video decoder will
use. Make sure each buffer is 64 KB contiguous.
buf_64k = vcm_phys_alloc(MT0, 2*SZ_64K, VCM_64KB);
5. Allocate a 16 MB buffer for the output of the video decoder and the
input of the display engine. Use 1MB, 64KB and 4KB blocks to map the
buffer.
buf_frame = vcm_phys_alloc(MT0, SZ_16M);
6. Program the DMA controller.
buf = vcm_get_next_phys_addr(buf_64k, NULL, len);
while (buf) {
dma_prg(buf);
buf = vcm_get_next_phys_addr(buf_64k, NULL, len);
}
7. Create virtual memory regions for the DMA buffers and the video
decoder output from the vcm_out region. Make sure the buffers are
aligned to the buffer size.
res_64k = vcm_reserve(vcm_out, 8*SZ_64K, VCM_ALIGN_64K);
res_16M = vcm_reserve(vcm_out, SZ_16M, VCM_ALIGN_16M);
8. Connect the virtual reservations with the physical allocations.
vcm_back(res_64k, buf_64k);
vcm_back(res_16M, buf_frame);
9. Program the decoder and the display engine with addresses from the
IOMMU side of the mapping:
base_64k = vcm_get_dev_addr(res_64k);
base_16M = vcm_get_dev_addr(res_16M);
10. Create a kernel mapping to read and write the 16M buffer.
cpu_vcm = vcm_create_from_prebuilt(VCM_PREBUILT_KERNEL);
11. Create a reservation on that prebuilt VCM. Use any alignment.
res_cpu_16M = vcm_reserve(cpu_vcm, SZ_16M, 0);
12. Back the reservation using the same physical memory that the
decoder and the display engine are looking at.
vcm_back(res_cpu_16M, buf_frame);
13. Get a pointer that kernel can dereference.
base_cpu_16M = vcm_get_dev_addr(res_cpu_16M);
The general point of the VCMM is to allow users a higher level API
than the current IOMMU abstraction provides that solves the general
mapping problem. This means that all of the common mapping code would
be written once. In addition, the API allows all the low level details
of IOMMU programing and VM interoperation to be handled at the right
level.
Eventually the following functions could all be reworked and their
users could call VCM functions.
arch/arm/plat-omap/iovmm.c
map_iovm_area()
arch/m68k/sun3/sun3dvma.c
dvma_map_align()
arch/alpha/kernel/pci_iommu.c
pci_map_single_1()
arch/powerpc/platforms/pasemi/iommu.c
iobmap_build()
arch/powerpc/kernel/iommu.c
iommu_map_page()
arch/sparc/mm/iommu.c
iommu_map_dma_area()
arch/sparc/kernel/pci_sun4v_asm.S
ENTRY(pci_sun4v_iommu_map)
arch/ia64/hp/common/sba_iommu.c
sba_map_page()
arch/arm/mach-omap2/iommu2.c
omap2_iommu_init()
arch/arm/plat-omap/iovmm.c
Re: [PATCH] smsc95xx: Add module parameter to override MAC address
On 06/25/2010 03:25 AM, Simon Horman wrote: On Thu, Jun 24, 2010 at 10:14:14AM +0200, Sebastien Jan wrote: Define a new module parameter 'macaddr' to override the MAC address fetched either from eeprom, or randomly generated. The expected MAC address shall be in the 01:23:45:67:89:AB format. I'm confused as to why this is desirable when the mac address can already be configured after module insertion via smsc95xx_netdev_ops.eth_mac_addr(). For example for booting over NFS using a pre-defined MAC address, with a minimal setup (no initrd). Or is there another way to force a MAC address for this use-case? -- To unsubscribe from this list: send the line unsubscribe 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/8] OMAP3: Adding Smartreflex and Voltage driver support
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, June 25, 2010 4:55 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH 0/8] OMAP3: Adding Smartreflex and Voltage driver support Thara Gopinath th...@ti.com writes: This patch series introduces smartreflex and voltage driver support for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. Originally all the functionalities introduced in this patch were present in arch/arm/mach-omap2/smartreflex.c file in Kevin's pm tree. This patch series does a major rewrite of this file and introduces a separate voltage driver. Major contributors to the original driver are I just noticed that one thing missing from this series compared to what was in the previous PM branch is the disable/enable of SR in the idle path, so SR is not getting exercised during idle anymore in the current PM branch. Could you rememdy that please with another patch on top of this series (the new pm-sr branch?) Kevin Hello Kevin, This was intentional as there is not voltage scaling happening in the idle thread in pm-sr branch. Smartreflex needs to be disabled only if a voltage scaling is done during retention/off. I had submitted a patch for addressing this and removing all voltage refrences in pm34xx.c against origin/pm branch the link to which is below https://patchwork.kernel.org/patch/103086/ Regards Thara -- To unsubscribe from this list: send the line unsubscribe 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] omap: hwspinlock: Added hwspinlock driver
Hi Simon, On 6/25/2010 2:40 AM, Que, Simon wrote: Hi, We are introducing a kernel driver for hardware spinlock, called hwspinlock. It is designed to interface with the OMAP4 hardware spinlock module. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization will set aside some spinlocks as reserved for special-purpose use. All other locks can be used by anyone. This is configurable using a Kconfig option. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c Why using a Kconfig option in that case? You can reserve the locks at run time based on other driver request. The goal of the hwspinlock is to protect data shared between various processors inside OMAP4 like ipu, iva, dsp and mpu. So in anycase the syslink driver can request the needed locks at init time on behalf of the dsp or the ipu. Since you don't even know the number of locks because it is determined at init time, you cannot know at build time that information. You should add an API to reserve some locks at run time instead of doing that. The driver takes in data passed in device initialization. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address provided by the device initialization. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. int hwspinlock_lock_irqsave(struct hwspinlock *, unsigned long *); Same as hwspinlock_lock, but disables interrupts and preemption int hwspinlock_trylock_irqsave(struct hwspinlock *, unsigned long *); Same as hwspinlock_trylock, but disables interrupts and preemption int hwspinlock_unlock_irqrestore(struct hwspinlock *, unsigned long); Same as hwspinlock_unlock, but restores interrupts and preemption struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of an unreserved hardware spinlock. If no more locks are available, returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a reserved hardware spinlock. This allows the system to use a specific reserved lock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Please see the below patch contents, or the attached patch, and provide feedback. Signed-off-by: Simon Ques...@ti.com Cc: Hari Kanigerih-kanige...@ti.com = diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 9f73d79..a13c188 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -182,3 +182,13 @@ config OMAP3_SDRC_AC_TIMING wish to say no. Selecting yes without understanding what is going on could result in system crashes; +config OMAP_HWSPINLOCK_NUM_RESERVED + int Number of hardware spinlocks reserved for system use + depends on ARCH_OMAP + default 8 + range 0 32 + help + Choose a number of hardware spinlocks to reserve for internal use. + The rest will be unreserved and availble for general use. Make + that the number of reserved locks does not exceed the total number + available locks. diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6725b3a..14af19a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -170,3 +170,5 @@ obj-y += $(nand-m) $(nand-y) smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o obj-y += $(smc91x-m) $(smc91x-y) + +obj-y += hwspinlocks.o \ No newline at end of file diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-omap2/hwspinlocks.c new file mode 100644 index 000..de813a0 --- /dev/null +++ b/arch/arm/mach-omap2/hwspinlocks.c @@ -0,0 +1,126 @@ +/* + * OMAP hardware spinlock driver + * + * Copyright (C) 2010 Texas Instruments. All rights reserved. + * + * Contact: Simon Ques...@ti.com
Re: [PATCH] smsc95xx: Add module parameter to override MAC address
Hi Sebastien, I'm confused as to why this is desirable when the mac address can already be configured after module insertion via smsc95xx_netdev_ops.eth_mac_addr(). For example for booting over NFS using a pre-defined MAC address, with a minimal setup (no initrd). Or is there another way to force a MAC address for this use-case? I can't see an existing way of specifying this as a kernel parameter in Documentation/kernel-parameters.txt. netdev= doesn't have a mac address parameter. During development I initially had smsc95xx driver using this logic to select a MAC address: 1. If net-dev_addr has already been set to a valid mac address (i.e. by an administrator before bringing the device up) then use that address. 2. If the device is already currently set to a valid mac address then use that address. This could have been set by either the device's EEPROM or by a previously running bootloader. 3. Generate a random mac address. Unfortunately, this doesn't work so well as the usbnet framework sets net-dev_addr to the USB node_id before calling our bind function, so we usually matched at step 1 (and not with the desired outcome). So I removed step 1 because, as Simon mentioned, it's possible to change the mac address after the device is brought up. I can see you have a different use case, but I don't think this specific driver is the place for this logic. I'd rather see it added to either the usbnet framework or (preferably) the netdev framework so *all* ethernet drivers can do this the same way. otherwise we could end up with slight variations of this code in every single driver! Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] omap: generic: introduce a single check_revision
On Wed, Jun 23, 2010 at 5:16 AM, Nishanth Menon n...@ti.com wrote: Introduce a single omap generic check_revision that routes the request to the right revision of check_revision. Cc: Tony Lindgren t...@atomide.com Cc: Angelo Arrifano mik...@gmail.com Cc: Zebediah C. McClure z...@lurian.net Cc: Alistair Buxton a.j.bux...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Sanjeev Premi pr...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Senthilvadivu Gurusamy svad...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Tomi Valkeinen tomi.valkei...@nokia.com Cc: Aaro Koskinen aaro.koski...@nokia.com Cc: Vikram Pandita vikram.pand...@ti.com Cc: Vishwanath S vishw...@ti.com Cc: linux-omap@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap1/io.c | 3 +-- arch/arm/mach-omap2/io.c | 2 +- arch/arm/plat-omap/common.c | 12 arch/arm/plat-omap/include/plat/cpu.h | 13 - 4 files changed, 26 insertions(+), 4 deletions(-) snip diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index fca73cd..538e170 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -89,6 +89,18 @@ void __init omap_reserve(void) omap_vram_reserve_sdram_lmb(); } +void __init omap_check_revision() minor nitpick: void __init omap_check_revision(void)? -- To unsubscribe from this list: send the line unsubscribe 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-SR] [PATCH] OMAP: PM: Remove the usage of vdd id's.
[Reply 1/2]
Gopinath, Thara had written, on 06/24/2010 10:02 AM, the following:
This patch removes the usage of vdd and sr id alltogether.
good.. thanks for doing this :). /me had enough of them ;)
This is achieved by introducing a separte voltage domain per
VDD and hooking this up with the voltage and smartreflex
internal info structure. Any user of voltage or smartreflex layer
should call into omap_volt_domain_get to get the voltage
domain handle and make use of this to call into the various
exported API's.
These changes should be part of V2 of the sr/voltage series
instead of being a separate patch in itself.
Apologies on the spam, but it does look like the reply never reached l-o due to
size! I will split the reply into two parts if possible
This series seems to do a lot more than sr id, vdd id removal.. mebbe
splitting this series was easier for review - after spending an hr of
cross refering the humungous patch to code, i am all set to have a break ;).
I know the series will get squashed anyways, but helps review. anyways,
my attempt at giving some sane comments below.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|4 +
arch/arm/mach-omap2/pm-debug.c|2 +-
arch/arm/mach-omap2/smartreflex-class3.c | 26 +-
arch/arm/mach-omap2/smartreflex.c | 115 +++--
arch/arm/mach-omap2/sr_device.c | 14 +-
arch/arm/mach-omap2/voltage.c | 697
+
arch/arm/mach-omap2/voltage.h | 126 -
arch/arm/plat-omap/include/plat/smartreflex.h | 41 +-
arch/arm/plat-omap/include/plat/voltage.h | 137 +
9 files changed, 617 insertions(+), 545 deletions(-)
delete mode 100644 arch/arm/mach-omap2/voltage.h
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
what is the motivation for plat/voltage.h? are we expecting external
users other than voltage related layers to use this? are all APIs
required to be exposed?
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 074347f..c4f9abc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -265,6 +265,7 @@ static struct omap_sr_dev_data omap34xx_sr1_dev_attr = {
.test_sennenable= 0x3,
.test_senpenable= 0x3,
.test_nvalues = omap34xx_sr1_test_nvalues,
+ .vdd_name = mpu,
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
@@ -294,6 +295,7 @@ static struct omap_sr_dev_data omap36xx_sr1_dev_attr = {
.test_sennenable= 0x1,
.test_senpenable= 0x1,
.test_nvalues = omap36xx_sr1_test_nvalues,
+ .vdd_name = mpu,
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
@@ -328,6 +330,7 @@ static struct omap_sr_dev_data omap34xx_sr2_dev_attr = {
.test_sennenable= 0x3,
.test_senpenable= 0x3,
.test_nvalues = omap34xx_sr2_test_nvalues,
+ .vdd_name = core,
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
@@ -356,6 +359,7 @@ static struct omap_sr_dev_data omap36xx_sr2_dev_attr = {
.test_sennenable= 0x1,
.test_senpenable= 0x1,
.test_nvalues = omap36xx_sr2_test_nvalues,
+ .vdd_name = core,
minor nitpick - we should standardize on l3 or core - I like core as
it is a little more precise but i see usage mixed up in
arch/arm/mach-omap2/*.[ch] - just a side note..
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 9ed7146..82bb032 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -31,11 +31,11 @@
#include plat/board.h
#include plat/powerdomain.h
#include plat/clockdomain.h
+#include plat/voltage.h
#include prm.h
#include cm.h
#include pm.h
-#include voltage.h
int omap2_pm_debug;
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index f3b766f..0b5c824 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -14,36 +14,36 @@
#include plat/smartreflex.h
#include smartreflex-class3.h
-#include voltage.h
-static int sr_class3_enable(int id)
+static int sr_class3_enable(struct omap_volt_domain *volt_domain)
{
unsigned long volt = 0;
- volt = get_curr_voltage(id);
+ volt = get_curr_voltage(volt_domain);
if (!volt) {
- pr_warning(%s: Current voltage unknown.Cannot enable SR%d\n,
- __func__, id);
+ pr_warning(%s: Current voltage unknown.Cannot enable
sr_%s\n,
I am going to be a nitpick ;)- space after
that '.'
Re: [PATCH v2 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
Kevin, On 6/25/2010 1:44 AM, Kevin Hilman wrote: From: Rajendra Nayakrna...@ti.com Enable omap_device layer support for OMAP4, so that drivers can use them to enable/idle/shutdown devices. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com Signed-off-by: Kevin Hilmankhil...@deeprootsystems.com --- arch/arm/plat-omap/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..9405831 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_ARCH_OMAP2) += omap_device.o obj-$(CONFIG_ARCH_OMAP3) += omap_device.o +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o You need as well to enable omap_hwmod.c build otherwise it cannot build on OMAP4. diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 8ed47ea..5de06c3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -15,7 +15,7 @@ clock-common = clock.o clock_common_data.o \ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) -obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) +obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o 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: [PATCH 3/9] omap: generic: introduce a single check_revision
Grazvydas Ignotas had written, on 06/25/2010 04:31 AM, the following: On Wed, Jun 23, 2010 at 5:16 AM, Nishanth Menon n...@ti.com wrote: Introduce a single omap generic check_revision that routes the request to the right revision of check_revision. [...] diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index fca73cd..538e170 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -89,6 +89,18 @@ void __init omap_reserve(void) omap_vram_reserve_sdram_lmb(); } +void __init omap_check_revision() minor nitpick: void __init omap_check_revision(void)? ack. thanks for catching this. -- 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 1/4] omap mailbox: extend API to take a callback param
On Fri, Jun 25, 2010 at 3:52 AM, Kanigeri, Hari h-kanige...@ti.com wrote: I don't know what PCMIIW stands for :) please correct me if I'm wrong :) It looks like the variable mbox_configured that was added previously doesn't cover all the issues. It covers the shutdown issue with reference counting but as you mentioned that it poses an issue at startup as the RX interrupt for the second mbox instance doesn't get enabled. yeah. -- Even though this might not be relevant to mbox_configured issue, this looks like a nice feature to add. So this means we are going to support multiple writers to mailbox instance? yes, multiple writers, but also it will allow multiple readers. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9 v2] omap: move generic omap3 features to generic
sgx, iva, l2cache, sgx, neon, isp are generic features, make
them generic features, current OMAP3 detection mechanism
is still retained. 192Mhz is more specific OMAP3 feature
so it is retained as is
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: rebased patch after changes to 3/9
V1: original
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/common.c |4 +++
arch/arm/plat-omap/include/plat/cpu.h | 39 +++-
3 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat;\
+ omap_features |= OMAP_HAS_ ##feat; \
}
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
* AM35xx devices
*/
- if (omap3_has_sgx()) {
+ if (omap_has_sgx()) {
omap_revision = OMAP3517_REV(rev);
strcpy(cpu_name, AM3517);
} else {
/* Already set in omap3_check_revision() */
strcpy(cpu_name, AM3505);
}
- } else if (omap3_has_iva() omap3_has_sgx()) {
+ } else if (omap_has_iva() omap_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, OMAP3430/3530);
- } else if (omap3_has_iva()) {
+ } else if (omap_has_iva()) {
omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, OMAP3525);
- } else if (omap3_has_sgx()) {
+ } else if (omap_has_sgx()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, OMAP3515);
} else {
@@ -354,11 +354,11 @@ static void __init omap3_cpuinfo(void)
/* Print verbose information */
pr_info(%s ES%s (, cpu_name, cpu_rev);
- OMAP_SHOW_FEATURE(3, l2cache);
- OMAP_SHOW_FEATURE(3, iva);
- OMAP_SHOW_FEATURE(3, sgx);
- OMAP_SHOW_FEATURE(3, neon);
- OMAP_SHOW_FEATURE(3, isp);
+ OMAP_SHOW_FEATURE(, l2cache);
+ OMAP_SHOW_FEATURE(, iva);
+ OMAP_SHOW_FEATURE(, sgx);
+ OMAP_SHOW_FEATURE(, neon);
+ OMAP_SHOW_FEATURE(, isp);
OMAP_SHOW_FEATURE(3, 192mhz_clk);
printk()\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index f240d9a..60db750 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,10 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+/* OMAP Generic features */
+u32 omap_features;
+EXPORT_SYMBOL(omap_features);
+
void __init omap_check_revision(void)
{
#ifdef CONFIG_ARCH_OMAP1
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index f8ecbc4..3cc4947 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -331,14 +331,14 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3517
# define cpu_is_omap3430() is_omap3430()
# define cpu_is_omap3503() (cpu_is_omap3430()\
- (!omap3_has_iva())\
- (!omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (!omap_has_sgx()))
# define cpu_is_omap3515() (cpu_is_omap3430()\
- (!omap3_has_iva())\
- (omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (omap_has_sgx()))
# define cpu_is_omap3525() (cpu_is_omap3430()\
- (!omap3_has_sgx())\
-
[PATCH 3/9 v2] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: comments from http://marc.info/?t=12772595616r=1w=2
fixed
V1: original
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/common.c | 12
arch/arm/plat-omap/include/plat/cpu.h | 13 -
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
/*
* Runtime detection of OMAP3 features
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: Make VFPv3 usable on ARMv6
On Wed, 2010-06-23 at 08:57 +0100, Tony Lindgren wrote: MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release according to B.5 VFP changes in DDI0211F_arm1136_r1p0_trm.pdf. This is also when TLS register got added, so we can use HAS_TLS also to test for MVFR0 and MVFR1. Otherwise VFPFMRX and VFPFMXR access fails and we get: Internal error: Oops - undefined instruction: 0 [#1] PC is at no_old_VFP_process+0x8/0x3c LR is at __und_svc+0x48/0x80 ... Signed-off-by: Tony Lindgren t...@atomide.com The new version looks fine to me. Acked-by: Catalin Marinas catalin.mari...@arm.com -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/9 v2] omap: generic: introduce a single check_revision
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 25, 2010 6:57 PM
To: linux-omap
Cc: Menon, Nishanth; Tony Lindgren; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton; Grazvydas Ignotas; Paul Walmsley; Premi, Sanjeev;
Shilimkar, Santosh; Guruswamy, Senthilvadivu; Kevin Hilman; Tomi
Valkeinen; Aaro Koskinen; Pandita, Vikram; S, Vishwanath; linux-
o...@vger.kernel.org
Subject: [PATCH 3/9 v2] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: comments from http://marc.info/?t=12772595616r=1w=2
fixed
V1: original
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/common.c | 12
arch/arm/plat-omap/include/plat/cpu.h | 13 -
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
Inside omap2_check_revision() there is already check for cpu type. So do we
need to have it here? Here is the code snippet!!
void __init omap2_check_revision(void)
{
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
omap3_cpuinfo();
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
...
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-
omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
/*
* Runtime detection of OMAP3 features
--
Re: [PATCH 3/9 v2] omap: generic: introduce a single check_revision
DebBarma, Tarun Kanti had written, on 06/25/2010 08:50 AM, the following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 25, 2010 6:57 PM
To: linux-omap
Cc: Menon, Nishanth; Tony Lindgren; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton; Grazvydas Ignotas; Paul Walmsley; Premi, Sanjeev;
[...]
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
Inside omap2_check_revision() there is already check for cpu type. So do we
need to have it here? Here is the code snippet!!
void __init omap2_check_revision(void)
{
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
omap3_cpuinfo();
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
...
thanks for your comment.
My rationale for doing it is to allow for a single OMAP build for both
omap1 and omap2+ in which case the cpu_is check makes sense.
we have two choices:
a) remove the hope of having a single omap build (and the above logic is
a bit simpler.
b) when a new processor like omap5+ appears, yeah, we'd need to add
cpu_is_omap5xxx() here as well..
I am biased to (a), but leave the decision to community wisdom ;)
[...]
--
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: ZOOM2 doesn't boot on upstream kernel
On Wed, Jun 23, 2010 at 4:03 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] It's working for me. it's good to hear ! This is what I see: ## Booting image at 81c0 ... Image Name: Linux-2.6.35-rc3-1-g945a7eb Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2409672 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. (and then nothing happens, you don't even see the penguin on the screen) 1. console=ttyS0 are you sure ? all TI's docs state ttyS2 (and this works for me with TI's BSP kernels) but since I don't see the penguin on the screen, I don't think this is the problem btw I see there is CMDLINE in the .config, and also boot cmds that I pass via uboot.. I wonder if they should be the same.. 2. And can you try omap3_defconfig it doesn't compile: arch/arm/mach-omap2/built-in.o: In function `ads7846_dev_init': linux-2.6/arch/arm/mach-omap2/board-omap3stalker.c:542: undefined reference to `omap_set_gpio_debounce' linux-2.6/arch/arm/mach-omap2/board-omap3stalker.c:543: undefined reference to `omap_set_gpio_debounce_time' I'll see what I can do about it... thank you ! ~pnesh -- To unsubscribe from this list: send the line unsubscribe 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: ZOOM2 doesn't boot on upstream kernel
On Fri, Jun 25, 2010 at 5:05 PM, Neshama Parhoti pnesh...@gmail.com wrote:
1. console=ttyS0
you are absolutely right !!!
i changed it to ttyS0 and now I get the boot msgs ! :)
can you please check out my whole boot args to see if i have any other error ?
just to make sure..
setenv bootcmd 'tftpboot 0x81C0 /srv/tftp/uImage; bootm 0x81C0'
setenv nfsdata nfsroot=192.168.1.4:/home/pnesh/myfs,nolock,devfs=mount
ip=192.168.1.160
setenv bootargs console=ttyS3,115200n8 root=/dev/nfs rw rootdelay=1
mem=256M init=/init videoout=omap24xxvout
omap_vout.video1_numbuffers=4 omap_vout.vid1_static_vrfb_alloc=y
${nfsdata}
thank you 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: ZOOM2 doesn't boot on upstream kernel
On Fri, 25 Jun 2010 17:05:53 +0300 Neshama Parhoti pnesh...@gmail.com wrote: 1. console=ttyS0 are you sure ? all TI's docs state ttyS2 (and this works for me with TI's BSP kernels) Its ttyS0 if the omap serial driver is compiled in. The omap driver takes the ports instead of the 8250 driver. Graeme -- To unsubscribe from this list: send the line unsubscribe 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] smsc95xx: Add module parameter to override MAC address
Hi Steve, Thanks for your answer. On 06/25/2010 10:43 AM, steve.glendinn...@smsc.com wrote: [...] I can see you have a different use case, but I don't think this specific driver is the place for this logic. I'd rather see it added to either the usbnet framework or (preferably) the netdev framework so *all* ethernet drivers can do this the same way. otherwise we could end up with slight variations of this code in every single driver! I perfectly understand your concerns. Unfortunately, I will probably not be able to implement these changes into the netdev framework. However, I'd be happy to make some tests if someone proposes such changes. -- To unsubscribe from this list: send the line unsubscribe 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: ZOOM2 doesn't boot on upstream kernel
On Fri, Jun 25, 2010 at 5:15 PM, Graeme Gregory d...@xora.org.uk wrote: Its ttyS0 if the omap serial driver is compiled in. The omap driver takes the ports instead of the 8250 driver. thank you, now it makes sense ! Graeme -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9 v2] omap: generic: introduce a single check_revision
On Fri, Jun 25, 2010 at 7:25 PM, Nishanth Menon n...@ti.com wrote:
DebBarma, Tarun Kanti had written, on 06/25/2010 08:50 AM, the following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 25, 2010 6:57 PM
To: linux-omap
Cc: Menon, Nishanth; Tony Lindgren; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton; Grazvydas Ignotas; Paul Walmsley; Premi, Sanjeev;
[...]
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap()
macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
Inside omap2_check_revision() there is already check for cpu type. So do
we need to have it here? Here is the code snippet!!
void __init omap2_check_revision(void)
{
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
omap3_cpuinfo();
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
...
thanks for your comment.
My rationale for doing it is to allow for a single OMAP build for both omap1
and omap2+ in which case the cpu_is check makes sense.
we have two choices:
a) remove the hope of having a single omap build (and the above logic is a
bit simpler.
I think Tarun Kanti intended to point out the redundancy within the
OMAP2PLUS build path.
i.e the cpu checks
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
^^^ are not needed, as the omap2_check_revision does it anyway.
Then eventually omap_is_55xx() would be needed only inside
omap2_check_revision, and not in
omap_check_revision().
~Venkat.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9 v2] omap: generic: introduce a single check_revision
S, Venkatraman had written, on 06/25/2010 09:38 AM, the following:
On Fri, Jun 25, 2010 at 7:25 PM, Nishanth Menon n...@ti.com wrote:
DebBarma, Tarun Kanti had written, on 06/25/2010 08:50 AM, the following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 25, 2010 6:57 PM
To: linux-omap
Cc: Menon, Nishanth; Tony Lindgren; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton; Grazvydas Ignotas; Paul Walmsley; Premi, Sanjeev;
[...]
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap()
macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
Inside omap2_check_revision() there is already check for cpu type. So do
we need to have it here? Here is the code snippet!!
void __init omap2_check_revision(void)
{
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
omap3_cpuinfo();
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
...
thanks for your comment.
My rationale for doing it is to allow for a single OMAP build for both omap1
and omap2+ in which case the cpu_is check makes sense.
we have two choices:
a) remove the hope of having a single omap build (and the above logic is a
bit simpler.
I think Tarun Kanti intended to point out the redundancy within the
OMAP2PLUS build path.
yes I am aware of that. but consider the following:
CONFIG_ARCH_OMAP1 and CONFIG_ARCH_OMAP2PLUS being defined at the same time.
the logic will enter without a reason for it to do so, instead it will
print OMAP revision unknown for OMAP1 - not desired.
i.e the cpu checks
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
^^^ are not needed, as the omap2_check_revision does it anyway.
Then eventually omap_is_55xx() would be needed only inside
omap2_check_revision, and not in
omap_check_revision().
yes if we dont depend of if check as I mentioned above, I agree.
option a: as above
option b:
+#ifdef CONFIG_ARCH_OMAP1
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ omap2_check_revision();
+#endif
I know this is what Tarun and you are proposing, i dont have a strong
feeling against it if community is aligned on it.
~Venkat.
--
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 3/9 v2] omap: generic: introduce a single check_revision
On Fri, Jun 25, 2010 at 8:13 PM, Nishanth Menon n...@ti.com wrote:
S, Venkatraman had written, on 06/25/2010 09:38 AM, the following:
On Fri, Jun 25, 2010 at 7:25 PM, Nishanth Menon n...@ti.com wrote:
DebBarma, Tarun Kanti had written, on 06/25/2010 08:50 AM, the following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 25, 2010 6:57 PM
To: linux-omap
Cc: Menon, Nishanth; Tony Lindgren; Angelo Arrifano; Zebediah C.
McClure;
Alistair Buxton; Grazvydas Ignotas; Paul Walmsley; Premi, Sanjeev;
[...]
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap()
macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() ||
cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
Inside omap2_check_revision() there is already check for cpu type. So do
we need to have it here? Here is the code snippet!!
void __init omap2_check_revision(void)
{
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
omap3_cpuinfo();
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
}
...
thanks for your comment.
My rationale for doing it is to allow for a single OMAP build for both
omap1
and omap2+ in which case the cpu_is check makes sense.
we have two choices:
a) remove the hope of having a single omap build (and the above logic is
a
bit simpler.
I think Tarun Kanti intended to point out the redundancy within the
OMAP2PLUS build path.
yes I am aware of that. but consider the following:
CONFIG_ARCH_OMAP1 and CONFIG_ARCH_OMAP2PLUS being defined at the same time.
the logic will enter without a reason for it to do so, instead it will print
OMAP revision unknown for OMAP1 - not desired.
AFAIK, Tony has ruled out OMAP1 _and_ OMAP2+ multi-omap build.
If it was indeed possible, then
a) #ifdefs are not needed
b) omap2_check_revision() shouldn't emit the warning, as it doesn't
cater to all SoCs.
omap99_check_revision() could be in the later code path of
omap_check_revision()
i.e the cpu checks
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() ||
cpu_is_omap44xx())
^^^ are not needed, as the omap2_check_revision does it anyway.
Then eventually omap_is_55xx() would be needed only inside
omap2_check_revision, and not in
omap_check_revision().
yes if we dont depend of if check as I mentioned above, I agree.
option a: as above
option b:
+#ifdef CONFIG_ARCH_OMAP1
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ omap2_check_revision();
+#endif
I know this is what Tarun and you are proposing, i dont have a strong
feeling against it if community is aligned on it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. Since we don't have an OMAP-specific bus, override
the runtime PM hooks for the platform_bus for the OMAP specific
implementation.
While the runtime PM API has three main states (idle, suspend, resume)
This version treats idle and suspend the same way by implementing both
on top of omap_device_disable(), which follows closely with how driver
are currently using clock enable/disable calls. Longer-termm
pm_runtime_idle() could take other constraints into consideration to
make the decision, but the current
Device driver -runtime_suspend() hooks are called just before the
device is disabled (via omap_device_idle()), and device driver
-runtime_resume() hooks are called just after device has been
enabled (via omap_device_enable().)
Hi Kevin,
You shouldn't hijack the platform bus in this way, for a number of
reasons. Not all platform devices in an OMAP system are internal OMAP
devices (as you know since you do an explicit check for omap devices).
Right there that says that the abstraction is at the wrong level.
What happens when an mostly transparent bridge is added with its own
peripherals and its own special operations? Does this routine then
need to be extended for each new special case? It's not maintainable
in the long run.
This approach is also not multiplatform friendly (cc'ing Eric and
Nicolas who are working on ARM multiplatform). It won't work for
building a kernel that supports, say, both versatile and OMAP.
The kernel already has the facility to do what you need. We talked
about it briefly at ELC, and now that I look at it closer, I thing
gregkh is absolutely right. Just create a new bus type for OMAP
devices. It is simple to add one. You can probably even call out to
the platform bus ops for most of the operations. The fact that OMAP
devices have special behaviour that needs to be handled at the bus
type level means that they are not platform devices anymore. This
also eliminates all the omap_device_is_valid and OMAP_DEVICE_MAGIC
gymnastics.
I see from the comments in omap_device.c that doing an
omap_bus/omap_device is being considered anyway. Please don't merge
this patch and do the omap_bus_type instead.
Also, I notice that most of these hooks open-code the generic versions
of the runtime hooks. Instead of open coding it, can the omap hooks
call the generic hooks before/after doing the omap-specific work?
Cheers,
g.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile | 7 +++-
arch/arm/mach-omap2/pm_bus.c | 70
++
2 files changed, 76 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea52b03..8ed47ea 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
\
+ pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o += -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..9719a9f
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,70 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/mutex.h
+
+#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int r, ret = 0;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ if (dev-driver-pm dev-driver-pm-runtime_suspend)
+ ret = dev-driver-pm-runtime_suspend(dev);
+ if (!ret omap_device_is_valid(odev)) {
+ r =
RE: ZOOM2 doesn't boot on upstream kernel
Pnesh, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Neshama Parhoti Sent: Friday, June 25, 2010 9:06 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: Re: ZOOM2 doesn't boot on upstream kernel On Wed, Jun 23, 2010 at 4:03 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] It's working for me. it's good to hear ! This is what I see: ## Booting image at 81c0 ... Image Name: Linux-2.6.35-rc3-1-g945a7eb Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2409672 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. (and then nothing happens, you don't even see the penguin on the screen) 1. console=ttyS0 are you sure ? all TI's docs state ttyS2 (and this works for me with TI's BSP kernels) but since I don't see the penguin on the screen, I don't think this is the problem The penguin on the screen won't come up, since I don't think that the nec panel drivers for DSS2 has been merged in mainline. The latest patch to get this driver is found here: https://patchwork.kernel.org/patch/101435/ Regards, Sergio snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/uart][PATCH] Serial: Avoid populating uart_list in early init phase
Govindraj.R govindraj.r...@ti.com writes:
Leave the uart_list empty and keep the omap hwmod info
in a seperate uart_oh list and if board file calls
serial init use this uart_oh list info to fill uart_list.
The board file can also call just init_port to initialise
a single uart instance, so make init_port flexible to handle
individual uart instance by avoiding filling uart_list
in any non port_init function.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
As per earlier dicussion:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31157.html
Thanks.
Your inline patch is still getting mangled somehow. It looks like
you're using a webmail client (SquirrelMail) that seems to be altering
the whitespace in the patch. The attached .zip worked fine. Please
spend some time figuring out how to use git send-email directly
However, I just discovered another snag...
I did some more testing on Zoom3 and discovered that because we do the
HWMOD_INIT_NO_IDLE, and omap_serial_init[_port] is never called on Zoom3
(since it only uses debug board UART) the UART hwmods are left active
are never disabled (since they are not used.) This prevents retention :(
So, here's an idea... (I know, you're growing more and more to not like
my ideas that are going around in circles... sorry about that)
The ultimate goal is fix up all this serial.c hackery by getting your
OMAP serial driver upstream and moving PM handling there, so lets focus
on that instead of continuing to make this hacky layer perfect.
So for now, lets accept that with our current serial.c layer, we have to
always initialize all the UARTs for our PM core to work. Currently,
Zoom2/3 are the only ones not doing that, so lets just change that until
we get your OMAP serial driver merged.
The patch below does it for Zoom3, can you test and do similar for
Zoom2? Note that the default console will need to be changed to ttyS4
(Zoom3) and ttyS3 (Zoom2) after this patch.
Thanks,
Kevin
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index 1d7f827..9307f58 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -96,7 +96,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
static struct platform_device zoom_debugboard_serial_device = {
.name = serial8250,
- .id = PLAT8250_DEV_PLATFORM,
+ .id = PLAT8250_DEV_PLATFORM + 4,
.dev= {
.platform_data = serial_platform_data,
},
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 3314704..ff3b144 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -65,6 +65,7 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
static void __init omap_zoom_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_serial_init();
zoom_peripherals_init();
zoom_debugboard_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9 v2] omap: generic: introduce a single check_revision
S, Venkatraman had written, on 06/25/2010 10:16 AM, the following:
On Fri, Jun 25, 2010 at 8:13 PM, Nishanth Menon n...@ti.com wrote:
S, Venkatraman had written, on 06/25/2010 09:38 AM, the following:
On Fri, Jun 25, 2010 at 7:25 PM, Nishanth Menon n...@ti.com wrote:
DebBarma, Tarun Kanti had written, on 06/25/2010 08:50 AM, the following:
[...]
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..f240d9a 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,18 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+#ifdef CONFIG_ARCH_OMAP1
+ if (cpu_is_omap7xx() || cpu_is_omap15xx() || cpu_is_omap16xx())
+ omap1_check_revision();
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() ||
cpu_is_omap44xx())
+ omap2_check_revision();
+#endif
+}
Inside omap2_check_revision() there is already check for cpu type. So do
we need to have it here? Here is the code snippet!!
void __init omap2_check_revision(void)
[...]
My rationale for doing it is to allow for a single OMAP build for both
omap1
and omap2+ in which case the cpu_is check makes sense.
we have two choices:
a) remove the hope of having a single omap build (and the above logic is
a
bit simpler.
I think Tarun Kanti intended to point out the redundancy within the
OMAP2PLUS build path.
yes I am aware of that. but consider the following:
CONFIG_ARCH_OMAP1 and CONFIG_ARCH_OMAP2PLUS being defined at the same time.
the logic will enter without a reason for it to do so, instead it will print
OMAP revision unknown for OMAP1 - not desired.
AFAIK, Tony has ruled out OMAP1 _and_ OMAP2+ multi-omap build.
Thanks for clarifying. my bad.. missed that thread :(.
Will post a v3 - do feel free to review and reviewd/Ack if you find it ok.
If it was indeed possible, then
a) #ifdefs are not needed
ofcourse :)
b) omap2_check_revision() shouldn't emit the warning, as it doesn't
cater to all SoCs.
omap99_check_revision() could be in the later code path of
omap_check_revision()
hmm.. This will not be relevant anymore. will post a v3 which assumes
that omap1 and omap2 are independent.
the headers ensure that null functions are introduced when the defines
are not present.
[...]
--
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
[PATCH 3/9 v3] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Note: OMAP1 and OMAP2+ are not built into a single kernel. This
allows for the headers definitions of omap1_check_revision() and
omap2_check_revision() to be used without #ifdefs and additional cpu
checks in our single check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: comments from http://marc.info/?t=12774725203r=1w=2
fixed
V2: comments from http://marc.info/?t=12772595616r=1w=2
fixed
V1: original
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/common.c |6 ++
arch/arm/plat-omap/include/plat/cpu.h | 13 -
4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..4a0e333 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,12 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+ omap1_check_revision();
+ omap2_check_revision();
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
/*
* Runtime detection of OMAP3 features
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
-Original Message-
From: Menon, Nishanth
Sent: Friday, June 25, 2010 9:55 PM
To: linux-omap
Cc: Tony Lindgren; Menon, Nishanth; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton; Grazvydas
Ignotas; Paul Walmsley; Premi, Sanjeev; Shilimkar, Santosh; Guruswamy,
Senthilvadivu; Kevin Hilman;
DebBarma, Tarun Kanti; Tomi Valkeinen; Aaro Koskinen; Pandita, Vikram; S,
Vishwanath; linux-
o...@vger.kernel.org
Subject: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Note: OMAP1 and OMAP2+ are not built into a single kernel. This
allows for the headers definitions of omap1_check_revision() and
omap2_check_revision() to be used without #ifdefs and additional cpu
checks in our single check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: comments from http://marc.info/?t=12774725203r=1w=2
fixed
V2: comments from http://marc.info/?t=12772595616r=1w=2
fixed
V1: original
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/common.c |6 ++
arch/arm/plat-omap/include/plat/cpu.h | 13 -
4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..4a0e333 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,12 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+ omap1_check_revision();
+ omap2_check_revision();
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
I think codingstyle suggest empty function braces to be on next line
like
static inline void omap2_check_revision(void)
{}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
/*
* Runtime detection of OMAP3 features
Otherwise patch looks good to me.
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
Cousson, Benoit b-cous...@ti.com writes: On 6/25/2010 1:44 AM, Kevin Hilman wrote: From: Rajendra Nayakrna...@ti.com Enable omap_device layer support for OMAP4, so that drivers can use them to enable/idle/shutdown devices. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com Signed-off-by: Kevin Hilmankhil...@deeprootsystems.com --- arch/arm/plat-omap/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..9405831 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_ARCH_OMAP2) += omap_device.o obj-$(CONFIG_ARCH_OMAP3) += omap_device.o +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o You need as well to enable omap_hwmod.c build otherwise it cannot build on OMAP4. Doh, sorry. Pushed an updated pm-wip/hwmods with this folded into $SUBJECT patch. Kevin diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 8ed47ea..5de06c3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -15,7 +15,7 @@ clock-common = clock.o clock_common_data.o \ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common) -obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) +obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o 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: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
Shilimkar, Santosh had written, on 06/25/2010 11:41 AM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Friday, June 25, 2010 9:55 PM
To: linux-omap
Cc: Tony Lindgren; Menon, Nishanth; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton; Grazvydas
Ignotas; Paul Walmsley; Premi, Sanjeev; Shilimkar, Santosh; Guruswamy,
Senthilvadivu; Kevin Hilman;
DebBarma, Tarun Kanti; Tomi Valkeinen; Aaro Koskinen; Pandita, Vikram; S,
Vishwanath; linux-
o...@vger.kernel.org
Subject: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Note: OMAP1 and OMAP2+ are not built into a single kernel. This
allows for the headers definitions of omap1_check_revision() and
omap2_check_revision() to be used without #ifdefs and additional cpu
checks in our single check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: comments from http://marc.info/?t=12774725203r=1w=2
fixed
V2: comments from http://marc.info/?t=12772595616r=1w=2
fixed
V1: original
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/common.c |6 ++
arch/arm/plat-omap/include/plat/cpu.h | 13 -
4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..4a0e333 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,12 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+ omap1_check_revision();
+ omap2_check_revision();
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
I think codingstyle suggest empty function braces to be on next line
like
static inline void omap2_check_revision(void)
{}
are you sure about that? can you point me to the documentation for that?
Style I followed is off:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD#l661
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
/*
* Runtime detection of OMAP3 features
Otherwise patch looks good to me.
thanks for the ack.
--
1.6.3.3
--
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 v2 1/3] OMAP: PM: initial runtime PM core support
Grant Likely grant.lik...@secretlab.ca writes: On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Implement the new runtime PM framework as a thin layer on top of the omap_device API. Since we don't have an OMAP-specific bus, override the runtime PM hooks for the platform_bus for the OMAP specific implementation. While the runtime PM API has three main states (idle, suspend, resume) This version treats idle and suspend the same way by implementing both on top of omap_device_disable(), which follows closely with how driver are currently using clock enable/disable calls. Longer-termm pm_runtime_idle() could take other constraints into consideration to make the decision, but the current Device driver -runtime_suspend() hooks are called just before the device is disabled (via omap_device_idle()), and device driver -runtime_resume() hooks are called just after device has been enabled (via omap_device_enable().) Hi Kevin, Hi Grant. Thanks for the review and suggestions. You shouldn't hijack the platform bus in this way, for a number of reasons. Not all platform devices in an OMAP system are internal OMAP devices (as you know since you do an explicit check for omap devices). Right there that says that the abstraction is at the wrong level. What happens when an mostly transparent bridge is added with its own peripherals and its own special operations? Does this routine then need to be extended for each new special case? It's not maintainable in the long run. This approach is also not multiplatform friendly (cc'ing Eric and Nicolas who are working on ARM multiplatform). It won't work for building a kernel that supports, say, both versatile and OMAP. Totally agree here, but this a separate issue not specifically created by this series (it was created when runtime PM support for SH was added), but indeed I am continuining bad behavior. :/ The issue is that the current method to override bus methods is by overriding weak symbols. This clearly doesn't scale to support multiple platforms in the same image. What would be needed (if we continue to override the platform_bus methods) is to have some sort of register function for overriding these methods. I'll look into that based on the result of discussions below... The kernel already has the facility to do what you need. We talked about it briefly at ELC, and now that I look at it closer, I thing gregkh is absolutely right. Just create a new bus type for OMAP devices. It is simple to add one. You can probably even call out to the platform bus ops for most of the operations. The fact that OMAP devices have special behaviour that needs to be handled at the bus type level means that they are not platform devices anymore. This also eliminates all the omap_device_is_valid and OMAP_DEVICE_MAGIC gymnastics. I see from the comments in omap_device.c that doing an omap_bus/omap_device is being considered anyway. Please don't merge this patch and do the omap_bus_type instead. Agreed, it is logicially simpler in many ways and as you've noticed, we've been discussing it in the OMAP community. However, I keep coming back to extending the platform bus, primarily since the resulting new bus code would look almost identical to the platform bus. All I really needed is the ability to extend a small subset of the PM functions, so this led to me the extend instead of duplicate approach. In addition, I really don't want to duplicate all the platform_driver and platform_device code, again because it would be identical but especially since this would seriously impact many drivers. For drivers that are used on OMAP and also on other platforms, do we want drivers to know (or care) if they are on the platform bus or on the OMAP bus? I think this is how it is done for OF devices, but I'm not crazy about that approach (after our discussions at ELC, I remember thinking you'd been through this with the OF devices as well and are moving towards using platform_bus/platform_device for those too. Did I understand correctly?) This affects many aspects of all drivers, from register and probe (for early devices/drivers too!) to all the plaform_get_resource() usage, all of which assumes a platform_driver and platform_device. I didn't look closely, but I didn't see if (or how) OF was handling early devices. All that being said, if I could create a custom bus, but continue to use platform_devices, that would greatly simply the changes to drivers. Do you think that's acceptable? If so, I can take a stab at that and see what it looks like. Also, I notice that most of these hooks open-code the generic versions of the runtime hooks. Instead of open coding it, can the omap hooks call the generic hooks before/after doing the omap-specific work? Ah, good point. This patch pre-dates the creation of pm_generic_runtime_*, but certainly should be upgraded to use those. Thanks. Kevin Cheers, g.
RE: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
-Original Message-
From: Menon, Nishanth
Sent: Friday, June 25, 2010 11:02 PM
To: Shilimkar, Santosh
Cc: linux-omap; Tony Lindgren; Angelo Arrifano; Zebediah C. McClure; Alistair
Buxton; Grazvydas
Ignotas; Paul Walmsley; Premi, Sanjeev; Guruswamy, Senthilvadivu; Kevin
Hilman; DebBarma, Tarun
Kanti; Tomi Valkeinen; Aaro Koskinen; Pandita, Vikram; S, Vishwanath
Subject: Re: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
Shilimkar, Santosh had written, on 06/25/2010 11:41 AM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Friday, June 25, 2010 9:55 PM
To: linux-omap
Cc: Tony Lindgren; Menon, Nishanth; Angelo Arrifano; Zebediah C. McClure;
Alistair Buxton;
Grazvydas
Ignotas; Paul Walmsley; Premi, Sanjeev; Shilimkar, Santosh; Guruswamy,
Senthilvadivu; Kevin
Hilman;
DebBarma, Tarun Kanti; Tomi Valkeinen; Aaro Koskinen; Pandita, Vikram; S,
Vishwanath; linux-
o...@vger.kernel.org
Subject: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Note: OMAP1 and OMAP2+ are not built into a single kernel. This
allows for the headers definitions of omap1_check_revision() and
omap2_check_revision() to be used without #ifdefs and additional cpu
checks in our single check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: comments from http://marc.info/?t=12774725203r=1w=2
fixed
V2: comments from http://marc.info/?t=12772595616r=1w=2
fixed
V1: original
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/common.c |6 ++
arch/arm/plat-omap/include/plat/cpu.h | 13 -
4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index e4d8680..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap1_check_revision(void);
extern void omap_sram_init(void);
/*
@@ -102,7 +101,7 @@ void __init omap1_map_common_io(void)
/* We want to check CPU revision early for cpu_is_omap() macros.
* IO space mapping must be initialized before we can do that.
*/
- omap1_check_revision();
+ omap_check_revision();
#if defined (CONFIG_ARCH_OMAP730) || defined (CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4e1f53d..eeb0e30 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..4a0e333 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,12 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+ omap1_check_revision();
+ omap2_check_revision();
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
I think codingstyle suggest empty function braces to be on next line
like
static inline void omap2_check_revision(void)
{}
are you sure about that? can you point me to the documentation for that?
Style I followed is off:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
RE: [RFC] omap: hwspinlock: Added hwspinlock driver
Benoit, Thanks for the comments. My responses are below. Why using a Kconfig option in that case? You can reserve the locks at run time based on other driver request. The goal of the hwspinlock is to protect data shared between various processors inside OMAP4 like ipu, iva, dsp and mpu. So in anycase the syslink driver can request the needed locks at init time on behalf of the dsp or the ipu. Since you don't even know the number of locks because it is determined at init time, you cannot know at build time that information. You should add an API to reserve some locks at run time instead of doing that. The reserved locks are not meant for syslink use only. It will also be used by i2c, which does not go through syslink. If we were to follow your suggestion, who should call the function to establish number of reserved locks? We can instead think of the config option as requesting a particular number of reserved locks for system use, independent of how many locks actually exist in the system. How many reserved locks there are, and which driver is using which reserved locks -- that is a system integration issue that should be sorted out at a higher level. It is a details, but why are you renaming the registers with the HW prefix? The module name is spinlock not hwspinlock. The names should be that: #define SPINLOCK_REVISION0x #define SPINLOCK_SYSCONFIG 0x0010 #define SPINLOCK_SYSSTATUS 0x0014 #define SPINLOCK_LOCK_BASE 0x0800 or even that since you are not sharing these defines: #define REVISION0x #define SYSCONFIG 0x0010 #define SYSSTATUS 0x0014 #define LOCK_BASE 0x0800 Every IPs are by definition an HW module, so that information is useless. You have a good point, I will make this change. Since it is a new driver for a new IP, why don't you use directly the omap_device / omap_hwmod abstraction? hwmod for spinlock is not currently ready. We want to integrate with the platform/driver/device system for now, as a first step. hwmod can be implemented later. Simon -- To unsubscribe from this list: send the line unsubscribe 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] smsc95xx: Add module parameter to override MAC address
From: Sebastien Jan s-...@ti.com Date: Fri, 25 Jun 2010 16:20:36 +0200 Hi Steve, Thanks for your answer. On 06/25/2010 10:43 AM, steve.glendinn...@smsc.com wrote: [...] I can see you have a different use case, but I don't think this specific driver is the place for this logic. I'd rather see it added to either the usbnet framework or (preferably) the netdev framework so *all* ethernet drivers can do this the same way. otherwise we could end up with slight variations of this code in every single driver! I perfectly understand your concerns. Unfortunately, I will probably not be able to implement these changes into the netdev framework. However, I'd be happy to make some tests if someone proposes such changes. I don't think such logic belongs anywhere other than an initrd. We have mechanisms by which to handle this already, and contrary to what many people claim it is not at all so hard to create a custom initrd. -- To unsubscribe from this list: send the line unsubscribe 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-SR] [PATCH] OMAP: PM: Remove the usage of vdd id's.
Thara Gopinath th...@ti.com writes: This patch removes the usage of vdd and sr id alltogether. This is achieved by introducing a separte voltage domain per VDD and hooking this up with the voltage and smartreflex internal info structure. Any user of voltage or smartreflex layer should call into omap_volt_domain_get to get the voltage domain handle and make use of this to call into the various exported API's. Great, I'm glad to see those gone. Minor comment on naming: In current code, we currently have struct clockdomain *clkdm; struct powerdomain *pwrdm; so, for consistency, I'd suggest using struct voltagedomain *voltdm; instead of this: struct omap_volt_domain *volt_domain; Also, it looks like your 'struct omap_vdd_info' is the real struct that represents a voltage domain. Maybe you're planning this already, but I suggest you get rid of omap_vdd_info and just move all that stuff into the voltagedomain. Again, that will probably create a diff with a ton of renames, so this should just be part of your V2 series. These changes should be part of V2 of the sr/voltage series instead of being a separate patch in itself. Agreed. 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
static inline function style (was Re: [PATCH 3/9 v3] omap: generic: introduce a single check_revision)
Shilimkar, Santosh had written, on 06/25/2010 01:07 PM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Friday, June 25, 2010 11:02 PM
[..]
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
I think codingstyle suggest empty function braces to be on next line
like
static inline void omap2_check_revision(void)
{}
are you sure about that? can you point me to the documentation for that?
Style I followed is off:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD#l
661
I got similar comment long back and hence remembered. Looks like it's not
explicitly documented
changing subject to get folks interested..
i would think that checkpatch should crib about it, but it being an
automated script, could be messed up sometimes..
but I am curious -
static inline void foo(void) { }
static inline int foo(void)
{
return -ENODEV;
}
is the style I have seen to date. usually without a functional code, it
made more sense to have it out of line and more in the style of a normal
function..
could someone give any suggestions on this?
--
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: [RFC] omap: hwspinlock: Added hwspinlock driver
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Que, Simon
Sent: Thursday, June 24, 2010 7:40 PM
To: linux-omap@vger.kernel.org
Cc: Kanigeri, Hari; Ohad Ben-Cohen
Subject: [RFC] omap: hwspinlock: Added hwspinlock driver
Hi,
snip
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6725b3a..14af19a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,3 +170,5 @@ obj-y += $(nand-
m) $(nand-y)
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
+
+obj-y += hwspinlocks.o
If this block is only on OMAP4, why build it for omap2 and omap3?
\ No newline at end of file
diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-
omap2/hwspinlocks.c
new file mode 100644
index 000..de813a0
--- /dev/null
+++ b/arch/arm/mach-omap2/hwspinlocks.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP hardware spinlock driver
+ *
+ * Copyright (C) 2010 Texas Instruments. All rights reserved.
+ *
+ * Contact: Simon Que s...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/slab.h
+
+#include plat/hwspinlock.h
+
+/* Base address of HW spinlock module */
+#define HWSPINLOCK_BASE(L4_44XX_BASE + 0xF6000)
+#define HWSPINLOCK_REGADDR(reg)\
+ OMAP2_L4_IO_ADDRESS(HWSPINLOCK_BASE + (reg))
+
+/* Spinlock register offsets */
+#define HWSPINLOCK_REVISION0x
+#define HWSPINLOCK_SYSCONFIG 0x0010
+#define HWSPINLOCK_SYSSTATUS 0x0014
+#define HWSPINLOCK_LOCK_BASE 0x0800
+
+/* Spinlock register addresses */
+#define HWSPINLOCK_REVISION_REG\
+ HWSPINLOCK_REGADDR(HWSPINLOCK_REVISION)
+#define HWSPINLOCK_SYSCONFIG_REG \
+ HWSPINLOCK_REGADDR(HWSPINLOCK_SYSCONFIG)
+#define HWSPINLOCK_SYSSTATUS_REG \
+ HWSPINLOCK_REGADDR(HWSPINLOCK_SYSSTATUS)
+#define HWSPINLOCK_LOCK_REG(i) \
+ HWSPINLOCK_REGADDR(HWSPINLOCK_LOCK_BASE + 0x4 * (i))
+
+/* Spinlock count code */
+#define HWSPINLOCK_32_REGS 1
+#define HWSPINLOCK_64_REGS 2
+#define HWSPINLOCK_128_REGS4
+#define HWSPINLOCK_256_REGS8
+#define HWSPINLOCK_NUMLOCKS_OFFSET 24
+
+
+/* Initialization function */
+int __init hwspinlocks_init(void)
+{
+ int i;
+ int retval = 0;
+
+ struct platform_device *pdev;
+ struct hwspinlock_plat_info *pdata;
+ void __iomem *base;
+ int num_locks;
+ bool is_reserved;
+
+ /* Determine number of locks */
+ switch (__raw_readl(HWSPINLOCK_SYSSTATUS_REG)
+ HWSPINLOCK_NUMLOCKS_OFFSET) {
+ case HWSPINLOCK_32_REGS:
+ num_locks = 32;
+ break;
+ case HWSPINLOCK_64_REGS:
+ num_locks = 64;
+ break;
+ case HWSPINLOCK_128_REGS:
+ num_locks = 128;
+ break;
+ case HWSPINLOCK_256_REGS:
+ num_locks = 256;
+ break;
+ default:
+ return -EINVAL; /* Invalid spinlock count code */
+ }
+
+ /* Device drivers */
+ for (i = 0; i num_locks; i++) {
+ pdev = platform_device_alloc(hwspinlock, i);
+
+ base = HWSPINLOCK_LOCK_REG(i); /* Get register address */
+
+ /* Some locks are reserved for system use */
+ if (i CONFIG_OMAP_HWSPINLOCK_NUM_RESERVED)
+ is_reserved = true;
+ else
+ is_reserved = false;
+
+ /* Pass data to device initialization */
+ pdata = kzalloc(sizeof(struct hwspinlock_plat_info),
+
GFP_KERNEL);
+ pdata-num_locks = num_locks;
+ pdata-io_base = base;
Any reason not to have the driver ioremap the HWSPINLOCK address and rather
pass the physical
RE: [RFC] omap: hwspinlock: Added hwspinlock driver
Simon, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Que, Simon Sent: Friday, June 25, 2010 6:10 AM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ohad Ben-Cohen Subject: [RFC] omap: hwspinlock: Added hwspinlock driver Hi, We are introducing a kernel driver for hardware spinlock, called hwspinlock. It is designed to interface with the OMAP4 hardware spinlock module. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization will set aside some spinlocks as reserved for special-purpose use. All other locks can be used by anyone. This is configurable using a Kconfig option. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in data passed in device initialization. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address provided by the device initialization. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. int hwspinlock_lock_irqsave(struct hwspinlock *, unsigned long *); Same as hwspinlock_lock, but disables interrupts and preemption int hwspinlock_trylock_irqsave(struct hwspinlock *, unsigned long *); Same as hwspinlock_trylock, but disables interrupts and preemption int hwspinlock_unlock_irqrestore(struct hwspinlock *, unsigned long); Same as hwspinlock_unlock, but restores interrupts and preemption struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of an unreserved hardware spinlock. If no more locks are available, returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a reserved hardware spinlock. This allows the system to use a specific reserved lock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Please see the below patch contents, or the attached patch, and provide feedback. Signed-off-by: Simon Que s...@ti.com Cc: Hari Kanigeri h-kanige...@ti.com = diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 9f73d79..a13c188 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -182,3 +182,13 @@ config OMAP3_SDRC_AC_TIMING wish to say no. Selecting yes without understanding what is going on could result in system crashes; +config OMAP_HWSPINLOCK_NUM_RESERVED + int Number of hardware spinlocks reserved for system use + depends on ARCH_OMAP It should have been ARCH_OMAP4 but I think this KCONFIG should be killed + default 8 + range 0 32 + help + Choose a number of hardware spinlocks to reserve for internal use. + The rest will be unreserved and availble for general use. Make + that the number of reserved locks does not exceed the total number + available locks. This reservation KCONFIG isn't necessary. HWSPINLOCK IP is not really for very generic use but specific usages where you need to protect the data between independent softwares running on different masters. For other Linux only side software even with dual core, kernel spinlock library is sufficient. diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6725b3a..14af19a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -170,3 +170,5 @@ obj-y += $(nand-m) $(nand-y) smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o obj-y += $(smc91x-m) $(smc91x-y) + +obj-y += hwspinlocks.o Are you building this for all OMAP's ?? \ No newline at end of file diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-omap2/hwspinlocks.c new file mode 100644 index 000..de813a0 --- /dev/null +++
Re: [PM-SR] [PATCH] OMAP: PM: Remove the usage of vdd id's.
Thara Gopinath th...@ti.com writes:
This patch removes the usage of vdd and sr id alltogether.
This is achieved by introducing a separte voltage domain per
VDD and hooking this up with the voltage and smartreflex
internal info structure. Any user of voltage or smartreflex layer
should call into omap_volt_domain_get to get the voltage
domain handle and make use of this to call into the various
exported API's.
These changes should be part of V2 of the sr/voltage series
instead of being a separate patch in itself.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
-static struct omap_sr *_sr_lookup(int srid)
+static struct omap_sr *_sr_lookup(struct omap_volt_domain *volt_domain)
{
struct omap_sr *sr_info, *temp_sr_info;
sr_info = NULL;
list_for_each_entry(temp_sr_info, sr_list, node) {
- if (srid == temp_sr_info-srid) {
+ if (volt_domain == temp_sr_info-volt_domain) {
sr_info = temp_sr_info;
break;
Do we still need an _sr_lookup() function? Isn't there a single SR
instance per voltage domain?
At init time, the sr_info should be linked to the voltage domain, and
then the code can simply do:
struct omap_sr *sr_info = voltdm-sr_info;
instead of _sr_lookup.
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 v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, Jun 25, 2010 at 09:26:43AM -0600, Grant Likely wrote: This approach is also not multiplatform friendly (cc'ing Eric and Nicolas who are working on ARM multiplatform). It won't work for building a kernel that supports, say, both versatile and OMAP. And I should also point out that multiplatform is not the answer to Linus' concerns. There's no way such work is going to be anywhere near complete come the next merge window. Note that the loss of the defconfigs will make the integration of multiplatform patches extremely time consuming and slow. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, Jun 25, 2010 at 12:04 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Grant Likely grant.lik...@secretlab.ca writes: On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Implement the new runtime PM framework as a thin layer on top of the omap_device API. Since we don't have an OMAP-specific bus, override the runtime PM hooks for the platform_bus for the OMAP specific implementation. While the runtime PM API has three main states (idle, suspend, resume) This version treats idle and suspend the same way by implementing both on top of omap_device_disable(), which follows closely with how driver are currently using clock enable/disable calls. Longer-termm pm_runtime_idle() could take other constraints into consideration to make the decision, but the current Device driver -runtime_suspend() hooks are called just before the device is disabled (via omap_device_idle()), and device driver -runtime_resume() hooks are called just after device has been enabled (via omap_device_enable().) Hi Kevin, Hi Grant. Thanks for the review and suggestions. You shouldn't hijack the platform bus in this way, for a number of reasons. Not all platform devices in an OMAP system are internal OMAP devices (as you know since you do an explicit check for omap devices). Right there that says that the abstraction is at the wrong level. What happens when an mostly transparent bridge is added with its own peripherals and its own special operations? Does this routine then need to be extended for each new special case? It's not maintainable in the long run. This approach is also not multiplatform friendly (cc'ing Eric and Nicolas who are working on ARM multiplatform). It won't work for building a kernel that supports, say, both versatile and OMAP. Totally agree here, but this a separate issue not specifically created by this series (it was created when runtime PM support for SH was added), but indeed I am continuining bad behavior. :/ I think I could successfully argue that ARM is more important that SH. If SH messes up it's sandbox the collateral damage isn't nearly so severe. Don't follow the SH lead in this case. The issue is that the current method to override bus methods is by overriding weak symbols. This clearly doesn't scale to support multiple platforms in the same image. Agreed. It scales better to change the hooks at runtime, which is actually quite easy, but it still leaves the abstraction at the wrong level. What would be needed (if we continue to override the platform_bus methods) is to have some sort of register function for overriding these methods. I'll look into that based on the result of discussions below... The kernel already has the facility to do what you need. We talked about it briefly at ELC, and now that I look at it closer, I thing gregkh is absolutely right. Just create a new bus type for OMAP devices. It is simple to add one. You can probably even call out to the platform bus ops for most of the operations. The fact that OMAP devices have special behaviour that needs to be handled at the bus type level means that they are not platform devices anymore. This also eliminates all the omap_device_is_valid and OMAP_DEVICE_MAGIC gymnastics. I see from the comments in omap_device.c that doing an omap_bus/omap_device is being considered anyway. Please don't merge this patch and do the omap_bus_type instead. Agreed, it is logicially simpler in many ways and as you've noticed, we've been discussing it in the OMAP community. However, I keep coming back to extending the platform bus, primarily since the resulting new bus code would look almost identical to the platform bus. All I really needed is the ability to extend a small subset of the PM functions, so this led to me the extend instead of duplicate approach. In addition, I really don't want to duplicate all the platform_driver and platform_device code, again because it would be identical but especially since this would seriously impact many drivers. For drivers that are used on OMAP and also on other platforms, do we want drivers to know (or care) if they are on the platform bus or on the OMAP bus? Some questions to make sure I understand: Do you have a lot of these cases? Do non-OMAP devices also have to process the omap clock enable/disable code too, or is this only for stuff that is internal to the chip? Or is this the case where existing non-omap device drivers can also drive the omap SoC hardware? I think this is how it is done for OF devices, but I'm not crazy about that approach (after our discussions at ELC, I remember thinking you'd been through this with the OF devices as well and are moving towards using platform_bus/platform_device for those too. Did I understand correctly?) Yes, I've got patches which merge of_platform_bus_type with the platform bus. This was an easy decision to make because the of-specific
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, Jun 25, 2010 at 2:06 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jun 25, 2010 at 09:26:43AM -0600, Grant Likely wrote: This approach is also not multiplatform friendly (cc'ing Eric and Nicolas who are working on ARM multiplatform). It won't work for building a kernel that supports, say, both versatile and OMAP. And I should also point out that multiplatform is not the answer to Linus' concerns. There's no way such work is going to be anywhere near complete come the next merge window. Yes, but solving the defconfig problem isn't the reason for multiplatform. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, Jun 25, 2010 at 02:13:15PM -0600, Grant Likely wrote: On Fri, Jun 25, 2010 at 2:06 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jun 25, 2010 at 09:26:43AM -0600, Grant Likely wrote: This approach is also not multiplatform friendly (cc'ing Eric and Nicolas who are working on ARM multiplatform). It won't work for building a kernel that supports, say, both versatile and OMAP. And I should also point out that multiplatform is not the answer to Linus' concerns. There's no way such work is going to be anywhere near complete come the next merge window. Yes, but solving the defconfig problem isn't the reason for multiplatform. Does anyone know where we are on the defconfig problem? From what I can see, it's mostly stalled for the time being, which is not good news for us. -- To unsubscribe from this list: send the line unsubscribe 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] omap: hwspinlock: Added hwspinlock driver
Santosh, This reservation KCONFIG isn't necessary. HWSPINLOCK IP is not really for very generic use but specific usages where you need to protect the data between independent softwares running on different masters. For other Linux only side software even with dual core, kernel spinlock library is sufficient. We will consider this. Are you building this for all OMAP's ?? Move this base address to plat/omap44xx.h and use it from there OMAP2_L4_IO_ADDRESS this should not be used anymore. Rather, use ioremap and readl/writel Good points, we'll implement these. Why do you have two files ? This IP is not part of OMAP1 and all the code can go in mach-omap and can be exported from there. Are you suggesting we use a library approach instead of a driver approach? We want to make this expandable in the future. If something in the underlying hardware changes with OMAP5, OMAP6, etc, we only need to update the device initialization file. The driver can remain unchanged. Thank you, Simon -- To unsubscribe from this list: send the line unsubscribe 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] omap: hwspinlock: Added hwspinlock driver
From: Que, Simon Sent: Friday, June 25, 2010 8:14 PM Benoit, Thanks for the comments. My responses are below. Why using a Kconfig option in that case? You can reserve the locks at run time based on other driver request. The goal of the hwspinlock is to protect data shared between various processors inside OMAP4 like ipu, iva, dsp and mpu. So in anycase the syslink driver can request the needed locks at init time on behalf of the dsp or the ipu. Since you don't even know the number of locks because it is determined at init time, you cannot know at build time that information. You should add an API to reserve some locks at run time instead of doing that. The reserved locks are not meant for syslink use only. It will also be used by i2c, which does not go through syslink. If we were to follow your suggestion, who should call the function to establish number of reserved locks? We can instead think of the config option as requesting a particular number of reserved locks for system use, independent of how many locks actually exist in the system. How many reserved locks there are, and which driver is using which reserved locks -- that is a system integration issue that should be sorted out at a higher level. Syslink was just an example, any driver including i2c can reserve any number of locks. The MPU is always the master, so no other processor will start if the MPU didn't enable them previously. You can always reserve lock at runtime, during board init. BTW, the spinlock is not a system wide resources but more a Soc resource. It is a details, but why are you renaming the registers with the HW prefix? The module name is spinlock not hwspinlock. The names should be that: #define SPINLOCK_REVISION0x #define SPINLOCK_SYSCONFIG 0x0010 #define SPINLOCK_SYSSTATUS 0x0014 #define SPINLOCK_LOCK_BASE 0x0800 or even that since you are not sharing these defines: #define REVISION0x #define SYSCONFIG 0x0010 #define SYSSTATUS 0x0014 #define LOCK_BASE 0x0800 Every IPs are by definition an HW module, so that information is useless. You have a good point, I will make this change. Since it is a new driver for a new IP, why don't you use directly the omap_device / omap_hwmod abstraction? hwmod for spinlock is not currently ready. We want to integrate with the platform/driver/device system for now, as a first step. hwmod can be implemented later. Not ready??? The data was in my git tree for months and is available in Kevin's tree for a while. http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod_44xx_data.c;h=20f5f8c2a67e6e82854f66761f08faf7f65d6ee1;hb=7aefc6cd5c93afe464bcf527d20fdac81d00af77#l3597 Why did you think it was not ready? Even if it was not there, it takes about 30 minutes to write the hwmod for such a basic IP. Doing the platform driver first was perhaps needed for legacy code, in your case, you are probably wasting your time writing code that was be already there and that you will have to remove later. Benoit Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- To unsubscribe from this list: send the line unsubscribe 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-SR] [PATCH] OMAP: PM: Remove the usage of vdd id's.
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 25, 2010 8:49 PM
Thara Gopinath th...@ti.com writes:
This patch removes the usage of vdd and sr id alltogether.
This is achieved by introducing a separte voltage domain per
VDD and hooking this up with the voltage and smartreflex
internal info structure. Any user of voltage or smartreflex layer
should call into omap_volt_domain_get to get the voltage
domain handle and make use of this to call into the various
exported API's.
These changes should be part of V2 of the sr/voltage series
instead of being a separate patch in itself.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
-static struct omap_sr *_sr_lookup(int srid)
+static struct omap_sr *_sr_lookup(struct omap_volt_domain
*volt_domain)
{
struct omap_sr *sr_info, *temp_sr_info;
sr_info = NULL;
list_for_each_entry(temp_sr_info, sr_list, node) {
-if (srid == temp_sr_info-srid) {
+if (volt_domain == temp_sr_info-volt_domain) {
sr_info = temp_sr_info;
break;
Do we still need an _sr_lookup() function? Isn't there a single SR
instance per voltage domain?
Yep, it must be a one to one mapping. But you still need to get the smartreflex
instance that belong to a certain voltage domain. A voltage domain does not know
if it has a SR that can control it.
Benoit
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 4/7] omap3: sr: device: cleanup pr_xxx
strings in c dont need to be split accross multiple lines with \
. instead they can be put as abc def and it is equivalent to
abc def. fix the same
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index dbf7603..7d13704 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -151,8 +151,9 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_dev_data-volts_supported = omap_get_voltage_table(i,
sr_dev_data-volt_data);
if (!sr_dev_data-volts_supported) {
- pr_warning(%s: No Voltage table registerd fo VDD%d.Something \
- really wrong\n\n, __func__, i + 1);
+ pr_warning(%s: No Voltage table registerd fo VDD%d.
+ Something is really wrong\n,
+ __func__, i + 1);
i++;
kfree(sr_data);
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 5/7] omap3: sr: device: add unlikely checks
Add unlikely checks to better optimize the rare occurrance of
erroneous conditions.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 7d13704..177299a 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -43,8 +43,9 @@ static void __init sr_read_efuse(struct omap_sr_dev_data
*dev_data,
{
int i;
- if (!dev_data || !dev_data-volts_supported || !dev_data-volt_data ||
- !dev_data-efuse_nvalues_offs) {
+ if (unlikely(!dev_data || !dev_data-volts_supported ||
+ !dev_data-volt_data ||
+ !dev_data-efuse_nvalues_offs)) {
pr_warning(%s: Bad parameters! dev_data = %x,
dev_data-volts_supported = %x,
dev_data-volt_data = %x,
@@ -87,8 +88,8 @@ static void __init sr_set_testing_nvalues(struct
omap_sr_dev_data *dev_data,
{
int i;
- if (!dev_data || !dev_data-volts_supported ||
- !dev_data-volt_data || !dev_data-test_nvalues) {
+ if (unlikely(!dev_data || !dev_data-volts_supported ||
+ !dev_data-volt_data || !dev_data-test_nvalues)) {
pr_warning(%s: Bad parameters! dev_data = %x,
dev_data-volts_supported = %x,
dev_data-volt_data = %x,
@@ -123,7 +124,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
static int i;
sr_data = kzalloc(sizeof(struct omap_sr_data), GFP_KERNEL);
- if (!sr_data) {
+ if (unlikely(!sr_data)) {
pr_err(%s: Unable to allocate memory for %s sr_data.Error!\n,
__func__, oh-name);
return -ENOMEM;
@@ -150,7 +151,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_data-device_idle = omap_device_idle;
sr_dev_data-volts_supported = omap_get_voltage_table(i,
sr_dev_data-volt_data);
- if (!sr_dev_data-volts_supported) {
+ if (unlikely(!sr_dev_data-volts_supported)) {
pr_warning(%s: No Voltage table registerd fo VDD%d.
Something is really wrong\n,
__func__, i + 1);
@@ -162,7 +163,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
omap_sr_latency,
ARRAY_SIZE(omap_sr_latency), 0);
- if (IS_ERR(od)) {
+ if (unlikely(IS_ERR(od))) {
pr_warning(%s: Could not build omap_device for %s: %s.\n\n,
__func__, name, oh-name);
kfree(sr_data);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 6/7] omap3: sr: device: check for dev_attr
in the unlikely case that hwmod database is messed up, dont crash
report error and attempt to recover.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 177299a..81d2532 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -131,6 +131,12 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
}
sr_dev_data = (struct omap_sr_dev_data *)oh-dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err(%s: Bad oh-dev_attr!\n, __func__);
+ kfree(sr_data);
+ return -EINVAL;
+ }
+
/*
* OMAP3430 ES3.1 chips by default come with Efuse burnt
* with parameters required for full functionality of
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 1/7] omap3: voltage: cleanup pr_xxxx
few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do .
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index d289691..963b037 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -253,8 +253,9 @@ static int vp_debug_set(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
}
return 0;
}
@@ -265,7 +266,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
vsel = voltage_read_reg(info-vp_offs.voltage_reg);
- pr_notice(curr_vsel = %x\n, vsel);
+ pr_notice(%s: curr_vsel = %x\n, __func__, vsel);
*val = vsel * 12500 + 60;
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 2/7] omap3: sr: cleanup pr_xxx
pr_xxx family is not informative for debug unless one decides
to grep the code, instead print the function to help debug
easier on the field.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 57fc9b2..d63691b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -804,8 +804,9 @@ static int omap_sr_params_store(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug to enable\n,
+ __func__);
}
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 0/7] Janitor series 2: cleanups
More misc cleanups for Sr branch including print cleans, checks etc. This series probably should be squashed with other patches in pm-sr branch. note some of these patches address few other comments I had made in an unrelated patch. Related comments prior to providing patches: a) I looked close into sr_device.c, I dont think we should decide in sr_device.c if SR is enabled by default or not. IMHO, this should be passed on from board files. it is not the sr_device's call to make. we have boards which are comfortable with SR and which are not. example some boards may choose to enable SR late in the game, while some may choose to enable it by default. we need to cater to both. e.g. currently 3430 es3.1 would have SR enabled by default. N900 as an example chooses to allow users to decide what to have and is enabled late in the game (boots up disabled, gets enabled once userspace starts). b) It assumes that 3630 have ntargets - this is true from ES1.1 onwards. the older silicon dont have ntargets fused in them. How do we want to handle these? This is the second series independent of series 1: http://marc.info/?l=linux-omapm=127741497415352w=2 Nishanth Menon (7): omap3: voltage: cleanup pr_ omap3: sr: cleanup pr_xxx omap3: sr: enable/disable sr only if required omap3: sr: device: cleanup pr_xxx omap3: sr: device: add unlikely checks omap3: sr: device: check for dev_attr omap3: sr: device: fail sr_dev_init should return error arch/arm/mach-omap2/smartreflex.c | 24 ++-- arch/arm/mach-omap2/sr_device.c | 29 +++-- arch/arm/mach-omap2/voltage.c |7 --- 3 files changed, 41 insertions(+), 19 deletions(-) Regards, Nishanth Menon Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 7/7] omap3: sr: device: fail sr_dev_init should return error
sr_dev_init should return error on error conditions Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/sr_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c index 81d2532..945ff45 100644 --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -163,7 +163,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) __func__, i + 1); i++; kfree(sr_data); - return 0; + return -ENODATA; } sr_set_nvalues(sr_dev_data, sr_data); od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data), @@ -173,6 +173,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) pr_warning(%s: Could not build omap_device for %s: %s.\n\n, __func__, name, oh-name); kfree(sr_data); + return PTR_ERR(od); } i++; return 0; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-SR] [PATCH 3/7] omap3: sr: enable/disable sr only if required
we dont need to go down the path of enabling/disabling the SR
if we dont need to. do some sanity check and trigger if needed
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d63691b..9b5a10e 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -778,15 +778,26 @@ static int omap_sr_autocomp_show(void *data, u64 *val)
static int omap_sr_autocomp_store(void *data, u64 val)
{
struct omap_sr *sr_info = (struct omap_sr *) data;
+ u32 value = (u32) val;
if (!sr_info) {
pr_warning(%s: omap_sr struct for SR not found\n, __func__);
return -EINVAL;
}
- if (!val)
- sr_stop_vddautocomp(sr_info);
- else
- sr_start_vddautocomp(sr_info);
+
+ /* Sanity check */
+ if (value (value != 1)) {
+ pr_err(%s: invalid value %d\n, __func__, value);
+ return -EINVAL;
+ }
+
+ /* change only if needed */
+ if (sr_info-is_autocomp_active ^ value) {
+ if (!val)
+ sr_stop_vddautocomp(sr_info);
+ else
+ sr_start_vddautocomp(sr_info);
+ }
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
Grant Likely grant.lik...@secretlab.ca writes: On Fri, Jun 25, 2010 at 12:04 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Grant Likely grant.lik...@secretlab.ca writes: On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Implement the new runtime PM framework as a thin layer on top of the omap_device API. Since we don't have an OMAP-specific bus, override the runtime PM hooks for the platform_bus for the OMAP specific implementation. While the runtime PM API has three main states (idle, suspend, resume) This version treats idle and suspend the same way by implementing both on top of omap_device_disable(), which follows closely with how driver are currently using clock enable/disable calls. Longer-termm pm_runtime_idle() could take other constraints into consideration to make the decision, but the current Device driver -runtime_suspend() hooks are called just before the device is disabled (via omap_device_idle()), and device driver -runtime_resume() hooks are called just after device has been enabled (via omap_device_enable().) Hi Kevin, Hi Grant. Thanks for the review and suggestions. You shouldn't hijack the platform bus in this way, for a number of reasons. Not all platform devices in an OMAP system are internal OMAP devices (as you know since you do an explicit check for omap devices). Right there that says that the abstraction is at the wrong level. What happens when an mostly transparent bridge is added with its own peripherals and its own special operations? Does this routine then need to be extended for each new special case? It's not maintainable in the long run. This approach is also not multiplatform friendly (cc'ing Eric and Nicolas who are working on ARM multiplatform). It won't work for building a kernel that supports, say, both versatile and OMAP. Totally agree here, but this a separate issue not specifically created by this series (it was created when runtime PM support for SH was added), but indeed I am continuining bad behavior. :/ I think I could successfully argue that ARM is more important that SH. If SH messes up it's sandbox the collateral damage isn't nearly so severe. Don't follow the SH lead in this case. The issue is that the current method to override bus methods is by overriding weak symbols. This clearly doesn't scale to support multiple platforms in the same image. Agreed. It scales better to change the hooks at runtime, which is actually quite easy, but it still leaves the abstraction at the wrong level. What would be needed (if we continue to override the platform_bus methods) is to have some sort of register function for overriding these methods. I'll look into that based on the result of discussions below... The kernel already has the facility to do what you need. We talked about it briefly at ELC, and now that I look at it closer, I thing gregkh is absolutely right. Just create a new bus type for OMAP devices. It is simple to add one. You can probably even call out to the platform bus ops for most of the operations. The fact that OMAP devices have special behaviour that needs to be handled at the bus type level means that they are not platform devices anymore. This also eliminates all the omap_device_is_valid and OMAP_DEVICE_MAGIC gymnastics. I see from the comments in omap_device.c that doing an omap_bus/omap_device is being considered anyway. Please don't merge this patch and do the omap_bus_type instead. Agreed, it is logicially simpler in many ways and as you've noticed, we've been discussing it in the OMAP community. However, I keep coming back to extending the platform bus, primarily since the resulting new bus code would look almost identical to the platform bus. All I really needed is the ability to extend a small subset of the PM functions, so this led to me the extend instead of duplicate approach. In addition, I really don't want to duplicate all the platform_driver and platform_device code, again because it would be identical but especially since this would seriously impact many drivers. For drivers that are used on OMAP and also on other platforms, do we want drivers to know (or care) if they are on the platform bus or on the OMAP bus? Some questions to make sure I understand: Do you have a lot of these cases? Yes, there are several. There are several instances of hardware blocks that are re-used across OMAP and DaVinci but where the device clocking and PM infrastructure is totally different. Runtime PM helps a lot here in that all the details can be done in low-level, SoC specific code. There are even cases of OMAP-derivative parts that will change clocking or change (or remove) PM internal details and require special handling. We want to be able to use the same driver for all these, and not care if it's an OMAP, Davinci, OMAP-derivative etc. There's also the special case of the MUSB driver which is on
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, Jun 25, 2010 at 3:58 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Grant Likely grant.lik...@secretlab.ca writes: Yes, I've got patches which merge of_platform_bus_type with the platform bus. This was an easy decision to make because the of-specific bits (specifically, matching an of_device_id table with a device tree node) are applicable to all bus types; i2c, spi, mdio, platform, etc). The needed OF data structures have been moved into struct device and struct device_driver so that of_platform_bus_type no longer has anything different. The drivers still need to care about OF when extra platform data needs to be extracted from the DT node, but for IRQs and register ranges it is automatic. Does that mean the drivers are still doing platform_get_resource() for either platform devices or OF devices, or are does the driver have to know which bus it was on and call accordingly. It's the latter that I want to stay away from. platform_get_resource() works for OF and non-OF platform devices with no extra code needed in the OF case. It's the other data that requires special code because it is provided in the device tree instead of in a platform_data structure. A driver that normally uses platform_data will need extra code early in the probe hook to go and parse the device tree and populate the private data structures accordingly. This behaviour has to be handled in the driver because every driver uses a different platform_data structure. It cannot be generic code. The rest of the driver can remain untouched. In the old (bad) way, the bus type was entirely different, and drivers used by both platform_bus_type and of_platform_bus_type needed to have entirely separate device_driver structures and probe() hooks for each bus type. [...] So, instead of having all the platform_bus_type devices as children of the platform device (/sys/devices/platform/*), you could set the omap devices to be children of an omap bus device (/sys/devices/omap/*). Different busses can also implement different behaviour by using a different parent device. For example: /sys/devices/platform /sys/devices/omap-bus-a /sys/devices/omap-bus-a/omap-bus-b Thoughts? Hmm, I like this idea. This is certainly worth exploring as a first pass. Thanks for the idea, :-) g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
Grant Likely grant.lik...@secretlab.ca writes: Another way to look at the problem is that these runtime customizations are kind of a property of the parent device (the bus, not the bus_type). Would it make sense for parent devices to have runtime ops to perform for each child that is suspended/resumed? That would make it simple to register another device that implements the bus behaviour and attach it at runtime instead of compile time. Maybe I didn't fully understand your idea, but the problem here is devices do not have dev_pm_ops. Only busses, classes, and types have dev_pm_ops. Though I'm horribly unfamiliar with the intended usage of 'struct device_type', an interesing discovery is that dev-type also has dev_pm_ops, and it takes precedence over the bus type in the suspend/resume. IOW, when suspending, when deciding which dev_pm_ops to use, it checks class, type, then bus in that order. I need to explore this 'type' feature a little more, but using that or the 'class' might be another way to have custom PM ops for certain platform_devices. 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 7/8] OMAP: PM: Allowing an early init of pm debugfs driver.
Thara Gopinath th...@ti.com writes: This patch changes the pm_db_init from arch initcall to a postcore initcall. With arch initcall, it is impossible for pm driver that gets initialized prior to this driver to use one of the pm debug fs entries during its init. Making it a postcore initcall ensures that this drver gets initialized early on before any pm drivers. Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm-debug.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 4280006..b239c16 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -611,6 +611,6 @@ static int __init pm_dbg_init(void) return 0; } -arch_initcall(pm_dbg_init); +postcore_initcall(pm_dbg_init); There's already a 'pm_dbg_init_done' flag in this code being used for that purpose. That should be re-used instead. 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 v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, Jun 25, 2010 at 4:46 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Grant Likely grant.lik...@secretlab.ca writes: Another way to look at the problem is that these runtime customizations are kind of a property of the parent device (the bus, not the bus_type). Would it make sense for parent devices to have runtime ops to perform for each child that is suspended/resumed? That would make it simple to register another device that implements the bus behaviour and attach it at runtime instead of compile time. Maybe I didn't fully understand your idea, but the problem here is devices do not have dev_pm_ops. Only busses, classes, and types have dev_pm_ops. Sorry, I mistyped. What I meant was for the parent device's device_driver to be able to have a set of child dev_pm_ops; but I'm wading into territory (power management) I'm not particularly familiar with, and that might be making things far too complex. Though I'm horribly unfamiliar with the intended usage of 'struct device_type', an interesing discovery is that dev-type also has dev_pm_ops, and it takes precedence over the bus type in the suspend/resume. IOW, when suspending, when deciding which dev_pm_ops to use, it checks class, type, then bus in that order. So I guess my suggestion above boils down to somehow inserting parent between type and bus in that list. I need to explore this 'type' feature a little more, but using that or the 'class' might be another way to have custom PM ops for certain platform_devices. Should maybe start cc'ing Greg and linux-kernel/linux-pm in this discussion. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH:v4 12/13] OMAP: GPIO: Implement GPIO as a platform device
Charulatha V ch...@ti.com writes:
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
This patch makes GPIO to use runtime APIs.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before machine_init. Therefore
GPIO device register and driver register are implemented as
postcore_initcalls.
Inorder to convert GPIO as platform device, modifications are
required in clock_data.c file for OMAP1 so that device names
can be used to obtain clock instead of getting clocks by
name/NULL ptr.
omap_gpio_init() does nothing now and this function would be
removed in the next patch as it's usage is spread across most of
the board files.
TODO:
1. Cleanup the GPIO driver. Use function pointers and register
offest pointers instead of using hardcoded values
2. Remove all cpu_is_ checks and OMAP specific macros
3. Remove usage of gpio_bank array so that only
instance specific information is used in driver code
4. Modify save/restore context, gpio_prepare_for_idle,
and gpio_resume_after_idle functions as instance
specific function and not for all instances in a single call
init_gpio_info() too.
I think this item (TODO #4) needs to be done as part of this series, as
this new generic driver needs to be completely ignorant of how many
banks are on chip, or currently in use. All operations should be on a
single device (in this case, a single GPIO bank.)
As each hwmod has its own device, it can have it's own independent
suspend/resume. To do this, you should remove the sysdev_class and
sys_device just use the regular device. Here's a little patch[1] on top
of your current series that shows how you would hook up the standard PM
methods. Also, the prepare_for_idle, resume_from_idle should be handled
by the runtime PM callbacks.
With the save/restore context handled on demand (when mod_usage
transitions to/from zero), and the runtime PM calls handled from within
the driver, we could get rid of all the GPIO calls from
omap_sram_idle(). That would be a huge improvement.
Kevin
[1] compile-tested only
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 6dc5e4b..6a5a8f4 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2091,10 +2091,44 @@ void omap_gpio_restore_context(void)
}
#endif
+static int gpio_bank_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int gpio_bank_resume(struct device *dev)
+{
+ return 0;
+}
+
+static int gpio_bank_runtime_idle(struct device *dev)
+{
+ return 0;
+}
+
+static int gpio_bank_runtime_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int gpio_bank_runtime_resume(struct device *dev)
+{
+ return 0;
+}
+
+static struct dev_pm_ops gpio_pm_ops = {
+ .suspend = gpio_bank_suspend,
+ .resume = gpio_bank_resume,
+ .runtime_idle= gpio_bank_runtime_idle,
+ .runtime_suspend = gpio_bank_runtime_suspend,
+ .runtime_resume = gpio_bank_runtime_resume,
+};
+
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
.driver = {
.name = omap-gpio,
+ .pm = gpio_pm_ops,
},
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Fri, 25 Jun 2010, Russell King - ARM Linux wrote: Does anyone know where we are on the defconfig problem? From what I can see, it's mostly stalled for the time being, which is not good news for us. What looked to be promizing is the work by Uwe Kleine-König according to the preview he posted on June 10: Message-id: 20100610063234.ga22...@pengutronix.de Nicolas
