On Saturday 11 May 2013 08:05 AM, Tony Lindgren wrote:
Commit ad871c10 (ARM: dts: OMAP: Add usb_otg and glue data to
OMAP3+ boards) added support for MUSB on omap3 for device tree,
but added the interrupts the wrong way probably as they were
copied from the omap4.dtsi file. On omap3 we have TI
Added board specific dt data for omap3 beagle in omap3-beagle.dts
file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
On Mon, 2013-04-22 at 10:38 +0100, Mark Jackson wrote:
I'm trying to work out how to generate a valid UBI image, but I keep
getting a cannot get enough PEBs warning.
I generate my image (destined for a 64MB NAND partition) using:-
$ mkfs.ubifs -d output/target -e 0x1f000 -c 483 -m 0x800 -x
On 14.05.2013 15:01, Yegor Yefremov wrote:
On 14.05.2013 14:52, Felipe Balbi wrote:
On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote:
Trying to boot 3.10-rc1 on an am3515 based board. With the same
.config as 3.7 the system comes to RTC stops there. I've also tried
make
No changes to the patches itself.
Only the dependency on some omap-gpio enable_irq/disable_irq patch
has been removed.
While developing, I was struck by a bug with disable_irq. After reviewing
the disable_irq code path, I thought the interrrupt got never disabled
for omap. After fixing the bug
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4db8de5..2b2ec09 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -224,6 +224,7 @@ struct omap_hsmmc_host {
PSTATE shows current state of data lines.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2b2ec09..61c0254 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -53,6
On 15.05.2013 10:37, Yegor Yefremov wrote:
On 14.05.2013 15:01, Yegor Yefremov wrote:
On 14.05.2013 14:52, Felipe Balbi wrote:
On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote:
Trying to boot 3.10-rc1 on an am3515 based board. With the same
.config as 3.7 the system comes to RTC
On 23/04/13 09:14, Kishon Vijay Abraham I wrote:
After the device names are created using PLATFORM_DEVID_AUTO, the old
device names given in usb_bind_phy are no longer valid causing the musb
controller not to get the phy reference. Updated the usb_bind_phy with
the new device names to get MUSB
NM
On 05/15/2013 12:29 AM, Nishanth Menon wrote:
$subject - add a space?
s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
Will fix.
On 09:17-20130514, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
On Tuesday 14 May 2013 10:27 PM, Vincent Stehlé wrote:
From: Vincent Stehlé v-ste...@ti.com
OMAP5 needs SCU in SMP.
This fixes the following link errors:
arch/arm/mach-omap2/built-in.o: In function `scu_gp_set':
arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to
On Wednesday 15 May 2013 02:24 AM, Andreas Fenkart wrote:
OMAP4430 TRM chap. 25.4.5.2
To reduce dynamic consumption, an efficient idle scheme is based on the
following:
• An efficient local autoclock gating for each module
• The implementation of control sideband signals between the PRCM
Hi,
I am working on a dm3730 based camera.
The sensor input clock is provided by the cpu via the CAM_XCLK pin.
Here is the corresponding log :
[9.115966] Entering cam_set_xclk
[9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz
[9.121337] ov10x33 1-0010: sensor
On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130503 10:55]:
Looks like we can get VBUS interrupt before the ID interrupt
how can this happen ? VBUS interrupt happens when you connect to a port
which is sourcing VBUS to you, while ID interrupt
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
Hi Greg,
Sourav Poddarsourav.pod...@ti.com writes:
Move uart_console definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the
From: Santosh Shilimkar santosh.shilim...@ti.com
With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.
While at this, also remove unused sysc auto idle api from hwmod code.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.
The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in
From: Santosh Shilimkar santosh.shilim...@ti.com
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
As discussed on the list, in future if dma mode needs to be brought
back to this driver, UART sysc handling needs to be updated in
changes in v3:
1. Fix the patch ordering issue (which otherwise broke git-bisect) as pointed
out by Kevin Hilman. I missed re-sending these out with the fix in time for
the 3.10 merge window. Thanks to Nishanth Menon for picking these up and doing
a rebase against 3.10-rc1.
Thanks also to Sourav
_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)
However the same programming logic is missing when it comes to sidle
From: Santosh Shilimkar santosh.shilim...@ti.com
UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.
So remove the un-used slave idle platforms hooks now.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by:
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote:
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
Hi Greg,
Sourav Poddarsourav.pod...@ti.com writes:
Move uart_console definition to serial core header
Hello,
Idea is to add the missing bits under arch/arm/*omap* required
to enable by default the ti-soc-thermal driver. I am planing to
move it out of staging tree. It would be interesting to get
feedback from other ppl. By enabling it by default we could reach
more ppl for testing it across the
On Wednesday 15 May 2013 08:27 PM, Greg KH wrote:
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote:
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
Hi Greg,
Sourav Poddarsourav.pod...@ti.com writes:
Hello,
Idea is to add the missing bits under arch/arm/*omap* required
to enable by default the ti-soc-thermal driver. I am planing to
move it out of staging tree. It would be interesting to get
feedback from other ppl. By enabling it by default we could reach
more ppl for testing it across the
Introduce HAS_BANDGAP config entry. This config is a
boolean value so that arch code can flag is they
feature a bandgap device.
This config entry follows the same idea behind
ARCH_HAS_CPUFREQ.
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc:
This patch add the bandgap entry for OMAP4430 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
On Friday 10 May 2013 07:32 PM, Nishanth Menon wrote:
On 11:09-20130426, Kevin Hilman wrote:
Rajendra Nayak rna...@ti.com writes:
[...]
OMAP UART IP needs manual idle modes based on functional state of the
IP. Currently this is handled by the driver with function pointers
implemented in
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Hi Greg,
I have rebased this patch series on top of 3.10-rc1.
This patch series contains fixes around the issue that
the console UART should not idled on suspend while using
no_console_suspend in bootargs.
The approach thought of is to modify the serial core/serial driver to bypass
runtime PM
Move uart_console definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the uart_console defintion from mpc52xx_uart driver.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Reviewed-by: Felipe
The driver manages no_console_suspend by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Reviewed-by: Felipe Balbi ba...@ti.com
Reviewed-by: Kevin Hilmankhil...@linaro.org
Tested-by: Kevin Hilmankhil...@linaro.org
Signed-off-by: Sourav Poddar
Hi,
On Wednesday 15 May 2013 08:27 PM, Sourav Poddar wrote:
On Wednesday 15 May 2013 08:27 PM, Greg KH wrote:
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote:
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman
Hi Kevin,
Resending this patch series again on top of 3.10-rc1.
This is a cleanup series done in response to the
serial driver fixes done for no_console_suspend case.
This cleanups mainly include getting
rid of using omap_device_disable_idle_on_suspend api for both dt and non dt
case
as the
no_console_suspend is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Signed-off-by: Sourav Poddar
Remove no_idle_on_suspend check, since respective
driver should be able to prevent idling of an
omap device whenever required.
Driver's can get same behavior by just returning -EBUSY
from their -runtime_suspend only during suspend.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi
The ti,no_idle_on_suspend property was required to keep ocmcram clocks
running during idle.
But commit 72bb6f9 (ARM: OMAP: omap_device: don't attempt late suspend
if no driver bound), added in v3.6 should prevent any automatic clock
gating for devices without drivers bound. Since there is no
On 15-05-2013 11:23, Benoit Cousson wrote:
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
On 11:46-20130515, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files
* Mark A. Greer mgr...@animalcreek.com [130514 18:57]:
On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote:
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
changed PM to not access IVA registers on omaps that don't have
them. Turns out we still need to idle iva2 as
Hi,
Is it expected that after boot you get 0 brightness i.e. a seemingly
blank display on N900 with 3.10-rc1?
First thought after seeing a blank display was that the probe
issues are still there, but everything was fine and after setting
/sys/class/backlight/acx565akm/brightness you get a
On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote:
* Mark A. Greer mgr...@animalcreek.com [130514 18:57]:
On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote:
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
changed PM to not access IVA registers on
On 12:36 Wed 15 May , Eduardo Valentin wrote:
On 15-05-2013 11:23, Benoit Cousson wrote:
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc:
On 15/05/13 20:18, Aaro Koskinen wrote:
Hi,
Is it expected that after boot you get 0 brightness i.e. a seemingly
blank display on N900 with 3.10-rc1?
First thought after seeing a blank display was that the probe
issues are still there, but everything was fine and after setting
48 matches
Mail list logo
