On 05/23/11 00:04, gr...@linuxhacker.ru wrote:
Hello!
Next attempt at BN Nook Color board file submission.
USB peripheral mode is fully operational as is serial console and
MMC/SDCard.
Changes
since v3:
Separated mach-types change into a separate patch (already got RMK
On Mon, May 23, 2011 at 02:43:24PM +0300, Tomi Valkeinen wrote:
Here are the OMAP Display Subsystem updates for 2.6.40.
Most of the patches are OMAP4 related, either fixing the old code to
allow us to implement new OMAP4 features, or implementing those new
features. Other bigger changes are
Hi Oleg,
Some comments below, mostly nitpicking, sorry...
On 05/23/11 00:04, gr...@linuxhacker.ru wrote:
From: Oleg Drokin gr...@linuxhacker.ru
Bare-bones board file, comes with serial console, gpio keys,
MMC/SDCard and USB (peripheral) support.
Signed-off-by: Oleg Drokin
* Felipe Balbi ba...@ti.com [110523 09:08]:
Hi,
On Wed, May 18, 2011 at 01:44:09PM +0300, Felipe Balbi wrote:
These are all supposed to go into -rc cycle but I guess we're already
too late for that (?). If so, let me know and I can add Cc:
sta...@kernel.org to all of those patches so
* Felipe Balbi ba...@ti.com [110523 11:11]:
On Mon, May 23, 2011 at 10:15:15AM +0300, Jarkko Nikula wrote:
On Mon, 23 May 2011 09:14:38 +0300
Felipe Balbi ba...@ti.com wrote:
a gentle ping here too. Without this we will have regressions on
ehci/ohci as the pm_runtime patches have
* Kevin Hilman khil...@ti.com [110520 18:21]:
Tony,
Please pull the following OMAP PM related cleanups for 2.6.40.
Pulled into for-next for this merge window.
arch/arm/mach-omap2/board-3430sdp.c | 19 --
arch/arm/mach-omap2/board-rx51.c| 18 +-
arch/arm/mach-omap2/cpuidle34xx.c
On Tue, 2011-05-24 at 15:38 +0900, Paul Mundt wrote:
On Mon, May 23, 2011 at 02:43:24PM +0300, Tomi Valkeinen wrote:
Here are the OMAP Display Subsystem updates for 2.6.40.
Most of the patches are OMAP4 related, either fixing the old code to
allow us to implement new OMAP4 features, or
From: Koen Kooi k...@dominion.thruhere.net
The USB enable GPIO has been inverted and the USER button moved.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v1:
* Limited line width to 80 chars max
* changed XM || XMC to cpu_is_omap3630()
Hi,
On Tue, May 24, 2011 at 11:52:45AM +0300, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [110523 11:11]:
On Mon, May 23, 2011 at 10:15:15AM +0300, Jarkko Nikula wrote:
On Mon, 23 May 2011 09:14:38 +0300
Felipe Balbi ba...@ti.com wrote:
a gentle ping here too. Without this
Hi All,
I am no success in booting up the ARM1176 processor with the
linux-2.6.32 kernel.
While googling about the ARM Harvard architecture, I came to know that
we have to flush/invalidate the D-Cache and I-Cache
when using the self modifying codes.
So here my questions/doubts :
1) Is'nt it the
On 5/23/2011 6:40 AM, Gulati, Shweta wrote:
Benoit,
On Fri, May 20, 2011 at 7:19 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Shweta,
On 5/13/2011 8:27 AM, Gulati, Shweta wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field
On 5/24/2011 12:04 PM, Balbi, Felipe wrote:
Hi,
On Tue, May 24, 2011 at 11:52:45AM +0300, Tony Lindgren wrote:
* Felipe Balbiba...@ti.com [110523 11:11]:
On Mon, May 23, 2011 at 10:15:15AM +0300, Jarkko Nikula wrote:
On Mon, 23 May 2011 09:14:38 +0300
Felipe Balbiba...@ti.com wrote:
a
Hi Samuel,
On Mon, May 23, 2011 at 3:10 AM, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Lesly,
On Tue, May 17, 2011 at 07:10:03PM +0530, Manuel, Lesly Arackal wrote:
Hi Samuel,
On Sat, May 14, 2011 at 12:09 AM, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Lesly,
On Fri, May 06, 2011
From: Charulatha V ch...@ti.com
With register offsets now defined for respective OMAP versions
we can get rid of cpu_class_* checks. In addition, organized
common initialization for the different OMAP silicon versions.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma
From: Charulatha V ch...@ti.com
Use memset to fill omap_gpio_reg_offs structure with 0x
instead of filling each and every undefined register offset
separately with USHRT_MAX in a given OMAP SoC. This would ease
while adding new register offsets in the future SoCs.
Signed-off-by: Charulatha V
From: Charulatha V ch...@ti.com
gpio_context array, which is used to save gpio bank's context,
is used only for OMAP3 architecture.
Move gpio_context as part of gpio_bank structure so that
it can be specific to each gpio bank and can be used for
any OMAP architecture
TODO: extend the gpio
From: Charulatha V ch...@ti.com
Make workaround_enabled flag bank-specific instead of using a single
flag for all the banks together. This would be helpful while making
use of runtime framework in OMAP GPIO driver which would make the
driver handle each GPIO bank independently.
Also rename
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
(bothe OMAP 2420 and 2430) not for OMAP3 which is incorrect.
Fix the above by providing non-wakeup GPIO information through pdata
It is not required to use hard-coded offsets any more in context
save and restore functions and instead use the generic offsets
which have been correctly initialized during device registration.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
---
From: Charulatha V ch...@ti.com
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
From: Charulatha V ch...@ti.com
In set_24xx_gpio_triggering(), for OMAP4, GPIO wakeup request
is set for all type of GPIO triggers whereas as per TRM the GPIO
wakeup request can only be generated on edge transitions. Fix this.
In set_24xx_gpio_triggering(), OMAP4_GPIO_IRQWAKEN0 register
is used
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO
banks 2-6 as GPIO bank1 is in wakeup domain. Instead
of identifying bank's power domain by bank id, make use
of a flag loses_context which is filled by
pwrdm_can_ever_lose_context() during dev_init.
For
From: Charulatha V ch...@ti.com
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle()
functions to handle save context restore context respectively in the
OMAP GPIO driver itself instead of calling these functions from pm specific
files. For this, in gpio_prepare_for_idle(), use
From: Charulatha V ch...@ti.com
gpio_bank_count is the count of number of GPIO devices
in a SoC. Remove this dependency from the driver. Also remove
the dependency on array of pointers to gpio_bank struct of
all GPIO devices.
TODO:
The save_context/ restore_context need to be modified to be
Since wake_status, wake_clear, wake_set is common for all banks on a given
OMAP version it is enough to get their values once during probe().
Also, register offsets are already initialzed according to OMAP versions
during device registration. We no longer need these explicit checks.
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module
during a gpio request/free.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c |2 +
arch/arm/mach-omap1/gpio16xx.c |2 +
arch/arm/mach-omap1/gpio7xx.c
From: Charulatha V ch...@ti.com
Modify the omap_gpio_save/restore_context to support OMAP4
architecture so that the OMAP GPIO driver need not be modified
when OMAP4 off mode support is available.
Signed-off-by: Charulatha V ch...@ti.com
---
drivers/gpio/gpio_omap.c | 130
Do some more cleanup of OMAP GPIO driver and avoid usage of gpio_bank_count
and gpio_bank pointer array by means of maintaining a list.
Patch series is on following commit of linux-omap-pm (branch: wip/gpio-cleanup):
commit d04952091a3b9b4b47696cee48e92a9173fd9ffb
GPIO: OMAP: cleanup show
On Wed, 2011-05-18 at 17:41 +0300, Tomi Valkeinen wrote:
On Wed, 2011-05-18 at 16:24 +0200, Kevin Hilman wrote:
Looking closer at the code, a zero return happens only when
1) no hwmod associated to omap_device
2) no power domain associated to hwmod
3) power domain has not (yet) lost
On 05/23/11 20:39, Ricardo Neri wrote:
Hi Steve,
Le mercredi 18 mai 2011 à 12:07 -0500, Steve Calfee a écrit :
On 05/17/11 22:41, Peter Ujfalusi wrote:
On Tuesday 17 May 2011 22:35:09 Steve Calfee wrote:
I think the generally accepted method of doing stuff like this is to
have the
On Tuesday, May 24, 2011, Menon, Nishanth wrote:
On Mon, May 23, 2011 at 19:05, Todd Poynor toddpoy...@google.com wrote:
On Mon, May 23, 2011 at 06:12:15PM -0500, Nishanth Menon wrote:
cpufreq table allocated by opp_init_cpufreq_table is better
freed by OPP layer itself. This allows future
On Thu, May 19, 2011 at 06:05:21PM +0530, Koyamangalath, Abhilash wrote:
I have tried the patch on am37x evm and the i2c soft-reset time-out issue
doesn't
seem to go off for me. Previously I used to get a log :
[0.00] omap_hwmod: i2c1: softreset failed (waited 1 usec)
Hi Tomi,
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-18 at 17:41 +0300, Tomi Valkeinen wrote:
On Wed, 2011-05-18 at 16:24 +0200, Kevin Hilman wrote:
Looking closer at the code, a zero return happens only when
1) no hwmod associated to omap_device
2) no power domain
Premi, Sanjeev pr...@ti.com writes:
[...]
[sp] I don't like #ifdefs either but each time we cannot create
a new file changes like this.
The current code is a mess with debugfs used too frequently.
And - all of it is not for debug. The location of ifdefs in
in the
Menon, Nishanth n...@ti.com writes:
On Thu, May 19, 2011 at 08:12, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
OMAP2 does not use OPP tables at the moment for DVFS. Currently,
we depend on opp table initialization to give us the freq_table,
which makes sense for
* Move variable declarations from header file and make these static
(the entire header file should probably go away).
* Define L3 TARG instance offsets, and read/write STDERRLOG registers
relative to those offsets, rather than defining STDERRLOG_MAIN
instance offsets and accessing other
37 matches
Mail list logo
