On Tuesday 20 September 2011 15:33:12 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [110920 14:12]:
On Tuesday 20 September 2011, Arnd Bergmann wrote:
One more thing: my randconfig tests are running now and
have spit out a new error after merging lost of stuff
today:
Good
Hi,
Looks like beagle xM can't wakeup from S2R, and the kernel is 3.1-rc4.
See dmesg below:
root@beagleboard:~#
root@beagleboard:~# echo 9 /proc/sys/kernel/printk
root@beagleboard:~# echo platform /sys/power/pm_test
root@beagleboard:~# echo mem /sys/power/state
[ 69.132354] PM: Syncing
Hi
a few comments.
First, as Govindraj mentioned, this should be cc'ed to
linux-arm-ker...@lists.infradead.org. It's surprising that the linux-arm
mailing list is still running...
On Fri, 16 Sep 2011, Tero Kristo wrote:
This driver will eventually support OMAP soc PRM module features,
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:30 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for
Hi
some comments (also see the comments for the 1/16 patch, some of which
apply to this patch)
On Fri, 16 Sep 2011, Tero Kristo wrote:
diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c
index dfc0920..880748a 100644
--- a/drivers/power/omap_prm.c
+++
Hi Deepthy,
On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote:
On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote:
On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
register for UYVY8_2X8 and YUYV8_2X8
Hi
a few more comments here:
On Fri, 16 Sep 2011, Tero Kristo wrote:
diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c
index dfc0920..880748a 100644
--- a/drivers/power/omap_prm.c
+++ b/drivers/power/omap_prm.c
#define DRIVER_NAME omap-prm
+#define
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now
On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
It seems that you replace the #ifdef in the board-flash.c file
with a similar #ifdef in the header that replaces this with an
empty inline function when the object is not built.
Found another similar problem over night, presumably in
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant
On Wed, 21 Sep 2011, Yong Zhang wrote:
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn
Hi,
On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Hi,
On Wednesday 21 September 2011 02:10 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:30 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Converting uart driver to adapt to pm runtime API's.
Code re-org + cleanup.
Moving some functionality from serial.c to omap-serial.c
Changes involves:
1.) Cleaning up certain uart calls from sram_idle func.
2.) Removed all types of uart clock handling code from serial.c
3.) Using
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Wake up event set will be cleared on pad mux_read.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
Currently we use a shared irq handler to identify uart activity and then
trigger a timer. Based the timeout value set from sysfs the timer used to
expire. If no uart-activity was detected timer-expiry func sets can_sleep
flag. Based on this we will disable the uart clocks in idle path.
Since the
We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250 support for
omap-uarts.
Serial_in and serial_out
In preparation to UART runtime conversion remove uart specific calls
from pm24xx/34xx files and their definition from serial.c
These func calls will no more be used with upcoming uart runtime design.
1.) omap_uart_can_sleep :- currently used to set uart-can_sleep flag based
on which uart
Removing some of the uart info that is maintained in omap_uart_state struct
used for UART PM in serial.c.
Remove omap_uart_state struct dependency from omap_serial_init,
omap_serial_init_port, omap_serial_early_init and omap_uart_idle_init functions.
And populate the same info in
In preparation to runtime conversion add missing uart regs to
port structure which can be used in context restore.
Also ensuring all uart reg info's are part of port structure.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |3 ++
Prior to this change rx-pad wakeup was done by writing to rx-pad offset value
populated in serial.c idle_init. Now with mux framework support we can use
mux_utilities along with hmwod framework to handle io-pad configuration and
enable rx-pad wake-up mechanism.
Add default mux data for all uart's
Adapts omap-serial driver to use pm_runtime API's.
Use runtime runtime API's to handle uart clocks and obtain
device_usage statics. Set runtime API's usage to irq_safe so that
we can use get_sync from irq context. Auto-suspend for port specific
activities and put for reg access. Use
From: Deepak K deepa...@ti.com
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as from on errata will be handled in driver file itself.
In suspend path the console_lock is taken by uart_port_suspend
however when no_console_suspend is used console_lock is not taken.
During system wide suspend omap_pwr_domain hooks cut all
clocks that are left enabled. So its unsafe to proceed printing after
clocks are cut by pwr_domain hooks. Also
If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.
If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive pm_runtime calls,
which can cause a deadlock over power
For the early console probing we had avoided hwmod reset and idling
and uart was idled using hwmod API and enabled back using omap_device API
after omap_device registration.
Now since we are using runtime API's to enable back uart move hwmod idling and
use runtime API to enable back UART.
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
Kevin,
* Arnd Bergmann a...@arndb.de [110921 01:55]:
On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
It seems that you replace the #ifdef in the board-flash.c file
with a similar #ifdef in the header that replaces this with an
empty inline function when the object is not
On Wednesday 21 September 2011, Tony Lindgren wrote:
* Ohad Ben-Cohen o...@wizery.com [110920 01:34]:
On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm wondering how hwspinlock updates like this should go upstream.
The first hwspinlock batch was picked by
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
From: Charulatha V ch...@ti.com
The gpio_bank_count is the count of number of GPIO devices in a SoC. Remove
this
dependency from the driver by using list. Also remove the dependency on array
of
pointers to gpio_bank struct of all
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
From: Charulatha V ch...@ti.com
The context lost count is modified in omap_sram_idle() path when
pwrdm_post_transition() is called. But pwrdm_post_transition() is called
only after omap_gpio_resume_after_idle() is called. Correct this
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
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
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]:
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making
non_wakeup_gpios as part of pdata.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
Wakeup enable register offset initialized according to OMAP versions
during device registration. Use this to avoid version checks.
Starting with OMAP4, legacy registers should not be used in combination
with the updated regsiters. Use
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]:
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
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
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
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
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 Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
Also, use wkup_status register consistently instead of referring to wakeup
clear and
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]:
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions. Initialization specific to OMAP16xx has been moved within
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
From: Charulatha V ch...@ti.com
Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren
On Tue, Sep 20, 2011 at 04:13:40PM -0700, Tony Lindgren wrote:
* Ohad Ben-Cohen o...@wizery.com [110920 01:34]:
On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm wondering how hwspinlock updates like this should go upstream.
The first hwspinlock batch was
On Tue, Aug 30, 2011 at 04:38:50PM +0300, Jarkko Nikula wrote:
Tested-by: Jarkko Nikula jarkko.nik...@bitmer.com
I applied these with the last two patches squashed together in order to
preserve bisection - the two patches should have been combined as patch
2 removes a field that the existing
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
From: Charulatha V ch...@ti.com
Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]:
From: Charulatha V ch...@ti.com
The only bank-type (method) used in the OMAP GPIO driver is MPUIO type as
they
need to be handled separately. Identify the same using a flag and remove all
METHOD_* macros.
mpuio_init() function is
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]:
From: Charulatha V ch...@ti.com
In all OMAP1 SoCs, the MPUIO bank width is 16 bits. But, in OMAP7xx,
it is wrongly initialised to 32. Fix this.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]:
Unless the dbclk aliases are assigned, clk_get(bank-dev, dbclk)
would not fetch the associated clock handle. As a result, we would
not be able to turn on/off the debounce clock. This was preventing
the gpio modules going to low power
* Greg KH g...@kroah.com [110921 07:27]:
On Tue, Sep 20, 2011 at 04:13:40PM -0700, Tony Lindgren wrote:
* Ohad Ben-Cohen o...@wizery.com [110920 01:34]:
On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm wondering how hwspinlock updates like this should go
* Arnd Bergmann a...@arndb.de [110921 06:39]:
On Wednesday 21 September 2011, Tony Lindgren wrote:
* Ohad Ben-Cohen o...@wizery.com [110920 01:34]:
On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm wondering how hwspinlock updates like this should go upstream.
On Tuesday 20 September 2011 08:31 PM, Santosh Shilimkar wrote:
On Friday 16 September 2011 11:26 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
[...]
#define OMAP44XX_EMIF2_SIZESZ_1M
#define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE
On Wed, Sep 21, 2011 at 4:12 PM, Arnd Bergmann a...@arndb.de wrote:
My feeling is that it would be best for Ohad to send these directly
to Linus, since it's basically a standalone subsystem and he's listed
as the maintainer (well, after this series at least).
I agree. That's the path of least
On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote:
Ohad can you please try this first? Just please make sure your patches are
first in next tree before sending in the pull request.
Sure thing.
Stephen, I'll send you the location of my tree in a few.
Thanks,
Ohad.
--
To
On Wed, Sep 21, 2011 at 6:56 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote:
Ohad can you please try this first? Just please make sure your patches are
first in next tree before sending in the pull request.
Sure thing.
* Ohad Ben-Cohen o...@wizery.com [110912 09:14]:
hwspinlock devices provide system-wide hardware locks that are used
by remote processors that have no other way to achieve synchronization.
For that to work, each physical lock must have a system-wide unique id
number that all processors are
* Ohad Ben-Cohen o...@wizery.com [110921 08:34]:
On Wed, Sep 21, 2011 at 6:56 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote:
Ohad can you please try this first? Just please make sure your patches are
first in next tree before
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power domain.
The power domains get the
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers magically coming from.
ToDo:
- Measure the wake-up latencies for all power domains for OMAP3
-
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf.
On Wed, Sep 21, 2011 at 7:14 PM, Tony Lindgren t...@atomide.com wrote:
OK acked the related patch.
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
. Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints
. Remove the remove the latency related functions from OMAP PM in favor of
the generic per-device PM QoS API
. Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which
Remove the following functions from the API:
omap_pm_set_max_mpu_wakeup_lat
omap_pm_set_max_dev_wakeup_lat
omap_pm_set_max_sdma_lat
The generic per-device PM QoS functions shall be used instead, cf.
include/linux/pm_qos.h.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power state of the MPU subsystem.
The
On Wednesday 21 September 2011, Linus Walleij wrote:
On Wed, Sep 21, 2011 at 4:12 PM, Arnd Bergmann a...@arndb.de wrote:
My feeling is that it would be best for Ohad to send these directly
to Linus, since it's basically a standalone subsystem and he's listed
as the maintainer (well, after
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency
The MPU latency figures for cpuidle include the MPU itself and also
the peripherals needed for the MPU to execute instructions (e.g.
main memory, caches, IRQ controller, MMU etc). On OMAP3 those
peripherals belong to the MPU and CORE power domains and so the
cpuidle C-states are a combination of
From: Jean Pihet j-pi...@ti.com
. Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints
. Remove the remove the latency related functions from OMAP PM in favor of
the generic per-device PM QoS API
. Implement the devices wake-up latency constraints using the global
device
From: Jean Pihet j-pi...@ti.com
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power
From: Jean Pihet j-pi...@ti.com
Remove the following functions from the API:
omap_pm_set_max_mpu_wakeup_lat
omap_pm_set_max_dev_wakeup_lat
omap_pm_set_max_sdma_lat
The generic per-device PM QoS functions shall be used instead, cf.
include/linux/pm_qos.h.
Signed-off-by: Jean Pihet
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power
From: Jean Pihet j-pi...@ti.com
The MPU latency figures for cpuidle include the MPU itself and also
the peripherals needed for the MPU to execute instructions (e.g.
main memory, caches, IRQ controller, MMU etc). On OMAP3 those
peripherals belong to the MPU and CORE power domains and so the
From: Jean Pihet j-pi...@ti.com
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers magically coming from.
ToDo:
- Measure the wake-up latencies
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf.
Hi,
Sorry I was missing the 'From:' line. Patch sent has been resent properly.
On Wed, Sep 21, 2011 at 6:24 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Regards,
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Hi Arnd,
Arnd Bergmann a...@arndb.de writes:
On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
It seems that you replace the #ifdef in the board-flash.c file
with a similar #ifdef in the header that replaces this with an
empty inline function when the object is not built.
Found
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Tuesday 20 September 2011 08:31 PM, Santosh Shilimkar wrote:
On Friday 16 September 2011 11:26 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
[...]
#define OMAP44XX_EMIF2_SIZE SZ_1M
#define
This patch set adds support for DM814x/AM387x device series having Cortex-A8
MPU.
The technical documents are available from following link:
http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html
This series is referred in code as TI814X.
Since these devices share similar architecture
This patch updates existing macros, functions used for TI816X, to enable
addition of other SoCs belonging to TI81XX family (e.g., TI814X).
The approach taken is to use TI81XX/ti81xx for code/data going to be common
across all TI81XX devices.
cpu_is_ti81xx() is introduced to handle code common
This patch adds cpu type, macros for identification of TI814X device.
Note that following update to common OMAP data structures is made:
cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct
clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from
u8.
This patch adds minimal support and build configuration for TI8148 EVM. Also
adds support for low level debugging on UART1 console on the EVM.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +++
arch/arm/mach-omap2/Makefile
Tony,
I'm looking at creating a public repository to hold patches not yet in
shape for inclusion in linux-omap (if not personally, then someone at
TI that meets the below charter). I know there can be concern that
this becomes a distraction if we start pulling in community patches.
It seems it
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110915 16:23]:
Kevin Hilman khil...@ti.com writes:
Please pull this omap_device cleanup series for v3.2. This sets the
groundwork for Benoit's DT infrastructure work.
Turns out this series has a dependency on a
On Wed, Sep 21, 2011 at 05:28:50PM +0800, Yong Zhang wrote:
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit
Hi,
* Jason Kridner jkrid...@beagleboard.org [110921 10:56]:
Tony,
I'm looking at creating a public repository to hold patches not yet in
shape for inclusion in linux-omap (if not personally, then someone at
TI that meets the below charter). I know there can be concern that
this becomes a
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
- omap2_set_globals_ti816x();
-
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
+
+static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
+};
+
+static void __init ti8148_evm_init(void)
+{
+ omap_serial_init();
+ omap_board_config = ti8148_evm_config;
+ omap_board_config_size =
Cousson, Benoit b-cous...@ti.com writes:
On 9/17/2011 6:13 PM, Grant Likely wrote:
On Fri, Sep 16, 2011 at 04:43:19PM +0200, Benoit Cousson wrote:
[...]
+}
+
+static int _omap_device_notifier_call(struct notifier_block *nb,
+ unsigned long event, void *dev)
On Wed, Sep 21, 2011 at 4:23 PM, Tony Lindgren t...@atomide.com wrote:
Hi,
* Jason Kridner jkrid...@beagleboard.org [110921 10:56]:
Tony,
I'm looking at creating a public repository to hold patches not yet in
shape for inclusion in linux-omap (if not personally, then someone at
TI that
* Kevin Hilman khil...@ti.com [110915 16:23]:
Kevin Hilman khil...@ti.com writes:
Please pull this omap_device cleanup series for v3.2. This sets the
groundwork for Benoit's DT infrastructure work.
Turns out this series has a dependency on a patch[1] in Russell's
for-next branch.
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
static void __init
Tony Lindgren wrote on Thursday, September 22, 2011 2:18 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
+
+static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
+}; +
+static void __init ti8148_evm_init(void)
+{
+omap_serial_init();
+omap_board_config =
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
The request functions now verify the success of omap_dm_timer_prepare() call
after a timer is acquired. If *_prepare() fails then we have to release the
timer. In order to avoid race condition during this time, include *_prepare()
* Arnd Bergmann a...@arndb.de [110920 23:34]:
On Tuesday 20 September 2011 15:33:12 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [110920 14:12]:
On Tuesday 20 September 2011, Arnd Bergmann wrote:
One more thing: my randconfig tests are running now and
have spit out a new
Hi Tarun,
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
Adaptation of dmtimer code to platform driver using omap_device and
omap_hwmod abstraction. It also include pm-runtime and off-mode support.
I've applied these into dmtimer branch with some changes to simplify
things further.
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
@@ -514,10 +514,23 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-pdev = pdev;
- /* Skip pm_runtime_enable for OMAP1 */
- if (!pdata-needs_manual_reset) {
1 - 100 of 109 matches
Mail list logo
