On Thu, May 17, 2012 at 4:47 AM, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> From: Rajendra Nayak
>>
>> On HS devices on the way out of MPU OSWR and OFF ROM code wrongly
>> overwrites the CM L3INSTR registers. So to avoid this, save them and
>> restore on the way out from MPU OSWR/OFF.
>>
>>
On Thu, May 17, 2012 at 4:35 AM, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> From: Santosh Shilimkar
>>
>> The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
>> IVA and Tesla execution.
>>
>> At wakeup from MPU OFF on HS device only (not GP device), when
>> restoring the
On Wed, May 16, 2012 at 10:21 PM, Kevin Hilman wrote:
> Santosh Shilimkar writes:
>
>> Kevin,
>>
>> On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
>>> On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
Santosh,
Tero Kristo writes:
> From: Santosh Shilimka
On Wed, May 16, 2012 at 4:17 PM, Ming Lei wrote:
> Jon,
>
> On Wed, May 16, 2012 at 6:05 AM, Ming Lei wrote:
>>
>>
>> On Tuesday, May 15, 2012, Jon Hunter wrote:
>>> Hi Ming,
>>>
>>> On 05/14/2012 11:53 PM, Ming Lei wrote:
On Thu, May 10, 2012 at 5:35 AM, Jon Hunter wrote:
> From: Jon
On Thu, May 17, 2012 at 1:44 AM, Jon Hunter wrote:
> Hi Benoit,
>
> On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
>> Hi Jon,
>>
>> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>>> From: Jon Hunter
>>>
>>> In order to migrate the dmtimer driver to support device-tree I found
>>> that it
>>> was first n
On 17 May 2012 05:29, Stephen Warren wrote:
>>>
>>> Generic binding to provide a way to provide the client-channel map and
>>> other dmac specific parameters to the dma controller driver
>>>
>>> DMA Model:-
>>> Only the most common characteristics of a dma setup are assumed
>>> in this binding.
The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
otherwise the following failure message should be dumped because
hardware handler is defined as NULL:
[3.383483] genirq: Threaded irq requested with handler=NULL and
!ONESHOT for irq 368
[3.392730] omap_hsmmc: probe of omap
Tero Kristo writes:
> Without this, CPU0 will crash in the ROM code during wakeup from
> device off. This patch also clears the GIC save area, to prevent
> ROM code from writing garbage to the GIC registers during wakeup.
> The actual GIC restore is done by kernel.
>
> This bug fix applies only t
Tero Kristo writes:
> If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back
> to off.
Why is it waking up then? (I know the answer, but will forget. The
changelog serves as my long-term memory.)
> This is needed during wakeup from device off to prevent cpu1
> from being st
Hi Tero
On Mon, 14 May 2012, Tero Kristo wrote:
> save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
> otherwise the secure ROM code will crash.
Do we know why the l3_main_3 interconnect has to be enabled? Is this
needed to access some L3 or instrumentation registers?
- Paul
--
Tero Kristo writes:
> From: Santosh Shilimkar
>
> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
> The issue occurs when EMIF_SDRAM_CONFIG is restored first before
> EMIF_SDRAM_CONFIG_2 is not yet restored,
+Benoit
Tero Kristo writes:
> save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled,
> otherwise the secure ROM code will crash.
>
> Signed-off-by: Tero Kristo
I think I mentioned this already (I'm already lost in what I've said for
thisseries), but I don't think the secure RAM stuff
On 05/16/2012 01:42 PM, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Jassi Brar wrote:
>> On 16 May 2012 21:45, Stephen Warren wrote:
>
>>
>> Generic binding to provide a way to provide the client-channel map and
>> other dmac specific parameters to the dma controller driver
>>
>> DMA Model:-
Tero Kristo writes:
> From: Axel Haslam
>
> ROM code restores part of the GIC context during wakeup from device
> off mode from the SAR RAM. If the PPI and SPI interrupts are not
> marked as non-secure on GP chips, this crashes the device during
> wakeup, thus mark them as non-secure.
>
> Signed
Tero Kristo writes:
> From: Carlos Leija
>
> At wakeup from OFF/OSWR CPU1 will call secure HAL service through a local
> secure dispatcher with MMU off,
Reviewers who are uninitaited in this level of detail need some more
help here (even those who are deeply familiar will need more help in a
Hello Jon,
On Wed, 16 May 2012, Jon Hunter wrote:
> I have been looking into this and in order to get rid for the above
> function pointer we would need to move at a minimum the following
> functions from omap-mach2/clkt_clksel.c into the platform code.
By platform code, do you mean arch/arm/pla
Tero Kristo writes:
> From: Rajendra Nayak
>
> On HS devices on the way out of MPU OSWR and OFF ROM code wrongly
> overwrites the CM L3INSTR registers. So to avoid this, save them and
> restore on the way out from MPU OSWR/OFF.
>
> This errata applies to all HS/EMU versions of OMAP4.
>
> Signed-
On 05/16/2012 04:05 PM, Kevin Hilman wrote:
Tero Kristo writes:
From: Santosh Shilimkar
The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
IVA and Tesla execution.
At wakeup from MPU OFF on HS device only (not GP device), when
restoring the Secure RAM, the ROM Code recon
Tero Kristo writes:
> From: Santosh Shilimkar
>
> The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
> IVA and Tesla execution.
>
> At wakeup from MPU OFF on HS device only (not GP device), when
> restoring the Secure RAM, the ROM Code reconfigures the clocks the
> same way
Tero Kristo writes:
> From: Santosh Shilimkar
>
> The SAR RAM is maintained during Device OFF mode.
so why is this patch bothering to save and restore it?
-ECONFUSED
> The register layout
> is fixed in SAR ROM. SAR is split into 4 banks with different
> privilege accesses based on device typ
Tero Kristo writes:
> From: Rajendra Nayak
>
> Restore all CM1/2 module registers as they are lost in OFF mode.
Save and restore?
Also, as in the previous patch. Can this be done using cluster PM
notifier as well?(I realize that this series was probably done
before the PM notifiers were u
Tero Kristo writes:
> From: Rajendra Nayak
>
> SAR/ROM code restores only CORE DPLL to its original state
> post wakeup from OFF mode.
> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
> are saved and restored here during an OFF transition.
>
> [n...@ti.com: minor cleanups]
> Sign
+Jean for functional power states
Tero Kristo writes:
> This patch adds device off support to OMAP4 device type.
Description is rather thin for a patch that is doing so much.
> OFF mode is disabled by default,
why?
> however, there are two ways to enable OFF mode:
> a) In the board file, ca
On 17 May 2012 01:12, Arnd Bergmann wrote:
>>
>> Generic binding to provide a way to provide the client-channel map and
>> other dmac specific parameters to the dma controller driver
>>
>> DMA Model:-
>> Only the most common characteristics of a dma setup are assumed
>> in this binding.
>> Clien
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> In order to migrate the dmtimer driver to support device-tree I found
>> that it
>> was first necessary to clean-up the timer platform data. The goal of this
>
On Wednesday 16 May 2012, Jassi Brar wrote:
> On 16 May 2012 21:45, Stephen Warren wrote:
>
> Generic binding to provide a way to provide the client-channel map and
> other dmac specific parameters to the dma controller driver
>
> DMA Model:-
> Only the most common characteristics of a dma se
Tero Kristo writes:
> Added in preparation for device off mode. SAR ROM contains the mapping
> from SAR RAM to IO registers, and this will eventually be parsed during
> init time to do the reverse before device off.
>
> Signed-off-by: Tero Kristo
This should be combined with the patch that uses
Tero Kristo writes:
> From: Santosh Shilimkar
>
> L3INIT powerdomain has USB HOST and USB TLL modules which support
> hardware save-and-restore (HW SAR) mechanism.
> This patch updates the L3INIT power domain to mark them as capable
> of doing H/w save and restore and provides functions to do th
On 05/16/2012 12:46 PM, Stephen Warren wrote:
> On 05/16/2012 11:37 AM, Jon Hunter wrote:
>>
>>
>> On 05/16/2012 12:24 PM, Jassi Brar wrote:
>>> On 16 May 2012 22:42, Jon Hunter wrote:
>>>
>> What is still unclear to me, is if you use this token approach how
>> readable is the device-tree
Tero Kristo writes:
> On Tue, 2012-05-15 at 15:41 -0700, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>> > PM debug now contains a file that can be used to control OSWR support
>> > enable / disable on OMAP4. Also removed the off_mode_enable file for
>> > the same platform as it is unsupported
On 05/16/2012 11:37 AM, Jon Hunter wrote:
>
>
> On 05/16/2012 12:24 PM, Jassi Brar wrote:
>> On 16 May 2012 22:42, Jon Hunter wrote:
>>
> What is still unclear to me, is if you use this token approach how
> readable is the device-tree? For example, if you have a client that can
> use
On 05/16/2012 12:24 PM, Jassi Brar wrote:
> On 16 May 2012 22:42, Jon Hunter wrote:
>
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/chann
On 16 May 2012 22:42, Jon Hunter wrote:
>>> What is still unclear to me, is if you use this token approach how
>>> readable is the device-tree? For example, if you have a client that can
>>> use one of two dmac and for each dmac the request/channel number is
>>> different, then by using a global
On 05/16/2012 11:16 AM, Jassi Brar wrote:
> On 16 May 2012 21:31, Jon Hunter wrote:
>> On 05/16/2012 08:15 AM, Jon Hunter wrote:
>>> Hi Jassi,
>>>
>>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter wrote:
> On 05/04/2012 02:01 PM, Jassi Brar
On 05/16/2012 11:22 AM, Jassi Brar wrote:
[...]
> OK, my guts feel people might be interested in what's cooking on
> my side. I started with the binding text first and then would write
> code based upon that approach.
>
> The following might be tweaked as I look deeper into client and DMAC
> dr
Santosh Shilimkar writes:
> Kevin,
>
> On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
>> On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
>>> Santosh,
>>>
>>> Tero Kristo writes:
>>>
From: Santosh Shilimkar
GIC distributor control register has changed between C
On 16 May 2012 21:45, Stephen Warren wrote:
> On 05/16/2012 10:01 AM, Jon Hunter wrote:
> ...
>> By the way, I do see your point. You wish to describe the all the
>> mappings available to all dma controllers and then set a mapping in the
>> device tree. Where as I am simply setting a mapping and d
On 16 May 2012 21:31, Jon Hunter wrote:
> On 05/16/2012 08:15 AM, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>> Hi Jon,
>>>
>>> On 16 May 2012 06:41, Jon Hunter wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
>
> + i2c1: i2c@1 {
> +
On 05/16/2012 10:01 AM, Jon Hunter wrote:
...
> By the way, I do see your point. You wish to describe the all the
> mappings available to all dma controllers and then set a mapping in the
> device tree. Where as I am simply setting a mapping and do not list all
> other possibilities (assuming that
On 05/16/2012 10:44 AM, Stephen Warren wrote:
> On 05/16/2012 07:15 AM, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>> Hi Jon,
>>>
>>> On 16 May 2012 06:41, Jon Hunter wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
>
> + i2c1: i2c@1 {
>
On 05/16/2012 08:15 AM, Jon Hunter wrote:
> Hi Jassi,
>
> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>> Hi Jon,
>>
>> On 16 May 2012 06:41, Jon Hunter wrote:
>>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = <&sdma 2
On 05/16/2012 01:14 AM, Linus Walleij wrote:
> On Mon, May 14, 2012 at 8:38 PM, Stephen Warren wrote:
>> On 05/12/2012 05:49 PM, Linus Walleij wrote:
...
>>> Maybe "-simple" isn't such a good name for this thing. Noone thinks
>>> any kind of pin control is simple in any sense of the word anyway :-
On 05/16/2012 07:15 AM, Jon Hunter wrote:
> Hi Jassi,
>
> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>> Hi Jon,
>>
>> On 16 May 2012 06:41, Jon Hunter wrote:
>>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = <&sdma 2 1
+ Tarun for any comments
On Wednesday 16 May 2012 05:05 AM, Jon Hunter wrote:
> From: Jon Hunter
>
> In order to migrate the dmtimer driver to support device-tree I found that it
> was first necessary to clean-up the timer platform data. The goal of this
> series is to simplify the timer platfor
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/16/2012 1:35 AM, Jon Hunter wrote:
>> From: Jon Hunter
>>
>> In order to migrate the dmtimer driver to support device-tree I found
>> that it
>> was first necessary to clean-up the timer platform data. The goal of this
>
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
> Hi Jon,
>
> On 16 May 2012 06:41, Jon Hunter wrote:
>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>>
>>> + i2c1: i2c@1 {
>>> + ...
>>> + dma = <&sdma 2 1 &sdma 3 2>;
>>> + ...
>>> + };
>>>
Hi Jon,
On 16 May 2012 06:41, Jon Hunter wrote:
> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>
>> + i2c1: i2c@1 {
>> + ...
>> + dma = <&sdma 2 1 &sdma 3 2>;
>> + ...
>> + };
>>>
>> I see this requires a client driver to specify a particular re
Tero,
On Monday 14 May 2012 03:33 PM, Tero Kristo wrote:
> From: Santosh Shilimkar
>
> GIC distributor control register has changed between CortexA9 r1pX and
> r2pX. The Control Register secure banked version is now composed of 2
> bits:
> bit 0 == Secure Enable
> bit 1 == Non-Secure E
Kevin,
On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
> On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
>> Santosh,
>>
>> Tero Kristo writes:
>>
>>> From: Santosh Shilimkar
>>>
>>> GIC distributor control register has changed between CortexA9 r1pX and
>>> r2pX. The Control Re
On Thu, May 10, 2012 at 5:35 AM, Jon Hunter wrote:
> +
> + /*configure CTI0 for pmu irq routing*/
> + cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
> + cti_unlock(&omap4_cti[0]);
> + cti_map_trigger(&omap4_cti[0], 1, 6, 2);
> +
> + /*configure CTI1 for pmu ir
Hi Tomi,
On 5/16/2012 11:08 AM, Tomi Valkeinen wrote:
On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
Hello Tomi,
On Mon, 14 May 2012, Tomi Valkeinen wrote:
I've been doing testing to understand the problem, but so far I don't
have any idea why things go wrong. I haven't found out an
Hi Tony,
Two important fixes from Juan that are necessary to utilize the DSP on
OMAP4, and a trivial hwspinlock cleanup.
I tried to keep things as simple as possible, but please tell me if
you want this pull request anyway differently (e.g. split to two
separate fixes/cleanups requests, use an an
Hi Linus,
Please pull a tiny but quite important remoteproc fix for 3.4.
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remotep
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunter
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtim
On Wed, 2012-05-16 at 12:08 +0300, Tomi Valkeinen wrote:
> On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
> > Hello Tomi,
> >
> > On Mon, 14 May 2012, Tomi Valkeinen wrote:
> >
> > > I've been doing testing to understand the problem, but so far I don't
> > > have any idea why things go w
On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
> Santosh,
>
> Tero Kristo writes:
>
>> From: Santosh Shilimkar
>>
>> GIC distributor control register has changed between CortexA9 r1pX and
>> r2pX. The Control Register secure banked version is now composed of 2
>> bits:
>> bit 0 ==
On Tue, 2012-05-15 at 15:41 -0700, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > PM debug now contains a file that can be used to control OSWR support
> > enable / disable on OMAP4. Also removed the off_mode_enable file for
> > the same platform as it is unsupported.
> >
> > Signed-off-by: Tero
On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
> Hello Tomi,
>
> On Mon, 14 May 2012, Tomi Valkeinen wrote:
>
> > I've been doing testing to understand the problem, but so far I don't
> > have any idea why things go wrong. I haven't found out any logic in
> > which configuration works an
On Tue, 2012-05-15 at 15:36 -0700, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > On OMAP4, there is no support to read previous logic state
> > or previous memory state achieved when a power domain transitions
> > to RET. Instead there are module level context registers.
> >
> > In order to sup
On Tue, 2012-05-15 at 14:44 -0700, Kevin Hilman wrote:
> Santosh,
>
> Tero Kristo writes:
>
> > From: Santosh Shilimkar
> >
> > GIC distributor control register has changed between CortexA9 r1pX and
> > r2pX. The Control Register secure banked version is now composed of 2
> > bits:
> > bit
On Tue, May 15, 2012 at 01:14:29PM -0700, Tony Lindgren wrote:
> * Felipe Balbi [120514 12:41]:
> > On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote:
> > > * Tony Lindgren [120514 11:19]:
> > > > * Felipe Balbi [120514 11:04]:
> > > > >
> > > > > That whole MMC card detection is al
On Tue, 2012-05-15 at 12:52 -0700, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > From: Rajendra Nayak
> >
> > Remove the FIXME's in the suspend sequence since
> > we now intend to support system level RET support.
>
> minor: this should probably go at the end of the series, after retention
>
Jon,
On Wed, May 16, 2012 at 6:05 AM, Ming Lei wrote:
>
>
> On Tuesday, May 15, 2012, Jon Hunter wrote:
>> Hi Ming,
>>
>> On 05/14/2012 11:53 PM, Ming Lei wrote:
>>> On Thu, May 10, 2012 at 5:35 AM, Jon Hunter wrote:
From: Jon Hunter
This patch is based upon Ming Lei's patch to
On Mon, May 14, 2012 at 8:38 PM, Stephen Warren wrote:
> On 05/12/2012 05:49 PM, Linus Walleij wrote:
>>
>> We have some pinctrl drivers implementing gpiolib too already,
>> and it's unavoidable I think, as some recent discussion about
>> matcing struct gpio_chip and pinctrl GPIO ranges shows.
>
>
64 matches
Mail list logo
