On Tue, 2011-11-15 at 19:20 +0530, mythr...@ti.com wrote:
> From: Mythri P K
>
> Disables the internal pull resistor for SDA and SCL which are enabled by
> default, as there are expernal pull up's in 4460 and 4430 ES2.3
> SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
>
On Wed, 2011-11-16 at 11:01 +0530, K, Mythri P wrote:
> On Mon, Nov 14, 2011 at 1:03 PM, Tomi Valkeinen wrote:
> > On Fri, 2011-11-11 at 18:39 +0530, mythr...@ti.com wrote:
> >> -static int get_timings_index(void)
> >> +static bool hdmi_find_code(const struct hdmi_config *timings_arr,
> >> +
Hi Kevin,
On Friday 18 November 2011 01:05 AM, Kevin Hilman wrote:
Rajendra Nayak writes:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hm
This is to inform you that your recent unsubscribe request was unsuccessful.
This is probably because we could find no current subscription in your name.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Thu, Nov 17, 2011 at 3:42 AM, DebBarma, Tarun Kanti
wrote:
...
Is the intention to restrict enabling the dmtimer clocks from hard|soft
irqs?
>>> The aim is to prevent client drivers perform clock enable/disable
>>> independently.
>>> Instead just use the request/start/stop APIs. In
Hi,
On Fri, Nov 18, 2011 at 3:36 AM, Kevin Hilman wrote:
> OK, but that doesn't mean you have to keep sending it. It just means
> Tony's fixes branch isn't in -next (yet.)
I do not care about which one is merged, but don't want to apply
the fix patch manually for each test, :-)
In fact, there
chip->irq_ack is never called for nested threaded IRQs, because they
don't have a primary IRQ handler.
So we must ACK the IRQs in the toplevel retu and tahvo IRQ handler threads.
Signed-off-by: Michael Buesch
---
Index: linux-3.1.1/drivers/cbus/retu.c
===
This fixes the initialization of retu/tahvo cached IRQ masks.
Signed-off-by: Michael Buesch
---
Index: linux-3.1.1/drivers/cbus/retu.c
===
--- linux-3.1.1.orig/drivers/cbus/retu.c2011-11-17 23:09:26.498214061
+0100
+++ li
Tero Kristo writes:
> Introduce a chained interrupt handler mechanism for the PRCM
> interrupt, so that individual PRCM event can cleanly be handled by
> handlers in separate drivers. We do this by introducing PRCM event
> names, which are then matched to the particular PRCM interrupt bit
> depen
On Wed, 2011-11-16 at 10:48 +0530, Shubhrajyoti D wrote:
> Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of
> oring with ARCH2/3/4.
>
> Reported-by: Russell King
> Signed-off-by: Shubhrajyoti D
Pushed to l2-mtd-2.6, thanks!
Artem.
--
To unsubscribe from this list: send the line "uns
The Devkit8000 uses a TWL4030 pin for card detection.
Thats why the error:
_omap_mux_init_gpio: Could not set gpio192
occurs.
This patch checks that the pin is on OMAP before
calling omap_mux_init_gpio.
Signed-off-by: Thomas Weber
---
Changelog:
v2: Remove backslash at end of line
arch/arm/mac
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> 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
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> 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 Beagle
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> 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
Shubhrajyoti D writes:
> The register IRQENABLE_CLR is a bit map of interrupt events.
> All the bits have to be cleared to clear the interrupts.
>
> Signed-off-by: Vikram Pandita
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/i2c/busses/i2c-omap.c |2 +-
> 1 files changed, 1 insertions(+)
Ming Lei writes:
> On Wed, Nov 9, 2011 at 3:24 AM, Kevin Hilman wrote:
>> tom.leim...@gmail.com writes:
>>
>>> From: Ming Lei
>>>
>>> The patch fixes the compile failure:
>>>
>>> CC arch/arm/mach-omap2/cpuidle34xx.o
>>> arch/arm/mach-omap2/cpuidle34xx.c:317:12: error: 'THIS_MODULE'
>>> u
Rajendra Nayak writes:
> A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
> enabled state by the hwmod framework post the initial setup.
> Once a real user of the device (a driver) tries to enable it
> at a later point, the hmwod framework throws a WARN() about
> the device being already
"Premi, Sanjeev" writes:
[...]
>>
>> If PMIC is not TWL family, then I don't expect any functions in
>> twl_common.c to be called.
>
> This is the reason I wanted to know if the check on ".irq" in the
> patch is sufficient. If any PMIC requires & sets "pmic_i2c_board_info.irq"
> then both omap3
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
wrote:
> For now, the Samsung GPIO, Pinconfig and Pinmux information is
> represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
> i2c
> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, November 17, 2011 5:25 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
> Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with
> voltage layer when
On Thursday 17 November 2011 04:09 PM, Cousson, Benoit wrote:
+ Paul
On 11/17/2011 11:11 AM, Rajendra Nayak wrote:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
a
On 17 November 2011 13:38, Linus Walleij wrote:
>> Linus,
>> Is there a plan to move even the data that exists in the pinmux
>> drivers today (including the function/pin-groups definition)
>> eventually to DT? Or is it just the 'mapping' data to map
>> devices to functions (that today is done from
On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
(...)
+ * The OMAP control module has a device-control sub-module
+ * which handles all pin/padmuxing for OMAP. The sub-module
+ * is further split into a 'core' instance within t
On Thu, Nov 17, 2011 at 3:41 PM, Rajendra Nayak wrote:
> A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
> enabled state by the hwmod framework post the initial setup.
> Once a real user of the device (a driver) tries to enable it
> at a later point, the hmwod framework throws a WARN() ab
+ Paul
On 11/17/2011 11:11 AM, Rajendra Nayak wrote:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
ty
On Wed, 2011-11-09 at 01:12 +0100, Ilya Yanok wrote:
> Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
> display driver.
>
> Signed-off-by: Ilya Yanok
> ---
> drivers/video/omap2/displays/panel-generic-dpi.c | 24
> ++
> 1 files changed, 24 inserti
[]...
Why do we have to idle -> enable? The module is already enabled, isn't
it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?
Yes, now that I read it, it does sound confusing. I should have at-least
read it once before I picked it from serial.c
But anyway, here's
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
the device being already in enabled state.
Fix this by intr
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
the device being already in enabled state.
Fix this by intr
Hi Rajendra,
On 11/17/2011 8:19 AM, Rajendra Nayak wrote:
[...]
+static int omap_console_hwmod_enable(struct omap_device *od)
+{
+ console_lock();
+ /*
+ * For early console we prevented hwmod reset and idle
A period is missing. Or maybe it should a comma with not capital letter.
+ * So bef
On Thu, Nov 17, 2011 at 6:23 AM, Omar Ramirez Luna wrote:
> On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
> wrote:
> ...
>>> My use case is as follows:
>>>
>>> DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
>>> for processing the message, when it reaches tidspbri
On Thursday 17 November 2011 06:34 AM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
Signed-off-by: Rajendra Naya
On Wednesday 16 November 2011 08:29 PM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
> These are still early patches, but I wanted to get
> some feedback on if I am heading in the right direction.
> Hence sharing these in the current form.
The platform pieces look good! We need to discuss about
the driver and needed infrastr
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
(...)
> + * The OMAP control module has a device-control sub-module
> + * which handles all pin/padmuxing for OMAP. The sub-module
> + * is further split into a 'core' instance within the CORE
> + * powerdomain and a 'wkup' instance within th
On Tue, Nov 15, 2011 at 5:33 AM, Rajendra Nayak wrote:
> On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
>> * Rajendra Nayak [14 04:05]:
>>>
>>> > +static const struct pinctrl_pin_desc omap4_core_pads[] = {
>>> > + PINCTRL_PIN(0, "c12"),
>>> > + PINCTRL_PIN(1, "d12"),
>>> >
36 matches
Mail list logo
