arm registered cpufreq transition notifier to recalculate it.
Signed-off-by: Richard Zhao
Acked-by: Santosh Shilimkar
---
drivers/cpufreq/omap-cpufreq.c | 35 ---
1 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/d
If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different
arch has different per-cpu loops_per_jiffy definition.
Signed-off-by: Richard Zhao
Acked-by: Russell King
---
arch/arm/kernel/smp.c | 54 +
1 files changed, 54 insertions(+),
On Fri, 17 Feb 2012, Vaibhav Hiremath wrote:
> In case of AM33xx family of devices (like cpsw) have different sysc
> bit field offsets defined,
>
> sysc_type3:
> | 3 2 | 10 |
> | STDBYMODE | IDLEMODE |
>
> So introduce new sysc_type3 in omap_hwmod common data.
>
> Signed-off-by: Vai
Hi Vaibhav, Kevin,
On Fri, 30 Mar 2012, Vaibhav Hiremath wrote:
> Currently dummy voltage domain data is being created
> in order to succeed boot process, nothing has been done
> w.r.t actual hardware (voltage control).
>
> Also, hook up the AM33XX voltage domain to OMAP framework.
>
> Signed-o
Hi Vaibhav
On Wed, 21 Mar 2012, Vaibhav Hiremath wrote:
> Define AM33XX control register, in order to allow access to
> control register address space, also add CONTROL_SEC_CLK_CTRL
> register offset; both are required in clock tree data,
> for wdt0 and timer0 clock source select configuration.
>
On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote:
> On Thu, Apr 26, 2012 at 14:19:28, Paul Walmsley wrote:
> > looking at Table 1-1 "Device Features" of SPRUH73D, it seems that some
> > AM33xx family chips come with some features disabled, such as the
> > PRU-ICSS, the SGX, Ethernet, or USB. How wi
Tero Kristo writes:
> On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
[...]
>> > From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001
>> > From: Tero Kristo
>> > Date: Mon, 23 Apr 2012 12:14:46 +0300
>> > Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_
"Mark A. Greer" writes:
> On Thu, Apr 26, 2012 at 04:29:45PM -0700, Kevin Hilman wrote:
>
> Hi Kevin.
>
>> This is a rebased version of this series which is ready for broader
>> testing. I'd especially appreciate testing from those of you with
>> AM35x platforms.
>>
>> Currently, our SoC detect
Tarun Kanti DebBarma writes:
> Breaking commit: ab985f0f7c2c0ef90b7c832f0c04f470dda0593d
>
> Initialization of irqenable, irqstatus registers is the common
> operation done in this function for all OMAP platforms, viz.
> OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register
> was overwrit
On Thu, Apr 26, 2012 at 04:29:45PM -0700, Kevin Hilman wrote:
Hi Kevin.
> This is a rebased version of this series which is ready for broader
> testing. I'd especially appreciate testing from those of you with
> AM35x platforms.
>
> Currently, our SoC detection is based on SoC family detection
On Fri, Apr 27, 2012 at 3:57 PM, Kevin Hilman wrote:
> Grant Likely writes:
>
>> On Fri, 27 Apr 2012 19:43:30 +0530, Tarun Kanti DebBarma
>> wrote:
>>> Here are the remaining cleanup patches. There are broadly
>>> two categories of cleanups.
>>>
>>> Cat-1: Those missed while introducing new fea
NeilBrown writes:
> On Thu, 26 Apr 2012 13:39:07 -0700 Kevin Hilman wrote:
>
>> NeilBrown writes:
>>
>> > All interrupts can wake-from-sleep (I think) so it should be
>> > permissible to call enable_irq_wake(). Setting this flag allows that.
>> >
>> > It is needed because without this, an int
Grant Likely writes:
> On Fri, 27 Apr 2012 19:43:30 +0530, Tarun Kanti DebBarma
> wrote:
>> Here are the remaining cleanup patches. There are broadly
>> two categories of cleanups.
>>
>> Cat-1: Those missed while introducing new feature like SPARSE_IRQ
>>handling and DT support; use ed
On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote:
> "Mark A. Greer" writes:
>
> > On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote:
> > We could chose whether pm_idle & cpuidle issue a wfi based on
> > whether there is a davinci-emac present. The issue with that is
> >
On Fri, Apr 27, 2012 at 10:38:08PM +0200, Linus Walleij wrote:
> On Wed, Apr 18, 2012 at 12:19 PM, Russell King - ARM Linux
> wrote:
>
> > Oops, this patch wasn't supposed to be part of this set...
>
> ...however it gives me the impression that you have a patch set cooking
> to also switch PL08x
"DebBarma, Tarun Kanti" writes:
> On Wed, Apr 25, 2012 at 7:15 PM, Russell King - ARM Linux
> wrote:
[...]
>> Correction.
>>
>> Don't email your patch in any way to the stable folk _before_ it has been
>> taken into Linus' tree. However, you _may_ add in the patch attributations
>> a Cc: ta
On Fri, Apr 27, 2012 at 02:21:59PM -0700, Kevin Hilman wrote:
> "Mark A. Greer" writes:
>
> > From: "Mark A. Greer"
> >
> > The Chip Identification register on the am35x family of SoCs
> > has bits 12, 7:5, and 3:2 marked as reserved and are read as
> > zeroes. Unfortunately, on other omap SoCs
"Mark A. Greer" writes:
> From: "Mark A. Greer"
>
> The Chip Identification register on the am35x family of SoCs
> has bits 12, 7:5, and 3:2 marked as reserved and are read as
> zeroes. Unfortunately, on other omap SoCs, a 0 bit means a
> feature is "Full Use" so the OMAP3_CHECK_FEATURE() macro
"Mark A. Greer" writes:
> From: "Mark A. Greer"
>
> prcm_setup_regs() blindly accesses IVA bits
> in the PRM and calls omap3_iva_idle() which
> does more IVA related register accesses.
> Only do this if the IVA hardware actually
> exists.
>
> Signed-off-by: Mark A. Greer
Thanks, queuing for v3
On Thu, Apr 26, 2012 at 04:56:39PM -0600, Paul Walmsley wrote:
> On Thu, 19 Apr 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer"
> >
> > The am35x family of SoCs do not have an IVA so
> > a parallel set of clockdomain dependencies are
> > required that are simililar to OMAP3 but without
>
"Mark A. Greer" writes:
> On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote:
>> On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote:
>> > Hi
>>
>> Hi Paul, Kevin.
>>
>> > On Wed, 11 Apr 2012, Mark A. Greer wrote:
>> >
>> > > From: "Mark A. Greer"
>> > >
>> > > Currently
"Mark A. Greer" writes:
> On Wed, Apr 11, 2012 at 03:46:20PM -0700, Kevin Hilman wrote:
>> Hi Mark,
>
> Hi Kevin.
>
>> "Mark A. Greer" writes:
>>
>> > From: "Mark A. Greer"
>> >
>> > Typical OMAP3 SoCs have four power domain states: ON,
>> > INACTIVE, RETENTION, and OFF. The am35x family of S
Hi Mark,
Mark Brown writes:
> On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>
>> Devfreq and cpufreq are related to dynamic frequency/voltage switching
>> between
>> pre defined Operating Performance Points or the OPPs. Every OPP being
>> a voltage/frequency pair. Smartreflex is a
Kevin Hilman writes:
[...]
> I also don't like all the cpu_is* checking currently in omap_hwmod.c
> (which is here before you added this) and have an idea on how to clean
> it up, I should have a patch by tomorrow for this. That should help
> adding am33xx support here without needing all the c
On Wed, Apr 18, 2012 at 12:19 PM, Russell King - ARM Linux
wrote:
> Oops, this patch wasn't supposed to be part of this set...
...however it gives me the impression that you have a patch set cooking
to also switch PL08x over to the virtual channel mechanism which is
really appetizing to see :-)
On Fri, Apr 27, 2012 at 9:03 PM, Russell King - ARM Linux
wrote:
> On Fri, Apr 27, 2012 at 09:00:22PM +0200, Linus Walleij wrote:
>> Are these development artifacts?
>
> Read the commit message. ;)
>
> They're there (and removed by the next patch) so that the driver can
> be easily switched betwe
On Mon, Apr 23, 2012 at 6:08 PM, Russell King
wrote:
> Signed-off-by: Russell King
> ---
> Documentation/feature-removal-schedule.txt | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
Your effort on this is much appreciated.
Acked-by: Linus Walleij
Thanks,
Linus Walleij
Tero Kristo writes:
> Looks good to me, acked.
Thanks.
Kevin
>
> On Tue, 2012-04-24 at 07:23 -0700, Kevin Hilman wrote:
>> commit e7410cf7 (02fdb03e69699f26e1370d0e51593dbc8a4e5265) moved
>> mangement of cam_pwrdm to CPUidle but left some remnants behind,
>> namely the call to clkcm_allo_idle(
_omap4_wait_target_disable() is called only from inside _omap4_disable_module()
which is already protected by SoC specific checks. Remove the cpu_is check
here.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mac
Rather than use runtime cpu_is* checking inside _init_clkdm, initialize
SoC specific function pointer at init time.
Note that initializing the function pointer oh->init_clkdm pointer
must be done before _init_clocks() is called because it is used there.
Signed-off-by: Kevin Hilman
---
arch/arm/
Rather than using cpu_is* checking at runtime, initialize SoC specific
function pointers for the various hard reset functions at init time.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 111 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h
_enable_module is specific to OMAP4-class SoCs, so rename it to
be consistend with the corresponding _omap4_disable_module.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_h
Rather than using cpu_is* checking at runtime, initialize an SoC specific
function pointer for wait_target_ready().
While here, downgrade the BUG() to a WARN_ON() so it gives a noisy
warning instead of causing a kernel panic.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c
This series attempts to remove all the runtime cpu_is* checking in
omap_hwmod.c in favor of using function pointers initialized at init
time.
This series was motivated by the addition of support for the AM335x
series which was done by adding several more cpu_is* checks, and
provided the proverbial
The enable/disable module functions are specific to SoCs with
OMAP4-class PRCM. Rather than use cpu_is* checks at runtime inside
the enable/disable module functions, use cpu_is at init time to
initialize function pointers only for SoCs that need them.
NOTE: the cpu_is* check for _enable_module wa
On Fri, Apr 27, 2012 at 07:31:16PM +0100, Russell King - ARM Linux wrote:
> I don't have that in the branch I'm building because I started the
> DMA engine work against v3.4-rc3.
>
> > This is the second patch to separate the twl6040 from twl-core.
> > If you are missing this patch twl6040 will no
Hi Russell,
On Fri, Apr 27, 2012 at 9:31 PM, Russell King - ARM Linux
wrote:
>> Can you check if you have this commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=8eaeb9393397be8eb700ab38a69c450975463b77
>
> I don't have that in the branch I'm building because I sta
On Fri, 27 Apr 2012 19:43:30 +0530, Tarun Kanti DebBarma
wrote:
> Here are the remaining cleanup patches. There are broadly
> two categories of cleanups.
>
> Cat-1: Those missed while introducing new feature like SPARSE_IRQ
>handling and DT support; use edge/level handlers from
>
On Fri, Apr 27, 2012 at 09:00:22PM +0200, Linus Walleij wrote:
> On Mon, Apr 23, 2012 at 6:05 PM, Russell King
> wrote:
>
> > Add DMA engine support to the OMAP HSMMC driver. This supplements the
> > private DMA API implementation contained within this driver, and the
> > driver can be switched
On Mon, Apr 23, 2012 at 6:05 PM, Russell King
wrote:
> Add DMA engine support to the OMAP HSMMC driver. This supplements the
> private DMA API implementation contained within this driver, and the
> driver can be switched at build time between using DMA engine and the
> private DMA API.
>
> Signe
On Mon, Apr 23, 2012 at 6:04 PM, Russell King
wrote:
> Split the virtual slave channel DMA support from the sa11x0 driver so
> this code can be shared with other slave DMA engine drivers.
>
> Signed-off-by: Russell King
I really like the direction of this thing.
Acked-by: Linus Walleij
Yours,
On Fri, Apr 27, 2012 at 09:14:23PM +0300, Ujfalusi, Peter wrote:
> On Fri, Apr 27, 2012 at 8:19 PM, Russell King - ARM Linux
> wrote:
> > root@omap-4430sdp:~# lsmod
> > Module Size Used by
> > snd_soc_dmic 1492 0
> > snd_soc_omap4_hdmi 1724 0
> > snd_soc_omap_hd
On Fri, Apr 27, 2012 at 8:19 PM, Russell King - ARM Linux
wrote:
> root@omap-4430sdp:~# lsmod
> Module Size Used by
> snd_soc_dmic 1492 0
> snd_soc_omap4_hdmi 1724 0
> snd_soc_omap_hdmi 1536 0
> snd_soc_omap_abe_twl6040 4867 0
> snd_soc_omap_dmic
On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> pre defined Operating Performance Points or the OPPs. Every OPP being
> a voltage/frequency pair. Smartreflex is a different
> power management technique.
On Mon, 23 Apr 2012 17:07:32 +0100, Russell King
wrote:
> Add DMA engine support to the OMAP SPI driver. This supplements the
> private DMA API implementation contained within this driver, and the
> driver can be independently switched at build time between using DMA
> engine and the private DMA
On Fri, Apr 27, 2012 at 08:04:52PM +0300, Ujfalusi, Peter wrote:
> On Fri, Apr 27, 2012 at 7:50 PM, Russell King - ARM Linux
> wrote:
> >> You need to load the DMIC driver as well:
> >> insmod snd-soc-omap-dmic.ko
> >
> > You must be joking...
>
> Well SDP4430/Blaze have the following setup:
> twl
On Fri, Apr 27, 2012 at 7:50 PM, Russell King - ARM Linux
wrote:
>> You need to load the DMIC driver as well:
>> insmod snd-soc-omap-dmic.ko
>
> You must be joking...
Well SDP4430/Blaze have the following setup:
twl6040 via McPDM
digital microphones via DMIC
So I would:
root@omap-4430sdp:~# insm
On Fri, Apr 27, 2012 at 07:32:42PM +0300, Ujfalusi, Peter wrote:
> On Fri, Apr 27, 2012 at 7:04 PM, Russell King - ARM Linux
> wrote:
> > Right, so the only platform I have out of that (as I said above) is
> > SDP4430.
> >
> > And as I've already said, it does *not* appear to support any audio
> >
On Fri, Apr 27, 2012 at 7:04 PM, Russell King - ARM Linux
wrote:
> Right, so the only platform I have out of that (as I said above) is
> SDP4430.
>
> And as I've already said, it does *not* appear to support any audio
> of any kind:
>
> root@omap-4430sdp:~# insmod snd-soc-twl6040.ko
> root@omap-44
On Fri, Apr 27, 2012 at 06:53:39PM +0300, Ujfalusi, Peter wrote:
> Hi Russell,
>
> On Fri, Apr 27, 2012 at 4:58 PM, Russell King - ARM Linux
> wrote:
> > Can someone please hint on what audio is supported on these two OMAP
> > boards? From what I can tell, the answer is either "nothing" or "hdmi
Hi Russell,
On Fri, Apr 27, 2012 at 4:58 PM, Russell King - ARM Linux
wrote:
> Can someone please hint on what audio is supported on these two OMAP
> boards? From what I can tell, the answer is either "nothing" or "hdmi",
> both of which are useless to me if someone wants me to convert the OMAP
Hi Rusell,
On 04/27/2012 08:28 AM, Russell King - ARM Linux wrote:
When building ALSA as modules:
drivers/built-in.o: In function `omapdss_hdmihw_remove':
omap_hwspinlock.c:(.text+0x23da8): undefined reference to
`snd_soc_unregister_codec'
drivers/built-in.o: In function `omapdss_hdmihw_probe'
On Fri, Apr 27, 2012 at 03:56:42PM +0100, Liam Girdwood wrote:
> On Fri, 2012-04-27 at 19:45 +0530, Shilimkar, Santosh wrote:
> > + Peter and Liam to comment
> >
> > On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux
> > wrote:
> > > Can someone please hint on what audio is supported on th
On Fri, 2012-04-27 at 19:45 +0530, Shilimkar, Santosh wrote:
> + Peter and Liam to comment
>
> On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux
> wrote:
> > Can someone please hint on what audio is supported on these two OMAP
> > boards? From what I can tell, the answer is either "nothi
+ Peter and Liam to comment
On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux
wrote:
> Can someone please hint on what audio is supported on these two OMAP
> boards? From what I can tell, the answer is either "nothing" or "hdmi",
> both of which are useless to me if someone wants me to c
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson, Benoit
Cc: Grant Likely
Signed-off-by: Tarun
There is no more need to have saved_wakeup because bank->context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson, Benoit
Cc: Grant Likely
Signed-off-by: Tarun Kanti DebBar
This cleanup got missed while implementing following:
25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1 gpio/omap: Add DT support to GPIO driver
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson, Benoit
Cc: Grant Likely
Signed-off-by: Tarun Kanti DebBarma
---
arc
commit 672e302e3c (ARM: OMAP: use edge/level handlers from generic IRQ
framework) removed retrigger support in favor of using generic IRQ
framework. This patch cleans up some unused remnants of that removal.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson, Benoit
Cc: Gran
Since we already have bank->context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson, Benoit
Cc: Grant Likely
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Sh
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank->regs->wkup_en, 0x, 0);
_gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets initia
Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0
which are present on OMAP4+ processors. Now we can distinguish
conditions applicable to OMAP4,5 and those specific to OMAP24xx
and OMAP3xxx.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson, Benoit
Cc: Gran
We do checking for bank->enabled_non_wakeup_gpios in order
to skip redundant operations. Somehow, the check got missed
while doing the cleanup series.
Just to make sure that we do context restore correctly in
*_runtime_resume(), the bank->workaround_enabled check is
moved after context restore. Ot
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_ba
Can someone please hint on what audio is supported on these two OMAP
boards? From what I can tell, the answer is either "nothing" or "hdmi",
both of which are useless to me if someone wants me to convert the OMAP
ASoC driver to DMA engine.
>From what I can see on the 4430SDP, there's a 3.5mm head
When building ALSA as modules:
drivers/built-in.o: In function `omapdss_hdmihw_remove':
omap_hwspinlock.c:(.text+0x23da8): undefined reference to
`snd_soc_unregister_codec'
drivers/built-in.o: In function `omapdss_hdmihw_probe':
omap_hwspinlock.c:(.text+0x24248): undefined reference to
`snd_soc_
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
> Hi Tero,
>
> Tero Kristo writes:
>
> > On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote:
> >> Hi Paul,
> >>
> >> On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote:
> >> > Perhaps you might be willing to add some debugging to
Greg,
On Monday 23 April 2012 08:14 PM, Shilimkar, Santosh wrote:
> On Mon, Apr 23, 2012 at 7:57 PM, Greg KH wrote:
>> On Mon, Apr 23, 2012 at 04:34:46PM +0530, Shilimkar, Santosh wrote:
>>> Afzal,
>>>
>>> On Mon, Apr 23, 2012 at 4:26 PM, Mohammed, Afzal wrote:
Hi Aneesh,
On Fri,
From: Aneesh V
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Signed-off-by:
From: Aneesh V
Add register offsets and bit field definitions
for EMIF module in TI SoCs
Signed-off-by: Aneesh V
Reviewed-by: Santosh Shilimkar
Reviewed-by: Benoit Cousson
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar
Tested-by: Lokesh
From: Aneesh V
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of
From: Aneesh V
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage ch
From: Aneesh V
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Signed-off-by: Aneesh V
Reviewed-by: Santosh Shilimkar
Reviewed-by: Benoit Cousson
[santosh.shilim...@ti.com: Moved to drivers
From: Aneesh V
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Signed-off-by: Aneesh V
Rev
Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
EMIF is an SDRAM controller that supports, based on its revision,
one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
for LPDDR2.
The driver supports the following features:
- Calculates the DDR AC timing para
From: Aneesh V
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers.
Right now this is used by the TI EMIF SDRAM co
The register bits for MPU_CLK_SRC and IVA2_CLK_SRC
in CM_CLKSEL1_PLL register are 3 bits wide.
Fix the MASK definition accordingly.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-om
On Thu, Apr 26, 2012 at 14:19:28, Paul Walmsley wrote:
> Hello Vaibhav,
>
> looking at Table 1-1 "Device Features" of SPRUH73D, it seems that some
> AM33xx family chips come with some features disabled, such as the
> PRU-ICSS, the SGX, Ethernet, or USB. How will this affect the clock tree?
>
On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra
wrote:
> 2012/4/4 Javier Martinez Canillas :
>> board_onenand_init() and board_nand_init() initialization functions are
>> used to initialize OneNAND and NAND memories respectively. But only
>> board_nand_init() was visible to be used from bo
2012/4/23 Laurent Pinchart :
> The supply is connected to the DSS DO-D5 pins and is thus needed for
> both serial and parallel display interfaces on the igep0030 as well as
> the igep0020.
>
> If the igep0030 module isn't connected to a display, no DSI or DPI
> display will be specified in board co
On Fri, Apr 27, 2012 at 00:26:47, Paul Walmsley wrote:
> On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote:
>
> > On Thu, Apr 26, 2012 at 14:27:20, Paul Walmsley wrote:
>
> (attribution lost)
>
> > > > I am thinking of separating clocktree patch (PATCH-V3 3/3) from this
> > > > series,
> > > > so t
On Fri, Apr 27, 2012 at 00:35:25, Tony Lindgren wrote:
> * Hiremath, Vaibhav [120426 11:52]:
> >
> > Yes, they were accepted and were also available under linux-omap/soc2
> > branch
> > for quite some time.
>
> Hmm sorry if I've dropped them accidentally. I tend to drop the branches
> after ea
Breaking commit: ab985f0f7c2c0ef90b7c832f0c04f470dda0593d
Initialization of irqenable, irqstatus registers is the common
operation done in this function for all OMAP platforms, viz.
OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register
was overwriting the correctly programmed OMAP1 value a
On Fri, Apr 27, 2012 at 02:13:10, Dill, Russ wrote:
> On Thu, Apr 26, 2012 at 11:33 AM, Kevin Hilman wrote:
> > Vaibhav Hiremath writes:
> >
> >
> > If so, please reply with your Tested-by.
>
> Tested-by: Russ Dill
>
> All three patches in series boot tested on:
> Beagleboard xM
> Beagleboard
Looks good to me, acked.
-Tero
On Tue, 2012-04-24 at 07:23 -0700, Kevin Hilman wrote:
> commit e7410cf7 (02fdb03e69699f26e1370d0e51593dbc8a4e5265) moved
> mangement of cam_pwrdm to CPUidle but left some remnants behind,
> namely the call to clkcm_allo_idle() for the clockdomains in the MPU
> pwrd
85 matches
Mail list logo
