This set makes changes related to the OCPIF_SWSUP_IDLE flag for DSS slave
interfaces. This is required since the clocks of these interfaces were changed
recently with the patches below for OMAP2, OMAP3 and OMAP4 respectively:
b8ac10d8b75843c9ddd6aadf70a0cdf8aa783659
ARM: OMAP2xxx: HWMOD: fix DSS
The clocks for all DSS slave interfaces were recently changed to dss_ick on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had dss_54m_fck as it's clock which couldn't be autoidled, and
hence the OCPIF_SWSUP_IDLE flag was needed.
Remove the OCPIF_SWSUP_IDLE
The clock for all DSS L3 slave interfaces had been recently changed to
dss_fck from l3_div_ck. dss_fck is an optional clock in DSS clock domain
which can't autoidle when enabled.
Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS hwmods so
that clock is explicitly enabled and
Hello Archit,
On Wed, 11 Apr 2012, Archit Taneja wrote:
If we compare how the slave clocks are enabled and disabled in _setup() and
_disable_clocks() respectively:
static int _setup(struct omap_hwmod *oh, void *data)
{
...
...
if (os-flags OCPIF_SWSUP_IDLE) {
Hi,
On Friday 13 April 2012 01:39 PM, Paul Walmsley wrote:
Hello Archit,
On Wed, 11 Apr 2012, Archit Taneja wrote:
If we compare how the slave clocks are enabled and disabled in _setup() and
_disable_clocks() respectively:
static int _setup(struct omap_hwmod *oh, void *data)
{
...
Hi Archit,
On 4/13/2012 10:21 AM, Archit Taneja wrote:
On Friday 13 April 2012 01:39 PM, Paul Walmsley wrote:
On Wed, 11 Apr 2012, Archit Taneja wrote:
...
dss_ick is the slave clock of all the dss hwmods on omap3. This
doesn't seem
to be right, does it?
It's not 100% right, but it was
Hi Archit,
On Fri, 13 Apr 2012, Archit Taneja wrote:
There were still some issues related to this, particularly on OMAP4, I have
posted a patch set to fix this just a while back.
Was looking at those. The first one, removing the OCPIF_SWSUP_IDLE flags,
makes sense to me. But as far as the
On 4/13/2012 10:01 AM, Archit Taneja wrote:
The clock for all DSS L3 slave interfaces had been recently changed to
dss_fck from l3_div_ck. dss_fck is an optional clock in DSS clock domain
which can't autoidle when enabled.
Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS
On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote:
On 4/13/2012 10:01 AM, Archit Taneja wrote:
The clock for all DSS L3 slave interfaces had been recently changed to
dss_fck from l3_div_ck. dss_fck is an optional clock in DSS
clock domain
which can't autoidle when enabled.
Add
Hi,
On Friday 13 April 2012 02:09 PM, Paul Walmsley wrote:
Hi Archit,
On Fri, 13 Apr 2012, Archit Taneja wrote:
There were still some issues related to this, particularly on OMAP4, I have
posted a patch set to fix this just a while back.
Was looking at those. The first one, removing the
On Thu, Apr 12, 2012 at 08:50:55PM +0200, Cousson, Benoit wrote:
+ 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
Hi,
On Thu, Apr 12, 2012 at 09:57:32AM -0700, Kevin Hilman wrote:
+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
Hi Paul,
While the patch did fix the issue for Anand, I guess it
was because of the additional delay post reset, waiting on the
RESETDONE bit and timing out, before accessing the i2c_con register.
I thought some more on this and the logic of the delay between the
SOFTRESET bit being set
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the existing 32k-sync timer implementation
without any major code
Add missing idle_st bit for 32k-sync timer into the prcm-common
header file, required for hwmod data.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
---
Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 3 hwmod table.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
---
This patch has been
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz)
On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote:
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
Can someone tell me how this works with the current omap-serial driver
please? It looks to me like this has been broken when DMA support was
added to the driver.
Moreover, please look at the probe function error paths. They seem to
be lacking any kind of realistic cleanup, so are a potential
Hi Vaibhav,
On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote:
Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here.
These patches have been reviewed and accepted in the list, only thing is
they couldn't make it to upstream during v3.4 merge window.
I believe Tony is going
Hi Rajendra,
thanks for the summary,
On Fri, 13 Apr 2012, Rajendra Nayak wrote:
Should I go ahead and send a revert for the -rc?
Thanks for the offer, I don't think it's needed -- I'll just build the
revert changelog here with your comments from your E-mail.
regards
- Paul
--
To
On Fri, 13 Apr 2012, Archit Taneja wrote:
The clocks for all DSS slave interfaces were recently changed to dss_ick on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had dss_54m_fck as it's clock which couldn't be autoidled, and
hence the OCPIF_SWSUP_IDLE
Hi Rajendra
here's what I've queued for v3.4-rc; please let me know if you have any
comments.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Fri, 13 Apr 2012 05:08:43 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod: Revert ARM: OMAP2+: hwmod: Make
omap_hwmod_softreset wait for reset status
This
On Fri, 13 Apr 2012, Paul Walmsley wrote:
On Fri, 13 Apr 2012, Archit Taneja wrote:
The clocks for all DSS slave interfaces were recently changed to dss_ick
on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had dss_54m_fck as it's clock which
On Sat, Apr 7, 2012 at 6:15 AM, Andrew Morton a...@linux-foundation.org wrote:
On Fri, 30 Mar 2012 19:58:16 +0800
Bryan Wu bryan...@canonical.com wrote:
Attempting to consolidate the ARM LED code, this removes the
custom RealView LED trigger code to turn LEDs on and off in
response to CPU
Hi,
On Friday 13 April 2012 04:54 PM, Paul Walmsley wrote:
On Fri, 13 Apr 2012, Paul Walmsley wrote:
On Fri, 13 Apr 2012, Archit Taneja wrote:
The clocks for all DSS slave interfaces were recently changed to dss_ick on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
On Friday 13 April 2012 04:52 PM, Paul Walmsley wrote:
Hi Rajendra
here's what I've queued for v3.4-rc; please let me know if you have any
comments.
Looks good, thanks Paul.
- Paul
From: Paul Walmsleyp...@pwsan.com
Date: Fri, 13 Apr 2012 05:08:43 -0600
Subject: [PATCH] ARM: OMAP2+:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e:
Linux 3.4-rc2 (2012-04-07 18:30:41 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending
On Wed, 2012-04-11 at 20:44 -0600, Paul Walmsley wrote:
This is useful not only for OMAP4 and AM3517/3505, but also will probably
be useful for the C6x chips that Mark Salter is working on.
I have been keeping an occasional eye on these patches but I don't see
any usefulness for the currently
Hello,
Does the 3.3.1 kernel provide decent power management and idle support?
How does it compare to the android kernels?
If 3.3.1 does not yet have good pm and idle support, is the 3.4-rc2
stable enough to use?
Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe
On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
While SD card performance loss is not that bad (~7%), NAND one is
The current serial UART code, while fidling with ocp idlemode bits,
forget about the smart idle wakeup bit even if it is supported by
UART IP block. This will lead to missing the module wakeup on OMAP's
where the smart idle wakeup is supported.
This was the root cause of the console sluggishness
I'm using linux-3.0 as released on ftp/kernel.org on an DM37x based
board, and I've run into sporadic cases where the init scripts exit with
illegal instruction when using a ramdisk as the rootfs:
[9.640838] VFS: Mounted root (ext2 filesystem) on device 1:0.
[9.647521] Freeing init
On Wed, Apr 04, 2012 at 03:20:22PM -0700, Kevin Hilman wrote:
Hi Dave,
On 03/26/2012 05:19 PM, Kevin Hilman wrote:
The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.
This 'depends on' was in the original patch from Russell King, but was
On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote:
It would be helpful now to narrow down what are the big contributors to
the overhead in omap_sram_idle(). Most of the code there is skipped for
C1 because the next states for MPU and CORE are both ON.
Ok I did some tests, all
The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.
This 'depends on' was in the original patch from Russell King, but was
erroneously removed by me when making this option user-selectable in
commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.)
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.
Thanks to Russell King for pointing out the parts
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Wed, Apr 04, 2012 at 03:20:22PM -0700, Kevin Hilman wrote:
Hi Dave,
On 03/26/2012 05:19 PM, Kevin Hilman wrote:
The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.
This 'depends on' was
Without runtime PM enabled, hwmod needs to leave all IP blocks in an
enabled state by default so any driver access to the HW will succeed.
This is accomplished by seting the postsetup_state to enabled for all
hwmods during init when runtime PM is disabled.
Currently, we have a special case for
This set of patches provides the foundation for enabling
OMAP4 Dsp (Tesla) as remote processor.
The first patch is a generic fix for mailbox in mach-omap2.
Without this patch, the irq for a mailbox instance other than
the first one is not properly enabled.
The second patch fixes the clock and
The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.
The enable_irq function should be called every time a
new mbox instance is created, in the generic
Irq and clock names were wrong for dsp iommu configuration
for omap4.
Renamed tesla_ick to dsp_fck.
Renamed INT_44XX_DSP_MMU to OMAP44XX_IRQ_TESLA_MMU.
dsp-iommu is enabled by default.
Signed-off-by: Juan Gutierrez jgutier...@ti.com
---
arch/arm/mach-omap2/omap-iommu.c | 6 ++
1 files
Some remote processors (like Omap4's DSP) need to explicitly
configure a boot address in a special register or memory
location, and this is the address from which they start
executing code when taken out of reset.
Support for this infrastructure has been added to remoteproc
code. The memory or
On Fri, 13 Apr 2012, Kevin Hilman wrote:
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.
Hi,
* Kevin Hilman khil...@ti.com [120413 13:54]:
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not
Gutierrez, Juan jgutier...@ti.com writes:
This set of patches provides the foundation for enabling
OMAP4 Dsp (Tesla) as remote processor.
Looks like this series suffers from space/tab and various whitespace
problems.
Please run them through scripts/checkpatch.pl, or possibly your mailer
is
Hi Kevin
Yes, I ran the checkpatch, but I indeed had some problems sending the
patches to the list :(
so I edited the patch directly in the mailer. I will try one more time
with git send-email
On Fri, Apr 13, 2012 at 6:02 PM, Kevin Hilman khil...@ti.com wrote:
Gutierrez, Juan jgutier...@ti.com
On Tue, Apr 10, 2012 at 6:40 AM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused
On Wed, Apr 11, 2012 at 4:50 AM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Tue, Apr 10, 2012 at 9:41 PM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120410 06:44]:
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,11 +120,63 @@
This set of patches provides the foundation for enabling
OMAP4 Dsp (Tesla) as remote processor.
The first patch is a generic fix for mailbox in mach-omap2.
Without this patch, the irq for a mailbox instance other than
the first one is not properly enabled.
The second patch fixes the clock and
The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.
The enable_irq function should be called every time a
new mbox instance is created, in the generic
Irq and clock names were wrong for dsp iommu configuration
for omap4.
Renamed tesla_ick to dsp_fck.
Renamed INT_44XX_DSP_MMU to OMAP44XX_IRQ_TESLA_MMU.
dsp-iommu is enabled by default.
Signed-off-by: Juan Gutierrez jgutier...@ti.com
---
arch/arm/mach-omap2/omap-iommu.c |6 ++
1 files
Some remote processors (like Omap4's DSP) need to explicitly
configure a boot address in a special register or memory
location, and this is the address from which they start
executing code when taken out of reset.
Support for this infrastructure has been added to remoteproc
code. The memory or
53 matches
Mail list logo
