Hi Paul ,
Thanks for the review.
+/* In register I2C_CON, Bit 15 is the I2C enable bit */
+#define I2C_EN BIT(15)
+#define I2C_CON_OFFSET 0x24
This stuff, along with omap_i2c_reset(), doesn't belong in omap_hwmod.c,
which is common code
On 4/4/2011 8:59 PM, Catalin Marinas wrote:
On Fri, 2011-04-01 at 10:32 +0100, Santosh Shilimkar wrote:
The GIC register accesses today make use of readl()/writel()
which prove to be very expensive when used along with mandatory
barriers. This mandatory barriers also introduces an un-necessary
On 4/5/2011 1:38 AM, Linus Walleij wrote:
2011/4/4 Marc Zyngiermarc.zyng...@arm.com:
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 ourselves out
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
-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 vishwanath...@ti.com writes:
On Mon, 2011-04-04 at 22:08 +0200, Linus Walleij wrote:
2011/4/4 Marc Zyngier marc.zyng...@arm.com:
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
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 capable
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
.word
parameter u32 mask type cast befor inversion
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
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
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;
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 32-bit all
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 2011 10:16:56
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
From: Michael Fillinger m-fillin...@ti.com
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 m-fillin...@ti.com
[ ba...@ti.com : few cleanups here an there and also
removal of
On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
From: Michael Fillinger m-fillin...@ti.com
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 m-fillin...@ti.com
[
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 m-fillin...@ti.com
MCOP is an FPGA-based Silicon Validation platform
which is used to test particular IPs inside OMAP
before we have a real
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 m-fillin...@ti.com
MCOP is an FPGA-based Silicon Validation platform
which is used to test particular IPs inside OMAP
before we have a
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're
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
linux-arm-kernel-boun...@lists.infradead.org schrieb am 05.04.2011
10:31:44:
Von: Uwe Kleine-König u.kleine-koe...@pengutronix.de
An: Russell King - ARM Linux li...@arm.linux.org.uk
Kopie: rub...@unipv.it, kgene@samsung.com,
eric.y.m...@gmail.com, ben-li...@fluff.org, t...@atomide.com,
On Tuesday 05 April 2011 07:33 AM, Ming Lei wrote:
Hi,
2011/4/5 Avik Silavik...@linux.vnet.ibm.com:
#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
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:
parameter u32
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
On Tue, Apr 5, 2011 at 2:23 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com 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
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 Fri, Apr 01, 2011 at 01:16:12PM +0300, Ameya Palande wrote:
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Mathias Nyman mathias.ny...@nokia.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 66
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 31, 2011 at 04:38:12PM
Hi Tony,
On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
* Sebastian Reichels...@debian.org [110329 11:13]:
On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
* Sebastian Reichels...@debian.org [110329 10:26]:
Is there any reason, that the rx51 platform code does not support
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 Reichels...@debian.org [110329 11:13]:
On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
* Sebastian Reichels...@debian.org [110329 10:26]:
Is
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 Reichels...@debian.org [110329 11:13]:
On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren 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 Reichels...@debian.org [110329 11:13]:
On
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
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 strictly
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |3 +++
2 files changed, 24 insertions(+), 0
Add the SoC specific implemention for clkdm_is_idle
for OMAP2/3 and OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 12
arch/arm/mach-omap2/clockdomain44xx.c |7 +++
2 files changed, 19 insertions(+), 0 deletions(-)
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-kernelm=130189971726452w=2
Doing this requires adding additional api's in 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
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
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
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,
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 with this
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 Nayakrna...@ti.com
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
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 whose
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
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 into 3 layers:
-
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
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
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
* Russell King - ARM Linux li...@arm.linux.org.uk [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.
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’:
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
Vishwanath Sripathy vishwanath...@ti.com 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
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
Avinash.H.M avinas...@ti.com 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
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 David
Will the family be having a memorial service?
On Tue, Apr 5, 2011 at 12:07 PM, Felipe Balbi ba...@ti.com 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
2011/4/5 Santosh Shilimkar santosh.shilim...@ti.com:
[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
2011/4/5 Santosh Shilimkar santosh.shilim...@ti.com:
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
2011/4/1 Linus Torvalds torva...@linux-foundation.org:
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
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 Brownell
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
On Tue, Apr 5, 2011 at 8:21 PM, Sarah Sharp
sarah.a.sh...@linux.intel.com 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
Hi,
On Tue, Apr 5, 2011 at 9:10 PM, Avinash.H.M avinas...@ti.com 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
64 matches
Mail list logo
