On Sun, Nov 04, 2012 at 04:14:30PM +0530, Shubhrajyoti D wrote:
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Reviewed-by: Felipe
On Sun, Nov 04, 2012 at 04:14:31PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Hi,
On Sun, Nov 04, 2012 at 04:14:32PM +0530, Shubhrajyoti D wrote:
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by:
Hi,
On Sun, Nov 04, 2012 at 04:14:33PM +0530, Shubhrajyoti D wrote:
Currently the restore is done based on the flag
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE.
This helps the following
- The driver is always capable of restoring regardless
of the off mode support being there or not.
- While
On 2012-11-02 20:54, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [121102 01:56]:
On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 08:38, Santosh Shilimkar wrote:
Lets not move this in DMA code since the above is really related
to frame buffer. It
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the
On Sat, Nov 03, 2012 at 02:32:59PM -0500, Joel A Fernandes wrote:
beaglebone_defconfig: Add dummy regulator to init tlv320aic3x
https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93
This should never be done in production, you should ensure that the
Hi,
On Thu, Oct 25, 2012 at 03:25:08PM +0300, Felipe Balbi wrote:
Hi,
here's another series for OMAP I2C driver. There are a few cleanups
and one very nice new feature: we can now report how many bytes
we transferred until NACK.
Note that the implemementation for OMAP-I2C turned out to
On Monday 05 November 2012 01:16 PM, Felipe Balbi wrote:
include/linux/i2c-omap.h |1 -
4 files changed, 104 insertions(+), 75 deletions(-)
since I have reviewed your previous version, it would be nice to Cc me
so I don't loose your series ;-)
OK will do that. thanks
On Monday 05 November 2012 01:20 PM, Felipe Balbi wrote:
Hi,
On Sun, Nov 04, 2012 at 04:14:27PM +0530, Shubhrajyoti D wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev
On Monday 05 November 2012 01:23 PM, Felipe Balbi wrote:
Hi,
On Sun, Nov 04, 2012 at 04:14:29PM +0530, Shubhrajyoti D wrote:
The dtrev is used only for the comments. Remove the same and use
the scheme instead to know if it is version2.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
I
On 2012-11-03 02:31, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of
On 2012-11-02 13:56, Archit Taneja wrote:
On Friday 02 November 2012 04:58 PM, Tomi Valkeinen wrote:
On 2012-11-02 13:09, Archit Taneja wrote:
On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 12:44, Archit Taneja wrote:
Hmm, that makes sense. Anyway, I don't think
Hi,
On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote:
@@ -1155,7 +1187,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev OMAP_I2C_REV_ON_3630_4430)
+ if (dev-rev OMAP_I2C_REV_ON_3630)
On Sun, Nov 04, 2012 at 20:54:17, Bedia, Vaibhav wrote:
On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote:
On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT
instead of ADDR_TYPE_RT to ensure the omap hwmod code
Hi,
On Mon, Nov 05, 2012 at 02:14:48PM +0530, Shubhrajyoti wrote:
On Monday 05 November 2012 01:23 PM, Felipe Balbi wrote:
Hi,
On Sun, Nov 04, 2012 at 04:14:29PM +0530, Shubhrajyoti D wrote:
The dtrev is used only for the comments. Remove the same and use
the scheme instead to know if
Paul,
On Mon, Nov 5, 2012 at 4:15 AM, Paul Walmsley p...@pwsan.com wrote:
Hi Jean,
On Sat, 3 Nov 2012, Jean Pihet wrote:
The setup is as identical as possible to yours:
- U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) from
http://www.pwsan.com/tmp/3530es3beagle-MLO-u-boot-20121023.tar.bz2.
On Monday 05 November 2012 02:35 PM, Felipe Balbi wrote:
egister map is different.
So the scheme may still be required.
fair enough, but drop it from debugging messages.
OK thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to
PWM subsystem. All these submodules shares the resources (clock) has
a clock gating register in PWM Subsystem. This patch series creates a
parent PWM Subsystem driver to handle access synchronization of shared
resources clock
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP EHRPWM).
To handle resource sharing IP integration
1. Rework on parent child relation between PWMSS and
ECAP, EQEP EHRPWM child devices to support runtime PM.
2. Add support for
Add support for device-tree binding for EHRWPM driver.
Also size of #pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
Also enable clock gating in PWM subsystem common config space.
Also when here set .owner member in platform_driver structure
Some platforms (like AM33XX) requires clock gating from control module
explicitly. So adding optional TBCLK handling if DT node populated with
tbclkgating. This helps the driver can coexist for Davinci platforms.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 1e63652...
Add PWMSS device tree nodes in relation with ECAP EHRPWM DT nodes to
AM33XX SoC family. Also populates device tree nodes for ECAP EHRPWM by
adding necessary properties like pwm-cells, base reg set disabled as
status.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Second version
PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Second version
- Combined with HWMOD changes DT bindings.
- No changes
:100644 100644
Add support for device-tree binding for ECAP APWM driver.
Also size of #pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
Also enable clock gating in PWM subsystem common config space.
Also when here set .owner member in platform_driver
EHRPWM module requires explicit clock gating from control module.
Hence add clock node in clock tree for EHRPWM modules.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 17e3de5... 833260f... M arch/arm/mach-omap2/clock33xx_data.c
:100644 100644 a89e825... c0e34e6... M
In some platforms (like am33xx), PWM sub modules (ECAP, EHRPWM, EQEP)
are integrated to PWM subsystem. These PWM submodules has resources
shared and only one register bit-field is provided to control
module/clock enable/disable, makes it difficult to handle common
resources from independent PWMSS
On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote:
@@ -1155,7 +1187,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts
Add PM power_off control to rtc driver, along with this PMIC status
is set to STATUS_OFF to shutdown PMIC if PWR_EN is toggled by RTC
module.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is
supported. Also adds platform data flag, which should be
passed from board init data.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to
Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
1 file changed, 2 insertions(+)
diff --git
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when
Hi Florian,
Here are a few omapdss fixes, two fixing crasher bugs and the third
fixes a missing unlock. These are based on 3.7-rc1. I can rebase on
top of something else if you prefer that.
Tomi
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1
Hi,
On Mon, Nov 05, 2012 at 02:54:32PM +0530, Shubhrajyoti Datta wrote:
On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote:
@@ -1155,7 +1187,7 @@ omap_i2c_probe(struct platform_device *pdev)
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc:
Add pinmux configurations for gpio volume keys. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is
Add gpio based push buttons device tree data to am335x-evmsk device
by adding all the necessary parameters like key-code, gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 31 +++
1 file changed, 31 insertions(+)
Add pinmux configurations for gpio based keys to am335x-evmsk. In
this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations
Add gpio-leds device tree data to am335x-evmsk device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on am335x starter
kit.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 30 ++
1 file changed, 30
Add pinmux configurations for gpio based user-keys to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations
Add pinmux configurations for gpio matrix keypad. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is
Add gpio based volume keys device tree data to am335x-evm by adding
all the required parameters like keycode, gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git
Add pinmux configurations for gpio based volume keys to am335x-evmsk.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this
Add gpio-leds device tree data to am335x-bone device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 30
Add matrix keypad device tree data to am335x-evm by adding all
the necessary parameters like keymap, row column gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git
Add device tree date for GPIO based various drivers matrix keypad,
volume keys, push buttons and use leds accross three AM33XX devices
viz EVM, BeagleBone and Starter Kit.
To make it functional this series also adds pinctrl data for all
the GPIOs used by various drivers. In this series only
Hi Lokesh,
On 11/05/2012 06:58 AM, Lokesh Vutla wrote:
Hi,
On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote:
This patch series adds Device tree data for the EMIF
sdram controllers in OMAP5 and LPDDR2 memory devices
in OMAP5-evm board.
Testing:
- Boot tested on OMAP5430 evm.
-
Hi,
On Mon, Nov 05, 2012 at 12:01:05PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Nov 05, 2012 at 02:54:32PM +0530, Shubhrajyoti Datta wrote:
On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote:
@@
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi
On Fri, Nov 02, 2012 at 20:55:54, Daniel Mack wrote:
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..c3616c6
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
On 11/05/2012 11:51 AM, Benoit Cousson wrote:
Hi Lokesh,
On 11/05/2012 06:58 AM, Lokesh Vutla wrote:
Hi,
On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote:
This patch series adds Device tree data for the EMIF
sdram controllers in OMAP5 and LPDDR2 memory devices
in OMAP5-evm board.
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC
Hi Benoit,
On Monday 05 November 2012 04:33 PM, Benoit Cousson wrote:
On 11/05/2012 11:51 AM, Benoit Cousson wrote:
Hi Lokesh,
On 11/05/2012 06:58 AM, Lokesh Vutla wrote:
Hi,
On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote:
This patch series adds Device tree data for the EMIF
sdram
+ Felipe
Hi Afzal,
On 11/05/2012 06:59 AM, Afzal Mohammed wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg interrupt property addition]
Hi Kevin,
On 11/03/2012 09:31 AM, Kevin Hilman wrote:
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
When booting with DT the OF core can fill up the resources provided
within
the DT blob.
The current way of handling the DT boot prevents us from removing
hwmod data
for platforms only
On Thu, Nov 01, 2012 at 19:19:41, Cousson, Benoit wrote:
Hi Avinash,
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
The errata i207 is enabled for 2430 and 3xxx. Use the revision check
to enable the erratum instead.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
Does the followiing
- Make the revision a 32- bit consisting of rev_lo amd rev_hi each
of 16 bits.
- Also use the revision register for the erratum i207.
- Refactor the i2c_omap_init code.
Adds a patch to remove the hardcoding sysc register. Instead
read register ,reset and then writeback the
Currently after the reset the sysc is written with hardcoded values.
The patch reads the sysc register and writes back the same value
after reset.
- Some unnecessary rev checks can be optimised.
- Also due to whatever reason the hwmod flags are changed
we will not reset the values.
- In some of
Currently the restore is done based on the flag
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE.
This helps the following
- The driver is always capable of restoring regardless
of the off mode support being there or not.
- While testing omap2430 it is found that in case of certain
error paths (timeout) a
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie bit-14 of the hi register to know if it
is OMAP_I2C_IP_VERSION_2.
On platforms
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |
The dtrev is used only for the comments. Remove the same and use
the scheme instead to know if it is version2.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v3: remove the scheme from the commments.
todo: remove the dtrev from hwmod etc.
drivers/i2c/busses/i2c-omap.c | 12 +---
Memory present for OMAP5-evm is 2GB. But in dts file
it is specified as 1GB. Correcting the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts
This patch series adds Device tree data for the EMIF
sdram controllers in OMAP5 and LPDDR2 memory devices
in OMAP5-evm board.
Testing:
- Boot tested on OMAP5430 evm.
- Built EMIF as a module.
Changes from v2:
* Rebased on top of
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ead74c8..790bb2a 100644
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 11 +
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Hi,
OMAPDSS device tree support is still some way in the future. Tony has requested
to get DSS working for Panda SDP boards with DT kernel, so that we'll have
fully working boards with DT.
This series makes a few hacks to get a working display on OMAP4 Panda and SDP
boards. The idea is to setup
Device tree support for omapdss is still some way in the future. In an
effort to get a minimal DSS support for DT enabled kernel on selected
OMAP4 boards, we'll go for a temporary solution: We will call the same
non-DT omapdss setup code for OMAP4 SDP and Pandaboards from
board-generic.c, thus
Normally the omapdss driver gets the regulators using the regulator
names assigned for omapdss. However, in an effort to get a minimal DSS
support for DT enabled kernel on selected boards, we will add omapdss
devices and platform data the old way even for DT kernel. This causes
the problem that
Call the non-DT omapdss setup code from board-generic if the board is
omap4-panda or omap4-sdp. This will give us working omapdss for those
boards when using DT kernel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 10 ++
1 file changed,
Device tree support for omapdss is still some way in the future. In an
effort to get a minimal DSS support for DT enabled kernel on selected
OMAP4 boards, we'll go for a temporary solution: We will call the same
non-DT omapdss setup code for OMAP4 SDP and Pandaboards from
board-generic.c, thus
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Hi Ricardo,
On 2012-11-05 15:14, Tomi Valkeinen wrote:
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Assuming that we do work on a DT object format, and that the runtime
resolution mechanism is approved,
then I agree that this part of the capebus patches
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the
On Mon, Nov 05, 2012 at 16:15:40, AnilKumar, Chimata wrote:
Add device tree date for GPIO based various drivers matrix keypad,
volume keys, push buttons and use leds accross three AM33XX devices
viz EVM, BeagleBone and Starter Kit.
To make it functional this series also adds pinctrl data for
On Mon, Nov 05, 2012 at 05:53:36PM +0530, Shubhrajyoti D wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie bit-14 of the
On Mon, Nov 05, 2012 at 05:53:38PM +0530, Shubhrajyoti D wrote:
The dtrev is used only for the comments. Remove the same and use
the scheme instead to know if it is version2.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
v3: remove the scheme
Hi,
On Mon, Nov 05, 2012 at 05:53:43PM +0530, Shubhrajyoti D wrote:
Currently after the reset the sysc is written with hardcoded values.
The patch reads the sysc register and writes back the same value
after reset.
- Some unnecessary rev checks can be optimised.
- Also due to whatever
On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote:
-dev-syscstate);
- }
not sure if this will work. What about the first time you call reset() ?
won't SYSC just contain the reset values ?
No actually the hwmod sets the value.
Hi,
On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote:
On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote:
- dev-syscstate);
-}
not sure if this will work. What about the first time you call reset() ?
won't
On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Assuming that we do work on a DT object format, and that the runtime
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote:
On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files
On Sunday 04 November 2012 08:55 PM, Bedia, Vaibhav wrote:
Hi Santosh,
On Sat, Nov 03, 2012 at 21:22:04, Shilimkar, Santosh wrote:
On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
From: Vaibhav Hiremath hvaib...@ti.com
The current OMAP timer code registers two timers -
one as
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote:
On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
On Sat, Nov 03, 2012 at 21:33:47, Shilimkar, Santosh wrote:
[...]
+static int omap2_mbox_fifo_needs_flush(struct omap_mbox *mbox)
+{
+ struct omap_mbox2_fifo *fifo =
+ ((struct omap_mbox2_priv *)mbox-priv)-tx_fifo;
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
On Sat, Nov 03, 2012 at 21:40:37, Shilimkar, Santosh wrote:
[...]
+#if defined(CONFIG_SOC_AM33XX)
+ else if (soc_is_am33xx()) {
+ list = am33xx_mboxes;
+
+ list[0]-irq = platform_get_irq(pdev, 0);
+
smartreflex.c now resides in drivers/power/avs directory,
but class driver is in mach-omap2. High time we move it
to drivers/power/avs.
This series *does not* try to fix VP/VC to be voltage
regulator OR introduce a new OMAP voltage regulator series.
Instead, it purely tries to do the minimal
SoC integration of SmartReflex AVS block is varied. Some use
Voltage Processor for a hardware loop in certain OMAP SoC (called
hardware loop), while others have just the AVS block without
hardware loop automatic calibration mechanism for AVS block
to talk through. So provide the Voltage Processor
remove duplicate definitions which are already present
in linux/platform_data/voltage-omap.h
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h
Minor cleanup to use the preferred pr_warn
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
Don't see why the source should be in drivers/power/avs, but not config option
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/Kconfig | 22 --
drivers/power/avs/Kconfig | 22 ++
2 files changed, 22
Move voltdm_reset to include/linux/platform_data/voltage-omap.h
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.h |1 -
include/linux/platform_data/voltage-omap.h |1 +
2 files changed, 1 insertion(+), 1
1 - 100 of 190 matches
Mail list logo
