* [PATCH] omap4: usb: explicitly configure MUSB pads
From: Felipe Balbi @ 2011-02-16 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297851135-25952-1-git-send-email-gadiyar@ti.com>
On Wed, Feb 16, 2011 at 03:42:15PM +0530, Anand Gadiyar wrote:
> Use the mux framework APIs to explicitly configure
> the MUSB pads. The MUSB controller in OMAP4 can use
> either the old ULPI interface, or the new internal PHY.
> Configure the pads accordingly.
>
> Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
applied to musb-next, will send a pull request for Tony by friday.
--
balbi
^ permalink raw reply
* [PATCH] ARM: errata: pl310 cache sync operation may be faulty
From: Catalin Marinas @ 2011-02-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216060351.GB16604@bnru02>
On 16 February 2011 06:03, Srinidhi KASAGAR
<srinidhi.kasagar@stericsson.com> wrote:
> On Tue, Feb 15, 2011 at 12:34:22 +0100, Russell King - ARM Linux wrote:
>> On Tue, Feb 15, 2011 at 04:48:03PM +0530, srinidhi kasagar wrote:
>> > +#ifdef ARM_ERRATA_753970
>> > +#define L2X0_DUMMY_REG ?0x740
>> > + ? /* write to an unmmapped register */
>> > + ? writel_relaxed(0, base + L2X0_DUMMY_REG);
>> > + ? cache_wait(base + L2X0_CACHE_SYNC, 1);
>> > +#else
>> > ? ? writel_relaxed(0, base + L2X0_CACHE_SYNC);
>> > ? ? cache_wait(base + L2X0_CACHE_SYNC, 1);
>> > +#endif
>>
>> So why wrap cache_wait() up in that horrible ifdef as well - and why not
>> put the dummy register definition along side the other register definitions?
[...]
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -49,8 +49,14 @@ static inline void cache_wait(void __iomem *reg, unsigned long mask)
> ?static inline void cache_sync(void)
> ?{
> ? ? ? ?void __iomem *base = l2x0_base;
> +
> +#ifdef CONFIG_ARM_ERRATA_753970
> + ? ? ? /* write to an unmmapped register */
> + ? ? ? writel_relaxed(0, base + L2X0_DUMMY_REG);
> +#else
> ? ? ? ?writel_relaxed(0, base + L2X0_CACHE_SYNC);
> ? ? ? ?cache_wait(base + L2X0_CACHE_SYNC, 1);
> +#endif
> ?}
You could still leave cache_wait() after #endif, even though it is a
no-op. I think it is clearer that the erratum workaround only targets
the sync.
--
Catalin
^ permalink raw reply
* [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler
From: Rabin Vincent @ 2011-02-16 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <-6723806473392693428@unknownmsgid>
On Fri, Feb 11, 2011 at 22:03, Will Deacon <will.deacon@arm.com> wrote:
>> Allow a platform-specific IRQ handler to be specified via platform data. ?This
>> will be used to implement the single-irq workaround for the DB8500.
>>
>> Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
>> ---
>> ?arch/arm/include/asm/pmu.h ? | ? 14 ++++++++++++++
>> ?arch/arm/kernel/perf_event.c | ? 17 ++++++++++++++++-
>> ?2 files changed, 30 insertions(+), 1 deletions(-)
>
> If you're happy with this as a workaround for your platform, then
> it looks alright to me.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks.
>
> One thing you could try is using the GIC patch I posted the other day:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041496.html
>
> If you then do:
>
> ? ?ARM: gic: allow per-cpu SPIs to be affine to multiple CPUs
>
> ? ?The concept of a per-cpu SPI is somewhat a contradiction, but can occur in
> ? ?systems where SPIs from different CPUs are ORd together into a single line.
>
> ? ?An example of this is the PMU interrupt on the u8500 platform.
>
> ? ?This patch allows SPIs with the IRQF_PERCPU flag to be affine to multiple
> ? ?CPUs in a CPU mask. This, of course, assumes that the driver knows what it
> ? ?is doing and can handle such a configuration.
>
> ? ?Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 9def30b..512f55f 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -145,7 +145,7 @@ gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)
> ?{
> ? ? ? ?void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3);
> ? ? ? ?unsigned int shift = (d->irq % 4) * 8;
> - ? ? ? unsigned int cpu = cpumask_first(mask_val);
> + ? ? ? unsigned int cpu_map, cpu = cpumask_first(mask_val);
> ? ? ? ?u32 val;
> ? ? ? ?struct irq_desc *desc;
>
> @@ -155,9 +155,19 @@ gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)
> ? ? ? ? ? ? ? ?spin_unlock(&irq_controller_lock);
> ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ?}
> +
> ? ? ? ?d->node = cpu;
> +
> + ? ? ? if (CHECK_IRQ_PER_CPU(desc->status)) {
> + ? ? ? ? ? ? ? cpu_map = 0;
> + ? ? ? ? ? ? ? for_each_cpu(cpu, mask_val)
> + ? ? ? ? ? ? ? ? ? ? ? cpu_map |= 1 << (cpu + shift);
> + ? ? ? } else {
> + ? ? ? ? ? ? ? cpu_map = 1 << (cpu + shift);
> + ? ? ? }
> +
> ? ? ? ?val = readl(reg) & ~(0xff << shift);
> - ? ? ? val |= 1 << (cpu + shift);
> + ? ? ? val |= cpu_map;
> ? ? ? ?writel(val, reg);
> ? ? ? ?spin_unlock(&irq_controller_lock);
>
>
> You'll be able to target the PMU IRQ to both CPUs and avoid the need for
> ping-ponging the affinity. This is a bit weird though as usually you'd have
> a PPI for a percpu interrupt so this might be better off staying inside
> platform code and leaving the GIC code alone. I also think this approach
> is more invasive from the perf point of view.
>
> Unless this approach gives markedly better profiling results than your
> proposal, I think we should go with what you've got.
I gave this a try, along with the modifications to enable IRQ_PER_CPU
and have the pmu code use the appropriate flags and set the affinity.
Didn't work though; it always ends up triggering the spurious IRQ check.
^ permalink raw reply
* [PATCH 00/11] OMAP2+: clock: add clockfw autoidle for iclks, OMAP2xxx
From: Rajendra Nayak @ 2011-02-16 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216065030.22089.61217.stgit@twilight.localdomain>
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org
[mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf
> Of Paul Walmsley
> Sent: Wednesday, February 16, 2011 12:23 PM
> To: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: [PATCH 00/11] OMAP2+: clock: add clockfw autoidle for iclks,
OMAP2xxx
>
> Hello,
>
> This patch series adds clock framework-controlled autoidle support for
> the OMAP2xxx DPLL, APLLs, and OMAP2/3 interface clocks. The old
> direct register writes in the PM code to enable clock autoidle have been
> removed.
>
> This series also ensures that all clock autoidle is disabled during
> boot and only re-enabled if CONFIG_PM is enabled.
>
> The series applies on the 'clk_autoidle_a_2.6.39' branch of
> git://git.pwsan.com/linux-2.6.
>
> Boot-tested on N800, and dynamic idle-tested on OMAP3430 Beagleboard.
> Compile-tested with omap1_defconfig, omap2plus_defconfig, a 5912
> OSK-only config, an N8x0-only config, an OMAP3-only config, and an
OMAP4-only
> config.
Boot-tested on 3430sdp/4430sdp, with CONFIG_PM and with !CONFIG_PM.
suspend-offmode tested on 3430sdp and suspend-retmode on 4430sdp (with
some out-of-tree patches)
Dynamic idle testing on 3430sdp showed me some very jerky debug console
the
moment a 'echo 1 > /debug/pm_debug/sleep_while_idle' is done.
This however seems to be the case even on 2.6.38-rc4 and not related to
the
current patch series. Will debug further, but seems to some 3430sdp
specific
issue, since you did not see it on Beagleboard and seems it is not seen on
OMAP3
zoom's either.
Just out of curiosity, what dynamic-idle state where you able to achieve
on
Beagle? And what was the debug console timeout that you configured?
Regards,
Rajendra
>
>
> - Paul
>
> ---
>
> clk_autoidle_b_2.6.39
> text data bss dec hex filename
> 5530703 330544 5594520 11455767 aecd17
vmlinux.omap2plus_defconfig.orig
> 5531167 330544 5594520 11456231 aecee7
vmlinux.omap2plus_defconfig.patched
>
> Paul Walmsley (11):
> OMAP2+: clock: disable autoidle on all clocks during clock init
> OMAP2: clock: add DPLL autoidle support
> OMAP2xxx: clock: add clockfw autoidle support for APLLs
> OMAP2+: clock: comment that osc_ck/osc_sys_ck should use clockfw
autoidle control
> OMAP2+: clock: add interface clock type code with autoidle support
> OMAP2420: clock: add sdrc_ick
> OMAP2420: clock: use autoidle clkops for all autoidle-controllable
interface clocks
> OMAP2430/3xxx: clock: add modem clock autoidle support
> OMAP2430: clock: use autoidle clkops for all autoidle-controllable
interface clocks
> OMAP3: clock: use autoidle clkops for all autoidle-controllable
interface clocks
> OMAP2/3: PM: remove manual CM_AUTOIDLE bit setting in
mach-omap2/pm*xx.c
>
>
> arch/arm/mach-omap2/Makefile | 7 +
> arch/arm/mach-omap2/clkt2xxx_apll.c | 24 +++++
> arch/arm/mach-omap2/clkt2xxx_dpll.c | 63 +++++++++++++
> arch/arm/mach-omap2/clkt2xxx_osc.c | 14 +++
> arch/arm/mach-omap2/clkt_iclk.c | 82 +++++++++++++++++
> arch/arm/mach-omap2/clock.h | 11 ++
> arch/arm/mach-omap2/clock2420_data.c | 130
+++++++++++++++++-----------
> arch/arm/mach-omap2/clock2430_data.c | 130
++++++++++++++++------------
> arch/arm/mach-omap2/clock34xx.c | 29 ++++++
> arch/arm/mach-omap2/clock34xx.h | 5 +
> arch/arm/mach-omap2/clock3517.c | 4 +
> arch/arm/mach-omap2/clock3xxx.c | 3 -
> arch/arm/mach-omap2/clock3xxx_data.c | 155
+++++++++++++++++----------------
> arch/arm/mach-omap2/clock44xx_data.c | 3 +
> arch/arm/mach-omap2/cm-regbits-24xx.h | 3 +
> arch/arm/mach-omap2/cm2xxx_3xxx.c | 69 +++++++++++++++
> arch/arm/mach-omap2/cm2xxx_3xxx.h | 8 ++
> arch/arm/mach-omap2/pm24xx.c | 69 +--------------
> arch/arm/mach-omap2/pm34xx.c | 105 ----------------------
> 19 files changed, 557 insertions(+), 357 deletions(-)
> create mode 100644 arch/arm/mach-omap2/clkt2xxx_dpll.c
> create mode 100644 arch/arm/mach-omap2/clkt_iclk.c
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] omap4: 4430sdp: drop ehci support
From: Anand Gadiyar @ 2011-02-16 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Most revisions of the OMAP4 Blaze/SDP platform do not have
the EHCI signals routed by default. The pads are routed
for the alternate HSI functionality instead, and explicit
board modifications are needed to route the signals to
the USB PHY on the board.
Also, turning on the PHY connected to the EHCI port causes
a board reboot during bootup due to an unintended short
on the rails - this affects many initial revisions of the
board, and needs a minor board mod to fix (or as a
workaround, one should not attempt to power on the
USB PHY).
Given that these boards need explicit board mods to even
get EHCI working (separate from the accidental short above),
we should not attempt to enable EHCI by default.
So drop the EHCI support from the board files for the
Blaze/SDP platforms.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 20 --------------------
1 file changed, 20 deletions(-)
Index: linux-omap-usb/arch/arm/mach-omap2/board-4430sdp.c
===================================================================
--- linux-omap-usb.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-omap-usb/arch/arm/mach-omap2/board-4430sdp.c
@@ -44,7 +44,6 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON 48
#define ETH_KS8851_QUART 138
-#define OMAP4SDP_MDM_PWR_EN_GPIO 157
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
@@ -251,16 +250,6 @@ static void __init omap_4430sdp_init_irq
gic_init_irq();
}
-static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
- .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .phy_reset = false,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL,
-};
-
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
.mode = MUSB_OTG,
@@ -576,14 +564,6 @@ static void __init omap_4430sdp_init(voi
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* Power on the ULPI PHY */
- status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
- if (status)
- pr_err("%s: Could not get USBB1 PHY GPIO\n", __func__);
- else
- gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
-
- usb_ehci_init(&ehci_pdata);
usb_musb_init(&musb_board_data);
status = omap_ethernet_init();
^ permalink raw reply
* [PATCH 2/2] omap4: 4430sdp: mux GPIO_157 to safe mode
From: Anand Gadiyar @ 2011-02-16 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297855040-1337-1-git-send-email-gadiyar@ti.com>
Commit 7d4ca85a5 (omap4: Fix ULPI PHY init for ES1.0 SDP)
changed the mux mode of the pad for GPIO_157 to HSI_MODE
by accident - the original intent was to mux it properly
to solve a board reboot problem.
The board reboot is caused by a bug on many revs of the
board that causes an accidental short circuilt when this
pad is driven high. To ensure this never happens (even
with misbehaving bootloaders), mux the pad to safe mode instead.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
Index: linux-omap-usb/arch/arm/mach-omap2/board-4430sdp.c
===================================================================
--- linux-omap-usb.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-omap-usb/arch/arm/mach-omap2/board-4430sdp.c
@@ -543,7 +543,15 @@ static void __init omap_sfh7741prox_init
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
- OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /*
+ * USBB2_ULPITLL_CLK/GPIO_157 controls the circuitry
+ * that turns on the PHY connected to the EHCI port.
+ * several revisions of the Blaze are affected by
+ * an accidental short-circuit that causes a reboot
+ * if this pad is driven high. So, explicitly configure
+ * the pad in safe mode to ensure this never happens
+ */
+ OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE7),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
^ permalink raw reply
* [PATCH 1/2] omap4: 4430sdp: drop ehci support
From: Felipe Balbi @ 2011-02-16 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297855040-1337-1-git-send-email-gadiyar@ti.com>
On Wed, Feb 16, 2011 at 04:47:19PM +0530, Anand Gadiyar wrote:
> Most revisions of the OMAP4 Blaze/SDP platform do not have
> the EHCI signals routed by default. The pads are routed
> for the alternate HSI functionality instead, and explicit
> board modifications are needed to route the signals to
> the USB PHY on the board.
>
> Also, turning on the PHY connected to the EHCI port causes
> a board reboot during bootup due to an unintended short
> on the rails - this affects many initial revisions of the
> board, and needs a minor board mod to fix (or as a
> workaround, one should not attempt to power on the
> USB PHY).
>
> Given that these boards need explicit board mods to even
> get EHCI working (separate from the accidental short above),
> we should not attempt to enable EHCI by default.
>
> So drop the EHCI support from the board files for the
> Blaze/SDP platforms.
>
> Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> Cc: Keshava Munegowda <keshava_mgowda@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
Tony, if you want to queue this one directly, here's my:
Acked-by: Felipe Balbi <balbi@ti.com>
if you wish, I can send you a pull request as well. I already have
another patch for you anyway.
--
balbi
^ permalink raw reply
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Rabin Vincent @ 2011-02-16 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297697188-5206-1-git-send-email-will.deacon@arm.com>
On Mon, Feb 14, 2011 at 20:56, Will Deacon <will.deacon@arm.com> wrote:
> Currently, the gic uses handle_level_irq for handling SPIs (Shared
> Peripheral Interrupts), requiring active interrupts to be masked at
> the distributor level during IRQ handling.
>
> On a virtualised system, only the CPU interfaces are virtualised in
> hardware. Accesses to the distributor must be trapped by the hypervisor,
> adding latency to the critical interrupt path in Linux.
>
> This patch modifies the GIC code to use handle_fasteoi_irq for handling
> interrupts, which only requires us to signal EOI to the CPU interface
> when handling is complete. Cascaded IRQ handling is also updated so that
> EOI is signalled after handling.
Several of the platforms using the GIC also have GPIO code which uses
set_irq_chained_handler(). I think you will have to modify all of
these to call irq_eoi() appropriately and not the other functions.
Some of these will also likely be used with other interrupt handlers
than the GIC, though.
^ permalink raw reply
* [PATCH 0/4] ARM: add support for hw-breakpoints [v4]
From: karthikeyan.s @ 2011-02-16 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <-857909442890734186@unknownmsgid>
There seems to be a bug in the gdb patch... There should probably be a
separate loop for wpts.
for (i = 0; i < info->bp_count; i++)
> {
> if (arm_hwbp_control_is_enabled (p->bpts[i].control))
> arm_linux_insert_hw_breakpoint1 (p->bpts + i, tid, 0);
> if (arm_hwbp_control_is_enabled (p->wpts[i].control))
> arm_linux_insert_hw_breakpoint1 (p->wpts + i, tid, 1);
> }
-Karthik
On Wed, Jul 7, 2010 at 10:02 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hello,
>
> > This is version 4 of the patches originally posted at:
> >
> > v1.)
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-February/009084.html
> > v2.)
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011170.html
> > v3.)
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017680.html
> >
> > Changes from v3 include:
> > - Based on 2.6.35-rc3
> > - Support for unaligned addresses
> > - Numerous bug fixes
> > - Tested with GDB, for which the testsuite passes
> >
> > GDB patches have been posted here:
> >
> > http://sourceware.org/ml/gdb-patches/2010-07/msg00110.html
> >
> > I'd like to get these patches applied now that I'm confident that
> > they function correctly, so please give them a go.
> >
> > Cc: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: S. Karthikeyan <informkarthik@gmail.com>
> > Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
> >
>
> I accidentally passed suppress-cc=all to git send-email, so this
> is a pointer for the people I meant to CC. If you want to view
> the patchset it's archived at:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-July/019882.html
>
> Sorry about that,
>
> Will
>
>
>
--
---
S. Karthikeyan | +919980814745
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110216/8ec27222/attachment-0001.html>
^ permalink raw reply
* [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Jarkko Nikula @ 2011-02-16 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=3PCBOvFtd1T-=tDjXcs+_0opKqxVps+StCZqf@mail.gmail.com>
On Wed, 16 Feb 2011 11:22:09 +0530
"Gulati, Shweta" <shweta.gulati@ti.com> wrote:
> On Tue, Feb 15, 2011 at 8:59 PM, Jarkko Nikula <jhnikula@gmail.com> wrote:
> > Probably discussed earlier but would it make more sense to have flag in
> > struct twl4030_platform_data and to do registers writes in twl-core?
> > Looks suspicious to have i2c_writes under arch/arm/.
> twl_i2c_read/write APIs are used from arch/arm in many board files,
> so I think it should not cause any issue.
Not good either e.g. in modularization point of view. I was thinking
something like below. I played safe and let the SR to be enabled only if
the twl4030_power_data.sr_enable is set. I read that Kevin had problems
earlier with 2430SDP if SR was enabled.
Note proof of concept patch only. I omitted the comments and don't do
explicit SR disable and I'd clean up the error paths in twl4030_power_init
a bit before this (e.g. printing error codes). Not sure either is the
twl4030-power.c right place for this or core.
--
Jarkko
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 16422de0..e767b0f 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -92,6 +92,9 @@ static u8 twl4030_start_script_address = 0x2b;
#define OFF_STATE_SHIFT 4
#define OFF_STATE_MASK (0xf << OFF_STATE_SHIFT)
+#define TWL4030_DCDC_GLOBAL_CFG PHY_TO_OFF_PM_RECEIVER(0x61)
+#define SMARTREFLEX_ENABLE BIT(3)
+
static u8 res_config_addrs[] = {
[RES_VAUX1] = 0x17,
[RES_VAUX2] = 0x1b,
@@ -510,6 +513,22 @@ int twl4030_remove_script(u8 flags)
return err;
}
+int __init twl4030_sr_enable(void)
+{
+ u8 temp;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ return ret;
+
+ temp |= SMARTREFLEX_ENABLE;
+
+ return twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+}
+
void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
{
int err = 0;
@@ -549,8 +568,15 @@ void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0,
TWL4030_PM_MASTER_PROTECT_KEY);
- if (err)
+ if (err) {
pr_err("TWL4030 Unable to relock registers\n");
+ return;
+ }
+
+ if (twl4030_scripts->sr_enable)
+ err = twl4030_sr_enable();
+ if (err)
+ pr_err("TWL4030 Unable to set smartreflex. %d\n", err);
return;
unlock:
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 61b9609..1f64e3e 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -630,6 +630,7 @@ struct twl4030_power_data {
struct twl4030_script **scripts;
unsigned num;
struct twl4030_resconfig *resource_config;
+ bool sr_enable; /* Smartreflex enable state */
#define TWL4030_RESCONFIG_UNDEF ((u8)-1)
};
^ permalink raw reply related
* [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Gulati, Shweta @ 2011-02-16 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216134523.ba5d3917.jhnikula@gmail.com>
Jarkko,
On Wed, Feb 16, 2011 at 5:15 PM, Jarkko Nikula <jhnikula@gmail.com> wrote:
> On Wed, 16 Feb 2011 11:22:09 +0530
> "Gulati, Shweta" <shweta.gulati@ti.com> wrote:
>
>> On Tue, Feb 15, 2011 at 8:59 PM, Jarkko Nikula <jhnikula@gmail.com> wrote:
>> > Probably discussed earlier but would it make more sense to have flag in
>> > struct twl4030_platform_data and to do registers writes in twl-core?
>> > Looks suspicious to have i2c_writes under arch/arm/.
>> twl_i2c_read/write APIs are used from arch/arm in many board files,
>> so I think it should not cause any issue.
>
> Not good either e.g. in modularization point of view. I was thinking
> something like below. I played safe and let the SR to be enabled only if
> the twl4030_power_data.sr_enable is set. I read that Kevin had problems
> earlier with 2430SDP if SR was enabled.
>
> Note proof of concept patch only. I omitted the comments and don't do
> explicit SR disable and I'd clean up the error paths in twl4030_power_init
> a bit before this (e.g. printing error codes). Not sure either is the
> twl4030-power.c right place for this or core.
You missed commit log which says that "T2 bit is required to enable I2C_SR
path of voltage control" it is not at all enabling SR, voltage scale
APIs VPforceupdate/ VCbypass
needs this path to be enabled.
And calling APIs twl_i2c_read/write in driver codebase does n't ensure correct
ordering of flag changes and twl_read/write.
> --
> Jarkko
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 16422de0..e767b0f 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -92,6 +92,9 @@ static u8 twl4030_start_script_address = 0x2b;
> ?#define OFF_STATE_SHIFT ? ? ? ? ? ? ? ?4
> ?#define OFF_STATE_MASK ? ? ? ? (0xf << OFF_STATE_SHIFT)
>
> +#define TWL4030_DCDC_GLOBAL_CFG ? ? ? ?PHY_TO_OFF_PM_RECEIVER(0x61)
> +#define SMARTREFLEX_ENABLE ? ? BIT(3)
> +
> ?static u8 res_config_addrs[] = {
> ? ? ? ?[RES_VAUX1] ? ? = 0x17,
> ? ? ? ?[RES_VAUX2] ? ? = 0x1b,
> @@ -510,6 +513,22 @@ int twl4030_remove_script(u8 flags)
> ? ? ? ?return err;
> ?}
>
> +int __init twl4030_sr_enable(void)
> +{
> + ? ? ? u8 temp;
> + ? ? ? int ret;
> +
> + ? ? ? ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &temp,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? TWL4030_DCDC_GLOBAL_CFG);
> + ? ? ? if (ret)
> + ? ? ? ? ? ? ? return ret;
> +
> + ? ? ? temp |= SMARTREFLEX_ENABLE;
> +
> + ? ? ? return twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TWL4030_DCDC_GLOBAL_CFG);
> +}
> +
> ?void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
> ?{
> ? ? ? ?int err = 0;
> @@ -549,8 +568,15 @@ void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
>
> ? ? ? ?err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0,
> ? ? ? ? ? ? ? ? ? ? ? ?TWL4030_PM_MASTER_PROTECT_KEY);
> - ? ? ? if (err)
> + ? ? ? if (err) {
> ? ? ? ? ? ? ? ?pr_err("TWL4030 Unable to relock registers\n");
> + ? ? ? ? ? ? ? return;
> + ? ? ? }
> +
> + ? ? ? if (twl4030_scripts->sr_enable)
> + ? ? ? ? ? ? ? err = twl4030_sr_enable();
> + ? ? ? if (err)
> + ? ? ? ? ? ? ? pr_err("TWL4030 Unable to set smartreflex. %d\n", err);
> ? ? ? ?return;
>
> ?unlock:
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index 61b9609..1f64e3e 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -630,6 +630,7 @@ struct twl4030_power_data {
> ? ? ? ?struct twl4030_script **scripts;
> ? ? ? ?unsigned num;
> ? ? ? ?struct twl4030_resconfig *resource_config;
> + ? ? ? bool sr_enable; /* Smartreflex enable state */
> ?#define TWL4030_RESCONFIG_UNDEF ? ? ? ?((u8)-1)
> ?};
>
>
>
--
Thanks,
Regards,
Shweta
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Eduardo Valentin @ 2011-02-16 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin7vRMreG3hOAk95MYZUCV-Kr6ac7gD7jgvX6Gf@mail.gmail.com>
Hello Linus,
On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
> 2010/5/11 Eduardo Valentin <eduardo.valentin@nokia.com>:
>
> > Here is the version 5 of the change to export OMAP data to userspace
> > (name, revision, id code, production id and die id).
> >
> > Basically, this version is still attempting to create a new file under /proc.
> > It is the /proc/socinfo, which should be used to export bits which are SoC specific
> > (not CPU related, nor machine related).
> >
> > So, differences between previous version are:
> > - merged patch 02/04 with 03/04 to avoid compilation breakages.
> > - simplified the seq_file usage by using the single_open and single_release functions
> > - exported a function to register a seq_operation .show callback
> > - adapted the changes accordingly
> >
> > As usual, comments are welcome.
>
> Eduardo, what has happened to this patchset?
Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>
> Now we need something similar for arch/arm/mach-ux500 and I was sort of
> hoping that this infrastructure would be in place already... wrong I was.
Right.
>
> Do you want help in picking it up and try to polish it up?
Yeah, but it would need a refactoring. IIRC, result of last discussion was that
we should not mess with /proc. So, maybe moving back to something under sysfs.
Perhaps /sys/devices/soc or so?
>
> Yours,
> Linus Walleij
--
Eduardo Valentin
^ permalink raw reply
* [PATCH 0/4] ARM: add support for hw-breakpoints [v4]
From: Will Deacon @ 2011-02-16 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=u-=BkFP7HfsbYUM5_FnVm+5Vj7kfARXPsNf+e@mail.gmail.com>
Hi Karthik,
> There seems to be a bug in the gdb patch... There should probably be a separate loop for wpts.
>
> for (i = 0; i < info->bp_count; i++)
> > {
> > if (arm_hwbp_control_is_enabled (p->bpts[i].control))
> > arm_linux_insert_hw_breakpoint1 (p->bpts + i, tid, 0);
> > if (arm_hwbp_control_is_enabled (p->wpts[i].control))
> > arm_linux_insert_hw_breakpoint1 (p->wpts + i, tid, 1);
> > }
Ulrich Weigand (added to CC) is dealing with the GDB patches, so he
will have more idea about this than me. Last I heard, the testsuite
was passing so I guess this has been fixed if it was a problem.
Cheers,
Will
^ permalink raw reply
* [PATCH] OMAP2+: PM: Warn users of sleep_while_idle if !CONFIG_CPU_IDLE
From: Rajendra Nayak @ 2011-02-16 12:04 UTC (permalink / raw)
To: linux-arm-kernel
This should help users who do a
'echo 1 > /debug/pm_debug/sleep_while_idle' with a
config which has !CONFIG_CPU_IDLE and wonder
why OMAP is'nt sleeping in idle.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/pm-debug.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 125f565..1e722a0 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -569,6 +569,10 @@ static int option_get(void *data, u64 *val)
*val = *option;
+#ifndef CONFIG_CPU_IDLE
+ if (option == &sleep_while_idle)
+ pr_warn("CONFIG_CPU_IDLE is not enabled\n");
+#endif
return 0;
}
@@ -581,6 +585,11 @@ static int option_set(void *data, u64 val)
*option = val;
+#ifndef CONFIG_CPU_IDLE
+ if (option == &sleep_while_idle)
+ pr_warn("CONFIG_CPU_IDLE is not enabled\n");
+#endif
+
if (option == &enable_off_mode) {
if (val)
omap_pm_enable_off_mode();
--
1.7.0.4
^ permalink raw reply related
* [PATCH] spi/pl022: rid dangling labels
From: Grant Likely @ 2011-02-16 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297845626-13332-1-git-send-email-linus.walleij@stericsson.com>
On Wed, Feb 16, 2011 at 09:40:26AM +0100, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> Remove a compilation error regarding unused labels that came about
> when simplifying the DMA code.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied, thanks.
g.
> ---
> drivers/spi/amba-pl022.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/amba-pl022.c b/drivers/spi/amba-pl022.c
> index 4cd05cc..14a451b 100644
> --- a/drivers/spi/amba-pl022.c
> +++ b/drivers/spi/amba-pl022.c
> @@ -1030,8 +1030,6 @@ static int configure_dma(struct pl022 *pl022)
>
> return 0;
>
> -err_submit_tx:
> -err_submit_rx:
> err_txdesc:
> dmaengine_terminate_all(txchan);
> err_rxdesc:
> --
> 1.7.3.2
>
^ permalink raw reply
* [PATCH 0/3] OMAP2+ hwmod fixes
From: Rajendra Nayak @ 2011-02-16 12:11 UTC (permalink / raw)
To: linux-arm-kernel
This series fixes some hwmod api return values
and also adds some state checks.
The hwmod iterator functions are made to
continue and not break if one of the
callback functions ends up with an error.
Series applies on 2.6.38-rc4 and is boot
tested on OMAP3430SDP and OMAP4430SDP
platforms.
Rajendra Nayak (3):
OMAP2+: hwmod: Avoid setup if clock lookup failed
OMAP2+: hwmod: Fix what _init_clock returns
OMAP2+: hwmod: Do not break iterator fn's if one fails
arch/arm/mach-omap2/omap_hwmod.c | 31 +++++++++++++++----------------
1 files changed, 15 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH 1/3] OMAP2+: hwmod: Avoid setup if clock lookup failed
From: Rajendra Nayak @ 2011-02-16 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297858285-7056-1-git-send-email-rnayak@ti.com>
Add a hwmod state check in the _setup function
to avoid setting up hwmods' for which clock
lookup has failed.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e282e35..cd9dcde 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1362,6 +1362,12 @@ static int _setup(struct omap_hwmod *oh, void *data)
int i, r;
u8 postsetup_state;
+ if (oh->_state != _HWMOD_STATE_CLKS_INITED) {
+ WARN(1, "omap_hwmod: %s: _setup failed as one or more"
+ "clock lookups' have failed\n", oh->name);
+ return -EINVAL;
+ }
+
/* Set iclk autoidle mode */
if (oh->slaves_cnt > 0) {
for (i = 0; i < oh->slaves_cnt; i++) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] OMAP2+: hwmod: Fix what _init_clock returns
From: Rajendra Nayak @ 2011-02-16 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297858285-7056-2-git-send-email-rnayak@ti.com>
_init_clock always returns 0 and does
not propogate the error (in case of failure)
back to the caller, causing _init_clocks to
fail silently.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cd9dcde..960461f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -926,7 +926,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data)
if (!ret)
oh->_state = _HWMOD_STATE_CLKS_INITED;
- return 0;
+ return ret;
}
/**
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] OMAP2+: hwmod: Do not break iterator fn's if one fails
From: Rajendra Nayak @ 2011-02-16 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297858285-7056-3-git-send-email-rnayak@ti.com>
The iterator functions used to iterate over all
registered hwmods and all hwmods of a given class
break if one of the iterator functions fail.
Instead iterate over all the functions and return
an ORed return value back to the user.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 23 ++++++++---------------
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 960461f..3cab82e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1568,25 +1568,21 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
*
* Call @fn for each registered omap_hwmod, passing @data to each
* function. @fn must return 0 for success or any other value for
- * failure. If @fn returns non-zero, the iteration across omap_hwmods
- * will stop and the non-zero return value will be passed to the
- * caller of omap_hwmod_for_each(). @fn is called with
+ * failure. Return value of all callback functions is OR'd and the
+ * value is passed back to the caller. @fn is called with
* omap_hwmod_for_each() held.
*/
int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
void *data)
{
struct omap_hwmod *temp_oh;
- int ret;
+ int ret = 0;
if (!fn)
return -EINVAL;
- list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
- ret = (*fn)(temp_oh, data);
- if (ret)
- break;
- }
+ list_for_each_entry(temp_oh, &omap_hwmod_list, node)
+ ret |= (*fn)(temp_oh, data);
return ret;
}
@@ -2127,8 +2123,7 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh, const char *name)
* @user: arbitrary context data to pass to the callback function
*
* For each omap_hwmod of class @classname, call @fn.
- * If the callback function returns something other than
- * zero, the iterator is terminated, and the callback function's return
+ * Return value of all callback functions is OR'd and the
* value is passed back to the caller. Returns 0 upon success, -EINVAL
* if @classname or @fn are NULL, or passes back the error code from @fn.
*/
@@ -2150,14 +2145,12 @@ int omap_hwmod_for_each_by_class(const char *classname,
if (!strcmp(temp_oh->class->name, classname)) {
pr_debug("omap_hwmod: %s: %s: calling callback fn\n",
__func__, temp_oh->name);
- ret = (*fn)(temp_oh, user);
- if (ret)
- break;
+ ret |= (*fn)(temp_oh, user);
}
}
if (ret)
- pr_debug("omap_hwmod: %s: iterator terminated early: %d\n",
+ pr_debug("omap_hwmod: %s: one or more callback fn failed: %d\n",
__func__, ret);
return ret;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/2] Fix/Clean regulator consumer mapping for 3430sdp
From: Rajendra Nayak @ 2011-02-16 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296737122-20765-1-git-send-email-rnayak@ti.com>
Tony,
> -----Original Message-----
> From: Rajendra Nayak [mailto:rnayak at ti.com]
> Sent: Thursday, February 03, 2011 6:15 PM
> To: linux-omap at vger.kernel.org
> Cc: tony at atomide.com; linux-arm-kernel at lists.infradead.org;
balbi at ti.com; Rajendra Nayak
> Subject: [PATCH v2 0/2] Fix/Clean regulator consumer mapping for 3430sdp
>
> This is a short series to fix some, and clean the
> existing regulator consumer supply mappings for
> the OMAP3430sdp board.
>
> The series is boot tested on the 3430sdp board
> and applies on 2.6.38-rc3.
Any plans to pull these 3430sdp board file cleanup/fixes?
Regards,
Rajendra
>
> Changes in v2:
> Define regulator_consumer_supply as array's
> and use ARRAY_SIZE macro to define
> num_consumer_supplies
>
> Rajendra Nayak (2):
> omap3sdp: Fix regulator mapping for ads7846 TS controller
> omap3sdp: clean regulator supply mapping in board file
>
> arch/arm/mach-omap2/board-3430sdp.c | 78
+++++++++++++++++------------------
> 1 files changed, 38 insertions(+), 40 deletions(-)
^ permalink raw reply
* [PATCH] i.MX23/28 framebuffer driver
From: Arnd Bergmann @ 2011-02-16 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikhcphz_8TS4L+z2heayqnJbK1NEW8DzqTm=YKp@mail.gmail.com>
On Tuesday 15 February 2011, Clark, Rob wrote:
> I'd been experimenting a bit on the side w/ the DRM driver framework (
> http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
> ), but had to add a good chunk of mostly boilerplate code to our xorg
> driver in order just to test it. Maybe some generic support for KMS
> in xf86-video-fbdev would have made this easier to develop the kernel
> part without in parallel having to implement the userspace part. I'm
> not sure if this is the sort of thing the linaro-wg has in mind?
I'm not sure what the the linaro multimedia wg thinks of this, but the
kernel code you linked looks like it's doing exactly the right thing.
Arnd
^ permalink raw reply
* [PATCH 16/17] mc13xxx: mfd_cell is now implicitly available to drivers
From: Fabio Estevam @ 2011-02-16 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216094154.GV13279@pengutronix.de>
Hi Uwe,
On 2/16/2011 7:41 AM, Uwe Kleine-K?nig wrote:
...
>>
>> /* MC13783 */
>> -static struct mc13783_platform_data mc13783_pdata __initdata = {
> isn't using __initdata here broken already before your patch? Was
> introduced in c67a3e09. Fabio?
I followed the same approach as in the mx31_3ds.c file.
> But in general I'd prefer to keep as much __initdata as possible because
> this occupies less memory when using a multi-machine kernel.
So keeping __initdata is OK then? Let me know and I can fix it needed.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 16/17] mc13xxx: mfd_cell is now implicitly available to drivers
From: Fabio Estevam @ 2011-02-16 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216094154.GV13279@pengutronix.de>
Hi Uwe,
On 2/16/2011 7:41 AM, Uwe Kleine-K?nig wrote:
...
>> /* MC13783 */
>> -static struct mc13783_platform_data mc13783_pdata __initdata = {
> isn't using __initdata here broken already before your patch? Was
> introduced in c67a3e09. Fabio?
I followed the same approach as in mx31_3ds.c file.
> But in general I'd prefer to keep as much __initdata as possible because
> this occupies less memory when using a multi-machine kernel.
Ok, is the __initdata usage correct then? If not, I can change it. Just let me know.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Jarkko Nikula @ 2011-02-16 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTiniGdh2_=eFjSaLsQ4VVG1Eh0F=0Tex-KNKspBf@mail.gmail.com>
On Wed, 16 Feb 2011 17:24:30 +0530
"Gulati, Shweta" <shweta.gulati@ti.com> wrote:
> > Note proof of concept patch only. I omitted the comments and don't do
> > explicit SR disable and I'd clean up the error paths in twl4030_power_init
> > a bit before this (e.g. printing error codes). Not sure either is the
> > twl4030-power.c right place for this or core.
> You missed commit log which says that "T2 bit is required to enable I2C_SR
> path of voltage control" it is not at all enabling SR, voltage scale
> APIs VPforceupdate/ VCbypass
> needs this path to be enabled.
> And calling APIs twl_i2c_read/write in driver codebase does n't ensure correct
> ordering of flag changes and twl_read/write.
Ah, yeah. I forgot to comment that I tried shortly also to run this
enable code from workqueue ~60 s after bootup and indeed SR didn't work
if those autocomp sysfs nodes were set before setting the TWL SR bit and
I believe same holds for voltage scaling too as you say.
What I'm thinking is there actually need for some higher level
control for these that quarantees the right order independently from
when each module are initialized.
--
Jarkko
^ permalink raw reply
* [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
From: Santosh Shilimkar @ 2011-02-16 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4dfaffa99292bf8e36791ea9a68de75e@mail.gmail.com>
Catalin,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Tuesday, February 15, 2011 12:44 PM
> To: linux-arm-kernel at lists.infradead.org; Andrei Warkentin
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com;
> Catalin Marinas
> Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
> operation can cause data corruption
>
> > -----Original Message-----
> > From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> > Sent: Monday, February 14, 2011 10:39 AM
> > To: Andrei Warkentin
> > Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com;
> > linux-arm-kernel at lists.infradead.org; Catalin Marinas
> > Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
> > operation can cause data corruption
> >
>
> [....]
>
> > > ...
> > I understood that from first comment. But I am not in favor
> > of polluting common ARM files with SOC specific #ifdeffery.
> > We have gone over this when first errata support
> > was added for PL310
> >
> > I have a better way to handle this scenario.
> > Expect an updated patch for this.
> >
>
> Below is the updated version which should remove any
> OMAP dependency on these errata's. Attached same.
>
> ----
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Fri, 14 Jan 2011 14:16:04 +0530
> Subject: [v2 PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
> operation
> can cause data corruption
>
> PL310 implements the Clean & Invalidate by Way L2 cache maintenance
> operation (offset 0x7FC). This operation runs in background so that
> PL310 can handle normal accesses while it is in progress. Under very
> rare circumstances, due to this erratum, write data can be lost when
> PL310 treats a cacheable write transaction during a Clean &
> Invalidate
> by Way operation.
>
> Workaround:
> Disable Write-Back and Cache Linefill (Debug Control Register)
> Clean & Invalidate by Way (0x7FC)
> Re-enable Write-Back and Cache Linefill (Debug Control Register)
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
Ack , Nak ?
> arch/arm/Kconfig | 13 ++++++++++++-
> arch/arm/include/asm/outercache.h | 1 +
> arch/arm/mach-omap2/Kconfig | 3 +++
> arch/arm/mach-omap2/omap4-common.c | 7 +++++++
> arch/arm/mm/cache-l2x0.c | 28 +++++++++++++++----------
> ---
> 5 files changed, 38 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5cff165..ebadd95 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
>
> config PL310_ERRATA_588369
> bool "Clean & Invalidate maintenance operations do not
> invalidate
> clean lines"
> - depends on CACHE_L2X0 && ARCH_OMAP4
> + depends on CACHE_L2X0 && CACHE_PL310
> help
> The PL310 L2 cache controller implements three types of
> Clean &
> Invalidate maintenance operations: by Physical Address
> @@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622
> visible impact on the overall performance or power
> consumption
> of the
> processor.
>
> +config PL310_ERRATA_727915
> + bool "Background Clean & Invalidate by Way operation can cause
> data corruption"
> + depends on CACHE_L2X0 && CACHE_PL310
> + help
> + PL310 implements the Clean & Invalidate by Way L2 cache
> maintenance
> + operation (offset 0x7FC). This operation runs in background
> so
> that
> + PL310 can handle normal accesses while it is in progress.
> Under
> very
> + rare circumstances, due to this erratum, write data can be
> lost
> when
> + PL310 treats a cacheable write transaction during a Clean &
> + Invalidate by Way operation Note that this errata uses Texas
> + Instrument's secure monitor api to implement the work
> around.
> endmenu
>
> source "arch/arm/common/Kconfig"
> diff --git a/arch/arm/include/asm/outercache.h
> b/arch/arm/include/asm/outercache.h
> index fc19009..348d513 100644
> --- a/arch/arm/include/asm/outercache.h
> +++ b/arch/arm/include/asm/outercache.h
> @@ -31,6 +31,7 @@ struct outer_cache_fns {
> #ifdef CONFIG_OUTER_CACHE_SYNC
> void (*sync)(void);
> #endif
> + void (*set_debug)(unsigned long);
> };
>
> #ifdef CONFIG_OUTER_CACHE
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-
> omap2/Kconfig
> index f285dd7..fd11ab4 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -45,7 +45,10 @@ config ARCH_OMAP4
> select CPU_V7
> select ARM_GIC
> select LOCAL_TIMERS
> + select CACHE_L2X0
> + select CACHE_PL310
> select PL310_ERRATA_588369
> + select PL310_ERRATA_727915
> select ARM_ERRATA_720789
> select ARCH_HAS_OPP
> select PM_OPP if PM
> diff --git a/arch/arm/mach-omap2/omap4-common.c
> b/arch/arm/mach-omap2/omap4-common.c
> index 1926864..9ef8c29 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)
> omap_smc1(0x102, 0x0);
> }
>
> +static void omap4_l2x0_set_debug(unsigned long val)
> +{
> + /* Program PL310 L2 Cache controller debug register */
> + omap_smc1(0x100, val);
> +}
> +
> static int __init omap_l2_cache_init(void)
> {
> u32 aux_ctrl = 0;
> @@ -99,6 +105,7 @@ static int __init omap_l2_cache_init(void)
> * specific one
> */
> outer_cache.disable = omap4_l2x0_disable;
> + outer_cache.set_debug = omap4_l2x0_set_debug;
>
> return 0;
> }
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 170c9bb..a8caee4 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -67,18 +67,22 @@ static inline void l2x0_inv_line(unsigned long
> addr)
> writel_relaxed(addr, base + L2X0_INV_LINE_PA);
> }
>
> -#ifdef CONFIG_PL310_ERRATA_588369
> +#if defined(CONFIG_PL310_ERRATA_588369) ||
> defined(CONFIG_PL310_ERRATA_727915)
> static void debug_writel(unsigned long val)
> {
> - extern void omap_smc1(u32 fn, u32 arg);
> -
> - /*
> - * Texas Instrument secure monitor api to modify the
> - * PL310 Debug Control Register.
> - */
> - omap_smc1(0x100, val);
> + if (outer_cache.set_debug)
> + outer_cache.set_debug(val);
> + else
> + writel(val, l2x0_base + L2X0_DEBUG_CTRL);
> +}
> +#else
> +/* Optimised out for non-errata case */
> +static inline void debug_writel(unsigned long val)
> +{
> }
> +#endif
>
> +#ifdef CONFIG_PL310_ERRATA_588369
> static inline void l2x0_flush_line(unsigned long addr)
> {
> void __iomem *base = l2x0_base;
> @@ -91,11 +95,6 @@ static inline void l2x0_flush_line(unsigned long
> addr)
> }
> #else
>
> -/* Optimised out for non-errata case */
> -static inline void debug_writel(unsigned long val)
> -{
> -}
> -
> static inline void l2x0_flush_line(unsigned long addr)
> {
> void __iomem *base = l2x0_base;
> @@ -119,9 +118,11 @@ static void l2x0_flush_all(void)
>
> /* clean all ways */
> spin_lock_irqsave(&l2x0_lock, flags);
> + debug_writel(0x03);
> writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
> cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
> cache_sync();
> + debug_writel(0x00);
> spin_unlock_irqrestore(&l2x0_lock, flags);
> }
>
> @@ -329,6 +330,7 @@ void __init l2x0_init(void __iomem *base, __u32
> aux_val, __u32 aux_mask)
> outer_cache.flush_all = l2x0_flush_all;
> outer_cache.inv_all = l2x0_inv_all;
> outer_cache.disable = l2x0_disable;
> + outer_cache.set_debug = NULL;
>
> printk(KERN_INFO "%s cache controller enabled\n", type);
> printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL
> 0x%08x,
> Cache size: %d B\n",
> --
> 1.6.0.4
^ 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