On 02/08/2012 02:34 AM, Grazvydas Ignotas wrote:
> Hi,
>
> On OMAP3 pandora, system suspend stops working properly after using
> audio at least once:
>
> (just after boot):
> # echo mem > /sys/power/state
> [ 12.578186] PM: Entering mem sleep
> [ 12.678802] PM: suspend of devices complete aft
Enabled the flag so that musb_dsps glue file can be used for am335x
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 126c220..ef0c3f9 100644
--- a/dri
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.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
These three patches are refreshed version of patches
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta
---
arch/arm/mach-omap2/omap_phy_internal.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477
From: Mythri P K
Add sysfs support for the user space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c|1 +
drivers/video/omap2/dss/hdmi.c
From: Mythri P K
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/ti_hdmi.h |2
From: Mythri P K
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the
On Wednesday 08 February 2012 09:56 AM, Ajay Kumar Gupta wrote:
> +static int dsps_musb_init(struct musb *musb)
> +{
> + struct device *dev = musb->controller;
> + struct musb_hdrc_platform_data *plat = dev->platform_data;
> + struct platform_device *pdev = to_platform_device(dev->paren
* Kevin Hilman [120207 13:38]:
> Russell King - ARM Linux writes:
>
> [...]
>
> > Another problem oopses the kernel at boot in the voltage domain code,
> > which I suspect this has never been boot tested on OMAP34xx CPUs:
> >
> > omap_vc_init_channel: PMIC info requried to configure vc forvdd_c
* Igor Grinberg [120205 03:08]:
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
> Section mismatch in reference from the function cm_t35_init_usbh()
> to the (unknown reference) .init.data:(unknown)
> The function cm_t35_init_usbh() references
> the (unknown reference) __initdata (unknown
* Santosh Shilimkar [120206 01:48]:
> With the latest Sourcery G++ Lite 2011.03-41 and latest linaro
> tool-chains OMAP2 only build breaks with below error.
>
> arch/arm/mach-omap2/omap-smc.S: Assembler messages:
> arch/arm/mach-omap2/omap-smc.S:30: Error: selected processor does not support
> A
* Russell King - ARM Linux [120207 01:39]:
> On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> > FYI, I'm now seeing the same warning as Igor posted with
> > omap2plus_defconfig using the same compiler as Igor:
> >
> > gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
> >
> > Stil
On 02/07/2012 02:43 PM, Andrew Richardson wrote:
I'm experiencing what appears to be a minimum clock resolution issue
in using clock_gettime() on a PandaBoard ES running ubuntu.
Do you have CONFIG_OMAP_32K_TIMER enabled in your kernel?
Look at 'dmesg | grep clock' and check for the following:
* Mark Brown [120207 08:57]:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>
> > The twl changes were done like that because it was assuming that
> > USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
> > platforms at 3.3 time. The whole point of doing that
Enabled the flag so that musb_dsps glue file can be used for am335x
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 126c220..ef0c3f9 100644
--- a/dri
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.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
These three patches are refreshed version of patches
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta
---
arch/arm/mach-omap2/omap_phy_internal.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477
On 2/4/12, Tony Lindgren wrote:
> * Tony Lindgren [120203 12:25]:
>> Add simple pinmux driver using device tree data.
>> +#define REG_NAME_LEN(sizeof(unsigned long) + 1)
>
> This is too short to contain the register name. Also the index
> for smux->names won't increase pro
Hi,
On Mon, Jan 30, 2012 at 2:08 AM, Nicolas Ferre wrote:
> On 01/29/2012 12:57 AM, Olof Johansson :
>> Hi,
>>
>>
>> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
>> wrote:
>>
>>
>>> And we're now there. So...
>>>
>>> Arnd, Olaf,
>>>
>>> Please incorporate the latest ARM (for-armsoc
Kevin Hilman writes:
> Tony Lindgren writes:
>
> [...]
>
>>> > > --- a/arch/arm/mach-omap2/pm34xx.c
>>> > > +++ b/arch/arm/mach-omap2/pm34xx.c
>>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>>> > > {
>>> > > local_fiq_disable();
>>> > >
>>> > > - if (omap_irq_pendin
Gary Thomas writes:
> I have an OMAP3530 (DM3730) board which uses a very simple
> power controller (TPS65910A1). This controller does not
> support many of the power supplies, etc, that are common
> on the TWL4030 and similar devices.
>
> I'm using Linux 3.0.
Can you try what you want with c
On Tue, Feb 07, 2012 at 02:36:06PM -0800, Kevin Hilman wrote:
> Tony Lindgren writes:
>
> [...]
>
> >> > > --- a/arch/arm/mach-omap2/pm34xx.c
> >> > > +++ b/arch/arm/mach-omap2/pm34xx.c
> >> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
> >> > > {
> >> > >local_fiq_disable();
Santosh Shilimkar writes:
> OMAP4 cpuidle driver is reporting the state requested by governor rather than
> the actually attempted one.
>
> This is obviously misleading sysfs and powertop cpuidle statistics.
> Fix it so that stats are reported correctly.
>
> Reported-by: Kevin Hilman
> Signed-of
Tony Lindgren writes:
[...]
>> > > --- a/arch/arm/mach-omap2/pm34xx.c
>> > > +++ b/arch/arm/mach-omap2/pm34xx.c
>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>> > > {
>> > > local_fiq_disable();
>> > >
>> > > -if (omap_irq_pending())
>> > > +if (omap_irq_
Russell King - ARM Linux writes:
[...]
> Another problem oopses the kernel at boot in the voltage domain code,
> which I suspect this has never been boot tested on OMAP34xx CPUs:
>
> omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not
> populated.Hence cannot initialize vc
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, m
This functionality has just been implemented in the cx20442 codec
driver, no need to keep it here duplicated.
Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the board header file and a call to the regulator_toggle()
helper function from the old API wrapper found in
After the CX20442 codec driver already takes care of enabling the codec
power for itself, but before dropping the old bias control method from
the Amstrad Delta ASoC sound card file, which in fact keeps the modem
power always on, even after the ASoC device close for now, extend the
modem setup with
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, m
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak wrote:
> MMC1 is not the only instance that can be used/wired for SD.
> So remove this assumption from the driver.
>
> Signed-off-by: Rajendra Nayak
> ---
> drivers/mmc/host/omap_hsmmc.c | 14 --
> 1 files changed, 0 insertions(+), 14
Hi,
Looks like the register offsets are incorrect in the OMAP mailbox code
(arch/arm/mach-omap2/mailbox.c) for the OMAP4_MAILBOX_IRQ* macros. The
discrepancy is with p.224 of TI document SPRUGX9 and p3891 of SWPU231K.
Patch attached.
My hardware hasn't come in yet, so I would appreciate it if any
On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
> The twl changes were done like that because it was assuming that
> USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
> platforms at 3.3 time. The whole point of doing that was to reduce
> the ifdefery in every d
On Tuesday 07 February 2012 02:02 AM, S, Venkatraman wrote:
I gave it a spin on Beagleboard-XM (OMAP3630) with root filesystem
on the SD card, and checked again on 4430SDP.
Tested-by: Venkatraman S
Great, thanks Venkat.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" i
On Mon, 6 Feb 2012, Tony Lindgren wrote:
Yes that's the current URL. For most part all the code is in the
mainline kernel, and the linux-omap git tree is used for staging
the patches for every merge window. Right now the focus is getting
all the fixes into the -rc cycle, and over next few weeks
On 02/07/2012 03:43 PM, Mark Brown wrote:
> That just sounds far too icky - I'm really not happy that people have
> been doing that in ASoC TBH, it just makes everything more tricky than
> it should be. It save a little bit of effort with the control but just
> pushes that complexity elsewhere whe
On Tue, Feb 07, 2012 at 03:39:24PM +0200, Peter Ujfalusi wrote:
> In the codec driver I have one 'shadow' register which does not exist on
> the HW. I'm going to need to have access to that shadow register's bits
> in the future transparently.
Alternatively just rewrite the code for that to use a
On 02/07/2012 03:29 PM, Mark Brown wrote:
> and it looks like you'll save a bunch more code if you're able to
> convert over to using a regmap cache. Note that as a first pass you
> just need to define which registers are volatile and enable a cache type
> - if defaults are omitted then the values
On Tue, Feb 07, 2012 at 03:01:14PM +0200, Peter Ujfalusi wrote:
> - select SND_SOC_TWL6040 if TWL4030_CORE
> + select SND_SOC_TWL6040
I'd expect this to be changed to an if I2C rather than no dependency at
all?
signature.asc
Description: Digital signature
On 02/07/2012 03:16 PM, Mark Brown wrote:
> though I'd be inclined to just embed this structure into the twl6040
> struct directly, you're always going to need to allocate it and it saves
> a tiny bit of error handling and whatnot.
True. I'm not sure why I have settled with this solution... As I r
On Tue, Feb 07, 2012 at 03:01:13PM +0200, Peter Ujfalusi wrote:
> Complete the separation of the twl6040 from the twl core since
> it is a separate chip, not part of the twl6030 PMIC.
Looking good
Reviewed-by: Mark Brown
and it looks like you'll save a bunch more code if you're able to
convert
On Tue, Feb 07, 2012 at 03:01:18PM +0200, Peter Ujfalusi wrote:
> twl6040 has three power supply source:
> VBAT needs to be connected to VBAT, VIO, and V2V1.
> Add regulator support for the VIO, V2V1 supplies.
> Initially handle the two supply together with bulk commands.
> Signed-off-by: Peter Uj
The board has two fixed voltage regulator. Correct the
device ID for the vbat, which used -1.
Create defines for the fixed regulator IDs so when adding new
regulators we know the next available ID to use for them.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-4430sdp.c |7 +
The twl6040 VIO power is connected to SMPS V1V8, the
V2V1 power is coming from SMPS V2V1 of twl6030.
These are fixed, always on regulators.
Create fixed voltage regulators for these supplies.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-4430sdp.c | 58 +++
twl6040 has three power supply source:
VBAT needs to be connected to VBAT, VIO, and V2V1.
Add regulator support for the VIO, V2V1 supplies.
Initially handle the two supply together with bulk commands.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl6040-core.c | 41 ++
The twl6040 VIO power is connected to SMPS V1V8, the
V2V1 power is coming from SMPS V2V1 of twl6030. These are fixed,
always on regulators.
Create fixed voltage regulators for these supplies.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-omap4panda.c | 62
On OMAP4 platform audio has separate IC, it is no longer part
of the pmic chip.
Prevent twl-core to claim the 0x4b address, which belongs to
the twl6040 audio IC.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 58 +++
1 files changed, 33
Complete the separation of the twl6040 from the twl core since
it is a separate chip, not part of the twl6030 PMIC.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-4430sdp.c| 12 ++--
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/board-omap4panda.c | 1
twl6040 no longer needs twl4030.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 7c205e7..9462d50 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/c
Hello,
Changes since v1 (RFC series):
- make use of regmap in the converted twl6040 driver [1]
- use module_i2c_driver to reduce line of code
- Use regulator_bulk functions for now in the twl6040 mfd driver. [2]
[1] Initially I'm not using the register cache offered by regmap, it will come
as a f
On Fri, Feb 03, 2012 at 17:13:53, Hiremath, Vaibhav wrote:
> This patch series removes the existing hard-coded way of providing
> offset to omap4_prminst_xxx API's and instead use offsets
> provided in powerdomains_data.
> Also, hook up AM33XX device support to existing omap4 PRM code.
>
> Bac
On Tue, Feb 7, 2012 at 1:54 AM, Gary Thomas wrote:
> This will be a bit more of a change than just another PMIC since
> this device isn't much of a power manager (other than at the very
> lowest level to handle power up sequencing, etc). It's good to
> hear that it _should_ work and I look forwar
On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> FYI, I'm now seeing the same warning as Igor posted with
> omap2plus_defconfig using the same compiler as Igor:
>
> gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
>
> Still no other warnings though.
If you're not getting the twl
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak wrote:
> This series mainly cleans up all instances of hardcoding's in
> the driver based on pdev->id. This is cleanup leading to the
> DT adaptation of omap_hsmmc driver.
>
> Patches are based on 3.3-rc2 and can be found here
> git://gitorious.org/om
On Tue, Feb 07, 2012 at 06:26:52AM +0100, Cousson, Benoit wrote:
> Moreover, with Rob latest series, IRQ_DOMAIN will be enabled on every
> ARM platform, so the "depend IRQ_DOMAIN" that "fix" is removing right
> now will have to be added again once we will move that code to use
> genirq domain
On Tue, Feb 07, 2012 at 01:54:57AM +0100, Cousson, Benoit wrote:
> Hi Russell,
>
> On 2/7/2012 1:24 AM, Russell King - ARM Linux wrote:
>> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>>> In theory that patch should not be even needed.
>>
>> In theory that change is needed to fi
55 matches
Mail list logo