Hi,
On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
Hi,
On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse
Hi,
On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121016 09:53]:
* Kishon Vijay Abraham I kis...@ti.com [121007 23:01]:
ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have
On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121024 17:36]:
* Santosh Shilimkar santosh.shilim...@ti.com [121017 06:35]:
(Looping Arnd and Olof)
On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
When building omap_l3_noc/smx drivers as
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
---
v2 - add the iestate 0 check back.
- Remove a stray change.
- Applies on
Hi,
On Thu, Oct 25, 2012 at 12:06:51PM +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
---
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Oct 25, 2012 at 12:06:51PM +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
On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
On 10/24/2012 12:10 PM, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When a GPIO bank is freed or shutdown, ensure that the banks
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition
Hi,
On Thu, Oct 25, 2012 at 12:23:56PM +0530, Shubhrajyoti Datta wrote:
@@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device
*dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
-
Hi Jon,
many thanks for your time to look at this.
On 25.10.2012 03:28, Jon Hunter wrote:
On 10/22/2012 02:55 PM, Daniel Mack wrote:
diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt
b/Documentation/devicetree/bindings/bus/gpmc.txt
new file mode 100644
index 000..ef1c6e1
---
Hi Nishant,
On Tue, Oct 23, 2012 at 11:43 PM, Nishanth Menon n...@ti.com wrote:
smartreflex.c now resides in drivers/power/avs directory, but class driver
is in mach-omap2. High time we move it off to drivers/power/avs.
Great to see the SR fully moved to drivers/.
After review of the code I am
Nishant,
On Tue, Oct 23, 2012 at 11:43 PM, Nishanth Menon n...@ti.com wrote:
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
Hi Tony,
Thanks for the patch.
On Wednesday 24 October 2012 17:20:56 Tony Lindgren wrote:
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same
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
Hi Dmitry,
On Wednesday 24 October 2012 12:05 PM, Dmitry Torokhov wrote:
Hi Sourav,
On Fri, Oct 05, 2012 at 12:56:26PM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of
On Thu, Oct 25, 2012 at 2:30 PM, Felipe Balbi ba...@ti.com wrote:
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
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
[...]
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+}
+
static int
Hi Jon,
On 25.10.2012 03:53, Jon Hunter wrote:
On 10/22/2012 02:55 PM, Daniel Mack wrote:
+Example for an AM33xx board:
+
+gpmc: gpmc@5000 {
+compatible = ti,gpmc;
+ti,hwmods = gpmc;
+reg = 0x5000 0x100;
Nit-pick, that size is quite
Hi,
On Thu, Oct 25, 2012 at 03:04:29PM +0530, Shubhrajyoti Datta wrote:
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
[...]
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+
Hi,
On Wed, Oct 24, 2012 at 04:41:11PM +0200, Michael Trimarchi wrote:
Hi
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
It's impossible to have Arbitration Lost,
Read Overflow, and Tranmist Underflow all
asserted at the same time.
Those error conditions are mutually exclusive
so
Hi,
On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote:
On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote:
On Mon, 22 Oct 2012, Jean Pihet wrote:
On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com
wrote:
Do you have CPU_IDLE enabled?
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Shubhrajyoti D (2):
i2c: omap: re-factor omap_i2c_init function
Implement reset as a seperate 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: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 28
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
---
drivers/i2c/busses/i2c-omap.c | 71
Hi
On 10/25/2012 12:10 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 24, 2012 at 04:41:11PM +0200, Michael Trimarchi wrote:
Hi
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
It's impossible to have Arbitration Lost,
Read Overflow, and Tranmist Underflow all
asserted at the same time.
Those
Hi,
On Thu, Oct 25, 2012 at 12:33:18PM +0200, Michael Trimarchi wrote:
@@ -587,9 +587,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
goto err_i2c_init;
}
- /* We have an error */
- if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
-
Hi,
(a small top-post here, don't forget to keep the patch version in the
subject, I think this is v3 already, so next patch should be v4)
On Thu, Oct 25, 2012 at 03:53:05PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the
Hi,
On Thu, Oct 25, 2012 at 03:53:06PM +0530, Shubhrajyoti D wrote:
Implement reset as a seperate 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.
since you're
Hi Tony,
On Thu, Oct 04, 2012 at 03:04:52PM -0700, Tony Lindgren wrote:
We can move menelaus.h to live with other mfd headers to
get it out of plat for ARM common zImage support.
Cc: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Samuel Ortiz
On Mon, Oct 22, 2012 at 3:16 PM, Felipe Balbi ba...@ti.com wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17
On Wed, Oct 24, 2012 at 21:11:13, Cousson, Benoit wrote:
Hi Jon,
On 10/19/2012 04:59 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Hi,
On Thu, Oct 25, 2012 at 05:10:10PM +0530, Shubhrajyoti Datta wrote:
On Mon, Oct 22, 2012 at 3:16 PM, Felipe Balbi ba...@ti.com wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Hi Vaibhav,
On 10/25/2012 02:05 PM, Hiremath, Vaibhav wrote:
On Wed, Oct 24, 2012 at 21:11:13, Cousson, Benoit wrote:
Hi Jon,
On 10/19/2012 04:59 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes
On Thu, Oct 25, 2012 at 04:30:37, Hunter, Jon wrote:
On 10/24/2012 01:17 PM, Hiremath, Vaibhav wrote:
On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in
On 10/25/2012 07:12 AM, Hiremath, Vaibhav wrote:
On Thu, Oct 25, 2012 at 04:30:37, Hunter, Jon wrote:
On 10/24/2012 01:17 PM, Hiremath, Vaibhav wrote:
On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not calling complete()
in that situation.
Fix the issue by moving omap_i2c_complete_cmd()
call inside the 'out' label.
Signed-off-by:
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 be a
little more complex then I expected, mainly because of the way
I2C_CNT
PM callbacks pass our device pointer as argument
and we don't need to access the platform_device
just to dereference that down to dev-drvdata.
instead, just use dev_get_drvdata() directly.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 6 ++
1 file changed, 2
this is important in cases where client driver
wants to know how many bytes were actually
transferred.
There is one trick here: if transfer is completed,
meaning I2C_CNT reaches zero, then ARDY will be
asserted to let SW know that it can program a
new transfer.
When ARDY is asserted, I2C_CNT is
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg which gets incremented the amount of bytes
actually transferred.
Signed-off-by:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
byte got NACKed so it doesn't have to resend
all bytes
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't enabled as an
IRQ source.
One such case is after we finish
On 10/25/2012 07:18 AM, Jon Hunter wrote:
...
@@ -113,6 +114,9 @@ static int omap_timer_interrupt_test(struct
omap_dm_timer *gptimer)
irq_data.gptimer = gptimer;
init_completion(irq_data.complete);
+
+ omap_dm_timer_enable(gptimer);
+
Hi,
On Thu, Oct 25, 2012 at 03:25:13PM +0300, Felipe Balbi wrote:
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
byte got NACKed so it doesn't have to resend
all bytes
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
PM callbacks pass our device pointer as argument
and we don't need to access the platform_device
just to dereference that down to dev-drvdata.
instead, just use dev_get_drvdata() directly.
Signed-off-by: Felipe Balbi ba...@ti.com
---
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17 insertions(+), 9
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not calling complete()
in that situation.
Fix the issue by moving
Hi,
On Thu, Oct 25, 2012 at 06:13:16PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not
Hi,
On Thu, Oct 25, 2012 at 06:12:00PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Hi Omar,
Thanks for reply.
---
U : What kernel is this? If non-mainline, I might try it out of
curiosity.
ME :
* code sourcery arm-2012.03-57-lite
* beaglboard xM rev C
*
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't
On 10:27-20121025, Jean Pihet wrote:
On Tue, Oct 23, 2012 at 11:43 PM, Nishanth Menon n...@ti.com wrote:
[..]
static int sr_class3_disable(struct omap_sr *sr, int is_volt_reset)
{
+ if (!sr-soc_ops.vp_enable) {
This should be ' if (!sr-soc_ops.vp_disbable) {'.
Argh.. yes. thanks
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg
Hi,
On Thu, Oct 25, 2012 at 06:23:57PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
On Thursday 25 October 2012 06:22 PM, Felipe Balbi wrote:
Hi,
On Thu, Oct 25, 2012 at 06:23:57PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
On 10/25/2012 02:00 AM, Santosh Shilimkar wrote:
On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
On 10/24/2012 12:10 PM, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When a GPIO bank is freed or shutdown, ensure that the banks
dbck_enable_mask is cleared also. Otherwise,
Hi,
Santosh Shilimkar writes:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually
On 10/25/2012 03:00 AM, Daniel Mack wrote:
Hi Jon,
many thanks for your time to look at this.
On 25.10.2012 03:28, Jon Hunter wrote:
On 10/22/2012 02:55 PM, Daniel Mack wrote:
diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt
b/Documentation/devicetree/bindings/bus/gpmc.txt
On Thursday 25 October 2012 06:41 PM, Jon Hunter wrote:
On 10/25/2012 02:00 AM, Santosh Shilimkar wrote:
On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
On 10/24/2012 12:10 PM, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When a GPIO bank is freed or shutdown, ensure that
On 10/25/2012 04:43 AM, Daniel Mack wrote:
Hi Jon,
On 25.10.2012 03:53, Jon Hunter wrote:
On 10/22/2012 02:55 PM, Daniel Mack wrote:
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000
Hi Kishon,
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the index of get_irq since irq of core is removed from hwmod
entry.
Also
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From:
On Thursday 25 October 2012 04:25 PM, Felipe Balbi wrote:
overflow, underflow
these are data errors personally feel may be removed.
and arbitration lost)
will investigate.
and try to make sure if
actually need to reset the controller all the time. I find it really odd
that we're always
On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
You also miss one very very very big point. This will break every I2C
using userspace
On 2012-03-09 10:03, Hiremath, Vaibhav wrote:
On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote:
Hi Archit,
On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info() when the physical address for the
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled by of_*, removed the call to dwc3_get_device_id.
Just for my understanding: How are these
Matt Porter mpor...@ti.com writes:
On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
[...]
Ok, very quick update...no need to mess around with the eeprom. I just
received the official word on what will be supported. Since A2 is
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
You also miss one very very
HI,
On Thu, Oct 25, 2012 at 06:31:58PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is
On Thu, Oct 25, 2012 at 04:04:44PM +0200, Benoit Cousson wrote:
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled by of_*, removed the call to
On Wednesday 24 October 2012, Tony Lindgren wrote:
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
On 10/23/2012 11:29 PM, Tomi Valkeinen wrote:
On 2012-10-23 20:21, Ricardo Neri wrote:
If so, you could pass only that one address, instead of the whole HDMI
register space?
Yes, that could work. I thought about that but the common HDMI driver
would have to know the the IP-specific
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Todo: all the error cases may not need a reset.
Shubhrajyoti D (2):
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: Shubhrajyoti D shubhrajy...@ti.com
---
some of the errors may not need a reset.
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
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74
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: Shubhrajyoti D shubhrajy...@ti.com
---
some of the errors may not need a reset.
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Todo: all the error cases may not need a reset.
Shubhrajyoti D (2):
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
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74
Hi Benoit,
On Thursday 25 October 2012 07:11 PM, Benoit Cousson wrote:
Hi Kishon,
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the
On 2012-10-25 17:31, Ricardo Neri wrote:
On 10/23/2012 11:29 PM, Tomi Valkeinen wrote:
On 2012-10-23 20:21, Ricardo Neri wrote:
If so, you could pass only that one address, instead of the whole HDMI
register space?
Yes, that could work. I thought about that but the common HDMI driver
Use devm_request_mem_region() to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/omap_wdt.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index
Convert omap_wdt to new watchdog core. On OMAP boards, there are usually
multiple watchdogs. Since the new watchdog core supports multiple
watchdogs, all watchdog drivers used on OMAP should be converted.
The legacy watchdog device node is still created, so this should not
break existing users.
It's not needed to manually reset the driver data.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/omap_wdt.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 7e8d3e0..af1e72e 100644
Hello,
This is a third version of the patch to convert omap_wdt to new watchdog
core. On OMAP boards, there are usually multiple watchdogs. Since the new
watchdog core supports multiple watchdogs, all watchdog drivers used on
OMAP should be converted. This is especially important on devices like
Eliminate a goto to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/omap_wdt.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index af1e72e..bee43a9 100644
---
Use devm_ioremap() to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/omap_wdt.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 45019b0..7e8d3e0
Use devm_kzalloc() to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/omap_wdt.c | 23 ++-
1 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index
On Thu, Oct 25, 2012 at 17:48:47, Hunter, Jon wrote:
On 10/25/2012 07:12 AM, Hiremath, Vaibhav wrote:
On Thu, Oct 25, 2012 at 04:30:37, Hunter, Jon wrote:
On 10/24/2012 01:17 PM, Hiremath, Vaibhav wrote:
On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
Add the 12 GP timers nodes
Hi,
On Mon, Oct 15, 2012 at 07:32:33PM -0600, Paul Walmsley wrote:
The OMAP watchdog timer driver directly calls a function exported by
code in arch/arm/mach-omap2. This is not good; it tightly couples
this driver to the mach-omap2 integration code. Instead, add a
temporary platform_data
On Thu, Oct 25, 2012 at 18:03:37, Hunter, Jon wrote:
On 10/25/2012 07:18 AM, Jon Hunter wrote:
...
@@ -113,6 +114,9 @@ static int omap_timer_interrupt_test(struct
omap_dm_timer *gptimer)
irq_data.gptimer = gptimer;
init_completion(irq_data.complete);
+
+
MMC debounce clock is applicable only for omap2430, warning message gets
printed when enable fails for debounce clock. Remove the get debounce clock
failure message as it is noisy for other platforms.
Signed-off-by: Balaji T K balaj...@ti.com
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
On Thursday 25 October 2012 06:39 AM, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121023 03:12]:
On Fri, Oct 12, 2012 at 04:54:34PM +0100, Russell King - ARM Linux wrote:
omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
omap_hsmmc omap_hsmmc.0: Failed to get
* Balaji T K balaj...@ti.com [121025 09:00]:
MMC debounce clock is applicable only for omap2430, warning message gets
printed when enable fails for debounce clock. Remove the get debounce clock
failure message as it is noisy for other platforms.
Signed-off-by: Balaji T K balaj...@ti.com
Jon Hunter jon-hun...@ti.com writes:
On 10/24/2012 12:10 PM, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When a GPIO bank is freed or shutdown, ensure that the banks
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition will restore
Jon Hunter jon-hun...@ti.com writes:
On 10/25/2012 02:00 AM, Santosh Shilimkar wrote:
On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
On 10/24/2012 12:10 PM, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When a GPIO bank is freed or shutdown, ensure that the banks
From: Kevin Hilman khil...@ti.com
When a GPIO is freed or shutdown, ensure that the proper bit in
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition will restore previous debounce values
from the shadow copies (bank-context.debounce*) leading to
1 - 100 of 173 matches
Mail list logo
