Hi Samuel, Liam, Tony,
Now rc2 is out, and the the OMAP4 audio is still broken.
Can you please queue this patch for 3.4?
The patch applies on top of mainline cleanly, and I also pushed a new
branch just in case:
The following changes since commit f549e088b806f44b6ab6eeef0cb71ced1d2488dd:
On Thursday 12 April 2012 08:30 AM, Greg KH wrote:
On Wed, Apr 11, 2012 at 08:44:39PM -0600, Paul Walmsley wrote:
Cc Mark Greer, Mark Salter
Hi Greg, Aneesh,
On Sat, 17 Mar 2012, Aneesh V wrote:
Add a driver for the EMIF SDRAM controller used in TI SoCs
EMIF is an SDRAM controller that
+ omap ml
Hi Jean, Andrew, Nicolas,
On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote:
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+ };
+
+ usart0:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc2.
Tested on omap5430evm with 3.1-custom kernel.
Hello Vaibhav,
On Fri, 30 Mar 2012, Vaibhav Hiremath wrote:
After some healthy discussion, now we have come to the conclusion and
decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is
different than OMAP3 and OMAP4 architecture.
Have been reviewing these patch sets here.
Hi Peter,
On Thu, Apr 12, 2012 at 09:39:28AM +0300, Peter Ujfalusi wrote:
Hi Samuel, Liam, Tony,
Now rc2 is out, and the the OMAP4 audio is still broken.
Can you please queue this patch for 3.4?
I'm busy this week, but I'll queue this one up beginning of next week. I have
several MFD fixes
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma
On 04/06/2012 05:24 AM, Chris Ball wrote:
Hi Paul,
On Thu, Apr 05 2012, Paul Walmsley wrote:
I'm really sorry for the long delay!
On Thu, 5 Apr 2012, Chris Ball wrote:
Thanks. Paul, just waiting for your Signed-off-by.
Signed-off-by: Paul Walmsley p...@pwsan.com
Thanks, no problem!
On Thursday 12 April 2012 03:13 PM, Tarun Kanti DebBarma wrote:
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context
On Fri, Mar 30, 2012 at 11:03:49AM -0500, Omar Ramirez Luna wrote:
'domain_destroy with devices attached' case isn't yet handled, instead
code assumes that the device was already detached.
If the domain is destroyed the hardware still has access to invalid
pointers to its page table and
Benoit,
On Monday 27 February 2012 04:02 PM, Santosh Shilimkar wrote:
Most of the OMAP4 control module register defines are not used and
can be removed. Keep only needed defines and move them to common
control module header just like other OMAP versions.
Signed-off-by: Santosh Shilimkar
On 2012-04-11 13:17, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network
performance on 3.3. For example, if I use TFTP to download a
Couple of patches on the ARMv7 cache code. First patch adds
v7_flush_dcache_by_level() API and second patch updates the setup
function to use the same.
R Sricharan (1):
ARM: mm: Add v7_flush_dcache_by_level() API.
Santosh Shilimkar (1):
ARM: mm: Flush only CPU local cache instead of all
From: R Sricharan r.sricha...@ti.com
On ARMv7 based SOC with an integrated L2 cache, there is a need
to have a flush API to operate on each cache level. In few low
power modes, L2 cache is retained where as L1 is lost. The current
v7_flush_dcache_all(), flushes all the levels and it would be
The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.
But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
The setup
On Thu, Apr 12, 2012 at 1:04 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few brief comments based on a quick scan:
On Wed, 11 Apr 2012, Raja, Govindraj wrote:
Here is the patch [1] to do the same.
- I don't see where it affects I/O wakeups for the UART. If I/O wakeups
are still set on
On 07:06 Thu 12 Apr , Mohammed, Afzal wrote:
+ omap ml
Hi Jean, Andrew, Nicolas,
On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote:
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+
Hi Jean,
On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
If ATMEL is also going driver way, then probably our voice together may be
heard and hopefully it will expedite the matter.
I'm going to add it too my idea was to create something similiar as the
pintrl
you
I have a problem with WLAN driver wl12xx and 3.4-rc2. I made tests both on
AM3517 + W7310 and Pandaboard. Both have wl1271 chip inside. Previous kernels
2.6.37 and 3.3-rc7 made no problem: I could associate with my AP and then reach
every host in my LAN. With 3.4-rc2 I can only associate, but
Hi Santosh,
On 4/12/2012 12:31 PM, Santosh Shilimkar wrote:
Benoit,
On Monday 27 February 2012 04:02 PM, Santosh Shilimkar wrote:
Most of the OMAP4 control module register defines are not used and
can be removed. Keep only needed defines and move them to common
control module header just like
Hi Paul,
On Thursday 12 April 2012 12:29 AM, Paul Walmsley wrote:
That approach sounds fine to me, but I don't think Fernando's patch will
help with I2C.. Since it uses a custom reset function omap_i2c_reset(),
the delay will actually need to go there.
While working on fixing this I stumbled
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not
Currently the i2c driver calls the pm_runtime_enable and never
the disable. This may cause a warning when pm_runtime_enable
checks for the count match.Attempting to fix the same by calling
pm_runtime_disable in the error and the remove path.
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
From: Tasslehoff Kjappfot tasskj...@gmail.com
i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again.
Move the errata handling to i2c_probe.
Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that
The patch series does the following
- Warn fixes if CONFIG_PM_RUNTIME is not selected.
- I2C register restore only if context if the context is lost
- Bus busy recovery mechanism.
- the reset is not done in init.
- Adds a patch to use devm_* functions
- Also checks the return type of the get_sync
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done
No functional change. Makes the read ready processing a separate
function. This is to avoid extremely long level of indentation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 86 +---
1 files changed, 45 insertions(+),
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D
In omap_i2c_remove we are accessing the I2C_CON register without
enabling the clocks. Fix the same by enabling the clocks and disabling
it.
This fixes the following crash.
[ 154.723022] [ cut here ]
[ 154.725677] WARNING: at
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we used drivers/misc.
Why not create it? I have no objection to that, it makes it more
obvious as to what this really is.
greg k-h
--
Hi Santosh,
just posted a series whose aim is the same, please have a look and
let's try to merge the two approaches.
On Thu, Apr 12, 2012 at 12:29:47PM +0100, Santosh Shilimkar wrote:
The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention
Hi Greg,
On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we used drivers/misc.
Why not create it? I have no objection to that,
On OMAP4+, the clkdm association is moved to hwmod while on older OMAPs'
its associated with a clk.
Hence look for a clkdm in both clk and hwmod and warn only when
its missing in both. Also fix the pr_warning() to print the correct
hwmod name.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
On 12:14 Thu 12 Apr , Mohammed, Afzal wrote:
Hi Jean,
On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
If ATMEL is also going driver way, then probably our voice together may be
heard and hopefully it will expedite the matter.
I'm going to add it too my
On Thu, Apr 12, 2012 at 01:34:15PM +, Mohammed, Afzal wrote:
Hi Greg,
On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we
Gary Thomas g...@mlbassoc.com writes:
On 2012-04-11 13:17, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network
performance on 3.3.
Hi Greg,
On Thu, Apr 12, 2012 at 19:40:50, Greg KH wrote:
There is another memory controller used in a few TI SoCs,
namely GPMC [1], do you prefer having it too there.
Sure, why not?
Thanks a lot, we were struggling to find a suitable location for the driver.
Regards
Afzal
--
To
On Thu, Apr 12, 2012 at 6:40 PM, Greg KH g...@kroah.com wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we used drivers/misc.
Why not create it? I have no objection to that,
Mohammed, Afzal af...@ti.com writes:
Hi Greg,
On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we used drivers/misc.
Why not
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of
On Thu, Apr 12, 2012 at 6:57 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
Hi Santosh,
just posted a series whose aim is the same, please have a look and
let's try to merge the two approaches.
Sure ...
On Thu, Apr 12, 2012 at 12:29:47PM +0100, Santosh Shilimkar wrote:
The ARMv7
On 2012-04-12 08:14, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-11 13:17, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing
Hello,
is SCCB (Serial camera control bus, Omnivision's I2C variant) supported
in the Linux driver for OMAP3?
more specifically, I'm looking at the 2-wire interface on the
beagleboard-xm camera expansion port
any plan to make it work?
thanks, regards, p.
--
Peter Meerwald
+43-664-218
+Felipe for EHCI question
Gary Thomas g...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71 seconds, so about 50% slower than on the 3.0 kernel. Applying the
second [unnamed] patch
Hi
On Thu, 12 Apr 2012, Mohammed, Afzal wrote:
On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we used drivers/misc.
Why
Hi
On Thu, 12 Apr 2012, Rajendra Nayak wrote:
On OMAP4+, the clkdm association is moved to hwmod while on older OMAPs'
its associated with a clk.
Sounds like this should be conditional based on the platform, then,
rather than weakening the warning for all platforms ?
Hence look for a clkdm
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71 seconds, so about 50% slower than on the 3.0
Hi Rajendra,
On Thu, 12 Apr 2012, Rajendra Nayak wrote:
On Thursday 12 April 2012 12:29 AM, Paul Walmsley wrote:
That approach sounds fine to me, but I don't think Fernando's patch will
help with I2C.. Since it uses a custom reset function omap_i2c_reset(),
the delay will actually need
Hello Tushar,
On Thu, 12 Apr 2012, Tushar Behera wrote:
With this patch, I continuously get following message on my console.
(Tested on Origen board, based on EXYNOS4210).
mmc0: Too large timeout requested for CMD25!
So, with this change, should we update sdhci_calc_timeout() also?
Gary Thomas g...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71
Hi,
On Thu, Apr 12 2012, Paul Walmsley wrote:
With this patch, I continuously get following message on my console.
(Tested on Origen board, based on EXYNOS4210).
mmc0: Too large timeout requested for CMD25!
So, with this change, should we update sdhci_calc_timeout() also?
Looks like
+ Felipe,
Hi Paul,
On 4/12/2012 7:00 PM, Paul Walmsley wrote:
Hi
On Thu, 12 Apr 2012, Mohammed, Afzal wrote:
On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
On 2012-04-12 12:08, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was.
Hi Benoît,
On Thu, 12 Apr 2012, Cousson, Benoit wrote:
The LPDDR2 spec does consider as well NVM (Non Volatile Memory), so I think we
should stick to driver/memory for EMIF.
Hmm good point!
So perhaps something like drivers/memory/dram/ for the SDRAM controllers,
and maybe
On 4/12/2012 9:15 PM, Paul Walmsley wrote:
Hi Benoît,
On Thu, 12 Apr 2012, Cousson, Benoit wrote:
The LPDDR2 spec does consider as well NVM (Non Volatile Memory), so I think we
should stick to driver/memory for EMIF.
Hmm good point!
So perhaps something like drivers/memory/dram/ for the
From: Konstantin Shlyakhovoy x0155...@ti.com
Subject: drivers/rtc/rtc-twl.c: use static register while reading time
RTC stores time and date in several registers. Due to the fact that these
registers can't be read instantaneously, there is a chance that reading
from counting registers gives an
Hi Greg,
On Wed, Apr 11, 2012 at 8:00 PM, Greg KH g...@kroah.com wrote:
On Wed, Apr 11, 2012 at 08:44:39PM -0600, Paul Walmsley wrote:
Cc Mark Greer, Mark Salter
Hi Greg, Aneesh,
On Sat, 17 Mar 2012, Aneesh V wrote:
Add a driver for the EMIF SDRAM controller used in TI SoCs
EMIF is
Gary Thomas g...@mlbassoc.com writes:
On 2012-04-12 12:08, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is
On Wed, Apr 11, 2012 at 08:29:51PM -0600, Paul Walmsley wrote:
On Wed, 11 Apr 2012, Mark A. Greer wrote:
Okay, I'll get rid of the commas (fwiw, gfx_sgx_3xxx_wkdeps[] has commas
in k.o, the others don't).
Okay thanks, that's just an oversight in the mainline data. If you're so
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Grazvydas Ignotas
Sent: Tuesday, April 10, 2012 7:30 PM
What I think is going on here is that omap_sram_idle() is taking too
much time because it's overhead is too large. I've added a counter
On Wed, Apr 11, 2012 at 04:36:25PM -0600, Paul Walmsley wrote:
Hi
just a few comments based on a quick look
On Wed, 11 Apr 2012, Mark A. Greer wrote:
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index 1f62f23..22aac4c 100644
---
On Wed, Apr 11, 2012 at 06:42:44PM -0500, Jon Hunter wrote:
Hi Mark,
On 04/11/2012 02:05 PM, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Currently in the OMAP3 code, cpu_idle() calls pm_idle(),
which is a function pointer set to omap3_pm_idle()).
omap3_pm_idle()
On 2012-04-12 16:03, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 12:08, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.comwrites:
[...]
This worked a
74 matches
Mail list logo
