On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> In preparation for suspend-resume support for AM33XX, add
> the assembly file with the code which is copied to internal
> memory (OCMC RAM) during bootup and runs from there.
>
> As part of the low power entry (DeepSle
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> OMAP timer code registers two timers - one as clocksource
> and one as clockevent. Since AM33XX has only one usable timer
> in the WKUP domain one of the timers needs suspend-resume
> support to restore the configurati
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> Needed to let the AM335x PM handle the IPs which need forced
> standby transition during every suspend-resume cycle when
> the corresponding driver is not compiled into the kernel.
>
> Signed-off-by: Vaibhav Bedia
> S
* Pantelis Antoniou [130807 09:31]:
> Hi Tony,
>
> On Aug 7, 2013, at 7:15 PM, Tony Lindgren wrote:
>
> > * Pantelis Antoniou [130806 02:44]:
> >> On Aug 6, 2013, at 12:33 PM, Greg Kroah-Hartman wrote:
> >>> On Tue, Aug 06, 2013 at 10:53:44AM +0300, Pantelis Antoniou wrote:
> +
> stat
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> AM335x supports various low power modes as documented
> in section 8.1.4.3 of the AM335x TRM which is available
> @ http://www.ti.com/litv/pdf/spruh73f
>
> DeepSleep0 mode offers the lowest power mode with limited
> wa
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> With all the requisite changes in place we can now
> enable the basic PM support for AM335x. This patch
> updates the various OMAP files to enable suspend-resume
> on AM335x.
>
> Signed-off-by: Vaibhav Bedia
> Signed-
On Tue, Aug 06, 2013 at 03:36:33PM +0100, Ivan T. Ivanov wrote:
> Hi,
>
> On Tue, 2013-08-06 at 15:03 +0100, Mark Rutland wrote:
> > On Tue, Aug 06, 2013 at 12:53:10PM +0100, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov"
> > >
> > > Signed-off-by: Ivan T. Ivanov
> > > ---
> > > .../devicet
Hi Kevin,
On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote:
> [fixing address for Benoit]
>
> Pantelis Antoniou writes:
>
>> omap_device relies on the platform notifier callbacks managing resources
>> behind the scenes. The resources were not properly linked causing crashes
>> when removing the
Hi Kevin,
On Aug 8, 2013, at 12:15 AM, Kevin Hilman wrote:
> Pantelis Antoniou writes:
>
>> omap hwmod is really sensitive to hwmod misconfiguration.
>> Getting a minor clock wrong always ended up in a crash.
>> Attempt to be more resilient by not assigning variables with
>> error codes and the
On OMAP4 we have clk_set_rate()s being done for a few
DPLL clock nodes, as part of the clock init code, since
the bootloaders no longer locks these DPLLs.
So we have a clk_set_rate() done for a ABE DPLL node (which
inturn locks it) followed by a clk_set_rate() for the USB DPLL.
With USB DPLL bein
On Thursday 08 August 2013 11:07 AM, Rajendra Nayak wrote:
> On Wednesday 07 August 2013 11:39 PM, Paul Walmsley wrote:
>> Hi Rajendra,
>>
>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
>>
>>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I
>>> see
>>> the below errors. (I
On Thu, Aug 08, 2013 at 03:05:03AM +0300, Aaro Koskinen wrote:
> That seems to work - the board boots fine to shell as before. Feel free
> to add Reported-by: or Tested-by: from me to the patch.
Thanks, done. Should be in linux-next by tomorrow.
--
To unsubscribe from this list: send the line "un
On Wed, Aug 07, 2013 at 02:26:09AM +0300, Aaro Koskinen wrote:
> [0.258589] [1224] *pgd=, *pte=11fff0cb01f1,
> *ppte=11fff00a
BTW, your oops dump is interesting for another reason - the above.
You seem to have 64-bit page table entries above. This is produced
by this:
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
> We certainly don't want error conditions to be cleared any other
> place but the EDMA error handler, as this will make us 'forget'
> about missed events we might need to know errors have occurred.
>
> This fixes a race condition where the
On 08/08/2013 03:45 AM, Russ Dill wrote:
In reference to
the M3 handling it, the M3 wouldn't know which devices have a driver
bound and which don't.
Does it need to? M3 firmware can pretty much define "I will force the
device into low power state, and if the drivers dont handle things
properl
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> Hi,
>
> This is the third version of the patch series for adding basic suspend-resume
> support for AM33XX, previously submitted by Vaibhav Bedia. This patchset
> is based on 3.11-rc4 and depends on a forthcoming patchset from Suman Anna
>
(You have not CC'ed Greg, Looping him)
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> OMAP4 and AM33XX share the same EMIF controller IP. Although there
> are significant differences in the IP integration due to which
> AM33XX can't reuse the EMIF driver DVFS similar to OMAP4,
> it can
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> Interacting with WKUP-M3 requires some more control
> module register writes. Add the register offsets and
> APIs to write to these.
>
> Signed-off-by: Vaibhav Bedia
> Signed-off-by: Dave Gerlach
> ---
> arch/ar
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> Allow interrupt for wkup_m3 to be set from DT.
>
> Signed-off-by: Vaibhav Bedia
> Signed-off-by: Dave Gerlach
> Cc: Benoit Cousson
> ---
Acked-by: Santosh Shilimkar
--
To unsubscribe from this list: send the l
Rebooting appears to have broken in 3.11 (at some point before rc1).
Here is the console output:-
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.11.0-rc1-6-gf550793 (mpfj@mpfj-nanobone)
(gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #328 Thu Aug 8 14:36:16 BS
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> SDRAM controller on AM33XX requires that a modification of certain
> bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in
> AM335x-Rev H) is followed by a dummy read access to SDRAM. This
> scenario arises
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> OMAP timer code registers two timers - one as clocksource
> and one as clockevent. Since AM33XX has only one usable timer
> in the WKUP domain one of the timers needs suspend-resume
> support to restore the configur
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> Needed to let the AM335x PM handle the IPs which need forced
> standby transition during every suspend-resume cycle when
> the corresponding driver is not compiled into the kernel.
>
> Signed-off-by: Vaibhav Bedia
On Aug 7, 2013, at 3:08 PM, Suman Anna wrote:
> On 08/07/2013 12:41 PM, Kumar Gala wrote:
>>
>> On Aug 7, 2013, at 11:59 AM, Suman Anna wrote:
>>
>>> Kumar,
>>>
> Logic has been added to the OMAP2+ mailbox code to
> parse the mailbox dt nodes and construct the different
> mailboxes
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> In preparation for suspend-resume support for AM33XX, add
> the assembly file with the code which is copied to internal
> memory (OCMC RAM) during bootup and runs from there.
>
> As part of the low power entry (Dee
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> With all the requisite changes in place we can now
> enable the basic PM support for AM335x. This patch
> updates the various OMAP files to enable suspend-resume
> on AM335x.
>
> Signed-off-by: Vaibhav Bedia
> Sig
$subject and patch don't match.
On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
> On 08/08/2013 03:45 AM, Russ Dill wrote:
>> In reference to
>> the M3 handling it, the M3 wouldn't know which devices have a driver
>> bound and which don't.
> Does it need to? M3 firmware can pretty muc
On Thu, Aug 8, 2013 at 7:50 AM, Santosh Shilimkar
wrote:
> On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
>> From: Vaibhav Bedia
>>
>> In preparation for suspend-resume support for AM33XX, add
>> the assembly file with the code which is copied to internal
>> memory (OCMC RAM) during boot
Hi!
I have a device-tree-booting omap board that uses gpio-omap as gpio driver.
Kernel version is 3.11.0-rc4. I have connected a device that signals
interrupts to a gpio pin of the omap. The driver for this device fails in
request_threaded_irq.
The irq framework tries to setup the irq in __setu
On Thursday 08 August 2013 11:16 AM, Russ Dill wrote:
> On Thu, Aug 8, 2013 at 7:50 AM, Santosh Shilimkar
> wrote:
>> On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
>>> From: Vaibhav Bedia
>>>
>>> In preparation for suspend-resume support for AM33XX, add
>>> the assembly file with the co
On Thursday 08 August 2013 11:23 AM, Lars Poeschel wrote:
> Hi!
>
> I have a device-tree-booting omap board that uses gpio-omap as gpio driver.
> Kernel version is 3.11.0-rc4. I have connected a device that signals
> interrupts to a gpio pin of the omap. The driver for this device fails in
> re
On 08/08/2013 09:34 AM, Kumar Gala wrote:
>
> On Aug 7, 2013, at 3:08 PM, Suman Anna wrote:
>
>> On 08/07/2013 12:41 PM, Kumar Gala wrote:
>>>
>>> On Aug 7, 2013, at 11:59 AM, Suman Anna wrote:
>>>
Kumar,
>> Logic has been added to the OMAP2+ mailbox code to
>> parse the mailbox
On Thu, Aug 8, 2013 at 8:22 AM, Santosh Shilimkar
wrote:
> On Thursday 08 August 2013 11:16 AM, Russ Dill wrote:
>> On Thu, Aug 8, 2013 at 7:50 AM, Santosh Shilimkar
>> wrote:
>>> On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
From: Vaibhav Bedia
In preparation for suspen
On 08/08/2013 10:03 AM, Santosh Shilimkar wrote:
$subject and patch don't match.
On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
On 08/08/2013 03:45 AM, Russ Dill wrote:
In reference to
the M3 handling it, the M3 wouldn't know which devices have a driver
bound and which don't.
D
On 08/08/2013 09:23 AM, Santosh Shilimkar wrote:
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
From: Vaibhav Bedia
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspen
On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
From: Vaibhav Bedia
Interacting with WKUP-M3 requires some more control
module register writes. Add the register offsets and
APIs to write to these.
Signed-off-by: Vaibhav Bedia
Signed-of
On 08/08/2013 11:06 AM, Dave Gerlach wrote:
On 08/08/2013 10:03 AM, Santosh Shilimkar wrote:
$subject and patch don't match.
On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
On 08/08/2013 03:45 AM, Russ Dill wrote:
In reference to
the M3 handling it, the M3 wouldn't know which de
Dave Gerlach writes:
> From: Vaibhav Bedia
>
> SDRAM controller on AM33XX requires that a modification of certain
> bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in
> AM335x-Rev H) is followed by a dummy read access to SDRAM. This
> scenario arises when entering a low power state l
Dave Gerlach writes:
> From: Vaibhav Bedia
>
> OMAP timer code registers two timers - one as clocksource
> and one as clockevent. Since AM33XX has only one usable timer
> in the WKUP domain one of the timers needs suspend-resume
> support to restore the configuration to pre-suspend state.
>
> co
On Thursday 08 August 2013 02:16 PM, Kevin Hilman wrote:
> Dave Gerlach writes:
>
>> From: Vaibhav Bedia
>>
>> SDRAM controller on AM33XX requires that a modification of certain
>> bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in
>> AM335x-Rev H) is followed by a dummy read access
On 08/08/2013 01:25 PM, Kevin Hilman wrote:
Dave Gerlach writes:
From: Vaibhav Bedia
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the config
Santosh Shilimkar writes:
> On Thursday 08 August 2013 02:16 PM, Kevin Hilman wrote:
>> Dave Gerlach writes:
>>
>>> From: Vaibhav Bedia
>>>
>>> SDRAM controller on AM33XX requires that a modification of certain
>>> bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in
>>> AM335x-Rev H
On Thursday 08 August 2013 04:05 PM, Kevin Hilman wrote:
> Santosh Shilimkar writes:
>
>> On Thursday 08 August 2013 02:16 PM, Kevin Hilman wrote:
>>> Dave Gerlach writes:
>>>
From: Vaibhav Bedia
SDRAM controller on AM33XX requires that a modification of certain
bit-fields i
Hi,
On Thu, Aug 08, 2013 at 12:01:08PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 07, 2013 at 02:26:09AM +0300, Aaro Koskinen wrote:
> > [0.258589] [1224] *pgd=, *pte=11fff0cb01f1,
> > *ppte=11fff00a
>
> BTW, your oops dump is interesting for another reason
Dave Gerlach writes:
> On 08/08/2013 10:03 AM, Santosh Shilimkar wrote:
>> $subject and patch don't match.
>>
>> On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
>>> On 08/08/2013 03:45 AM, Russ Dill wrote:
In reference to
the M3 handling it, the M3 wouldn't know which devi
Fix the option description to match the other TI SoCs.
This is just a cosmetic change.
Signed-off-by: Ezequiel Garcia
---
arch/arm/mach-omap2/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 76170dd..56021
On 08/08/2013 04:14 PM, Kevin Hilman wrote:
Dave Gerlach writes:
On 08/08/2013 10:03 AM, Santosh Shilimkar wrote:
$subject and patch don't match.
On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
On 08/08/2013 03:45 AM, Russ Dill wrote:
In reference to
the M3 handling it, the
Hi Archit,
On Monday 05 August 2013 16:56:46 Archit Taneja wrote:
> On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote:
> > On 02/08/13 17:03, Archit Taneja wrote:
> >> +struct vpdma_data_format vpdma_yuv_fmts[] = {
> >> + [VPDMA_DATA_FMT_Y444] = {
> >> + .data_type = DATA_TYPE
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:38 Archit Taneja wrote:
> The primary function of VPDMA is to move data between external memory and
> internal processing modules(in our case, VPE) that source or sink data.
> VPDMA is capable of buffering this data and then deliv
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:43 Archit Taneja wrote:
> Add a DT node for VPE in dra7.dtsi. This is experimental because we might
> need to split the VPE address space a bit more, and also because the IRQ
> line described is accessible the IRQ crossbar driver
Hi,
On Fri, Aug 09, 2013 at 12:11:15AM +0300, Aaro Koskinen wrote:
> On Thu, Aug 08, 2013 at 12:01:08PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Aug 07, 2013 at 02:26:09AM +0300, Aaro Koskinen wrote:
> > > [0.258589] [1224] *pgd=, *pte=11fff0cb01f1,
> > > *ppte=11fff
Nishanth Menon writes:
> On 08/08/2013 04:14 PM, Kevin Hilman wrote:
>> Dave Gerlach writes:
>>
>>> On 08/08/2013 10:03 AM, Santosh Shilimkar wrote:
$subject and patch don't match.
On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
> On 08/08/2013 03:45 AM, Russ Dill w
Quoting Rajendra Nayak (2013-08-08 03:14:11)
> On OMAP4 we have clk_set_rate()s being done for a few
> DPLL clock nodes, as part of the clock init code, since
> the bootloaders no longer locks these DPLLs.
...
> Signed-off-by: Rajendra Nayak
Taken into clk-next. Thanks for the fix. Besides the an
Hi Mike,
On Thu, 8 Aug 2013, Mike Turquette wrote:
> Quoting Rajendra Nayak (2013-08-08 03:14:11)
> > On OMAP4 we have clk_set_rate()s being done for a few
> > DPLL clock nodes, as part of the clock init code, since
> > the bootloaders no longer locks these DPLLs.
> ...
> > Signed-off-by: Rajendr
* Dave Gerlach [130808 09:23]:
> On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
> >Lets address the above better. I don't see a need of 8 functions
> >exported doing one or 2 register writes.
> >
> >Look M3 based handling is going to be there on future SOCs
> >as well and this kind of handling o
On Mon, Aug 05, 2013 at 08:17:17PM +0530, Lokesh Vutla wrote:
> This patch series adds support for OMAP4 version of RNG module.
> This module produce a 64 bit random number and also allows to
> de tune FROs when repeated pattern is coming out of FROs.
> This series also has few fixes for the driver
56 matches
Mail list logo