Hi Mythri,
On Friday 06 January 2012 06:14 PM, mythr...@ti.com wrote:
> From: Mythri P K
>
> 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
> ---
> drivers/video/omap2/dss/dss_features.c |1 +
> drive
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
On Fri, 2012-01-06 at 18:14 +0530, mythr...@ti.com wrote:
> From: Mythri P K
>
> 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.
>
> Signed-off-by: Myt
On Fri, Jan 6, 2012 at 9:58 PM, Ben Dooks 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
>
> Will add this later.
OK thanks.
--
To un
On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
wrote:
>
>
>
> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti 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 the driver a
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 hav
"Bedia, Vaibhav" 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 the
Tero Kristo 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 pointers
> for
Hi Tarun,
Tarun Kanti DebBarma 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 associated data member t
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[
0.00
Shubhrajyoti D 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
> Signed-off-by: Shubhrajyoti D
> ---
> applies on Tony's ehci branch.
> Compile tested only
Hi,
On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon 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 oprofile use
On Fri, Dec 9, 2011 at 8:02 AM, Benoit Cousson 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 bus?
Th
On 01/09/2012 03:11 PM, Kevin Hilman wrote:
NeilBrown 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
Missing 'ARM: ' prefix, but I added it locally and queued as a fix for
v3.3.
oops, sent this before I
NeilBrown 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
Missing 'ARM: ' prefix, but I added it locally and queued as a fix for
v3.3.
Thanks for the patch!
Kevin
--
To unsubscribe from this list: s
"Hiremath, Vaibhav" 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
>>
>> C
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 mai
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 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
> >
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 plugged
On Mon, 09 Jan 2012 12:46:43 + "Joe Woodward" 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:
>
> # echo me
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 t
Hi Laurent,
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 directly to frame buffer
> memory for display. It then passe
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 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 Co
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.
[
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
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 3
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 th
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
Signed-off-by: Shubhrajyoti D
---
applies on Tony's ehci branch.
Compile tested only.
drivers/mfd/omap-usb-host.c |6 +++
On Wed, Jan 4, 2012 at 5:44 AM, Kevin Hilman wrote:
> Shubhrajyoti D 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
>> Signed-off-by: Shubhrajyoti D
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
* 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.
33 matches
Mail list logo
