On Thu, 2011-06-09 at 21:31 +0530, Raju, Sundaram wrote:
Here it is, with proper line wrapping;
Please cc the respective MAINTAINERS, added Dan...
SDMA and EDMA are TI SoC specific DMA controllers. Their drivers have
been maintained in the respective SoC folders till now.
On Thu, 2011-06-09 at 17:32 +0100, Russell King - ARM Linux wrote:
On Thu, Jun 09, 2011 at 09:31:56PM +0530, Raju, Sundaram wrote:
Here it is, with proper line wrapping;
Thanks. This is much easier to reply to.
I believe that even though the dmaengine framework addresses and
supports
On Fri, 2011-06-10 at 05:03 +0900, Paul Mundt wrote:
On Thu, Jun 09, 2011 at 04:56:42PM +0300, Tomi Valkeinen wrote:
+int dispc_runtime_get(void)
+{
+ int r;
+
+ DSSDBG(dispc_runtime_get\n);
+
+ r = pm_runtime_get_sync(dispc.pdev-dev);
+ WARN_ON(r 0);
+ return r 0 ?
Kevin Hilman wrote:
Sakari Ailus sakari.ai...@maxwell.research.nokia.com writes:
Hi Kevin and Felipe,
Kevin Hilman wrote:
In commit 7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support
for device power domains) a better way for handling platform-specific
power hooks was introduced.
I think I should have tried to explain my case with a specific example.
I tried to generalize it and it has confused and misled every one.
I have tried again now. :)
snip
A simple single buffer transfer (i.e. non sg transfer) can be done only
as a trivial case of the device_prep_slave_sg
On Fri, Jun 10, 2011 at 03:51:41PM +0530, Raju, Sundaram wrote:
Consider a simple video use case of de-interlacing a video buffer.
Odd lines have to be transferred first, and then the even lines are
transferred separately. This can be done by programming the
inter frame gap as the line size
On 6/10/2011 5:37 AM, Todd Poynor wrote:
On Thu, Jun 09, 2011 at 04:24:06PM +0530, Rajendra Nayak wrote:
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
...
+ * clkdm_is_idle - Check if the clkdm hwsup/autoidle is enabled
A minor
Vinod,
-Original Message-
From: Koul, Vinod [mailto:vinod.k...@intel.com]
Sent: Friday, June 10, 2011 11:39 AM
To: Raju, Sundaram; Dan
Cc: Russell King - ARM Linux; davinci-linux-open-
sou...@linux.davincidsp.com; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org;
On 6/10/2011 5:45 AM, Todd Poynor wrote:
+ int hwsup = 0;
if (pwrdm == NULL || IS_ERR(pwrdm))
return -EINVAL;
@@ -127,6 +128,7 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
(pwrdm-flags
Russell,
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 10, 2011 4:13 PM
To: Raju, Sundaram
Cc: Koul, Vinod; Dan; davinci-linux-open-sou...@linux.davincidsp.com; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
Hello,
Changes since v3:
- patches generated with git format-patch -M to handle renames better
- Included depending updates for twl6040 soc codec driver:
- HS ramp configuration, new ABE dais, updated sample rate constraints
- Configure the twl6040 codec on SDP4430 board
Updated intro message
Introduce a new file, which will be used to configure
common pmic (TWL) devices, regulators, and TWL audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/common-board-devices.c | 21 -
From: Misael Lopez Cruz misael.lo...@ti.com
Add twl6040_vibra as a child of MFD device twl6040_codec. This
implementation covers the PCM-to-PWM mode of TWL6040 vibrator
module.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Reduce the amount of duplicated code by moving the common
configuration for twl4030/5030/tpsxx to the twl-common file.
Use the omap3_pmic_get_config function from board files to
properly configure the PMIC with the common fields.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Misael Lopez Cruz misael.lo...@ti.com
---
drivers/input/misc/Kconfig |2 +-
From: Misael Lopez Cruz misael.lo...@ti.com
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The
Pass twl4030_codec_data instead of the twl4030_audio_data
for the ASoC codec driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040-core.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c
Add twl4030_vibra platform data, and the needed regulators
for twl6040 vibrator.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 48 +++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git
From: Liam Girdwood l...@ti.com
Add all DAIs to fully support OMAP4 ABE.
Signed-off-by: Liam Girdwood l...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl6040.c | 44
1 files changed, 36 insertions(+), 8
From: Liam Girdwood l...@ti.com
Add other supported sample rates to LP and HP modes.
Signed-off-by: Liam Girdwood l...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl6040.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
From: Misael Lopez Cruz misael.lo...@ti.com
Configure, and enable the twl6040 codec on SDP4430.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
From: Axel Castaneda Gonzalez x0055...@ti.com
Enable ramp down/up step to be configured based on
platform.
Signed-off-by: Axel Castaneda Gonzalez x0055...@ti.com
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/i2c/twl.h
From: Liam Girdwood l...@ti.com
Set default sysclk constraints to high performance mode.
Signed-off-by: Liam Girdwood l...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl6040.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
From: Misael Lopez Cruz misael.lo...@ti.com
Remove dependency between pll (hppll, lppll) and headset power
mode (low-power, high-performance), as headset power mode can
be used with any pll.
A new control is created to allow headset power mode configuration
from userspace. Changing headset power
From: Misael Lopez Cruz misael.lo...@ti.com
Convert TWL6040 CODEC driver into a TWL6040 MFD child, it implies
that MFD-level operations like register accesses, clock setting
and power management are done through MFD APIs, not directly by
CODEC driver anymore. To avoid conflicts with the other MFD
In preparation of renaming the driver from twl4030-codec
to twl4030-audio, first do some clean ups in the driver,
which does not cause any problems outside.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl4030-codec.c | 135 ++-
1
Allign the platform data names for twl4030 audio submodule:
twl4030_audio_data: for the core MFD driver
twl4030_codec_data: for ASoC codec driver
twl4030_vibra_data: for the input/ForceFeedback driver
To avoid breakage, change all depending drivers, files
to use the new types.
Signed-off-by:
Some regulator config can be moved out from board files,
since they are close to identical.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 51 --
arch/arm/mach-omap2/board-cm-t35.c | 41
Reduce the amount of duplicated code by moving the common
configuration for TWL6030 (on OMAP4 platform) to the
twl-common file.
Use the omap4_pmic_get_config function from board files to
properly configure the PMIC with the common fields.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
2011/6/10 Péter Ujfalusi peter.ujfal...@ti.com:
On Thursday 09 June 2011 16:40:15 onlyfever wrote:
Hello,
I want to power down Voice/Bluetooth sidetone PGA of TWL5030.
I set the VSTPGA Register/BTSTPGA Register to 0x00,but it seems that
the Voice/Bluetooth sidetone PGA still work,
and even
On Fri, Jun 10, 2011 at 05:18:46PM +0530, Raju, Sundaram wrote:
Russell,
How do you handle the situation where a driver uses your new proposed
API, but it doesn't support that in hardware.
It should be handled the same way how a sg buffer is handled,
if LLI chaining feature is not
Add OMAP SSI device and driver to the kernel configuration
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
---
arch/arm/mach-omap2/Makefile |2 ++
drivers/hsi/Kconfig |2 ++
drivers/hsi/Makefile |1 +
drivers/hsi/controllers/Kconfig | 23
Add an entry for HSI in the device-drivers section of
the kernel documentation.
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
---
Documentation/DocBook/device-drivers.tmpl | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git
Adds HSI framework in to the linux kernel.
High Speed Synchronous Serial Interface (HSI) is a
serial interface mainly used for connecting application
engines (APE) with cellular modem engines (CMT) in cellular
handsets.
HSI provides multiplexing for up to 16 logical channels,
low-latency and
From: Andras Domokos andras.domo...@nokia.com
Added ioctl range for HSI char devices to the documentation
Signed-off-by: Andras Domokos andras.domo...@nokia.com
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
---
Documentation/ioctl/ioctl-number.txt |1 +
1 files changed, 1
From: Andras Domokos andras.domo...@nokia.com
Add HSI character device kernel configuration
Signed-off-by: Andras Domokos andras.domo...@nokia.com
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
---
drivers/hsi/Kconfig |1 +
drivers/hsi/Makefile |2 +-
From: Andras Domokos andras.domo...@nokia.com
Add HSI char device driver to the kernel.
Signed-off-by: Andras Domokos andras.domo...@nokia.com
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
---
drivers/hsi/clients/hsi_char.c | 804
Hi !
Here you have the fifth round of the HSI framework patches.
The patch series introduces the HSI framework, an SSI driver
for OMAP and a generic character device for HSI/SSI devices.
SSI, which is a legacy version of HSI, is used to connect the application
engine with the cellular modem on
2011/6/10 Péter Ujfalusi peter.ujfal...@ti.com:
1. when use Headset:
uplink routing:HSMIC -- AVTXR2PGA AVTXL2PGA -- VDXS VDXM -- PCM_VDX
downlink routing:PCM_VDR -- VDR -- VRXPGA Fine gain -- DAC voice
-- VDL_GAIN Analog PGA -- HSOL/HSOR
Thanks
I check the loopbacks,it seems that all
On Thu, Jun 09, 2011 at 09:56:48AM -0400, Alan Stern wrote:
On Wed, 8 Jun 2011, Kevin Hilman wrote:
Runtime suspend
2. activity finishes
system suspend [echo mem /sys/power/state]
2. prevent future activity, halt/wait for current activity
The only difference is step 2.
That _is_
On Fri, 10 Jun 2011, Mark Brown wrote:
No, it's generally agreed that _all_ devices should return to full
power during system resume -- even if they were runtime suspended
before the system sleep. This also is explained in the Documentation
files.
What is the reasoning behind this
Attempting to disable USB generates the following warning at the moment:
warning: (ARCH_OMAP3 ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet
direct dependencies (USB_SUPPORT)
Signed-off-by: Nishanth Menon n...@ti.com
---
based on 3.0-rc2
arch/arm/mach-omap2/Kconfig |4 ++--
1 files
I've used the omap watchdog timer (CONFIG_OMAP_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y) with good results on 35XX based systems.
Recently I attempted to use the the same technique with 37XX and
discovered that my systems hangs instead of rebooting.
The simplest method to test is to do:
# echo 1
On Fri, Jun 10, 2011 at 10:51:02AM -0400, Alan Stern wrote:
On Fri, 10 Jun 2011, Mark Brown wrote:
No, it's generally agreed that _all_ devices should return to full
power during system resume -- even if they were runtime suspended
before the system sleep. This also is explained in
On Fri, 10 Jun 2011, Mark Brown wrote:
On Fri, Jun 10, 2011 at 10:51:02AM -0400, Alan Stern wrote:
On Fri, 10 Jun 2011, Mark Brown wrote:
No, it's generally agreed that _all_ devices should return to full
power during system resume -- even if they were runtime suspended
before
On Fri, Jun 10, 2011 at 11:45:30AM -0400, Alan Stern wrote:
On Fri, 10 Jun 2011, Mark Brown wrote:
It's not massively clear to me how much sense that makes for the
embedded case where we've got a much better idea of what happened to the
hardware over suspend. Note that I'm thinking here
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 10, 2011 8:45 PM
To: linux-omap
Cc: Tony; linux-arm; Balbi, Felipe; Menon, Nishanth
Subject: [PATCH] OMAP3+: Kconfig: has EHCI only if
On Fri, Jun 10, 2011 at 11:08, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, June 10, 2011 8:45 PM
To: linux-omap
Cc: Tony; linux-arm; Balbi, Felipe;
On Thu, Jun 9, 2011 at 1:27 AM, David Brown dav...@codeaurora.org wrote:
Moving the driver is good. I'm wondering what we should do with
iommu_dev.c, though. Wouldn't it make sense to move this file as well?
Yeah, it does make sense. I'll move that one too, thanks.
--
To unsubscribe from this
On Fri, 10 Jun 2011, Mark Brown wrote:
Well, this is a SHOULD, not a MUST. If you want your driver to leave a
device in a low-power state, it can do so. Just bear in mind that the
PM core's idea of the device's runtime power state may end up not
matching reality unless you're careful.
On Fri, 2011-06-10 at 16:43 +0530, Raju, Sundaram wrote:
Vinod,
...
Now coming to the buffer related attributes, sg list is a nice way to
represent a disjoint buffer; all the offload engines in drivers/dma
create a descriptor for each of the contiguous chunk in the sg list
buffer
On Fri, Jun 10, 2011 at 01:17:56PM -0400, Alan Stern wrote:
On Fri, 10 Jun 2011, Mark Brown wrote:
ignores that), it's noticably harder to reason about what's going on
when I go outside there and when I think about what I'm doing it always
feels like it should be possible to factor it out
On Friday, June 10, 2011, Mark Brown wrote:
On Fri, Jun 10, 2011 at 01:17:56PM -0400, Alan Stern wrote:
On Fri, 10 Jun 2011, Mark Brown wrote:
ignores that), it's noticably harder to reason about what's going on
when I go outside there and when I think about what I'm doing it always
On Fri, Jun 10, 2011 at 08:38:22PM +0200, Rafael J. Wysocki wrote:
On Friday, June 10, 2011, Mark Brown wrote:
I think from an interface point of view it's something like
UNIVERSAL_DEV_PM_OPS() and friends, probably with some additional ops
that can do the glue bits like enabling wakeup
On Friday, June 10, 2011, Mark Brown wrote:
On Thu, Jun 09, 2011 at 09:56:48AM -0400, Alan Stern wrote:
On Wed, 8 Jun 2011, Kevin Hilman wrote:
Runtime suspend
2. activity finishes
system suspend [echo mem /sys/power/state]
2. prevent future activity, halt/wait for current
On Fri, Jun 10, 2011 at 08:49:03PM +0200, Rafael J. Wysocki wrote:
On Friday, June 10, 2011, Mark Brown wrote:
It seems like everyone's agreeing with each other here - from the user
side the request seems to be largely for core infastructure like
UNIVERSAL_DEV_PM_OPS() (which I'm not sure
On Friday, June 10, 2011, Mark Brown wrote:
On Fri, Jun 10, 2011 at 08:38:22PM +0200, Rafael J. Wysocki wrote:
On Friday, June 10, 2011, Mark Brown wrote:
I think from an interface point of view it's something like
UNIVERSAL_DEV_PM_OPS() and friends, probably with some additional ops
On Friday, June 10, 2011, Mark Brown wrote:
On Fri, Jun 10, 2011 at 08:49:03PM +0200, Rafael J. Wysocki wrote:
On Friday, June 10, 2011, Mark Brown wrote:
It seems like everyone's agreeing with each other here - from the user
side the request seems to be largely for core infastructure
On Fri, 10 Jun 2011, Rafael J. Wysocki wrote:
Next, what subsystem (e.g. bus type) is the driver going to work with?
If the subsystem is smart enough, it can take care of many things, like
powering off, wakeup preparations and so on.
Now, there are a few combinations possible. First, if
Create a dedicated iommu drivers folder, put the base iommu code there,
and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
intel-iommu).
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.
Grouping the various iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested for MSM8X60.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig | 16
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/x86/Kconfig | 28
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
has to move from drivers/pci/pci.h to include/linux/pci.h.
On Wednesday, May 25, 2011, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
cpufreq table allocated by opp_init_cpufreq_table is better
freed by OPP layer itself. This allows future modifications to
the table handling to be transparent to the users.
Signed-off-by: Nishanth
On Thu, May 12, 2011 at 01:42, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/5/2011 12:23 PM, Saquib wrote:
Can anyone please help me to understand and fix this issue?
When CPU frequency is 1008MHz, duration of delay was close to
theoretical value, however, when 300MHz, it was close
Rafael J. Wysocki r...@sisk.pl writes:
[...]
Whether or not user space has disabled runtime PM _doesn't_ _matter_ for
system suspend, because _you_ _can't_ call pm_runtime_suspend(), or
pm_runtime_put_sunc(), from a driver's .suspend() callback _anyway_.
The reason is that doing that would
Alan Stern st...@rowland.harvard.edu writes:
[...]
More specifically, what should be the approach in system suspend when a
device is already runtime suspended? If you treat runtime and system PM
as completely independent, you would have to runtime resume the device
so that it can then be
Can you check with:
amixer | grep -A 6 Loopback
Simple mixer control 'Left Digital Loopback',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 7
Mono: 0 [0%] [-9.99dB]
Simple mixer control 'Left1 Analog Loopback',0
69 matches
Mail list logo
