Hi Jon,
On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote:
I do not think it is practically possible. Please see timing calculations
in arch/arm/mach-omap2/gpmc-*, the way it is done for different
peripherals are different, and we cannot expect gpmc driver to do those as
that would
Hi Jon,
On Thu, Jun 14, 2012 at 11:47:03, Mohammed, Afzal wrote:
gpmc_cs_set_timings() does currently convert time to clock cycles required,
and this gpmc driver have the capability to do it.
What I was saying is a different issue, input to gpmc_cs_set_timings, which
is time sometimes in
On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote:
于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of
* Mohammed, Afzal af...@ti.com [120613 06:50]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:48:15, Mohammed, Afzal wrote:
On Wed, Jun 13, 2012 at 17:34:58, Tony Lindgren wrote:
There should no longer be any need to initialize GPMC early. It should
behave like any other device driver, and
* Mohammed, Afzal af...@ti.com [120613 06:56]:
Hi Tony,
On Wed, Jun 13, 2012 at 19:20:35, Mohammed, Afzal wrote:
Hi Tony,
On Wed, Jun 13, 2012 at 19:14:08, Tony Lindgren wrote:
Actually why do you even need to store the revision? You can
just read it from the hardware as
Hi Tony,
On Thu, Jun 14, 2012 at 12:05:25, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120613 06:56]:
Or you meant, even there read revision register ?
Yeah that should be fine as this really should only happen
during init and whatever revision specific features can
be
On 06/14/12 07:46, Zumeng Chen wrote:
于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to
On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
于 2012年06月14日 14:31, Hiremath, Vaibhav 写道:
On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote:
于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then
Hi Jon,
On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote:
If the clk handle for the gpmc is passed to the gpmc driver, then there
is no reason why the driver cannot do this.
I believe passing clk details through platform data is an abuse of
clock framework.
Regards
Afzal
--
To
Hi Jon,
On Wed, Jun 13, 2012 at 20:38:09, Hunter, Jon wrote:
On 06/13/2012 08:05 AM, Mohammed, Afzal wrote:
Do you mean that gpmc driver should have the capability to calculate
peripheral
timings at runtime based on frequency ?, I am not sure how this can be
handled
by gpmc driver
On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom
Hi Richard, all,
On Tue, Jun 12, 2012 at 6:34 PM, Woodruff, Richard r-woodru...@ti.com wrote:
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, May 25, 2012 2:53 AM
Thanks for quick input. Apologies on slow ack of it.
Before we had these frameworks in place it was
On 06/14/12 10:08, Zumeng Chen wrote:
于 2012年06月14日 14:44, Igor Grinberg 写道:
On 06/14/12 07:46, Zumeng Chen wrote:
于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
If we don't set proper debouce
On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Commit
In case a board provides the gpio_pendown and not board_pdata,
the GPIO debounce is not taken care of.
Fix this by taking care of GPIO debounce in any case.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/common-board-devices.c | 22 --
1 files
On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
On Wed, Jun 13, 2012 at 2:20
于 2012年06月14日 16:06, Igor Grinberg 写道:
On 06/14/12 10:08, Zumeng Chen wrote:
于 2012年06月14日 14:44, Igor Grinberg 写道:
On 06/14/12 07:46, Zumeng Chen wrote:
于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng
On Thu, 2012-06-14 at 01:17 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Okay. These are a bit problematic, because we're in the process of
removing these kinds of things from the board file, as they cannot be
supported with device
* Mohammed, Afzal af...@ti.com [120613 23:44]:
Hi Tony,
On Thu, Jun 14, 2012 at 12:05:25, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120613 06:56]:
Or you meant, even there read revision register ?
Yeah that should be fine as this really should only happen
during init
Hi Jon,
On Wed, Jun 13, 2012 at 21:01:08, Hunter, Jon wrote:
On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
+static __devinit int gpmc_setup_cs(struct gpmc_peripheral *g_per,
+ struct gpmc_cs_data *cs, struct resource *res) {
+ int num, ret;
+
+ num =
Hi Tony,
On Thu, Jun 14, 2012 at 14:09:58, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120613 23:44]:
Sorry, I got confused, we need revision to be available while setting
time also, so you meant to store it as a variable or read revision
at probe as well as during setting time ?
Hi Jon,
On Wed, Jun 13, 2012 at 21:03:44, Hunter, Jon wrote:
On 06/13/2012 12:29 AM, Mohammed, Afzal wrote:
Irq memory resource creation functions returns number of resources,
if memory function only is modified, that will cause loss of uniformity
w.r.t irq function, even though both
Hi Jon,
On Wed, Jun 13, 2012 at 21:09:52, Hunter, Jon wrote:
Sure, but reviewing the function it still looks odd from a readability
standpoint. At least it made me think what is going on here So a
comment is definitely needed.
2. A bad setting in the configuration passed.
Hi Jon,
On Wed, Jun 13, 2012 at 21:14:30, Hunter, Jon wrote:
On 06/13/2012 02:37 AM, Mohammed, Afzal wrote:
In that case we would be directly depending on user flag whose value may
or may not change and I don't think it is good to directly depend on it
for waitpin # calculation.
You
Hi Tony,
On Wed, Jun 13, 2012 at 21:58:53, Hunter, Jon wrote:
Presently there are no peripherals in mainline turning on writeprotect,
initially intention was to just disable writeprotect at the end of probe
and not provide platforms opportunity to enable writeprotect as none
need it,
* Afzal Mohammed af...@ti.com [120611 08:20]:
+__init gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+ int ret;
+ struct gpmc_device_pdata *gpmc_pdev;
+ struct gpmc_cs_data *gpmc_cs;
+
+ gpmc_pdev = kzalloc(sizeof(*gpmc_pdev), GFP_KERNEL);
+ if
Hi Tony,
On Thu, Jun 14, 2012 at 14:26:52, Tony Lindgren wrote:
* Afzal Mohammed af...@ti.com [120611 08:20]:
+__init gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+ int ret;
+ struct gpmc_device_pdata *gpmc_pdev;
+ struct gpmc_cs_data *gpmc_cs;
+
+
On Wed, 2012-06-13 at 17:21 +0200, Jean Pihet wrote:
Hi Tero,
I have a few remarks regarding the genericity of this code. I think it
is better if the code in powerdomain.c stays generic and that the
platform specific checks and operations be moved in the specific
functions (via the
* Mohammed, Afzal af...@ti.com [120614 01:59]:
Hi Tony,
On Wed, Jun 13, 2012 at 21:58:53, Hunter, Jon wrote:
Presently there are no peripherals in mainline turning on writeprotect,
initially intention was to just disable writeprotect at the end of probe
and not provide platforms
Hi Tony,
On Thu, Jun 14, 2012 at 14:59:57, Tony Lindgren wrote:
* Afzal Mohammed af...@ti.com [120611 07:21]:
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19,
Hi
(revised patch below)
On Sun, 10 Jun 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120610 17:56]:
--- /dev/null
+++ b/include/linux/platform_data/aess.h
This should be include/linux/platform_data/omap-aess.h or similar as
there are other aess controllers too.
Hmm, I
* Paul Walmsley p...@pwsan.com [120614 02:53]:
Hi
(revised patch below)
On Sun, 10 Jun 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120610 17:56]:
--- /dev/null
+++ b/include/linux/platform_data/aess.h
This should be include/linux/platform_data/omap-aess.h or
Paul,
On 04/30/2012 08:11 PM, Paul Walmsley wrote:
Hi Kevin,
On Fri, 27 Apr 2012, Kevin Hilman wrote:
This series attempts to remove all the runtime cpu_is* checking in
omap_hwmod.c in favor of using function pointers initialized at init
time.
This series was motivated by the addition of
Hi Tony,
On Wed, Jun 13, 2012 at 17:28:33, Mohammed, Afzal wrote:
On Wed, Jun 13, 2012 at 17:24:45, Tony Lindgren wrote:
If there's a chance it causing file system corruption, we should
test it carefully on the boards before applying. If that's done,
then there's probably no need for
* Mohammed, Afzal af...@ti.com [120614 03:15]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:28:33, Mohammed, Afzal wrote:
On Wed, Jun 13, 2012 at 17:24:45, Tony Lindgren wrote:
If there's a chance it causing file system corruption, we should
test it carefully on the boards before applying.
Hi,
On Thu, Jun 14, 2012 at 15:06:25, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120614 01:59]:
On Wed, Jun 13, 2012 at 21:58:53, Hunter, Jon wrote:
devices should indicate if they use the write-protect pin and we should
either have this enable on boot as a global setting not
Hi guys,
I have dropped a few patches from the series and also
tested every single patch on my pandaboard. I2C messages
are still working fine with panda after each patch.
There's still lots of work to be done on the i2c-omap.c
driver but it's now easier to read, IMO.
Felipe Balbi (17):
i2c:
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 43 +++--
1 file changed, 11 insertions(+), 32 deletions(-)
diff --git
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 208 +
1 file changed, 84 insertions(+), 124
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
omap_i2c_dev is allocated with kzalloc(),
so we need not initialize b_hw to zero.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now uneeded
check for dev-buf_len as we
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 47 +
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 39d5583..07ae391 100644
---
trivial patch, no functional changes
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..9b532cd 100644
---
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 file changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
Tony,
Here is the EMIF driver DT support which was kept on hold for the driver
to get merged. The series has been already reviewed on the list.
This series adds device tree support for TI EMIF SDRAM controller
driver. For this, a binding has been added for representing AC timing
parameters and
From: Aneesh V ane...@ti.com
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Reviewed-by: Benoit Cousson
From: Aneesh V ane...@ti.com
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by:
From: Aneesh V ane...@ti.com
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Reviewed-by: Benoit
From: Aneesh V ane...@ti.com
Device tree support for the EMIF driver.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
trivial patch, no functional changes
Signed-off-by: Felipe Balbi ba...@ti.com
---
Looks good.
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
Hi Tony,
On Thu, Jun 14, 2012 at 15:49:02, Tony Lindgren wrote:
Well I took a look at the values, and it seems the only difference is the
static GPMC_CONFIG1_CLKACTIVATIONTIME(1) that your patch now overwrites 0.
It seems change below should be part of $subject.
Please let me know your
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63
-
1 file changed, 31 insertions(+), 32 deletions(-)
diff
On Thu, Jun 14, 2012 at 04:11:14PM +0530, Shilimkar, Santosh wrote:
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Not sure if it is needed but may be spliting the series into clean
up and functional update like logic changes etc may be
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Indeed. Looks good to me.
Reviewed-by : Santosh Shilimkar
On Fri, Apr 20, 2012 at 6:09 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
The devm API usage in probe() simplifies error handling operation.
Since iclk is not used in the driver it is removed from wherever
not needed.
Corrected the timer fck name mis-match between clock44xx_data.c and
Tony,
On Thu, Jun 14, 2012 at 4:24 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Fri, Apr 20, 2012 at 6:09 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
The devm API usage in probe() simplifies error handling operation.
Since iclk is not used in the driver it is removed from
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 47
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Executing at least once instead of never is
still a functional change :-)
Regards
Santosh
--
To
On Thu, Jun 14, 2012 at 04:33:39PM +0530, Shilimkar, Santosh wrote:
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Executing at least once
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 file changed, 17
On Thu, Jun 14, 2012 at 01:20:37PM +0300, Felipe Balbi wrote:
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
This doesn't feel right, and the explanation is definitely wrong.
stat BIT(1) is not the same as BIT(1)
On Thu, Jun 14, 2012 at 01:20:39PM +0300, Felipe Balbi wrote:
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_1p153(struct omap_i2c_dev *dev)
{
- unsigned long timeout = 1;
+ unsigned long timeout = 1;
+ u16
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Jun 14, 2012 at 01:20:42PM +0300, Felipe Balbi wrote:
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
You don't explain that you're adding a new dev_err() statement into the
driver for a missing acknowledge.
What if you're probing for a device - can this
* Mohammed, Afzal af...@ti.com [120614 02:46]:
Hi Tony,
On Thu, Jun 14, 2012 at 14:59:57, Tony Lindgren wrote:
* Afzal Mohammed af...@ti.com [120611 07:21]:
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+
On Thu, Jun 14, 2012 at 04:48:56PM +0530, Shilimkar, Santosh wrote:
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
Hi guys,
I have dropped a few patches from the series and also
tested every single patch on my pandaboard. I2C messages
are still working fine with panda after each patch.
There's still lots of work to be done on the
On Thu, Jun 14, 2012 at 4:53 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jun 14, 2012 at 04:48:56PM +0530, Shilimkar, Santosh wrote:
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
otherwise we could get our IRQ line disabled due
to many spurious
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was
On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
On Wed, Jun 13, 2012 at 2:20
Hi,
On Thu, Jun 14, 2012 at 12:13:33PM +0100, Russell King - ARM Linux wrote:
On Thu, Jun 14, 2012 at 01:20:37PM +0300, Felipe Balbi wrote:
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
This doesn't feel right,
On Wednesday 13 June 2012, Jon Hunter wrote:
As I said previously, I think just encoding the direction but not
the client specific ID (meaning we would have to disambiguate
the more complex cases that Stephen mentioned using a dma-names
property) would be the best because it keeps the
On Thu, Jun 14, 2012 at 04:41:45PM +0530, Shilimkar, Santosh wrote:
On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi ba...@ti.com
---
* Mohammed, Afzal af...@ti.com [120614 03:43]:
Hi Tony,
On Thu, Jun 14, 2012 at 15:49:02, Tony Lindgren wrote:
Well I took a look at the values, and it seems the only difference is the
static GPMC_CONFIG1_CLKACTIVATIONTIME(1) that your patch now overwrites 0.
It seems change below
On Thu, Jun 14, 2012 at 12:20:17PM +0100, Russell King - ARM Linux wrote:
On Thu, Jun 14, 2012 at 01:20:42PM +0300, Felipe Balbi wrote:
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
You don't explain that you're adding a new dev_err() statement into the
Hi,
On Thu, Jun 14, 2012 at 12:17:46PM +0100, Russell King - ARM Linux wrote:
On Thu, Jun 14, 2012 at 01:20:39PM +0300, Felipe Balbi wrote:
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int
*err)
+static int errata_omap3_1p153(struct omap_i2c_dev *dev)
{
-
* Mohammed, Afzal af...@ti.com [120614 03:43]:
Hi Tony,
On Thu, Jun 14, 2012 at 15:49:02, Tony Lindgren wrote:
Well I took a look at the values, and it seems the only difference is the
static GPMC_CONFIG1_CLKACTIVATIONTIME(1) that your patch now overwrites 0.
It seems change below
On Thu, Jun 07, 2012 at 12:08:35PM +0100, Russell King wrote:
Add DMA engine support to the OMAP SPI driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be independently switched at build time between using DMA
engine and the private
Hi Tony,
On Thu, Jun 14, 2012 at 17:22:08, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120614 03:43]:
+ t.clk_activation = fclk_offset_ns;
+
This too should be fclk_offset, not fclk_offset_ns.
As gpmc_cs_set_timing convert it to ticks from ns,
shouldn't we put it in ns ?
Hi Paul,
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
Hi Tony,
On Thu, Jun 14, 2012 at 17:19:06, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120614 03:43]:
It seems change below should be part of $subject.
For onenand I'm getting the following error:
omap2-onenand omap2-onenand: Cannot request GPMC CS
Without this change (not
On Thu, Jun 14, 2012 at 12:53:35PM +0100, Russell King - ARM Linux wrote:
On Thu, Jun 07, 2012 at 12:08:35PM +0100, Russell King wrote:
Add DMA engine support to the OMAP SPI driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be
Hi Tony,
On Thu, Jun 14, 2012 at 17:19:06, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120614 03:43]:
For onenand I'm getting the following error:
omap2-onenand omap2-onenand: Cannot request GPMC CS
I am a bit confused with this message, for onenand, we only have,
pr_err(%s:
On Thu, 2012-06-14 at 04:40 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2012-06-13 at 23:58
Hi Tony,
On Thu, Jun 14, 2012 at 17:39:41, Mohammed, Afzal wrote:
On Thu, Jun 14, 2012 at 17:19:06, Tony Lindgren wrote:
For onenand I'm getting the following error:
omap2-onenand omap2-onenand: Cannot request GPMC CS
I am a bit confused with this message, for onenand, we only have,
Hello,
To keep the McBSP fck alias handling in sync among OMAP versions.
Change the legacy implementation for OMAP2/3 regarding to McBSP fck alias.
OMAP4 (and OMAP5) uses the hwmod data to specify the aliases for the fcks and
it is also needed for the coming McBSP DT support.
Tested on OMAP3
Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |4
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 +
2 files
1 - 100 of 211 matches
Mail list logo
