With the legacy clock data gone, this is no longer needed under platform,
so move it under the clock driver itself. Remove unnecessary declarations
from the TI clock header also.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/clock34xx.c | 138
With the legacy clock data gone, this is no longer needed under platform,
so move it under the clock driver itself. Remove unnecessary declarations
from the TI clock header also.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/clock34xx.c | 138
On Thu 2015-02-26 14:50:00, Pali Rohár wrote:
> These files are not used by any DTS file anymore.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> ---
> arch/arm/boot/dts/omap34xx-hs.dtsi | 12
> arch/arm/boot/dts/omap36xx-hs.dtsi | 12
These files are not used by any DTS file anymore.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap34xx-hs.dtsi | 12
arch/arm/boot/dts/omap36xx-hs.dtsi | 12
2 files changed, 24 deletions(-)
delete mode 100644 arch/arm/boot/dts/omap34xx-hs.dtsi
delete mode
On Fri 2014-12-26 13:34:54, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the
> syscon area, which can be used to determine the SoCs temperature.
>
> Signed-off-by: Sebastian Reichel
Acked-by: Pavel Machek
Tested-by: Pavel Machek
Driver bi
* Pali Rohár [141226 08:29]:
> On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> > > > +
> > > > +#include "../../arch/arm/mach-omap2/control.h"
> > >
> > > No need to do this, you can use syscon here like
> > > pbias-regulator.c is doing.
> >
> > Oh looks like you're already using sysc
On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
> * Tony Lindgren [141226 07:57]:
> > * Pavel Machek [141226 02:32]:
> > > --- /dev/null
> > > +++ b/drivers/hwmon/omap34xx_temp.c
> > > @@ -0,0 +1,263 @@
> > > +/*
> > >
* Tony Lindgren [141226 07:57]:
> * Pavel Machek [141226 02:32]:
> > --- /dev/null
> > +++ b/drivers/hwmon/omap34xx_temp.c
> > @@ -0,0 +1,263 @@
> > +/*
> > + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> > + *
>
* Pavel Machek [141226 02:32]:
> --- /dev/null
> +++ b/drivers/hwmon/omap34xx_temp.c
> @@ -0,0 +1,263 @@
> +/*
> + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Wr
OMAP34xx and OMAP36xx processors contain a register in the
syscon area, which can be used to determine the SoCs temperature.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/omap34xx.dtsi | 7 +++
arch/arm/boot/dts/omap36xx.dtsi | 7 +++
2 files changed, 14 insertions(+)
diff
ot;TI OMAP34xx internal temperature sensor"
+ depends on ARCH_OMAP3 && HIGH_RES_TIMERS
+
config HWMON_DEBUG_CHIP
bool "Hardware Monitoring Chip debugging messages"
default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5c3b5d
* Jeremy Vial [140731 06:16]:
> Hi,
>
> My kernel crashed when my OMAP34xx ES3.1.2 leave suspend mode. The first
> patch seems to solve the issue, and the second one corrects Linux kernel
> coding style problems.
>
> Jeremy Vial (2):
> ARM: OMAP3: Fix choice of omap
According to the comment “restore_es3: applies to 34xx >= ES3.0" in
"arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used
if the revision of an OMAP34xx is ES3.1.2.
Signed-off-by: Jeremy Vial
---
arch/arm/mach-omap2/control.c |3 ++-
1 file changed, 2 insertions(+
Hi,
My kernel crashed when my OMAP34xx ES3.1.2 leave suspend mode. The first
patch seems to solve the issue, and the second one corrects Linux kernel
coding style problems.
Jeremy Vial (2):
ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX
rev3.1.2 case.
ARM: OMAP3: Fix
Add DT OPP table for OMAP34xx/35xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
OPP data here is based on existing opp3xxx_data.c
Since the omap36xx OPP tables would be different from OMAP34xx/35xx,
introduce an new omap34xx.dtsi for 34xx/35xx specific
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> Add DT OPP table for OMAP34xx family of devices. This data is
> decoded by OF with of_init_opp_table() helper function.
>
> This is in preparation to use generic cpu0-cpufreq driver.
No mention here about what you are removing ;-
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc:
Is there any source for code that generates a 3-byte subpage ECC that
matches the ECC the bootrom is expecting when reading bootloader code
out of the first block of NAND?
I'm dealing with a problem of the Micron MT46H256M32L4K1-5 that has a
in-chip BCH ECC engine on our boards where a reset doesn
The offset of WKUP_MOD is not right for the PRM_RSTST of OMAP3. So here
put the right one to match to the actual physical addr 0x48307258, which
defined in PRCM Registers section named as Global_Reg_PRM.
And there is a MPU_WD_RST bit in PRM_RSTST(0x48307258) holding the signal
from omap-wdt reboot
The offset of WKUP_MOD is not right for the PRM_RSTST of OMAP3. So here
put the right one to match to the actual physical addr 0x48307258, which
defined in PRCM Registers section named as Global_Reg_PRM.
And there is a MPU_WD_RST bit in PRM_RSTST(0x48307258) holding the signal
from omap-wdt reboot
On Thursday 05 April 2012 02:19 PM, Russell King - ARM Linux wrote:
On Thu, Apr 05, 2012 at 02:04:41PM +0530, Archit Taneja wrote:
We figured out the culprit patch, reverting this prevents the issue:
commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237
Author: Archit Taneja
Date: Fri Oct 7 03:08:4
On Thu, Apr 05, 2012 at 02:04:41PM +0530, Archit Taneja wrote:
> We figured out the culprit patch, reverting this prevents the issue:
>
> commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237
> Author: Archit Taneja
> Date: Fri Oct 7 03:08:44 2011 -0600
>
> ARM: OMAP: ctrl: Fix CONTROL_DSIPHY regi
Hi,
On Thursday 05 April 2012 01:54 PM, Russell King - ARM Linux wrote:
On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote:
On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
Hi,
On Sunday 05 February
On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote:
> On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
>> On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
>>> Hi,
>>>
>>> On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
Okay, so
From: "Govindraj.R"
Minor cleanup, replace all omap34xx/omap44xx cpu checks with
cpu is not omap24xx check.
Cc: Paul Walmsley
Cc: Felipe Balbi
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git
On Wed, 2012-02-15 at 17:28 -0800, Kevin Hilman wrote:
> NeilBrown writes:
>
> > On Wed, 15 Feb 2012 16:13:02 -0800 Kevin Hilman
> >
> > wrote:
> >
> >> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> >> > Luciano Coelho writes:
> >> >
> >> > [...]
> >> >
> >> >> I just tried this on my Panda a
Hi Kevin,
On Wed, 2012-02-15 at 16:13 -0800, Kevin Hilman wrote:
> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> > Luciano Coelho writes:
> >
> > [...]
> >
> >> I just tried this on my Panda and I keep getting this kind of BUGs. It
> >> spams my console so much that is pretty much unusable:
> >
Russell King - ARM Linux writes:
> On Sun, Feb 12, 2012 at 10:41:32AM +, Russell King - ARM Linux wrote:
>> Another issue (through lower priority) is this:
>>
>> twl-common.c:(.init.text+0x2e48): undefined reference to
>> `omap34xx_vddmpu_volt_data'
>> twl-common.c:(.init.text+0x2e4c): unde
NeilBrown writes:
> On Wed, 15 Feb 2012 16:13:02 -0800 Kevin Hilman
> wrote:
>
>> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
>> > Luciano Coelho writes:
>> >
>> > [...]
>> >
>> >> I just tried this on my Panda and I keep getting this kind of BUGs. It
>> >> spams my console so much that is pre
On Wed, 15 Feb 2012 16:13:02 -0800 Kevin Hilman
wrote:
> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> > Luciano Coelho writes:
> >
> > [...]
> >
> >> I just tried this on my Panda and I keep getting this kind of BUGs. It
> >> spams my console so much that is pretty much unusable:
> >>
> >> [
On 02/15/2012 03:54 PM, Kevin Hilman wrote:
Luciano Coelho writes:
[...]
I just tried this on my Panda and I keep getting this kind of BUGs. It
spams my console so much that is pretty much unusable:
[ 336.172302] BUG: sleeping function called from invalid context at
include/linux/freezer.
Luciano Coelho writes:
[...]
> I just tried this on my Panda and I keep getting this kind of BUGs. It
> spams my console so much that is pretty much unusable:
>
> [ 336.172302] BUG: sleeping function called from invalid context at
> include/linux/freezer.h:46
> [ 336
On Mon, 13 Feb 2012, Shubhrajyoti wrote:
> Boot tested on omap4430 sdp.
Thanks Shubhrajyoti! Added your Tested-by.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
On Thu, Feb 9, 2012 at 2:47 AM, Greg KH wrote:
> Show me an OMAP user that actually runs a mainline kernel :)
I haven't used anything but mainline kernel since years when I test
stuff on my Nokia N900.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe lin
On Sun, Feb 12, 2012 at 10:41:32AM +, Russell King - ARM Linux wrote:
> Another issue (through lower priority) is this:
>
> twl-common.c:(.init.text+0x2e48): undefined reference to
> `omap34xx_vddmpu_volt_data'
> twl-common.c:(.init.text+0x2e4c): undefined reference to
> `omap34xx_vddcore_vo
On Tue, 14 Feb 2012, Felipe Balbi wrote:
> Hi,
>
> On Thu, Feb 09, 2012 at 11:34:42AM -0800, Rex Feany wrote:
> > I also get these warnings when compiling:
> >
> > CC arch/arm/mach-omap2/usb-host.o
> > arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init':
> > arch/arm/mach-omap2/usb-h
Hi,
On Thu, Feb 09, 2012 at 11:34:42AM -0800, Rex Feany wrote:
> I also get these warnings when compiling:
>
> CC arch/arm/mach-omap2/usb-host.o
> arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init':
> arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible
> pointe
* Tony Lindgren [120213 12:46]:
>
> Got the compiler build going further with the following fix to
> crosstool-ng in case others are having similar issues. Will send
> that separately to crosstool-ng mailing list.
Looks like that's already in works according to this:
http://sourceware.org/ml/cr
Hi,
* Tony Lindgren [120207 21:01]:
> * Russell King - ARM Linux [120207 01:39]:
> > On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> > > FYI, I'm now seeing the same warning as Igor posted with
> > > omap2plus_defconfig using the same compiler as Igor:
> > >
> > > gcc version 4
* Russell King - ARM Linux [120212 03:13]:
> Here's another issue which kautobuildv2 just found, as I've now added
> randconfig to the suite of OMAP4430 SDP builds. Obviously, as it's
> using a different configuration each time, it's going to find different
> issues on each run.
>
> For this, th
Thus spake Tony Lindgren (t...@atomide.com):
> * Paul Walmsley [120209 17:48]:
> >
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> > testing branch; it works.
>
> Rex, care to confirm this is also the case for you with
> your custom .config?
Yes, it works. Thanks
On Monday 13 February 2012 12:42 AM, Paul Walmsley wrote:
> Hi
>
> On Sun, 12 Feb 2012, Russell King - ARM Linux wrote:
>
>> The other allnoconfig issue is:
>>
>> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to
>> `omap_i2c_reset'
>>
>> which looks like hwmod can't cope with
Hi
On Sun, 12 Feb 2012, Russell King - ARM Linux wrote:
> The other allnoconfig issue is:
>
> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to
> `omap_i2c_reset'
>
> which looks like hwmod can't cope with the I2C_OMAP being disabled.
>
> I don't propose these are fixed fo
Here's another issue which kautobuildv2 just found, as I've now added
randconfig to the suite of OMAP4430 SDP builds. Obviously, as it's
using a different configuration each time, it's going to find different
issues on each run.
For this, the seed config has the following extra lines compared wit
Another issue (through lower priority) is this:
twl-common.c:(.init.text+0x2e48): undefined reference to
`omap34xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e4c): undefined reference to
`omap34xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2e5c): undefined reference to
`omap36xx_vddmpu_vo
Hello Matt, Vaibhav,
On Fri, 10 Feb 2012, Matt Porter wrote:
> On Thu, Feb 09, 2012 at 07:19:47PM -0700, Paul Walmsley wrote:
> >
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> > testing branch; it works.
>
> Regarding the issue that Vaibhav reported with:
>
> "
On Fri, Feb 10, 2012 at 01:53:12PM +0200, Grazvydas Ignotas wrote:
> On Thu, Feb 9, 2012 at 8:36 PM, Tony Lindgren wrote:
> > Please everybody using omaps with mainline give a test for the
> > merge of the various fixes planned. I've done a branch with
> > v3.3-rc3 + Russell's fixes + Paul's seria
* Paul Walmsley [120209 17:48]:
>
> Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> testing branch; it works.
Rex, care to confirm this is also the case for you with
your custom .config?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux
On Thu, Feb 09, 2012 at 07:19:47PM -0700, Paul Walmsley wrote:
>
> Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> testing branch; it works.
Regarding the issue that Vaibhav reported with:
"omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck"
I also see it on m
On Fri, Feb 10, 2012 at 19:49:57, Paul Walmsley wrote:
> Hi
>
> On Fri, 10 Feb 2012, Hiremath, Vaibhav wrote:
>
> > On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> > >
> > > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> > > testing branch; it works.
> > >
>
On Fri, Feb 10, 2012 at 07:10:06AM +, Hiremath, Vaibhav wrote:
> On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> >
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> > testing branch; it works.
> >
>
> I tried it on AM37x EVM, it did worked for me but I h
Hi
On Fri, 10 Feb 2012, Hiremath, Vaibhav wrote:
> On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> >
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> > testing branch; it works.
> >
>
> I tried it on AM37x EVM, it did worked for me but I have some observa
On Thu, Feb 9, 2012 at 8:36 PM, Tony Lindgren wrote:
> Please everybody using omaps with mainline give a test for the
> merge of the various fixes planned. I've done a branch with
> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
> that I've queued up.
Seems to be good on pandora wi
On Wed, Feb 08, 2012 at 09:45:58AM +, Russell King - ARM Linux wrote:
> On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > Víctor M. Jáquez L. writes:
> > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > v3.3-rc2
> >
> > Great, thanks. Can you share
On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
>
> Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
> testing branch; it works.
>
I tried it on AM37x EVM, it did worked for me but I have some observations,
1) [root@arago /]# cat /tmp/pm_debug/count
usbhost_pwrdm
On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
Hi,
On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
Okay, so this requires backlight support, and TAAL selected, so that sorts
that error, bu
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
Thus spake Kevin Hilman (khil...@ti.com):
> Can you double check that you're building and booting using Tony's -rc3
> based branch?
I believe so, but I cloned it again anyway and it is different from what
I had originally.
> Also, can you do a test using omap2plus_defconfig?
Of course! Serial s
On Thu, 9 Feb 2012, Paul Walmsley wrote:
> Yeah, that one is PM related. If mach-omap2/pm24xx.c is hacked to only
> enter MPU retention, rather than full chip retention, it works (quick hack
> below). I suspect it is due to the lack of wakeup support in OMAP2 PM,
> but of course it could be s
Rex Feany writes:
> Thus spake Tony Lindgren (t...@atomide.com):
>
>> Please everybody using omaps with mainline give a test for the
>> merge of the various fixes planned. I've done a branch with
>> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
>> that I've queued up.
>>
>> If yo
On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
> Hi,
>
> On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
>> Okay, so this requires backlight support, and TAAL selected, so that sorts
>> that error, but causes others:
>>
>> taal display0: taal panel revision e3.8
On Thu, 9 Feb 2012, Tony Lindgren wrote:
> * Tony Lindgren [120209 10:05]:
> >
> > This fixes the various build and boot issues with custom .configs
> > that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial
> > console issues. And it fixes booting with DT to minimal enviroment.
>
Thus spake Tony Lindgren (t...@atomide.com):
> Please everybody using omaps with mainline give a test for the
> merge of the various fixes planned. I've done a branch with
> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
> that I've queued up.
>
> If you still see problems with com
* Tony Lindgren [120209 10:05]:
>
> This fixes the various build and boot issues with custom .configs
> that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial
> console issues. And it fixes booting with DT to minimal enviroment.
Looks like the serial console is still insanely slow
On Wed, Feb 08, 2012 at 05:39:28PM -0800, Kevin Hilman wrote:
> Greg KH writes:
>
> > What changeset(s) do you want me to take from my tty-next tree and put
> > it in the tty-linus tree to be merged for the 3.3-final timeframe?
>
> 6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is i
* Mark Brown [120209 05:06]:
> On Thu, Feb 09, 2012 at 09:25:36AM +0200, Jarkko Nikula wrote:
> > On 02/09/2012 02:47 AM, Greg KH wrote:
> > > Show me an OMAP user that actually runs a mainline kernel :)
>
> > I guess pretty much all these days? Most error reports what I recall
> > seeing during
On Thu, Feb 09, 2012 at 09:25:36AM +0200, Jarkko Nikula wrote:
> On 02/09/2012 02:47 AM, Greg KH wrote:
> > Show me an OMAP user that actually runs a mainline kernel :)
> I guess pretty much all these days? Most error reports what I recall
> seeing during past 2-3 years are from mainline kernel an
On 02/09/2012 02:47 AM, Greg KH wrote:
> Show me an OMAP user that actually runs a mainline kernel :)
>
I guess pretty much all these days? Most error reports what I recall
seeing during past 2-3 years are from mainline kernel and not that much
from linux-omap or some board support package kernel.
Hi,
On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
On Sun, Feb 05, 2012 at 12:56:26PM +, Russell King - ARM Linux wrote:
And here's another (set of) problem(s) on the 4430SDP board once the
previous have been worked around:
omap_hwmod: l3_div_ck: missing clockdomain f
On Feb 8, 2012, at 6:47 PM, "Greg KH" wrote:
> On Wed, Feb 08, 2012 at 05:14:18PM -0700, Paul Walmsley wrote:
>> Hi Greg
>>
>> was just directed at this thread:
>>
>> On Wed, 8 Feb 2012, Greg KH wrote:
>>
>>> Don't send me anything, saying it needs to get into the -rc merge
>>> window, that
Greg KH writes:
> What changeset(s) do you want me to take from my tty-next tree and put
> it in the tty-linus tree to be merged for the 3.3-final timeframe?
6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in microseconds,
edbe5db tty: serial: OMAP: block idle while the UART is t
On Wed, Feb 08, 2012 at 05:14:18PM -0700, Paul Walmsley wrote:
> Hi Greg
>
> was just directed at this thread:
>
> On Wed, 8 Feb 2012, Greg KH wrote:
>
> > Don't send me anything, saying it needs to get into the -rc merge
> > window, that you don't actually want to see merged. Otherwise, how l
Hi Greg
was just directed at this thread:
On Wed, 8 Feb 2012, Greg KH wrote:
> Don't send me anything, saying it needs to get into the -rc merge
> window, that you don't actually want to see merged. Otherwise, how long
> am I supposed to know to wait? That's just looney.
We did want to see
On Wed, Feb 08, 2012 at 11:53:27AM -0800, Greg KH wrote:
> On Wed, Feb 08, 2012 at 07:23:34PM +0200, Grazvydas Ignotas wrote:
> > On Wed, Feb 8, 2012 at 7:06 PM, Greg KH wrote:
> > > On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
> > >> Grazvydas Ignotas writes:
> > >>
> > >> > On
* Russell King - ARM Linux [120208 14:39]:
> On Wed, Feb 08, 2012 at 11:55:30AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [120208 01:15]:
> > > On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > > > Víctor M. Jáquez L. writes:
> > > > > If it helps, I observed the
On Wed, Feb 08, 2012 at 03:03:19PM -0800, Kevin Hilman wrote:
> Hi Greg,
>
> Greg KH writes:
>
> [...]
>
> >> It would look to me like they are queued for 3.4 but Kevin says there
> >> were intended for 3.3-rc.
> >
> > Kevin might have wished they would go into 3.3, but given that the first
> >
On Wed, Feb 08, 2012 at 11:55:30AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [120208 01:15]:
> > On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > > Víctor M. Jáquez L. writes:
> > > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > > v3.3
Hi Greg,
Greg KH writes:
[...]
>> It would look to me like they are queued for 3.4 but Kevin says there
>> were intended for 3.3-rc.
>
> Kevin might have wished they would go into 3.3, but given that the first
> round of these patches had to be reverted, I thought it safer to wait
> for 3.4.
S
On Wed, Feb 08, 2012 at 07:23:34PM +0200, Grazvydas Ignotas wrote:
> On Wed, Feb 8, 2012 at 7:06 PM, Greg KH wrote:
> > On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
> >> Grazvydas Ignotas writes:
> >>
> >> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman wrote:
> >> >> Kevin Hilma
* Russell King - ARM Linux [120208 01:15]:
> On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > Víctor M. Jáquez L. writes:
> > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > v3.3-rc2
> >
> > Great, thanks. Can you share your ~/.config?
>
> If it he
On 2/7/2012 9:41 AM, Russell King - ARM Linux wrote:
On Tue, Feb 07, 2012 at 01:54:57AM +0100, Cousson, Benoit wrote:
Hi Russell,
On 2/7/2012 1:24 AM, Russell King - ARM Linux wrote:
On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
In theory that patch should not be even neede
On Wed, Feb 8, 2012 at 7:06 PM, Greg KH wrote:
> On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
>> Grazvydas Ignotas writes:
>>
>> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman wrote:
>> >> Kevin Hilman writes:
>> >>
>> >>> This one is indeed strange. I have not seen this on th
On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
> Grazvydas Ignotas writes:
>
> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman wrote:
> >> Kevin Hilman writes:
> >>
> >>> This one is indeed strange. I have not seen this on the 34xx devices
> >>> I'm using (3430/n900, 3530/Overo,
Grazvydas Ignotas writes:
> On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman wrote:
>> Kevin Hilman writes:
>>
>>> This one is indeed strange. I have not seen this on the 34xx devices
>>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
>>
>> OK, I've reproduced this on v3.3-rc2.
>>
>> The reason I
Hi Mark,
On 2/7/2012 6:28 PM, Mark Brown wrote:
On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
The twl changes were done like that because it was assuming that
USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
platforms at 3.3 time. The whole point of doin
On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman wrote:
> Kevin Hilman writes:
>
>> Tony Lindgren writes:
>>
>> [...]
>>
Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
while in some of the deeper low power modes.
I tried reverting the rest of the patches
On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> Víctor M. Jáquez L. writes:
> > If it helps, I observed the same issue in a beagleboard rev B6, with
> > v3.3-rc2
>
> Great, thanks. Can you share your ~/.config?
If it helps, ARM Kautobuild V2 is up and running (assuming I don't b
* Kevin Hilman [120207 13:38]:
> Russell King - ARM Linux writes:
>
> [...]
>
> > Another problem oopses the kernel at boot in the voltage domain code,
> > which I suspect this has never been boot tested on OMAP34xx CPUs:
> >
> > omap_vc_init_channel
* Russell King - ARM Linux [120207 01:39]:
> On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> > FYI, I'm now seeing the same warning as Igor posted with
> > omap2plus_defconfig using the same compiler as Igor:
> >
> > gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
> >
> > Stil
* Mark Brown [120207 08:57]:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>
> > The twl changes were done like that because it was assuming that
> > USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
> > platforms at 3.3 time. The whole point of doing that
Kevin Hilman writes:
> Tony Lindgren writes:
>
> [...]
>
>>> > > --- a/arch/arm/mach-omap2/pm34xx.c
>>> > > +++ b/arch/arm/mach-omap2/pm34xx.c
>>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>>> > > {
>>> > > local_fiq_disable();
>>> > >
>>> > > - if (omap_irq_pendin
On Tue, Feb 07, 2012 at 02:36:06PM -0800, Kevin Hilman wrote:
> Tony Lindgren writes:
>
> [...]
>
> >> > > --- a/arch/arm/mach-omap2/pm34xx.c
> >> > > +++ b/arch/arm/mach-omap2/pm34xx.c
> >> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
> >> > > {
> >> > >local_fiq_disable();
Tony Lindgren writes:
[...]
>> > > --- a/arch/arm/mach-omap2/pm34xx.c
>> > > +++ b/arch/arm/mach-omap2/pm34xx.c
>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>> > > {
>> > > local_fiq_disable();
>> > >
>> > > -if (omap_irq_pending())
>> > > +if (omap_irq_
Russell King - ARM Linux writes:
[...]
> Another problem oopses the kernel at boot in the voltage domain code,
> which I suspect this has never been boot tested on OMAP34xx CPUs:
>
> omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not
> populated.Hence canno
On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
> The twl changes were done like that because it was assuming that
> USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
> platforms at 3.3 time. The whole point of doing that was to reduce
> the ifdefery in every d
On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> FYI, I'm now seeing the same warning as Igor posted with
> omap2plus_defconfig using the same compiler as Igor:
>
> gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
>
> Still no other warnings though.
If you're not getting the twl
On Tue, Feb 07, 2012 at 06:26:52AM +0100, Cousson, Benoit wrote:
> Moreover, with Rob latest series, IRQ_DOMAIN will be enabled on every
> ARM platform, so the "depend IRQ_DOMAIN" that "fix" is removing right
> now will have to be added again once we will move that code to use
> genirq domain
On Tue, Feb 07, 2012 at 01:54:57AM +0100, Cousson, Benoit wrote:
> Hi Russell,
>
> On 2/7/2012 1:24 AM, Russell King - ARM Linux wrote:
>> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>>> In theory that patch should not be even needed.
>>
>> In theory that change is needed to fi
On 2/7/2012 5:35 AM, Grant Likely wrote:
On Mon, Feb 6, 2012 at 5:24 PM, Russell King - ARM Linux
wrote:
On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
In theory that patch should not be even needed.
In theory that change is needed to fix the obviously broken code which
is
On Mon, Feb 6, 2012 at 5:24 PM, Russell King - ARM Linux
wrote:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>> In theory that patch should not be even needed.
>
> In theory that change is needed to fix the obviously broken code which
> is there at the moment.
>
> So, irrespe
1 - 100 of 295 matches
Mail list logo
