On Friday 07 June 2013 12:16 AM, Nishanth Menon wrote:
On 23:21-20130606, Sricharan R wrote:
Hi,
On Wednesday 05 June 2013 07:27 PM, Nishanth Menon wrote:
On 12:16-20130605, Sricharan R wrote:
From: Roger Quadros rog...@ti.com
[...]
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
+ Chris since the patch has some davinci_mmc.c changes.
Chris, Mark,
On 3/6/2013 9:45 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
Can
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.
This will help us use the overlay manager structs with omapdrm in the
following
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Separate the regulator initialization code to its own function, removing
duplicate code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 82 ---
1 file
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Split regulator and DSI PLL init code to their own functions for
clarity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 100 ++
1 file changed, 53
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Add helper functions to convert between omapdss specific video timings
and the common videomode.
Eventually omapdss will be changed to use only the common video timings,
and these helper functions will make the transition easier.
So we
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote:
On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote:
On 6/6/2013 12:53 AM, Mark Brown wrote:
Linus Walleij posted some patches which factor the state setting code
out into generic functions earlier on today - it
From: Linus Walleij linus.wall...@linaro.org
Date: Fri, 7 Jun 2013 09:31:58 +0200
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote:
On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote:
On 6/6/2013 12:53 AM, Mark Brown wrote:
Linus Walleij posted some patches
cc Benoît
On Fri, 7 Jun 2013, Sricharan R wrote:
I used autogen to remove the data, but some of the data were not in sync
with the mainline .(like abe, dss, aess, context register offsets etc..).
So i have to sync them manually.
OK. Are you going to fix the differences up soon?
- Paul
On 07/06/13 09:46, Archit Taneja wrote:
@@ -384,6 +424,10 @@ int omap_dss_register_driver(struct
omap_dss_driver *dssdriver)
omapdss_default_get_recommended_bpp;
if (dssdriver-get_timings == NULL)
dssdriver-get_timings = omapdss_default_get_timings;
+if
On 07/06/13 10:06, Archit Taneja wrote:
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Add helper functions to convert between omapdss specific video timings
and the common videomode.
Eventually omapdss will be changed to use only the common video timings,
and these helper functions
On 06/06/13 23:43, Aaro Koskinen wrote:
Hi,
On Tue, Jun 04, 2013 at 10:40:37AM +0300, Tomi Valkeinen wrote:
I've made some big changes on the omapdss device model, which involves
converting all the panel drivers. I've got only a bunch of boards, so I
hope some of you can perhaps do some
On 07/06/13 09:51, Archit Taneja wrote:
-static int dpi_init_display(struct omap_dss_device *dssdev)
-{
-struct platform_device *dsidev;
-
-DSSDBG(init_display\n);
-
-if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
-dpi.vdds_dsi_reg == NULL) {
-struct
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote:
cc Benoît
On Fri, 7 Jun 2013, Sricharan R wrote:
I used autogen to remove the data, but some of the data were not in sync
with the mainline .(like abe, dss, aess, context register offsets etc..).
So i have to sync them manually.
OK.
3) Thinking about Mainline: To reach the same target - no I2C
detection - and taking
into account above assumption No changes in default behavior
the following will need to be done:
- change i2c-omap/i2c-gpio DT bindings and add parameter which will
allow to change
.class value for
Class based instantiation can cause huge delays when booting. This
mechanism was used when it was not possible to describe slaves on I2C
busses. We now have other mechanisms, so most embedded I2C will not need
classes and it was explicitly not recommended to use them. Add a
deprecation warning for
On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote:
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote:
cc Benoît
On Fri, 7 Jun 2013, Sricharan R wrote:
I used autogen to remove the data, but some of the data were not in sync
with the mainline .(like abe, dss, aess, context
On Fri, 7 Jun 2013, Tero Kristo wrote:
On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote:
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote:
cc Benoît
On Fri, 7 Jun 2013, Sricharan R wrote:
I used autogen to remove the data, but some of the data were not in sync
with
On Friday 07 June 2013 03:20 PM, Paul Walmsley wrote:
On Fri, 7 Jun 2013, Tero Kristo wrote:
On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote:
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote:
cc Benoît
On Fri, 7 Jun 2013, Sricharan R wrote:
I used autogen to remove the data, but
On 07/06/13 09:19, Archit Taneja wrote:
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.
This will help us use the overlay manager
Hi,
On 17/05/13 22:17, Tony Lindgren wrote:
Hi all,
Here are patches against v3.10-rc1 to drop omap4 legacy booting as
things are now working well enough for booting omap4 with device
tree.
We already have am33xx and omap5 booting with device tree only,
and converting omap4 is
Hi Wolfram,
On 06/07/2013 12:06 PM, Wolfram Sang wrote:
3) Thinking about Mainline: To reach the same target - no I2C
detection - and taking
into account above assumption No changes in default behavior
the following will need to be done:
- change i2c-omap/i2c-gpio DT bindings and add parameter
From: Graeme Gregory g...@slimlogic.co.uk
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid
Hi Benoit,
On Friday 07 June 2013 04:13 PM, Benoit Cousson wrote:
Hi Sricharan,
On 06/07/2013 12:27 PM, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
from OMAP4 SOC hwmod
Hi,
On Fri, Jun 07 2013, Sekhar Nori wrote:
+ Chris since the patch has some davinci_mmc.c changes.
Chris, Mark,
On 3/6/2013 9:45 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter
Add pinmux configurations for MII based CPSW ethernet to am335x-bone.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive state.
Add pinmux configurations for RGMII based CPSW ethernet to am335x-evm.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive
Add pinmux DT nodes to CPSW for the following AM335x boards
* AM335x Beaglebone
* AM335x EVM
* AM335x EVMsk
default state contains the pinmux required for active mode and
sleep mode contains pinmux reset values for energy saving.
Mugunthan V N (3):
ARM: dts: AM33XX: Add pinmux configuration for
Add pinmux configurations for RGMII based CPSW ethernet to AM335x EVMsk.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory
Hi,
I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the
DVI output's EDID reading to work. Testing with i2cget and i2cdump, I
see that I can read individual bytes with i2cget, but using i2cdump
doesn't work, it just shows 'XX'es.
The same issue is there with 3.10-rc4,
Hi Sricharan,
On 06/06/2013 07:48 PM, Sricharan R wrote:
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
OK, so in fact you are not just renaming the board file,
On 06/06/2013 07:48 PM, Sricharan R wrote:
uevm is the official board supported for OMAP5 soc in the mainline.
This series renames the board dts file for OMAP5 accordingly and cleans
up the same. Also a few additional device DT entry updates are done.
This is on top of the below branch
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
It looks like
Hi Benoit,
Thanks for the quick response.
From: Cousson, Benoit
Sent: Friday, June 07, 2013 5:57 PM
To: J, KEERTHY
Cc: devicetree-disc...@lists.ozlabs.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; ldewan...@nvidia.com;
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
from OMAP4 SOC hwmod data file.
- The devices which are still missing the device tree bindings,
address
hi Tomi,
On 06/07/2013 02:53 PM, Tomi Valkeinen wrote:
Hi,
I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the
DVI output's EDID reading to work. Testing with i2cget and i2cdump, I
see that I can read individual bytes with i2cget, but using i2cdump
doesn't work, it just
On 07/06/13 15:36, Grygorii Strashko wrote:
Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 13d1eca..66a62e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -615,11 +615,11
The uevm is the only official board supported for the OMAP5 soc
in mainline. The existent sevm platform will no more be supported.
Hence cleaning up the board dts file to have only the data
required for uevm.
Renaming the board dts file and adding the following cleanups.
* There are no devices
From: Sourav Poddar sourav.pod...@ti.com
Booting omap5 uevm results in the following error
did not get pins for uart error: -19
This happens because omap5 uevm dts file is not adapted to use uart through
pinctrl
framework. Populating uart pinctrl data to get rid of the error.
Cc: Sourav Poddar
uevm is the only official board supported for OMAP5 soc in the mainline.
This series deprecates the support for existent sevm which will no more
be supported in mainline and renames the board dts file accordingly.
Also a few additional device DT entry updates are done.
This is on top of the below
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R
From: Dan Murphy dmur...@ti.com
Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
On Friday 07 June 2013 05:36 PM, Benoit Cousson wrote:
On 06/06/2013 07:48 PM, Sricharan R wrote:
uevm is the official board supported for OMAP5 soc in the mainline.
This series renames the board dts file for OMAP5 accordingly and cleans
up the same. Also a few additional device DT entry
On Friday 07 June 2013 05:33 PM, Benoit Cousson wrote:
Hi Sricharan,
On 06/06/2013 07:48 PM, Sricharan R wrote:
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote:
* Hebbar Gururaja gururaja.heb...@ti.com [130531 03:19]:
Amend the hsmmc controller to optionally take a pin control handle and
set the state of the pins to:
- default on boot, resume and before performing a mmc transfer
- idle after
On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote:
From: Graeme Gregory g...@slimlogic.co.uk
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the
On 6/7/2013 1:12 PM, David Miller wrote:
From: Linus Walleij linus.wall...@linaro.org
Date: Fri, 7 Jun 2013 09:31:58 +0200
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote:
On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote:
On 6/6/2013 12:53 AM, Mark Brown
On 2013-06-07 15:36, Mark Brown wrote:
On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote:
From: Graeme Gregory g...@slimlogic.co.uk
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference
Thanks for the quick update.
I've just applied the series in my for_3.11/dts branch.
Regards,
Benoit
On 06/07/2013 03:22 PM, Sricharan R wrote:
uevm is the only official board supported for OMAP5 soc in the mainline.
This series deprecates the support for existent sevm which will no more
be
On Friday 07 June 2013 08:21 PM, Benoit Cousson wrote:
Thanks for the quick update.
I've just applied the series in my for_3.11/dts branch.
Thanks..
Regards,
Sricharan
Regards,
Benoit
On 06/07/2013 03:22 PM, Sricharan R wrote:
uevm is the only official board supported for OMAP5 soc in
* Paul Walmsley p...@pwsan.com [130605 21:06]:
On Wed, 29 May 2013, Santosh Shilimkar wrote:
From: Vaibhav Hiremath hvaib...@ti.com
AM33XX only supports DT boot mode and with addition of
extracting module resources like, irq, dma and address space
from DT block, so now we can remove
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
from OMAP4 SOC hwmod data file.
- The devices which
Nishanth Menon n...@ti.com writes:
On 16:27-20130606, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Add another DTS include file
(twl4030_omap3_mux.dtsi) for boards that hook up the twl4030 this way
to include.
This allows
On Thursday 06 June 2013 06:27 PM, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
On Wed, 29 May 2013, Santosh Shilimkar wrote:
From: Vaibhav Hiremath hvaib...@ti.com
AM33XX only supports DT boot mode and with addition of
extracting module resources like, irq, dma and address
* Tony Lindgren t...@atomide.com [130607 09:35]:
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
* Tomi Valkeinen tomi.valkei...@ti.com [130607 05:53]:
On 07/06/13 15:36, Grygorii Strashko wrote:
Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 13d1eca..66a62e7 100644
---
On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130607 09:35]:
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be
On Friday 07 June 2013 02:10 PM, Paul Walmsley wrote:
On Fri, 7 Jun 2013, Tony Lindgren wrote:
I had to undo the following parts to avoid regressions on omap4sdp.
Can you please follow up on fixing the related issues so the fixup
won't be needed?
Well, I can't even test it at the moment.
On Fri, 7 Jun 2013, Tony Lindgren wrote:
I had to undo the following parts to avoid regressions on omap4sdp.
Can you please follow up on fixing the related issues so the fixup
won't be needed?
Well, I can't even test it at the moment. So it's probably best for
Santosh and Sricharan to fix
HI,
On Fri, Jun 07, 2013 at 03:36:38PM +0300, Grygorii Strashko wrote:
hi Tomi,
On 06/07/2013 02:53 PM, Tomi Valkeinen wrote:
Hi,
I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the
DVI output's EDID reading to work. Testing with i2cget and i2cdump, I
see that I can
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Add another DTS include file
(twl4030_omap3.dtsi) for boards that hook up the twl4030 this way
to include.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on
Tony Lindgren [t...@atomide.com]:
* Tomi Valkeinen tomi.valkei...@ti.com [130607 05:53]:
With that one, I don't get timeouts, but it still doesn't work (i.e.
behavior is the same as on -rc1).
When I run i2cdump the first time, I see that it (probably) manages to
read the first byte,
* Valkeinen, Tomi tomi.valkei...@ti.com [130607 11:37]:
Tony Lindgren [t...@atomide.com]:
* Tomi Valkeinen tomi.valkei...@ti.com [130607 05:53]:
With that one, I don't get timeouts, but it still doesn't work (i.e.
behavior is the same as on -rc1).
When I run i2cdump the first
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]:
On Friday 07 June 2013 02:10 PM, Paul Walmsley wrote:
On Fri, 7 Jun 2013, Tony Lindgren wrote:
I had to undo the following parts to avoid regressions on omap4sdp.
Can you please follow up on fixing the related issues so the
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]:
On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130607 09:35]:
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like
Hi,
On Fri, Jun 07, 2013 at 02:53:54PM +0300, Tomi Valkeinen wrote:
Hi,
I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the
DVI output's EDID reading to work. Testing with i2cget and i2cdump, I
see that I can read individual bytes with i2cget, but using i2cdump
doesn't
On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]:
On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130607 09:35]:
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013,
Hi All,
I observe, that OMAP4 SDP board boot is failed if CONFIG_SENSORS_LM75=y. See
log below.
This issue reproduced with kernel v3.9-rc6, but without hang - just I2C is stuck
in Bus Busy condition. My investigation results are below.
[2.048858] TCP: cubic registered
[2.052398]
Hi All,
I observe, that OMAP4 SDP board boot is failed if CONFIG_SENSORS_LM75=y. See
log below.
This issue reproduced with kernel v3.9-rc6, but without hang - just I2C is stuck
in Bus Busy condition. My investigation results are below.
[2.048858] TCP: cubic registered
[2.052398]
The omap_i2c_isr() does the irq check and schedules threaded handler if any of
enabled IRQs is active, but currently the I2C IRQs are enabled just once,
when I2C IP is enabling (transfer started) and they aren't changed after that.
More over, now the I2C INTC IRQ is disabled when I2C IP is idled.
ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be
processed incorrectly now:
iterration 1:
- I2C irq triggered (ARDY|NACK)
- omap_i2c_isr_thread() will ask NACK, fill dev-cmd_err = OMAP_I2C_STAT_NACK
and trigger cmd_complete completion.
- omap_i2c_xfer_msg() will be
According to I2C specification the NACK should be handled as folowing:
When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then gene rate either a STOP condition to
abort the transfer, or a repeated START condition to start a new
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
WARN_ONCE(true, We should never be here!\n);
return
From: Kevin Hilman khil...@deeprootsystems.com
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device, driver's -runtime_suspend() method
currently disables device
Hi,
On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
Hi,
On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote:
ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be
Have you seen that happen ever ? AL is Arbitration Lost, we never put
OMAP in a multi-master environment before.
ARDY | NACK I also find it a bit
Hi,
On Fri, Jun 07, 2013 at 09:46:07PM +0300, Grygorii Strashko wrote:
According to I2C specification the NACK should be handled as folowing:
When SDA remains HIGH during this ninth clock pulse, this is defined as the
Not
Acknowledge signal. The master can then gene rate either a STOP
Hi,
On Fri, Jun 07, 2013 at 09:46:08PM +0300, Grygorii Strashko wrote:
The omap_i2c_isr() does the irq check and schedules threaded handler if any of
enabled IRQs is active, but currently the I2C IRQs are enabled just once,
when I2C IP is enabling (transfer started) and they aren't changed
On 06/07/2013 06:27 AM, Benoit Cousson wrote:
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
On 11:31-20130607, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Add another DTS include file
(twl4030_omap3.dtsi) for boards that hook up the twl4030 this way
to include.
This allows RTC wake from off-mode to work again
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git
Hello,
Idea is to add the missing bits under arch/arm/*omap* required
to enable by default the ti-soc-thermal driver. I am planing to
move it out of staging tree. This has been scheduled to 3.11.
It would be interesting to get
feedback from other ppl. By enabling it by default we could reach
This change updates the ti-soc-thermal driver to use
standard GPIO DT bindings to read the GPIO number associated
to thermal shutdown IRQ, in case the device features it.
Previously, the code was using a specific DT bindings.
As now OMAP supports the standard way to model GPIOs,
there is no point
Bandgap is a device used to measure temperature on
electronic equipments. It is widely used in digital
integrated circuits. It is based on the dependency
between silicon voltage and temperature.
This patch introduce HAS_BANDGAP config entry.
This config is a boolean value so that arch
code can
Make DRA752 thermal support enabled on omap2plus_defconfig
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: AnilKumar Ch anilku...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tomi Valkeinen
Enable the bandgap driver for TI SoCs thermal support.
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: AnilKumar Ch anilku...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tomi Valkeinen
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
This patch add the bandgap entry for OMAP4430 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Let's replace is_pinconf with flags and add struct pcs_soc so we
can support also other features like pin wake-up events. Let's
export the probe so the SoC specific modules can pass their
SoC specific data to pinctrl-single if needed.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc:
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc:
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware.
Hi all,
Here are few patches to add support for SoC specific features
to pinctrl-single. This is needed at least for omaps to support
IO chain wake-up events from deeper idle states.
With this patch series, device drivers can request named pinctrl
states like active and idle from the PM runtime
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi
Grygorii Strashko grygorii.stras...@ti.com writes:
From: Kevin Hilman khil...@deeprootsystems.com
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device,
* Tony Lindgren t...@atomide.com [130607 13:56]:
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
This patch I should queue separately, the rest should go via
the pinctrl tree.
Regards,
Tony
--
To unsubscribe from this
* Balaji T K balaj...@ti.com [130607 06:42]:
On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote:
* Hebbar Gururaja gururaja.heb...@ti.com [130531 03:19]:
Amend the hsmmc controller to optionally take a pin control handle and
set the state of the pins to:
- default on boot, resume and
That sounds good to me - I can prepare patch for i2c-omap.c.
But, there is still an open question regarding *i2c-gpio.c* which,
actually, a source of biggest part of delay.
Why should the DEPRECATED flag not work with i2c-gpio?
signature.asc
Description: Digital signature
1 - 100 of 122 matches
Mail list logo
