On Fri, Dec 9, 2011 at 4:32 AM, Turquette, Mike mturque...@ti.com wrote:
On Fri, Sep 30, 2011 at 2:15 AM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Fri, Sep 30, 2011 at 3:00 AM, Linus Walleij linus.wall...@linaro.org
wrote:
2011/9/8 Santosh Shilimkar santosh.shilim...@ti.com:
On 12/11/2011 08:08 AM, NeilBrown wrote:
Should these settings just be moved up before the call to
omap_device_build_ss?? Doing that removes
[0.196014] Slab corruption: size-32 start=ded3edc0, len=32
warning.
Good catch! Yes, they must be set before omap_device_build_ss and
definitely
On Sun, Dec 11, 2011 at 09:12:07PM +0100, Janusz Krzysztofik wrote:
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
Depends on patch 8/10 omapfb: lcd_ams_delta: Drive control lines over
GPIO.
Signed-off-by: Janusz Krzysztofik
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions)
incorrectly set two struct omap_mcbsp_platform_data fields after
omap_device_build_ss and kfree calls.
Fix this by moving these pdata assignments
Flag single_channel in struct omap2_mcspi_device_config is not used
by drivers/spi/spi-omap2-mcspi.c so we may remove it from include/plat/mcspi.h
and affected board files.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/board-cm-t35.c |1 -
On Fri, 2011-12-09 at 16:21 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
OMAP3 uses the default settings for VDD1 channel, otherwise the settings
will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero
On Fri, 2011-12-09 at 12:23 -0800, Kevin Hilman wrote:
Hi Tero,
Tero Kristo t-kri...@ti.com writes:
Changes compared to previous version:
- merged most of the voltagedomain cleanup fixes to patch 2
- moved pmic latencies to omap_voltdm_pmic struct
- renamed omap_lp_params to
On Fri, 2011-12-09 at 10:07 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Nishanth Menon n...@ti.com
Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific
On Fri, 2011-12-09 at 10:27 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
This contains startup and shutdown times for the oscillator. By default
use MAX_INT.
nit: code uses ULONG_MAX
Oops, will fix the comment.
Oscillator setup is used for calculating and setting
On Fri, 2011-12-09 at 11:11 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Based on the oscillator datasheet for this device.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0
On Fri, 2011-12-09 at 11:37 -0800, Kevin Hilman wrote:
+Paul
Tero Kristo t-kri...@ti.com writes:
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of
Hi,
On Mon, Dec 12, 2011 at 1:43 AM, Sylwester Nawrocki snj...@gmail.com
For OMAP4 FD, it is not needed to include FD into MC framework since a
intermediate buffer is always required. If your HW doesn't belong to this
case, what is the output of your HW FD in the link? Also sounds FD results
On Fri, 2011-12-09 at 12:13 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the voltdm callback functions for sleep /
On Fri, 2011-12-09 at 15:23 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to serve IO and
WKUP events separately. This allows us to handle IO chain
On Fri, 2011-12-09 at 14:36 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Once more a new version, it was decided that the PRM driver will be
dropped for now, and we will have the chain handler support under
mach-omap2 directory. This will most likely be addressed in
On Fri, 2011-12-09 at 15:04 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
These are needed because runtime PM is disabled during suspend, and
it is bad if we get interrupts from the PRCM chain handler during it.
This patch masks all the PRCM interrupt events, but does not
On Fri, 2011-12-09 at 15:13 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected.
Good.
This routine is called directly from PRCM
On 12/12/11 10:38, Jarkko Nikula wrote:
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions)
incorrectly set two struct omap_mcbsp_platform_data fields after
omap_device_build_ss and kfree calls.
+ Paul and Peter
Hi Neil,
On 12/12/2011 12:35 AM, NeilBrown wrote:
In 3.2-rc5 (and some earlier kernels) I'm getting the boot-time warning:
[0.186828] omap-mcbsp.2: alias fck already exists
and
[0.188476] omap-mcbsp.3: alias fck already exists
This happens because
On Fri, 2011-12-09 at 09:37 +0800, Axel Lin wrote:
These symbols are not used outside it's driver so no need to
make the symbol global.
Signed-off-by: Axel Lin axel@gmail.com
Thanks, applied to DSS tree.
Tomi
signature.asc
Description: This is a digitally signed message part
On Fri, 2011-12-09 at 09:59 +0800, Axel Lin wrote:
This patch converts the drivers in drivers/video/omap/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.
Cc: Jonathan McDowell nood...@earth.li
Cc: Cory Maccarrone darkstar6...@gmail.com
Cc: Laurent
Hi,
On Thu, 2011-12-08 at 14:05 +0200, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 151
Hi
On 12/12/2011 12:23 PM, Igor Grinberg wrote:
On 12/12/11 10:38, Jarkko Nikula wrote:
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize
omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions)
incorrectly set two struct omap_mcbsp_platform_data
On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote:
Don't use Amstrad Delta custom I/O functions any longer, use GPIO API
instead.
Depends on patch 5/10 MTD: NAND: ams-delta: Use GPIO instead of custom
I/O.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi Mohamed,
On Tue, Nov 08, 2011 at 06:53:35PM +0530, Afzal Mohammed wrote:
Hi,
This series applies over Kyle Manna's v3 patch series,
https://lkml.org/lkml/2011/11/3/257,
with changes as per comments on
his/her 1/6 mfd: TPS65910: Handle non-existent devices
Kyle has not updated the
On 12/12/11 13:22, Jarkko Nikula wrote:
Hi
On 12/12/2011 12:23 PM, Igor Grinberg wrote:
On 12/12/11 10:38, Jarkko Nikula wrote:
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize
omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions)
incorrectly
Hi Ming,
It's maybe late, but I want to suggest one thing about FD API.
This OMAP FD block looks detection ability of just face.
But, It's possible to occur another device which can detect
specific object or patterns. Moreover, this API can expand
object recognition area. So, I think it's good
From: Tomi Valkeinen [tomi.valkei...@ti.com]
Sent: Monday, December 12, 2011 1:10 PM
To: Alex Gershgorin
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
tim.nord...@logicpd.com; bar...@tkos.co.il
Subject: Re: [PATCH] ARM: OMAP3LOGIC:
If the module does not have any modulemode, the _disable_module function
will do nothing. There is then no point waiting for a idle status change.
It will remove the following warnings.
[0.331848] omap_hwmod: dmm: _wait_target_disable failed
[0.339935] omap_hwmod: emif_fw:
Tero Kristo t-kri...@ti.com writes:
On Fri, 2011-12-09 at 16:21 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
OMAP3 uses the default settings for VDD1 channel, otherwise the settings
will
overlap with VDD2 and attempting to modify VDD1 voltage will actually
change
Tero Kristo t-kri...@ti.com writes:
On Fri, 2011-12-09 at 12:13 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the
Tero Kristo t-kri...@ti.com writes:
On Fri, 2011-12-09 at 15:13 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected.
Good.
This routine
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 106
1 files changed, 106 insertions(+), 0 deletions(-)
diff
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
. Implement the low level code which controls the power domains next power
states, through the hwmod
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 then applied to the corresponding power
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
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 OMAP3 Beagleboard and OMAP4 Pandaboard in
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 and CORE power domains and so the
From: Jean Pihet j-pi...@ti.com
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
ToDo:
- Measure the wake-up latencies for all
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf.
Hi Kevin,
On Wed, Nov 23, 2011 at 8:43 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
On Thu, Nov 17, 2011 at 10:29 PM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
The MPU latency figures for
Hi Kevin, Paul,
ping on this series
Thanks,
Jean
On Wed, Oct 19, 2011 at 4:28 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
. Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints
. Remove the latency related functions from OMAP PM in favor of
Hi Neil,
On Sun, Nov 27, 2011 at 07:17:41AM +1100, NeilBrown wrote:
Hi,
The recent tidying up of twl4030-irq seems to have left it broken.
At least it doesn't work for me on my gta04 (www.gta04.org). The
first interrupt from the device freezes the whole system (by being
constantly
On Thu, Jun 30, 2011 at 12:51 PM, Felipe Balbi ba...@ti.com wrote:
threads from twl4030's children will be called
nested in the context of the demultiplexing
handler on twl4030-irq.c.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/twl4030-irq.c | 11 ++-
1 files
Hi Tero,
On Mon, Nov 28, 2011 at 04:53:23PM +0200, Tero Kristo wrote:
This way, we can add custom flags for VDD1 and VDD2 regulators that
get passed all the way to regulator init. This is needed for SMPS
regulator support to select used controller mode for these regulators
(either voltage
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Usually moving
Hi,
PRCM chain handler is adding a support to the omap3+ kernel that
allows different drivers to use PRCM interrupt events for their
own purposes, typically this means IO wakeups. This work was
attempted to integrate as its own driver at some point of
the evolution of this set, however this was
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
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
depending on the specific OMAP SoC
OMAP mux now parses active wakeup events from pad registers and
calls corresponding hwmod ISRs once a wakeup is detected. This is
accomplished by registering an interrupt handler for PRCM IO event,
which is raised every time the HW detects wakeups.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
This is handled automatically by the PRCM chain interrupt mechanism now.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index
PRCM chain handler needs to disable forwarding of interrupts during
suspend, because runtime PM is disabled and most of the drivers
are potentially not able to handle interrupts coming at this time.
This patch masks all the PRCM interrupt events if a PRCM interrupt
occurs during suspend, but does
By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to be re-routed this way must
have a separate call to
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to serve IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Core event code is also changed in accordance to this, as PRCM
interrupt
* Hemant Pedanekar hema...@ti.com [111209 17:27]:
This patch set adds support for DM814x/AM387x device series having Cortex-A8
MPU.
The technical documents are available from following link:
http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html
This series is referred in code as
Hi,
The short version is this: either we revert this patch[1], or we apply
this patch series[2], as well as its essential fixes[3].
The long version is this. There's a synchronization issue with the
current keypad driver and twl core; the irq is marked as handled even
though the thread that is
* Igor Grinberg grinb...@compulab.co.il [111212 03:25]:
On 12/12/11 13:22, Jarkko Nikula wrote:
Hi
On 12/12/2011 12:23 PM, Igor Grinberg wrote:
On 12/12/11 10:38, Jarkko Nikula wrote:
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize
omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM:
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]:
From: Ravi Babu ravib...@ti.com
Added musb support for ti81xx platform which has two instances of musb
interface and uses CPPI4.1 DMA. The current patch set adds support for
single instance and in PIO mode only.
Applying into musb branch.
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]:
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Applying into musb branch.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
* Gupta, Ajay Kumar ajay.gu...@ti.com [111011 09:33]:
Hi,
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
This patch can result in a merge
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]:
From: Ravi Babu ravib...@ti.com
TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine.
It has builtin USB PHYs as AM35x. The current set of patches adds support
for one instance and only in PIO mode.
This one should get
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]:
Adding musb support in am335x EVM board file.
These last two patches are pending on the machine_id
change for the board file.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Mon, Dec 12, 2011 at 10:49:01AM -0800, Tony Lindgren wrote:
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]:
From: Ravi Babu ravib...@ti.com
TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine.
It has builtin USB PHYs as AM35x. The current set of patches adds
Hi,
On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote:
The short version is this: either we revert this patch[1], or we apply
this patch series[2], as well as its essential fixes[3].
The long version is this. There's a synchronization issue with the
current keypad driver and
On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote:
Hi,
The short version is this: either we revert this patch[1], or we apply
this patch series[2], as well as its essential fixes[3].
The long version is this. There's a synchronization issue with the
current keypad driver
* Felipe Contreras felipe.contre...@gmail.com [111208 11:52]:
On Thu, Dec 8, 2011 at 4:40 PM, Heikki Krogerus kro...@gmail.com wrote:
On Wed, Dec 07, 2011 at 09:56:56PM +0200, Felipe Contreras wrote:
From: Heikki Krogerus kro...@gmail.com
I would prefer that you change this so this is
Hi Mike
+int clk_register_gate(struct device *dev, const char *name, unsigned long
flags,
+ struct clk *fixed_parent, void __iomem *reg, u8
bit_idx,
+int set_to_enable)
+
How do you suggest handling gated clocks which are already
Hi Haojian,
On Sun, Dec 11, 2011 at 7:10 PM, Haojian Zhuang
haojian.zhu...@gmail.com wrote:
...
Hi Omar,
Thanks for your patch. Could you help to split your patches into small
pieces? Since different people are handling for different files. For
example, I can help to handle files in
On Mon, Dec 12, 2011 at 9:12 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote:
The short version is this: either we revert this patch[1], or we apply
this patch series[2], as well as its essential fixes[3].
The long version is this. There's
On Mon, Dec 12, 2011 at 9:23 PM, Greg KH gre...@suse.de wrote:
On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote:
The short version is this: either we revert this patch[1], or we apply
this patch series[2], as well as its essential fixes[3].
The long version is this. There's a
On Mon, Dec 12, 2011 at 11:47 AM, Andrew Lunn and...@lunn.ch wrote:
Hi Mike
+int clk_register_gate(struct device *dev, const char *name, unsigned long
flags,
+ struct clk *fixed_parent, void __iomem *reg, u8
bit_idx,
+ int
On Mon, Dec 12, 2011 at 11:04:35PM +0200, Felipe Contreras wrote:
On Mon, Dec 12, 2011 at 9:23 PM, Greg KH gre...@suse.de wrote:
On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote:
The short version is this: either we revert this patch[1], or we apply
this patch series[2], as
Hi,
On Mon, Dec 12, 2011 at 10:55:11PM +0200, Felipe Contreras wrote:
Samuel assumed it was ok and, like I said above, it worked for my simple
GPIO
usecase with beagleboard.
Well, for 3.2 I think the situation is fine, but that's not what I'm
talking about. About your GPIO tests, are
I don't like this approach. If the bool for a particular clk is
statically defined then it could be wrong (bootloader/kernel
mismatch).
I've been thinking of adding a clk-ops-init callback in clk_init,
which is defined for a platform to use however the author sees fit.
There have been a
On Mon, 12 Dec 2011 18:38:19 +0100 Samuel Ortiz sa...@linux.intel.com wrote:
Hi Neil,
On Sun, Nov 27, 2011 at 07:17:41AM +1100, NeilBrown wrote:
Hi,
The recent tidying up of twl4030-irq seems to have left it broken.
At least it doesn't work for me on my gta04 (www.gta04.org). The
Hi,
On 12/12/2011 10:49 AM, Ming Lei wrote:
If FD result is associated with a frame, how can user space get the frame
seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit
difficult to retrieve FD results from user space.
If you pass image data in memory buffers from user
Hi Arnd Olof,
Please pull omap hsmmc platform code changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap hsmmc
Ideally arch/arm/mach-omap2/hsmmc.c file will completely
disappear with device tree, but looks like we're still
some more patches away from that. Meanwhile,
Hi Arnd Olof,
Please pull two non-critical DMA fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
fixes-non-critical
These are workarounds for corner cases. There's no rush
to get them in during the -rc cycle, these are fixes for
features that never worked before.
* Ramirez Luna, Omar omar.rami...@ti.com [111209 13:38]:
On Fri, Dec 9, 2011 at 3:34 PM, Tony Lindgren t...@atomide.com wrote:
+ ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
...
EXPORT_SYMBOL_GPL(omap_dm_timer_request);
This does not seem right.. It seems that
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 14:36]:
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom
* Jarkko Nikula jarkko.nik...@bitmer.com [111212 00:45]:
Flag single_channel in struct omap2_mcspi_device_config is not used
by drivers/spi/spi-omap2-mcspi.c so we may remove it from include/plat/mcspi.h
and affected board files.
Thanks applying into cleanup branch.
Regards,
Tony
--
To
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
Might be worth checking if some board specific __initcall helps here
too?
If I only knew how I could insert a board specific __initcall between
two points from where the generic-gpio first, then the 8250 driver, are
called.
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]:
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
Might be worth checking if some board specific __initcall helps here
too?
If I only knew how I could insert a board specific __initcall between
two points from
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]:
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
Might be worth checking if some board specific __initcall helps here
too?
If I only knew
* Tero Kristo t-kri...@ti.com [111212 09:44]:
OMAP mux now parses active wakeup events from pad registers and
calls corresponding hwmod ISRs once a wakeup is detected. This is
accomplished by registering an interrupt handler for PRCM IO event,
which is raised every time the HW detects wakeups.
* Tero Kristo t-kri...@ti.com [111212 09:44]:
By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to
* Tero Kristo t-kri...@ti.com [111212 09:44]:
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
* Tero Kristo t-kri...@ti.com [111212 09:44]:
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this
Tero Kristo t-kri...@ti.com writes:
PRCM chain handler is adding a support to the omap3+ kernel that
allows different drivers to use PRCM interrupt events for their
own purposes, typically this means IO wakeups. This work was
attempted to integrate as its own driver at some point of
the
On Mon, Dec 12, 2011 at 5:08 PM, Tony Lindgren t...@atomide.com wrote:
...
@@ -134,22 +134,13 @@ static void omap_dm_timer_reset(struct
omap_dm_timer *timer)
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
...
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
Hi guys,
Gentle ping on this patch, :-)
thanks,
--
Ming Lei
On Fri, Dec 2, 2011 at 5:12 PM, Ming Lei ming@canonical.com wrote:
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81
1 files changed, 81
https://docs.google.com/document/d/1-MgXERW0_TNnd0VK2caXYhDXtT58z1DJ0laAmJajrEs/edit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
On Mon, Dec 12, 2011 at 8:08 PM, HeungJun, Kim riverful@samsung.com wrote:
Hi Ming,
It's maybe late, but I want to suggest one thing about FD API.
This OMAP FD block looks detection ability of just face.
But, It's possible to occur another device which can detect
specific object or
Hi Ming and Sylwester,
Thanks for the reply.
-Original Message-
From: Ming Lei [mailto:ming@canonical.com]
Sent: Tuesday, December 13, 2011 1:02 PM
To: HeungJun, Kim
Cc: Sylwester Nawrocki; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org;
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
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 failure.
Signed-off-by: Ricardo Salveti de Araujo
On Tue, Dec 13, 2011 at 1:59 PM, HeungJun, Kim riverful@samsung.com wrote:
Hi Ming and Sylwester,
Thanks for the reply.
-Original Message-
From: Ming Lei [mailto:ming@canonical.com]
Sent: Tuesday, December 13, 2011 1:02 PM
To: HeungJun, Kim
Cc: Sylwester Nawrocki;
On Mon, 2011-12-12 at 19:04 +0100, Samuel Ortiz wrote:
Hi Tero,
On Mon, Nov 28, 2011 at 04:53:23PM +0200, Tero Kristo wrote:
This way, we can add custom flags for VDD1 and VDD2 regulators that
get passed all the way to regulator init. This is needed for SMPS
regulator support to select
1 - 100 of 101 matches
Mail list logo
