On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter jon-hun...@ti.com wrote:
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
can create a PMU device based upon the DEBUGSS HWMOD and use the CTI
Hi Jon,
On Wed, Jun 13, 2012 at 00:12:27, Hunter, Jon wrote:
I am still wondering if we should warn against multiple devices using
the wait pin. I see that if could be valid to have multiple memory
devices of the same type using the WP pin spanning multiple CS. However,
in that case
On Tue, Jun 12, 2012 at 11:07 PM, Pandita, Vikram vikram.pand...@ti.com wrote:
On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter jon-hun...@ti.com wrote:
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is
Hi Jon,
On Wed, Jun 13, 2012 at 00:25:23, Hunter, Jon wrote:
When are the timings calculated? Why not just use the existing
gpmc_cs_set_timings()?
I guess I am not convinced that we need to have multiple formats to pass
timings such as clock, period, etc.
I think that it is sufficient
On Wed, Jun 13, 2012 at 11:43 AM, Pandita, Vikram vikram.pand...@ti.com wrote:
On Tue, Jun 12, 2012 at 11:07 PM, Pandita, Vikram vikram.pand...@ti.com
wrote:
On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter jon-hun...@ti.com wrote:
In order to use the CTI interrupts inconjunction with the DEBUGSS
Hi Jon,
On Wed, Jun 13, 2012 at 00:28:15, Hunter, Jon wrote:
On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
+enum {
+ has_none,
+ has_period,
+ has_clock
+};
+
+struct gpmc_time_ctrl {
+ int type;
+ struct gpmc_timings timings;
+ struct gpmc_misc_timings
Hi Jon,
On Wed, Jun 13, 2012 at 00:49:22, Hunter, Jon wrote:
On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
clk_enable(gpmc_l3_clk);
We should be able to get rid of the clk_enable() here and use ...
pm_runtime_enable(pdev-dev);
pm_runtime_get(pdev-dev);
The
Hi Jon,
On Tue, Jun 12, 2012 at 23:45:36, Hunter, Jon wrote:
GPMC_WAITPIN_IDX0 = 0
GPMC_WAITPIN_0 = 1
So, GPMC_WAITPIN_IDX0 = GPMC_WAITPIN_0 - 1, assuming that you want idx =
0 and not 1. Or you could change you shift value too. I was just
highlighting that they are not equal but one set
Hi Jon,
On Wed, Jun 13, 2012 at 00:07:46, Hunter, Jon wrote:
+ case GPMC_WAITPIN_3:
+ idx = GPMC_WAITPIN_IDX3;
+ break;
+ /* no waitpin */
+ case 0:
+ return 0;
+ break;
Do you need the break and return?
Not necessary, but to keep
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chen zumeng.c...@windriver.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c | 39
++
1 files changed, 39
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chen zumeng.c...@windriver.com
EHCI PHY requires these regulators:
EVM Rev =E -- VAUX2
EVM Rev E -- VUSB1V5, VUSB1V8
Adding USB internal LDOs (vusb1v5 vusb1v8) and VAUX2 to omap3evm
board file. Also removing
于 2012年06月13日 15:57, Igor Grinberg 写道:
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
Signed-off-by: Vaibhav Hiremathhvaib...@ti.com
Tested-by: Zumeng Chenzumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c | 39
于 2012年06月13日 16:16, Igor Grinberg 写道:
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
EHCI PHY requires these regulators:
EVM Rev=E -- VAUX2
EVM Rev E -- VUSB1V5, VUSB1V8
Adding USB internal LDOs (vusb1v5 vusb1v8) and VAUX2 to omap3evm
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chen zumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series
于 2012年06月13日 15:51, Igor Grinberg 写道:
On 06/13/12 04:44, 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 one time
touch on screen, so the driver couldn't work
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
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
the Beagle board
Linus,
Can you please apply the patch below. I've been waiting 10 days so far
for a fix for the build problem to get through the normal channels,
and it seems to be stuck with the FBdev maintainer, who missed -rc2
with his pull request - and still hasn't submitted it.
Tomi Valkeinen has a
On 06/13/12 12:03, Zumeng Chen wrote:
于 2012年06月13日 15:51, Igor Grinberg 写道:
On 06/13/12 04:44, 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 one time
touch on
Hi all,
Here are two regression fixes for the MUSB ifdef removal.
Note that this series does not fix things for blackfin
or davinci, similar fixes should be done for those.
Regards,
Tony
---
Tony Lindgren (2):
ARM: OMAP2+: Fix MUSB ifdefs for platform init code
ARM: OMAP2: Fix
Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry)
got rid of a bunch of ifdefs in the MUSB code. Looks like the
platform init code is still using these dropped defines though,
which in many cases results the board defaulting always to host
mode.
Currently the situation is that
Here's one more gpio_to_irq conversion that we missed
earlier. Tested with n800 in gadget mode using USB_ETH.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-tusb6010.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, 2012-06-13 at 10:57 +0100, Russell King - ARM Linux wrote:
Linus,
Can you please apply the patch below. I've been waiting 10 days so far
for a fix for the build problem to get through the normal channels,
and it seems to be stuck with the FBdev maintainer, who missed -rc2
with his
Hi Tony,
On Wed, Jun 13, 2012 at 16:39:08, Tony Lindgren wrote:
Sorry for the delay, had to do some fixes to get my GPMC testcase
working..
No problem
Looks good to me, made one comment to mtd: nand: omap2: handle nand on gpmc
patch. Maybe after that is fixed Artem can take a look and
* Mohammed, Afzal af...@ti.com [120612 22:00]:
Hi Jon,
On Tue, Jun 12, 2012 at 23:06:53, Hunter, Jon wrote:
Should you at least warn, if you are going to over-write a value?
Yes, that would be better except for too much logging, if Tony
prefers that way I will add.
If there's a
* Mohammed, Afzal af...@ti.com [120612 03:32]:
Hi Tony,
On Mon, Jun 11, 2012 at 19:31:01, Mohammed, Afzal wrote:
Objective of this series is to make things easy for GPMC driver
conversion series by separating out more things from driver
conversion series.
This series,
1. Unifies
Hi,
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of arch/arm/*omap*/
This series,
1. provides the ability for OMAP NAND driver to configure GPMC-NAND
registers by NAND
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |
GPMC platform initialization has been modified to fill NAND
platform data with GPMC NAND register details. As these
registers are accessible in NAND driver itself, configure
NAND in GPMC by itself.
Modified prefetch and ecc functions are logically same as
the corresponding exported symbols from
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in
gpmc initialization done by platform code now updates struct resource
with the address space alloted for nand. Use this interface to obtain
memory rather than relying on platform data field - phys_base.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |1
gpmc initialization for onenand done by platform code now provides
onenand address space as memory resource. Hence remove usage of
gpmc_cs_request in onenand driver and obtain memory details from
resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/onenand/omap2.c |
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related interrupts has been considered (which is the case
even without this
Now GPMC provides its client with interrupts that can be handled
using the standard interrupt API. Modify GPMC NAND setup to work
with it.
Also disable write protect in GPMC code, so that NAND driver can
be ignorant of GPMC configuration.
Signed-off-by: Afzal Mohammed af...@ti.com
---
GPMC platform initialization provides it's clients
with interrupts that can be used through struct
resource. Make use of it for irq mode functionality.
Also now write protect disable is done by GPMC,
hence remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 70
On Wed, 2012-06-13 at 17:03 +0530, Afzal Mohammed wrote:
+/* XXX: Only NAND irq has been considered,currently these are the only ones
used
+ */
+#define GPMC_NR_IRQ 2
I guess XXX means Warning? Why not to use plain English? :-)
--
Best Regards,
Artem Bityutskiy
Hi Tony,
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 warnings. It's safer to disable
NAND for untested boards if
* Mohammed, Afzal af...@ti.com [120612 22:24]:
Hi Jon,
On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
On 06/12/2012 01:53 AM, Mohammed, Afzal wrote:
On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote:
My preference would be to store gpmc_l3_clk in the pdata and pass to
* Jon Hunter jon-hun...@ti.com [120611 13:34]:
Hi Afzal,
On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
A driver is being created out of GPMC code. This is being
attempted to acheive by not breaking existing interface,
necessitating requirement of GPMC peripherals being able
to work
* Jon Hunter jon-hun...@ti.com [120612 11:01]:
On 06/12/2012 02:16 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, Jun 12, 2012 at 02:13:22, Hunter, Jon wrote:
+ gpmc_revision = (l 4) 0xf;
Why are you only storing the major part of the rev? Why not keep both
parts?
Does
Hi Tony,
On Wed, Jun 13, 2012 at 17:34:58, Tony Lindgren wrote:
I am not sure if I am missing something, but it appears that pdev will
always be NULL here as it is a local uninitialised variable.
This also creates a new warning:
arch/arm/mach-omap2/gpmc.c: In function
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng Chen zumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most
* Afzal Mohammed af...@ti.com [120611 08:19]:
@@ -106,7 +123,14 @@ static int tusb_set_async_mode(unsigned sysclk_ps,
unsigned fclk_ps)
tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
- return
* Afzal Mohammed af...@ti.com [120611 08:19]:
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -114,7 +136,13 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
return 0;
- return
* Mohammed, Afzal af...@ti.com [120612 03:44]:
Hi Tony,
On Mon, Jun 11, 2012 at 19:55:02, Mohammed, Afzal wrote:
Hi,
This series is based on 3.5-rc1, and is dependent on [1,2,3]
This series has been tested on omap3evm (smsc911x) rev G C and
beagle board(nand) using patch series
Hi Tony,
On Wed, Jun 13, 2012 at 17:02:17, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120612 22:00]:
Yes, that would be better except for too much logging, if Tony
prefers that way I will add.
If there's a chance it causing file system corruption, we should
test it carefully
Hi Tony,
On Wed, Jun 13, 2012 at 17:03:59, Tony Lindgren wrote:
NAND for untested boards if timings change. Are Jon's comments all handled?
I have explained the justification, why those changes were done so,
waiting for his comments.
Regards
Afzal
--
To unsubscribe from this list: send the
* Mohammed, Afzal af...@ti.com [120613 05:43]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:02:17, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120612 22:00]:
Yes, that would be better except for too much logging, if Tony
prefers that way I will add.
If there's a chance it causing
* Zumeng Chen zumeng.c...@gmail.com [120612 09:41]:
2012/6/12 Tony Lindgren t...@atomide.com
* Zumeng Chen zumeng.c...@gmail.com [120611 07:05]:
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on
Hi Tony,
On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120612 22:24]:
Hi Jon,
On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
Right but potentially, this could be done by the driver.
I do not think it is practically possible. Please
Hi Tony,
On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120612 11:01]:
On 06/12/2012 02:16 AM, Mohammed, Afzal wrote:
Does having minor revision add any value ?, at least as of now,
I do not see any.
May be not but it does not hurt either.
Hi Tony,
On Wed, Jun 13, 2012 at 17:57:48, Tony Lindgren wrote:
We can drop the old interface for non-mainline cases. In this case
tusb6010 is only used by board-n8x0.c, so it's best to just convert
it all to use the new interface.
Right, I will do accordingly
Regards
Afzal
--
To
Setup pinmux for CPI and register the mt9t001 camera sensor
in ISP subsystem.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 69
1 files changed, 69
Register the tvp5150 video decoder in ISP subsystem.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
This patch set adds mt9t001 camera sensor and tvp5150 video decoder
registration to
cm-t35/cm-t3730 board support file. Base board (SB-T35) CIP of cm-t3x module
can be
connected to external video input adapter like Compulab VIP-ADP board.
VIP-ADP has a digital camera sensor connection port
Hi Tony,
On Wed, Jun 13, 2012 at 17:59:50, Tony Lindgren wrote:
Here too we just need to care about the mainline kernel users
and convert them to use the new interface. No need to keep
gpmc_cs_set_timings around. The same applies for other similar
patches.
Not sure whether I follow you
* Mohammed, Afzal af...@ti.com [120613 06:10]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120612 22:24]:
Hi Jon,
On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
Right but potentially, this could be done by the driver.
* Mohammed, Afzal af...@ti.com [120613 06:16]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120612 11:01]:
On 06/12/2012 02:16 AM, Mohammed, Afzal wrote:
Does having minor revision add any value ?, at least as of now,
I do
* Mohammed, Afzal af...@ti.com [120613 06:43]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:59:50, Tony Lindgren wrote:
Here too we just need to care about the mainline kernel users
and convert them to use the new interface. No need to keep
gpmc_cs_set_timings around. The same applies for other
* Tony Lindgren t...@atomide.com [120613 06:45]:
* Mohammed, Afzal af...@ti.com [120613 06:16]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120612 11:01]:
On 06/12/2012 02:16 AM, Mohammed, Afzal wrote:
Does having
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 also work as a loadable module.
Once driver migration
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 needed.
Earlier for wr_access wr_data_mux_bus, we were checking,
cpu_is_34xx, but I feel it should instead be based on
IP revision as
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 needed.
Earlier for wr_access wr_data_mux_bus, we were
Hi Tony,
On Wed, Jun 13, 2012 at 19:09:38, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120613 06:10]:
On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
Do you mean that gpmc driver should have the capability to calculate
peripheral
timings at runtime based on frequency ?,
Hi Tony,
On Wed, Jun 13, 2012 at 18:12:15, Tony Lindgren wrote:
Or should additional timings be achieved without affecting old
interface, but that it seems would necessitate more code
duplication.
We should just keep the same timings as before, with values
added for the newly added
Hi,
On Tue, Jun 12, 2012 at 4:18 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, May 30, 2012 at 08:04:23PM +0530, Kishon Vijay Abraham I wrote:
This series adds a new usb2 phy driver. The device for which is created
by the ocp2scp driver. This also uses control module driver.
This series
Hi Afzal,
On 06/13/2012 12:20 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
On 06/12/2012 01:53 AM, Mohammed, Afzal wrote:
On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote:
My preference would be to store gpmc_l3_clk in the pdata and pass to
Hi Afzal,
On 06/13/2012 08:05 AM, Mohammed, Afzal wrote:
Hi Tony,
On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120612 22:24]:
Hi Jon,
On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
Right but potentially, this could be done by the driver.
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 pwrdm_ops struct).
On Tue, Jun 12, 2012 at 5:31 PM, Tero Kristo
Hi Afzal,
On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
Platform will provide driver with configuration details for
each CS like configuration, timing, interrupts. Setup GPMC
based on it. Platform data also provides platform data
resources used for connected peripheral (eg. gpio irq).
GPMC
Hi Afzal,
On 06/13/2012 12:50 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, Jun 12, 2012 at 23:39:32, Hunter, Jon wrote:
On 06/12/2012 07:58 AM, Mohammed, Afzal wrote:
Thinking again over it, I am feeling above is sufficient, reason same as
said earlier, to keep code simple currently this
Hi Afzal,
On 06/13/2012 02:37 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, Jun 12, 2012 at 23:45:36, Hunter, Jon wrote:
GPMC_WAITPIN_IDX0 = 0
GPMC_WAITPIN_0 = 1
So, GPMC_WAITPIN_IDX0 = GPMC_WAITPIN_0 - 1, assuming that you want idx =
0 and not 1. Or you could change you shift value too.
First of all, this isn't fully tested yet. I can
see some issues poping up after this patchset which
I'm not sure if it's a race condition somewhere or
the HW is just misbehaving.
All in all, the IRQ handler looks cleaner now. There's
still lots of things to be done and before I'm going any
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 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 | 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
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
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.
Signed-off-by: Felipe Balbi ba...@ti.com
---
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 | 209 +
1 file changed, 84 insertions(+), 125
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
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 | 25 +++--
1 file changed, 15 insertions(+), 10 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
that way all our IRQ handling will happen in
thread.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
now that we're running on a thread, there's
no problem in doing lots of work as IRQs won't
be disabled anymore.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
same check we had on the threaded IRQ handler,
copy it to the bottom half.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9dadfb1..e555681
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 | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
comment asks us to clear it twice, so let's
do so.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e555681..f30eb45 100644
---
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 | 50 +
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git
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
documentation is very unclear about how that
works and testing shows that driver works without
it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git
that errata refers only to RDR interrupt. It's safe
to drop it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 20f854d..9274fcb 100644
---
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
we will already loop again and that variable
will be reinitialized at the beginning of the
loop.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
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
dev-buf_len will always contain the correct
number we're looking for. No need to read
from BUFSTAT register.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git
Hi Afzal,
On 06/13/2012 01:10 AM, Mohammed, Afzal wrote:
Hi Jon,
On Wed, Jun 13, 2012 at 00:12:27, Hunter, Jon wrote:
I am still wondering if we should warn against multiple devices using
the wait pin. I see that if could be valid to have multiple memory
devices of the same type using
Hi Afzal,
On 06/13/2012 12:03 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, Jun 12, 2012 at 23:00:48, Hunter, Jon wrote:
On 06/12/2012 01:16 AM, Mohammed, Afzal wrote:
With the existing code, set_async was done as part of set_sync, hence
requiring GPMC to be configured twice after driver
Hi Tony, Afzal,
On 06/13/2012 07:40 AM, Mohammed, Afzal wrote:
Hi Tony,
On Wed, Jun 13, 2012 at 17:03:59, Tony Lindgren wrote:
NAND for untested boards if timings change. Are Jon's comments all handled?
I have explained the justification, why those changes were done so,
waiting for his
On 06/13/2012 08:40 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120613 06:16]:
Hi Tony,
On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120612 11:01]:
On 06/12/2012 02:16 AM, Mohammed, Afzal wrote:
Does having minor revision add any
1 - 100 of 115 matches
Mail list logo
