Hi Tony, Jon,
Thanks for your explanations, ideas suggestions.
Let me try to come up with a solution based on these.
Regards
Afzal
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
Hi Afzal,
On 07/10/2012 08:47 AM, Mohammed, Afzal
Hi Tony,
Could not respond you earlier as was sick
On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120705 07:56]:
On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
Presently bigger issue that I am facing w.r.t driver conversion
Hi Tony,
On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120709 23:24]:
On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote:
format. But the peripheral specific retime function still needs to be
also registered for peripherals that need
Hi Tony,
On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120710 03:09]:
On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120709 23:24]:
For the peripherals requiring retime, we cannot (as otherwise whatever
Hi Tony,
On Wed, Jul 04, 2012 at 13:21:59, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120704 00:05]:
On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote:
Yes how about the gpmc using driver code registers itself with the gpmc
code
and also registers it's retime function
Hi Tony,
On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120705 03:29]:
Initially I thought you were suggesting that all peripheral drivers
connected to gpmc should register their retime function (where
Yes that's what I was suggesting
Hi Tony,
On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120705 03:29]:
I have a doubt whether we are talking about the same thing, presently
our main issue is in eliminating the necessity of peripheral specific
functions like gpmc_onenand_init
Hi Tony,
On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120702 10:30]:
2. Provide some sort of retime callback that the gpmc driver can call
at probe time to calculate the timings.
Yes how about the gpmc using driver code registers itself with the
+ Grant and device tree, watchdog lists
On Wed, Jul 04, 2012 at 18:00:37, Mohammed, Afzal wrote:
Add am33xx wdt node.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
This was tested on AM335X EVM. This depends on,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69424.html
Hi Tony,
On Mon, Jul 02, 2012 at 13:05:47, Tony Lindgren wrote:
* Artem Bityutskiy artem.bityuts...@linux.intel.com [120627 02:36]:
On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote:
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to
Hi Jon, Tony,
On Tue, Jul 03, 2012 at 20:40:03, Hunter, Jon wrote:
So we have 2 options here ...
1. Use the HWMOD_INIT_NO_RESET for now and your updated version of this
patch
2. See if there is a gpio available to control the OneNAND reset on the
n900.
Do you agree? Any other options?
Hi Jon,
On Mon, Jul 02, 2012 at 22:59:03, Hunter, Jon wrote:
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the
added diff
would be perfectly
Hi Tony,
On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120628 09:48]:
The above change seems to imply that Tony's n900 is dependent on the
bootloader settings
and not those being set by the kernel. Ideally, we should not need to set
the async
Hi Jon,
On Fri, Jun 29, 2012 at 19:45:37, Hunter, Jon wrote:
On 06/29/2012 01:15 AM, Mohammed, Afzal wrote:
I have a different opinion, even with the existing code, with the default
timings for onenand, Numonyx is working in async mode, reason being that
frequency is being obtained
Hi Tony, Jon,
On Thu, Jun 28, 2012 at 22:13:37, Hunter, Jon wrote:
On 06/28/2012 07:32 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote:
The last patch in this series causes onenand not to show
up on my n900. I
Hi Tony,
On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote:
The last patch in this series causes onenand not to show
up on my n900. I believe the problem has been there earlier
too, but I just did not notice it.
Sorry for the delayed response, could reach workplace a short
while ago only
Hi Tony,
On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
Yes that seems to do the trick, thanks! I can fold that into the
breaking patch when applying.
Relieved, thanks
Regards
Afzal
--
To unsubscribe from this list: send the line
Hi Tony,
On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index c8a9487..bbae674 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm
Hi Jon,
On Tue, Jun 26, 2012 at 20:26:40, Hunter, Jon wrote:
On 06/26/2012 09:39 AM, Jon Hunter wrote:
a single global variable called onenand_flags for storing the current
state of sync_read, sync_write, vhf and hf. At least this would be only
one global instead of 4. Not a big deal.
V5
Hi Artem,
On Wed, Jun 27, 2012 at 15:05:55, Artem Bityutskiy wrote:
On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote:
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
Hi Artem,
On Wed, Jun 27, 2012 at 15:10:02, Artem Bityutskiy wrote:
On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote:
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
Hi Tony,
On Wed, Jun 27, 2012 at 12:03:07, 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 NAND platform initialization functions
2. Prepares
Hi Jon,
On Mon, Jun 25, 2012 at 21:42:14, Hunter, Jon wrote:
On 06/22/2012 04:01 AM, Afzal Mohammed wrote:
+static int hf, vhf, sync_read, sync_write, latency;
I am wondering if we can remove hf, vhf, sync_read/write variables
completely. We already have flags from sync_read/write and so
Hi Jon,
On Mon, Jun 25, 2012 at 20:59:57, Hunter, Jon wrote:
On 06/22/2012 04:00 AM, Afzal Mohammed wrote:
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one,
Hi Tony,
On Fri, Jun 22, 2012 at 18:25:38, Mohammed, Afzal wrote:
This series is based on 3.5-rc1, and is dependent on [1,2,3], and has
been tested on omap3evm (smsc911x) rev G C and beagle board(nand).
Also using private patches, nand onenand was tested on omap3evm,
rev G C respectively
Hi Tony, Jon,
On Thu, Jun 21, 2012 at 05:05:56, Hunter, Jon wrote:
On 06/20/2012 10:12 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120620 07:57]:
Therefore, I am wondering if Afzal's driver needs to register the gpmc
devices outside of the gpmc_probe() and add the devices
Hi Jon,
On Thu, Jun 21, 2012 at 03:41:39, Hunter, Jon wrote:
Ok, I see your point. So today the _set_async_mode() is really doing two
things ...
1. It is calculating the timings
2. Programming the timings and setting async mode.
I think that it would be best if we were to make
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120616 02:19]:
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
By gpmc registration, if you meant registering platform device for
gpmc peripherals, for a board that uses the new gpmc
Hi,
On Tue, Jun 19, 2012 at 06:59:42, CF Adad wrote:
Anyway, we have advanced our kernel to today's latest l-o (3.5-rc2). Though
we are not considering the GPMC a likely source of the error at this moment,
I'm considering exploring this patchset. Unfortunately, the NAND is very
critical
Hi Jon,
On Mon, Jun 18, 2012 at 21:31:46, Hunter, Jon wrote:
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base +
Hi Tony,
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120615 03:26]:
Here clock is required even before driver is probed, i.e for platform to
calculate timings, that has to be passed through platform data.
Eventually we should be able to move
Hi Tony,
On Fri, Jun 15, 2012 at 11:12:46, Mohammed, Afzal wrote:
But I am unable to find reason for failure upon using
gpmc_ticks_to_ns(1), which seems to me right thing to be used.
Let me try to invoke tusb6010 functions in beagle board,
observe timings so that at least I will get an idea
Hi Jon,
On Thu, Jun 14, 2012 at 23:23:48, Hunter, Jon wrote:
On 06/14/2012 12:40 AM, Mohammed, Afzal wrote:
During gpmc driver probe, it will configure all the connected peripherals,
if configuration details are not present at that point of time, gpmc driver
will cry out saying
Hi Jon,
On Fri, Jun 15, 2012 at 00:28:44, Hunter, Jon wrote:
On 06/14/2012 08:32 AM, Mohammed, Afzal wrote:
On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote:
Why? You currently have a global variable storing the clock handle. It
can be quite common for drivers to know the clock
Hi Jon,
On Fri, Jun 15, 2012 at 02:21:50, Hunter, Jon wrote:
On 06/14/2012 01:17 AM, 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
Hi Tony,
On Fri, Jun 15, 2012 at 16:15:43, Tony Lindgren wrote:
something yesterday when manually patching the clk_activation, maybe
I put the clk_activation value into async timings instead as I was
seeing the tick value set to 0 for the sync mode.
I too thought like that initially, but
Hi Jon,
On Fri, Jun 15, 2012 at 02:36:26, Hunter, Jon wrote:
On 06/14/2012 03:48 AM, Mohammed, Afzal wrote:
What I meant is we are not dependent on absolute value of flag to
find waitpin, and I disagree in depending on its absolute value,
which can change, while flag would be the same
Hi Tony,
On Wed, Jun 13, 2012 at 18:03:05, Tony Lindgren wrote:
Cool, yeah looks like the old interface almost works. I had to undo the
new additions for tusb6010 DMA to work as below. Then Jon has some good
comments. I also made few comments to the GPMC using driver changes.
Thanks and
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
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
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
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,
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;
+
+
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 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
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
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
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 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
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
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
Hi Tony,
On Thu, Jun 14, 2012 at 17:59:31, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120614 05:00]:
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
Hi Jon,
On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote:
On 06/14/2012 02:03 AM, Mohammed, Afzal wrote:
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
Hi Artem,
On Wed, Jun 13, 2012 at 16:39:08, Tony Lindgren wrote:
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 maybe ack
the two mtd related patches?
After fixing as per Tony's comments, V2 [1] of the
Hi Tony,
On Thu, Jun 14, 2012 at 21:47:47, Artem Bityutskiy wrote:
On Thu, 2012-06-14 at 16:01 +, Mohammed, Afzal wrote:
After fixing as per Tony's comments, V2 [1] of the series has been
posted, can you please take a look at it.
I do not have any objections if Tony takes the entire
Hi Tony,
On Thu, Jun 14, 2012 at 22:23:37, Tony Lindgren wrote:
Sounds like the tusb6010 non-ns tick value is the only remaining
issue.
t.clk_activation = gpmc_ticks_to_ns(1);
was used so that gpmc_cs_set_timings would do gpmc_ns_to_ticks over
it hence effectively 1 tick would get
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
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
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
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
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
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
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
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
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
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 Jon,
On Wed, Jun 13, 2012 at 22:08:47, Hunter, Jon wrote:
On 06/13/2012 12:03 AM, Mohammed, Afzal wrote:
As gpmc_onenand_setup is a callback by onenand driver, we would have
lost the opportunity to configure onenand before driver is probed.
Is that a problem? Looks like it is called
Hi Jon,
On Wed, Jun 13, 2012 at 22:16:57, Hunter, Jon wrote:
Afzal, let me know if you have been able to test. I have a omap2430 with
onenand I could try.
Yes, this has been tested with omap3evm. Let me try if I can get another
onenand board to test.
If you can test, that would be really
Hi Jon,
On Tue, Jun 12, 2012 at 00:06:30, Hunter, Jon wrote:
I agree with getting rid of the first instance at the beginning of
_set_async_mode, but why get rid of the above one? Are you assuming that
by default it is in async mode? Could be nice to keep it to be explicit.
Second one is
Hi Jon,
On Tue, Jun 12, 2012 at 00:19:35, Hunter, Jon wrote:
What boards have been tested with this change?
Beagle board, after applying all 5 series of patches, without all
patch series it can't be tested for beagle board as it depended on
bootloader, not this API
+ u16 bus_turnaround;
Hi Jon,
On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote:
+ pdev = omap_device_build(name, -1, oh, pdata,
+ sizeof(*pdata), NULL, 0, 0);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+
Hi Jon,
This change is required only till driver migration of all platforms
are done, after it, this hackish patch has to be reverted. This has
been done so that existing interface will work for each patch of
this series as well as till all boards are migrated.
On Tue, Jun 12, 2012 at 02:00:21,
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 having minor revision add any value ?, at least as of now,
I do not see any.
+ dev_info(gpmc_dev, GPMC
Hi Jon,
On Tue, Jun 12, 2012 at 02:27:09, Hunter, Jon wrote:
+static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data *cs,
+ struct resource *res)
+ return 1;
+}
Nit-pick, CodingStyle chapter 16 states that 0 should be used for
success
Hi Jon,
On Tue, Jun 12, 2012 at 03:13:02, Hunter, Jon wrote:
+static void gpmc_setup_cs_config(unsigned cs, unsigned conf)
+{
+ u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
Why is it necessary to read the register first? I thought you wanted to
get away from relying on bootloader
Hi Jon,
On Tue, Jun 12, 2012 at 03:57:45, Hunter, Jon wrote:
+ if (p-cycle2cyclesamecsen)
+ l |= GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
+ else
+ l = ~GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
+ if (p-cycle2cyclediffcsen)
+ l |= GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
Hi Jon,
On Tue, Jun 12, 2012 at 04:00:20, Hunter, Jon wrote:
Nit, holler is slang. Just say WARN.
It was a deliberate attempt to add human (or read humorous) touch
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Hi Jon,
On Tue, Jun 12, 2012 at 04:29:09, Hunter, Jon wrote:
+enum {
+ GPMC_WAITPIN_IDX0,
+ GPMC_WAITPIN_IDX1,
+ GPMC_WAITPIN_IDX2,
+ GPMC_WAITPIN_IDX3,
+ GPMC_NR_WAITPIN
+};
Max number of wait pins is 3 for omap4/5. I know that we discussed this
in the past, but are
Hi Jon,
On Tue, Jun 12, 2012 at 04:34:33, Hunter, Jon wrote:
On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
Helper for reconfiguring CS, peripheral that necessitated
it was OneNAND.
Why? I think you need to add more about why this was needed.
Ok, I will describe more
Regards
Afzal
--
Hi Tony, Artem,
On Thu, Jun 07, 2012 at 20:44:03, Mohammed, Afzal wrote:
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
Hi Paul,
On Mon, Jun 11, 2012 at 18:45:03, Mohammed, Afzal wrote:
Add gpmc hwmod and associated interconnect data
HWMOD_INIT_NO_RESET can be removed once kernel is updated to
configure GPMC for all peripherals. Currently many depend on
bootloader, this facility will be removed.
(feature
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 NAND platform initialization functions
2. Cleans up
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 which is going to be posted
shortly (this series only
101 - 200 of 299 matches
Mail list logo
