On 4/6/2011 3:46 AM, Linus Walleij wrote:
2011/4/5 Santosh Shilimkar:
[Me]
(And third it will also eventually need to hook into the timer-based
delay framework that I think Nokia is working on to be really
useful, else all delays become unpredictable.)
Do you mean udelay()/mdelay() here ?
Y
On 4/6/2011 3:52 AM, Linus Walleij wrote:
2011/4/5 Santosh Shilimkar:
The only issue I see is the clock-events implemented using
local timers capabilities in low power modes. The local timers
won't be able wakeup CPU from DORMANT or OFF state and hence
you will need an additional wakeup capable
Hi,
On Wednesday 06 April 2011 07:25 AM, Juha Kuikka wrote:
Hi,
I am working on a custom board with DM3730 and a DSI panel and I have
a problem in powering on the DSI complex IO block.
The DSS DSI initialization fails with:
omapdss DSI: dsi_complexio_init
omapdss DSI error: complexio reset not
2011/4/1 Arnd Bergmann :
> On Friday 01 April 2011, Ingo Molnar wrote:
>> IMO the right answer is what Linus and Thomas outlined:
>>
>> 1) provide a small number of clean examples and clean abstractions
>> 2) to not pull new crap from that point on
>> 3) do this gradually but consistently
Hi Avik,
2011/4/5 Avik Sil :
> Even after using ioremapped addresses in omap_writel() I'm getting the oops.
> Can you please point me to the location in mainline, where these l3 clocks
> are enabled?
I guess you can find here:
l3_main_3_ick && l3_instr_ick: arch/arm/mach-omap2/clock44xx
Hi,
On Tue, Apr 5, 2011 at 9:10 PM, Avinash.H.M wrote:
> GPIO module expects the debounce clocks to be enabled during reset. It doesn't
> reset properly and timeouts are seen, if this clock isn't enabled during
> reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
> whic
On Tue, Apr 5, 2011 at 8:21 PM, Sarah Sharp
wrote:
> On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
>> On Mon, 4 Apr 2011, Greg KH wrote:
>>
>> > As I have seen this tangentally mentioned already a few times
>> > publically, I figured it warranted it's own announcement now.
>> >
>> >
Hi,
I am working on a custom board with DM3730 and a DSI panel and I have
a problem in powering on the DSI complex IO block.
The DSS DSI initialization fails with:
omapdss DSI: dsi_complexio_init
omapdss DSI error: complexio reset not done! <-- my own addition
omapdss DSI error: failed to set com
On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
> On Mon, 4 Apr 2011, Greg KH wrote:
>
> > As I have seen this tangentally mentioned already a few times
> > publically, I figured it warranted it's own announcement now.
> >
> > Linux has lost a great developer with the passing of David
2011/4/1 Linus Torvalds :
> If you have discoverable hardware, use it.
>
> But by "discoverable hardware" I mean something like PCI config
> cycles. IOW, real hardware features.
The ARM AMBA architecture actually has such a thing, or a
little of it, found in drivers/amba/bus.c.
Basically it requ
2011/4/5 Santosh Shilimkar :
> The only issue I see is the clock-events implemented using
> local timers capabilities in low power modes. The local timers
> won't be able wakeup CPU from DORMANT or OFF state and hence
> you will need an additional wakeup capable clock-event
> working together with
2011/4/5 Santosh Shilimkar :
> [Me]
>> (And third it will also eventually need to hook into the timer-based
>> delay framework that I think Nokia is working on to be really
>> useful, else all delays become unpredictable.)
>>
> Do you mean udelay()/mdelay() here ?
Yes. Stephen Boyd from Qualcomm h
Will the family be having a memorial service?
On Tue, Apr 5, 2011 at 12:07 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
>> On Mon, 4 Apr 2011, Greg KH wrote:
>>
>> > As I have seen this tangentally mentioned already a few times
>> > publically, I f
Hi,
On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
> On Mon, 4 Apr 2011, Greg KH wrote:
>
> > As I have seen this tangentally mentioned already a few times
> > publically, I figured it warranted it's own announcement now.
> >
> > Linux has lost a great developer with the passing of
"Avinash.H.M" writes:
> The i2c module has a special reset sequence. The sequence is
> - Disable the I2C.
> - Write to SOFTRESET bit.
> - Enable the I2C.
> - Poll on the RESETDONE bit.
> This sequence must be followed for i2c reset in omap2, omap3. The sequence is
> implemented as a function and
Guys:
David Brownell unknowingly inspired me to get involved in Linux as a
profession. I saw him as an individual working successfully on Free
and Open Software, and have made an effort to emulate his success for
over a decade now.
I deeply regret never taking the time to meet and thank him in
Vishwanath Sripathy writes:
[...]
> Yes..I am planning to remove these parameters being exposed to board file
> and keep only minimal things (like oscillator ramp and ramp down time) in
> boaord file. We should be able calculate these parameters based on these
> generic parameters.
[...]
> Yes
On Mon, 4 Apr 2011, Greg KH wrote:
> As I have seen this tangentally mentioned already a few times
> publically, I figured it warranted it's own announcement now.
>
> Linux has lost a great developer with the passing of David Brownell
> recently and he will be greatly missed.
David made contribu
Fix build failure introduced by commit
7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 (usb: musb: Idle path retention
and offmode support for OMAP3) when building without gadget
support.
CC drivers/usb/musb/omap2430.o
drivers/usb/musb/omap2430.c: In function ‘musb_otg_notifications’:
drivers/usb/
* Russell King - ARM Linux [110405 02:48]:
>
> I'd suggest holding fire on new stuff.
>
> We *absolutely* *must* show that we're taking Linus' complaint seriously
> and make headway towards consolidating some of the code. I don't see that
> activity as optional.
I agree.
> I've now made the
GPIO module expects the debounce clocks to be enabled during reset. It doesn't
reset properly and timeouts are seen, if this clock isn't enabled during
reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
which the debounce clocks are enabled during reset.
Cc: Rajendra Nay
Hi ,
The patches solve the reset timeouts seen in i2c and gpio modules while
booting omap2 and omap3.
version: v2
* For discussion on v1, please refer
http://www.spinics.net/lists/linux-omap/msg49483.html
* changes from v1:
- moved i2c specific things from hwmod files to i2c file
The i2c module has a special reset sequence. The sequence is
- Disable the I2C.
- Write to SOFTRESET bit.
- Enable the I2C.
- Poll on the RESETDONE bit.
This sequence must be followed for i2c reset in omap2, omap3. The sequence is
implemented as a function and the i2c_class is updated with the corr
Laurent Pinchart wrote:
> Hi Sakari,
Hi Laurent,
> On Tuesday 05 April 2011 11:03:21 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>
> [snip]
>
>>> Let me try to summarize the issue and the requirements.
>>>
>>> IOMMU support on OMAP platforms uses an OMAP-specific implementation,
>>> divided
On Tue, 2011-04-05 at 08:45 +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 05, 2011 at 12:10:24PM +0530, Santosh Shilimkar wrote:
> > The only issue I see is the clock-events implemented using
> > local timers capabilities in low power modes. The local timers
> > won't be able wakeup CPU from
On Tue, Apr 05, 2011 at 01:12:57PM +0200, Uwe Kleine-König wrote:
> ah, ok, makes sense and actually is consistent with my book.
> (After knowing what I search I found it. The rules are:
>
> - A signed type of rank less than int
>-> int
> - An unsigned type of rank less than int,
>all of
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Signed-off-by: Alexander Holler
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
On 4/5/2011 6:14 PM, Rajendra Nayak wrote:
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |3 +++
2 fi
Hi,
On Tue, Apr 05, 2011 at 03:59:32PM +0300, Ameya Palande wrote:
> On 04/05/2011 03:38 PM, ext Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Apr 05, 2011 at 03:34:08PM +0300, Ameya Palande wrote:
> >>>Exactly, adding a new feature. Let me put it this way: which bug or
> >>>regression are you fixing
Hi Felipe,
On 04/05/2011 03:38 PM, ext Felipe Balbi wrote:
Hi,
On Tue, Apr 05, 2011 at 03:34:08PM +0300, Ameya Palande wrote:
Exactly, adding a new feature. Let me put it this way: which bug or
regression are you fixing with this patch ?
I never claimed that it is fixing a bug/regression ;)
Hi Paul,
On 4/4/2011 12:17 PM, Paul Walmsley wrote:
On Fri, 1 Apr 2011, Rajendra Nayak wrote:
On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
In omap_hwmod.c:_enable(), what do you think about:
1. saving the current idle mode of the clockdomain,
2. forcing the clockdomain to software-supervised
The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains should be idled
post a state_switch *only* if idle transitions on the
sleep_switch which is initialised to 0 in omap_set_pwrdm_state
happens to be a valid sleep_switch type (FORCEWAKEUP_SWITCH)
which are defined as
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH1
This causes the function to wrongly program some clock domains
even when the Powerdom
This series fixes a few issues in the clockdomain
state programming done as part of the omap_set_pwrdm_state()
function.
More details on the issues can be found in the discussions
below
http://marc.info/?l=linux-arm-kernel&m=130189971726452&w=2
Doing this requires adding additional api's in the
cl
Add the SoC specific implemention for clkdm_is_idle
for OMAP2/3 and OMAP4.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 12
arch/arm/mach-omap2/clockdomain44xx.c |7 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |3 +++
2 files changed, 24 insertions(+), 0 deletions(-)
Hi,
On Tue, Apr 05, 2011 at 03:34:08PM +0300, Ameya Palande wrote:
> >Exactly, adding a new feature. Let me put it this way: which bug or
> >regression are you fixing with this patch ?
>
> I never claimed that it is fixing a bug/regression ;)
but you want this go into the RC cycle, which is stri
On 04/05/2011 03:30 PM, ext Felipe Balbi wrote:
On Tue, Apr 05, 2011 at 03:23:12PM +0300, Ameya Palande wrote:
On 04/05/2011 03:19 PM, ext Felipe Balbi wrote:
On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:
Hi Tony,
On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
* Sebastian
On Tue, Apr 05, 2011 at 03:23:12PM +0300, Ameya Palande wrote:
> On 04/05/2011 03:19 PM, ext Felipe Balbi wrote:
> >On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:
> >>Hi Tony,
> >>
> >>On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
> >>>* Sebastian Reichel [110329 11:13]:
>
On 04/05/2011 03:19 PM, ext Felipe Balbi wrote:
On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:
Hi Tony,
On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
* Sebastian Reichel [110329 11:13]:
On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
* Sebastian Reichel
On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:
> Hi Tony,
>
> On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
> >* Sebastian Reichel [110329 11:13]:
> >>On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
> >>>* Sebastian Reichel [110329 10:26]:
> Is there any rea
Hi Tony,
On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
* Sebastian Reichel [110329 11:13]:
On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
* Sebastian Reichel [110329 10:26]:
Is there any reason, that the rx51 platform code does not support
the lp5523 chip? The chip driver
On Tue, Apr 05, 2011 at 03:00:11PM +0300, Ameya Palande wrote:
> Hi Felipe,
>
> On 03/31/2011 06:44 PM, ext Felipe Balbi wrote:
> >On Thu, Mar 31, 2011 at 06:30:32PM +0300, Ameya Palande wrote:
> >>Hi Felipe,
> >>
> >>On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>On Thu, Mar
On Fri, Apr 01, 2011 at 01:16:12PM +0300, Ameya Palande wrote:
> Signed-off-by: Ameya Palande
> Signed-off-by: Mathias Nyman
Reviewed-by: Felipe Balbi
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 66
> ++
> 1 files changed, 66 insertions(+), 0 deletions(-)
Hi Felipe,
On 03/31/2011 06:44 PM, ext Felipe Balbi wrote:
On Thu, Mar 31, 2011 at 06:30:32PM +0300, Ameya Palande wrote:
Hi Felipe,
On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:
Hi,
On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:
+static int rx51_lp5523_setup(void)
+{
+
On Tue, Apr 5, 2011 at 2:23 PM, Laurent Pinchart
wrote:
> Hi Sakari,
Hi Laurent, Sakari,
>
> On Tuesday 05 April 2011 11:03:21 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>
> [snip]
>
>> > Let me try to summarize the issue and the requirements.
>> >
>> > IOMMU support on OMAP platforms uses a
Hi Sakari,
On Tuesday 05 April 2011 11:03:21 Sakari Ailus wrote:
> Laurent Pinchart wrote:
[snip]
> > Let me try to summarize the issue and the requirements.
> >
> > IOMMU support on OMAP platforms uses an OMAP-specific implementation,
> > divided into 3 layers:
> >
> > - the IOVMM layer (arch
On Tue, Apr 05, 2011 at 10:01:00AM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 05, 2011 at 10:31:44AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > > > para
On Tuesday 05 April 2011 07:33 AM, Ming Lei wrote:
Hi,
2011/4/5 Avik Sil:
#define OMAP4430_CM_L3INSTR_L3_3_CLKCTRL
OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CORE_INST, 0x0720)
[...]
Should I use those identifier instead?
Yes, seems right, but you need to use the ioremap addresses of the identifiers.
linux-arm-kernel-boun...@lists.infradead.org schrieb am 05.04.2011
10:31:44:
> Von: Uwe Kleine-König
> An: Russell King - ARM Linux
> Kopie: rub...@unipv.it, kgene@samsung.com,
> eric.y.m...@gmail.com, ben-li...@fluff.org, t...@atomide.com, Jan
> Weitzel , linux-te...@vger.kernel.org, lin
Hello,
Am 04.04.2011 16:29, schrieb Alexander Holler:
it just happened here that the rechargeable backup battery for the RTC
on a TPS65950 run out off power, because of some days while the device
wasn't powered.
Afterwards I couldn't read or set the clock with hwclock using a kernel
2.6.37.n o
Hi,
On Tue, Apr 05, 2011 at 10:51:19AM +0100, Russell King - ARM Linux wrote:
> > I don't think Linus will like if we add yet another hwmod + clk data
> > file just for MCOP, so we need to re-use what's in tree.
>
> I'd suggest holding fire on new stuff.
>
> We *absolutely* *must* show that we'r
On Tue, Apr 05, 2011 at 12:36:57PM +0300, Felipe Balbi wrote:
> On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
> > From: Michael Fillinger
> >
> > MCOP is an FPGA-based Silicon Validation platform
> > which is used to test particular IPs inside OMAP
> > before we have a real ASIC.
On Tue, Apr 05, 2011 at 11:37 AM +0300, Felipe Balbi wrote:
> On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
> > From: Michael Fillinger
> >
> > MCOP is an FPGA-based Silicon Validation platform
> > which is used to test particular IPs inside OMAP
> > before we have a real ASIC.
>
On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
> From: Michael Fillinger
>
> MCOP is an FPGA-based Silicon Validation platform
> which is used to test particular IPs inside OMAP
> before we have a real ASIC.
>
> Signed-off-by: Michael Fillinger
>
> [ ba...@ti.com : few cleanups
From: Michael Fillinger
MCOP is an FPGA-based Silicon Validation platform
which is used to test particular IPs inside OMAP
before we have a real ASIC.
Signed-off-by: Michael Fillinger
[ ba...@ti.com : few cleanups here an there and also
removal of some unnecessary code. ]
Signed-off-b
On Fri, 2011-04-01 at 10:22 +0530, Nishanth Menon wrote:
> TWL6030 regulator dynamic operations such as those on vaux2 and vaux3
> were reported to be broken on platforms such as pandaboard(OMAP4).
> Digging deeper into the code, found that 6030 regulator support
> requires quiet a bit of fixes to
Laurent Pinchart wrote:
> Hi David,
Hi Laurent, David, others,
> On Wednesday 30 March 2011 17:50:17 David Cohen wrote:
>> On Wed, Mar 30, 2011 at 4:56 PM, Laurent Pinchart wrote:
>>> On Wednesday 30 March 2011 15:50:37 Sakari Ailus wrote:
Laurent Pinchart wrote:
> On Wednesday 30 March
On Tue, Apr 05, 2011 at 10:31:44AM +0200, Uwe Kleine-König wrote:
> On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > > parameter "u32 mask" type cast befor inversion
> s/befor/before/
>
> > Nak. I want a
On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > parameter "u32 mask" type cast befor inversion
s/befor/before/
> Nak. I want a 32-bit all ones quantity.
>
> unsigned long long vali = (unsigned short)~0;
parameter "u32 mask" type cast befor inversion
Signed-off-by: Jan Weitzel
---
arch/arm/mach-ixp4xx/common.c |4 ++--
arch/arm/mach-mmp/time.c |4 ++--
arch/arm/mach-omap1/time.c|4 ++--
arch/arm/mach-pxa/time.c |4 ++--
arch/arm/mach-
On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> parameter "u32 mask" type cast befor inversion
Nak. I want a 32-bit all ones quantity.
unsigned long long vali = (unsigned short)~0;
unsigned long long vall = ~(unsigned short)0;
compiles to:
vali:
.word 65535
.wo
On Tue, Apr 05, 2011 at 12:10:24PM +0530, Santosh Shilimkar wrote:
> The only issue I see is the clock-events implemented using
> local timers capabilities in low power modes. The local timers
> won't be able wakeup CPU from DORMANT or OFF state and hence
> you will need an additional wakeup capabl
On Mon, 2011-04-04 at 22:08 +0200, Linus Walleij wrote:
> 2011/4/4 Marc Zyngier :
> > On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote:
> >>
> >> If ARM are going to architect a set of timers into the hardware, let's
> >> make sure that all such hardware has them so we can dig ours
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Saturday, April 02, 2011 5:33 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer
> parameters
>
> Hi Vishwa,
>
> Vishwanath BS writes:
>
> > Volt
TI816X (common name for DM816x/C6A816x/AM389x family) devices configured to boot
as PCIe Endpoint have class code = 0. This makes kernel PCI bus code to skip
allocating BARs to these devices resulting into following type of error when
trying to enable them:
"Device :01:00.0 not available becau
66 matches
Mail list logo
