This patch does the following
Calls the pm_runtime_* functions directly.
Remove the MOD_REG_BIT macro usage thereby removiing un-needed branch.
At remove dont use the autosuspend runtime calls.
Changes from v1:
Fix the comments on changelogs.
Add acks to the patches.
The following changes since
Remove the macro MOD_REG_BIT instead make the bit field modifications
directly. This deletes a branch operation in cases where the the set
is predecided. While at it optimise two sequential bit clear in one step.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D
At remove we shouldnt be using the autosuspend timeout as we are
calling pm_runtime_disable immediately after.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
Call the pm_runtime functions directly making room for possible
pm optimisations. Also the runtime functions aren't just about
enabling and disabling of clocks though it does enable clocks also.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
On Wed, 2012-07-04 at 06:11 -0600, Paul Walmsley wrote:
Hi Tomi
On Wed, 27 Jun 2012, Paul Walmsley wrote:
On Thu, 10 May 2012, Tomi Valkeinen wrote:
These patches fix DSS hwmod data related to sysc flags. I haven't seen any
problem produced by these missing bits, but by looking at
Hi everyone,
this patch series aims at cleaning up of DSS of cpu_is checks thereby making it
more generic.
The 1st patch cleans up cpu_is checks from DISPC code.
The 2nd patch removes unused functions from DSS code.
The 3rd patch cleans up cpu_is checks from DSS code.
The 4th patch disables VENC
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra
Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these
functions have become redundant and no longer used.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dss.c | 45 -
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
OMAP4 checks are removed from VENC to provide it a cleaner interface. These
checks were introduced by patches HACK: OMAP: DSS2: VENC: disable VENC on OMAP4
to prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com and
OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug
This is a alternative to HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com to prevent
VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration
of a device for VENC on OMAP4.
Signed-off-by: Chandrabhanu
The OMAP3 checks have been removed and replaced by a dss feature
FEAT_DPI_USES_VDDS_DSI for cleaner implementation. The patches
OMAP: DSS2: enable VDDS_DSI when using DPI (8a2cfea8cc) by Tomi Valkeinen
tomi.valkei...@nokia.com and ARM: omap: fix oops in
drivers/video/omap2/dss/dpi.c (4041071571)
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
Hello!
I have been working on prototypes for the
Add ocp2scp data node in omap4 device tree file.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
This patch series has been lying here for long. If no one has any
comments on this patch series, can someone pick it up?
This patch series is done as a preparatory step for adding phy drivers
for dwc3 and musb.
This series adds a new driver for ocp2scp (only dt) to which phy
drivers are
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
USB2PHY is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding
On Wed, 2012-08-22 at 12:06 +0530, Chandrabhanu Mahapatra wrote:
Hi everyone,
this patch series aims at cleaning up of DSS of cpu_is checks thereby making
it
more generic.
The 1st patch cleans up cpu_is checks from DISPC code.
The 2nd patch removes unused functions from DSS code.
The 3rd
Hi AnilKumar,
On Mon, Aug 13, 2012 at 08:36:05PM +0530, AnilKumar Ch wrote:
Regulator platform data handling was mistakenly added to MFD
driver. So we will see build errors if we compile MFD drivers
without CONFIG_REGULATOR. This patch moves regulator platform
data handling from TPS65217 MFD
On Tue, Aug 21, 2012 at 4:12 PM, Felipe Balbi ba...@ti.com wrote:
On Sat, Aug 18, 2012 at 12:22:29AM +0530, Venkatraman S wrote:
omap hsmmc controller IP has an inbuilt timer that can be programmed to
^^^
built-in
guard
Hi,
On Wed, Aug 22, 2012 at 04:08:17PM +0530, S, Venkatraman wrote:
@@ -992,7 +996,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
hsmmc_command_incomplete(host, -EILSEQ);
end_cmd = 1;
- if (host-data ||
On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote:
This patch series has been lying here for long. If no one has any
comments on this patch series, can someone pick it up?
I've added them now as a drivers/ocp2scp branch arm-soc and pulled
them into the next/drivers topic branch.
On Wed, Aug 22, 2012 at 6:04 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote:
This patch series has been lying here for long. If no one has any
comments on this patch series, can someone pick it up?
I've added them now as a drivers/ocp2scp
On Sat, Aug 11, 2012 at 12:19 AM, Kevin Hilman khil...@ti.com wrote:
Hello,
In doing some automated testing of suspend/resume I noticed that
repeated attempts to suspend and resume via RTC wakeup fail on
3530/Beagle and 3730/Beagle-xM, but work fine on 3430/n900, 3530/Overo,
3730/OveroSTORM
On Tue, Aug 21, 2012 at 08:24:45PM -0500, Ricardo Neri wrote:
So, it seems that the way to go is extcon. I guess that ALSA will
use extcon just like today snd_jack uses the input driver. is this
correct? Is there any chance that ctrljack will propagate the events
through extcon? Is there any
On Wed, Aug 22, 2012 at 11:35:11AM +0530, Shubhrajyoti D wrote:
This patch does the following
Calls the pm_runtime_* functions directly.
Remove the MOD_REG_BIT macro usage thereby removiing un-needed branch.
At remove dont use the autosuspend runtime calls.
Applied all, thanks.
The
On Wed, Aug 22, 2012 at 10:29 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Wed, Aug 22, 2012 at 11:35:11AM +0530, Shubhrajyoti D wrote:
This patch does the following
Calls the pm_runtime_* functions directly.
Remove the MOD_REG_BIT macro usage thereby removiing un-needed
On Wed, Aug 22, 2012 at 10:33:55PM +0530, Shubhrajyoti Datta wrote:
Actually there was a patch in your tree that I sent which is not yet
in linus tree so I rebased
it to linux-next to avoid any merge conflicts.
Henceforth I will rebase it to your tree.
That's also a good option, though for
Hi,
On Wed, Aug 22, 2012 at 08:36:31PM +0530, Datta, Shubhrajyoti wrote:
The real mystery is why this happens on Beagle and Beagle-xM, but none
of the other OMAP3 boards (at least the ones I have.)
Looks like some race/ timing issue.
However I am not sure what is a good way to
On Thu, Aug 16, 2012 at 04:41:00PM +0300, Peter Ujfalusi wrote:
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
On Thu, Aug 16, 2012 at 04:41:01PM +0300, Peter Ujfalusi wrote:
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
I applied this - Tony,
On Thu, Aug 16, 2012 at 04:41:02PM +0300, Peter Ujfalusi wrote:
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Aug 16, 2012 at 04:41:03PM +0300, Peter Ujfalusi wrote:
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Aug 16, 2012 at 04:41:04PM +0300, Peter Ujfalusi wrote:
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
Applied but this didn't quite apply cleanly, please
On Thu, Aug 16, 2012 at 04:41:05PM +0300, Peter Ujfalusi wrote:
NUM_LINKS is no longer in use by the code.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Aug 16, 2012 at 04:41:06PM +0300, Peter Ujfalusi wrote:
We can use the has_ccr flag to replace the cpu_is_omap* checks.
This provides future proof implementation and we do not need to update the
code if new OMAP revision starts to use the McBSP driver.
Applied, thanks.
signature.asc
On Thu, Aug 16, 2012 at 04:41:07PM +0300, Peter Ujfalusi wrote:
Only create the devices in a legacy way if we do not have the DT data.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Aug 16, 2012 at 04:41:08PM +0300, Peter Ujfalusi wrote:
Device tree support for McBSP modules on OMAP2+ SoC.
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, Aug 21, 2012 at 05:33:56PM +0300, Peter Ujfalusi wrote:
To reflect the final devicetree node structure of McBSPs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks.
the initial OMAP McBSP DT structure was not able to describe the IP (and it's
versions) correctly.
Although this kind of IR diode circuitry is known to exist only in
N900 hardware, nothing prevents making similar circuitry on any OMAP
based board. The MACH_NOKIA_RX51 dependency is thus not something we
want to be there.
Also, this should depend on LIRC as it is a LIRC driver.
Signed-off-by:
These patches fix most of the issues pointed out in the patch review
by Sean Young and Sakari Ailus. The most noticeable change after these
patch set is that the IR transmission no longer times out even if the
timers are not waking up the MPU as it should be. However, the
transmission itself is
As clearly visible from the patch, this variable has no useful purpose
what so ever. Thus, it can be removed altogether without any side
effects.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff
No reason to avoid using the existing helpers.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 46628c0..7eed541 100644
This driver is useless without proper platform data. If data is not
available, we should not register the driver at all. Once this check
is done, the BUG_ON check during device open is no longer needed.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 4 +++-
The ir-rx51 driver calls omap_pm_set_max_mpu_wakeup_lat() in order to
avoid problems that occur when MPU goes to sleep in the middle of
sending an IR code. Without such calls it takes ridiculously long for
the MPU to wake up from a sleep, which distorts the IR signal
completely.
However, the
-Fix typo
-Change pwm_timer_num type to match type in platform data
-Remove extra parenthesis
-Replace magic constant with proper bit defintions
-Remove duplicate exit pointer
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
trivial
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
The lirc-dev expects the ir-code to be transmitted when the write call
returns back to the user space. We should not leave TX ongoing no
matter what is the reason we return to the user space. Easiest
solution for that is to simply remove interruptible sleeps.
The first wait_event_interruptible is
Remove a redundant macro definition. This is unneeded and becomes more
readable once the actual timer code is refactored a little.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
Hi,
On Tue, 21 Aug 2012 16:42:19 +0300
Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 08/21/2012 08:42 AM, Andreas Kemnade wrote:
Hi,
I tried a couple of times with different kernels to use mcbsp1 of dm3730
in master mode (so that it sends out clocks).
The result always is that I can
* Mark Brown broo...@opensource.wolfsonmicro.com [120822 12:12]:
On Thu, Aug 16, 2012 at 04:41:01PM +0300, Peter Ujfalusi wrote:
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
be hard to tell the
difference except for the value in WLEDCTRL1). Both instantiation through the
device tree and by passing platform data have been tested. Testing has been
done with an Androidized 3.2 kernel from the rowboat project
This patch is based on the mfd/for-next branch (20120822)
Changes
This is an equivalent conversion and will ease scheduled removal of
WQ_NON_REENTRANT.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
---
drivers/staging/omapdrm/omap_drv.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
Hi Afzal,
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime
52 matches
Mail list logo
