* Cousson, Benoit wrote:
Hi Thierry,
On 1/6/2012 3:28 PM, Thierry Reding wrote:
The irq_domain_add() function needs the number of interrupts in the
domain to properly initialize them. In addition the allocated domain
is now returned by the irq_domain_{add,generate}_simple() helpers.
Hi Grant,
On 1/6/2012 10:22 PM, Grant Likely wrote:
On Tue, Dec 20, 2011 at 02:39:55PM +0100, Benoit Cousson wrote:
[...]
+ /*
+* XXX: Use a 0 irq_base for the moment since the legacy devices
+* created statically are expected a hwirq = irq mapping.
+* A proper
Currently the runtime functions are compiled regardless
of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
using SET_RUNTIME_PM_OPS.
Cc : Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
applies on Tony's ehci branch.
Compile tested only.
On Fri, 2011-12-30 at 04:04 +0100, Janusz Krzysztofik wrote:
This functionality has just been implemented in the cx20442 codec
driver, no need to keep it here duplicated.
Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the board header file and a call to the
Hi Sebastian,
I am planning to ask Linus to pull the HSI framework in a couple of
days. Today, I have just rebased the patches against v3.2 tag and I am
waiting that everything is ok on linux-next to go ahead. In theory
should not be any problem.
About OMAP SSI driver, I will try to have it for
On 1/6/2012 10:30 PM, Rob Herring wrote:
On 01/06/2012 03:15 PM, Grant Likely wrote:
On Tue, Dec 20, 2011 at 02:39:54PM +0100, Benoit Cousson wrote:
The GIC binding was updated in 3.2 and expect 3 interrupt-cells.
- Update the #interrupt-cells
- interrupt-parent seems to be needed as well for
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected
via the DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on 3.2 I get the following:
# echo mem /sys/power/state
[ 23.186279] PM: Syncing filesystems ... done.
[
Hi Tony,
If this is not too late, could you please pull the OMAP interrupt controllers
adaptation to device tree?
This series is based on your lo/dt branch to get the DTS and board cleanup.
Thanks,
Benoit
The following changes since commit 40c0591f0a349ec074357e05c6ab1a3bc951807c:
Benoit
Hi Tony,
If this is not too late, could you please pull the various OMAP device tree
patches?
This series assume that all the drivers adaptation to DT are already merged and
is based on my previous interrupt controller series.
It means it has a strong dependency with i2c tree, mfd tree and rtc
Hi Laurent,
On Sun, Jan 8, 2012 at 12:17 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi,
I'm hitting what seems to be a tidspbridge driver issue when using gst-dsp
with the DSP JPEG encoder.
My application captures images from the OMAP3 ISP directly to frame buffer
memory
Hi Omar,
On Monday 09 January 2012 18:30:11 Ramirez Luna, Omar wrote:
On Sun, Jan 8, 2012 at 12:17 PM, Laurent Pinchart wrote:
Hi,
I'm hitting what seems to be a tidspbridge driver issue when using
gst-dsp with the DSP JPEG encoder.
My application captures images from the OMAP3 ISP
On Mon, 09 Jan 2012 12:46:43 + Joe Woodward j...@terrafix.co.uk wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected
via the DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on 3.2 I get the
following:
Hi Will,
Thanks for the fixes to kexec for ARM that went into mainline this
week. Mostly things work now.
One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
work after a kexec. During boot after kexec, the host device is
detected and initialised, but nothing
On Mon, Jan 09, 2012 at 04:39:09PM +, Maynard Johnson wrote:
On 01/08/2012 8:58 PM, Lik Lik wrote:
Hi all,
Hi guys [adding a bunch of people to CC because this issue is really
annoying me now],
I am an oprofile user and I need to profile one of my applications on a TI
OMAP4
On Mon, Jan 09, 2012 at 10:09:54PM +, Peter Chubb wrote:
Hi Will,
Hi Peter [adding linux-arm-kernel],
Thanks for the fixes to kexec for ARM that went into mainline this
week. Mostly things work now.
Great, that's good to hear!
One issue: the USB EHCI port on the (rev C2)
On Mon, Jan 09, 2012 at 10:54:03PM +, Will Deacon wrote:
On Mon, Jan 09, 2012 at 10:09:54PM +, Peter Chubb wrote:
Hi Will,
Hi Peter [adding linux-arm-kernel],
*Actually* adding linux-arm-kernel this time...
Thanks for the fixes to kexec for ARM that went into mainline
Hiremath, Vaibhav hvaib...@ti.com writes:
-Original Message-
From: Hilman, Kevin
Sent: Saturday, January 07, 2012 12:24 AM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsley; Hiremath, Vaibhav
Subject: [RFC/PATCH 8/7] ARM: OMAP: AM35xx: convert 3517 detection/flags
to AM35xx
NeilBrown ne...@suse.de writes:
opp_find_freq_ceil and opp_get_voltage are documented as requiring
rcu_lock to be held. So hold it.
Signed-off-by: NeilBrown ne...@suse.de
Missing 'ARM: ' prefix, but I added it locally and queued as a fix for
v3.3.
Thanks for the patch!
Kevin
--
To
On 01/09/2012 03:11 PM, Kevin Hilman wrote:
NeilBrownne...@suse.de writes:
opp_find_freq_ceil and opp_get_voltage are documented as requiring
rcu_lock to be held. So hold it.
Signed-off-by: NeilBrownne...@suse.de
Missing 'ARM: ' prefix, but I added it locally and queued as a fix for
v3.3.
On Fri, Dec 9, 2011 at 8:02 AM, Benoit Cousson b-cous...@ti.com wrote:
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
Why is this ti,? For EDID, isn't the I2C device actually on the
monitor itself, and DVI cable just connects to the I2C
Hi,
On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon will.dea...@arm.com wrote:
On Mon, Jan 09, 2012 at 04:39:09PM +, Maynard Johnson wrote:
On 01/08/2012 8:58 PM, Lik Lik wrote:
Hi all,
Hi guys [adding a bunch of people to CC because this issue is really
annoying me now],
I am an
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the runtime functions are compiled regardless
of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
using SET_RUNTIME_PM_OPS.
Cc : Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
Initializing cgroup subsys cpuset[ 0.00] Initializing cgroup
subsys cpu[ 0.00] Linux version 3.2.0-omap4 (eranian@panda)
(gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #9 SMP PR[
Hi Tarun,
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value
Tero Kristo t-kri...@ti.com writes:
This is needed for SMPS regulators, which use the OMAP voltage
processor for voltage get/set functions instead of the normal I2C
channel. For this purpose, regulator_init_data-driver_data contents
are expanded, it is now a struct which contains function
Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi Paul,
On Fri, Dec 16, 2011 at 03:06:09, Paul Walmsley wrote:
Hi,
This is a repost of Tero's PRCM chain handler patch set with a few changes:
- A new mux patch has been added to place hwmod mux entries with
OMAP_DEVICE_PAD_WAKEUP set into
On Mon, Jan 09, 2012 at 05:11:11PM -0800, Kevin Hilman wrote:
Seems to me like the get/set override should be more generic (part of
regulator core) instead of TWL specific?
Otherwise, whenever someone hooks up a non-TWL regulator to an OMAP and
is using HW control (via VC/VP), they'll have
On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
shubhrajy...@ti.com wrote:
On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
Ben,
On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote:
Hi
On Tue, 13 Dec 2011, Shubhrajyoti D wrote:
- The reset in
On Fri, Jan 6, 2012 at 9:58 PM, Ben Dooks ben-...@fluff.org wrote:
On Tue, Dec 20, 2011 at 12:55:59PM +0530, Shubhrajyoti D wrote:
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Will add this
On Fri, 2012-01-06 at 18:14 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add support for HPD GPIO configuration in board file.
Also remove the enabling of GPIO's required for HDMI from
hdmi driver file to display.c based on the GPIO #'s sent from
board file.
On Tue, 2012-01-10 at 09:37 +0200, Tomi Valkeinen wrote:
I still think we should try to fix the bug at hand, not try to implement
proper HPD support. Was there something wrong with the example patch I
gave? (other than it needs some splitting up).
And one reason I'm saying we shouldn't try to
Hi Mythri,
On Friday 06 January 2012 06:14 PM, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
GPIO based handling of connect/disconnect of the HDMI cable
(Hot-plug detect)is added to the HDMI driver.
Signed-off-by: Mythri P K mythr...@ti.com
---
32 matches
Mail list logo
