Hi Jon,
On Fri, Aug 17, 2012 at 20:32:34, Hunter, Jon wrote:
> > And we have been able to create such a function. Below is an implementation
> > that has been made for handling asynchronous timings. It has been tested for
> > OneNAND & SMSC on OMAP3EVM (rev G & C) with [1-4]. OneNAND was tested u
On Tue, Aug 07, 2012 at 12:43:51, Tony Lindgren wrote:
> * Tony Lindgren [120713 01:01]:
> > * Tony Lindgren [120712 23:46]:
> > > my scripts when applying patches. We'll have to apply this as a fix.
> > Arnd and Olof, let me know if you want me to resubmit a new branch instead
> > of the alread
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
> * Jon Hunter [120710 10:20]:
> > The DT node should simply have the information required by the retime
> > function or gpmc timings themselves if available. In the case of OneNAND
> > These can be stored in the DT and then t
Hi Tony,
On Thu, Jun 28, 2012 at 18:14:30, Mohammed, Afzal wrote:
> On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote:
> > * Mohammed, Afzal [120628 02:36]:
> > > diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
> > > b/arch/arm/mach-omap2/gpmc-onenand.c
> >
Hi Tony,
On Tue, Jul 10, 2012 at 18:35:55, Tony Lindgren wrote:
> The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
>
> Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/l
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 [120710 10:20]:
> > Hi Afzal,
> >
> > On 07/10/2012 08:47
Hi Tony,
On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote:
> * Mohammed, Afzal [120710 03:09]:
> > On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:
> > > * Mohammed, Afzal [120709 23:24]:
> > > > For the peripherals requiring retime, we cannot (as oth
Hi Tony,
On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:
> * Mohammed, Afzal [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 f
Hi Tony,
Could not respond you earlier as was sick
On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote:
> * Mohammed, Afzal [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 is the
>
Hi Tony,
On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
> * Mohammed, Afzal [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 l
Hi Grazvydas,
On Thu, Jul 05, 2012 at 17:58:55, Grazvydas Ignotas wrote:
> On Thu, Jul 5, 2012 at 10:21 AM, Mohammed, Afzal wrote:
> > Can someone please provide me with a link to N900 board schematics.
> >
> > It would be really helpful if information on how to do Numonyx
Hi Tony,
On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
> * Mohammed, Afzal [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 suggest
Hi Tony,
On Wed, Jul 04, 2012 at 13:21:59, Tony Lindgren wrote:
> * Mohammed, Afzal [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
+ 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
> ---
>
> Hi,
>
> This was tested on AM335X EVM. This depends on,
> http://www.mail-archive.com/linux-omap@vg
Hi Tony,
On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote:
> * Jon Hunter [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 gpmc code
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 op
Hi Tony,
On Mon, Jul 02, 2012 at 13:05:47, Tony Lindgren wrote:
> * Artem Bityutskiy [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 happen shortly would happen s
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
> &
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
> > freque
Hi Tony,
On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
> * Jon Hunter [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 mode
> > i
Hi,
On Fri, Jun 29, 2012 at 11:45:49, Mohammed, Afzal wrote:
> Kernel can't handle gpmc by itself, may be resetting onenand is
> a solution, as it seems bootloader is leaving it in sync mode.
To add, the above solution is made under the assumption that onenand
after reset will be in
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 [120628 02:36]:
> >> On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote:
> >>> The last patch in this series causes onenand n
Hi Tony,
On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote:
> * Mohammed, Afzal [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-o
Hi Tony,
On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote:
> * Mohammed, Afzal [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 &qu
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 on
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 initializa
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
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 creati
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 dea
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 omap
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
>
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 an
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 [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
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 _se
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
> * Mohammed, Afzal [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 use
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
> critic
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(on
Hi Tony,
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
> * Mohammed, Afzal [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
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 so
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, wh
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 w
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
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 com
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
> >
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
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 progra
Hi Tony,
On Thu, Jun 14, 2012 at 21:47:47, Artem Bityutskiy wrote:
> On Thu, 2012-06-14 at 16:01 +0000, 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 ob
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 th
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 wh
Hi Tony,
On Thu, Jun 14, 2012 at 17:59:31, Tony Lindgren wrote:
> * Mohammed, Afzal [120614 05:00]:
> > On Thu, Jun 14, 2012 at 17:22:08, Tony Lindgren wrote:
> > > * Mohammed, Afzal [120614 03:43]:
> > > > + t.clk_activation = fclk_offset_ns;
> > &
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 wi
Hi Tony,
On Thu, Jun 14, 2012 at 17:19:06, Tony Lindgren wrote:
> * Mohammed, Afzal [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,
p
Hi Tony,
On Thu, Jun 14, 2012 at 17:19:06, Tony Lindgren wrote:
> * Mohammed, Afzal [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 thi
Hi Tony,
On Thu, Jun 14, 2012 at 17:22:08, Tony Lindgren wrote:
> * Mohammed, Afzal [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,
shou
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 comm
Hi,
On Thu, Jun 14, 2012 at 15:06:25, Tony Lindgren wrote:
> * Mohammed, Afzal [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
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
Hi Tony,
On Thu, Jun 14, 2012 at 14:59:57, Tony Lindgren wrote:
> * Afzal Mohammed [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, wait_monitoring);
>
Hi Tony,
On Wed, Jun 13, 2012 at 19:13:24, Tony Lindgren wrote:
> * Mohammed, Afzal [120613 06:43]:
> > Do you mean for all the gpmc-* helpers existing initialization
> > needs to be modified to use the new interface, the previous version
> > was doing so. But then that
Hi Tony,
On Thu, Jun 14, 2012 at 14:26:52, Tony Lindgren wrote:
> * Afzal Mohammed [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 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
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
> >
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: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
Hi Tony,
On Thu, Jun 14, 2012 at 14:09:58, Tony Lindgren wrote:
> * Mohammed, Afzal [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 a
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;
> > +
> > +
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 b
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 unsubscri
Hi Tony,
On Thu, Jun 14, 2012 at 12:05:25, Tony Lindgren wrote:
> * Mohammed, Afzal [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 ca
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
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 wo
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 he
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 prob
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 a
Hi Tony,
On Wed, Jun 13, 2012 at 19:09:38, Tony Lindgren wrote:
> * Mohammed, Afzal [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 runt
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 f
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
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.
&
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 h
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 unsubscr
Hi Tony,
On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote:
> * Jon Hunter [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.
> >
>
Hi Tony,
On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
> * Mohammed, Afzal [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 no
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 li
Hi Tony,
On Wed, Jun 13, 2012 at 17:02:17, Tony Lindgren wrote:
> * Mohammed, Afzal [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 sho
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 ‘gpmc_cre
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 boa
Hi Artem,
On Wed, Jun 13, 2012 at 17:25:58, Artem Bityutskiy wrote:
> 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
> > + */
> > +#defineGPMC_NR_IRQ 2
>
> I guess "XXX" means "War
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 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 necessar
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
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);
>
> T
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_mi
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 suffic
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 would
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 is sufficient to
> > handle
Hi Jon,
On Tue, Jun 12, 2012 at 23:36:17, Hunter, Jon wrote:
> Well it is unclear what the code flow is for using this helper as this
> change simply adds the helper. If someone other function is writing to
> the CONFIG1 register before this function, then you may wish to
> highlight the programm
Hi Jon,
On Tue, Jun 12, 2012 at 23:32:05, Hunter, Jon wrote:
> Well looking at the function it seems that you either return an error
> code or 1. So if you are never going to return anything other than 1 on
> success it may as well be 0.
Irq & memory resource creation functions returns number of
Hi Jon,
On Tue, Jun 12, 2012 at 23:16:50, Hunter, Jon wrote:
> Ok, I see that this is necessary until all boards are migrated. However,
> please label with a FIXME to make it clear that this is to be removed.
Ok, I will update this.
Regards
Afzal
--
To unsubscribe from this list: send the line
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
> >> probe via the pdata.
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 takes control, with
> > your sugge
101 - 200 of 314 matches
Mail list logo
