Hi Wim,
On Mon, 28 Jan 2013, Aaro Koskinen wrote:
> On Thu, Dec 27, 2012 at 10:58:29PM +0200, Aaro Koskinen wrote:
> > Introduce Retu watchdog driver.
>
> Wim, any comments about this driver? Do you think it could be queued
> for 3.9?
It'd be really great if this could go in for v3.9. Without
Hi,
On Wed, 2 Jan 2013, Philip Avinash wrote:
> EHRPWM module requires explicit clock gating of TBCLK from control
> module. Hence add TBCLK clock node in clock tree for EHRPWM modules.
>
> Signed-off-by: Philip Avinash
This patch adds some sparse[1] warnings:
> arch/arm/mach-omap2/cclock33xx
er address
space. This patch:
1. Corrects register address mapping for ECAP & EHRPWM
2. Removes HWMOD flags in PWM submodule register address space.
3. Adds EQEP HWMOD entries.
Signed-off-by: Philip Avinash
[p...@pwsan.com: tweaked patch description]
Signed-off-by: Paul Walmsley
---
Hi Roger,
On Tue, 5 Feb 2013, Roger Quadros wrote:
> FYI, the usbhost patches are already in linux-next.
Thanks, I think I'll wait for 3.10 cleanup to send the clock cleanup
patches, they seem non-critical...
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> DEFINE_STRUCT_CLK does not have the capability to set flags, define
> DEFINE_STRUCT_CLK_FLAGS to handle flags. This is needed to add
> SET_RATE_PARENT flag in statically defined lcd clock in am335x.
>
> Signed-off-by: Afzal Mohammed
Thanks, queued fo
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> LCDC clock node is a one that does not have set rate capability. It
> just passes on the rate that is sent downstream by it's parent. While
> lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
> dpll_disp_ck has the capability to configure ra
On Thu, 31 Jan 2013, Paul Walmsley wrote:
> This one doesn't apply for me on v3.8-rc5 + your patches 2 and 3. Could
> you please update it and re-send?
Oops, looks like I accidentally tried to apply the first version of this
patch rather than the second one. The second one appl
Hi
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
> Currently round rate function would return proper rate iff requested
> rate exactly matches the PLL lockable rate. This causes set_rate to
> fail if exact rate could not be set. Instead round rate may return
> closest rate possible (less than the re
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> am335x does not have freqsel, avoid it.
>
> Signed-off-by: Afzal Mohammed
Thanks, queued for 3.9.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi
On Fri, 25 Jan 2013, Mohammed, Afzal wrote:
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > On Wed, 23 Jan 2013, Afzal Mohammed wrote:
>
> > > Currently round rate function would return proper rate iff requested
> > > rate exactly matches the
Convert the OMAP onboard hardware RNG driver to use runtime PM.
This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the RNG driver.
Signed-off-by: Paul Walmsley
Cc: Matt Mackall
Cc: Herbert Xu
---
drivers/char/hw_random/omap-rng.c | 35
Also, if other OMAP chips have RNGs that can be used
by Linux, there will be no need to modify the driver.
Signed-off-by: Paul Walmsley
Cc: Matt Mackall
Cc: Herbert Xu
---
arch/arm/mach-omap1/devices.c |3 +++
drivers/char/hw_random/omap-rng.c |3 ---
2 files changed, 3 insert
Encapsulate all of the RNG per-device state into a single per-device
structure record, as opposed to a set of per-driver file variables.
Signed-off-by: Paul Walmsley
Cc: Matt Mackall
Cc: Herbert Xu
---
drivers/char/hw_random/omap-rng.c | 115 +
1 file
Hello Jiří,
On Tue, 4 Sep 2012, Jiri Kosina wrote:
> Paul Walmsley has implemented dynamic quirk handling back in 2007 through
> commits:
>
> 2eb5dc30eb ("USB HID: encapsulate quirk handling into hid-quirks.c")
> 8222fbe67c ("USB HID: clarify static quirk hand
Hi Felipe
Just tested these OMAP serial changes at commit
e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 ("serial: omap: fix compile
breakage"). There's good news and bad news...
The good news is that after applying this series, the 'OMAP4 UART garbage
on long transmit buffers when PM is enabled'
Hi Kishon, Benoît,
On Fri, 7 Sep 2012, Kishon Vijay Abraham I wrote:
> Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this
> ocp2scp module does not have any fck but does have a single opt_clock,
> it is added as the main_clk for ocp2scp. Also removed phy_48m as the
> option
On Fri, 24 Aug 2012, Vaibhav Hiremath wrote:
> Add missing soc_is_am33xx() check for DPLL common control & clock
> related functions, without this dpll programmability would be broken
> for am33xx family of devices.
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Rajendra Naya
Hi
On Wed, 12 Sep 2012, Felipe Balbi wrote:
> On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
>
> > The bad news is that N800 no longer boots -- or the UART dies during
> > serial init:
> >
> > http://www.pwsan.com/omap/testlogs/test_tty_nex
Hi Paul
Recently several of us have been seeing "INFO: rcu_sched self-detected
stall on CPU { 0} (t=20611 jiffies)" stack tracebacks on various OMAP3
and 4 board.
I only noticed it during v3.6-rc3, but I suspect it's been happening
for users at least since May:
http://www.mail-archive.com/linu
ers.
> >
> > This is required in order to get AM33XX boot functionality.
> >
> > Signed-off-by: Vaibhav Hiremath
> > Cc: Paul Walmsley
> > ---
> > arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 168
> > ++--
> > 1 file
On Thu, 13 Sep 2012, Benoit Cousson wrote:
> In this case, the ocp2scp IP is just the *bus controller* to access the
> real USB_UTMI_PHY IP.
>
> The TRM diagram does not show that level of detail unfortunately. You
> can check the PRCM spec (Figure 78 : CD_L3_INIT_USB clock scheme) to see
> the t
Hi Paul,
thanks for the reply,
On Wed, 12 Sep 2012, Paul E. McKenney wrote:
> Interesting. I am assuming that the interrupt in the stack below came
> from idle, if not, please let me know what.
According to the exception stack section in the original traceback, it
appears that the serial inter
On Thu, 13 Sep 2012, Paul Walmsley wrote:
> Okay so is this an Acked-by for this patch? :-)
>
> If so I'll take it.
Just realized that's what your reply was, so have queued the patch for
3.7.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-
Hi Andy, Joe,
On Wed, 13 Jun 2012, Joe Perches wrote:
> Parenthesis alignment doesn't correctly check an existing line
> after an inserted or modified line with an open parenthesis.
>
> Fix it.
>
> Signed-off-by: Joe Perches
Reviewed-by: Paul Walmsley
Tested-by: Pau
at
actually shows up in traces.
Signed-off-by: Paul Walmsley
Cc: Paul E. McKenney
Cc: Dipankar Sarma
---
Documentation/RCU/stallwarn.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index
Hi Paul
On Thu, 20 Sep 2012, Paul Walmsley wrote:
> On Thu, 20 Sep 2012, Paul E. McKenney wrote:
>
> > Paul Walmsley, please let me know if the config below doesn't clear things
> > up for you or if there is some reason why this config is infeasible.
>
> Will certa
On Fri, 21 Sep 2012, Paul Walmsley wrote:
> The config used was 'omap2plus_defconfig', and enabled CONFIG_CPU_IDLE
> by hand.
One other thing I forgot to mention - CONFIG_RCU_CPU_STALL_INFO was
enabled by hand also. Below is the diff between omap2plus_defconfig and
the conf
cc Frederic Weisbecker - context is here:
http://marc.info/?l=linux-kernel&m=134749030206016&w=2
On Thu, 20 Sep 2012, Paul E. McKenney wrote:
> Fair point. I am wondering whether there is some path into the idle
> loop that somehow avoids telling RCU that the CPU has in face entered
> idle.
Hi
Just did a test with CONFIG_NO_HZ=n, and no rcu_sched stall messages
appeared for 60 minutes.
Following is the diff from omap2plus_defconfig.
- Paul
--- .config 2012-09-21 12:51:19.114938954 -0600
+++ .testconfig 2012-09-21 12:51:15.686926318 -0600
@@ -69,7 +69,7 @@
# Timers subsystem
On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> On Fri, Sep 21, 2012 at 06:08:59PM +0000, Paul Walmsley wrote:
>
> > As far as I know, our only idle entry point is in
> > arch/arm/common/process.c:cpu_idle().
>
> In mainline, this is arch/arm/kernel/process.c, correct?
On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> Good catch! Even worse, it gives "timer=18446744073709551615" on
> 64-bit systems, which is no easier on the eyes. I therefore changed
> the code to print a nicer message in this case, patch below.
Looks better, thanks.
- Paul
--
To unsubscribe fr
On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> On Fri, Sep 21, 2012 at 05:47:31PM +0000, Paul Walmsley wrote:
>
> > I built an OMAP kernel from Linus' commit
> > 4651afbbae968772efd6dc4ba461cba9b49bb9d8 ("Merge branch 'for-3.6-fixes' of
> > git://g
Hi Paul
On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> I am wondering if your system somehow figured out how to start a grace
> period that had no RCU callbacks waiting for it. If that happened,
> then a CONFIG_NO_HZ=y system could in theory get into a state where all
> CPUs are in dyntick-idle
On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> Could you please point me to a recipe for creating a minimal userspace?
> Just in case it is the userspac erather than the architecture/hardware
> that makes the difference.
Tony's suggestion is pretty good. Note that there may also be differences
Hi Paul
On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> Strangely enough, I believe that I have inadvertently fixed this in
> my -rcu tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>
> Nevertheless, if you get a chance to try it, I would be interested to
>
On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> And here is a patch. I am still having trouble reproducing the problem,
> but figured that I should avoid serializing things.
Thanks, testing this now on v3.6-rc6. One question though about the patch
description:
> All this begs the question of e
Hi Paul
On Sat, 22 Sep 2012, Paul Walmsley wrote:
> On Sat, 22 Sep 2012, Paul E. McKenney wrote:
>
> > And here is a patch. I am still having trouble reproducing the problem,
> > but figured that I should avoid serializing things.
>
> Thanks, testing this now on v
On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> Very cool, thank you for your testing efforts!!!
You're welcome.
> May I apply your Tested-by to this patch?
Please do:
Tested-by: Paul Walmsley # OMAP4430
Am testing on OMAP3730 (single-core) now.
- Paul
--
To unsubscribe fro
On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> On Sat, Sep 22, 2012 at 10:25:59PM +0000, Paul Walmsley wrote:
>
> > The recent tests here have been on Pandaboard, which is dual-CPU, but my
> > recollection is that I also observed the warnings on a single-core
> > Be
On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> On Sat, Sep 22, 2012 at 10:20:19PM +0000, Paul Walmsley wrote:
> > On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> >
> > > This thing has been in the kernel since about 2004, not sure why you
> > > didn't hit it
+ Vaibhav Hiremath
On Tue, 30 Oct 2012, Tony Lindgren wrote:
> * Pantelis Antoniou [121030 11:04]:
> > Looks like the lcdc clock definition got dropped.
> > It is required for the LCD controller to work. Reintroduce.
>
> This looks like a regression, can you also add the commit
> causing it?
L
On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
> As far as lck clock node is concerned, we had deliberately dropped all leaf-
> node clocks from the clock tree, please refer to the description mentioned
> in -
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html
Ach, shoul
Hi
a comment on this one (and any similar patch)
On 10/03/2013 08:56 AM, Viresh Kumar wrote:
__cpuidle_get_cpu_driver() is a single line function and so deserves to be
marked inline.
In general, this is a violation of Documentation/CodingStyle - see
Chapter 15.
Unless this produces a signi
On Sun, 6 Oct 2013, Sebastian Reichel wrote:
> This patch adds Synchronous Serial Interface (SSI) hwmod support for
> OMAP34xx SoCs.
>
> Signed-off-by: Sebastian Reichel
Thanks, queued this one for v3.13. You can drop it from any future
reposts of this series.
- Paul
--
To unsubscribe from
On Tue, 8 Oct 2013, Roger Quadros wrote:
> Add hwmod data for High Speed USB host and TLL modules
>
> CC: Paul Walmsley
> Signed-off-by: Roger Quadros
Thanks, queued.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hi Roger,
On Thu, 21 Mar 2013, Roger Quadros wrote:
> +Paul
>
> On 03/21/2013 03:48 PM, Roger Quadros wrote:
> > If the bootloader doesn't configure USB DPLL (e.g. in u-boot,
> > disable CONFIG_USB_EHCI_OMAP), then we get all sorts of problems
> > like
> > - division by zero errors at boot [1]
>
On Tue, 17 Sep 2013, Suman Anna wrote:
> Add the missing sysc configuration to the AM335 spinlock hwmod
> data. This ensures that smart-idle is enabled whenever the module
> is enabled by the driver.
>
> Signed-off-by: Suman Anna
Thanks, queued. You can omit this one from future reposts of thi
On Tue, 17 Sep 2013, Suman Anna wrote:
> Add the hwmod data for the spinlock IP in OMAP5 SoC.
> This is needed to be able to enable the OMAP spinlock
> support for OMAP5.
>
> Signed-off-by: Suman Anna
Thanks, queued. You can omit this one from future reposts of this series.
- Paul
--
To uns
On Fri, 27 Sep 2013, Javier Martinez Canillas wrote:
> I cc'ed Aaro Koskinen and Paul Walmsley now which seems to have OMAP1
> platforms
> to test. Could you please test [1] and [2] on a OMAP1 board? These patches
> solves a long standing issue we have on OMAP2+ when booti
Hi
On Fri, 27 Sep 2013, Suman Anna wrote:
> Paul,
> The hwmod data patches needs to be merged only after the respective DT
> node patches are merged, without which the hwmod entry will not have a
> base address while enabling and idling (using sysc) the hwmod during
> hwmod initialization.
Hmm,
Hi
On Thu, 6 Sep 2012, Felipe Balbi wrote:
> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
On Fri, 30 Nov 2012, Philip, Avinash wrote:
> Is there any way to get HWMOD and DT patches getting accepted in 3.8?
> Or should I wait and send rebased patch based on 3.8-rc1?
Our upstreams aren't taking any more new features for v3.8, so basing on
v3.8-rc1 is the best thing to do now.
In the m
Hi Omar,
On Thu, 6 Dec 2012, Omar Ramirez Luna wrote:
> I have checked next-20121206, it's OK to delete that file as the patch
> from Paul is doing that for common clock framework migration; now the
> only missing hunk from my original patch should apply to
> arch/arm/mach-omap2/cclock44xx_data.c
On Thu, 6 Dec 2012, Omar Ramirez Luna wrote:
> I was planning to wait until linux-omap had the changes from iommu
> tree (probably at rc1), if the merge conflict resulted in
> arch/arm/mach-omap2/cclock44xx_data.c still having ipu and dsp clocks,
> in this case the hwmod data changes wouldn't be n
On Mon, 10 Dec 2012, Roger Quadros wrote:
> We don't need multiple aliases for the OMAP USB host clocks and neither
> the dummy clocks so remove them.
>
> CC: Paul Walmsley
> CC: Rajendra Nayak
> CC: Benoit Cousson
> CC: Mike Turquette
>
> Signed-off-by
On Mon, 10 Dec 2012, Roger Quadros wrote:
> We don't need multiple aliases for the OMAP USB host clocks so remove them.
>
> CC: Paul Walmsley
> CC: Rajendra Nayak
> CC: Benoit Cousson
> CC: Mike Turquette
>
> Signed-off-by: Roger Quadros
Acked-by: Paul Walmsle
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
> In the map for reset sources register we use defines intended for
> using with PRM_RSTCTRL register. So fix it.
>
> Signed-off-by: Ivan Khoronzhuk
Thanks, queued for v3.8-rc fixes.
- Paul
--
To unsubscribe from this list: send the line "unsubscrib
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
> From: Nishanth Menon
>
> RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
> OMAP4460.
>
> Signed-off-by: Nishanth Menon
> [ivan.khoronz...@ti.com: ported from k3.4]
> Signed-off-by: Ivan Khoronzhuk
Thanks guys, queued for v3.8-rc f
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
> To read reset sources registers we have to use PRM_DEVICE_INST
>
> Signed-off-by: Ivan Khoronzhuk
Thanks, queued for v3.8-rc fixes.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
On Tue, 18 Dec 2012, Linus Torvalds wrote:
> But quite frankly, the thing is ugly as heck, and I hope it could just
> be deleted.
With luck we'll be able to get rid of it in 3.9, once the underlying issue
with the I2C driver is tracked down.
- Paul
--
To unsubscribe from this list: send the li
(cc Tero)
Hi,
On Thu, 20 Dec 2012, Sasha Levin wrote:
> With the current code, the condition in the if() doesn't make much sense due
> to
> precedence of operators.
>
> Signed-off-by: Sasha Levin
> ---
> drivers/mmc/host/omap_hsmmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Thu, 15 Nov 2012, Jon Hunter wrote:
>
> On 11/15/2012 11:07 AM, Igor Mazanov wrote:
> > Remove inline from clock framework function definitions to
> > build the kernel with GCC 4.7
>
> Adding Mike to the party ...
>
> May be good to add some details about the exact problem seen.
>
> I am
s
of the OMAP folks.
Acked-by: Paul Walmsley
> ---
> include/linux/clk-provider.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index c127315..f9f5e9e 100644
> --- a/include/l
>
> Signed-off-by: Jean-Philippe Francois
> Cc: NeilBrown
> Cc: Mike Turquette
> Signed-off-by: Paul Walmsley
> Signed-off-by: Jonghwan Choi
> ---
> arch/arm/mach-omap2/clock36xx.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
>
здравствуйте,
On Wed, 5 Jun 2013, Aida Mynzhasova wrote:
> Not so long ago I tried to boot Linux 3.10-rc4 kernel on DM816x EVM
> board. Unfortunately, my attempts were failed by reason of poor
> support of DM81xx-based devices in new kernels.
Yeah, TI pretty much gave up on trying to get support
Hi,
also,
On Wed, 5 Jun 2013, Aida Mynzhasova wrote:
> Aida Mynzhasova (5):
> ARM: OMAP: AM33xx: multiple renames for early initialization
If this patch is what's responsible for all the file renaming, please drop
it. Looks from the change summary that it's just useless churn (although
I h
Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators. This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: Paul Walmsley
Reviewed-by: Andrew Chew
Cc: Matthew Longnecker
Hi Mark,
On Fri, 7 Jun 2013, Mark Brown wrote:
> On Fri, Jun 07, 2013 at 08:06:56AM +0000, Paul Walmsley wrote:
>
> > Applies on v3.10-rc4. Will be used by the upcoming Tegra DFLL clocksource
> > driver, which will build its own table of voltage-to-VSEL values by
> >
Hi Mark,
On Fri, 7 Jun 2013, Mark Brown wrote:
> On Fri, Jun 07, 2013 at 09:38:10AM +0000, Paul Walmsley wrote:
>
> > +static int get_cvb_voltage(struct platform_device *pdev, int c0, int c1,
> > + int c2)
> > +{
> > + struct tegra_dfll *t
On Fri, 7 Jun 2013, Paul Walmsley wrote:
> The IP block has an I2C controller embedded in it that autonomously sends
> set-voltage commands (across a range of voltages) to the PMIC. To enable
> that, the driver must first initialize the IP block with a
> voltage-to-selector table.
Hi,
On Sat, 15 Jun 2013, Mike Turquette wrote:
> These patches appear fine to me but I did not see any Acks, nor could I
> tell if a v2 was necessary based on the comments. Will there be another
> version?
I'm not planning to do another version at this time.
> If not an Acked-by or Reviewed-by
On 06/18/2013 11:28 AM, Mike Turquette wrote:
Thanks for clarifying. I couldn't tell based on the discussion.
No worries :-)
Anyways I've taken these into clk-next now. There is not maintainer
for that directory as you pointed out, so no need to wait for Acks.
Great, thanks. Or if you'd pr
oscillate, although reads and writes to the
DFLL IP block will complete.
Thanks to Aleksandr Frid for identifying this and
saving hours of debugging time.
Signed-off-by: Paul Walmsley
Cc: Aleksandr Frid
Cc: Peter De Schrijver
---
drivers/clk/tegra/clk-tegra114.c | 37
resolve PWR_I2C timeout
issues.
Signed-off-by: Paul Walmsley
Cc: Peter De Schrijver
Reviewed-by: Andrew Chew
Cc: Matthew Longnecker
Cc: Laxman Dewangan
---
drivers/clk/tegra/clk-tegra114.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra114.c b
incorrectly defined.
Based on code originally written by Aleksandr Frid .
Signed-off-by: Paul Walmsley
Cc: Andrew Chew
Reviewed-by: Andrew Chew
Cc: Matthew Longnecker
Cc: Aleksandr Frid
---
drivers/clk/tegra/clk-tegra114.c | 118 ++
drivers/clk/tegra
Add the CAR IP block infrastructure needed to support the DFLL clocksource
to the Tegra114 clock code and data files.
Based on linux-next master. Mike, please let me know if you want the
patches based on a v3.10-rc.
Boot-tested on Tegra114 Dalmore; log follows.
- Paul
---
Paul Walmsley (3
Hi Stephen,
On Fri, 7 Jun 2013, Stephen Warren wrote:
> On 06/07/2013 06:19 AM, Paul Walmsley wrote:
> > Add DFLL DVCO reset line control functions to the CAR IP block driver.
> >
> > The DVCO present in the DFLL IP block has a separate reset line,
> > exposed via th
On Thu, 6 Jun 2013, Sebastian Andrzej Siewior wrote:
> From: Philip Avinash
>
> EHRPWM module requires explicit clock gating of TBCLK from control
> module. Hence add TBCLK clock node in clock tree for EHRPWM modules.
>
> Signed-off-by: Philip Avinash
> [bigeasy: remove CK_AM33XX]
> Signed-off
Hi Roger,
On Tue, 5 Feb 2013, Roger Quadros wrote:
> On 01/21/2013 05:03 PM, Paul Walmsley wrote:
> > Hi
> >
> > On Mon, 21 Jan 2013, Roger Quadros wrote:
> >
> >> On 01/18/2013 10:27 PM, Paul Walmsley wrote:
> >>> On Fri, 18 Jan 2013, Roger Qu
PRM/CM: move the low-level clockdomain functions into
> PRM/CM).
>
> I am not sure if this fix is correct, since there are other things in
> these files. Please NAK this patch (and propose a better one) if it is
> wrong.
>
> Cc: Paul Walmsley
> Cc: Rajendra Nayak
> Cc: R
On Tue, 11 Jun 2013, Prashant Gaikwad wrote:
> Why not implement these APIs in DFLL clock driver itself and pass RST address
> register to driver?
The DFLL DVCO reset registers are CAR registers, not DFLL registers.
Functions that operate on registers in one IP block shouldn't be located
in an
Hi,
On Tue, 12 Mar 2013, Suman Anna wrote:
> The OMAP mailbox platform driver code has been cleaned up to
> remove the dependencies with soc.h in preparation for moving
> the mailbox code to drivers folder.
>
> The code relied on cpu_is_xxx/soc_is_xxx macros previously to
> pick the the right se
Hi Sebastian
On Sun, 11 Aug 2013, Sebastian Reichel wrote:
> From: Sebastian Reichel
>
> This patch adds Synchronous Serial Interface (SSI) hwmod support for
> OMAP34xx SoCs.
a few comments:
- please add your Signed-off-by: to the patch description, per
Documentation/SubmittingPatches
- ple
Hi
On Fri, 23 Aug 2013, Sebastian Reichel wrote:
> On Wed, Aug 21, 2013 at 01:22:09AM +0000, Paul Walmsley wrote:
> > > From: Sebastian Reichel
> > > This patch adds Synchronous Serial Interface (SSI) hwmod support for
> > > OMAP34xx SoCs.
> >
> >
On Sun, 21 Jul 2013, Joe Perches wrote:
> commit 4bd5259e53a ("ARM: OMAP2/3: clockdomain/PRM/CM: move the
> low-level clockdomain functions into PRM/CM") deleted the files,
> update the pattern.
>
> Signed-off-by: Joe Perches
> cc: Paul Walmsley
> cc: Rajendra
On Sun, 21 Jul 2013, Joe Perches wrote:
> commit 498153995b9 ("ARM: OMAP2+: powerdomain/PRM: move the
> low-level powerdomain") renamed the files, update the patterns.
>
> Signed-off-by: Joe Perches
> cc: Paul Walmsley
> cc: Rajendra Nayak
> cc: Santosh Sh
Hi Joe,
On Sun, 21 Jul 2013, Joe Perches wrote:
> I certainly don't object at all if Andrew picks
> up the patches you mentioned and drops these 2.
>
> Andrew, here are links to Cesar's original patches
> https://patchwork.kernel.org/project/LKML/list/?submitter=3513
> https://lkml.org/lkml/2013
On Mon, 22 Jul 2013, Roger Quadros wrote:
> I observe the following problem on booting v3.11-rc1 on OMAP3 beagle board.
>
> [5.888946] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> [5.896057] Modules linked in:
> [5.899322] CPU: 0 PID: 9 Comm: rcu_sched Not tainted
>
tory clock for usb phy attached to ocp2scp and hence made as the main
> clock for ocp2scp.
>
> Cc: Keerthy
> Cc: Benoît Cousson
> Cc: Paul Walmsley
> Signed-off-by: Kishon Vijay Abraham I
This patch is missing the "big comment" that I requested in the hwmod
data:
ht
ached to ocp2scp and hence made as the main
clock for ocp2scp.
Cc: Keerthy
Cc: Benoît Cousson
Cc: Paul Walmsley
Signed-off-by: Kishon Vijay Abraham I
[p...@pwsan.com: add comment to the hwmod data to try to prevent any
future mistakes here]
Signed-off-by: Paul Walmsley
---
Nothing further rece
Hi Tony,
could you send this one upstream for v3.9-rc fixes? Should prevent
a MUSB regression in v3.9, mostly due to my own incompetence.
- Paul
-- Forwarded message --
Date: Wed, 10 Apr 2013 19:41:38 + (UTC)
From: Paul Walmsley
To: linux-o...@vger.kernel.org, linux-arm
he problem commit, until folks can
figure out the right long-term course of action.
Signed-off-by: Paul Walmsley
Cc: Mandeep Singh Baines
Cc: Jeff Layton
Cc: Shawn Guo
Cc:
Cc: Fengguang Wu
Cc: Trond Myklebust
Cc: Ingo Molnar
Cc: Ben Chan
Cc: Oleg Nesterov
Cc: Tejun Heo
Cc: Rafael J. Wy
On Wed, 13 Mar 2013, Jeff Layton wrote:
> Of course, this is all a lot of work, and not something we can shove
> into the kernel for 3.9 at this point. In the meantime, while Mandeep's
> warning is correctly pointing out a problem, I think we ought to back
> it out until we can fix this properly.
od assert/deassert
function, omap devices can call them through their platform data to
control their reset lines, they are expected to know the name of the
reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna
[p...@pwsan.com: tweaked some documentation; fixed CodingStyle is
Hello OMar,
On Mon, 16 Jul 2012, Omar Ramirez Luna wrote:
> For a reset sequence to complete cleanly, a module needs its
> associated clocks to be enabled, otherwise the timeout check
> in prcm code can print a false failure (failed to hardreset)
> that occurs because the clocks aren't powered ON
Hi
On Mon, 27 Aug 2012, Vaibhav Hiremath wrote:
> Currently, the device names for the dcan module follows the
> format "dcan.X", where 'X' is the dcan instance number.
> On other side, driver may request for clock with/without con_id
> and dev_id, and it is expected that platform should respect t
On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote:
> On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
>
> > Is the dcan driver present in v3.6-rc kernels?
>
> Multiple versions have been submitted already, I have validated using them.
> Irrespective of this, it is i
On Wed, 12 Sep 2012, Felipe Balbi wrote:
> On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
>
> > The bad news is that N800 no longer boots -- or the UART dies during
> > serial init:
> >
> > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d
rate
> handling for cases when clock framework is not available as
> the behaviour will stay the same.
>
> Note that we need to add a platform device to avoid using the
> i2c provided names that may be different on various omaps.
>
> Reported-by: Fengguang Wu
> Reported-b
On Mon, 17 Sep 2012, Tony Lindgren wrote:
> We need to queue this ASAP and before other patches to fix the
> build breakage in linux next. Then you can merge in that commit
> too, does that work for you?
That's fine, we'll just need a stable commit then that the CCF patches can
be based on.
-
1 - 100 of 786 matches
Mail list logo
