On Tue, Aug 23, 2011 at 9:48 AM, Rajendra Nayak rna...@ti.com wrote:
On 8/23/2011 5:28 AM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com writes:
[...]
FWIK, its a one time requirement to set the clock rate to the
right rate the device can operate in based on what a platform
supports.
* Paul Walmsley p...@pwsan.com [110821 08:11]:
From: Tomi Valkeinen tomi.valkei...@ti.com
Set HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core to allow DSS reset
properly.
Can you please add what this fixes so this can be justified as a fix?
Add missing ick opt-clock for rfbi. Rfbi uses the
* Tony Lindgren t...@atomide.com [110823 09:20]:
* Paul Walmsley p...@pwsan.com [110821 08:11]:
From: Tomi Valkeinen tomi.valkei...@ti.com
Set HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core to allow DSS reset
properly.
Can you please add what this fixes so this can be justified as a
Hi Tomi,
On Tue, 23 Aug 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110821 08:11]:
From: Tomi Valkeinen tomi.valkei...@ti.com
Set HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core to allow DSS reset
properly.
Can you please add what this fixes so this can be justified as a
On 22/08/11 23:39, Hilman, Kevin wrote:
Liam Girdwood l...@ti.com writes:
On 05/08/11 20:33, Hilman, Kevin wrote:
Mark Brown broo...@opensource.wolfsonmicro.com writes:
On Thu, Jul 28, 2011 at 02:48:57PM +0300, Tero Kristo wrote:
OMAP SMPS regulator driver provides access to OMAP voltage
Hi Tony,
The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 prcm-fixes-a-3.1rc
I've dropped Tomi's patches until the changelogs for those are fixed.
* Paul Walmsley | 2011-08-22 23:10:21 [-0600]:
IRQ handler type mismatch for IRQ 74
It turns out that the omap-serial code used one threaded IRQ
handler[1][2] and one non-threaded IRQ handler[3] that shared the same
IRQ. During the 3.1-rc series, a patch was merged[4] that caused
IRQF_ONESHOT
On 8/23/2011 10:33 AM, G, Manjunath Kondaiah wrote:
Add omap4 soc dts file for handling omap4 soc i2c
controllers existing on l4-core bus.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |7 +---
arch/arm/boot/dts/omap4.dtsi | 68
On Mon, 22 Aug 2011 23:10:21 -0600 (MDT)
Paul Walmsley p...@pwsan.com wrote:
Convert the omap-serial hardirq handler to a threaded IRQ handler. Without
this patch, OMAP boards which use the on-board OMAP UARTs and the
omap-serial driver will not boot to userspace after commit
Hi,
This creates a build failure for non-omap platforms as they don't know
about struct omap_device_pm_latency, struct omap_hwmod etc.
An empty of_omap_device_create() as inline should do the trick.
Jamie
On Tue, Aug 23, 2011 at 10:03:35AM +0500, G, Manjunath Kondaiah wrote:
The omap
Hi,
On Mon, Aug 22, 2011 at 05:45:06PM -0600, Paul Walmsley wrote:
On Fri, 19 Aug 2011, Felipe Balbi wrote:
On Thu, Aug 18, 2011 at 07:22:39PM +0200, Sebastian Andrzej Siewior wrote:
Pantelis Antoniou wrote:
Let me report that with this change Beagle board fails to boot,
hangs
Hi,
On Mon, Aug 22, 2011 at 11:10:21PM -0600, Paul Walmsley wrote:
Convert the omap-serial hardirq handler to a threaded IRQ handler. Without
this patch, OMAP boards which use the on-board OMAP UARTs and the
omap-serial driver will not boot to userspace after commit
On Sun, Aug 21, 2011 at 08:05:53PM +0200, Rafael J. Wysocki wrote:
On Sunday, August 21, 2011, Mark Brown wrote:
I don't understand why the driver would need to know what situation it's
in. I'd been working on the basis that the idea was that the driver
said what the constraints it has
On Mon, Aug 22, 2011 at 04:00:35PM +0200, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Test the just-initialized value rather than some other one.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
identifier
Hi Javier,
On Tuesday 23 August 2011 12:16:16 javier Martin wrote:
On 22 August 2011 18:15, Koen Kooi k...@beagleboard.org wrote:
Op 22 aug. 2011, om 08:42 heeft javier Martin het volgende geschreven:
On 19 August 2011 17:07, Koen Kooi k...@beagleboard.org wrote:
Op 19 aug. 2011 om 14:39
These are the previously sent HWMOD patches split into smaller pieces and with
improved commit messages.
I'm not sure if these are strictly needed to be sent for -rc. The DSS patches
9ede365aa6f74428a1f69c21ca1cf21213167576 (HACK: OMAP: DSS2: clk hack for
OMAP2/3) and
DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
HWMOD framework does not
The OMAP2xxx HWMOD data currently contains two errors with DSS clocks:
- dss_rfbi is missing ick opt-clock, which is needed for RFBI to
calculate timings
- dss_venc's interface and main clocks are wrong, causing VENC to fail
to start
These problems were temporarily fixed with a DSS patch
DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
HWMOD framework does not
The OMAP3 HWMOD data currently contains these errors with DSS clocks:
- dss_rfbi is missing ick opt-clock, which is needed for RFBI to
calculate timings
- dss_dsi is missing ick and sys_clk
- dss_venc is missing dss_96m_fck opt-clock, which is required on
OMAP3430
- dss_venc's interface
Remove the dss_dss_clk from dss_core's opt-clocks. dss_dss_clk already
defined as the dss main_clk, and thus is not needed as an opt-clock.
Remove opt-clocks for dss_dispc, as dispc only uses the main_clk.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
HWMOD framework does not
The OMAP4 HWMOD data currently contains errors with DSS clocks:
dss_hdmi and dss_venc have their main_clks wrong. The clocks should be
dss_48mhz_clk and dss_tv_clk, respectively.
These problems were temporarily fixed with the DSS patches
9ede365aa6f74428a1f69c21ca1cf21213167576 (HACK: OMAP:
OMAP2/3 dss_core has a reset status flag in sysstatus register. Add
SYSS_HAS_RESET_STATUS flag to HWMOD data so it can be used.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |3 ++-
1
This patch adds a custom DSS reset function used on OMAPs from OMAP2
forward.
The function doesn't actually do a reset, it only waits for the reset to
complete. The reason for this is that on OMAP4 there is no possibility
to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
all
With commit f64ad1a0e21a, gpio/omap: cleanup _set_gpio_wakeup(), remove
ifdefs, access to build time conditionally omitted 'suspend_wakeup'
member of the 'gpio_bank' structure has been placed unconditionally in
function _set_gpio_wakeup(), which is always built. This resulted in the
driver
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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
Hi Manju,
Few minor comments about your subjects in this series.
Patch series reworked from:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/61674
Also added support for i2c1 controller on omap4 based panda
board.
Baseline:
=
git://git.secretlab.ca/git/linux-2.6.git
Branch:
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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,
use 'loses_context' flag which is filled by
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@ti.com
Currently gpio_context array 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
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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 Vch...@ti.com
---
Nice !!
Reviewed-by: Santosh Shilimkar
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
request/free.
Signed-off-by: Charulatha Vch...@ti.com
---
Looks good.
Reviewed-by: Santosh Shilimkar
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Wakeup istatus register offset initialized according to OMAP versions
/s/ istatus / status
during device registration. Use this to avoid version checks.
Starting with OMAP4, legacy registers should not be used in combination
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@ti.com
mpuio_init() function is defined under #ifdefs. It is required only in case
of MPUIO bank type and only when PM operations are supported by it.
This is applicable only in case of OMAP16xx SoC's MPUIO
From: G, Manjunath Kondaiahmanj...@ti.com
The generic board file is created and derived from omap4 panda board file.
The changes here focus on minimal configuration to boot panda board with
dt enabled which provides basic platform for converting device drivers for
using dt.
Signed-off-by: G,
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
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
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
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
This patch enables AM35x SoCs to use generic OMAP3 hwmods
(i,e. omap3xxx_hwmods) by allowing board-am3517evm.c to
disable the modules which are not present in AM3517.
Reviewed-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c
This patch-set gets the kernel booting up on a AM3517 EVM.
The board is able to boot with ramdisk after this,but the MMC and Ethernet
drivers are not up yet. Lots of warnings remain which will be addressed in
subsequent patches.
The patches are tested on master of tmlind/linux-omap-2.6.git.
From: Vaibhav Hiremath hvaib...@ti.com
In case of AM3517 AM3505, Smart Reflex is not applicable so
we must not enable it. So add check for absence of SR feature
in omap3_twl_init() and return -ENODEV if absence, else continue.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by:
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
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
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
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
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@ti.com
Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha Vch...@ti.com
---
Ok.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Regards
Santosh
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Abhilash K V
Sent: Tuesday, August 23, 2011 6:51 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; li...@arm.linux.org.uk; b-cous...@ti.com;
From: G, Manjunath Kondaiahmanj...@ti.com
To: devicetree-disc...@lists.ozlabs.org
CC: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org
Add omap4 soc dts file for handling omap4 soc i2c
controllers existing on l4-core bus.
The subject and changelog is not accurate. You are
On Wed, Aug 17, 2011 at 07:10:02PM -0400, Ohad Ben-Cohen wrote:
+/**
+ * omap_iommu_attach() - attach iommu device to an iommu domain
+ * @dev: target omap iommu device
+ * @iopgd: page table
**/
-struct iommu *iommu_get(const char *name)
+static struct iommu
Rafael, Kevin,
On latest kernel( V3.1-rc1+), the subsystem(driver) suspend
callbacks are not getting called because power domain callbcaks
are populated.
And as per commit 4d27e9dc{PM: Make power domain callbacks take
precedence over subsystem ones}, it's expected bahavior.
Who is suppose to
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@ti.com
Even when bank-width is 16, all the OMAP1 registers are 4-byte aligned, so just
use a 4-byte read. The 'enabled' mask is already taking care to mask for bank
width.
Signed-off-by: Charulatha
On Wed, Aug 17, 2011 at 07:10:01PM -0400, Ohad Ben-Cohen wrote:
1. Migrate OMAP's iommu driver to the generic IOMMU API, and move it
to the dedicated iommu folder.
2. Fix omap3isp appropriately so it doesn't break.
3. Adapt OMAP's iovmm appropriately as well, because omap3isp still relies
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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.
Signed-off-by: Charulatha
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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 Vch...@ti.com
---
Looks like a proper BUG fix.
Reviewed-by:
+ Rajendra and Benoit to comment on optional clock
handling.
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove syscore_ops and
instead use dev_pm_ops now.
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
There is no need to operate on all the banks every time the function is called.
Just operate on the current bank passed by the framework.
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
---
Good.
Reviewed-by: Santosh
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Simplify omap2_gpio_prepare_for_idle() and omap2_gpio_resume_after_idle()
/s /Simplify /Cleanup
by moving most of the stuff to *_runtime_suspend() and *_runtime_resume().
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Most operations within runtime callbacks should be skipped when
*_runtime_get_sync() and *_runtime_put_sync() are called in probe(),
*_gpio_request() and *_gpio_free(). We just need clock enable/disable.
Signed-off-by: Tarun Kanti
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Context is now saved dynamically in respective functions whenever and
whichever registers are modified. This avoid overhead of saving all
registers context in the runtime callback.
Signed-off-by: Tarun Kanti
On Aug 19, 2011, at 9:43 AM, Koul, Vinod wrote:
On Tue, 2011-08-16 at 15:06 +0200, Linus Walleij wrote:
On Tue, Aug 16, 2011 at 2:56 PM, Koul, Vinod vinod.k...@intel.com wrote:
Currently we have two approaches to solve this problem first being the
DMA_STRIDE_CONFIG proposed by Linus W, I
On Tuesday 23 August 2011 06:23 PM, Santosh wrote:
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@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
On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Can this be easily converted to a spin_lock?
Sure, thanks for reviewing.
--
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
On Tue, Aug 23, 2011 at 7:49 PM, Santosh santosh.shilim...@ti.com wrote:
Rafael, Kevin,
On latest kernel( V3.1-rc1+), the subsystem(driver) suspend
callbacks are not getting called because power domain callbcaks
are populated.
And as per commit 4d27e9dc{PM: Make power domain callbacks take
On Tue, Aug 23, 2011 at 01:53:54PM +0530, Rajendra Nayak wrote:
On 8/23/2011 10:33 AM, G, Manjunath Kondaiah wrote:
Add omap4 soc dts file for handling omap4 soc i2c
controllers existing on l4-core bus.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
On Tue, Aug 23, 2011 at 5:26 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Besides the locking issue these patches look good to me. Please repost
when this is solved and I will put it in my tree then.
Great, thanks !
I'll do a quick re-spin with the collected comments and ACKs and repost.
At
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Gpio 2 of the TPS65950 has to be set to zero in order to enable the HSUBS2
clock.
Signed-off-by: Bryan DE FARIA bdefa...@adeneo-embedded.com
---
arch/arm/mach-omap2/board-omap3evm.c | 24
1 files
On Tue, Aug 23, 2011 at 03:48:15PM +0200, Cousson, Benoit wrote:
From: G, Manjunath Kondaiahmanj...@ti.com
To: devicetree-disc...@lists.ozlabs.org
CC: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org
Add omap4 soc dts file for handling omap4 soc i2c
controllers existing on
On Tue, Aug 23, 2011 at 10:07:05AM +0100, Jamie Iles wrote:
Hi,
This creates a build failure for non-omap platforms as they don't know
about struct omap_device_pm_latency, struct omap_hwmod etc.
An empty of_omap_device_create() as inline should do the trick.
Thanks. I will introduce this.
On Tue, Aug 23, 2011 at 03:05:01PM +0200, Cousson, Benoit wrote:
From: G, Manjunath Kondaiahmanj...@ti.com
The generic board file is created and derived from omap4 panda board file.
The changes here focus on minimal configuration to boot panda board with
dt enabled which provides basic
On Tue, Aug 23, 2011 at 10:03:28AM +0500, G, Manjunath Kondaiah wrote:
Patch series reworked from:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/61674
Also added support for i2c1 controller on omap4 based panda
board.
Baseline:
=
git://git.secretlab.ca/git/linux-2.6.git
Hi Grant,
On Tue, Aug 23, 2011 at 10:03:36AM +0500, G, Manjunath Kondaiah wrote:
The device tree support has been added to i2c1 controller and
corresponding i2c initilization in generic board file is cleaned
up so that platfom device is registered through dt and omap device
and not through
On Tue, Aug 23, 2011 at 1:57 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Mon, 22 Aug 2011 23:10:21 -0600 (MDT)
Paul Walmsley p...@pwsan.com wrote:
Convert the omap-serial hardirq handler to a threaded IRQ handler. Without
this patch, OMAP boards which use the on-board OMAP UARTs and the
Linus,
On Tue, 23 Aug 2011, Linus Torvalds wrote:
but the there is no difference for others seems to be total crap,
exactly because it results in this IRQF mismatch.
So I think that commit should just be reverted. Thomas?
Yes. I missed that detail when I applied that patch. Reverting it
Hi Santosh,
Santosh santosh.shilim...@ti.com writes:
Rafael, Kevin,
On latest kernel( V3.1-rc1+), the subsystem(driver) suspend
callbacks are not getting called because power domain callbcaks
are populated.
And as per commit 4d27e9dc{PM: Make power domain callbacks take
precedence over
Janusz Krzysztofik jkrzy...@tis.icnet.pl writes:
With commit f64ad1a0e21a, gpio/omap: cleanup _set_gpio_wakeup(), remove
ifdefs, access to build time conditionally omitted 'suspend_wakeup'
member of the 'gpio_bank' structure has been placed unconditionally in
function _set_gpio_wakeup(),
This patch set is the v2 of TI816X clock and hwmods patches sent earlier.
The clock data is currently added only for TI816X, while minimal hwmod data
common for TI816X and TI814X is added.
This patch set depends on following patches:
TI81XX: Prepare for addition of TI814X support
This patch adds PRCM register offsets for TI816X device as required for the
clock data.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/cm816x.h | 368
arch/arm/mach-omap2/prm2xxx_3xxx.h | 17 ++
2 files changed, 385
This patch adds data for various clocks present in TI816X.
Note that this data is not automatically generated and not all clocks are
covered currently.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/clock816x.h | 21 +
arch/arm/mach-omap2/clock816x_data.c | 1108
This patch adds data for various clock domains and power domains in TI816X.
Note that at present this is not exhaustive and need to add missing domains.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/clockdomains816x_data.c | 172 +++
This patch hooks clock initialization and clockdomain/powerdomain setup into
OMAP clock framework.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/clock3xxx_data.c |5 ++-
This patch adds minimum required hwmod data (e.g., UARTs) for bootup of TI81XX
devices (currently common data for TI816X and TI814X is added).
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 677
1 files changed, 677
This patch integrates TI816X and TI814X hwmods into hwmods framework.
Note that a TI81XX specific function ti81xx_cm_wait_module_ready() is added to
wait for module to become ready since corresponding OMAP2/3 function
omap2_cm_wait_module_ready() cannot be used as there are no IDLEST registers in
Rajendra Nayak rna...@ti.com writes:
On 8/23/2011 5:28 AM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com writes:
[...]
FWIK, its a one time requirement to set the clock rate to the
right rate the device can operate in based on what a platform
supports.
Except $SUBJECT patch
On Tue, 23 Aug 2011, Felipe Balbi wrote:
if you're not running on a slow bus, you should use top half to check if
IRQs are really from this device.
I don't think this applies in this case, since the IRQ isn't shared
between different hardware devices - it's shared for the purposes of a
(+)
--- linux-next-20110823.orig/drivers/usb/dwc3/debugfs.c
+++ linux-next-20110823/drivers/usb/dwc3/debugfs.c
@@ -437,7 +437,9 @@ static int dwc3_testmode_open(struct ino
struct dwc3_gadget_ep_cmd_params par0;
struct dwc3_gadget_ep_cmd_params par1;
struct dwc3_trb trb
---
drivers/usb/dwc3/debugfs.c |4
1 file changed, 4 insertions(+)
--- linux-next-20110823.orig/drivers/usb/dwc3/debugfs.c
+++ linux-next-20110823/drivers/usb/dwc3/debugfs.c
@@ -437,7 +437,9 @@ static int dwc3_testmode_open(struct ino
struct dwc3_gadget_ep_cmd_params par0
From: G, Manjunath Kondaiahmanj...@ti.com
To: devicetree-disc...@lists.ozlabs.org
CC: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org
Update omap4 panda dts file with required clock frequencies
for the i2c client devices existing on panda board.
Signed-off-by: G, Manjunath
Hi Benoit,
On Wed, Aug 24, 2011 at 12:33 AM, Cousson, Benoit b-cous...@ti.com wrote:
From: G, Manjunath Kondaiahmanj...@ti.com
To: devicetree-disc...@lists.ozlabs.org
CC: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org
Update omap4 panda dts file with required clock
The device tree support has been added to i2c1 controller and
corresponding i2c initilization in generic board file is cleaned
up so that platfom device is registered through dt and omap device
and not through board i2c initilization.
A couple of typos in the changelog.
That patch should be in
On 8/23/2011 5:18 PM, G, Manjunath Kondaiah wrote:
On Tue, Aug 23, 2011 at 03:48:15PM +0200, Cousson, Benoit wrote:
From: G, Manjunath Kondaiahmanj...@ti.com
To: devicetree-disc...@lists.ozlabs.org
CC: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org
Add omap4 soc dts file
(+)
--- linux-next-20110823.orig/drivers/usb/dwc3/gadget.h
+++ linux-next-20110823/drivers/usb/dwc3/gadget.h
@@ -202,6 +202,11 @@ void dwc3_gadget_exit(struct dwc3 *dwc);
#else
static inline int dwc3_gadget_init(struct dwc3 *dwc) { return 0; }
static inline void dwc3_gadget_exit(struct dwc3 *dwc
On Tuesday, August 23, 2011, Mark Brown wrote:
On Sun, Aug 21, 2011 at 08:05:53PM +0200, Rafael J. Wysocki wrote:
On Sunday, August 21, 2011, Mark Brown wrote:
I don't understand why the driver would need to know what situation it's
in. I'd been working on the basis that the idea was
Hi,
On Sun, Aug 14, 2011 at 2:44 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Yeah, but with the current approach it would be possible that
everything works fine, and then the DSP goes to hibernation, a module
is loaded that uses one dm timer, and then when the DSP wakes up, that
Ben,
This series fell through the cracks for v3.1, so I've now rebased it
onto v3.1-rc3 and am submitting it for v3.2. It no longer has any
dependencies on OMAP trees, so could you please pull this into your tree
for linux-next?
A few more OMAP I2C series will be coming on top of this one.
Hi Ben,
Initially, these fixes were planned to be queued for v3.1-rc, but since
the previous series from Andy didn't make it into v3.1, it should be
queued for v3.2.
This branch is based on the for_3.2/i2c-andy branch (previous pull request.)
Please pull into your tree for linux-next.
Thanks,
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2/i2c-fixes branch just submitted.
Please pull into your tree for linux-next.
Thanks,
Kevin
The following changes since commit f3cb1e11c4e54f4dc7e60f9513d43ffa0bbebc25:
Revert i2c-omap: fix static suspend vs.
On 8/23/2011 8:04 PM, Santosh wrote:
+ Rajendra and Benoit to comment on optional clock
handling.
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove
On 8/23/2011 10:45 PM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com writes:
On 8/23/2011 5:28 AM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com writes:
[...]
FWIK, its a one time requirement to set the clock rate to the
right rate the device can operate in based on what a platform
97 matches
Mail list logo
