On Tue, Nov 15, 2011 at 5:33 AM, Rajendra Nayak rna...@ti.com wrote:
On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [14 04:05]:
+static const struct pinctrl_pin_desc omap4_core_pads[] = {
+ PINCTRL_PIN(0, c12),
+ PINCTRL_PIN(1, d12),
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak rna...@ti.com 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
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak rna...@ti.com 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
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 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
On Thu, Nov 17, 2011 at 6:23 AM, Omar Ramirez Luna or.r...@gmail.com wrote:
On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
...
My use case is as follows:
DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
for processing the message,
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
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
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
[]...
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
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 ya...@emcraft.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 24
++
1 files changed,
+ 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
On Thu, Nov 17, 2011 at 3:41 PM, Rajendra Nayak rna...@ti.com 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
On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayakrna...@ti.com 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'
On 17 November 2011 13:38, Linus Walleij linus.wall...@linaro.org 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
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
-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 device
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
thomas.abra...@linaro.org 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
Premi, Sanjeev pr...@ti.com 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
Rajendra Nayak rna...@ti.com 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
Ming Lei tom.leim...@gmail.com writes:
On Wed, Nov 9, 2011 at 3:24 AM, Kevin Hilman khil...@ti.com wrote:
tom.leim...@gmail.com writes:
From: Ming Lei tom.leim...@gmail.com
The patch fixes the compile failure:
CC arch/arm/mach-omap2/cpuidle34xx.o
Shubhrajyoti D shubhrajy...@ti.com 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 vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
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
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
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
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
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
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 we...@corscience.de
---
Changelog:
v2: Remove backslash at end of
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 rmk+ker...@arm.linux.org.uk
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Pushed to l2-mtd-2.6, thanks!
Artem.
--
To
Tero Kristo t-kri...@ti.com 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
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 m...@bues.ch
---
Index: linux-3.1.1/drivers/cbus/retu.c
This fixes the initialization of retu/tahvo cached IRQ masks.
Signed-off-by: Michael Buesch m...@bues.ch
---
Index: linux-3.1.1/drivers/cbus/retu.c
===
--- linux-3.1.1.orig/drivers/cbus/retu.c2011-11-17 23:09:26.498214061
Hi,
On Fri, Nov 18, 2011 at 3:36 AM, Kevin Hilman khil...@ti.com 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, :-)
On Thu, Nov 17, 2011 at 3:42 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com 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.
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
Hi Kevin,
On Friday 18 November 2011 01:05 AM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com 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
On Wed, 2011-11-16 at 11:01 +0530, K, Mythri P wrote:
On Mon, Nov 14, 2011 at 1:03 PM, Tomi Valkeinen tomi.valkei...@ti.com 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
On Tue, 2011-11-15 at 19:20 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
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
36 matches
Mail list logo