On Thu, 9 Feb 2012, Paul Walmsley wrote:
Remove omap_{read,write}l() from the 24xx PM code. The clocksource
code should now handle what this was supposed to do.
Tested on N800 -- but it's hard to say whether this fixes anything.
OMAP24xx static suspend path is currently broken, and this
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 peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 58 +++
Hello,
Changes since v2:
- soc/codec/Kconfig: make twl6040 depend on I2C
- Regulator related patches has been removed (to be sent as separate series)
--
Intro mail from the original series:
This series will convert the twl6040 MFD driver to an i2c driver.
Compared to older twl4030/5030/TPS
twl6040 no longer needs twl4030.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
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..f1a1197 100644
---
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 peter.ujfal...@ti.com
Reviewed-by: Mark Brown broo...@opensource.wolfsonicro.com
---
arch/arm/mach-omap2/board-4430sdp.c| 12 ++--
Hello,
This series depends on the V3 of MFD: twl6040: Conversion to i2c driver set.
In order to have proper regulator support for twl6040 on SDP4430, and
PandaBoards I needed to add support for the V1V8, and V2V1 SMPS supplies from
twl6030.
The configuration on both boards (and the TRM
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 peter.ujfal...@ti.com
---
V1V8 supply most common use is to provide VIO for the system.
V2V1 supply is used on SDP4430/PandaBoards to provide 2.1V to
twl6040, and also as an input to VCXIO_IN, VDAC_IN of twl6030.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/regulator/twl-regulator.c |2 ++
1 files
To be able to attach consumers to these supplies from board
files we need to have regulator_init_data for them.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 10 ++
include/linux/i2c/twl.h |2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
These supplies going to be needed for the twl6040 driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
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 peter.ujfal...@ti.com
Reviewed-by: Mark Brown
These supplies going to be needed for the twl6040 driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
V1V8 supply from twl6030 commonly used as VIO for the machine.
V2V1 is adviced to supply the twl6040, and also to feed the twl6030's
VCXIO_IN, and VDAC_IN inputs.
Create the common regulator configurations for these regulators:
Make the V2V1 as supply_regulator for VCXIO, VDAC.
Add twl6040
On 02/10/2012 08:54 AM, Axel Lin wrote:
Fix below build error which is introduced by
commit 022658 ASoC: core: Add support for DAI and machine kcontrols.
CC [M] sound/soc/omap/n810.o
sound/soc/omap/n810.c: In function 'n810_set_input':
sound/soc/omap/n810.c:194: error: 'codec' undeclared
On Fri, Feb 10, 2012 at 12:00:18PM +0200, Peter Ujfalusi wrote:
twl6040 no longer needs twl4030.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
This should go via whatever path the first two patches go.
signature.asc
On Fri, Feb 10, 2012 at 12:05:11PM +0200, Peter Ujfalusi wrote:
V1V8 supply most common use is to provide VIO for the system.
V2V1 supply is used on SDP4430/PandaBoards to provide 2.1V to
twl6040, and also as an input to VCXIO_IN, VDAC_IN of twl6030.
Signed-off-by: Peter Ujfalusi
On Fri, Feb 10, 2012 at 02:54:37PM +0800, Axel Lin wrote:
Fix below build error which is introduced by
commit 022658 ASoC: core: Add support for DAI and machine kcontrols.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Feb 9, 2012 at 8:36 PM, Tony Lindgren t...@atomide.com wrote:
Please everybody using omaps with mainline give a test for the
merge of the various fixes planned. I've done a branch with
v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
that I've queued up.
Seems to be good
On Tue, Feb 7, 2012 at 3:32 PM, S, Venkatraman svenk...@ti.com wrote:
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak rna...@ti.com 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
This patch series colates the various i2c updates into
a series. Since it is collection of various patches
the version info is not retained, however most of them undergone
multiple versions.
This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d
The patch series does the
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Cc: Kevin Hilman khil...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Previous discurssion
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
Currently the i2c driver calls the pm_runtime_enable and never
the disable. This may cause a warning when pm_runtime_enable
checks for the count match.Attempting to fix the same by calling
pm_runtime_disable in the error and the remove path.
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak
Hi
On Fri, 10 Feb 2012, Hiremath, Vaibhav wrote:
On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
I tried it on AM37x EVM, it did worked for me but I have some observations,
On Fri, Feb 10, 2012 at 07:10:06AM +, Hiremath, Vaibhav wrote:
On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
I tried it on AM37x EVM, it did worked for me but I have some
On Thu, Feb 9, 2012 at 23:58, Shubhrajyoti D shubhrajy...@ti.com wrote:
Currently the memory region is not released the folowing error is
observed.
/testsuites # insmod omap-serial.ko
[ 130.746917] omap_uart omap_uart.0: memory region already claimed
[ 130.753143] omap_uart: probe of
On Thu, 9 Feb 2012 21:18:49 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote:
Hi,
On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Again, I'm totally confused as to _WHY_ this needs to
Hi Benoit,
HWMOD entries currently does contain GPMC, is it due to the reason that
GPMC is not yet adapted to omap_device / omap_hwmod or is there any
other reason for not having it in HWMOD (as GPMC not yet a driver?)
Yes, that's the reason.
Nobody had the time to update that driver
Hi,
These changes does,
1. detect SoC type (i.e. GP or not)
2. add minimal SRAM support
for AM335X devices
These are required to get AM335X boot to prompt (but not sufficient)
Regards
Afzal
Afzal Mohammed (1):
arm:omap:am33xx: SoC type detection
Vaibhav Bedia (1):
arm:omap: am33xx SRAM
Determine SoC type, i.e. whether GP or not
Note: cpu_is_34xx() is true for am33xx also. Doing
cpu_is_am33xx() check after cpu_is_34xx() will not
achieve what we want due to the above reason.
Hence cpu_is_am33xx() is done before cpu_is_34xx()
Signed-off-by: Afzal Mohammed af...@ti.com
From: Vaibhav Bedia vaibhav.be...@ti.com
Update SRAM start size for am33xx SoC's.
Note: cpu_is_34xx() is true for am33xx also. Doing
cpu_is_am33xx() check after cpu_is_34xx() will not
achieve what we want due to the above reason.
Hence cpu_is_am33xx() is done before cpu_is_34xx()
On Fri, Feb 10, 2012 at 19:49:57, Paul Walmsley wrote:
Hi
On Fri, 10 Feb 2012, Hiremath, Vaibhav wrote:
On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
I tried it on
On Fri, Feb 10, 2012 at 5:35 PM, Justin P. Mattock
justinmatt...@gmail.com wrote:
On Thu, 9 Feb 2012 21:18:49 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote:
Hi,
On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras
On Fri, 10 Feb 2012 18:05:59 +0200
Felipe Contreras felipe.contre...@gmail.com wrote:
On Fri, Feb 10, 2012 at 5:35 PM, Justin P. Mattock
justinmatt...@gmail.com wrote:
On Thu, 9 Feb 2012 21:18:49 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 09, 2012 at 04:45:00PM -0800,
On Fri, Feb 10, 2012 at 7:18 AM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote:
Hi,
On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Again, I'm totally confused as to _WHY_ this needs to be y.
On Fri, Feb 10, 2012 at 06:05:59PM +0200, Felipe Contreras wrote:
From 5c7ad6c00d051d574007cdbecdf14bf3d0cb Mon Sep 17 00:00:00 2001
From: Justin P. Mattock justinmatt...@gmail.com
Date: Fri, 10 Feb 2012 07:19:45 -0800
Subject: [PATCH] Add dependency TIDSBRIDGE_WDT3 to TIDSBRIDGE.
On Fri, Feb 10, 2012 at 6:16 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Feb 10, 2012 at 06:05:59PM +0200, Felipe Contreras wrote:
From 5c7ad6c00d051d574007cdbecdf14bf3d0cb Mon Sep 17 00:00:00 2001
From: Justin P. Mattock justinmatt...@gmail.com
Date: Fri, 10 Feb 2012 07:19:45
On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
There is no optimisation to adding __refdata to stuff. That's screaming
that you have lots of bugs here.
Thanks for your teaching. I find those aspects not very exhaustively documented
under Documentation/, so any hints
While resolving section mismatches introduced with recent patches
to for-next, a few dangerous, driver bind/unbind unaware section
tagging already present in mainline have been identified. Fix them.
Created and tested against linux-3.3-rc2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.
While being at it, section tagging of all init
* Matt Porter m...@ohporter.com [120208 13:35]:
This fixes smsc911x support on omap3evm that has been broken since
the smsc911x driver was updated to require the existence of vdd33a
and vddvario supplies.
Great. Few comments:
1. Could you please include the smsc911x commit and subject here
On Fri, Feb 10, 2012 at 06:16:19PM +0200, Felipe Contreras wrote:
On Fri, Feb 10, 2012 at 7:18 AM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote:
Hi,
On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras
On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote:
It's not an oops, it's a warning, and again, it depends on the
firmware being used. We don't have control over that, and we have no
way to detect if this feature is there. It's up to the user.
Perhaps just remove the warning
On Fri, Feb 10, 2012 at 8:53 PM, Menon, Nishanth n...@ti.com wrote:
On Thu, Feb 9, 2012 at 23:58, Shubhrajyoti D shubhrajy...@ti.com wrote:
Currently the memory region is not released the folowing error is
observed.
/testsuites # insmod omap-serial.ko
[ 130.746917] omap_uart omap_uart.0:
* Brian Austin brian.aus...@cirrus.com [120207 06:23]:
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
On Thu, Feb 09, 2012 at 07:19:47PM -0700, Paul Walmsley wrote:
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
Regarding the issue that Vaibhav reported with:
omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck
I also see it on my xM
Hi,
* Ajay Kumar Gupta ajay.gu...@ti.com [120207 19:55]:
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git
On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
* Matt Porter m...@ohporter.com [120208 13:35]:
This fixes smsc911x support on omap3evm that has been broken since
the smsc911x driver was updated to require the existence of vdd33a
and vddvario supplies.
Great. Few comments:
* Paul Walmsley p...@pwsan.com [120209 17:48]:
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
Rex, care to confirm this is also the case for you with
your custom .config?
Regards,
Tony
--
To unsubscribe from this list: send the line
* Santosh Shilimkar santosh.shilim...@ti.com [120202 05:33]:
From: Rajendra Nayak rna...@ti.com
hwmod setup already does a reset and sets the OCP sysconfig
registers appropriately. Avoid doing a reset again and overriding
the OCP sysconfig settings in the system timer init code.
If we want
* Santosh Shilimkar santosh.shilim...@ti.com [120202 05:33]:
arm_memblock_steal() is not suppose to be used outside -reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of -reserve callback to fix the it.
Hi Tarun,
* Tarun Kanti DebBarma tarun.ka...@ti.com [120202 09:00]:
Used following patches to avoid exception during system suspend:-
[PATCH RFC 1/2] mtd : Prevent the NULL pointer access
[PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not
implemented
OK so MTD
Paul Walmsley p...@pwsan.com writes:
On Thu, 9 Feb 2012, Paul Walmsley wrote:
Remove omap_{read,write}l() from the 24xx PM code. The clocksource
code should now handle what this was supposed to do.
Tested on N800 -- but it's hard to say whether this fixes anything.
OMAP24xx static
On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote:
It's not an oops, it's a warning, and again, it depends on the
firmware being used. We don't have control over that, and we have no
way to detect if
Tony Lindgren t...@atomide.com writes:
[...]
..but are there also some patches in your series that should also be
applied separately as fixes for the -rc cycle?
IMO, there aren't any things in this series that fall into the
regression category.
After I get to a final review and test of this
Hi Dong,
* Dong Aisheng donga...@gmail.com [120207 17:22]:
On 2/4/12, Tony Lindgren t...@atomide.com wrote:
The most difference may be the function enable due to hw difference.
But i see that for DT case, it seems function and group creation may
also be a problem.
What all do you see as a
On Fri, Feb 10, 2012 at 01:53:12PM +0200, Grazvydas Ignotas wrote:
On Thu, Feb 9, 2012 at 8:36 PM, Tony Lindgren t...@atomide.com wrote:
Please everybody using omaps with mainline give a test for the
merge of the various fixes planned. I've done a branch with
v3.3-rc3 + Russell's fixes +
Hi Shawn,
Sorry for the delay, some of this we already talked this week
at the conference.
* Shawn Guo shawn@linaro.org [120206 17:13]:
On Fri, Feb 03, 2012 at 12:55:08PM -0800, Tony Lindgren wrote:
It's so great to eventually see some codes after such an extensive
discussion on the
On Fri, Feb 10, 2012 at 09:42:32PM +0200, Felipe Contreras wrote:
On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter dan.carpen...@oracle.com
wrote:
On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote:
It's not an oops, it's a warning, and again, it depends on the
firmware being
On Fri, Feb 10, 2012 at 10:35 PM, Dan Carpenter
dan.carpen...@oracle.com wrote:
On Fri, Feb 10, 2012 at 09:42:32PM +0200, Felipe Contreras wrote:
On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter dan.carpen...@oracle.com
wrote:
On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote:
* Matt Porter mpor...@ti.com [120210 10:19]:
On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
* Matt Porter m...@ohporter.com [120208 13:35]:
This fixes smsc911x support on omap3evm that has been broken since
the smsc911x driver was updated to require the existence of vdd33a
Hello Matt, Vaibhav,
On Fri, 10 Feb 2012, Matt Porter wrote:
On Thu, Feb 09, 2012 at 07:19:47PM -0700, Paul Walmsley wrote:
Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's
testing branch; it works.
Regarding the issue that Vaibhav reported with:
omap_hwmod:
Hi Tony,
On Fri, Feb 10, 2012 at 12:05:03PM -0800, Tony Lindgren wrote:
Hi Dong,
* Dong Aisheng donga...@gmail.com [120207 17:22]:
On 2/4/12, Tony Lindgren t...@atomide.com wrote:
The most difference may be the function enable due to hw difference.
But i see that for DT case, it seems
Currently the memory region is not released the folowing error is
observed.
/testsuites # insmod omap-serial.ko
[ 130.746917] omap_uart omap_uart.0: memory region already claimed
[ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
[ 130.759338] omap_uart omap_uart.1: memory
71 matches
Mail list logo
