* Please help with the OMAP static mapping mess
From: Tony Lindgren @ 2011-10-04 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMQu2gxgRZzb6hh5pOVBgaPUZEizEqBr_e358MBuD_xHJOvX3Q@mail.gmail.com>
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [111003 22:45]:
> On Tue, Oct 4, 2011 at 4:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [111003 15:05]:
> >> On Mon, 3 Oct 2011, Nicolas Pitre wrote:
> >>
> >> > On Mon, 3 Oct 2011, Tony Lindgren wrote:
> >> >
> >> > > * Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
> >> > > >
> >> > > > Furthermore... there is also a static mapping for physical address
> >> > > > 0x4e000000 using virtual address 0xff100000 which is already reserved
> >> > > > for other purposes i.e. the consistent DMA area. ?It is not immediately
> >> > > > obvious where this comes from without being intimate with the OMAP code.
> >> > > > Can this be fixed as well i.e. moved elsewhere please?
> >> > >
> >> > > This sounds like a bug somewhere. Which omap are you seeing this on?
> >> >
> >> > OMAP4430 on a Panda board.
> >> >
> >> > Here are the static mappings I'm seeing:
> >> >
> >> > phys = 0x44000000 virt = 0xf8000000 size = 0x100000
> >> > phys = 0x4a000000 virt = 0xfc000000 size = 0x400000
> >> > phys = 0x50000000 virt = 0xf9000000 size = 0x100000
> >> > phys = 0x4c000000 virt = 0xfd100000 size = 0x100000
> >> > phys = 0x4d000000 virt = 0xfe100000 size = 0x100000
> >> > phys = 0x4e000000 virt = 0xff100000 size = 0x100000 <---
> >> > phys = 0x48000000 virt = 0xfa000000 size = 0x400000
> >> > phys = 0x54000000 virt = 0xfe800000 size = 0x800000
> >>
> >> It looks like this comes from OMAP44XX_DMM_VIRT.
> >>
> >> #define OMAP44XX_DMM_PHYS ? ? ? OMAP44XX_DMM_BASE
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* 0x4e000000 --> 0xfd300000 */
> >> #define OMAP44XX_DMM_VIRT ? ? ? (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET)
> >> #define OMAP44XX_DMM_SIZE ? ? ? SZ_1M
> >>
> >> The comment suggesting a mapping correspondance is obviously wrong. We have:
> >>
> >> #define OMAP44XX_DMM_BASE ? ? ? 0x4e000000
> >> #define OMAP4_L3_PER_IO_OFFSET ?0xb1100000
> >>
> >> Hence 0x4e000000 + 0xb1100000 = 0xff100000.
> >
> > Seem like it might cause some random patterns in tiler :)
> > Santosh, can youp please check it?
> >
> This is already fixed Tony. You have pulled that patch.
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg55258.html
OK thanks. Yup, looks like it's queued up in l3 branch.
Tony
^ permalink raw reply
* [PATCH 0/4] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
From: Vishwanath BS @ 2011-10-04 17:52 UTC (permalink / raw)
To: linux-arm-kernel
The folowing patch series provides IO Daisychain feature via omap hwmod mux
framework.
The patch series has been generated against 3.1 rc4 and tested on OMAP3 Platform
(ZOOM3) for Retention and OFF mode in suspend/cpuidle path.
Also tested against latest UART Runtime with Chain Handler patches [1].
[1]: git://gitorious.org/runtime_3-0/runtime_3-0.git v6_uart_runtime
Rajendra Nayak (1):
OMAP4 PM: Add IO Daisychain support
Vishwanath BS (3):
OMAP3 PM: Fix IO Daisychain sequence
OMAP3 PM: Enable IO Wake up
OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
arch/arm/mach-omap2/omap_hwmod.c | 9 +++++++--
arch/arm/mach-omap2/pm.c | 9 +++++++++
arch/arm/mach-omap2/pm.h | 3 +++
arch/arm/mach-omap2/pm34xx.c | 33 +++++++--------------------------
arch/arm/mach-omap2/pm44xx.c | 36 ++++++++++++++++++++++++++++++++++++
5 files changed, 62 insertions(+), 28 deletions(-)
^ permalink raw reply
* [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
From: Vishwanath BS @ 2011-10-04 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-1-git-send-email-vishwanath.bs@ti.com>
As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for enabling IO Daisy
chain is "The I/O wake-up scheme is enabled by triggering the I/O daisy chain
control (Wu clock) by programming a dedicated register
(PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software must wait for
the I/O daisy chain to complete before it transitions the PER domain to a
nonfunctional state. This is done by polling a dedicated status bit in the PRCM
module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared by
software when the bit is read to 1".
The original code was polling on a wrong register which is fixed in this patch.
Also omap3_enable_io_chain is made non static as it's going to be used in
subsequent patches.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..9a36a7c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern void omap3_enable_io_chain(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..61f1a5b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -95,7 +95,7 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
+void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout > 1000) {
@@ -114,7 +114,7 @@ static void omap3_enable_io_chain(void)
return;
}
omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
+ WKUP_MOD, PM_WKST);
}
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/4] ARM: OMAP4 PM: Add IO Daisychain support
From: Vishwanath BS @ 2011-10-04 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-1-git-send-email-vishwanath.bs@ti.com>
From: Rajendra Nayak <rnayak@ti.com>
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm44xx.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 9a36a7c..2e09d72 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
extern void omap3_enable_io_chain(void);
+extern void omap4_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..aa7cff4 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -16,8 +16,17 @@
#include <linux/err.h>
#include <linux/slab.h>
+#include <plat/common.h>
+
#include "powerdomain.h"
#include <mach/omap4-common.h>
+#include "pm.h"
+#include "cm-regbits-44xx.h"
+#include "cminst44xx.h"
+#include "prm-regbits-44xx.h"
+#include "prcm44xx.h"
+#include "prm44xx.h"
+#include "prminst44xx.h"
struct power_state {
struct powerdomain *pwrdm;
@@ -30,6 +39,33 @@ struct power_state {
static LIST_HEAD(pwrst_list);
+#define MAX_IOPAD_LATCH_TIME 1000
+
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!omap4_cminst_read_inst_reg_bits(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET,
+ OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ ((omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
+ >> OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+ /* Trigger WUCLKIN disable */
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
+
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/4] ARM: OMAP3 PM: Enable IO Wake up
From: Vishwanath BS @ 2011-10-04 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-1-git-send-email-vishwanath.bs@ti.com>
Enable IO Wake up for OMAP3 as part of PM Init.
Currently this has been managed in cpuidle path which is not the right place.
Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy
chain is handled as part of hwmod mux.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 61f1a5b..6c80988 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -885,6 +885,9 @@ static int __init omap3_pm_init(void)
goto err1;
}
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR "Failed to setup powerdomains\n");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/4] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
From: Vishwanath BS @ 2011-10-04 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-1-git-send-email-vishwanath.bs@ti.com>
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration.
The patch also removes IO Daisychain control from OMAP3 CPUIdle path since
it is not required anymore as it has handled via hwmod mux.
omap3_enable_io_chain is renamed as omap3_trigger_wuclk_ctrl as it is not really
enabling daisychain feature rather it triggers WUCLK CTRL.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 9 +++++++--
arch/arm/mach-omap2/pm.c | 9 +++++++++
arch/arm/mach-omap2/pm.h | 3 ++-
arch/arm/mach-omap2/pm34xx.c | 26 ++------------------------
4 files changed, 20 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..070f3f5 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -151,6 +151,7 @@
#include "prm44xx.h"
#include "prminst44xx.h"
#include "mux.h"
+#include "pm.h"
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 10000
@@ -1462,8 +1463,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh->mux && (!oh->mux->enabled ||
((oh->_state == _HWMOD_STATE_IDLE) &&
- oh->mux->pads_dynamic)))
+ oh->mux->pads_dynamic))) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_wuclk_ctrl();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1553,8 +1556,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh->clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh->mux && oh->mux->pads_dynamic)
+ if (oh->mux && oh->mux->pads_dynamic) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
+ omap_trigger_wuclk_ctrl();
+ }
oh->_state = _HWMOD_STATE_IDLE;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 3feb359..c3295fe 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -95,6 +95,15 @@ static void omap2_init_processor_devices(void)
}
}
+void omap_trigger_wuclk_ctrl(void)
+{
+ if (cpu_is_omap34xx())
+ omap3_trigger_wuclk_ctrl();
+
+ if (cpu_is_omap44xx())
+ omap4_trigger_wuclk_ctrl();
+}
+
/* Types of sleep_switch used in omap_set_pwrdm_state */
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2e09d72..9784d81 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,8 +21,9 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
-extern void omap3_enable_io_chain(void);
+extern void omap3_trigger_wuclk_ctrl(void);
extern void omap4_trigger_wuclk_ctrl(void);
+extern void omap_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 6c80988..6417ccb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -95,11 +95,11 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-void omap3_enable_io_chain(void)
+void omap3_trigger_wuclk_ctrl(void)
{
int timeout = 0;
- if (omap_rev() >= OMAP3430_REV_ES3_1) {
+ if ((omap_rev() >= OMAP3430_REV_ES3_1) && omap3_has_io_wakeup()) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
PM_WKEN);
/* Do a readback to assure write has been done */
@@ -119,13 +119,6 @@ void omap3_enable_io_chain(void)
}
}
-static void omap3_disable_io_chain(void)
-{
- if (omap_rev() >= OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -372,12 +365,6 @@ 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 (omap3_has_io_wakeup() &&
- (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
- omap3_enable_io_chain();
- }
/* Block console output in case it is on one of the OMAP UARTs */
if (!is_suspending())
@@ -469,15 +456,6 @@ void omap_sram_idle(void)
console_unlock();
console_still_active:
- /* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup() &&
- (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)) {
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
- PM_WKEN);
- omap3_disable_io_chain();
- }
-
pwrdm_post_transition();
clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Grant Likely @ 2011-10-04 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89C3FA.9020206@gmail.com>
On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
> > + /* Query the hardware for parent and initial rate */
> > +
> > + if (clk->ops->get_parent)
> > + /* We don't to lock against prepare/enable here, as
> > + * the clock is not yet accessible from anywhere */
> > + clk->parent = clk->ops->get_parent(clk->hw);
>
> I don't think this is going to work. This implies that the parent clock
> is already registered. For simple clk trees, that's probably not an
> issue, but for chips with lots of muxing it will be impossible to get
> the order correct for all cases. This is not an issue today as most
> clocks are statically created.
>
> I think what is needed is a 2 stage init. The 1st stage to create all
> the clocks and a 2nd stage to build the tree once all clocks are created.
>
> Tracking the parents using struct clk_hw instead would help as long as
> clocks are still statically allocated. However, that won't help for
> devicetree.
I disagree. Clocks really need to be registered in dependency order.
Even in the deferral case, the driver should hold of actually
registering the clk (note: the struct clk, not the struct device)
until the clocks it depends on are available.
I also agree with the point that there are a lot of SoC clocks that
may not even show up in clkdev, and for pragmatic considerations are
better set up all at once early in the init process (ie. as part of
common SoC setup code, and doesn't change between boards). That code
should be clue-full enough that it can register its own clocks in the
right order.
g.
^ permalink raw reply
* [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata
From: Kevin Hilman @ 2011-10-04 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbZhz8LcAYZEY3qqRkX4E_wtspWp09Eq9G=5VdpoMMF1FQ@mail.gmail.com>
Ohad Ben-Cohen <ohad@wizery.com> writes:
> Hi Kevin,
>
> On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Benoit did just this in preparation for DT.
>>
>> ? ? ? http://marc.info/?l=linux-omap&m=131672480111927&w=2
>>
>> Will that meet your needs?
>
> It's almost there, but not entirely.
>
> Benoit's alloc/delete functions focus on the omap_device part, leaving
> the handling of the platform device (allocation and pdata setting) to
> omap_device_build_ss(), which at the same time registers the pdev.
>
> I'd need to split omap_device_build_ss() into two: an alloc() part
> which does everything but registering the pdev, and a register() part.
> Users will first call alloc(), manually set archdata members, and then
> call the register() part.
>
> Something like this (compile-tested only, based on Benoit's
> for_3.2/4_omap4_dt_early_devices branch):
[...]
> That's the idea; please tell me how you'd like to see this go forward
> (there are at least several personal-taste issues here, e.g., naming:
> now we have two sets of alloc/delete functions which have different
> semantics)
The approach is OK with me, but I'm a bit torn about whether or not to
merge this since the need for this should go away when converting to DT.
Is anyone working on IOMMU DT description?
I guess if I do merge this, we can also clean this up significantly
after all devices are converted to DT.
> and which branch would you like me to base this work off of
> (not sure if Benoit's patches already went into your
> for_3.2/omap_device branch) and I'll respin this patch properly.
Unless it has other dependencies on Benoit's further DT patches, you can
base this on my for_3.2/omap_device-2 branch which includes Benoit's
alloc changes.
Kevin
^ permalink raw reply
* [PATCH v2 6/7] clk: Add initial WM831x clock driver
From: Grant Likely @ 2011-10-04 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926093858.GD2946@opensource.wolfsonmicro.com>
On Mon, Sep 26, 2011 at 10:38:58AM +0100, Mark Brown wrote:
> On Sat, Sep 24, 2011 at 10:08:36PM -0600, Grant Likely wrote:
> > On Thu, Sep 22, 2011 at 03:27:01PM -0700, Mike Turquette wrote:
>
> > > + ret = platform_driver_register(&wm831x_clk_driver);
> > > + if (ret != 0)
> > > + pr_err("Failed to register WM831x clock driver: %d\n", ret);
> > > +
> > > + return ret;
>
> > No need for this song-and-dance. The driver core is pretty well
> > debugged. Just use "return platform_driver_register(...);"
>
> No, that's not helpful. The issue isn't the device probe code itself,
> the issue is things like module unload not doing what they're supposed
> to do and leaving the device lying around or something - there's rather
> more going on than just the plain API call.
Then lets fix the core code. I see this pattern show up again and
again of extra boilerplate going around
platform_driver_{register,unregister}(). That says to me that there
either needs to be a new helper, or the core code needs to be made
more verbose.
In fact, I've been considering adding a macro for
{platform,i2c,spi,...}_drivers that does all the module boilerplate
for the common case of only registering a driver at init time.
Something like:
#define module_platform_driver(__driver) \
int __driver##_init(void) \
{ \
return platform_driver_register(&(__driver)); \
} \
module_init(__driver##_init); \
void ##__driver##_exit(void) \
{ \
platform_driver_unregister(&(__driver)); \
} \
module_exit(##__driver##_exit);
It's not a lot of code, but I dislike how much boilerplate every
single driver has to use if it doesn't do anything special.
g.
^ permalink raw reply
* [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
From: Grant Likely @ 2011-10-04 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110031126090.4611@utopia.booyaka.com>
On Mon, Oct 03, 2011 at 11:34:34AM -0600, Paul Walmsley wrote:
> + devicetree-discuss, lkml
>
> On Mon, 3 Oct 2011, Cousson, Benoit wrote:
>
> > But at that time, device tree was not there...
> > Now, the whole dev_attr stuff will be replaced because device tree is able to
> > provide the driver any kind of custom information that can be retrieved
> > directly from the driver without having to use a pdata in between. So I'm not
> > sure it worth spending too much time on that feature stuff.
> >
> > As an example here is the ongoing GPIO DT migration:
> > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg56505.html
> >
> > 3.2 will have the basic DT support using hwmod as a backend, but the idea is
> > that for 3.3, we start removing some information from hwmod to rely on device
> > tree only.
>
> One comment here though -- and I will make this comment on the original
> series too -- is that we should avoid adding direct DT dependencies into
> the driver.
>
> Specifically, these of_get_property() and of_property*() calls in the
> driver aren't right.
>
> We need some way of doing this that is completely independent from the
> device data format. Some way that does not care whether the input data is
> coming from DT, platform_data, ACPI, or whatever the new flavor of the
> year will be next year. Or we need to declare that these of_*() calls are
> not DT-specific, and define them as hooks that the device data format code
> can handle as it pleases.
Generally, I agree. For example, I've been thinking of either
modifying or creating bus_type-agnostic variants of the
platform_get_*() hooks so that the driver can get the data it needs
without knowing what the data source is. (Actually, it already works
that way for platform_devices and DT, but that is only because the DT
code populates the resource table when the device is created).
This works best for well understood things like GPIOs, IRQs, memory
ranges, and the like. It doesn't really work very well for data
specific to the device.
g.
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: G, Manjunath Kondaiah @ 2011-10-04 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6tXEx1A+ZuBTUdi8jjfx_hOCaX6eSpUOOhNH9us+Mnczg@mail.gmail.com>
On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
> On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> > On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
> >> Hi Manjunath,
> >>
> >> Here's the current state of the patch. ?The major think that needs to
> >> be done is to convert it to use a separate workqueue as described in
> >> the TODO above. ?It also needs some users adapted to it. ?One of the
> >> gpio drivers would work; preferably one of the newer drivers that
> >> doesn't have a lot of drivers depending on the early_initcall()
> >> behaviour yet.
> >
> > I have tested this patch on omap3 beagle board by making:
> > 1. omap-gpio driver init as late_initcall instead of postcore_initcall
> > 2. mmc driver probe will request gpio through gpio_request and gpio driver
> > returns -EDEFER_PROBE which in turn makes mmc driver to request deferral probe.
> > 3. When deferral probe gets activated, it scans driver entries and it will not
> > find any match for mmc driver probe.
>
> Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
> instead of platform_driver_register(). Add the probe hook to the
> platform_driver structure and change it to call
> platform_driver_register() and it should work. Don't forget to change
> mmc_omap_probe from __init to __devinit.
Yes. After changing it into platform_driver_register, I can see mmc probe is
getting completed from deferred probe list. But, MMC upper layer will check
probe and it waits for ever since probe_count is not getting incremented.
Log:
[ 1.807830] platform omap_hsmmc.0: Driver omap_hsmmc requests probe deferral
...
[ 1.948760] omap_device: omap_gpio.0: new worst case activate latency 0:30517
[ 1.959259] OMAP GPIO hardware version 2.5
...
[ 2.000488] platform omap_hsmmc.0: Retrying from deferred list
[ 2.008026] omap_device: omap_hsmmc.0: new worst case activate latency 0:244140
[ 2.020080] input: gpio-keys as /devices/platform/gpio-keys/input/input1
[ 2.035827] omap_hsmmc omap_hsmmc.0: Probe success...
[ 2.042083] twl_rtc twl_rtc: setting system clock to 2000-01-01 01:06:35 UTC
(946688795)
[ 2.056030] Waiting for root device /dev/mmcblk0p2...
[ 2.061492] driver_probe_done: probe_count = 0
[ 2.168518] driver_probe_done: probe_count = 0
[ 2.277832] driver_probe_done: probe_count = 0
[ 2.387207] driver_probe_done: probe_count = 0
[ 2.496582] driver_probe_done: probe_count = 0
Waits for ever in init/do_mount.c:
if ((ROOT_DEV == 0) && root_wait) {
printk(KERN_INFO "Waiting for root device %s...\n",
saved_root_name);
while (driver_probe_done() != 0 ||
(ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
msleep(100);
async_synchronize_full();
}
-Manjunath
^ permalink raw reply
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
From: Nicolas Pitre @ 2011-10-04 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109230908410.12663@xanadu.home>
On Fri, 23 Sep 2011, Nicolas Pitre wrote:
> Russell, please pull
>
> git://git.linaro.org/people/nico/linux vmalloc
Given the problems that exist in the OMAP tree and their likely fixes
going into mainline only during the next merge window, I'm withdrawing
this request until the next cycle.
> One regression was discovered on shmobile during testing because that
> platform asks for 158MB of consistent DMA memory while the documented
> maximum is 14MB. Inspection of the code doesn't tell why this is
> required, and listed maintainers did not respond yet after a couple
> days. So a temporary exception to the definition of VMALLOC_END was
> added for CONFIG_SHMOBILE and a noisy warning to get those maintainers'
> attention.
For the record, those maintainers still didn't respond.
Nicolas
^ permalink raw reply
* [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
From: Tony Lindgren @ 2011-10-04 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-2-git-send-email-vishwanath.bs@ti.com>
* Vishwanath BS <vishwanath.bs@ti.com> [111004 10:25]:
> @@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
> /* Do a readback to assure write has been done */
> omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
>
> - while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
> + while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
> OMAP3430_ST_IO_CHAIN_MASK)) {
> timeout++;
> if (timeout > 1000) {
Checking for PM_WKST here makes sense..
> @@ -114,7 +114,7 @@ static void omap3_enable_io_chain(void)
> return;
> }
> omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
> - WKUP_MOD, PM_WKEN);
> + WKUP_MOD, PM_WKST);
> }
> }
> }
..but are you sure you also want to write into PM_WKST?
Tony
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Nicolas Pitre @ 2011-10-04 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926191055.GP22455@n2100.arm.linux.org.uk>
On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> This also gives additional merge conflicts elsewhere, and while git
> rerere makes some of them easy, the quantity is going to be a right
> pain to deal with on a repeated basis.
Does this mean that you will only merge this before asking Linus to
pull? I would like to know on which leg I should stand with this
series.
Nicolas
^ permalink raw reply
* [PATCH 26/30] ARM: omap: add board autoselection
From: Arnd Bergmann @ 2011-10-04 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004155752.GT6324@atomide.com>
On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [111004 00:10]:
> > On Monday 03 October 2011, Tony Lindgren wrote:
> >
> > > Yes please leave out the list so we don't need to constantly update it.
> > > Let's just always build in MACH_OMAP_GENERIC.
> >
> > That's what I had initially, but now that board file has become
> > omap2-specific and no longer works on omap3-only or omap4-only
> > configurations.
>
> Will send a pull request for basic DT bootstrap support from Benoit
> that fixes that. So maybe let's sort that out first, then always
> select it?
Yes, sounds good. That is certainly the better solution in the long run.
Arnd
^ permalink raw reply
* [PATCH v2] regulator: Add driver for gpio-controlled regulators
From: Heiko Stübner @ 2011-10-04 19:34 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for regulators that can be controlled via gpios.
Examples for such regulators are the TI-tps65024x voltage regulators
with 4 fixed and 1 runtime-switchable voltage regulators
or the TI-bq240XX charger regulators.
The number of controlling gpios is not limited, the mapping between
voltage/current and target gpio state is done via the states map
and the driver can be used for either voltage or current regulators.
A mapping for a regulator with two GPIOs could look like:
gpios = {
{ .gpio = GPIO1, .flags = GPIOF_OUT_INIT_HIGH, .label = "gpio name 1" },
{ .gpio = GPIO2, .flags = GPIOF_OUT_INIT_LOW, .label = "gpio name 2" },
}
The flags element of the gpios array determines the initial state of
the gpio, set during probe. The initial state of the regulator is also
calculated from these values
states = {
{ .value = volt_or_cur1, .gpios = (0 << 1) | (0 << 0) },
{ .value = volt_or_cur2, .gpios = (0 << 1) | (1 << 0) },
{ .value = volt_or_cur3, .gpios = (1 << 1) | (0 << 0) },
{ .value = volt_or_cur4, .gpios = (1 << 1) | (1 << 0) },
}
The target-state for the n-th gpio is determined by the n-th bit
in the bitfield of the target-value.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes since v1:
address comments from Mark Brown, mainly use gpio_request_array
to allocate the settings-gpios.
readd forgotten patch history
changes since rfc v2:
add capability to work as voltage or current regulator
test on bq24075 and tps650240 and fix runtime errors
changes since rfc v1:
modifiy voltage switching driver to work with more than one gpio,
making it a versatile driver for gpio controlled regulators
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/gpio-regulator.c | 357 ++++++++++++++++++++++++++++++
include/linux/regulator/gpio-regulator.h | 87 ++++++++
4 files changed, 454 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c7fd2c0..5e0c7b6 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -64,6 +64,15 @@ config REGULATOR_USERSPACE_CONSUMER
If unsure, say no.
+config REGULATOR_GPIO
+ tristate "GPIO regulator support"
+ help
+ This driver provides support for regulators that can be
+ controlled via gpios.
+ It is capable of supporting current and voltage regulators
+ and the platform has to provide a mapping of GPIO-states
+ to target volts/amps.
+
config REGULATOR_BQ24022
tristate "TI bq24022 Dual Input 1-Cell Li-Ion Charger IC"
help
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 040d5aa..93a6318 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
+obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
obj-$(CONFIG_REGULATOR_BQ24022) += bq24022.o
obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c
new file mode 100644
index 0000000..abf32ad
--- /dev/null
+++ b/drivers/regulator/gpio-regulator.c
@@ -0,0 +1,357 @@
+/*
+ * gpio-regulator.c
+ *
+ * Copyright 2011 Heiko Stuebner <heiko@sntech.de>
+ *
+ * based on fixed.c
+ *
+ * Copyright 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
+ *
+ * Copyright (c) 2009 Nokia Corporation
+ * Roger Quadros <ext-roger.quadros@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This is useful for systems with mixed controllable and
+ * non-controllable regulators, as well as for allowing testing on
+ * systems with no controllable regulators.
+ */
+
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/gpio-regulator.h>
+#include <linux/gpio.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+
+struct gpio_regulator_data {
+ struct regulator_desc desc;
+ struct regulator_dev *dev;
+
+ int enable_gpio;
+ bool enable_high;
+ bool is_enabled;
+ unsigned startup_delay;
+
+ struct gpio *gpios;
+ int nr_gpios;
+
+ struct gpio_regulator_state *states;
+ int nr_states;
+
+ int state;
+};
+
+static int gpio_regulator_is_enabled(struct regulator_dev *dev)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+
+ return data->is_enabled;
+}
+
+static int gpio_regulator_enable(struct regulator_dev *dev)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+
+ if (gpio_is_valid(data->enable_gpio)) {
+ gpio_set_value_cansleep(data->enable_gpio, data->enable_high);
+ data->is_enabled = true;
+ }
+
+ return 0;
+}
+
+static int gpio_regulator_disable(struct regulator_dev *dev)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+
+ if (gpio_is_valid(data->enable_gpio)) {
+ gpio_set_value_cansleep(data->enable_gpio, !data->enable_high);
+ data->is_enabled = false;
+ }
+
+ return 0;
+}
+
+static int gpio_regulator_enable_time(struct regulator_dev *dev)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+
+ return data->startup_delay;
+}
+
+static int gpio_regulator_get_value(struct regulator_dev *dev)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+ int ptr;
+
+ for (ptr = 0; ptr < data->nr_states; ptr++)
+ if (data->states[ptr].gpios == data->state)
+ return data->states[ptr].value;
+
+ return -EINVAL;
+}
+
+static int gpio_regulator_set_value(struct regulator_dev *dev,
+ int min, int max)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+ int ptr, target, state;
+
+ target = -1;
+ for (ptr = 0; ptr < data->nr_states; ptr++)
+ if (data->states[ptr].value >= min &&
+ data->states[ptr].value <= max)
+ target = data->states[ptr].gpios;
+
+ if (target < 0)
+ return -EINVAL;
+
+ for (ptr = 0; ptr < data->nr_gpios; ptr++) {
+ state = (target & (1 << ptr)) >> ptr;
+ gpio_set_value(data->gpios[ptr].gpio, state);
+ }
+ data->state = target;
+
+ return 0;
+}
+
+static int gpio_regulator_set_voltage(struct regulator_dev *dev,
+ int min_uV, int max_uV,
+ unsigned *selector)
+{
+ return gpio_regulator_set_value(dev, min_uV, max_uV);
+}
+
+static int gpio_regulator_list_voltage(struct regulator_dev *dev,
+ unsigned selector)
+{
+ struct gpio_regulator_data *data = rdev_get_drvdata(dev);
+
+ if (selector >= data->nr_states)
+ return -EINVAL;
+
+ return data->states[selector].value;
+}
+
+static int gpio_regulator_set_current_limit(struct regulator_dev *dev,
+ int min_uA, int max_uA)
+{
+ return gpio_regulator_set_value(dev, min_uA, max_uA);
+}
+
+static struct regulator_ops gpio_regulator_voltage_ops = {
+ .is_enabled = gpio_regulator_is_enabled,
+ .enable = gpio_regulator_enable,
+ .disable = gpio_regulator_disable,
+ .enable_time = gpio_regulator_enable_time,
+ .get_voltage = gpio_regulator_get_value,
+ .set_voltage = gpio_regulator_set_voltage,
+ .list_voltage = gpio_regulator_list_voltage,
+};
+
+static struct regulator_ops gpio_regulator_current_ops = {
+ .is_enabled = gpio_regulator_is_enabled,
+ .enable = gpio_regulator_enable,
+ .disable = gpio_regulator_disable,
+ .enable_time = gpio_regulator_enable_time,
+ .get_current_limit = gpio_regulator_get_value,
+ .set_current_limit = gpio_regulator_set_current_limit,
+};
+
+static int __devinit gpio_regulator_probe(struct platform_device *pdev)
+{
+ struct gpio_regulator_config *config = pdev->dev.platform_data;
+ struct gpio_regulator_data *drvdata;
+ int ptr, ret, state;
+
+ drvdata = kzalloc(sizeof(struct gpio_regulator_data), GFP_KERNEL);
+ if (drvdata == NULL) {
+ dev_err(&pdev->dev, "Failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
+ if (drvdata->desc.name == NULL) {
+ dev_err(&pdev->dev, "Failed to allocate supply name\n");
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ drvdata->gpios = kmemdup(config->gpios,
+ config->nr_gpios * sizeof(struct gpio),
+ GFP_KERNEL);
+ if (drvdata->gpios == NULL) {
+ dev_err(&pdev->dev, "Failed to allocate gpio data\n");
+ ret = -ENOMEM;
+ goto err_name;
+ }
+
+ drvdata->states = kmemdup(config->states,
+ config->nr_states *
+ sizeof(struct gpio_regulator_state),
+ GFP_KERNEL);
+ if (drvdata->states == NULL) {
+ dev_err(&pdev->dev, "Failed to allocate state data\n");
+ ret = -ENOMEM;
+ goto err_memgpio;
+ }
+ drvdata->nr_states = config->nr_states;
+
+ drvdata->desc.owner = THIS_MODULE;
+
+ /* handle regulator type*/
+ switch (config->type) {
+ case REGULATOR_VOLTAGE:
+ drvdata->desc.type = REGULATOR_VOLTAGE;
+ drvdata->desc.ops = &gpio_regulator_voltage_ops;
+ drvdata->desc.n_voltages = config->nr_states;
+ break;
+ case REGULATOR_CURRENT:
+ drvdata->desc.type = REGULATOR_CURRENT;
+ drvdata->desc.ops = &gpio_regulator_current_ops;
+ break;
+ default:
+ dev_err(&pdev->dev, "No regulator type set\n");
+ ret = -EINVAL;
+ goto err_memgpio;
+ break;
+ }
+
+ drvdata->enable_gpio = config->enable_gpio;
+ drvdata->startup_delay = config->startup_delay;
+
+ if (gpio_is_valid(config->enable_gpio)) {
+ drvdata->enable_high = config->enable_high;
+
+ ret = gpio_request(config->enable_gpio, config->supply_name);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Could not obtain regulator enable GPIO %d: %d\n",
+ config->enable_gpio, ret);
+ goto err_memstate;
+ }
+
+ /* set output direction without changing state
+ * to prevent glitch
+ */
+ if (config->enabled_at_boot) {
+ drvdata->is_enabled = true;
+ ret = gpio_direction_output(config->enable_gpio,
+ config->enable_high);
+ } else {
+ drvdata->is_enabled = false;
+ ret = gpio_direction_output(config->enable_gpio,
+ !config->enable_high);
+ }
+
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Could not configure regulator enable GPIO %d direction: %d\n",
+ config->enable_gpio, ret);
+ goto err_enablegpio;
+ }
+ } else {
+ /* Regulator without GPIO control is considered
+ * always enabled
+ */
+ drvdata->is_enabled = true;
+ }
+
+ drvdata->nr_gpios = config->nr_gpios;
+ ret = gpio_request_array(drvdata->gpios, drvdata->nr_gpios);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Could not obtain regulator setting GPIOs: %d\n", ret);
+ goto err_enablegpio;
+ }
+
+ /* build initial state from gpio init data. */
+ state = 0;
+ for (ptr = 0; ptr < drvdata->nr_gpios; ptr++) {
+ if (config->gpios[ptr].flags & GPIOF_OUT_INIT_HIGH)
+ state |= (1 << ptr);
+ }
+ drvdata->state = state;
+
+ drvdata->dev = regulator_register(&drvdata->desc, &pdev->dev,
+ config->init_data, drvdata);
+ if (IS_ERR(drvdata->dev)) {
+ ret = PTR_ERR(drvdata->dev);
+ dev_err(&pdev->dev, "Failed to register regulator: %d\n", ret);
+ goto err_stategpio;
+ }
+
+ platform_set_drvdata(pdev, drvdata);
+
+ return 0;
+
+err_stategpio:
+ gpio_free_array(drvdata->gpios, drvdata->nr_gpios);
+err_enablegpio:
+ if (gpio_is_valid(config->enable_gpio))
+ gpio_free(config->enable_gpio);
+err_memstate:
+ kfree(drvdata->states);
+err_memgpio:
+ kfree(drvdata->gpios);
+err_name:
+ kfree(drvdata->desc.name);
+err:
+ kfree(drvdata);
+ return ret;
+}
+
+static int __devexit gpio_regulator_remove(struct platform_device *pdev)
+{
+ struct gpio_regulator_data *drvdata = platform_get_drvdata(pdev);
+
+ regulator_unregister(drvdata->dev);
+
+ gpio_free_array(drvdata->gpios, drvdata->nr_gpios);
+
+ kfree(drvdata->states);
+ kfree(drvdata->gpios);
+
+ if (gpio_is_valid(drvdata->enable_gpio))
+ gpio_free(drvdata->enable_gpio);
+
+ kfree(drvdata->desc.name);
+ kfree(drvdata);
+
+ return 0;
+}
+
+static struct platform_driver gpio_regulator_driver = {
+ .probe = gpio_regulator_probe,
+ .remove = __devexit_p(gpio_regulator_remove),
+ .driver = {
+ .name = "gpio-regulator",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init gpio_regulator_init(void)
+{
+ return platform_driver_register(&gpio_regulator_driver);
+}
+subsys_initcall(gpio_regulator_init);
+
+static void __exit gpio_regulator_exit(void)
+{
+ platform_driver_unregister(&gpio_regulator_driver);
+}
+module_exit(gpio_regulator_exit);
+
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("gpio voltage regulator");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpio-regulator");
diff --git a/include/linux/regulator/gpio-regulator.h b/include/linux/regulator/gpio-regulator.h
new file mode 100644
index 0000000..19fbd26
--- /dev/null
+++ b/include/linux/regulator/gpio-regulator.h
@@ -0,0 +1,87 @@
+/*
+ * gpio-regulator.h
+ *
+ * Copyright 2011 Heiko Stuebner <heiko@sntech.de>
+ *
+ * based on fixed.h
+ *
+ * Copyright 2008 Wolfson Microelectronics PLC.
+ *
+ * Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
+ *
+ * Copyright (c) 2009 Nokia Corporation
+ * Roger Quadros <ext-roger.quadros@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ */
+
+#ifndef __REGULATOR_GPIO_H
+#define __REGULATOR_GPIO_H
+
+struct regulator_init_data;
+
+enum regulator_type;
+
+/**
+ * struct gpio_regulator_state - state description
+ * @value: microvolts or microamps
+ * @gpios: bitfield of gpio target-states for the value
+ *
+ * This structure describes a supported setting of the regulator
+ * and the necessary gpio-state to achieve it.
+ *
+ * The n-th bit in the bitfield describes the state of the n-th GPIO
+ * from the gpios-array defined in gpio_regulator_config below.
+ */
+struct gpio_regulator_state {
+ int value;
+ int gpios;
+};
+
+/**
+ * struct gpio_regulator_config - config structure
+ * @supply_name: Name of the regulator supply
+ * @enable_gpio: GPIO to use for enable control
+ * set to -EINVAL if not used
+ * @enable_high: Polarity of enable GPIO
+ * 1 = Active high, 0 = Active low
+ * @enabled_at_boot: Whether regulator has been enabled at
+ * boot or not. 1 = Yes, 0 = No
+ * This is used to keep the regulator at
+ * the default state
+ * @startup_delay: Start-up time in microseconds
+ * @gpios: Array containing the gpios needed to control
+ * the setting of the regulator
+ * @nr_gpios: Number of gpios
+ * @states: Array of gpio_regulator_state entries describing
+ * the gpio state for specific voltages
+ * @nr_states: Number of states available
+ * @regulator_type: either REGULATOR_CURRENT or REGULATOR_VOLTAGE
+ * @init_data: regulator_init_data
+ *
+ * This structure contains gpio-voltage regulator configuration
+ * information that must be passed by platform code to the
+ * gpio-voltage regulator driver.
+ */
+struct gpio_regulator_config {
+ const char *supply_name;
+
+ int enable_gpio;
+ unsigned enable_high:1;
+ unsigned enabled_at_boot:1;
+ unsigned startup_delay;
+
+ struct gpio *gpios;
+ int nr_gpios;
+
+ struct gpio_regulator_state *states;
+ int nr_states;
+
+ enum regulator_type type;
+ struct regulator_init_data *init_data;
+};
+
+#endif
--
tg: (c6a389f..) topic/drivers/reg-switch (depends on: master)
^ permalink raw reply related
* [PATCH] ARM: mm: Align bank start to MAX_ORDER_NR_PAGES
From: Michael Bohan @ 2011-10-04 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317198748-17705-1-git-send-email-johan.palsson@stericsson.com>
On 9/28/2011 1:32 AM, Johan Palsson wrote:
> The VM subsystem assumes that there are valid memmap entries from
> the bank start aligned to MAX_ORDER_NR_PAGES.
>
> Cc: stable at kernel.org
> Cc: Russell King<rmk+kernel@arm.linux.org.uk>
> Cc: Michael Bohan<mbohan@codeaurora.org>
> Cc: Nicolas Pitre<nico@fluxnic.net>
> Signed-off-by: Johan Palsson<johan.palsson@stericsson.com>
> Signed-off-by: Rabin Vincent<rabin.vincent@stericsson.com>
> Signed-off-by: Linus Walleij<linus.walleij@linaro.org>
> ---
> arch/arm/mm/init.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index cc7e2d8..f8037ba 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -496,6 +496,13 @@ static void __init free_unused_memmap(struct meminfo *mi)
> */
> bank_start = min(bank_start,
> ALIGN(prev_bank_end, PAGES_PER_SECTION));
> +#else
> + /*
> + * Align down here since the VM subsystem insists that the
Can we change this to say 'Round down here' instead of 'Align down
here'? For consistency, we should probably change the comment and code
for the prev_bank_end case below to say 'Round up' and use round_up
instead of ALIGN().
> + * memmap entries are valid from the bank start aligned to
> + * MAX_ORDER_NR_PAGES.
> + */
> + bank_start = round_down(bank_start, MAX_ORDER_NR_PAGES);
> #endif
We ran into this bug on 2.6.38 and I had similar fix. Are you sure this
doesn't apply SPARSEMEM configurations? At first glance, it seems like
there could be an issue there as well.
Thanks,
Mike
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata
From: Ohad Ben-Cohen @ 2011-10-04 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87botwk4gw.fsf@ti.com>
On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman <khilman@ti.com> wrote:
> The approach is OK with me, but I'm a bit torn about whether or not to
> merge this since the need for this should go away when converting to DT.
I guess it will still take some time until our boards are fully
functional with DT, so I think we should regard this as an interim
solution. Without this patch, a huge deal of code consolidation and
generalization is gated (namely - generic iommu and dma api, and
everything that depends on it, e.g. rpmsg/remoteproc).
> Is anyone working on IOMMU DT description?
Unless Benoit is, I'll happily pick this up.
> I guess if I do merge this, we can also clean this up significantly
> after all devices are converted to DT.
Sure.
> Unless it has other dependencies on Benoit's further DT patches, you can
> base this on my for_3.2/omap_device-2 branch which includes Benoit's
> alloc changes.
Ok, thanks a lot !
Ohad.
^ permalink raw reply
* [PATCH 49/55] video: irq: Remove IRQF_DISABLED
From: Florian Tobias Schandinat @ 2011-10-04 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316681962-8217-50-git-send-email-yong.zhang0@gmail.com>
On 09/22/2011 08:59 AM, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Acked-by: David Brown <davidb@codeaurora.org>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/au1200fb.c | 2 +-
> drivers/video/bf54x-lq043fb.c | 2 +-
> drivers/video/bfin-lq035q1-fb.c | 2 +-
> drivers/video/bfin-t350mcqb-fb.c | 2 +-
> drivers/video/bfin_adv7393fb.c | 2 +-
> drivers/video/mb862xx/mb862xxfbdrv.c | 4 ++--
> drivers/video/msm/mddi.c | 2 +-
> drivers/video/msm/mdp.c | 2 +-
> drivers/video/nuc900fb.c | 2 +-
> drivers/video/omap2/displays/panel-taal.c | 2 +-
> drivers/video/ps3fb.c | 2 +-
> drivers/video/pxa3xx-gcu.c | 2 +-
> drivers/video/pxafb.c | 2 +-
> drivers/video/s3c2410fb.c | 2 +-
> drivers/video/sa1100fb.c | 3 +--
> drivers/video/sh_mobile_lcdcfb.c | 2 +-
> drivers/video/tmiofb.c | 2 +-
> drivers/video/vt8500lcdfb.c | 2 +-
> 18 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/au1200fb.c b/drivers/video/au1200fb.c
> index a19a40e..7200559 100644
> --- a/drivers/video/au1200fb.c
> +++ b/drivers/video/au1200fb.c
> @@ -1673,7 +1673,7 @@ static int __devinit au1200fb_drv_probe(struct platform_device *dev)
> /* Now hook interrupt too */
> irq = platform_get_irq(dev, 0);
> ret = request_irq(irq, au1200fb_handle_irq,
> - IRQF_DISABLED | IRQF_SHARED, "lcd", (void *)dev);
> + IRQF_SHARED, "lcd", (void *)dev);
> if (ret) {
> print_err("fail to request interrupt line %d (err: %d)",
> irq, ret);
> diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
> index 2464b91..56720fb 100644
> --- a/drivers/video/bf54x-lq043fb.c
> +++ b/drivers/video/bf54x-lq043fb.c
> @@ -633,7 +633,7 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - if (request_irq(info->irq, bfin_bf54x_irq_error, IRQF_DISABLED,
> + if (request_irq(info->irq, bfin_bf54x_irq_error, 0,
> "PPI ERROR", info) < 0) {
> printk(KERN_ERR DRIVER_NAME
> ": unable to request PPI ERROR IRQ\n");
> diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
> index 23b6c4b..c633068 100644
> --- a/drivers/video/bfin-lq035q1-fb.c
> +++ b/drivers/video/bfin-lq035q1-fb.c
> @@ -695,7 +695,7 @@ static int __devinit bfin_lq035q1_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - ret = request_irq(info->irq, bfin_lq035q1_irq_error, IRQF_DISABLED,
> + ret = request_irq(info->irq, bfin_lq035q1_irq_error, 0,
> DRIVER_NAME" PPI ERROR", info);
> if (ret < 0) {
> dev_err(&pdev->dev, "unable to request PPI ERROR IRQ\n");
> diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
> index d8de29f..d5e1267 100644
> --- a/drivers/video/bfin-t350mcqb-fb.c
> +++ b/drivers/video/bfin-t350mcqb-fb.c
> @@ -529,7 +529,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - ret = request_irq(info->irq, bfin_t350mcqb_irq_error, IRQF_DISABLED,
> + ret = request_irq(info->irq, bfin_t350mcqb_irq_error, 0,
> "PPI ERROR", info);
> if (ret < 0) {
> printk(KERN_ERR DRIVER_NAME
> diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
> index 8486f54..811dd7f 100644
> --- a/drivers/video/bfin_adv7393fb.c
> +++ b/drivers/video/bfin_adv7393fb.c
> @@ -481,7 +481,7 @@ static int __devinit bfin_adv7393_fb_probe(struct i2c_client *client,
> goto out_4;
> }
>
> - if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, IRQF_DISABLED,
> + if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, 0,
> "PPI ERROR", fbdev) < 0) {
> dev_err(&client->dev, "unable to request PPI ERROR IRQ\n");
> ret = -EFAULT;
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 12a634a..11a7a33 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -738,7 +738,7 @@ static int __devinit of_platform_mb862xx_probe(struct platform_device *ofdev)
> if (mb862xx_gdc_init(par))
> goto io_unmap;
>
> - if (request_irq(par->irq, mb862xx_intr, IRQF_DISABLED,
> + if (request_irq(par->irq, mb862xx_intr, 0,
> DRV_NAME, (void *)par)) {
> dev_err(dev, "Cannot request irq\n");
> goto io_unmap;
> @@ -1074,7 +1074,7 @@ static int __devinit mb862xx_pci_probe(struct pci_dev *pdev,
> if (mb862xx_pci_gdc_init(par))
> goto io_unmap;
>
> - if (request_irq(par->irq, mb862xx_intr, IRQF_DISABLED | IRQF_SHARED,
> + if (request_irq(par->irq, mb862xx_intr, IRQF_SHARED,
> DRV_NAME, (void *)par)) {
> dev_err(dev, "Cannot request irq\n");
> goto io_unmap;
> diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
> index 178b072..4527cbf 100644
> --- a/drivers/video/msm/mddi.c
> +++ b/drivers/video/msm/mddi.c
> @@ -715,7 +715,7 @@ static int __devinit mddi_probe(struct platform_device *pdev)
>
> mddi->int_enable = 0;
> mddi_writel(mddi->int_enable, INTEN);
> - ret = request_irq(mddi->irq, mddi_isr, IRQF_DISABLED, "mddi",
> + ret = request_irq(mddi->irq, mddi_isr, 0, "mddi",
> &mddi->client_data);
> if (ret) {
> printk(KERN_ERR "mddi: failed to request enable irq!\n");
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 2750ed2..cb2ddf1 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -426,7 +426,7 @@ int mdp_probe(struct platform_device *pdev)
> goto error_get_clk;
> }
>
> - ret = request_irq(mdp->irq, mdp_isr, IRQF_DISABLED, "msm_mdp", mdp);
> + ret = request_irq(mdp->irq, mdp_isr, 0, "msm_mdp", mdp);
> if (ret)
> goto error_request_irq;
> disable_irq(mdp->irq);
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 37dd850..d1fbbd8 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -587,7 +587,7 @@ static int __devinit nuc900fb_probe(struct platform_device *pdev)
> fbinfo->flags = FBINFO_FLAG_DEFAULT;
> fbinfo->pseudo_palette = &fbi->pseudo_pal;
>
> - ret = request_irq(irq, nuc900fb_irqhandler, IRQF_DISABLED,
> + ret = request_irq(irq, nuc900fb_irqhandler, 0,
> pdev->name, fbinfo);
> if (ret) {
> dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
> diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
> index 7f91002..80c3f6a 100644
> --- a/drivers/video/omap2/displays/panel-taal.c
> +++ b/drivers/video/omap2/displays/panel-taal.c
> @@ -1034,7 +1034,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
> gpio_direction_input(gpio);
>
> r = request_irq(gpio_to_irq(gpio), taal_te_isr,
> - IRQF_DISABLED | IRQF_TRIGGER_RISING,
> + IRQF_TRIGGER_RISING,
> "taal vsync", dssdev);
>
> if (r) {
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index 65560a1..213fbbc 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -1082,7 +1082,7 @@ static int __devinit ps3fb_probe(struct ps3_system_bus_device *dev)
> }
>
> retval = request_irq(ps3fb.irq_no, ps3fb_vsync_interrupt,
> - IRQF_DISABLED, DEVICE_NAME, &dev->core);
> + 0, DEVICE_NAME, &dev->core);
> if (retval) {
> dev_err(&dev->core, "%s: request_irq failed %d\n", __func__,
> retval);
> diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
> index d8de557..1ed8b36 100644
> --- a/drivers/video/pxa3xx-gcu.c
> +++ b/drivers/video/pxa3xx-gcu.c
> @@ -676,7 +676,7 @@ pxa3xx_gcu_probe(struct platform_device *dev)
> }
>
> ret = request_irq(irq, pxa3xx_gcu_handle_irq,
> - IRQF_DISABLED, DRV_NAME, priv);
> + 0, DRV_NAME, priv);
> if (ret) {
> dev_err(&dev->dev, "request_irq failed\n");
> ret = -EBUSY;
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 0f4e8c9..e89778f 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -2191,7 +2191,7 @@ static int __devinit pxafb_probe(struct platform_device *dev)
> goto failed_free_mem;
> }
>
> - ret = request_irq(irq, pxafb_handle_irq, IRQF_DISABLED, "LCD", fbi);
> + ret = request_irq(irq, pxafb_handle_irq, 0, "LCD", fbi);
> if (ret) {
> dev_err(&dev->dev, "request_irq failed: %d\n", ret);
> ret = -EBUSY;
> diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
> index 798144a..ee4c0df 100644
> --- a/drivers/video/s3c2410fb.c
> +++ b/drivers/video/s3c2410fb.c
> @@ -910,7 +910,7 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
> for (i = 0; i < 256; i++)
> info->palette_buffer[i] = PALETTE_BUFF_CLEAR;
>
> - ret = request_irq(irq, s3c2410fb_irq, IRQF_DISABLED, pdev->name, info);
> + ret = request_irq(irq, s3c2410fb_irq, 0, pdev->name, info);
> if (ret) {
> dev_err(&pdev->dev, "cannot get irq %d - err %d\n", irq, ret);
> ret = -EBUSY;
> diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
> index e8b76d6..98d55d0 100644
> --- a/drivers/video/sa1100fb.c
> +++ b/drivers/video/sa1100fb.c
> @@ -1457,8 +1457,7 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
> if (ret)
> goto failed;
>
> - ret = request_irq(irq, sa1100fb_handle_irq, IRQF_DISABLED,
> - "LCD", fbi);
> + ret = request_irq(irq, sa1100fb_handle_irq, 0, "LCD", fbi);
> if (ret) {
> printk(KERN_ERR "sa1100fb: request_irq failed: %d\n", ret);
> goto failed;
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 4636f9d..facffc2 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1577,7 +1577,7 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, priv);
>
> - error = request_irq(i, sh_mobile_lcdc_irq, IRQF_DISABLED,
> + error = request_irq(i, sh_mobile_lcdc_irq, 0,
> dev_name(&pdev->dev), priv);
> if (error) {
> dev_err(&pdev->dev, "unable to request irq\n");
> diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
> index cd1c4dc..8e4a446 100644
> --- a/drivers/video/tmiofb.c
> +++ b/drivers/video/tmiofb.c
> @@ -744,7 +744,7 @@ static int __devinit tmiofb_probe(struct platform_device *dev)
> goto err_ioremap_vram;
> }
>
> - retval = request_irq(irq, &tmiofb_irq, IRQF_DISABLED,
> + retval = request_irq(irq, &tmiofb_irq, 0,
> dev_name(&dev->dev), info);
>
> if (retval)
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index c13c246..777c21d 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -355,7 +355,7 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
> goto failed_free_palette;
> }
>
> - ret = request_irq(irq, vt8500lcd_handle_irq, IRQF_DISABLED, "LCD", fbi);
> + ret = request_irq(irq, vt8500lcd_handle_irq, 0, "LCD", fbi);
> if (ret) {
> dev_err(&pdev->dev, "request_irq failed: %d\n", ret);
> ret = -EBUSY;
^ permalink raw reply
* [PATCH] picoxcell: add a definition of VMALLOC_END
From: Jamie Iles @ 2011-10-04 20:24 UTC (permalink / raw)
To: linux-arm-kernel
Nicolas Pitre's vmalloc cleanup series didn't get merged in this cycle
so picoxcell is missing a VMALLOC_END definition.
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
arch/arm/mach-picoxcell/include/mach/vmalloc.h | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-picoxcell/include/mach/vmalloc.h
diff --git a/arch/arm/mach-picoxcell/include/mach/vmalloc.h b/arch/arm/mach-picoxcell/include/mach/vmalloc.h
new file mode 100644
index 0000000..0a4bb0e
--- /dev/null
+++ b/arch/arm/mach-picoxcell/include/mach/vmalloc.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (c) 2011 Picochip Ltd., Jamie Iles
+ *
+ * This file contains the hardware definitions of the picoXcell SoC devices.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define VMALLOC_END 0xfe000000UL
--
1.7.4.1
^ permalink raw reply related
* [PATCH] picoxcell: add a definition of VMALLOC_END
From: Jamie Iles @ 2011-10-04 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317759855-21281-1-git-send-email-jamie@jamieiles.com>
On Tue, Oct 04, 2011 at 09:24:15PM +0100, Jamie Iles wrote:
> Nicolas Pitre's vmalloc cleanup series didn't get merged in this cycle
> so picoxcell is missing a VMALLOC_END definition.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Oops. Wrong patch, should have been this one.
8<----
From: Jamie Iles <jamie@jamieiles.com>
Subject: [PATCH] picoxcell: add a definition of VMALLOC_END
Nicolas Pitre's vmalloc cleanup series didn't get merged in this cycle
so picoxcell is missing a VMALLOC_END definition.
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
arch/arm/mach-picoxcell/include/mach/vmalloc.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-picoxcell/include/mach/vmalloc.h
diff --git a/arch/arm/mach-picoxcell/include/mach/vmalloc.h b/arch/arm/mach-picoxcell/include/mach/vmalloc.h
new file mode 100644
index 0000000..0216cc4
--- /dev/null
+++ b/arch/arm/mach-picoxcell/include/mach/vmalloc.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2011 Picochip Ltd., Jamie Iles
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define VMALLOC_END 0xfe000000UL
--
1.7.4.1
^ permalink raw reply related
* [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata
From: Kevin Hilman @ 2011-10-04 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbYaEPBUz_J11+f+W+G9uUG3E6aQ-5=X9bj2nRhij-w-Sw@mail.gmail.com>
Ohad Ben-Cohen <ohad@wizery.com> writes:
> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman <khilman@ti.com> wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.
tag. you're it.
>> I guess if I do merge this, we can also clean this up significantly
>> after all devices are converted to DT.
>
> Sure.
OK, as long as I have some confidence that this is going in the right
direction (and having you on the job is a good sign!) I'm willing to
merge something like this as an interim solution.
Kevin
>> Unless it has other dependencies on Benoit's further DT patches, you can
>> base this on my for_3.2/omap_device-2 branch which includes Benoit's
>> alloc changes.
>
> Ok, thanks a lot !
> Ohad.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Grant Likely @ 2011-10-04 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKnu2MpQ8Wvd4TF8Ge=o8ACyEoaEY8TcvOSdT1w6zfYiSKFUiw@mail.gmail.com>
On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
> 2011/9/30 Grant Likely <grant.likely@secretlab.ca>:
>
> >?I'm not convinced that the sysfs approach is
> > actually the right interface here (I'm certainly not a fan of the gpio
> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
> > userspace i/f is hammered out.
>
> Actually, thinking about it I cannot see what would be wrong
> with /dev/gpio0 & friends in the first place.
>
> Using sysfs as swiss army knife for custom I/O does not
> seem like it would be long-term viable so thanks for this
> observation, and I think we need /dev/gpio* put on some
> mental roadmap somewhere.
Agreed. I don't want to be in the situation we are now with GPIO,
where every time I look at the sysfs interface I shudder.
g.
^ permalink raw reply
* [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
From: Kevin Hilman @ 2011-10-04 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-2-git-send-email-vishwanath.bs@ti.com>
Hi Vishwa,
Vishwanath BS <vishwanath.bs@ti.com> writes:
> As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for enabling IO Daisy
> chain is "The I/O wake-up scheme is enabled by triggering the I/O daisy chain
> control (Wu clock) by programming a dedicated register
> (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software must wait for
> the I/O daisy chain to complete before it transitions the PER domain to a
> nonfunctional state. This is done by polling a dedicated status bit in the PRCM
> module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared by
> software when the bit is read to 1".
>
> The original code was polling on a wrong register which is fixed in this patch.
> Also omap3_enable_io_chain is made non static as it's going to be used in
> subsequent patches.
>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
A fix for this was posted[1] by Mohan V (added to Cc) back in June. It
recieved a few minor comments but an updated version was never posted.
Maybe you can ping Mohan or update that version fixing the comments
mentioned in that thread.
Thanks,
Kevin
[1] http://marc.info/?l=linux-omap&w=2&r=1&s=%27Mohan+V%27&q=b
^ permalink raw reply
* [PATCH v2 6/7] clk: Add initial WM831x clock driver
From: Mark Brown @ 2011-10-04 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004181818.GD2870@ponder.secretlab.ca>
On Tue, Oct 04, 2011 at 12:18:18PM -0600, Grant Likely wrote:
> On Mon, Sep 26, 2011 at 10:38:58AM +0100, Mark Brown wrote:
> > No, that's not helpful. The issue isn't the device probe code itself,
> > the issue is things like module unload not doing what they're supposed
> > to do and leaving the device lying around or something - there's rather
> > more going on than just the plain API call.
> Then lets fix the core code. I see this pattern show up again and
> again of extra boilerplate going around
> platform_driver_{register,unregister}(). That says to me that there
> either needs to be a new helper, or the core code needs to be made
> more verbose.
I'd go with the latter, it's pretty much the approach the subsystems I
help maintain have been taking. In fast paths it's a bit different but
in slow paths it tends to be helpful to know why things just fell over.
> In fact, I've been considering adding a macro for
> {platform,i2c,spi,...}_drivers that does all the module boilerplate
> for the common case of only registering a driver at init time.
> Something like:
> #define module_platform_driver(__driver) \
> int __driver##_init(void) \
> { \
> return platform_driver_register(&(__driver)); \
> } \
> module_init(__driver##_init); \
> void ##__driver##_exit(void) \
> { \
> platform_driver_unregister(&(__driver)); \
> } \
> module_exit(##__driver##_exit);
> It's not a lot of code, but I dislike how much boilerplate every
> single driver has to use if it doesn't do anything special.
Yeah, this sort of stuff would be helpful - there's quite a bit of
boilerplate you end up having to write to get drivers going.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox