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 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,
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 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 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, 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 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 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 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 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 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 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 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 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 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 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, 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,
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,
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 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 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 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, 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 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
+ 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 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
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 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]:
> > 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 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 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,
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, 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: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,
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, 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
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 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
Hi Tony,
On Sat, Aug 25, 2012 at 01:16:30, Tony Lindgren wrote:
> This hangs n800 during the boot.
Shall I read the above as n800 boot without patch 10/10,
but with the other patches in this series ?
As per the board file, n800 has tusb6010 as well as
OneNAND in sync read & async write mode, wa
Hi Jon,
On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
> On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
> > +/* can the cycles be avoided ? */
>
> What is the above comment referring too?
This was added in the initial stages and refers to the usage of
cycles in struct gpmc_device_timings.
Hi Tony,
On Sat, Aug 25, 2012 at 01:24:47, Tony Lindgren wrote:
> Yes agreed. Also as some values make sense only in cycles, converting them
> back and forth to time is wrong. So at least some values should have an
> option to specify them in cycles directly, and then ignore any time based
> valu
Hi Daniel,
On Mon, Aug 27, 2012 at 17:46:17, Daniel Mack wrote:
> > Such a generic routine would help create a driver out of gpmc platform
> > code, which would be peripheral agnostic and thus lead to DT finally.
> > Input to generic timing calculation routine would be gpmc peripheral
> > timings
Hi Daniel,
On Mon, Aug 27, 2012 at 19:00:32, Daniel Mack wrote:
> So the GPMC driver is the one that is matched from DT, and the NAND
> driver will the be instanciated from the (generic) GPMC driver?
I think you were referring to nand device being instantiated from
gpmc driver?, hence resulting
Hi Jon,
On Tue, Aug 28, 2012 at 02:00:13, Hunter, Jon wrote:
> On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
> > And at least for initial users, they are expected to have
> > some grasp on how to calculate timings, such a user will
> > not be much worried about your 3 conc
Hi Tony,
On Thu, Sep 15, 2011 at 11:12:53, DebBarma, Tarun Kanti wrote:
> On Thu, Sep 15, 2011 at 3:15 AM, Tony Lindgren wrote:
> > * Tarun Kanti DebBarma [110908 13:36]:
> >> removed from timer code. New set of timers present on
> >> OMAP4 are now supported.
> > Also, as we don't need the suppo
Hi Tony,
On Sat, Sep 17, 2011 at 07:05:31, Tony Lindgren wrote:
>
> Afzal, care to check if that works for AM335X/TI816X/TI814X?
With following patch over yours, AM335X (the only board with me) boots up fine.
Regards
Afzal
From ff64a239e60f9b517860eb2fe9c4f88a188ca51d Mon Sep 17 00:00:00 2001
Hi Govindraj,
On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
> If OMAP UART is used as console uart and debug is enabled,
> avoid gating of uart clocks to print all debug prints.
:
:
> console_uart_id = uart->num;
>
> + if (cmdline_find_option("d
Hi Govindraj,
On Wed, Oct 19, 2011 at 11:05:02, Mohammed, Afzal wrote:
> Hi Govindraj,
>
> On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
> > If OMAP UART is used as console uart and debug is enabled,
> > avoid gating of uart clocks to p
Hi Govindraj,
On Wed, Oct 19, 2011 at 18:22:58, Govindraj wrote:
> On Wed, Oct 19, 2011 at 11:05 AM, Mohammed, Afzal wrote:
> > Hi Govindraj,
> >
> > On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
> >> If OMAP UART is used as console uart and debug is enab
Hi Govindraj,
On Thu, Oct 20, 2011 at 14:09:22, Govindraj wrote:
> Yes correct, I missed that part here is the updated patch [1]
> Updated change-log for debug/loglevel and checked console_loglevel
> in addition to debug in bootargs.
Perhaps checking console_loglevel only is sufficient, if I am n
Hi Russell,
n Mon, Oct 17, 2011 at 18:30:32, Mohammed, Afzal wrote:
> Hi, Russell,
>
> While adding low level debug support for new board in OMAP2+ family, we
> came across following error,
>
> arch/arm/kernel/debug.S: Assembler messages:
> arch/arm/kernel/debug.S:138: Er
Hi Tony, Russell,
On Thu, Oct 20, 2011 at 22:41:13, Tony Lindgren wrote:
> * Russell King - ARM Linux [111020 09:15]:
> >
:
:
> > If it finds its way into the patch system. Note that I'm not applying
> > patches after end of today until after the kernel summit.
>
> Afzal, can you please put thi
Hi Kyla,
On Thu, Nov 03, 2011 at 22:38:01, Kyle Manna wrote:
> The JTAGREVNUM register contains a silicon revision number in the lower
> four bits and the upper four bits are to always read 0.
>
> To detect the presence of the device, attempt to read JTAGREVNUM
> register and check that it return
Hi Kyle,
On Thu, Nov 03, 2011 at 22:38:01, Kyle Manna wrote:
> + ret = mfd_add_devices(tps65910->dev, -1, tps65910s,
> + ARRAY_SIZE(tps65910s), NULL, 0);
> + if (ret < 0)
> + goto err2;
Isn't goto err sufficient
Regards
Afzal
--
To unsubscribe from this li
Hi Brown,
On Fri, Nov 04, 2011 at 19:34:22, Mark Brown wrote:
> On Fri, Nov 04, 2011 at 06:18:48PM +0530, Afzal Mohammed wrote:
>
> > if (i == TPS65910_REG_VDD1 || i == TPS65910_REG_VDD2) {
> > pmic->desc[i].ops = &tps65910_ops_dcdc;
> > + pmic->d
Hi Mark,
On Fri, Nov 04, 2011 at 20:54:11, Mark Brown wrote:
> ...should be in two separate commits.
Ok
>
> > 2. struct tps65910_platform_data usage can be avoided
> > by making use of struct tps65910_board to simplify
> > driver. Hence remove it
>
> Why is this a simplification? Note that
Hi Mark,
On Fri, Nov 04, 2011 at 20:55:59, Mark Brown wrote:
> On Fri, Nov 04, 2011 at 02:26:05PM +0000, Mohammed, Afzal wrote:
> > Hi Brown,
>
> Ahem.
I am sorry for that if it offended you, not deliberate, this may
have to do with our different cultures, for me it is alw
Hi Mark,
On Fri, Nov 04, 2011 at 21:48:56, Mark Brown wrote:
> So that definitely seems wrong then - n_voltages is supposed to be the
> number of voltages that can be selected so if the regulator supports
> _NUM_VOLTS steps then I'd expect to see that constant used directly.
> Otherwise I'd sugges
Hi Mark,
On Fri, Nov 04, 2011 at 22:10:09, Mark Brown wrote:
>
> What do you mean when you say "gain"?
>
Effective voltage expression is (value1 * 12.5mV + 562.5 mV) * value2.
In this value2 is being called as gain.
value1 can have values from 3 to 75, both inclusive (73 steps)
value2 can hav
Hi,
This is regarding board with multiple variations using an upcoming SoC from TI.
Variation of the board is detected by reading EEPROM using I2C after
init_machine gets invoked. In one of the variation UART# used is different.
Because of this decompressor logs (and early prints) can't be capture
Hi Tero,
With "this branch" you meant,
HEAD @ 297624c ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle,
right ? (the one Paul suggested to try)
Regards
Afzal
On Mon, Apr 23, 2012 at 14:54:04, Kristo, Tero wrote:
> On Fri, 2012-04-06 at 07:52 +0000, Mohammed, Afzal wrote
Hi Tero,
On Mon, Apr 23, 2012 at 15:43:22, Kristo, Tero wrote:
> > > can you try the attached patch with this branch and omap3evm board? I
> > > don't have the board myself so I can't test it myself (I tested this
> > > with omap3beagle and it works with that one.)
With your patch, OMAP3EVM boot
Hi Aneesh,
On Fri, Apr 13, 2012 at 01:28:55, V, Aneesh wrote:
> Thanks. I will wait for your review then. Once I have your comments
> I will re-work and submit in the new directory structure proposed.
Do you have a plan on submitting EMIF driver in the new proposed
(drivers/memory) directory. Or
Hi Santosh,
On Mon, Apr 23, 2012 at 16:34:46, Shilimkar, Santosh wrote:
> Please go ahead in creating directory.
Thanks for the quick reply.
Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Tero,
On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote:
> Okay thats good (although I wonder why the attachment got corrupted.)
> Did you check if the device suspends / resumes properly also? Can you
> check what do you have in the /proc/interrupts for the hwmod_io
> interrupt just after bo
Hi Tony,
On Wed, Apr 25, 2012 at 22:14:25, Tony Lindgren wrote:
> > Once driver is acceptable, platform code for other peripherals
> > connected via GPMC would be adapted to make use of GPMC driver. And
> > then the board modifications. But before that HWMOD entry has to be
> > populated for respe
Hi Tony,
On Wed, Apr 25, 2012 at 22:17:26, Tony Lindgren wrote:
> Obviously we can't merge any of this if until all the board-*.c files
> are changed and tested.
>
> Can you maybe still keep the old interfaces in addition to the new ones
> so we can do the conversion one board-*.c file at a time
Hi Kevin,
On Sat, Apr 28, 2012 at 04:45:21, Hilman, Kevin wrote:
> Afzal, care to test the patch below to see if it fixes your boot problem
> on OMAP3EVM with the IO chain series?
Your patch fixes the boot problem
Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-o
Hi Kevin,
On Tue, May 01, 2012 at 02:10:28, Hilman, Kevin wrote:
>
> Afzal, care to give this one a test as well? It should have the same
> result but is a more targetted fix. With and ack from Tero and a
> Tested-by from you, I'll post this to the list and and queue it up for
> v3.5.
Over wha
Hi Kevin,
On Tue, May 01, 2012 at 19:38:00, Hilman, Kevin wrote:
> >> Afzal, care to give this one a test as well? It should have the same
> >> result but is a more targetted fix. With and ack from Tero and a
> >> Tested-by from you, I'll post this to the list and and queue it up for
> >> v3.5.
Hi Jon,
On Tue, May 01, 2012 at 23:23:00, Hunter, Jon wrote:
> Hi Afzal,
>
> Looks good! Some minor comments ...
Thanks
> > +#defineGPMC_WAITPIN_IDX0 0x0
> > +#defineGPMC_WAITPIN_IDX1 0x1
> > +#defineGPMC_WAITPIN_IDX2
Hi Jon,
On Wed, May 02, 2012 at 02:11:48, Hunter, Jon wrote:
> > +
> > + pdata->clk_prd = gpmc_get_fclk_period();
>
> Does this need to be done here? May be this should be done in the probe
> function. You could store the handle to the main clk in the pdata.
This is done so that migration of g
Hi Jon,
On Wed, May 02, 2012 at 02:46:02, Hunter, Jon wrote:
> > Some boards depend on bootloader to update chip select value for NAND.
> > It is felt that Kernel should not depend on bootloader to get CS, as
> > for a particular board CS is hardwired and is fixed, hence this can
> > directly be u
Hi Sergei,
On Tue, May 01, 2012 at 22:19:37, Sergei Shtylyov wrote:
> > +
> > +#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
> > + defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
>
> You can use IS_ENABLED(CONFIG_MTD_ONENAND_OMAP2) instead these two.
Thanks for educating me.
Regards
Afzal
-
Hi Jon,
On Fri, May 04, 2012 at 21:50:16, Hunter, Jon wrote:
> > As mentioned in the cover letter,
> >
> > "Additional features that currently boards in mainline does not make
> > use of like, waitpin interrupt handling, changes to leverage revision
> > 6 IP differences has not been incorporated.
Hi Jon,
On Fri, May 04, 2012 at 21:57:10, Hunter, Jon wrote:
> > - gpmc_write_reg(GPMC_SYSCONFIG, l);
> > - gpmc_mem_init();
> > + switch (conf & GPMC_WAITPIN_MASK) {
> > + case GPMC_WAITPIN_0:
> > + idx = GPMC_WAITPIN_IDX0;
> > + break;
> > + case GPMC_WAITPIN_1:
>
Hi Jon,
On Fri, May 04, 2012 at 22:00:21, Hunter, Jon wrote:
> >>> +
> >>> + pdata->clk_prd = gpmc_get_fclk_period();
> >>
> >> Does this need to be done here? May be this should be done in the probe
> >> function. You could store the handle to the main clk in the pdata.
> >
> > This is done so t
Hi Paul,
On Sun, May 06, 2012 at 07:34:07, Paul Walmsley wrote:
> Did you notice the warning that this patch generates on boot?
>
> omap_hwmod: gpmc: cannot be enabled for reset (3)
>
> The HWMOD_NO_IDLEST hwmod flag is needed, since there is no GPMC IDLEST
> bit.
Yes, putting that flag makes
Hi Jon,
On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote:
> >>> + /* no waitpin */
> >>> + case 0:
> >>> + break;
> >>> + default:
> >>> + dev_err(gpmc->dev, "multiple waitpins selected on CS:%u\n", cs);
> >>> + return -EINVAL;
> >>> + break;
> >>> + }
> >>
> >>
Hi Jon,
On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote:
> > Clk_prd is a platform data passed to the driver, so platform code
> > updates it, where else can it be done ?
>
> The point is that you can pass what ever you like. You do not need to
> pass the frequency you can pass the clock han
Hi Jon,
On Mon, May 07, 2012 at 21:53:34, Hunter, Jon wrote:
> Write protect is a pin and there is only one. Like the waitpins and CS
> signals this needs to be associated with a device. It would make sense
> that this is associated with the cs data.
> >>>
> >>> As far as platform
Hi Tony,
On Tue, May 01, 2012 at 17:49:03, Mohammed, Afzal wrote:
> GPMC driver conversion patch series. Some peripherals has GPMC helper
> functions, these has been modified to cater to the needs of GPMC
> driver. All the boards using GPMC has been adapted to use the new
> GPMC drive
Hi Paul,
On Mon, May 07, 2012 at 16:42:16, Mohammed, Afzal wrote:
> > > +static struct omap_hwmod omap3xxx_gpmc_hwmod = {
> > > + .name = "gpmc",
> > > + .class = &omap3xxx_gpmc_hwmod_class,
> > > + .c
Hi Jon,
On Tue, May 08, 2012 at 20:38:24, Hunter, Jon wrote:
> > Different ways of doing things, this looks cleaner to me as already it is
> > checked, and time of execution in both cases would not differ much.
>
> Sure. However, I think that this could be simplified so that it is
> easier to re
Hi Jon,
On Tue, May 08, 2012 at 20:43:19, Hunter, Jon wrote:
> >> In fact if you migrate to runtime pm then we should not have the clk_get
> >> in the gpmc_init any more.
> >
> > Even if converted to RPM, to get clk rate, clk_get has to be done
> > somewhere, right ?
>
> Yes exactly. However, y
Hi Paul,
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
> > Major reason was that there are some boards that rely on bootloader
> > settings, eg. kernel does not do any setting for smsc911x. I did not
> > want to break those, at least it causes problem with omap3evm, see below
>
> But th
Hi Tony,
On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote:
> > To resolve this and as per your earlier question on whether old along
> > with new interface can be made to work parallely, here is suggestion
> > from my end to deal with it.
>
> I think this is the only way to keep this all bu
Hi Ivan,
On Wed, May 09, 2012 at 21:01:42, Tony Lindgren wrote:
> > Note that I could prepare a new MTD patch with BCH ecc code included,
> > allowing to drop the GPMC BCH ecc api.
>
> OK, let's do that then. I'll drop this patch and you can coordinate
> your patch with Afzal.
Now that some rev
Hi Ivan,
On Thu, May 10, 2012 at 23:15:27, Ivan Djelic wrote:
> > > So, when Afzal's patches are pushed, I'll submit a new, single MTD patch.
> >
> > But this is not going to happen this merge window as I understood, may
> > be not even the next one. We need to make UBIFS happy sooner than that,
Hi Paul,
On Thu, May 10, 2012 at 11:33:44, Mohammed, Afzal wrote:
> Hi Paul,
>
> On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
>
> > > Major reason was that there are some boards that rely on bootloader
> > > settings, eg. kernel does not do any s
Hi Tony,
On Sat, May 12, 2012 at 01:30:49, Tony Lindgren wrote:
> Let's try to get merged these into l-o master around -rc2 so we can
> have them tested properly for a few weeks before v3.6 merge window.
Sure, this will be my goal
Regards
Afzal
--
To unsubscribe from this list: send the line "u
Hi All,
On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:
> > > Some boards depend on bootloader to update chip select value for NAND.
> > > It is felt that Kernel should not depend on bootloader to get CS, as
> > > for a particular board CS is hardwired a
Hi Thomas,
On Tue, May 15, 2012 at 12:00:32, Thomas Weber wrote:
> > I need a help.
> >
> > Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
> > let me know GPMC CS on which NAND is connected.
> On Devkit8000 the NAND is connected to CS0.
Thanks for the information
>
Hi Tony,
On Tue, May 15, 2012 at 20:08:34, Mohammed, Afzal wrote:
> 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
&g
Hi Santosh,
On Fri, May 18, 2012 at 12:33:16, Shilimkar, Santosh wrote:
> + Afzal who has been doing quite a bit of GMPC work recently.
>
> On Fri, May 18, 2012 at 10:13 AM, Ming Lei wrote:
> > The IRQ52 on OMAP2+ is not a shared interrupt line. If IRQF_SHARED
> > is passed to request_irq and de
Hi Maxim,
On Fri, May 18, 2012 at 13:23:53, Maxim Podbereznyy wrote:
> Hey guys!
>
> Who knows how to initialize and use tps65910 driver in linux with
> am3517? I designed a board using the Craneboard schematic as a
> reference. Mistral provides the kernel 2.6.32 and it works fine. Now
> I'm port
Hi Santosh,
On Fri, May 18, 2012 at 15:43:31, Shilimkar, Santosh wrote:
> On the side note, looks like GMPC too needs to be converted
> to sparse IRQ since it seems to be creating a dummy irqchip
> and dispatching secondary handlers based on chip selects.
GPMC dummy chip is being modified to so
Hi Ivan,
On Sat, May 19, 2012 at 18:20:18, Ivan Djelic wrote:
> Hi Afzal,
>
> I tried to take your series of patches, but I had issues with the
> first [1] (I did not try the others): it depends on the following patch,
> which is not in the l2-mtd-2.6 tree:
>
> http://www.mail-archive.com/linux
Hi Artem,
On Tue, May 22, 2012 at 11:44:43, Artem Bityutskiy wrote:
> You merge the 2 trees and work on top of that? Or you wait for 3.5-r1
> when everything is merged and work on top of that?
I will merge 2 trees & do
Tony, are you ok with that ?
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+
Hi Paul,
On Tue, May 22, 2012 at 12:17:30, Paul Walmsley wrote:
> Hi Afzal
>
> On Thu, 10 May 2012, Mohammed, Afzal wrote:
>
> > On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
>
> (attribution lost)
Hmm, second time, normally I try to delete as much as po
1 - 100 of 314 matches
Mail list logo
