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 t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]:
removed from timer code. New set of timers present on
OMAP4 are now supported.
Also, as
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 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 returns a
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 list:
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;
+
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 one of
Hi Mark,
On Fri, Nov 04, 2011 at 20:55:59, Mark Brown wrote:
On Fri, Nov 04, 2011 at 02:26:05PM +, 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 always a
confusion whether I
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 suggest
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 have
Hi Liam,
On Tue, Nov 08, 2011 at 21:26:39, Mark Brown wrote:
On Tue, Nov 08, 2011 at 06:54:10PM +0530, Afzal Mohammed wrote:
Count of selector voltage is required for regulator_set_voltage
to work via set_voltage_sel. VDD1/2 currently have it as zero,
so regulator_set_voltage won't work
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 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 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 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,
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, 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,
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 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
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [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
On Tue, Aug 07, 2012 at 12:43:51, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120713 01:01]:
* Tony Lindgren t...@atomide.com [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
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 using
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, was
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. I
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
values.
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 concerns above, anyway
Hi,
On Fri, Aug 31, 2012 at 23:53:32, Nicolas Pitre wrote:
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote:
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote:
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote:
AM335X EVM (based on AM33XX device) only supports
Hi Tony,
On Mon, Aug 27, 2012 at 14:04:44, Mohammed, Afzal wrote:
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
Hi,
On Fri, Aug 31, 2012 at 06:22:34, Tony Lindgren wrote:
This way we can remove includes of plat/gpio.h which won't work
with the single zImage support.
Note that we also remove the cpu_class_is_omap2() check
in gpio-omap.c as the drivers should not call it as we need to
make it local to
Hi Tony,
On Fri, Aug 31, 2012 at 06:22:37, Tony Lindgren wrote:
As the interrupts should only be defined in the platform_data, and
eventually coming from device tree, there's no need to define them
in header files.
Let's remove the hardcoded references to irqs.h and fix up the includes
so
Hi Tony,
On Wed, Sep 05, 2012 at 06:39:22, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120904 01:47]:
*I am not sending the patches now to avoid confusion by way of having
too many patch series*
In case you like this, let me know, I will post.
Yes please post the patches
Hi,
On Wed, Sep 05, 2012 at 14:20:09, Mohammed, Afzal wrote:
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.
+ if (GPMC_REVISION_MAJOR(l) 0x4)
+ gpmc_capability = GPMC_HAS_WR_ACCESS
Hi Tony,
On Wed, Sep 05, 2012 at 14:33:58, Mohammed, Afzal wrote:
On Wed, Sep 05, 2012 at 06:39:22, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120904 01:47]:
*I am not sending the patches now to avoid confusion by way of having
too many patch series*
In case you like
Hi Tony,
On Mon, Sep 03, 2012 at 11:04:10, Mohammed, Afzal wrote:
On Mon, Aug 27, 2012 at 14:04:44, Mohammed, Afzal wrote:
On Sat, Aug 25, 2012 at 01:16:30, Tony Lindgren wrote:
This hangs n800 during the boot.
Paul reported that n800 stopped booting on OMAP baseline [1]
due to an mmc
Hi Tony,
On Tue, Sep 11, 2012 at 05:47:10, Tony Lindgren wrote:
FYI, looks like a new warning got introduced, so I've
committed the following trivial patch on top of this series.
I was not careful enough, sorry. Thanks for fixing it.
Another hunk as follows would also be required for error
+Tony
On Tue, Sep 11, 2012 at 11:58:54, Mohammed, Afzal wrote:
Let probe return error value if gpmc terminal
count interrupt could not be obtained
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
My commit (now in l-o/devel-gpmc),
bd4156f mtd: nand: omap2: use gpmc provided irqs
Hi Tony,
On Tue, Sep 11, 2012 at 11:12:27, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120910 22:36]:
I was not careful enough, sorry. Thanks for fixing it.
Another hunk as follows would also be required for error
path even though compiler didn't complain.
Not sure
Hi Jon,
On Thu, Sep 06, 2012 at 01:25:23, Hunter, Jon wrote:
Nit-pick, I see some devices writing the above as ...
WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
Otherwise ...
Reviewed-by: Jon Hunter
Hi Tony,
On Sat, Sep 08, 2012 at 03:40:34, Tony Lindgren wrote:
Great, this all looks good to me. I suggest that on top of this
we add minimal devicetree binding that does not even attempt to
deal with the timings yet.
Then once the minimal devicetree binding is in place, we can
call the
On Tue, Sep 11, 2012 at 23:51:07, Tony Lindgren wrote:
Ah thanks, that's a copy paste UTF-8 issue. I'll just fold
in the fixes and push them out to a new devel-gpmc-fixed
branch.
Thanks Tony
Regards
Afzal
Hi Tony,
On Wed, Sep 12, 2012 at 00:16:06, Tony Lindgren wrote:
Here are the timing changes with and without this patch from
my n800. You can just diff the two files to see some differences.
Hmm.. that was pretty close, OneNAND async,sync as well as
tusb sync values were same.
But some of
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
* Mohammed, Afzal: Wednesday, September 12, 2012 3:20 PM
But some of the tusb async values is less by one. I need
to get it right.
Reason has been identified. It was due to rounding error,
no changes are required in the expressions. Moving
completely to picoseconds resolves the issue.
Can you
Hi Paul,
On Wed, Sep 12, 2012 at 22:04:16, Paul Walmsley wrote:
Two checkpatch warnings are added by this patch:
I did checkpatch earlier, but without --strict
I've fixed them here in the obvious way. But please make sure that all
your patches are clean with 'checkpatch.pl --strict';
Hi Paul,
On Thu, Sep 13, 2012 at 03:45:27, Paul Walmsley wrote:
+ HWMOD_INIT_NO_RESET |
As I understand it, this is not due to any GPMC-related reset bugs, but
just because the kernel is relying on the bootloader GPMC timing data
being preserved. Is that
Hi Tony,
On Fri, Sep 14, 2012 at 15:50:02, Mohammed, Afzal wrote:
* Mohammed, Afzal: Wednesday, September 12, 2012 3:20 PM
But some of the tusb async values is less by one. I need
to get it right.
Reason has been identified. It was due to rounding error,
no changes are required
Hi Tony,
On Tue, Sep 18, 2012 at 04:40:02, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120917 15:54]:
Can you please try with the attached patch ?
Gave it a quick try and it seemed to work.. But when I tried
rebasing my patches for the cbus to keep things working with
Hi Tony,
On Fri, Sep 21, 2012 at 10:21:04, Tony Lindgren wrote:
I gave this series a quick test on my n800 after applying the
two serial patches needed to get the uart to work, and it seems
to be working just fine.
Was there still some discussion on the format of the generic
timings
Hi Mark,
On Sat, Sep 22, 2012 at 00:57:38, Mark Jackson wrote:
I'm developing a beaglebone cape board which requires the use of a GPMC
chip select.
I've chosen GPMC_CS0, and in board-am335xevm.c, I have added the following:-
static void gpmc_test()
{
unsigned long base =
Hi Mark,
On Mon, Sep 24, 2012 at 16:21:40, Mark Jackson wrote:
On 24/09/12 05:51, Mohammed, Afzal wrote:
It seems you are using PSP Kernel.
Invoking omap_init_gpmc before gpmc request should help.
Okay ... I'm now using earlyprintk and omap_init_gpmc(), but I still get boot
hangs
On Tue, Sep 25, 2012 at 16:21:39, ABRAHAM, KISHON VIJAY wrote:
On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde m...@pengutronix.de
wrote:
I'm interested in to get these patches into the kernel soon. Kishon any
news on this patch?
Something like this would be required for USB support
Hi Jon,
On Thu, Sep 27, 2012 at 08:54:22, Hunter, Jon wrote:
On 09/19/2012 08:23 AM, Afzal Mohammed wrote:
+Dependency of peripheral timings on gpmc timings:
+
+cs_on: t_ceasu
Thanks for adding these details. Could be good to clarify that the
left-hand side parameters are the gpmc
Hi Tony,
On Fri, Sep 28, 2012 at 01:56:16, Tony Lindgren wrote:
Please see below a status update on the remaining problem
plat headers.
gpmc.h
Afzal, can you do a patch for gpmc.h?
Yes, I will do it.
Regards
Afzal
Hi Jon,
On Thu, Sep 27, 2012 at 20:46:12, Hunter, Jon wrote:
On 09/27/2012 05:07 AM, Mohammed, Afzal wrote:
Or maybe should the timings be grouped as ...
General
Read Async
Read Async Address/Data Multiplexed
Read Sync
Read Sync Address/Data Multiplexed
Write Async
Write Async
+ Jon and Paul
On Fri, Oct 05, 2012 at 21:04:57, Mohammed, Afzal wrote:
Hi,
This series prepares gpmc for generic timing. v7 of this series was
named OMAP-GPMC: generic time calc, prepare for driver. generic
timing routine has been removed from this series. generic timing
will be posted
+ Jon and Paul
On Fri, Oct 05, 2012 at 21:05:54, Mohammed, Afzal 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, omap_nand_flash_init was doing things
Hi,
On Fri, Oct 05, 2012 at 21:22:50, Mohammed, Afzal wrote:
This series cleans up omap-gpmc related code so that omap can
be a part of common zImage.
Upon selecting BCH CONFIG option, build breaks, updated
series - v2 that fixes it has been posted.
Regards
Afzal
Hi Ivan,
On Mon, Oct 08, 2012 at 11:05:56, Mohammed, Afzal wrote:
This series cleans up omap-gpmc related code so that omap can
be a part of common zImage.
This series moves gpmc.h from plat-omap/include/plat to mach-omap2
so that header file is local.
Patches 7 8 cleans up the already
On Wed, Oct 10, 2012 at 22:08:41, Ivan Djelic wrote:
On Mon, Oct 08, 2012 at 07:08:08AM +0100, Mohammed, Afzal wrote:
Please verify that BCH[48] works as earlier with this series.
I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2
tag.
All BCH error correcting
Hi Peter,
On Thu, Oct 11, 2012 at 15:05:43, Peter Meerwald wrote:
I'm getting the kernel log messages early in the bootup sequence (kernel
3.6.1 mainline)
[0.121337] GPMC revision 5.0
[0.121582] gpmc: irq-20 could not claim: err -22
This issue has been present for quite some time,
Hi Daniel,
On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote:
Admittedly, I lost track on the multiple GPMC series here, and they also
cause major merge conflicts with Linus' current master branch.
Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
Series [1-2] plus
Hi,
On Fri, Oct 12, 2012 at 21:54:52, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121012 08:56]:
omap-gpmc omap-gpmc: error: clk_get
omap-gpmc: probe of omap-gpmc failed with error -2
I think Afzal posted something about this already? Looks
like this too
Hi,
On Mon, Oct 15, 2012 at 17:44:07, Mohammed, Afzal wrote:
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
g...@gitorious.org:x0148406-public/linux-kernel.git tags/gpmc
Hi Tony,
On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [121011 05:48]:
After -rc1 is out, let's plan on adding the minimal
set required for removing plat and mach includes from
drivers into a clean-up branch. Afzal, can you maybe
do a pull request
+ linux-omap and Daniel
On Fri, Oct 19, 2012 at 16:20:21, Mohammed, Afzal wrote:
add am33xx rtc node.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Based on v3.7-rc1,
Dependent on series rtc: omap dt support (for am33xx),
(https://lkml.org/lkml/2012/10/19/163)
Tested on Beagle Bone
Hi Daniel,
On Thu, Oct 18, 2012 at 22:03:13, Hiremath, Vaibhav wrote:
On Thu, Oct 18, 2012 at 21:49:44, Daniel Mack wrote:
On 18.10.2012 18:12, Vaibhav Hiremath wrote:
It would be really helpful if you could test these patches and ack them.
Ok, will do tomorrow. What's missing there is
Hi Richard,
* Richard Cochran, October 21, 2012 1:05 PM:
People keep saying, the beaglebone works fine with v3.7-rc1, but it
isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been
fixed, and no one is doing anything about it either.
A fix to resolve the gpmc issue has been
Hi Daniel,
* Daniel Mack, November 03, 2012 1:06 AM:
I'm testing these patches with an AM33xx board that has the first musb
port wired to an USB type A plug, but it doesn't yet work for me.
So there is no host interface registered. I'm unsure on how to fix this,
and I didn't get an answer
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 0x2
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 gpmc
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 updated
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
--
To
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 that migration of gpmc
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;
+ }
Why not combined case 0 and default?
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 handle
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 are concerned, it is
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 driver.
GPMC HWMOD
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,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk
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 read. At
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, you could now
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 this is
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 building
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 review
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,
I
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 setting for smsc911x. I did not
want to break
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
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 and is fixed, hence this can
directly
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
I
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
only NAND related
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 ming@canonical.com wrote:
The IRQ52 on OMAP2+ is not a shared interrupt line. If IRQF_SHARED
is passed to
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 porting
1 - 100 of 299 matches
Mail list logo
